videojs / http-streaming

HLS, DASH, and future HTTP streaming protocols library for video.js
https://videojs-http-streaming.netlify.app/
Other
2.51k stars 424 forks source link

Issues playing dash and hls streams #384

Closed augusto closed 5 years ago

augusto commented 5 years ago

Description

The player won't play correctly a video in either DASH or HLS formats. Both formats work ok with other players (jwplayer - both formats, hlsjs - hls, shaka - dash).

Sources

Steps to reproduce

  1. Go to the test player page: https://videojs.github.io/http-streaming/
  2. Enter the video url: https://s3.amazonaws.com/ds-video-public/test/bbb/demo/h264_master.m3u8 or https://s3.amazonaws.com/ds-video-public/test/bbb/demo/h264.mpd with the corresponding type.
  3. Click Load
  4. Try to play the stream

Results

Expected

Video plays without any errors

Error output

For DASH on all browsers: The player shows jumps to the end of the player timeline without playing anything.

For HLS on all browsers: The player plays the first segment and the shows the error "VIDEOJS: ERROR: (CODE:3 MEDIA_ERR_DECODE) The media playback was aborted due to a corruption problem or because the media used features your browser did not support."

Additional Information

I used shaka packager 2.3.0 (latest release so far) to create the streams following the example on this page under the heading Single file MP4 output with DASH + HLS

videojs-http-streaming version

videojs-http-streaming 1.8.0

videojs version

Video.js 7.4.2

Browsers

Chrome: 71.0.3578.98 Opera 57.0.3098.116 Firefox 64.0

Platforms

Linux, Ubuntu 18.04

Other Plugins

No

Other JavaScript

No

welcome[bot] commented 5 years ago

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can. To help make it easier for us to investigate your issue, please follow the contributing guidelines.

mjneil commented 5 years ago

This is due to a bug in the m3u8-parser not correctly handling byte range tags without an offset

https://github.com/videojs/m3u8-parser/issues/78

augusto commented 5 years ago

Thanks for checking this @mjneil. That explains why only the first segment was played.

I hope someone else might be able to comment on the issue with DASH, as I assume it will have a different cause.

mjneil commented 5 years ago

It looks like your dash manifest uses a sidx box for providing the byterange info. This is currently in the works of being supported. You can track that features progress in https://github.com/videojs/mpd-parser/pull/41 and https://github.com/videojs/http-streaming/pull/303

tidemann commented 5 years ago

I'm having similar problems with playing .mpd source using videojs 7.4.1, videojs-contrib-eme 4.3.1 and http-streaming 1.5.1 using a widevine lisence-server like this:

    player.src({
        src: MPD_SOURCE,
        type: 'application/dash+xml',
        keySystems: {
            'com.widevine.alpha': LISENCE_SERVER_URL

        }
    });

It works fine in THEOPlayer and I noticed in chrome://media-internals/ that the duration with THEOPlayer is set to 7277.397333 when the source is loaded. When using videojs + eme + vhs, duration is 0.080859 for the same source.

Could this be why it stops immediately? It just reaches the end of the first chunk is fetches and ignores the duration set in the .mpd manifest?

gkatsev commented 5 years ago

445 (the replacement for #303) for SIDX support has been merged. We'll be releasing soon.