Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

XUMO HLS stream fails to play in Chrome #1817

Closed
MilosRasic opened this issue Feb 21, 2019 · 7 comments
Closed

XUMO HLS stream fails to play in Chrome #1817

MilosRasic opened this issue Feb 21, 2019 · 7 comments
Assignees
@TheModMaker
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone
v2.5

Comments

@MilosRasic
Copy link
Contributor

MilosRasic commented Feb 21, 2019 •
edited
Loading

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
Copy link
Contributor

theodab commented Feb 21, 2019

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.

@theodab theodab added type: bug Something isn't working correctly and removed needs triage labels Feb 21, 2019
@MilosRasic
Copy link
Contributor Author

@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.

@shaka-bot shaka-bot added this to the v2.5 milestone Feb 21, 2019
@theodab
Copy link
Contributor

theodab commented Feb 21, 2019

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

MilosRasic commented Mar 15, 2019 •
edited
Loading

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
Copy link
Contributor

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.

@TheModMaker TheModMaker self-assigned this Apr 24, 2019
@shaka-project shaka-project locked and limited conversation to collaborators Jun 28, 2019
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@TheModMaker TheModMaker

Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Milestone
v2.5
Development

No branches or pull requests
5 participants
@MilosRasic @TheModMaker @shaka-bot @theodab @michellezhuogg