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 760242 - rtmpsink: should get streamheaders from caps instead of first buffer.
rtmpsink: should get streamheaders from caps instead of first buffer.
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2016-01-06 21:39 UTC by Julien MOUTTE
Modified: 2016-02-10 00:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Implement a setcaps function where we get the headers, and use them. (5.44 KB, patch)
2016-01-06 21:39 UTC, Julien MOUTTE
committed Details | Review

Description Julien MOUTTE 2016-01-06 21:39:22 UTC
Created attachment 318388 [details] [review]
Implement a setcaps function where we get the headers, and use them.

This would allow for dynamic adding of rtmpsink to a running pipeline.
Comment 1 Nicolas Dufresne (ndufresne) 2016-01-06 22:13:00 UTC
Review of attachment 318388 [details] [review]:

Looks good to me. Is it possible someone would have it's own muxer that does not set this into caps ? Maybe I'm mistaken, but this does not seems backward compatible if streamheader is missing, shall be make sure it still workaround it by assuming first buffer is the header ?
Comment 2 Julien MOUTTE 2016-01-07 09:47:41 UTC
Well if the streamheader is not set in the caps there are a lot more plugins that will break like multifdsink right ?

The whole concept of the streamheaders is so that you can start a new connection while the element has been running for a while and have all the necessary pieces to start decoding.

My use case here is that I have a FLV muxer running and connected with a rtmpsink. At some point I need to remove/add the sink as something has changed. The current implementation fails as it is not sending the headers at all (just concatenating the 2 first buffers).

The only way to maintain the current behaviour while implementing streamheaders would be to look at the buffers timestamps / offsets to figure if the first buffer is actually the first buffer produced by the upstream muxer or not but that's hackish :)
Comment 3 Tim-Philipp Müller 2016-01-07 09:59:59 UTC
Nicolas, are you aware of any third party muxer that does not produce streamheaders in the caps, or was that just a general backwards compat consideration?
Comment 4 Nicolas Dufresne (ndufresne) 2016-01-07 14:18:57 UTC
I'm raising the concern that this is not backward compatible (and could be made so will a little more effort). Though, I'm not aware of third party FLV muxer (maybe Pexip ?). The streamheader purpose is clear to me, but it wasn't fully implemented until recently if I remember well. If nobody cares about third parties, just merge it, but at least be aware.
Comment 5 Nicolas Dufresne (ndufresne) 2016-02-09 22:26:05 UTC
So, what do we do here, go ahead with that ?
Comment 6 Tim-Philipp Müller 2016-02-09 22:41:03 UTC
I'm fine with it. I think the benefits of the change outweigh the as-far-as-we-know-mostly-hypothetical risk of breakage with third party muxers, especially seeing that this is in -bad; and if this ever materialises it can be fixed easily.

However, if you think we should block merging this on a fallback code path being implemented, that reasonable too :)
Comment 7 Nicolas Dufresne (ndufresne) 2016-02-10 00:40:26 UTC
Let's solve this problem then :-D
Comment 8 Nicolas Dufresne (ndufresne) 2016-02-10 00:41:47 UTC
Since git bz didn't do that this time:

commit 2b457a46a06c9ada62942aa1b1773fc59530523a
Author: Julien MOUTTE <>
Date:   Wed Jan 6 21:39:00 2016 +0000

    rtpmsink: Implement setcaps that uses streamheader