[mythtv] Mythtranscode .mpg => .mpg not .mpg => .nuv

[Geoffrey Hausheer]

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