GNOME Bugzilla – Bug 625825
cannot link rtpmp4adepay ! aacparse
Last modified: 2011-01-04 10:37:00 UTC
Created attachment 166971 [details] [review] don't require framed=false to be able to link aacparse In a pipeline like gst-launch-0.10 rtspsrc location=rtsp://stream.yle.mobi/yle/areena/MEDIA_E0329814_p3.mp4 protocols="tcp" name=s mp4mux name=m ! filesink location=2010.07.14.Mennään\ sirkukseen.mp4 s. ! queue ! rtpmp4adepay ! aacparse ! progressreport ! m. s. ! queue ! rtph264depay ! h264parse output-format=sample ! m. I need to put a aacparse after rtpmp4adepay to get the sampling-rate into the caps. The sampling-rate is needed by qtmux (all flavours). The attached patch works for me, but I am now sure where it should be fixed properly.
I don't think we can do this currently, because decodebin/decodebin2 don't handle this right yet and may end up plugging aacparse elements in an endless loop in some circumstances. It's something that should work some day though, so parsers can just be plugged unconditionally for remuxing etc. (I'm sure there's another bug for that somewhere). As a work-around you could put a capssetter element between the depayloader and the parser and force caps with framed=false. The best fix for now would be to make rtpm4adepay parse the sample rate (and number of channels?) and put that into the caps itself. (If that info isn't readily available in the depayloader, the codec utility functions from bug #617314 which will hopefully land really soon now might help with the parsing.)
Forgot to add: aacparse etc. don't have a rank at the moment, so the patch wouldn't really a problem now, but the intention is to give these elements ranks after the next release.
Created attachment 167712 [details] [review] grab the sampling rate and put into caps Get the sampling rate from the AudioSpecificConfig. Has been ripped out of aacparse.
Comment on attachment 167712 [details] [review] grab the sampling rate and put into caps commit 988f228da74f1aca62c69d50c5b67765580298b0 Author: Stefan Kost <ensonic@users.sf.net> Date: Thu Aug 12 12:33:06 2010 +0300 rtpmp4adepay: grab the sampling arte and put into caps This is needed to be able to mux the received audio into mp4 (in the case of aac). Fixes #625825.
The problem is not fully solved. aacparse seems to ensure timestamps on buffers, which rtpmp4adepay also not handles yet :/
This is the symptom - retried with aacparse and still run into it at some point :/ 0:02:21.582795880 4517 0x82637c0 WARN qtmux gstqtmux.c:1847:gst_qt_mux_add_buffer:<m> error: Received buffer without timestamp/duration. 0:02:21.582982695 4517 0x82637c0 WARN qtmux gstqtmux.c:1847:gst_qt_mux_add_buffer:<m> error: Received buffer without timestamp/duration. Will look into it and see if it is a different bug. This was working before, so I smell a regression :/
mp4adepay does not timestamp all outgoing buffers when there are multiple frames per RTP packet.
commit 5ed3701a2d0c7f22473d6d4ae551b58adb8049b3 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Dec 31 13:57:05 2010 +0100 mp4adepay: improve timestamps on outgoing packets Improve parsing of the samplerate. Parse the framelen so that we can calculate timestamps. When interpollate the incomming timestamp on outgoing buffers when there are multiple subframes. fixes #625825
*** Bug 637359 has been marked as a duplicate of this bug. ***