GNOME Bugzilla – Bug 656226
[faac] Does not passthrough downstream caps constraints to upstream
Last modified: 2011-09-22 15:51:12 UTC
Created attachment 193495 [details] png of failing pipeline I removed the ffmpeg plugin today as part of testing transmageddon. Transcoding pipelines which works fine with ffenc_aac, seem fail with the FAAC plugin. It is not clear to me from either dotfile dump or gst-debug log why FAAC fail, while ffenc_aac succeed. Attaching both log and png dump. On the command line I get: GStreamer encountered a general stream error. gstoggdemux.c(3481): gst_ogg_demux_loop (): /GstPipeline:TranscodingPipeline/GstURIDecodeBin:uridecoder/GstDecodeBin2:decodebin22/GstOggDemux:oggdemux2: stream stopped, reason not-negotiated While in the debug log I been able to find this, it seems to complain about demuxer, but that doesn't make any sense to me as the same demuxer works fine with ffenc_aac. 0:00:10.323071105 ^[[331m27186^[[00m 0x89817a0 ^[[37mLOG ^[[00m ^[[00;01;35m GST_SCHEDULING gstpad.c:4690:gst_pad_push:<oggdemux2:serial_0f461594>^[[00m called chainfunction &gst_multi_queue_chain with buffer 0xb012a110, returned not-negotiated 0:00:10.323092374 ^[[331m27186^[[00m 0x89817a0 ^[[33;01mWARN ^[[00m ^[[00m oggdemux gstoggdemux.c:983:gst_ogg_pad_stream_out:<oggdemux2>^[[00m could not submit packet for stream 0f461594, error: -4 0:00:10.323111487 ^[[331m27186^[[00m 0x89817a0 ^[[36mDEBUG ^[[00m ^[[00m oggdemux gstoggdemux.c:407:gst_ogg_pad_reset:<oggdemux2:serial_0f461594>^[[00m doing reset 0:00:10.323129857 ^[[331m27186^[[00m 0x89817a0 ^[[37mLOG ^[[00m ^[[00m oggdemux gstoggdemux.c:3283:gst_ogg_demux_loop_forward:<oggdemux2>^[[00m Failed demux_chain 0:00:10.323147772 ^[[331m27186^[[00m 0x89817a0 ^[[37mLOG ^[[00m ^[[00m
Created attachment 193496 [details] GST_DEBUG_LOG
It's just that when a not-negotiated flow error happens, the not-negotiated flow is passed upstream to the element driving the pipeline, in this case oggdemux. That's why the demuxer posts the error message. The error happens somewhere else though. According to the log and the graph there seems to be something wrong with negotiation / fixation somewhere. The problem is that audioconvert turns the stereo into mono, which it then feeds to the faac encoder. But the capsfilter after the encoder wants channels=2, so when faac outputs channels=1 AAC, this generates a not-negotiated.
Why does it convert stereo to mono at all? Might additionally be an audioconvert bug But anyway, to fix this faac has to translate downstream caps to upstream caps in the sinkpad getcaps function, e.g. passthrough the number of channels and sample rates supported by downstream.
If only we had something like base (audio) encoder classes that could help arranging this sort of thing ... (hint hint)
rygel also hits this problem if the it tries to use FAAC. Will soon do what Sebastian suggests.
Tested with updated baseclass based plugin from Mnauw, this bug is fixed now. Closing.