[mythtv] New MPEG2 commercial-cut code ready for testing

[Cory Papenfuss]

> your original looks like this (in presentation order)
> 0   ...    7     8    9    10    11
> I    ...    B    P    B    B      P
> I    ...    I*    I*     B   B      P
>
> where the '*' represents a regenerated frame. This was done correctly
> (or, more precisely, as expected)  If the I* frames aren't generated
> correctly, then the rest of the GOP is likely to be hosed, as all
> further frames (P and B) are generated from frame 8.  This is the
> situation in which looking at the orginal B frames, and regenerated I
> frames should help.  Your streams seem to have custom quantization
> matrices, and that may be influencing the code too.  I have a clip you
> sent me earlier, and I'll play with that and see if I can see what you
> see.  The 'enc' data still isn't being generated correctly for some
> reason, so I can't yet do before-vs-after comparisons.
>
 	Whoops... I realized that it might be the stream-order vs. 
presentation order that was confusing me.  Still though...

>>         The second I-frame looks blockier than the B-frame it was
>> generated from.  Also, the third I-frame (which should be the same as the
>> original 7400) look different and more blocky.  Wrong header that gets
>> inherited?  By the next GOP, things have cleared up.
> See the above explanation.  I hope it explains what is going on.
>
 	My original thought still seems correct.  I finally wrote up a 
diagram to step through and see which is which.  In yours, #8 which is 
a P in the original is different from the generated I* in the copy.  I 
understand that all subsequent frames after #8 I* in the copy will be 
based on #8's data then.

 	If it's any help, the original has interlacing present, whereas 
the copy looks to have less interlacing, but more blocky colors.  I can 
send a chunk of the original containing the cut if desired.

 	Also, it might be helpful to hack up mpegparse to include what he 
thinks the frame# is (as per mepg2fix's definition).  As it is, I'm still 
using avidemux to visually determine absolute frame numbers (and I/P/B 
type).

 	Man... between all the logic of GOPs, open/closed, PTS 
discrepancies, stream order AND frame order, it's a bit of a mind-job to 
sort it all out.

>> The bad heuristic still present:
>> "Need to insert 7394 frames > max allowed: 20"
> This is caused by cutting on a frame that has no PTS.  I know how to
> fix it, but haven't done so yet, as I'm trying to figure out a way to
> do it that isn't a hack.  The next release should have this fixed,
> though.
> .
>
 	Nifty.

> Yes this is my plan.  I might even be able to get rid of the Qt
> requirement (I'm only using it because it has more powerful lists than
> C++ does on its own).  While the program is being targeted at myth, I
> am doing my best to make sure it can be used stand-aolne as well.
>
 	Yay.  :)

-Cory

-- 

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