GNOME Bugzilla – Bug 758453
souphttpclientsink: add support for next-request as per multifilesink, with supporting parameters.
Last modified: 2015-12-11 15:11:28 UTC
Created attachment 316018 [details] Add support for next-request to souphttpclient as per multifilesink, with supporting parameters. Add support for next-request as per multifilesink, with supporting parameters. next-request : When to start a new request flags: readable, writable Enum "GstSoupHttpClientSinkNext" Default: 0, "none" (0): none - No explicit request boundary (1): buffer - New request for each buffer (2): discont - New request after each discontinuity (3): key-frame - New request at each key frame (Useful for MPEG-TS segmenting) (4): key-unit-event - New request after a force key unit event (5): max-size - New request when the configured maximum request size would be exceeded with the n$ (6): max-duration - New request when the configured maximum request duration would be exceeded with t$ location-prefix : URI prefix combined with URI suffix to produce location flags: readable, writable String. Default: null location-suffix : URI suffix, use %d to specify index location flags: readable, writable String. Default: null index : Index to use with location-suffix property to create location. The index is incremented by one for each buf$ flags: readable, writable Integer. Range: 0 - 2147483647 Default: 0 max-request-size : Maximum request size before starting a new request in max-size mode flags: readable, writable Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 2147483648 max-request-duration: Maximum request duration in nanoseconds before starting a new request in max-size mode flags: readable, writable Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 18446744073709551615 Depends on the following patch: https://bugzilla.gnome.org/show_bug.cgi?id=758385
I don't know, I'm not really in favour of duplicating this kind of logic in all kinds of sinks. I think it would be better to check if we can make splitmuxsink work with this sink.
My core need is to make the hlssink work with HTTP. There are similarities that can be refactored out, definitely.
*** Bug 758385 has been marked as a duplicate of this bug. ***
+1 in trying to figure out how to have the feature in a single place and have other elements reuse it. multifilesink, splitmusink, hlssink and dashsink (in bugzilla) do very similar things.
I'm withdrawing this patch, as it's definitely wrong - the job should be done by splitmusink.
Looking further into splitmuxsink, it looks like that element is broken too. Instead of taking it's source from the output of a muxer, splitmuxsink tries to embed the muxer. This embedding only works with one muxer (mp4mux) and no others (like mpegtsmux). In order for splitmuxsink to do the job, it looks like a whole lot of additional fixing is necessary. http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-not-working-with-mpegtsmux-td4672836.html What really should happen is the "split" part should be part of hlssink directly, as the HLS protocol is very specific on how that split should happen. Both the writing of the resulting files, and the writing of the index m3u8 file should both be sinks, allowing the generic filesink and the generic souphttpclientsink to be used without any fuss.
I don't know what version of splitmuxsink you've been testing, but it is supposed to work with all major muxers and people have been using it successfully with muxers other than mp4mux. The unit test for splitmuxsink uses oggmux. If there are issues with other muxers, those need to be fixed. There was an issue in tsmux that it was not reusable, that has been fixed in tsmux. Could you explain in detail how the "HLS protocol is very specific on how that split should happen" and how splitmuxsink does something else? If you believe that splitmuxsink should be using the output of a muxer you may not understand the purpose and workings of this element fully.
I've been using git-master, with the following pipeline: ... ! splitmuxsink name=mux max-size-time=5000000000 location=/var/www/html/stream/split-segment%05d.ts muxer=mpegtsmux This fails as follows: (gst-launch-1.0:16459): GStreamer-CRITICAL **: Padname video is not unique in element mux, not adding This works fine: ... ! mpegtsmux name=mux ! hlssink ... If I'm doing something wrong it would be great to know what it is. I was hoping that cleaning up hlssink's sink support so that it was not hard coded to multifilesink would be reasonably straightforward, but this has caused weeks of delay and a significant amount of frustration. I would really appreciate being able to confirm a proper way forward before I waste more time coming up with patches that are ultimately rejected again.
Looks like multiplexing anything more complex than a single video channel is simply not possible with splitmuxsink without specialist code, making integrating it with hls or dash a losing proposition: http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-muxing-AV-data-td4672979.html