[mythtv-users] pluggable mythtranscode

[Michael T. Dean]

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 
details.)

Mike