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 650423 - Ordering-dependent bug with mpegtsdemux, h264parse, ac3parse, and matroskamux
Ordering-dependent bug with mpegtsdemux, h264parse, ac3parse, and matroskamux
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-05-17 18:29 UTC by bens
Modified: 2011-05-17 20:28 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
GST_DEBUG=5 log of the failure. (98.81 KB, application/x-xz)
2011-05-17 18:29 UTC, bens 		Details

Description bens 2011-05-17 18:29:19 UTC 
Created attachment 187981 [details]
GST_DEBUG=5 log of the failure.

When I run the pipeline

./gst-jhbuild run gst-launch-0.10 filesrc location=clip.mts ! mpegtsdemux
name=demux ! ac3parse ! queue ! matroskamux name=mux ! filesink
location=clip.mkv . demux. ! h264parse ! queue ! mux.

it runs fine, although it eventually fails as documented in #650416.  If I instead run

./gst-jhbuild run gst-launch-0.10 filesrc location=clip.mts ! mpegtsdemux name=demux ! h264parse ! queue ! matroskamux name=mux ! filesink location=clip.mkv . demux. ! ac3parse ! queue ! mux.

then the launcher immediately fails with

0:00:00.193190536 10350  0x97d1088 ERROR           GST_PIPELINE ./grammar.y:614:gst_parse_perform_link: could not link ac3parse0 to queue1

These two pipelines are identical except for the order in which the streams are expressed.  In my limited understanding of gstreamer, these two pipelines are different syntactic representations of the exact same semantics, so I was very surprised to see one succeed and one fail.
Comment 1 David Schleef 2011-05-17 20:28:38 UTC 
You probably need to use:

  ... ! ac3parse ! queue ! mux.audio_%d

(i.e., specify the pad template you want to link to.)  The reason for this is that the parser uses pad template caps to determine which REQUEST pad to create, and queue has "ANY" as pad template caps.

I'm marking this as NOTABUG, but if I'm incorrect, please reopen.