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 *
*************************************************************************
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
