[mythtv] New MPEG2 commercial-cut code ready for testing
Cory Papenfuss
papenfuss at juneau.me.vt.edu
Tue Nov 15 11:28:48 EST 2005
> 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 *
*************************************************************************
More information about the mythtv-dev
mailing list