Hi,
i'm trying to play the following stream via gstreamer
gst-launch-1.0 souphttpsrc is-live=true location=https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 ! hlsdemux ! decodebin ! videorate ! videoconvert ! ximagesink
Unfortunately the stream is stopping after a few seconds. Afterwards the picture is updated in a very slow frequency (1 picture in 10 seconds, or slower).
I set the debug level to 3 and see the following message before the stream is stopped.
calculate_skew: backward timestamps at server or no buffer timestamps. Resync base PCR
I notified the problem on my current arch linux installation, and also on a ubuntu machine.
Other streams working fine. The problem seems also related to this stream. The stream is working in vlc fine.
I'm new in gstreamer, so i don't have any ideas how to proceed.
Are there extra special options, to fix this problem? Have anyone an idea, why the stream is stopping?
Thanks in advance and best regards
Marcel
0:00:22.821619516 42400 0x7f5d9000d760 DEBUG adaptivedemux gstadaptivedemux.c:3716:gst_adaptive_demux_stream_download_loop:<hlsdemux0> Calling update_fragment_info
0:00:22.821630787 42400 0x7f5d9000d760 DEBUG hls m3u8.c:848:gst_m3u8_get_next_fragment: Looking for fragment 14457398
0:00:22.821642670 42400 0x7f5d9000d760 INFO hlsdemux gsthlsdemux.c:1087:gst_hls_demux_update_fragment_info:<hlsdemux0> This playlist doesn't contain more fragments
0:00:22.821653152 42400 0x7f5d9000d760 DEBUG adaptivedemux gstadaptivedemux.c:3718:gst_adaptive_demux_stream_download_loop:<hlsdemux0:src_0> Fragment info update result: -3 eos
0:00:22.821661445 42400 0x7f5d9000d760 DEBUG adaptivedemux gstadaptivedemux.c:3784:gst_adaptive_demux_stream_download_loop:<hlsdemux0:src_0> EOS, checking to stop download loop
0:00:22.821670986 42400 0x7f5d9000d760 DEBUG adaptivedemux gstadaptivedemux.c:4442:gst_adaptive_demux_has_next_period:<hlsdemux0> Has next period: 0
0:00:22.821678758 42400 0x7f5d9000d760 DEBUG adaptivedemux gstadaptivedemux.c:2853:gst_adaptive_demux_stream_wait_manifest_update:<hlsdemux0> No fragment left but live playlist, wait a bit
-- Marcel Behlau (Soft- und Hardwareentwicklung) ELFIN Technology GmbH Siegburger Straße 215 50679 Köln Germany Tel: +49 (221) 6778932-0 Fax: +49 (221) 6778932-2 [hidden email] www.elfin.de Unternehmenssitz: Siegburger Straße 215, 50679 Köln Amtsgericht Köln, HRB 77204 Geschäftsführer: Michael Braun, Jörg Hellmich, René Specht _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I have little experience with video streams (I'm also fairly new to
GStreamer), but I'm getting the same problem, even when using auto-built pipelines, e.g. gst-play-1.0.exe https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 gst-launch-1.0 souphttpsrc location=https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 ! queue2 use-buffering=true ! decodebin3 ! autovideosink gst-launch-1.0 uridecodebin uri=https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 ! autovideosink I'd first of all recommend adding a buffering element after the http source, such as queue2. Caching the stream should usually help prevent constant starts and stops during playback. VLC, YouTube, etc. all do this. See docs here: https://gstreamer.freedesktop.org/documentation/application-development/advanced/buffering.html?gi-language=c I'd also suggest trying a completely different HLS source to test the pipeline, just to see if it's something wrong specific to this stream. Someone will have to comment beyond this, I am simply uneducated in this area. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi, thx for your help. A lot of streams are working fine, but some streams (which are requested by my customer) are failing with this problem. I think the problem is related to buffering/caching, which isn't
optimal for this kind of stream/some server configurations. It
seems, there is some kind of an hiccup, so that the data isn't
provided in a very smooth manner. Regarding this, i tried to increase the buffer sizes to create an data pool for compensating the "data downtime". If i use the following command, gstreamer is fetching a long, long time, before starting the playback. Unfortunately, the stream is stopping also after a few seconds. What is happening during in the fetching phase? gst-launch-1.0 --gst-debug=uridecodebin:5 uridecodebin uri=https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 buffer-duration=30000000000 buffer-size=100000000 download=true use-buffering=true high-watermark=1.0 low-watermark=1.0 ! autovideosink
Btw. i found an workaround by fetching the data with ffmpeg. This can be done via this one-liner:
On 10.07.20 22:27, gotsring wrote:
I have little experience with video streams (I'm also fairly new to GStreamer), but I'm getting the same problem, even when using auto-built pipelines, e.g. gst-play-1.0.exe https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 gst-launch-1.0 souphttpsrc location=https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 ! queue2 use-buffering=true ! decodebin3 ! autovideosink gst-launch-1.0 uridecodebin uri=https://d2e1asnsl7br7b.cloudfront.net/7782e205e72f43aeb4a48ec97f66ebbe/index_5.m3u8 ! autovideosink I'd first of all recommend adding a buffering element after the http source, such as queue2. Caching the stream should usually help prevent constant starts and stops during playback. VLC, YouTube, etc. all do this. See docs here: https://gstreamer.freedesktop.org/documentation/application-development/advanced/buffering.html?gi-language=c I'd also suggest trying a completely different HLS source to test the pipeline, just to see if it's something wrong specific to this stream. Someone will have to comment beyond this, I am simply uneducated in this area. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel -- Marcel Behlau (Soft- und Hardwareentwicklung) ELFIN Technology GmbH Siegburger Straße 215 50679 Köln Germany Tel: +49 (221) 6778932-0 Fax: +49 (221) 6778932-2 [hidden email] www.elfin.de Unternehmenssitz: Siegburger Straße 215, 50679 Köln Amtsgericht Köln, HRB 77204 Geschäftsführer: Michael Braun, Jörg Hellmich, René Specht _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |