GNOME Bugzilla – Bug 339233
GStreamer performance issues with DVD playback
Last modified: 2011-06-25 19:14:15 UTC
The performance of GStreamer-based applications seem to lag behind other (potentially less flexible) media frameworks. I am hoping this bug may be used to discuss these perceived performance issues. In 2003, I was using the Xine application and libraries to play DVD's. The system in question was a G3-based iBook. I was able to watch entire movies with no lag. Today, I have replaced my old G3 with a G4-based iBook. Playing DVD's using gst-launch does not work well. The video immediately starts to lag behind the audio. I am using the following command to play DVD's: gst-launch dvdreadsrc title=1 ! decodebin name=dvd dvd. ! queue ! ffmpegcolorspace ! xvimagesink dvd. ! audioconvert ! queue ! alsasink The command top shows that gst-launch is maxing out the system's CPU and appears to be dropping frames.
Do you have the same issue with a pipeline like: gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! ffmpegcolorspace ! xvimagseink dvd. ! a52dec ! queue ! audioconvert ! audioresample ! alsasink ? I suspect in the case where decodebin is used a lot of CPU cycles are wasted decoding audio/subtitle streams that aren't being listened/watched to.
I can't get the audio portion of this pipeline to play. This works: gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! ffmpegcolorspace ! xvimagseink But adding this: gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! ffmpegcolorspace ! xvimagseink dvd. ! a52dec ! queue ! audioconvert ! audioresample ! alsasink causes a black window to be displayed (no video or audio.) Top shows that gst-launch is not taxing the CPU while this black window is displayed.
In order to avoid changing the subject, I submitted bug #339356, DVD pipeline does not work on PowerPC. This bug documents several steps I took to help isolate the problem mentioned in comment #2. My intent is starting a new bug is to allow this one to focus on the original issue: performance.
I was able to get the following pipeline to work: gst-launch dvdreadsrc title=2 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! xvimagesink dvd. ! dvdlpcmdec ! queue ! alsasink However, the audio drops out occasionally. As before, this seems to be a performance issue.
Using gstreamer-ffmpeg to decode the video stream seems to behave a little differently: gst-launch dvdreadsrc title=2 ! dvddemux name=dvd dvd. ! ffdec_mpeg2video ! queue ! ffmpegcolorspace ! xvimagesink dvd. ! dvdlpcmdec ! audioconvert ! audioresample ! queue ! alsasink The audio now rarely drops out. However, there does seem to be a loss of synchronization between the audio and video.
Michael, is this still an issue for you or can this be closed?
I am still having the performance issues. When I use ffdec_mpeg2video, the audio and video remain synchronized, but the video only displays about three frames per second. Using mpeg2dec performs even worse. The strange thing is that top only shows the CPU being hit at only 52% by ffdec_mpeg2video. mpeg2dec hits about 75-90%. I am now using: gstreamer-plugins-ugly-0.10.5 gstreamer-ffmpeg-0.10.2 gstreamer-tools-0.10.13 gstreamer-devel-0.10.13 gstreamer-plugins-base-0.10.12 gstreamer-0.10.13 gstreamer-plugins-good-0.10.5 gstreamer-python-0.10.7 gstreamer-plugins-good-devel-0.10.5 gstreamer-plugins-base-devel-0.10.12 gstreamer-plugins-ugly-devel-0.10.5
Strange, the performance of mpeg2dec is suddenly much better. In fact it is better than ffdec_mpeg2video, which has never been the case before. This following command line plays pretty well: gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! ffmpegcolorspace ! xvimagesink dvd. ! a52dec ! audioconvert ! audioresample ! queue ! alsasink Occasionally, the audio drops out. However, it eventually picks up where it left off (no lag is introduced, just drops). Also, the video does stall, but rarely. This happens less often than the audio drop. Top shows that gst-launch + X is taking up around 100% of the CPU. I am now using (Fedora Rawhide as of 05 Oct 07): gstreamer-plugins-good-devel-0.10.6-5.fc8 gstreamer-plugins-ugly-devel-0.10.5-2.lvn7 gstreamer-0.10.14-4.fc8 gstreamer-plugins-base-0.10.14-5.fc8 gstreamer-devel-0.10.14-4.fc8 gstreamer-plugins-good-0.10.6-5.fc8 gstreamer-python-0.10.8-2.fc8 gstreamer-tools-0.10.14-4.fc8 gstreamer-plugins-base-devel-0.10.14-5.fc8 gstreamer-plugins-ugly-0.10.5-2.lvn7 gstreamer-ffmpeg-0.10.2-2.lvn7 mpeg2dec-0.4.1-2.lvn6 xorg-x11-server-Xorg-1.3.0.0-28.fc8
I just run dvd playback under oprofile and got 25% cpu from libgstflumpeg2vdec. Removing that from my plugins improved the playback. It also fixed an issue with some intro animations that where shaky (like play 10 frames, go 2 frames back, play 10 frames, ...) After that is liboil, pulseaudio and ffmpegcolorspace that where using most cpu now.
(In reply to comment #3) > In order to avoid changing the subject, I submitted bug #339356, DVD pipeline > does not work on PowerPC. This bug documents several steps I took to help > isolate the problem mentioned in comment #2. My intent is starting a new bug > is to allow this one to focus on the original issue: performance.
*ping* Is this bug still valid?
Its still quite slow. I am not sure what causing it right now (this is using xv, no ffmpegcolorspace and no deinterlace) 732248 27.9865 no-vmlinux no-vmlinux /no-vmlinux 448203 17.1303 libspeexdsp.so.1.5.0 libspeexdsp.so.1.5.0 /usr/lib/libspeexdsp.so.1.5.0 213885 8.1747 liboil-0.3.so.0.3.0 liboil-0.3.so.0.3.0 /usr/lib/liboil-0.3.so.0.3.0 144390 5.5186 libpulsecore.so.9.0.0 libpulsecore.so.9.0.0 /usr/lib/libpulsecore.so.9.0.0 125289 4.7885 libgstffmpegcolorspace.so libgstffmpegcolorspace.so yuv420p_to_rgb32 124666 4.7647 nvidia_drv.so nvidia_drv.so /usr/lib/xorg/modules/updates/drivers/nvidia_drv.so 114222 4.3656 libc-2.9.so libc-2.9.so /lib/libc-2.9.so 96150 3.6748 libpixman-1.so.0.12.0 libpixman-1.so.0.12.0 /usr/lib/libpixman-1.so.0.12.0 51145 1.9548 libGLcore.so.173.14.18 libGLcore.so.173.14.18 /usr/X11R6/lib/libGLcore.so.173.14.18 35081 1.3408 libmpeg2.so.0.0.0 libmpeg2.so.0.0.0 mpeg2_idct_add_mmxext 34398 1.3147 libpulse.so.0.7.1 libpulse.so.0.7.1 /usr/lib/libpulse.so.0.7.1 25331 0.9681 libmpeg2.so.0.0.0 libmpeg2.so.0.0.0 get_non_intra_block 17393 0.6648 libm-2.9.so libm-2.9.so /lib/libm-2.9.so
gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! ffmpegcolorspace ! xvimagesink produces smooth video with occasional choppiness. gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! ffmpegcolorspace ! xvimagesink dvd. ! a52dec ! audioconvert ! audioresample ! queue ! alsasink produces choppy audio and video. gstreamer-tools-0.10.22-3.fc11.ppc gstreamer-0.10.23-2.fc11.ppc gstreamer-tools-0.10.23-2.fc11.ppc gstreamer-plugins-base-devel-0.10.23-3.fc11.ppc gstreamer-plugins-base-0.10.22-2.fc11.ppc gstreamer-0.10.22-3.fc11.ppc gstreamer-plugins-flumpegdemux-0.10.15-6.fc11.ppc totem-gstreamer-2.26.2-1.fc11.ppc gstreamer-plugins-base-0.10.23-3.fc11.ppc gstreamer-plugins-good-0.10.15-3.fc11.ppc gstreamer-ffmpeg-0.10.7-2.fc11.1.ppc gstreamer-python-0.10.15-1.fc11.ppc gstreamer-plugins-ugly-0.10.12-1.fc11.ppc gstreamer-devel-0.10.23-2.fc11.ppc xorg-x11-server-Xorg-1.6.1.901-1.fc11.ppc libmpeg2-0.5.1-7.fc11.1.ppc
I don't really expect it to make any difference if it's an optimisation/performance issue with the video decoding, but have you tried ResinDVD, from gst-plugins-bad?
Created attachment 171352 [details] playback palyback dvd
Is this still an issue. For me DVD playback just works fine these days.
is anybody able to reproduce the problem in later versions or shall we close the bug ?
This is a performance issue. I have observed that GStreamer often does not perform as well as other (possibly less flexible, e.g., Xine) frameworks. So, the overt symptoms may go away with faster hardware. However, the question is really about how CPU- and/or memory-intensive GStreamer is and the effect on performance. For example, how does the profiling of GStreamer compare to a similar workflow on Xine?
The question is really how we'd like to go further here. Someone attaching an oprofile log here (or several for several media-frameworks) would be a good start. Otherwise I don't believe that anything is going to happen.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!