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 719553 - rtpasfpay: crash and segment format warnings with asfmux ! rtpasfpay
rtpasfpay: crash and segment format warnings with asfmux ! rtpasfpay
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.2.1
Other Linux
: Normal critical
: 1.5.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-29 13:01 UTC by tomboshoven
Modified: 2015-08-16 13:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description tomboshoven 2013-11-29 13:01:58 UTC
When I try a simple pipeline for adding an rtp payload to an asf stream, I get (reproducible) segmentation faults, in both GStreamer 1.0.10 and 1.2.1.
A basic pipeline showing this behavior is the following:

audiotestsrc ! avenc_wmav2 ! asfmux ! rtpasfpay ! fakesink

If I remove the rtpasfpay element, the pipeline works as expected.
Comment 1 Tim-Philipp Müller 2013-11-29 13:30:54 UTC
Still some warnings about event ordering left, but at least it doesn't crash any longer:

 commit a27b79cbe46e6a738306be50990ea8da0ab5212e
 Author: Tim-Philipp Müller <tim@centricular.com>
 Date:   Fri Nov 29 13:23:40 2013 +0000

    rtpasfpay: init rtp buffer fixing rtp packet creation
    
    https://bugzilla.gnome.org/show_bug.cgi?id=719553

 commit bc7989071fbee7959a21860192aacf5dcc6ce31b
 Author: Tim-Philipp Müller <tim@centricular.com>
 Date:   Fri Nov 29 13:22:56 2013 +0000

    asfmux: don't use buffer after giving away ownership
    
    https://bugzilla.gnome.org/show_bug.cgi?id=719553
Comment 2 Olivier Crête 2013-12-05 21:53:17 UTC
This added patch will push the segment, but the segment is in bytes and the RTP excepts a segment in TIME. I'm not sure why asfmux sends a segment in bytes in the first place?

commit 0a970f1cd11c3fd3d070bd52bbde3216aa697335
Author: Olivier Crête <olivier.crete@collabora.com>
Date:   Thu Dec 5 16:50:27 2013 -0500

    rtpasfpay: Use GstRTPBasePayload method to push buffer
    
    This way the event is also pushed.
Comment 3 Tim-Philipp Müller 2013-12-05 22:56:15 UTC
I don't think it ever makes sense for an rtp*pay to push a segment in BYTES. Does it?

Why did you push the paatch when you're not sure if it makes sense? ;)
Comment 4 Olivier Crête 2013-12-05 23:15:27 UTC
The patch I pushed is to the payloader and makes sense.. The question is, does it ever makes sense for the muxer to push a segment in bytes instead of in time?
Comment 5 Tim-Philipp Müller 2013-12-05 23:29:26 UTC
I think it does, if it needs to seek back later to fix up the header for example (which asfmux *should* do if it can and it's not streaming).

We did add support for doing a SEEKING query downstream to determine if sinks are seekable (filesink on a local file) or streaming (udpsink) for example. This could probably be utilised here if the payloader responds to it or forwards it properly.
Comment 6 Tim-Philipp Müller 2015-08-08 15:28:23 UTC
commit 424426f48646d40ee4930582bc986ade99bfd645
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Sat Aug 8 15:45:59 2015 +0100

    asfmux: output TIME segment if we output a stream and won't seek back later
    
    Check if downstream is seekable via a SEEKING query and output a
    BYTE segment if we want to seek back to fix up the headers later,
    but if we're streaming send a TIME segment instead (which goes
    down better with e.g. asfmux ! rtpasfpay).
    
    https://bugzilla.gnome.org/show_bug.cgi?id=719553