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:
[EMAIL PROTECTED] /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:
[EMAIL PROTECTED] /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 * *************************************************************************
_______________________________________________ mythtv-users mailing list [EMAIL PROTECTED] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
