Hls.js: Live stream: poster is removed before user starts playback

[AviVahl]

Environment

• [x] The stream has correct Access-Control-Allow-Origin headers (CORS)
• [x] There are no network errors such as 404s in the browser console when trying to play the stream
• [x] The issue observed is not already reported by searching on Github under https://github.com/dailymotion/hls.js/issues
• [x] The issue occurs in the latest reference client on http://dailymotion.github.io/hls.js/demo and not just on my page
• Link to playable M3U8 file: https://live-ftv.wixmp.com/ftvoriginal/m3u8s/stream.m3u8
• Hls.js version: latest (as used in the provided demo page below)
• Browser name/version: Chrome 55.0.2883.87 (64-bit)
• OS name/version: Windows 10 (+all updates)

Steps to reproduce

1. https://jsfiddle.net/p86cu6y6/
2. Watch poster disappearing before you even click Play.

Expected behavior

Poster to stay until playback/seek was fired by user.

Actual behavior

First received live frame is replacing poster.

Console output

Console is empty.

Additional information

autoplay is not set, as can be seen in the demo page.

[mangui]

Hi @AviVahl this is happening as after the first fragment gets loaded, hls.js will seek to its start position.
and as soon as video element receives a seek request, poster is disposed.

If you use a poster, I think preloading fragments might result in a waste of bandwidth.
as you are loading fragments although the user might not hit the play button
In your case I would rather do it this way

<script>
  if(Hls.isSupported()) {
    var video = document.getElementById('video');
    var hls = new Hls({ autoStartLoad: false});
    hls.loadSource('https://live-ftv.wixmp.com/ftvoriginal/m3u8s/stream.m3u8');
    hls.attachMedia(video);

    video.addEventListener('play',function() {
     hls.startLoad();
    });    
  };
</script>

[AviVahl]

I see. Thank you for the informative answer.
I wonder, is there a way to preload _only the first_ fragment without causing the seek?
Or even better, specify an amount of time to preload.
It would allow immediate playback start if the user decides to press play, which is what I really want.

In addition, does hls.js look at the HTMLMediaElement.preload flag? Would be great if this behavior also took into account the preload attribute we set on the <video> element itself.

@mangui

[vincentbernat]

Just a note: the issue is not limited to live videos. It also happens on VOD. On both Firefox and Chromium.

[noraiz-anwar]

@mangui onloadedmetadata is never fired if we initialize hls with autoStartLoad: false. It seems like browser need to make sure if stream is available before firing onloadedmetadata and as we restrict loading any chunk, browser keep on waiting for initial stream.
Is there any way we can retain video poster without autoStartLoad: false?
Thanks.

[ghost]

I'd like to add my voice to people requesting a working solution to this problem that does not imply setting the autoload to false. Certain browsers will not provide a play button at all to the user if autostart is set to false. It will just show the infinite load animation and the player will be disabled (IE and Chrome). There needs to be a working solution to keep the poster frame set even when the autostart is set to true and until the user actually presses play, bandwidth waste aside.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.