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.

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

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

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