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 625825 - cannot link rtpmp4adepay ! aacparse
cannot link rtpmp4adepay ! aacparse
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 0.10.27
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 637359 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-08-02 12:56 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2011-01-04 10:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
don't require framed=false to be able to link aacparse (602 bytes, patch)
2010-08-02 12:56 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
rejected Details | Review
grab the sampling rate and put into caps (1.63 KB, patch)
2010-08-12 09:36 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2010-08-02 12:56:02 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.
Comment 1 Tim-Philipp Müller 2010-08-04 08:40:57 UTC
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.)
Comment 2 Tim-Philipp Müller 2010-08-04 08:59:52 UTC
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.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2010-08-12 09:36:39 UTC
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 4 Stefan Sauer (gstreamer, gtkdoc dev) 2010-09-08 07:28:19 UTC
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.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2010-10-29 17:57:05 UTC
The problem is not fully solved. aacparse seems to ensure timestamps on buffers, which rtpmp4adepay also not handles yet :/
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2010-10-29 18:00:33 UTC
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 :/
Comment 7 Wim Taymans 2010-12-30 09:33:54 UTC
mp4adepay does not timestamp all outgoing buffers when there are multiple frames per RTP packet.
Comment 8 Wim Taymans 2010-12-31 13:00:13 UTC
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
Comment 9 Mark Nauwelaerts 2011-01-04 10:37:00 UTC
*** Bug 637359 has been marked as a duplicate of this bug. ***