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?

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.

Sebastian it is exactly what Tim exposed.
I will update this morning on the context of the experiment where I've experienced this bug.

Created attachment 307992 [details]
playlist

Canon Legria Playlist

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 http://192.168.0.80/livestream/  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="http://192.168.0.80:80/livestream/playlist"  extra-headers="Bo, HOST=(string)192.16.0.80" keep-alive=TRUE  keep-alive=TRUE is-live=TRUE ! hlsdemux !  decodebin ! autovideosink

Created attachment 307996 [details]
gstreamer log

Created attachment 308013 [details]
gstreamer log

I've added a more completed gstreamer debug log

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.e.

I see gstsouphttpsrc.c:1754:gst_soup_http_src_start:<souphttpsrc1> start("http://192.168.0.80/livestream/segment?seq=37675") in prerolling phase

And then in play phase i found gstsouphttpsrc.c:1754:gst_soup_http_src_start:<souphttpsrc1> start("http://192.168.0.80/livestream/segment?seq=37675")

https://bugzilla.gnome.org/show_bug.cgi?id=751371
https://bugzilla.gnome.org/show_bug.cgi?id=751372

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).

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)?

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.

Is there a workaround for this?
I cannot change camera firmware :)

If I understand this bug correctly the patch on https://bugzilla.gnome.org/show_bug.cgi?id=751372 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.

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.

Do you want that ilI open another ticket for the double first fragment http request issue? Against what component?

Is it still need info or could be confirmed?

It seems like a confirmed bug, this should be fixed after the 1.6 release that is happening soon.

Do you have some snip of code that could be tested?

Any news on this?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org'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: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/280.