GNOME Bugzilla – Bug 675624
[PATCH] [souphttpsrc] Add new features required to support DASH streaming
Last modified: 2013-05-18 09:50:20 UTC
Created attachment 213608 [details] [review] [souphttpsrc] Add new features required to support DASH streaming In attachment: souphttpsrc-add-support-for-DASH-streaming.patch This patch modifies the souphttpsrc element in the gst-plugins-good-0.10.31 package. It adds support for several new features that are needed by the DASH streaming client DASHBIN (released in a separate patch). The new capabilities are: 1) support for HTTP partial GET requests through the byte range specified with the properties "first-byte-pos" and "last-byte-pos"; 2) support for HTTP persistent connections; 2) several new signals to report the souphttpsrc status to the controlling bin (DASHBIN) and to request the URL of a new data segment as soon as the current one is finished; 3) two new action signals to start/stop downloading new segments (in case the download buffer is full and we want to delay the download of the next data segment); 4) error recovery support: if the given URL points to an unavailable server (or a missing file), the error is reported to the controlling bin (DASHBIN) so that an alternative URL is tried if available; All the new features (with the exclusion of the HTTP partial GET requests support) are enabled only when the new property "dash-mode" is set to TRUE. Best regards, Gianluca Gennari
You really don't need all those changes on souphttpsrc to implement a DASH element in GStreamer. - Partial get requests can be handled with extra headers using range requests. - Persistent connections pool is handled by libsoup at a lower level already. - Buffering should be handled in downstream elements - Error handling to try alternative URLs should also be handled by the application or the bin using souphttpsrc. - Queueing the next segment in souphttpsrc can be done by the application or the managing bin. I think that trying to implement all this logic in souphttpsrc goes against the classical design of GStreamer elements, souphttpsrc is just an HTTP downloader, the logic for DASH and other protocols should be implemented by the app/bin that is using this source. This is the way we use at Fluendo for our DASH demuxer and we've been able to make a fully functional demuxer without patching a single line of code in souphttpsrc. Best regards,
Hi Julien, thanks for the review. I agree with most of your comments. At the time the project was started, the intention was to use it just as an internal tool to evaluate the new DASH standard, and only later we decided to release it as open source. Also, this was my first big GStreamer project, so I was not completely aware of some of the "best practices". Anyway, this is completely solved today as the original project has been dropped in favor of a new design based on the HLSdemux plugin structure, that is called "dashdemux" (jointly developed by Orange and STM). Anyway, I still have a couple of observation: - persistent connections are explicitly disabled by souphttpsrc, by hardcoding the corresponding HTTP header "Connection" to "close". So, at least, we need a property to enable persistent connections explicitly. - hlsdemux and dashdemux use the URI handler interface of the HTTP downloader element to set the URI of the segment to download; as far as I can understand, there is no API to directly set extra headers in the URI handler interface. In dashdemux we implemented support for partial GET requests by appending a string similar to this: "?range=0-1000" to the requested URI, and patching souphttpsrc to handle this extra information. This approach follows the suggestion in Appendix E of the DASH standard. Do you think this is a viable solution? Is there a way to set the extra headers property using the URI handler interface? Thanks for your comments, Gianluca Gennari