GNOME Bugzilla – Bug 740461
hlsdemux:GOPRO Cam Not streaming fine due to segment duration
Last modified: 2018-11-03 13:28:52 UTC
GST_DEBUG=2,*hls*:9,*mpegts*:9,*tsbase*:9 gst-launch-1.0 playbin uri=http://10.5.5.9:8080/live/amba.m3u8 video-sink=ximagesink Problem: Lot of freeze and not a smooth video/audio streamed avplay works fine but not gst Thank you for having a look
Created attachment 291129 [details] Log of pipeline
for your reference, ffmpeg -i "http://10.5.5.9:8080/live/amba.m3u8" -an -vcodec libx264 -s 400x300 -strict experimental -b:v 300k -b:a 4k -f flv "test.mp4" works fine
Could be related to this: ERROR fragmented m3u8.c:1001:gst_m3u8_client_advance_fragment: Could not find current fragment After this it starts pushing the fragments in a non-contiguous sequence: gst_hls_demux_get_next_fragment:<hlsdemux0> Fetching next fragment http://10.5.5.9:8080/live/amba_hls-4.ts 0:00:18.000000000 gst_hls_demux_get_next_fragment:<hlsdemux0> Fetching next fragment http://10.5.5.9:8080/live/amba_hls-8.ts 0:00:18.000000000 gst_hls_demux_get_next_fragment:<hlsdemux0> Fetching next fragment http://10.5.5.9:8080/live/amba_hls-12.ts 0:00:18.00000000 ... The timestamps should be increasing by 1s for each fragment, and it seems to be skipping a few of them.
It seems that the gopro hls files are much shorter than the advertised target duration. Here I get 0.28s file and the target is 1s
*** This bug has been marked as a duplicate of bug 731982 ***
Reopening as it still isn't smooth because of the large difference of the real duration of the segments and the reported one. The sync is lost quickly and playback stops.
-- 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/193.