Support self-initializing single-segment media in DASH

[seventhmoon]

Since Lollipop, HEVC/H.265 is supported in OS.

Is Exoplayer support HEVC/H.265 over DASH?
I tried the test stream from http://dashif.org/test-vectors/#MRMR_HEVC (e.g. http://dash.edgesuite.net/dash264/TestCasesHEVC/2a/1/TOS_OnDemand_HEVC_MultiRes.mpd) but I got the following error

com.google.android.exoplayer.demo E/LoadTask﹕ Unexpected exception loading stream
java.lang.NullPointerException: Attempt to read from field 'int com.google.android.exoplayer.extractor.mp4.DefaultSampleValues.sampleDescriptionIndex' on a null object reference
at com.google.android.exoplayer.extractor.mp4.FragmentedMp4Extractor.parseTfhd(FragmentedMp4Extractor.java:389)

[andrewlewis]

The dev branch has support for H.265/HEVC. However, that test stream does not play because its manifest does not contain initialization segments, and the player doesn't find a media format. If I modify it to include an initialization segment it plays back fine.

[Zo2m4bie]

@andrewlewis Can you share your code how to modify initialization segments to play HEVC?

[andrewlewis]

The manifest linked to in this issue does not have an initialization segment for video. To play it, I looked at one of the video representations, found where the initialization data was and manually added the byte range in an Initialization element in the associated SegmentBase element in the manifest. Normally you shouldn't need to do this, as the tool generating the manifest should output the required element.

The issue is not really specific to HEVC/H.265 and could equally apply with another format.

[waqarz]

@andrewlewis if there is an issue with http://dashif.org/test-vectors/#MRMR_HEVC or the vector http://dash.edgesuite.net/dash264/TestCasesHEVC/2a/1/TOS_OnDemand_HEVC_MultiRes.mpd please report here: https://github.com/Dash-Industry-Forum/Test-Vectors/issues

The MPD mentioned above is on-demand DASH content with self-initializing segments, hence initialization information is not needed separately. I currently don't see any conformance issues with the vector.

[andrewlewis]

Yeah, it looks like this stream conforms to the spec, but we don't currently support streams where the manifest doesn't include initialization data.

[ojw28]

@waqarz - This is pretty unusual media. One of the properties of sensible delivery via DASH is that the client shouldn't need to make unbounded range requests into arbitrarily large pieces of data.

Self-initializing segments are normally used in the case where the media consists of many small segments (e.g. defined with a timeline in the manifest). A client may need to make unbounded range requests, but only ever to retrieve small amounts of data (e.g. to obtain a ~5 second duration self-initializing segment). ExoPlayer already supports this.

In the case of the mpd in this issue, the whole media is a single segment. To satisfy the property of sensible delivery defined above, the client needs to be able to make bounded requests for initialization and index data. Having obtained this data, it then makes subsequent bounded requests for sub-segments based on the sidx box. The problem is that this mpd doesn't define the initialization range (for video only; it's there for audio!?). To get the initialization data a client would therefore need to make an unbounded range request into the arbitrarily large single segment and keep reading until it encounters what it's looking for.

Admittedly the sample does seem technically valid according to the spec, but that doesn't mean it's "sensible". In all such cases it's trivial to include the initialization range in the mpd, and doing so allows clients to operate more efficiently. Hence I'd consider it a bug, practically speaking, if I ran or used a production system where media is single-segment and the initialization range is omitted.

Question: Was it just a mistake/omission that the ranges are missing for the test vector manifests, or were they deliberately designed in this way to test an edge case that I don't think any production system should be hitting, or do you disagree with my reasoning above?

Thanks!

[waqarz]

@ojw28 Although I don't see this as a major issue (e.g. index is not allowed in init, so the index byte range already gives the clue for init), but I am not building clients either; the good places to report and discuss this is DASH-IF. If industry would like to mandate init range then it should go into the spec. Its only the Spec (DASH or another interoperability document) that define what bugs are.

[ojw28]

The initialization data could in theory be right at the very end of the file, correct? Or is there a requirement somewhere in the BMFF spec that the moov has to come before the sidx and/or any mdat atoms?

[waqarz]

Perhaps it can be, the ISO BMFF spec says that moov is not required to be at a specific position.

[ojw28]

I think we can close this. I've filed Dash-Industry-Forum/Test-Vectors#66 for the test vectors to be updated to something that better reflects what clients will actually need to handle.