GNOME Bugzilla – Bug 752858
hlsdemux: Double http request of first fragment in m3u8
Last modified: 2018-11-03 13:38:48 UTC
I opened this new ticket from https://bugzilla.gnome.org/show_bug.cgi?id=752732 In the camcorder server streaming implementation I can try to consuming cannot require a fragment in the m3u8 twice because after the first consumption it will be invalidate and it is unavailable to a second one. Analyzing network traffic and gstreamer log seems that the first fragment it is required twice (the first for negotiation in prerolling and one for consumption in Playing phase). m3u8 live playlist and gstreamer log are attached in the cited ticket.
I tried reproducing it with git master and some online non-live playlists but I couldn't. Perhaps it is something specific with live playlists or with your particular stream. Did you try git master to check if it wasn't solved already? The log on the other bug isn't very helpful. Could you attach a new one with GST_DEBUG=hlsdemux:9,adaptivedemux:9 here, please?
Ok. I've attached the new log of: GST_DEBUG_FILE=gstreamer_m3u8.log GST_DEBUG=hlsdemux:9,adaptivedemux:9 gst-launch-1.0 -v souphttpsrc location="http://192.168.0.80:80/livestream/playlist" keep-alive=TRUE ! hlsdemux ! decodebin ! autovideosink And the two m3u8 states. One before pipeline launch and the other after pipeline stopped.
Created attachment 308238 [details] gstereamer doulbe http request log
Created attachment 308239 [details] Playlist retrieved with http before pipleline launch
Created attachment 308240 [details] Playlist retrieved with http after pipleline ended with error
Thiago do you need more test or logs?
Could you try getting a log with git master, a few things have changed in HLS stream repositioning and it might be fixed already. If not, please submit new logs with master. Thanks
Ok. I've attached the git master log.
Created attachment 308660 [details] gstreamer git master log
Is this enough? I can make some more log and test tomorrow if you need.
I found one issue with adaptivedemux with this log but it seems weird that some element downstream returns EOS from a pad push. Is this using playbin or some custom pipeline? Can you get a full GST_DEBUG=6 log for further investigation?
The pipeline it is exactly in the comment 2. If you want i can use this GST_DEBUG level to log this pipeline.
(In reply to Stefano from comment #12) > The pipeline it is exactly in the comment 2. If you want i can use this > GST_DEBUG level to log this pipeline. Yes, please.
Created attachment 308843 [details] GST_DEBUG=6,hlsdemux:9,adaptivedemux:9 log gstreamer master branch log of pipeline: GST_DEBUG_FILE=gstreamer_master_m3u8_debug6.log GST_DEBUG=6,hlsdemux:9,adaptivedemux:9 ./gst-launch-1.0 -v souphttpsrc location="http://192.168.0.80:80/livestream/playlist" keep-alive=true ! hlsdemux keep-alive=true ! decodebin ! autovideosink
Ok i've attached with the log level you requirded. I can send other log today or execute other test then I will start a vacation period so if you are available today send me other requests.
It seems like the issue is related to the fact that this is HLS serving mp4 fragments but without moof atoms. It is playback of a sequence of moov|mdat chunks which is a new case that hasn't been implemented yet. So qtdemux is not ready to play fragmented stream that is not using the fragmented atoms. That being said, I'd believe it is not that far from working. The best way for us to implement it would be to get access to a short sequence of those fragments so we could simulate the playback of those without needing access to your hardware. Would it be possible to get a sequence of those fragments and host them somewhere for analysis? Worst case you could just try: gst-launch-1.0 -v souphttpsrc location="http://192.168.0.80:80/livestream/playlist" keep-alive=true ! hlsdemux keep-alive=true ! filesink location=streamdump.mp4 but the fragments split as the original stream would be better. Thanks,
I can download mp4 fragment trough a custom python script if this is enough for you.
That would be great, getting a short sequence of fragments would be enough (at least 3). Thanks again!
Created attachment 308851 [details] mp4_fragments This are 4 mp4 fragments downloaded from playlist with a custom python script.
It helps to have proper timestamping support to play those samples properly, so adding the other bug as a dependency. It is not directly related to the double http requests, though.
Thiago do you need more tests, logs or fragments? What is causing the double http reqeust? When a fragment was downloaded for negotiation cannot be pushed in the pipeline instead of downloading again?
I'm already able to reproduce it, was busy what other stuff in the past weeks but I'm back on fixing those issues. The problem is not fully in hlsdemux, it also needs some fixes in qtdemux.
Thank you for the update. Now that 1.6 was released do you plan to push something in master that I can test with the camcoder?
One additional trickery here is that when starting a fragment, should audio and video start aligned? Because usually the previous fragment won't end with both audio and video having the same end-timestamp.
Thiago what about your last comment? Do you need some test?
The playlists lack a #EXT-X-MEDIA-SEQUENCE tag. Without this, hlsdemux cannot know how to deal with a playlist update. That might explain why hlsdemux is downloading a fragment multiple times. According to the HLS draft: 6.2.2. Live Playlists The server MAY limit the availability of Media Segments by removing Media Segments from the Playlist file (Section 6.2.1). If Media Segments are to be removed, the Playlist file MUST contain an EXT-X -MEDIA-SEQUENCE tag. Its value MUST be incremented by 1 for every Media Segment that is removed from the Playlist file https://tools.ietf.org/html/draft-pantos-http-live-streaming-17#section-6.2.2
Is this still an issue with current master ?
-- 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/284.