[mythtv] New MPEG2 commercial-cut code ready for testing
Cory Papenfuss
papenfuss at juneau.me.vt.edu
Mon Nov 14 07:13:31 EST 2005
> On 11/13/05, Cory Papenfuss papenfuss-at-juneau.me.vt.edu {MythTV}
> <ticket_7ae9cde7519064942bb26bba32c78366 at phracturedblue.com> wrote:
>> That got it to compile, but the -c doesn't appear to work
>> correctly on one of my streams. I'm sending something like:
>> mpeg2fix -i sync.nuv -o test.mpg -c "1 - 7440"
>> and it hangs indefinately. If I cut to a different point:
>> mpeg2fix -i sync.nuv -o test.mpg -c "1 - 7400"
>> it appears to work (although blockiness).
> I have found a couple of trivial fixes that may address the blockiness
> and the hanging (and a segfault). Go here:
> http://www.pblue.org/myth/mpeg2fix-0.8.tgz
>
The hangs I mentioned appear to be gone now, but the blockiness at
the cuts remains.
> Basically, what I have been doing to test is to take a stream, choose
> two arbitrary cut points and then move them around
> incrementing/decrementing one at a time to cycle through an entire GOP
> at the front and the end, watching the 'Converting Frame...' message
> to see what frame number I'm on.
>
Question about this... shouldn't frame 0 already *be* an I-frame,
or is that not what these signify?
Converting frame 6 to an I-frame ((null))
Converting frame 7 to an I-frame ((null))
Converting frame 8 to an I-frame ((null))
Converting frame 0 to an I-frame ((null))
Converting frame 1 to an I-frame ((null))
Warning, QMAT_SHIFT is larger then 21, overflows possible
Converting frame 3 to an I-frame ((null))
Warning, QMAT_SHIFT is larger then 21, overflows possible
> But yes, you are using it correctly: -c "start_frame - end_frame" (in
> absolute frame numbers). Because of telecine, there is no easy way to
> predict what time the cuts are supposed to happen, so I the logic got
> pretty hairy, and that is what I am most concerned about.
>
That will be tough to debug and probably just needs more people
to hammer on it to see where it breaks. At least I seem to have a
collection of rough-around-the-edges streams to do some preliminary
breaking... :)
One thing that gets a little bit screwy here is what a frame
number actually means. Since the purpose of this is be able to insert
video frames to maintain sync, it ends up being effectively synced to the
audio PTS, no?
> There is one thing I know needs fixing: At the end of a cutlist, the
> frame-number should restart at '0', and that doesn't happen yet. I'm
> not sure if this will cause playback problems or not, but in general,
> it shouldn't. After a cutframe, I do reencode such that the first
> frame is always an 'I' frame, and add a sequence and gop header at
> that point.
>
My guess is that somewhere in the construction of all that is
what's causing the blockiness. I wish I could find a decent utility to
easily parse through the resulting streams. I'm so far using avidemux to
index and count frames, etc.
I just now managed to find one... trying to back down from frame
#7400 on my stream to find if I could eliminate the blockiness, I got
this:
$mpeg2fix -i sync.nuv -o test.mpg -c "1 - 7398" -c "7450 - 51428"
Opening sync.nuv
Input #0, mpeg, from 'sync.nuv':
Duration: N/A, bitrate: N/A
Stream #0.0[0x1e0], 29.97 fps: Video: mpeg2video, yuv420p, 704x480, 5370
kb/s
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, 192 kb/s
#0 PTS:16022 Delta: 0.000000ms queue: 2
#1 PTS:16022 Delta: 0.000000ms queue: 1
Converting frame 3 to an I-frame ((null))
Converting frame 4 to an I-frame ((null))
Converting frame 5 to an I-frame ((null))
Need to insert 7394 frames > max allowed: 20
... sounds like a heuristic logic error like you may be looking
to find.
-Cory
--
*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************
More information about the mythtv-dev
mailing list