[ivtv-devel] Re: [mythtv-users] Nonlinear MPEG2 editor that
doesn't suck?
Cory Papenfuss
papenfuss at juneau.me.vt.edu
Wed Dec 15 13:58:33 UTC 2004
On Wed, 15 Dec 2004, Leo Weppelman wrote:
>> Anyway, it appears that a signifcant cleanup can be done with the
>> dvb-mplex and/or replex utility on the raw IVTV stream. It generates a
>> number of PTS-related errors such as:
>
> I have this too! I noticed that playing the stream with mplayer had no
> problems. Doing something like:
> mencoder <nuv> -oac copy -ovc copy -o <nuv.out>
>
> rebuild the B-frames in avidemux now and all is fine....
I'm assuming that this is what you are referring to:
ODML: Aspect information not (yet?) available or unspecified, not writing
vprp header.
Pos: 0.7s 22f ( 0%) 0fps Trem: 0min 0mb A-V:0.070 [0:192]
Skipping frame!
Pos: 1.1s 35f ( 0%) 0fps Trem: 0min 0mb A-V:0.067 [761:192]
Skipping frame!
Pos: 8.0s 241f ( 0%) 0fps Trem: 0min 507mb A-V:-0.068 [687:192]
1 duplicate frame(s)!
Pos: 8.5s 256f ( 0%) 0fps Trem: 0min 552mb A-V:-0.068 [915:192]
1 duplicate frame(s)!
Pos: 579.8s 17378f (35%) 644fps Trem: 0min 811mb A-V:-0.068
[4006:192]]
1 duplicate frame(s)!
Pos: 580.2s 17388f (35%) 644fps Trem: 0min 811mb A-V:-0.068 [4005:192]
1 duplicate frame(s)!
Pos: 580.6s 17398f (35%) 644fps Trem: 0min 811mb A-V:-0.068 [4005:192]
1 duplicate frame(s)!
Pos: 580.9s 17408f (35%) 645fps Trem: 0min 811mb A-V:-0.068 [4004:192]
1 duplicate frame(s)!
Pos: 581.3s 17418f (35%) 645fps Trem: 0min 811mb A-V:-0.068 [4003:192]
I'm a bit confused, however, since the "output" of mencoder is an
avi file:
papenfuss at juneau /video/footage> file test2.nuv
test2.nuv: RIFF (little-endian) data, AVI
I'm fine with it being wrapped in an AVI, but as I see it there
are two things going on here. One is stripping out some apparently
unnecessary streams:
papenfuss at juneau /video/footage> du -sm test.nuv test.nuv_clean.nuv
871 test.nuv
815 test.nuv_clean.nuv
since some of tcscan's output onthe original said:
stream id [0xbb] 1
stream id [0xbe] 18
stream id [0xbf] 2
stream id [0xc0] 2
stream id [0xe0] 35
... and the other is a *workaround* for avidemux. MPlayer knows
how to parse an MPEG stream with varying sync information (VPTS? APTS?
frame_time? --av_fine_ms?). Avidemux seems to have a static offset that
it generates when it originally indexes an MPEG file (e.g. 66ms). If the
offset changes within the video, it breaks.
My question is, what exactly is rebuilding the B-frames doing?
Is it avidemux's way of generating the indexing offset information on a
per-GOP basis? It's certainly not manipulating the actual video stream,
is it?
Very interesting and it seems like it might be a viable workaround
at this point. Still... a repair of the stream (either at the ivtv driver
level or as a post-processing script) would make the most sense.
-Cory
*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************
More information about the mythtv-users
mailing list