GNOME Bugzilla – Bug 654383
No playback of DVDs in Totem Debian / Squeeze
Last modified: 2012-10-20 07:05:20 UTC
Created attachment 191688 [details] Totem-GStreamer log of DVD playback Cannot play back DVDs in Totem using backend GStreamer 0.10.x Video is out of sync, many video frames are dropped, audio is not audible or very bad. This problem, on my machine, first occurred in Lenny distribution of Debian Linux, is present in Squeeze, current most up to date version of Debian. This problem does not appear to be with Totem using Xine backend, but xine libs were dropped in Squeeze distribution. GStreamer is the only backend available for me now. Films dowloaded from the internet, .xvid.wav type of formats, are played back alright. Also playing back of music mpeg files or radio over internet is alright though. The problem really appears with the playback of DVDs. Gstreamer Log attached. Any hints would be greatly appreciated. Should you need any system info of my s/w or h/w setup, please let me know. Many thanks in advance. Tomas Kral
Wild guess, but could you turn off deinterlacing in totem and try again? (I'm thinking it may be a dup of #653828.)
(In reply to comment #1) > Wild guess, but could you turn off deinterlacing in totem and try again? (I'm > thinking it may be a dup of #653828.) I tried pressing <i> to turn off deinteralacing, unfortunatelly with no perceiveable effect, in the log it says time stamping problem, not sure what it is what chances are there for me to find a patch or workaround? many thanks so far
I attach a profiler output, not sure I can use profiler, since I have used it for the first time # DVD playback - droppping frames no sound # actually setting deinterlacing on/off has no effect, at least not a visible one # used gconf /apps/totem/deinterlace on/off tcat@lynx:~$ opreport --global-percent | head -22 Overflow stats not available CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt TIMER:0| samples| %| ------------------ 20752 40.1773 libmpeg2.so.0.0.0 9527 18.4449 no-vmlinux 2805 5.4307 libpixman-1.so.0.16.4 2365 4.5788 libglib-2.0.so.0.2800.6 1892 3.6630 libgobject-2.0.so.0.2800.6 1849 3.5798 libc-2.11.2.so 1468 2.8422 Xorg TIMER:0| samples| %| ------------------ 1452 2.8112 Xorg 16 0.0310 [vdso] (tgid:2090 range:0xb7746000-0xb7747000) 1391 2.6931 libgstreamer-0.10.so.0.26.0 1289 2.4956 libpthread-2.11.2.so 1178 2.2807 libxaa.so 797 1.5430 libcairo.so.2.10800.10 702 1.3591 liba52-0.7.4.so # now with a playback of .xvid.wav file # very smooth, crystal clear sound tcat@lynx:~$ opreport --global-percent | head -22 Overflow stats not available CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt TIMER:0| samples| %| ------------------ 58351 40.8129 libmpeg2.so.0.0.0 27787 19.4353 no-vmlinux 7145 4.9975 libpixman-1.so.0.16.4 6034 4.2204 libglib-2.0.so.0.2800.6 5410 3.7840 libc-2.11.2.so 4871 3.4070 libgobject-2.0.so.0.2800.6 3835 2.6823 libgstreamer-0.10.so.0.26.0 3692 2.5823 Xorg TIMER:0| samples| %| ------------------ 3642 2.5474 Xorg 50 0.0350 [vdso] (tgid:2090 range:0xb7746000-0xb7747000) 3501 2.4487 libpthread-2.11.2.so 3024 2.1151 libxaa.so 1980 1.3849 liba52-0.7.4.so 1868 1.3065 libcairo.so.2.10800.10
Created attachment 191867 [details] Custom Totem-GStreamer log of DVD playback
I have just built my custom totem from sources, compiled against stable Debian/Squeeze libgstreamer.*-dev libs I left out some pluggins Same result, video is out of sync, many video frames are dropped, audio is not audible or very bad. Log attached, profiler report below Any hints appreaciated Many thanks in advance tcat@lynx:/usr/src/totem-2.30.2$ opreport --global-percent | head -22 CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt TIMER:0| samples| %| ------------------ 347759 23.0985 no-vmlinux 204239 13.5657 Xorg TIMER:0| samples| %| ------------------ 203663 13.5275 Xorg 376 0.0250 [vdso] (tgid:2090 range:0xb7746000-0xb7747000) 200 0.0133 [vdso] (tgid:2214 range:0xb7734000-0xb7735000) 150989 10.0288 libavcodec.so.52.97.2 150737 10.0121 libmpeg2.so.0.0.0 120303 7.9906 libgstffmpegcolorspace.so 74048 4.9183 libpixman-1.so.0.16.4 69077 4.5882 libc-2.11.2.so 58618 3.8935 libxaa.so 28550 1.8963 libglib-2.0.so.0.2800.6 26851 1.7835 libgstreamer-0.10.so.0.26.0 24105 1.6011 libpthread-2.11.2.so
I'm thinking you might be missing plugins, causing some kind of weird conversions as fallback, from the debug lines below. Maybe a higher GST_DEBUG level might shed some light on this. 0:00:14.658562728 2133 0x92366c0 WARN basetransform gstbasetransform.c:1065:gst_base_transform_acceptcaps_default:<identity0> transform could not transform audio/x-private1-ac3 in anything we support 0:00:14.813502848 2133 0x9145348 WARN basetransform gstbasetransform.c:1065:gst_base_transform_acceptcaps_default:<identity1> transform could not transform video/mpeg, mpegversion=(int)2, systemstream=(boolean)false in anything we support 0:00:15.203044093 2133 0x92366c0 WARN basetransform gstbasetransform.c:1065:gst_base_transform_acceptcaps_default:<aresample> transform could not transform audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)2, rate=(int)48000, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT > in anything we support 0:00:15.312402431 2133 0x9145348 WARN basetransform gstbasetransform.c:1065:gst_base_transform_acceptcaps_default:<vscale> transform could not transform video/x-raw-yuv, format=(fourcc)I420, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)16/15, framerate=(fraction)25/1, interlaced=(boolean)true in anything we support 0:00:16.544204308 2133 0x9285400 WARN basetransform gstbasetransform.c:1065:gst_base_transform_acceptcaps_default:<vscale> transform could not transform video/x-raw-yuv, format=(fourcc)I420, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)16/15, framerate=(fraction)25/1, interlaced=(boolean)true in anything we support 0:00:16.761365768 2133 0x9285400 WARN basetransform gstbasetransform.c:1065:gst_base_transform_acceptcaps_default:<vscale> transform could not transform video/x-raw-yuv, format=(fourcc)I420, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)16/15, framerate=(fraction)25/1, interlaced=(boolean)true in anything we support Though... > CPU: CPU with timer interrupt, speed 0 MHz (estimated) Maybe your computer might just be THAT slow :P
Created attachment 194508 [details] Totem-GStreamer log of DVD playback - dbg LEVEL 3
I have rerun a dbg session as per your suggestion using higher dbg level GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:3 totem 2> totem2.log please see attachment it complains about time stamping, not sure what it is it happens with all my commercial DVDs > CPU: CPU with timer interrupt, speed 0 MHz (estimated) I know, I cannot probably use otprof properly :-) I am just thinking how I could create just a small ISO image, say first 5 mins sample of a DVD, that I could upload here for you, and you could mount as loop device and test? thank you so far P.S. profiling is set as follows CONFIG_EVENT_PROFILE=y CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_OPROFILE_IBS=y # CONFIG_OPROFILE_EVENT_MULTIPLEX is not set CONFIG_HAVE_OPROFILE=y # CONFIG_SYSPROF_TRACER is not set CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set
It seems I'll need more detailed logs to see what is leading to the failure to set up conversion. It's very odd it happens for both audio and video. Can you make a GST_DEBUG=5 please ? That might be large. Something you can also try, in case these conversion messages are a red herring, is to change the video output from Xv to something else through gstreamer-properties, if you have that installed. Or also the audio output, though that sounds more unlikely to be the issue.
I have rerun a dbg session with dbg level 5 GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:5 totem 2> totem3.log Resulting file, even gzipped, is quite large, it is deposited at http://ifile.it/6o321el/totem3.log.gz I have also tried changing videosink as you suggested best results are obtained with, X11/Shm/Xv Trident Backend Scaler (that's my graphics card) xvimagesink device="0" That has been my setting from the very start No Xv produces much worse results, even more video frames dpropped Just thinking where I could get other video sinks should this be a problem, it has not been with libxine though Many thanks so far Thomas P.S. $ gstreamer-properties # puts out gstreamer-properties-Message: Skipping unavailable plugin 'artsdsink' gstreamer-properties-Message: Skipping unavailable plugin 'esdsink' gstreamer-properties-Message: Skipping unavailable plugin 'pulsesink' gstreamer-properties-Message: Skipping unavailable plugin 'glimagesink' gstreamer-properties-Message: Skipping unavailable plugin 'sdlvideosink' gstreamer-properties-Message: Skipping unavailable plugin 'v4lmjpegsrc' gstreamer-properties-Message: Skipping unavailable plugin 'qcamsrc' gstreamer-properties-Message: Skipping unavailable plugin 'esdmon' gstreamer-properties-Message: Skipping unavailable plugin 'pulsesrc' $
After reading logs for a while, I think those conversion messages are a red herring. What I'm now suspecting is the audio clock. Near the start, it seems to stay at 0 for quite a while, and this causes the video sink to wait for a long time before rendering a frame, timing out and trying to wait again. As a test, could you move all audio sink plugins (*) out of the way, and run totem again, to see if I'm on the right track here ? It should affect other movies, which you say are fine, so... (*) something like: cd /usr/lib/gstreamer-0.10/ mkdir /tmp/gst-plugins mv libgstalsa* /tmp/gst-plugins Also anything you might have such as libgstesd, libgstpulse, libgstsdl, etc. They can be moved back later the same way. Try running without logs to compare with/without audio plugins, to avoid heavy logging interfering. Thanks
moved alsa libs away rerun w/o logging first afraid not noticable improvement then w/ logging GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:5 totem 2> totem4.log log file deposited at http://ifile.it/duo0574/totem4.log.gz sorry becoming feeling guilty about my hardware many thanks so far Tom
corrected link http://ifile.it/5vp2uks/totem4.log.gz if the earlier did not work
Let's try another approach. Can you run these sets of commands, and report which of them have slow playback, replacing DEVICE with the device your DVD drive is (eg, /dev/dvd), TITLE with the title number of something testable (eg, 2), and DECODER by eihter mpeg2dec or ffdec_mpeg2video, whichever you have. Basic play-from-DVD: gst-launch dvdreadsrc device=$DEVICE title=$TITLE ! dvddemux ! $DECODER ! ffmpegcolorspace ! xvimagesink Play from muxed: gst-launch dvdreadsrc device=/dev/dvd title=2 num-buffers=1024 ! filesink location=/tmp/tmp.mpeg gst-launch filesrc location=/tmp/tmp.mpeg ! dvddemux ! $DECODER ! ffmpegcolorspace ! xvimagesink Play from demuxed: gst-launch filesrc location=/tmp/tmp.mpeg ! dvddemux name=d d.current_video ! filesink location=/tmp/tmp2.mpeg gst-launch filesrc location=/tmp/tmp2.mpeg ! mpeg2dec ! ffmpegcolorspace ! xvimagesink
Executed in the order as you suggested Only playing from demuxed was slow, all others smooth All played without sound I attach gst.cmd file I also attach gstlnch.log, put out for each step Many thanks do far Thomas
Created attachment 196031 [details] gst-launch command
Created attachment 196032 [details] gst-launch command log
> Only playing from demuxed was slow, all others smooth Ah, that's very interesting. I notice I used mpeg2dec instead of $DECODER in the third pipeline. If you try this third pipeline again, with ffdec_mpeg2video instead of mpeg2dec, does it now play slow too ? If so, while not yet a fix, you can probably workaround your problem by removing libgstffmpeg.* from /usr/lib/gstreamer0.10 (or ~/lib/gstreamer0.10).
> Ah, that's very interesting. I notice I used mpeg2dec instead of $DECODER in > the third pipeline. If you try this third pipeline again, with ffdec_mpeg2video > instead of mpeg2dec, does it now play slow too ? Tried with ffdec_mpeg2video, but fails to play at all $ gst-launch-0.10 filesrc location=/tmp/tmp2.mpeg ! ffdec_mpeg2video ! ffmpegcolorspace ! xvimagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/ffdec_mpeg2video:ffdec_mpeg2video0: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstffmpegdec.c(2684): gst_ffmpegdec_chain (): /GstPipeline:pipeline0/ffdec_mpeg2video:ffdec_mpeg2video0: ffdec_mpeg2video: input format was not set before data start ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... with mpeg2dec it plays although slow
If you replace ffdec_mpeg2video with of mpeg2dec in the first pipeline: gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! mpeg2dec ! ffmpegcolorspace ! xvimagesink Does this make the pipeline slow ? If not, what about this: gst-launch-0.10 rsndvdbin ! ffmpegcolorspace ! xvimagesink If you play this pipeline twice, with libgstffmpeg.so out of the way for the first run, and libmpeg2dec.so out of the way in the second ? Remove ~/.gstreamer-0.10/.registry*bin after moving plugins around, to be sure.
gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! mpeg2dec ! ffmpegcolorspace ! xvimagesink IS SLOW gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! ffdec_mpeg2video ! ffmpegcolorspace ! xvimagesink IS FAST - if I could add a sound pipe, that would be it -:) had to create s symlink /dev/scd0 -> /dev/dvd gst-launch-0.10 rsndvdbin ! ffmpegcolorspace ! xvimagesink libgstffmpeg.so moved away to /tmp, registry cleaned (rm -r .gst*/reg*) IS SLOW libgstmpeg2dec.so moved away to /tmp, registry cleaned (rm -r .gst*/reg*) IS SLOW
Interesting. It doesn't seem to be just mpeg2dec being slower. Can you try this variant on the slow pipeline, and see if it makes it faster: gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! mpegvideoparse ! mpeg2dec ! ffmpegcolorspace ! xvimagesink and this variant on on the fast one to see if it makes it slower: gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! mpegvideoparse ! ffdec_mpeg2video ! ffmpegcolorspace ! xvimagesink As for adding an audio path, something like this (remove the newlines, I'm adding them for clarity only): gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux name=d d. ! queue ! a52dec ! audioconvert ! autoaudiosink d. ! queue ! 'video/x-dvd-subpicture' ! dvdspu name=s d. ! queue ! ffdec_mpeg2video ! s. s. ! queue ! ffmpegcolorspace ! navseek ! xvimagesink This will allow you to seek/pause as well (pause only with a recent -good).
gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! mpegvideoparse ! mpeg2dec ! ffmpegcolorspace ! xvimagesink NOT FASTER gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! mpegvideoparse ! ffdec_mpeg2video ! ffmpegcolorspace ! xvimagesink NOT SLOWER $ gst-launch-0.10 \ dvdreadsrc device=/dev/scd0 title=2 ! dvddemux name=d \ d. ! queue ! a52dec ! audioconvert ! autoaudiosink \ d. ! queue ! 'video/x-dvd-subpicture' ! dvdspu name=s \ d. ! queue ! ffdec_mpeg2video ! s. \ s. ! queue ! ffmpegcolorspace ! navseek ! xvimagesink WARNING: erroneous pipeline: could not link queue0 to a52dec0 # does not playback
Try replacing 'd. ! queue ! a52dec' with 'd.current_audio ! queue ! a52dec'
And could you please upload two gst logs of: - the slow one: gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! mpeg2dec ! ffmpegcolorspace ! xvimagesink - the fast one: gst-launch-0.10 dvdreadsrc device=/dev/scd0 title=2 ! dvddemux ! ffdec_mpeg2video ! ffmpegcolorspace ! xvimagesink with GST_DEBUG=5, so I can compare both ? It doesn't seem to be a simple "one decoder is slow, another is fast" from the results of other tests. Thanks for your patience.
uploded logs here http://ifile.it/5fhxlyc/gst-fast.log.gz http://ifile.it/ems4391/gst-slow.log.gz $ gst-launch-0.10 \ dvdreadsrc device=/dev/scd0 title=2 ! dvddemux name=d \ d.current_audio ! queue ! a52dec ! audioconvert ! autoaudiosink \ d. ! queue ! 'video/x-dvd-subpicture' ! dvdspu name=s \ d. ! queue ! ffdec_mpeg2video ! s. \ s. ! queue ! ffmpegcolorspace ! navseek ! xvimagesink works nicely, but how can I stop english subtitles showing? BTW interesting, "mouse move events" can put even fast pipeline to a halt for good of a couple of seconds thanks so much tom
Try gst-launch-0.10 \ dvdreadsrc device=/dev/scd0 title=2 ! dvddemux name=d \ d.current_audio ! queue ! a52dec ! audioconvert ! autoaudiosink \ d. ! queue ! ffdec_mpeg2video ! ffmpegcolorspace ! navseek ! xvimagesink
I got this warning, did not play WARNING: erroneous pipeline: could not link queue1 to ffdec_mpeg2video0
files deposited again, the service retain uploads only for a week or so http://ifile.it/sjq1pe7/gst-fast.log.gz http://ifile.it/ob5hetg/gst-slow.log.gz many thanks so far
Ah, thanks for the reminder. I got the files now. As for the pipeline, try d.current_video ! queue ! ffdec_mpeg2video ... Not sure why it can't select the right pad without help...
The fast one reports: 0:00:42.677859340 4065 0x9cc0050 DEBUG basesink gstbasesink.c:4914:gst_base_sink_change_state:<xvimagesink0> rendered: 13, dropped: 21 The slow one reports: 0:00:49.962755674 4083 0x9152050 DEBUG basesink gstbasesink.c:4914:gst_base_sink_change_state:<xvimagesink0> rendered: 8, dropped: 26 So not much difference, both seem to have dropped the vast majority of the frames along the way, mostly even before the video sink. Even the fast one must have been less than a frame every couple seconds... It's just baffling.
$ gst-launch-0.10 \ dvdreadsrc device=/dev/scd0 title=1 ! dvddemux name=d \ d.current_audio ! queue ! a52dec ! audioconvert ! autoaudiosink \ d.current_video ! queue ! ffdec_mpeg2video ! ffmpegcolorspace ! navseek ! xvimagesink Is a workaround that plays nicely, albeit with some frames dropped thank you for that BTW my current processor is DURON 750MHz, bus speed is 100MHz, DVD is DMA 33MHz I have got DURON 1200MHz in the sale, so i may try to swap them and see if I got better render / drop ratio perhaps it really is a slow H/W issue Anyway, now I am thinking, how I could recompile totem, making it use the above workaround :-)
Actually my DVD is U-DMA 66, I got 80-pin conductor cable for it $ dmesg | grep -i dvd [ 2.652445] ata2.00: ATAPI: Optiarc DVD RW AD-5200A, 1.09, max UDMA/66 [ 2.672904] scsi 1:0:0:0: CD-ROM Optiarc DVD RW AD-5200A 1.09 PQ: 0 ANSI: 5
adding a comment from Bastien, totem maintainer / developer On Tue, 2011-11-01 at 20:08 +0100, Tomas Kral wrote: > Dear Bastien, > > I have been experiencing slow DVD playback using totem with gstreamer > back end. > > I have filed a bug at > > https://bugzilla.gnome.org/show_bug.cgi?id=654383 > GStreamer | gstreamer (core) | 0.10.x > > I have a workaround that plays smoothly. > My question is, how I could compile it to totem? > > I have sources and gstreamer development libs installed. Totem doesn't have any custom pipelines, it just uses playbin2. If playbin2 is broken, then it needs to be fixed.
So it seems to me that the main issue is/was that mpeg2dec is a lot slower than ffdec_mpeg2video and your machine is so slow that it makes or breaks things for you in this case. Not sure what to do about that to be honest. Possibly it might help if you move out of the way or chmod -rx the libgstmpeg2dec.so plugin file (hoping that ffdec_mpeg2video will be chosen instead).
Dear Tim, I have upgraded my CPU from Duron 750 to Athlon 1000 Mhz, also increased RAM from 256 to 512 MB, and it helps, video is now watchable, I may still be loosing some frames, but anyway it plays back now. Many thanks for previous continued support. Tom
Alright, thanks for the update. I hope you don't mind if we close this then, I believe there is another bug for making the other decoder the default (we did at some point, but there were problems..)
Tim, Yes please do close it, it has been filed for a while. and again, many thanks for all the support. Tom