HLS - Live stream with fMP4 - infinite loading

[avelad]

Have you read the FAQ and checked for duplicate issues: Yes

What version of Shaka Player are you using: Master branch

Can you reproduce the issue with the latest code from master: Yes

Are you using the demo app or your own custom app: Demo

What browser and OS are you using: Chrome 63 / Firefox 57 in Ubuntu 17.10

What are the manifest and license server URIs:
(you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)
https://cdn.demo.anevia.com/live/eds/dvb_txt/HLS-MP4/dvb_txt.m3u8 (HLS - Live stream with fMP4)

What did you do?
Load the stream

What did you expect to happen?
The video is reproduced

What actually happened?
The video is on infinite loading

The same stream in hls.js works: http://video-dev.github.io/hls.js/demo/

[vaage]

@avelad based on your screenshot, it appears your content has not been set up for CORS. If you enable CORS on your server, what happens?

[avelad]

@vaage , I just tested and I see the same behaviour.

[vaage]

@avelad When I try to run your content, I get errors about no access control allow origin. Unless CORS is set-up correctly on the server us to test with, we won't be able to look into this issue.

[joeyparrish]

@vaage, you can use --disable-web-security in Chrome to work around CORS for the sake of debugging.

[vaage]

Thanks @joeyparrish.

When I run your content what I see is:

Updating manifest...
hls_parser.js:1182 First segment dvb_txt-video=499712.track_id=10000-9383262.m4s starts at 26304.347555555567
hls_parser.js:1182 First segment dvb_txt-audio_20000=160000.track_id=20000-9383262.m4s starts at 50044175.87422225
hls_parser.js:1182 First segment dvb_txt-video=599040.track_id=10001-9383262.m4s starts at 26304.347555555567
hls_parser.js:1182 First segment dvb_txt-DVBTXT_TTML_fra_5888=10000.track_id=30002-9383262.webvtt starts at 11436.54077777778
streaming_engine.js:1305 (audio:2) looking up segment: presentationTime=11511.904177904129 currentPeriod.startTime=0
streaming_engine.js:1305 (video:8) looking up segment: presentationTime=11511.931177854538 currentPeriod.startTime=0

Which is similar to what your screenshot showed, however it looks like to me (and maybe @joeyparrish) can comment on this too, is that your content times do not line-up with the presentation, so the player is stuck waiting for your content to start. @joeyparrish is that accurate?

[avelad]

@vaage, I tested the same stream in Safari, AVPlayer (iOS), ExoPlayer (Android), hls.js and in all it works

[joeyparrish]

From the log posted by @vaage, it seems that the video and audio timestamps (as understood by our parser) are very different. (26304s for video and 50044175s for audio) Probably, our parser is doing something wrong. We'll take a look. Thanks!

[joeyparrish]

In the video stream:

• moov->mvhd has timescale of 1
• moov->trak->mdia->mdhd has timescale of 25

In the audio stream:

• moov->mvhd has timescale of 1
• moov->trak->mdia->mdhd has timescale of 48000

Our HLS parser makes a bad assumption that the timescale is 90000, which is only true for TS content.

[joeyparrish]

I've been able to fix the parser locally with regard to timescale, but I still have an issue with your content. It seems that the WebVTT segments have some bad timestamp info in them.

For example:

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:8070850976,LOCAL:00:00:00.000

TS timestamp of 8070850976 is 89676.12s, but the corresponding audio & video segments have timestamps of 93910850.6s. For these to align, the MPEGTS timestamp in the vtt file would need to be "8451976554000".

If we take these apart in hex, it becomes apparent that the timestamp has rolled over at 33 bits:

8070850976    => 0x  1e10f69a0
8451976554000 => 0x7afe10f6610

The bottom 33 bits are very very close, and a quick google search shows that this seems to be a thing in MPEG that libraries have to deal with.

We'll fix the MP4 parsing first, then come back to the rollover issue.

[avelad]

@joeyparrish , do you have any update? We want use fmp4 with HLS, but this issue is limiting us.

[joeyparrish]

No, I'm sorry. Not yet.

[joeyparrish]

I just pushed the first fix, which fixes assumptions about the timescale in MP4 HLS content.

After that, we need to deal with rollover on load.

After that, ideally, we should also deal with rollover which occurs during playback. Given that this happens every 1.1 days in TS or HLS+VTT, end-users will definitely encounter this in live streams.

[avelad]

Thanks @joeyparrish . I just tested the fix for MP4 timescale and it works!. Can you migrate this fix to 2.3.x?

[joeyparrish]

Yes, this will be in v2.3.1. I hope to land rollover fixes in v2.3.1 as well.

[joeyparrish]

All of the rollover-related fixes are now in.

[joeyparrish]

Cherry-picked to v2.3.1.