New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 662887 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Unable to play CMAF segments

Reported by karishma...@gmail.com, Nov 7 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Example URL:
http://dashif.org/reference/players/javascript/v2.3.0/samples/dash-if-reference-player/index.html

Steps to reproduce the problem:
1. Include CMAF compliant fragments (with multiple moof and mdat in a fragment) in an mpd
2. Chrome throws an error as soon as video inti segment is appended. Including only audio adaptation set works fine
3. Firefox and IE Edge seem to play even video fine

What is the expected behavior?
CMAF fragments should play fine in chrome

What went wrong?
Chrome throws an MEDIA_ERR_SRC_NOT_SUPPORTED  error

Did this work before? No 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes

Chrome version: 54.0.2840.71  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0
 
Cc: chcunningham@chromium.org ddorwin@chromium.org
Components: -Internals>Media Internals>Media>Source
Owner: wolenetz@chromium.org
Status: Assigned (was: Unconfirmed)
@karishma.bagga, can you please specify an mpd or Stream that repros this?
Further to #2, when this occurs, what does chrome://media-internals show for the player involved in the repro (there could be more information in that media log, especially)?
Status: Unconfirmed (was: Assigned)
Labels: Needs-Feedback
Sorry for the delay, here you go
Stream: http://streampoc.mlbcontrol.net/wmay/cmaf/unenc2/dash_manifest.mpd
Player: http://dashif.org/reference/players/javascript/v2.3.0/samples/dash-if-reference-player/index.html

the media-internals log:

00:00:00 74	info    Video codec: avc1.42C01E
00:00:00 74	error	Append: stream parsing failed. Data size=1066 append_window_start=0 append_window_end=inf
00:00:00 76	pipeline_error	chunk demuxer: append failed


Is there something wrong with the ftyp?
Cc: kqyang@chromium.org
Owner: chcunningham@chromium.org
Status: Assigned (was: Unconfirmed)
Repro confirmed. Taking a look
That stream fails to parse because it contains a trex with default_sample_description_index = 0. 

IIUC default_sample_description_index is 1 based, so 0 is not allowed. Does CMAF intend to change this? If not, its probably just an invalid value. 

Cc: wolenetz@chromium.org
@karishma.bagga
I made a workaround patch. (https://chromium-review.googlesource.com/c/chromium/src/+/666346)

The stream seems to be wrong in video encoding.

Comment 13 Deleted

Correcting the ftyp seemed to work (without the patch). Do you think there's something wrong in the encoding apart from that? 
Thanks
I believe our parser doesn't really use the ftyp at this time - just skips over it. I would be surprised if changes to the ftyp alone fixed your issue. Happy to take a look at your latest encoding.

The original error is as described in comment 10. The trex for the subtitles track had a default_sample_descritpion_index = 0. The spec (ISO/IEC 14496-12:2005 Section 8.18.3) describes the range for this type of index as starting at 1, so we give an error for 0.

The workaround CL from Dongheun skips parsing this index. In practice, that works ok since we don't really parse subtitle tracks in mp4 at this time. But we rejected the patch because we aim to avoid accumulating little exceptions to the spec in our parsing code. 
I agree with @chcunningham's opinion.

Removing the subtitle track information(TRAK) that does not use moov of the initial segment seems to solve the issue without patch.

Sign in to add a comment