[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