XUMO HLS stream fails to play in Chrome

[MilosRasic]

Have you read the FAQ and checked for duplicate open issues?

Yes, I've been looking through issues for days.

What version of Shaka Player are you using?

2.5.0-beta3

Can you reproduce the issue with our latest release version?

Yes.

Can you reproduce the issue with the latest code from master?

Yes.

Are you using the demo app or your own custom app?

Tried both, but mostly used Demo App.

If custom app, can you reproduce the issue using our demo app?

Yes.

What browser and OS are you using?

Linux, Chrome Version 72.0.3626.109 (Official Build) (64-bit)

Also tried Chrome on Mac.

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

Haven't tested on a TV.

What are the manifest and license server URIs?

https://dai1.xumo.com/a7ze70ah55wn6lu4/9999243/master.m3u8

No DRM.

What did you do?

Tried to play the stream, many times. Looked through the code but couldn't figure out much except that the error is thrown by the browser.

Tested in Firefox and confirmed it's playing the stream fine.

Checked with hls.js and confirmed it plays fine in both Chrome and FF.

Built from master. Built mux.js from master with videojs/mux.js#224 merged. Copied the built mux.js to Shaka demo directory. Confirmed it doesn't behave differently.

What did you expect to happen?

Playback should work in Chrome as well.

What actually happened?

When playing stream in Demo App, it reports the following error:

Shaka Error MEDIA.VIDEO_ERROR (4,,CHUNK_DEMUXER_ERROR_APPEND_FAILED: Initialization segment misses expected aac track.)

Console in dev tools contains error with codes 3016 and 3014.

The player keeps loading segments and console.logging "Updating manifest..."

The main manifest looks like this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=230000,CODECS="avc1.4d001e,avc1.42000d,avc1.64000c,avc1.64001e,avc1.64001f,mp4a.40.2,mp4a.40.5"
0.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=440000,CODECS="avc1.4d001e,avc1.42000d,avc1.64000c,avc1.64001e,avc1.64001f,mp4a.40.2,mp4a.40.5"
1.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=700000,CODECS="avc1.4d001e,avc1.42000d,avc1.64000c,avc1.64001e,avc1.64001f,mp4a.40.2,mp4a.40.5"
2.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1200000,CODECS="avc1.4d001e,avc1.42000d,avc1.64000c,avc1.64001e,avc1.64001f,mp4a.40.2,mp4a.40.5"
3.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,CODECS="avc1.4d001e,avc1.42000d,avc1.64000c,avc1.64001e,avc1.64001f,mp4a.40.2,mp4a.40.5"
4.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,CODECS="avc1.4d001e,avc1.42000d,avc1.64000c,avc1.64001e,avc1.64001f,mp4a.40.2,mp4a.40.5"
5.m3u8

A manifest for a bandwidth looks like

#EXTM3U
#EXT-X-TARGETDURATION:7
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:1414183
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_001.ts
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_002.ts
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_003.ts
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_004.ts
#EXTINF:5.972,pid=181
https://hls-beacons.xumo.com/hlsstream/v1/beacon?url=https%3A%2F%2Flive-content.xumo.com%2F181%2Fcontent%2FXM0HG9ZQQGN3CF%2F19419631%2F6_005.ts&aid=XM0HG9ZQQGN3CF&eventType=ASSET&cid=9999243&did=a7ze70ah55wn6lu4&playId=1550756272034&eventSubType=playInterval&pid=181
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_006.ts
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_007.ts
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_008.ts
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_009.ts
#EXTINF:6.006,pid=181
https://live-content.xumo.com/181/content/XM0HG9ZQQGN3CF/19419631/6_010.ts

After downloading and parsing those, Shaka proceeds to download the ts files with content-type video/M2PT. I have no idea how to check those. The only human-readable string they contain is "FFmpeg Service".

I also noticed hls.js only downloads ts file for a single bandwidth before starting playback.

chrome://media-internals data below

Shaka Player Properties

render_id: 457
player_id: 1098
origin_url: https://v2-5-0-beta3-dot-shaka-player-demo.appspot.com/
frame_url: https://v2-5-0-beta3-dot-shaka-player-demo.appspot.com/demo/#asset=https://dai1.xumo.com/a7ze70ah55wn6lu4/9999243/master.m3u8;lang=en-GB;build=uncompiled
frame_title: Shaka Player Demo
surface_layer_mode: kOnDemand
url: blob:https://v2-5-0-beta3-dot-shaka-player-demo.appspot.com/148d31af-1c9b-4610-8c7b-0233c03a742d
info: ChunkDemuxer: buffering by DTS
pipeline_state: kStopped
duration: 4294967296
found_video_stream: true
video_codec_name: h264
found_audio_stream: true
audio_codec_name: aac
error: Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf
pipeline_error: CHUNK_DEMUXER_ERROR_APPEND_FAILED

Shaka Log

00:00:00.000	origin_url	https://v2-5-0-beta3-dot-shaka-player-demo.appspot.com/
00:00:00.000	frame_url	https://v2-5-0-beta3-dot-shaka-player-demo.appspot.com/demo/#asset=https://dai1.xumo.com/a7ze70ah55wn6lu4/9999243/master.m3u8;lang=en-GB;build=uncompiled
00:00:00.000	frame_title	Shaka Player Demo
00:00:00.000	surface_layer_mode	kOnDemand
00:00:00.000	url	blob:https://v2-5-0-beta3-dot-shaka-player-demo.appspot.com/148d31af-1c9b-4610-8c7b-0233c03a742d
00:00:00.000	info	ChunkDemuxer: buffering by DTS
00:00:00.000	pipeline_state	kStarting
00:00:01.423	duration	4294967296
00:00:03.947	found_video_stream	true
00:00:03.947	video_codec_name	h264
00:00:03.947	found_audio_stream	true
00:00:03.947	audio_codec_name	aac
00:00:03.947	error	Initialization segment misses expected aac track.
00:00:03.947	error	Initialization segment misses expected h264 track.
00:00:03.947	error	Initialization segment misses expected h264 track.
00:00:03.947	error	Initialization segment misses expected h264 track.
00:00:03.947	error	Initialization segment misses expected h264 track.
00:00:03.947	error	Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf
00:00:03.948	pipeline_error	CHUNK_DEMUXER_ERROR_APPEND_FAILED
00:00:03.948	pipeline_state	kStopping
00:00:03.948	pipeline_state	kStopped

hls.js Player Properties

render_id: 624
player_id: 18
origin_url: https://video-dev.github.io/
frame_url: https://video-dev.github.io/hls.js/demo/
frame_title: hls.js demo
surface_layer_mode: kOnDemand
url: blob:https://video-dev.github.io/8adca8ff-23cf-4a26-85d0-75748038a16c
info: Effective playback rate changed from 0 to 1
pipeline_state: kPlaying
found_audio_stream: true
audio_codec_name: aac
found_video_stream: true
video_codec_name: h264
audio_dds: false
audio_decoder: FFmpegAudioDecoder
is_platform_audio_decoder: false
video_dds: false
video_decoder: FFmpegVideoDecoder
is_platform_video_decoder: false
seek_target: 38.992
audio_buffering_state: BUFFERING_HAVE_ENOUGH
height: 144
width: 256
video_buffering_state: BUFFERING_HAVE_ENOUGH
for_suspended_start: false
pipeline_buffering_state: BUFFERING_HAVE_ENOUGH
event: PLAY
duration: 59.992

hls.js Log

00:00:00.000 | origin_url | https://video-dev.github.io/
00:00:00.000 | frame_url | https://video-dev.github.io/hls.js/demo/
00:00:00.000 | frame_title | hls.js demo
00:00:00.000 | surface_layer_mode | kOnDemand
00:00:00.000 | url | blob:https://video-dev.github.io/8adca8ff-23cf-4a26-85d0-75748038a16c
00:00:00.000 | info | ChunkDemuxer: buffering by DTS
00:00:00.000 | pipeline_state | kStarting
00:00:01.450 | found_audio_stream | true
00:00:01.450 | audio_codec_name | aac
00:00:01.450 | found_video_stream | true
00:00:01.450 | video_codec_name | h264
00:00:01.452 | audio_dds | false
00:00:01.452 | audio_decoder | FFmpegAudioDecoder
00:00:01.452 | is_platform_audio_decoder | false
00:00:01.452 | info | Selected FFmpegAudioDecoder for audio decoding, config: codec: aac, bytes_per_channel: 2, channel_layout: 3, channels: 2, samples_per_second: 44100, sample_format: 2, bytes_per_frame: 4, seek_preroll: 0us, codec_delay: 0, has extra data: false, encryption scheme: Unencrypted, discard decoder delay: false
00:00:01.452 | video_dds | false
00:00:01.452 | video_decoder | FFmpegVideoDecoder
00:00:01.452 | is_platform_video_decoder | false
00:00:01.452 | info | Selected FFmpegVideoDecoder for video decoding, config: codec: h264, format: PIXEL_FORMAT_I420, profile: h264 high, coded size: [256,144], visible rect: [0,0,256,144], natural size: [256,144], has extra data: false, encryption scheme: Unencrypted, rotation: 0°
00:00:01.452 | pipeline_state | kPlaying
00:00:01.458 | seek_target | 38.992
00:00:01.458 | pipeline_state | kSeeking
00:00:01.458 | pipeline_state | kPlaying
00:00:01.461 | audio_buffering_state | BUFFERING_HAVE_ENOUGH
00:00:01.463 | height | 144
00:00:01.463 | width | 256
00:00:01.464 | video_buffering_state | BUFFERING_HAVE_ENOUGH
00:00:01.466 | for_suspended_start | false
00:00:01.466 | pipeline_buffering_state | BUFFERING_HAVE_ENOUGH
00:00:01.466 | info | Effective playback rate changed from 0 to 1
00:00:01.466 | event | PLAY
00:00:01.454 | duration | 59.992
00:00:05.104 | duration | 60.05461
00:00:06.434 | duration | 66.002175
00:00:06.438 | duration | 66.060621
00:00:08.535 | duration | 72.019936
00:00:09.660 | duration | 72.066621
00:00:10.425 | info | video decoder config changed midstream, new config: codec: h264, format: PIXEL_FORMAT_I420, profile: h264 high, coded size: [640,360], visible rect: [0,0,640,360], natural size: [640,360], has extra data: false, encryption scheme: Unencrypted, rotation: 0°
00:00:10.922 | height | 360
00:00:10.922 | width | 640
00:00:14.536 | duration | 78.025936
00:00:15.709 | duration | 78.072632
00:00:16.684 | info | Selected video track: []
00:00:16.685 | video_buffering_state | BUFFERING_HAVE_NOTHING
00:00:16.685 | video_buffering_state | BUFFERING_HAVE_ENOUGH
00:00:16.685 | for_suspended_start | false
00:00:16.685 | pipeline_buffering_state | BUFFERING_HAVE_ENOUGH
00:00:20.380 | duration | 84.031936
00:00:21.518 | duration | 84.078632
00:00:26.541 | duration | 90.037936
00:00:27.799 | duration | 90.084643
00:00:32.542 | duration | 96.009936
00:00:33.840 | duration | 96.057277
00:00:38.541 | duration | 102.015936
00:00:39.671 | duration | 102.016325
00:00:39.675 | duration | 102.063288
00:00:44.599 | duration | 108.021936
00:00:45.764 | duration | 108.069288
00:00:50.384 | duration | 114.012684
00:00:51.746 | duration | 114.021042
00:00:51.748 | duration | 114.075299
00:00:56.558 | duration | 120.014213

The most glaring difference I can see is hls.js not logging Duration until after playback has started and logging values that look more meaningful.

On a related note, the manifests seem to be dynamic and will sometimes return absolute cross-origin URLs which contain the word "beacon". These will fail CORS with Shaka. hls.js doesn't have a problem with those. It uses XHR, not Fetch API, and doesn't even make OPTIONS requests.

I'd be happy to help debug or even fix this, but my knowledge of video and audio codecs is severely limited. Identifying this as a known issue or some pointers about where to look for bugs would be much appreciated.

[theodab]

Trying this out, it looks like when using the fetch plugin it errors whenever the URL is the "beacon" URL, as you mentioned. Interestingly, when the fetch plugin is disabled and we use XHR plugin, it gives a CORS error no matter what the URL is. More investigation will be required.

[MilosRasic]

@theodab If you try again with Fetch, it should work with no CORS errors after a couple of attempts. The manifests contain the "beacon" url less often than not. I can probably debug the CORS erros on my own but the thing where I really feel helpless after a couple of days of investigating is the media error we get when there are no CORS errors.

[theodab]

The fact that the fetch plugin is succeeding in situations where the XHR plugin gets a CORS error suggests that one or both of them has some kind of bug in it. They should ideally have the same behavior. Said bug may or may not be related to this issue, however.

[michellezhuogg]

Confirmed the bug. In Chrome, it shows two kinds of error messages, either 'Initialization segment misses expected aac track', or 'MANIFEST.HLS_COULD_NOT_PARSE_SEGMENT_START_TIME'. In Firefox, it shows 'Initialization segment misses expected aac track'.
Further investigation needed.

[michellezhuogg]

Hello @MilosRasic ,
I tried to play the content https://dai1.xumo.com/a7ze70ah55wn6lu4/9999243/master.m3u8 with hls.js, and it's not loading successfully. Could you please confirm that? Thank you!

[MilosRasic]

There are two problems here. One, with Shaka in Chrome failing to start playback, and another one where Fetch API will fail CORS when a manifest includes hls-beacons.xumo.com urls. You need to look at dev tools as well to figure out which of the two if happening, since the stream will not always return hls-beacons.xumo.com before it's stopped by another error.

Without hls-beacons.xumo.com
Chrome: Shaka Error MEDIA.VIDEO_ERROR (4,,CHUNK_DEMUXER_ERROR_APPEND_FAILED: Initialization segment misses expected aac track.)

Firefox: plays fine

With hls-beacons.xumo.com
Chrome: Shaka Error MANIFEST.HLS_COULD_NOT_PARSE_SEGMENT_START_TIME ()

Firefox: Shaka Error MANIFEST.HLS_COULD_NOT_PARSE_SEGMENT_START_TIME ()

hls.js plays fine for me in both browsers: Chrome v73 and Firefox v65

[TheModMaker]

The problem is that your master playlist has a CODECS value with 7 codecs in it. We use this value to determine which codecs are in the streams and so we assume there are 7 streams. So what is probably happening is we are telling the browser that the audio stream has multiple audio tracks in it and the browser rejects it.

The preferred thing is to just list the codecs that are in the streams, like just avc1.64001f,mp4a.40.2. Listing the extra codecs makes it seem like there are more streams than there are. All browsers we've seen can switch between profiles fine so there is no need to list every profile of the codec you use.