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.

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

DASH manifest without segmentInfo #1088

Closed
aptly-io opened this issue Oct 26, 2017 · 4 comments
Closed

DASH manifest without segmentInfo #1088

aptly-io opened this issue Oct 26, 2017 · 4 comments
Labels
status: archived Archived and locked; will not be updated status: will not implement The team chooses not to implement this enhancement

Comments

@aptly-io
Copy link

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

@theodab theodab added needs triage type: enhancement New feature or request and removed needs triage labels Oct 26, 2017
@joeyparrish joeyparrish added status: will not implement The team chooses not to implement this enhancement and removed type: enhancement New feature or request labels Oct 26, 2017
@joeyparrish
Copy link
Member

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

@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
Copy link
Member

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

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

@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@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.
Labels
status: archived Archived and locked; will not be updated status: will not implement The team chooses not to implement this enhancement
4 participants