On 11/4/05, Cory Papenfuss wrote: > On Thu, 3 Nov 2005, Geoffrey Hausheer wrote: > - Did you mean this tarball? :) > http://www.pblue.org/myth/mpeg2fix-0.2.tgz Of course. The other is the prelude to what is currently in mythtranscode that I did 2 years ago :)
> > - I'm confused as to what you mean by "discontinuous PTS" as > opposed to "a PTS discrepency"... The PTS fixup code goes, but only with > the 3to2 enabled? Is that what you mean by discontinuous PTS code broken? It will probably be more clear if I explain what the code does: for a block of frames (a I/P followed by all of its subsequent B frames) we reorder them into presentation order (So I-B1-B2 would become B1-B2-I) and check the PTS against the expected value (what you'd get if you add 1/frame-rate). In the case where -no3to2 is set, we just clear any pulldown flags and move on. If -no3to2 is not set, then and 3:2 is set for this frame, we add an additional 0.5frame to the expected PTS. Next we check whether the expected PTS < actual PTS by more than 0.5 frame. If so, we generate however many I-frames would be needed to catch up. Next we check If fixup is set (either by -no3to2 or independantly). If so the actual PTS is set to the expected PTS. We then set the DTS accordingly (we never preserve , or even look at the original the DTS), and write the frames out in the original order to the multiplexer. So to answer your question: The code assumes the PTS is continuous, and that any discontinuity implies a missing frame that it should fill. this is obviously a bogus assumption, and needs to be fixed. I just haven't figured out how I want to do it yet. > > - It appears to remux a chunk of video I've got and then hang, > sucking CPU. Nothing logged with debug=4, just sitting there. > Threadlock, maybe? If it is sucking CPU it is probably not a deadlock. The code isn't really multithreaded except at the top most level. it is actually a ping-pong mode (one thread runs, then signals the other and waits for a signal that the other is done, and so on). The only reason for the threading is because replex wants to drive the decoding, and that isn't really flexible enough for my needs. More likely it is in an infinite loop in one of two places: (1) no 'Picture' frame was found by libmpeg2 and it is in a endless loop trying to decode an invalid frame, or (2) the PTS received was completely bogus, and we are trying to create hundreds of filler frames to catch up . Running it through gdb, and just pressing ctrl-c then doing 'thread apply all bt' would be helpful here. > > - The remuxing cuts the original up into lots of PU's. Is that required > for your bitrate matching? Actually, the one part of replex I haven't looked at is how the SCR is synchronized with the packets. the PS packets are all ~2k in size, but as far as how it ensures they stay in step, I haven't looked into it. In my experiece it does a pretty good job though. Here is a link to my mpegparse utility: http://www.pblue.org/myth/mpegparse.c It has no dependencies, just 'gcc -o mpegparse mpegparse.c' It is very crude, but will analyze most streams, and the output can be sent to me (actually only need +/- 500 lines around the PTS that the fixer is hung on). Using it on your original stream can help find addities that might cause mpeg2fix to go into fits. To determine the correct PTS to look for you need the offset. The top couple of lines from mpeg2fix (with debug set to at least 2) will appear as: number1 number2 number3 number4 V:number5 A:number6 delta: number7 the interesting one is number2 in this case. add number2+PTS from mpeg2fix to get the PTS seen by mpeg2parse. The biggest problem with this kind of stuff is that mpeg2 streams tend to be huge, so getting useful examples for debugging can be hard, so it requires a lot of patience to work out these bugs. Thanks, .Geoff _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
