[mythtv] Questions for MPEG2 knowledgable folks

Geoffrey Hausheer mythtv0368 at phracturedblue.com
Fri Oct 21 06:11:53 UTC 2005


On 10/20/05, Cory Papenfuss wrote:
>         So you're planning on padding and/or discarding mis-matched A and
> V stream frames?
Yes.  Well, you can't discard audio frames, as that really disrupts
the experience, though one possibility is to speed them up with pitch
correction.  If it is only 10-20 ms/sec it is unlikely you'll even
here the difference..  The other option is to add remove frames in
video (which is the option I'm currently using, because it is simple
to impelement).  The current problem I'm having is that while I can
remove B-frames to speed up video (which I don't normally have to do),
and this has a minimum impact on the bitrate, I can only insert I
frames, which is causing overruns in the allowed bitrate (resulting in
an SCR/PTS mismatch during muxing).  The other problem with this is
that I-frames don't happen very often (and since I'm not doing any
encoding, I can only insert a duplicate I-frame next to an existing
i-frame), so you need to insert longer delays, which are very
noticable as stuttering video.  Ideally, I could generate a P-frame
with all motion-vectors zeroed out.  This frame could be inserted
after any I or P frame letting me smooth out the video slow-down, and
would have a minimal impact on the video bitrate.  It may not be quite
as flexible though, and I haven't figured out how to code valid
P-frames as yet, but this is likely my next avenue of attack.

>         I still think a partial reconversion would be a great compromise.
> ONLY reencode (even it's a full decode/reencode of an entire GOP) around
> glitches in the stream or commercial cuts.
Yes, this would be ideal, and I had planned on coding it back when I
first did mpeg2trans (almost 2 years ago now), but it requires getting
everything else working first, and I never had much luck ironing out
the 1st wave of bugs.



More information about the mythtv-dev mailing list