[mythtv] mythtranscode, key frames and fifo output

[Chris Petersen]

> So let me get this straight, you want to rewrite mythtranscode in php? :)

hah.  if I could, I would probably have done so (though perl -- php on 
the commandline is just weird).  ;)

> Since Geoffrey hasn't been around lately, I've been trying to
> maintain/enhance the transcoder so I'll look into this.

Cool, I'm much obliged.

> I haven't seen this, but like your 2nd email states, I'm using ivtv for
> all my recordings.  I do have a few old MPEG4 files around for testing
> with though and some new transcodes that are MPEG4 as well so I can test.

It's not all recordings, either.  Though I think the keyframe (something 
I don't really understand) thing is probably the key (no pun intended).

It's also odd that it seems to work fine for playback within myth, but 
not the fifo stuff, since as I understand it, they all use the same code 
for dealing with cutlists..

> I know exactly why this happens and can fix this fairly easily I
> believe.  The editor limits you to setting a cutpoint within a certain
> distance of the end of a recording.  This is done (in part) because
> the player can't see to within a certain distance of the end of
> the recording, partially because there may be no keyframe or
> seektable entry that close to the end.

Yup.  the no-keyframe-at end thing was how it was explained to me originally

> I'll see what I can find on the non-exact cuts, the extra stuff at
> the end should be easy for me to fix.  Basically if there is an
> end-cut marker within 2 seconds or so of the end, the mythtranscode
> should ignore it and just skip all frames left.

Cool.  That'd rock.   Will still have to do something funky for 
nuvexport's transcode stuff (since it seems faster/better to have 
transcode handle the cutlist internally), but at least the default 
ffmpeg stuff will be good (ffmpeg can't deal with cutlists, and its 
internal denoise stuff sucks, so we use mythtranscode for all of those).

-Chris