[mythtv-users] pluggable mythtranscode
Michael T. Dean
mtdean at thirdcontact.com
Tue Mar 27 02:11:24 UTC 2012
On 03/26/2012 03:42 PM, Brian J. Murrell wrote:
> On 12-03-26 03:35 PM, Brian J. Murrell wrote:
>> On 12-03-26 03:05 PM, Raymond Wagner wrote:
>>> of course there
>>> should be no use to it. Better to apply the cutlist at the same time,
>>> or do so before hand with lossless transcode, rather than bother
>>> transcoding all that video.
>> Of course, a deteline
> Uhm. s/deteline/detelecine/
>> operation has a known and predictable effect on
>> frame numbers. I suppose one could mathematically fix up the flagging
>> values to account for the 29.97/24 framerate reduction.
> The other obvious solution of course is to transcode before commflagging.
> The only downside to that is that while commflagging can be done in real
> time, and is therefore useful for those situations where you watch very
> shortly after the program starts, waiting for the transcoding before
> getting that commflagging benefit eliminates that ability.
> And of course, one can re-commflag after transcoding to get the best of
> both worlds, at the slight cost of a second commflag.
And, FWIW, compared to transcoding, commercial flagging is a piece of
cake/walk in the park/easy, which is why we've always just had you do a
mythcommflag --rebuild and a new mythcommflag run.
Basically, if you're wasting, er, spending 2 to 12 hrs of max-load
electricity usage to transcode an hour-long recording, what's another
2-5 minutes. ;)
FWIW, I think Jim Stichnoth did a patch (and I think it was committed)
to adjust some of the seek and/or flag and/or cut data after a lossless
transcode--but pretty sure it's only lossless transcode and only when
performed by (built-in) mythtranscode. (Jim can probably give more
More information about the mythtv-users