Chrome PTS bug - Playback never starts with FF 46 and Edge

[FedeOmoto]

Hi!

Using Shaka Player v2.0.0-beta2, this stream never starts: http://wzstrm.arnet.com.ar:1935/investorsvod/earnings_release_1q16.mp4/manifest.mpd

In both FF and Edge, we see that it downloads a lot of video chunks until it stops loading.

It works OK with Chrome.

[tdrews]

Thanks for the report. We'll take a look.

[cpeterso]

I tested this stream in some other browsers and MPEG-DASH players. It looks like there is likely a problem with the manifest and maybe bugs in Firefox and/or Shaka.

Browser	Shaka Player	DASH.js player	Bitdash player
Chrome	plays	plays	plays
Firefox	fails?!	plays	plays
Edge	fails	fails	fails
IE11	fails	fails	fails

@jyavenard: Here is my about:media from Firefox Nightly 48. Why might Firefox fail to play this stream in Shaka but succeed in DASH.js and Bitdash when Edge and IE11 fail everywhere?

HTMLMediaElement debug data

http://shaka-player-demo.appspot.com/demo/
    mediasource:http://shaka-player-demo.appspot.com/605919bb-2c2b-e547-b19c-8a151944a64d
    currentTime: 0
    Quality: -- (total:0 dropped:0 corrupted:0)
    Buffered ranges: [(0.2, 50.015442)]
        SourceBuffer 0
            start=0 end=50.015442
        SourceBuffer 1
            start=0.2 end=279
    Internal Data:
    audio decoder: apple CoreMedia decoder
    audio frames decoded: 90
    audio state: ni=0 no=0 ie=1 demuxr:0 demuxq:0 decoder:1 tt:-1.000000 tths:-1 in:90 out:90 qs=3 pending:3 waiting:0 sid:0
    video decoder: shutdown
    hardware video decoding: disabled
    video frames decoded: 0 (skipped:0)
    video state: ni=0 no=0 ie=0 demuxr:0 demuxq:0 decoder:0 tt:-1.000000 tths:-1 in:0 out:0 qs=0 pending:0 waiting:1 sid:4294967295
    Dumping data for demuxer 118650800:
        Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 2.089433
            NumSamples:2154 Size:1314718 NextGetSampleIndex:90 NextInsertionIndex:2154
            Buffered: ranges=[(0.000000, 50.015442)]
        Dumping Video Track Buffer(video/avc) - mLastVideoTime: 0.000000
            NumSamples:2788 Size:12370147 NextGetSampleIndex:4294967295 NextInsertionIndex:2788
            Buffered: ranges=[(0.200000, 279.000000)]

[tdrews]

The first segment has a baseMediaDecodeTime of 0 seconds, but the first sample
has a sampleCompositionTimeOffset of 18000/90000 = 0.2 seconds (i.e., its DTS is 0 but its PTS is 0.2).

There appears to be a bug in Chrome which causes buffered ranges to use DTS instead of PTS (see #338 and see https://bugs.chromium.org/p/chromium/issues/detail?id=398130). And, in addition to this, the manifest specifies that the first segment starts at t=0 when it should specify that it starts at t=0.2. So, this content works on Chrome because the two issues cancel each other out.

Chrome should report buffered ranges using PTS (see https://www.w3.org/TR/media-source/#track-buffers), and DASH manifests should specify segment start times using PTS too.

[jyavenard]

That video stream has a gap of 200ms at the start. Firefox only skip over gaps that are less than 150ms.

The buffered range starts at 0.2s. Dash.js will seek to the video.buffered.start(0) and playback will start.

I guess Shaka doesn't. It probably should

[tdrews]

Shaka will jump the initial gap in the buffer if that gap is specified in the manifest, i.e., if the manifest specifies that the first segment starts at t=0.2, Shaka will start playback at t=0.2. However, Shaka does not jump any unexpected gaps in the buffer (by way of inspecting video.buffered post appendBuffer). We'd like to avoid doing this... but we may need to in order to work around these DTS/PTS issues and to handle actual missing segments (see #180).

[jyavenard]

I've seen so many invalid manifests and incorrectly muxed data (which typically do not start at time=0) that it would be rather crazy to always trust the manifest.

As chrome incorrectly reports the buffered range using the dts (and those always start at 0 by definition) all videos appear to have a buffered range starting at 0, it probably means that with shaka it's fine for now. When that bug is fixed, problems will start.

It's been beyond frustrating to have received countless bug reports that a stream works with chrome but not firefox, when chome is doing the wrong thing.

Similar with unexpected gap in the data.

[jdalton]

Does this still repro in Edge 16 (or 17 preview)?

[zouhir]

Tested on Edge17 preview, The video link that @FedeOmoto has reported works with no issues.

More tests on Edge 17 preview:

✅ Shaka: works and tested, supports 4K! here.

✅ Dash.js: works and tested here.

✅ Bitdash: works and tested here.

Only problem would be if you have unsupported encryption which is unrelated to the library.

I think it is safe to close this issue!

[joeyparrish]

I believe the Chrome DTS/PTS bug has now been fixed, so I'm closing this bug. If you still have issues with the latest stable release of Chrome, please file a new issue. Thanks!