DASH manifest without segmentInfo

[aptly-io]

I'm faced with the play-back of crippled DASH manifests: it misses segment info. dashif.org handles this case by fetching the sidx boxes from its associated media containers.
From #765 I understand and agree completely that its owners prefer not to make additional network requests?
Still would a PR that implements this be accepted? Would such implementation eventually end up in the CAF receiver?

Have you read the FAQ and checked for duplicate issues: Yes, relevant for this discussion #765
What version of Shaka Player are you using: 2.2.4
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: demo/cast_receiver
If custom app, can you reproduce the issue using our demo app: Yes
What browser and OS are you using: chromecast
What are the manifest and license server URIs: in-house
What did you do? load crippled DASH manifest
What did you expect to happen?
Extracting segment info from the media container's sidx boxes.

What actually happened?
It stopped prematurely saying it needs hard segment stuff from the manifest: segmentList, segmentTimeline or segmentBase info

[joeyparrish]

We do not support DASH manifests without any index info. We do support SIDX parsing to get the index, but the manifest needs to at least indicate the byte range of the SIDX box (using SegmentBase indexRange="...").

In my opinion, these so-called "crippled" DASH manifests are not reasonable from the perspective of a JavaScript application. If your encoder vendor produces crippled DASH manifests, you should file a support request to ask them to fix their product. I would be happy to assist you in that if you wish.

[aptly-io]

@joeyparrish Sorry to come back at this closed issue. I've prototyped a working solution that extracts all sidx information from the media files listed in the MPD. The solution also determines the initial segment's start and end. Supporting the latter is a ugly. I'm seeking advice for a more elegant solution that I might have overlooked ...

The segment handling code returns a shaka.dash.DashParser.StreamInfo from its createStream(). This object contains the initSegmentReference object of type shaka.media.InitSegmentReference with an const startByte and const endByte. At the time that StreamInfo is created and returned, these start and end are unknown: set to 0. (the createSegmentIndex promise is not yet resolved).

After parsing all sidx boxes, also the actual start & end of the init segment is known; only now the start and end inside the InitSegmentReference is updated. I had to drop the const because of this to make the closure compiler happy. Therefore I wonder; would there be a more elegant solution to update these values inside the initSegmentReference?

Note: it's impossible for me (even with your assistance :-) to have the content creation department to update their many legacy and future MPD; it's like another company that I've no access to (like climbing over 100 Mount Everest's) . I (and customers) have just have to live with the sub-optimal crippled MPD situation.

Thanks.

[joeyparrish]

@aptly-io, we can definitely drop the constness of those properties if it's helpful.

You may want to look at these two recent changes we made for HLS which may be helpful:

"Make partial segment requests in HLS parser": a93455a
This shows how you can request a partial segment for faster startup, in case you haven't done this yet in your fork.

"Fix HLS playback where moof box is larger than 1k": 88857c5
This shows a new feature we added to the MP4 parser so that you can parse buffers which contain partial MP4 boxes.

Does your work on this so far include WebM? Or just MP4?

Are you interested in sending a pull request?

[aptly-io]

@joeyparrish Thank you for the feedback!

Yes, I saw your approach for parsing partial mp4 boxes with the stop_ flag to prevent running into BUFFER_READ_OUT_OF_BOUNDS; will adopt this (I was returning false from a new boxHeader(call-back) to halt further parsing/reading).

The content is MP4 (with h264, AAC and TTML-TXT or PNG inside).

I see clear benefits from creating a pull request. I need to check with superiors (dev. time constraints and getting over the CLA are huge).