[mythtv] Questions for MPEG2 knowledgable folks

[Cory Papenfuss]

> Interesting, I didn't know the PVR cards would do this
>
 	It's the biggest reason why people bitch once in awhile about 
trying to burn ivtv captures to DVDs.  Most of the HOWTOs out there split 
into ES's and remux (to add the DVD NAV streams).  When that's done, sync 
gets off since the PTS information is discarded.  ProjectX appears to be 
the closest thing to being able to clean up the streams at the moment. 
Unfortunately, it's a 900-lb Java-flavored gorilla.

>>
>>         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.
 	Is the behavior of a playback device defined for when this 
happens?  I'd only heard of applying to broken bit when a GOP gets mangled 
(e.g. non-keyframe editing).

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.

 	There's open vs. closed GOPs, as well as different GOP structures. 
I didn't think that DVD-compliance implied either of those, however... I 
thought that open/closed and variable-length GOP structures were OK. 
Maybe it's just that the settop players are often tolerant of them and 
I've never noticed.

 	... that brings us back to your original question.  Can P/B frames 
be "losslessly" converted into I-frames.  I know very little about the 
internals of MPEG2 compression, so I can't help there.  I do know that the 
MPEG2 streams produced from ivtv card are pretty dirty.  In most captures 
I've played with, I've seen lost packets, very short PUs (generally a few 
dozen GOPs), fixed GOP length/structure (leading to poor choices on 
I-frames during scene changes, etc), open or closed GOP structures, etc. 
If the *structure* of the stream could be cleaned up without introducing a 
"generation loss," that would be great.  I suspect it would be pretty 
expensive, computationally.  It does fix all the problems, however.

>
> 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.
 	I think if you get clean streams, you've got 95% of the problems 
with commercial cutting solved.

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.
 	Sounds great, but won't it still be non-standard?  The problem is 
only partially that the encapsulation is funky.  The ES's themselves can 
be wrong (wrong GOP structure for instance).  They'll be especially wrong 
once frames are added/removed to fix PTS/DTS sync loss.  If you're right 
about the DVD-standard ONLY allowing a fixed GOP structure, you're kinda 
screwed to reencode ("losslessly" into I-frames or otherwise).  If it 
allows for variable, you could transcode only around dropped frames (and 
by trivial extension, commercial cuts).

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).
>
 	*Minimum* rate-limiting?

-Cory

-- 

*************************************************************************
* Cory Papenfuss                                                        *
* Electrical Engineering candidate Ph.D. graduate student               *
* Virginia Polytechnic Institute and State University                   *
*************************************************************************