After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 339356 - gst-launch does not provide feedback for bad pipelines
gst-launch does not provide feedback for bad pipelines
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.3
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 348176 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-04-21 22:02 UTC by W. Michael Petullo
Modified: 2006-07-20 23:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description W. Michael Petullo 2006-04-21 22:02:21 UTC
Please describe the problem:
I have come across a problem while trying to play a DVD using gst-launch.

Steps to reproduce:
1.  gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue !
ffmpegcolorspace ! xvimagesink dvd. ! a52dec ! queue ! audioconvert !
audioresample ! alsasink

This pipeline causes a blank, black window to appear.  Neither audio nor video
is played.  Running top shows that gst-launch is using very few CPU cycles.

2.  gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue !
ffmpegcolorspace ! xvimagesink dvd. ! fakesink

I ran the above pipeline to try and isolate the problem.  The audio stream is
simply going into a fakesink, but the symptoms are the same as pipeline 1.

3.  gst-launch dvdreadsrc title=1 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue !
ffmpegcolorspace ! xvimagesink

This pipeline plays the DVD video fine.  However, audio is not played because
the pipeline does not specify anything for audio.

4.  gst-launch filesrc location=/mnt/cdrom/video_ts/vts_01_0.vob ! dvddemux
name=dvd dvd. ! mpeg2dec ! queue ! ffmpegcolorspace ! xvimagesink dvd. ! a52dec
! queue ! audioconvert ! audioresample ! alsasink

Again trying to isolate the problem.  This pipeline plays both audio and video.
 However, the output is jumbled because of CSS.

5.  gst-launch dvdreadsrc title=1 ! decodebin name=dvd dvd. ! queue !
ffmpegcolorspace ! xvimagesink dvd. ! audioconvert ! queue ! alsasink

This pipeline plays audio and video.  However, the performance is not very good
(see bug #339233, which prompted me to try the other pipelines.)


Actual results:


Expected results:


Does this happen every time?


Other information:
The test system is a PowerPC G3 iBook running Fedore Core 5.
Comment 1 Tim-Philipp Müller 2006-04-21 22:43:27 UTC
This pipeline will only work if there is actually an AC3 sound stream available for this title.

You may want to try 'mad', 'dvdlpcmdec' or 'dtsdec' instead of 'a52dec'.
Comment 2 W. Michael Petullo 2006-04-22 01:05:48 UTC
In pipeline 2 above, I routed the audio directly to fakesink.  The results were the same as when using a52dec.  Doesn't this mean that the problem does NOT lie in a52sink?
Comment 3 W. Michael Petullo 2006-04-23 01:53:04 UTC
This plays, though the audio drops out occasionally:

gst-launch dvdreadsrc title=2 ! dvddemux name=dvd dvd. ! mpeg2dec ! queue ! xvimagesink dvd. ! dvdlpcmdec ! queue ! alsasink

So, my question is now: can GStreamer detect that, for example, a stream does not contain a a52 track when the a52dec plugin is used?  In general, can GStreamer provide more verbose feedback to indicate why a pipeline does not work?  This would help one construct a valid pipeline.

Also, it would be useful if gst-launch + playbin/decodebin printed the plugins  used to automatically create a pipeline.
Comment 4 Tim-Philipp Müller 2006-04-23 09:34:56 UTC
You always need a 'queue' element in each branch/stream after dvddemux (or any demuxer really). If you don't have that, the pipeline might not be able to preroll, ie. it hangs as you described. That's expected behaviour.

Of course GStreamer could theoretically detect things like you're asking, but the benefit would be very small (IMHO) and it wouldn't be 100% correct from a theoretical point of view (as it's not always clear with some type of streams if there aren't more new pads going to be created later).

Generally, gst-launch is just a debug tool for developers who know what they're doing. It does lots of things automagically in the background (like waiting for a pad to be created etc.), but that 'magic' also has the side-effect of stalling the pipeline if you're telling it to wait for something that won't ever happen.

You can see what elements playbin/decodebin use if you pass the -v switch to gst-launch.
Comment 5 Wim Taymans 2006-07-03 14:21:00 UTC
as Tim said, it's a debugging tool, the smart things should go in the apps.
Comment 6 W. Michael Petullo 2006-07-03 23:19:43 UTC
I have been using gst-launch for various purposes for years (mostly format conversion in shell scripts.)  So, I would avoid considering it a "just a debug tool."  I think the command line utility finally brings the power of Unix to audio and video processing.  The "apps" will never do everything that users need (i.e., an application vs. sed/awk/etc. -- both have their use cases), and it would be a shame if the Unix-like philosophy/potential was overlooked.

Anyway, I just wanted to voice my two cents.  I was originally attracted to GStreamer in 2001 or so when I saw gst-launch as a much cooler sox.
Comment 7 Tim-Philipp Müller 2006-07-20 23:05:15 UTC
*** Bug 348176 has been marked as a duplicate of this bug. ***