On 11/13/05, Cory Papenfuss papenfuss-at-juneau.me.vt.edu {MythTV}
<[EMAIL PROTECTED]> 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 *
*************************************************************************
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
