GNOME Bugzilla – Bug 99589
[PATCH] mpeg created with mplexhi -V exhibit choppy video
Last modified: 2006-03-10 16:50:23 UTC
To reproduce, render separate mpeg audio & video. You can easily do this with cinelerra. Mux these streams with "mplexhi -V". The -V switch is for variable bit rate. Try playing the mux'd mpeg with gstreamer. The video looks choppy -- pause a little too long then show frames a little too fast, etc. i can provide an example mpeg if needed. Without the -V flag, i can't figure out how to create very small (less than 20M for 3 minutes) mpeg streams.
you will at least have to provide a sample video, yes. Have you tried with other players ?
An example stream is available at: ftp://ftp.berlios.de/pub/redael/nau-scene1.mpg It plays perfectly with MPlayer. i suspect gstreamer is getting confused because of the VBR encoding.
The problem appears to be bad discontinuity detection in mpegparse, I'm looking into it.
this mpeg has wrong SCR values that don't match the stated muxrate. you can temporarily get correct playback by making the discontinuity checking less strict by adding max_discont=200000 to mpegdemux. I don't really know yet how to solve this properly..
This problem seems to slow down seeking quite a lot. It is a real problem. Can you make an index for SCR to speed this up?
For my application, this is the highest priority bug due to gstreamer. i really need a good solution for this as soon as possible.
i decided to try fixing this myself. My proposed patch uses the index to determine the next_scr. Only if the index is unavailable, it resorts to the old guesswork. This seems to fix the problem. i run my indexer with max_discont=1000000 and run my playback with max_discont=10000 and it works. i'm not sure if this is the _correct_ fix or if i am just curing the symptom of some deeper problem. Wim, please comment.
Created attachment 13468 [details] [review] proposed fix for next_scr
This still isn't a complete fix. Somehow seeks are not getting exactly the correct byte-offset and mpeg2dec is blowing up downstream. ==21648== Thread 2: ==21648== Invalid read of size 1 ==21648== at 0x470A6918: mpeg2_idct_copy_c (idct.c:171) ==21648== by 0x470A08E2: mpeg2_slice (slice.c:980) ==21648== by 0x4709AD0D: mpeg2_parse (decode.c:189) ==21648== by 0x47097124: gst_mpeg2dec_chain (gstmpeg2dec.c:467) ==21648== by 0x40240B8B: gst_pad_push (in /home/joshua/gst/gstreamer/gst/.libs/libgstreamer-0.5.so.2.0.0) ==21648== by 0x46FF5539: gst_mpeg_demux_parse_packet (gstmpegdemux.c:663) ==21648== by 0x46FF2DFF: gst_mpeg_parse_loop (gstmpegparse.c:430) ==21648== by 0x41FF7901: loop_group_schedule_function (gstoptimalscheduler.c:759) ==21648== Address 0x470AA068 is not stack'd, malloc'd or free'd
i would be equally happy if the ffmpeg plugin was enhanced to support frame accurate seeking. Then i would re-encode all my mpeg films into MSMPEG4v3, which is one of the most compact formats too.
Adding the PATCH keyword and upgrading the priority level to High because of the attached fix.
I'm fetching this one. Let's see, from the patch, I'm guessing that the real problem is the fact that the seeking in mpegparse assumes CBR (quite obviously, since it uses muxrate for this). I've got several VBR movies here, and the SCR (stream) & PTS (packet/content) values are identical, which means that they're correct (take that from me). Also, if I loop-seek to assure that the *PTS* (rather than the adjusted timestamp) is equal to the time that I need, I get the correct output. I can actually seek accurate up to a second or closer in highly-variable-bitrate videos of 24 hours. The whole timestamp-adjust-stuff (mpegparse->adjust) is broken, since it adapts the PTS to match the muxrate (and thereby moves timestamps back to how they would be if the stream was read as CBR) while actually, the PTS values (or SCR) should be used for timestamps without being adapted (that is correct). Without the adjust adaptations, it works fine. Then, however, seeking inside the mpegstream elements needs to be adapted to use this, too, else discontinuity events will be inprecise. I'm working on a full-blown patch. Joshua (or Wim), can you confirm all this?
Created attachment 23328 [details] [review] fuzzy patch, not cleaned up, integrated exact seeking
Created attachment 26547 [details] [review] Updated precise seeking patch, fully disable timestamp adjustments This is a new updated version after the dvd separation, and it fully rmeoves timestamp adjustments.
so, was it applied ronald ?
No. 1) it doesn't apply cleanly, I suspect 2) discontinuities need to be thought out better than now.
Ronald, is this the same bug I'm seeing with choppy playback on: http://mirrors.creativecommons.org/movingimages/Building_on_the_Past.mpg or is that something different? [In a nutshell, totem seems confused about the length of the mpg, never its place in the mpg- one moment it reports the mpg is two minutes long, which is correct, next moment that it is nine moments long, and moves the slider appropriately.] [I'd like to put that video on a liveCD to commemorate Totem getting into the distro, but... that doesn't appear to be possible until this is fixed :/
The file posted by Luis seems to work fine with current cvs. I can't test the first file because the url no longer works.
Ronald, do you know if this bug is still valid ?
My patch was never applied, so I guess so, yes.
file seems to work fine with HEAD cvs. closing.