You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a live HLS stream at http://peach.duckdns.org/live.m3u8 Everything works fine on first load or using pause/resume using the example player at http://www.flashls.org/latest/examples/chromeless/. However, if I hit the "stop" button and then the "play" button the player won't re-fetch the m3u8 file, it just re-plays the content that is cached in memory. Reloading the page gets the stream playing again. This is a problem because I'm using the clappr player, and it only exposes the stop control when playing a live stream. Is there something different that I should be doing when constructing the HLS stream (currently using FFMpeg), different HTTP headers, or maybe something in the JavaScript that creates the player? Or is this a bug I'm hitting in the player?
The text was updated successfully, but these errors were encountered:
@jcollie
chromeless stop() button will stop the video playback and the fragment buffering. but indeed it is not flushing the internal buffer. this is why you are still able to play content cached in memory.
in your case you want to reload the stream.
I guess there should be some means with clappr to relad the URL ?
I have a live HLS stream at http://peach.duckdns.org/live.m3u8 Everything works fine on first load or using pause/resume using the example player at http://www.flashls.org/latest/examples/chromeless/. However, if I hit the "stop" button and then the "play" button the player won't re-fetch the m3u8 file, it just re-plays the content that is cached in memory. Reloading the page gets the stream playing again. This is a problem because I'm using the clappr player, and it only exposes the stop control when playing a live stream. Is there something different that I should be doing when constructing the HLS stream (currently using FFMpeg), different HTTP headers, or maybe something in the JavaScript that creates the player? Or is this a bug I'm hitting in the player?
The text was updated successfully, but these errors were encountered: