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 752732 - hlsdemux doesn't maintain extra-headers
hlsdemux doesn't maintain extra-headers
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-07-22 15:33 UTC by Stefano
Modified: 2018-11-03 13:38 UTC
See Also:
GNOME target: ---
GNOME version: ---

playlist (647 bytes, audio/x-mpegurl)
2015-07-23 14:31 UTC, Stefano
gstreamer log (8.84 KB, text/x-log)
2015-07-23 14:47 UTC, Stefano
gstreamer log (7.59 KB, text/x-log)
2015-07-23 17:03 UTC, Stefano

Description Stefano 2015-07-22 15:33:35 UTC
hlsdemux doesn't maintain extra-headers params when retrieving segments in m3u8.
Comment 1 Sebastian Dröge (slomo) 2015-07-22 20:28:57 UTC
What exactly do you mean with this? Can you describe it with an example, ideally also with a way to reproduce whatever problem you're seeing?
Comment 2 Tim-Philipp Müller 2015-07-22 21:31:04 UTC
This came up on IRC.

Basically if you set souphttpsrc's "extra-headers" property in playbin's source-setup callback, then the extra headers are used for downloading the initial playlist, but not for any of the other playlists or fragments. It's similar to cookies etc. really.
Comment 3 Stefano 2015-07-23 07:58:53 UTC
Sebastian it is exactly what Tim exposed.
I will update this morning on the context of the experiment where I've experienced this bug.
Comment 4 Stefano 2015-07-23 14:31:49 UTC
Created attachment 307992 [details]

Canon Legria Playlist
Comment 5 Stefano 2015-07-23 14:46:16 UTC
I'm try to stream from Canon Legria wifi camcoder.
It is undocumented but I see that this camcoder has an internal http server.
I can retrieve the playlist that I've attached with souphttpsrc from camera url  but i need to use extra-headers to pass x-session-id identifier that the camera want.
The problem is, as you can see in the attached playlist, that the internal segment are mp4 and needs the same extra-headers to be retrieved.
Streaming the single fragment url works fine with gstreamer.
I've workarounded hlsdemux extra-headers issue using an http proxy that automatically add the custom headers I need to validate the request.
Segments play fine but using m3u8 doesn't work or ocassionally play only the first segment (every segment has a length of 0.48 as you can see from #EXTINF:0.48.

I've attached also the gstreamer log of the run of:
GST_DEBUG=5 gst-launch-1.0 -v souphttpsrc location=""  extra-headers="Bo, HOST=(string)" keep-alive=TRUE  keep-alive=TRUE is-live=TRUE ! hlsdemux !  decodebin ! autovideosink
Comment 6 Stefano 2015-07-23 14:47:05 UTC
Created attachment 307996 [details]
gstreamer log
Comment 7 Stefano 2015-07-23 17:03:09 UTC
Created attachment 308013 [details]
gstreamer log

I've added a more completed gstreamer debug log
Comment 8 Stefano 2015-07-23 19:04:31 UTC
I've also found that the pipeline seems to call the first segment twice, one in prerolling phase and one in play phase (this invalidate the second call on the same segment)


I see gstsouphttpsrc.c:1754:gst_soup_http_src_start:<souphttpsrc1> start("") in prerolling phase

And then in play phase i found gstsouphttpsrc.c:1754:gst_soup_http_src_start:<souphttpsrc1> start("")
Comment 9 Thiago Sousa Santos 2015-07-23 22:36:10 UTC

I guess those 2 bugs are also related to same kind of issue. We're waiting on the issues on these patches to be sorted out to merge them. #751371 needs some design decision regarding how to get cookies from the application (in this case from adaptivedemux/hlsdemux).
Comment 10 Stefano 2015-07-23 22:46:21 UTC
Thiago it is something similar but more related to extra-headers parameter (custom user headers).
I'm also in the special case that for the particular camera implementation I cannot require the same segment twice because the after their first time will be invalidate server side and the pipeline it is interupted. I don't know why the first http segment in m3u8 is http required twice by gstreamer (probably the first one for negotiation)?
Comment 11 Thiago Sousa Santos 2015-07-23 22:47:42 UTC
Yes, IIRC souphttpsrc sends both the request and response headers, adaptivedemux should catch those events and set those values to its internal sources as well.
Comment 12 Stefano 2015-07-23 22:50:13 UTC
Is there a workaround for this?
I cannot change camera firmware :)
Comment 13 Thiago Sousa Santos 2015-07-23 22:55:25 UTC
If I understand this bug correctly the patch on might be very similar to what you need. Can you test it and check?

The patch there is still going to evolve a bit but it might already work.
Comment 14 Stefano 2015-07-23 23:02:46 UTC
Yes I can test tomorrow but this seems to me more related to the headers eventually.
Is this solving also the problem of requiring the first fragment twice?
After I've consume a fragment the server will invalidate it so I cannot ask twice like the pipeline is dooing.
Comment 15 Stefano 2015-07-24 08:15:44 UTC
Do you want that ilI open another ticket for the double first fragment http request issue? Against what component?
Comment 16 Stefano 2015-09-02 14:54:04 UTC
Is it still need info or could be confirmed?
Comment 17 Thiago Sousa Santos 2015-09-04 19:19:00 UTC
It seems like a confirmed bug, this should be fixed after the 1.6 release that is happening soon.
Comment 18 Stefano 2015-10-09 13:35:00 UTC
Do you have some snip of code that could be tested?
Comment 19 Stefano 2015-11-11 09:33:57 UTC
Any news on this?
Comment 20 GStreamer system administrator 2018-11-03 13:38:18 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: