[mythtv] Questions for MPEG2 knowledgable folks

Geoffrey Hausheer mythtv0368 at phracturedblue.com
Wed Oct 19 18:21:52 UTC 2005


On 10/19/05, Cory Papenfuss wrote:
>         I wouldn't call myself too knowlegable about MPEG2 stuff, but this
> is a fairly well-known issue with ivtv streams from the Hauppauge cards.
> When there's a glitch, it will drop frames and adjust the PTS to
> compensate.  It is especially prone to this on "dirty" signals like from
> an analog tape (no TBC is the most likely culprit).

Interesting, I didn't know the PVR cards would do this

>
>         I'm not sure of the best solution, but I rather like the idea of
> either converting to I-frames, or perhaps reencoding around the bad spot.
> This has other uses (e.g. "lossless" commercial cutting).  Subtle things
> become more important, though... like do you offset the PTS/DTS of
> everything after the first cut by the 4 minutes you removed?  What does
> the MPEG spec say about discontinuous PTS?
>
>         Basically MPEG2 was never meant to be edited... :)
Actually, MPEG2 is designed to be edited...sort of.  the spec allows
for discontinuous PTS if you set the broken bit.  However, it isn't
designed to allow editing at an arbitrary frame.  It is further
restricted bythings like DVD-compliance.  For insatnce, it would be
perfectly valid to reencode B frames into I frames, and include those
at the beginning of a GOP after a cut, thus allowing frame-accurate
cutting.  But DVDs require a strict GOP structure, so this wouldn't be
a DVD-compliant stream.

But yes, mpeg2trans already has code to adjust PTS and DTS values so
that there are no apparent breaks after a commercial cut.  Note that
I'm not looking at commercial cutting at the moment, just into getting
'clean' mpeg2 streams.  Depending on how this goes, I'll probably
revisit the mpeg2trans code.  My current plan is actually to fully
demux the streams after ensuring they are exactly the same length
(thus trhowing away all pts/dts info), and remux them from the ES,
thus creating a 'clean' encapsulation.  the main problem with the
mpeg2trans code at the moment, is that it doesn't respect the
rate-limiting (adding in padding frames where needed) which can cause
poor playback by some devices.  Unfortunately, I don't know of any GPL
MPEG2-muxers that will enforce rate-limiting, so i'm not sure what I
can do about this (besides writing my own).



More information about the mythtv-dev mailing list