-
Notifications
You must be signed in to change notification settings - Fork 626
Add SUPPLEMENTAL-CODECS support in both DASH and HLS #1785
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
Merged
copybara-service
merged 6 commits into
androidx:main
from
DolbyLaboratories:dlb/dovi-supplemental-codecs/dev
Jan 7, 2025
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
b650119
Merge pull request #10 from androidx/main
ybai001 79078c3
Add SUPPLEMENTAL-CODECS support in both DASH and HLS
ybai001 c18c6b3
Remove the modification on Format
ybai001 e8d29dc
Remove redundant blank line
ybai001 545d37c
Fix two bugs in the updated code
ybai001 1ac847a
Update code according to review result
ybai001 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain why we need this special DV check here? It looks like the check above (L1185-1192) already achieves the same goal unless there are multiple video codecs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of this special check is to update codecs with manifest codec info. For my test stream,
manifestFormat.codecs = "dvhe.08.01" while codecs = "hev1.08.01" before this special handling. (So that L1185 is false and corresponding logic is not touched.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Does this happen because the extractor doesn't know this is a DV format? For MP4 containers for example I'd assume they have a
dvcC
ordvvC
, which should results in theformat.codecs
already populated with the expected values.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During the fmp4 paring, the parser finds the 'dvcc' or 'dvvc' box here, and corresponding codec string is updated in DolbyVisionConfig::parse(). After tracking the history of this file, I finally found this one. The author was Dolby engineer but is Google engineer now. :)
I'm not sure whether there is any side effect on codec selection if I change the logic (e.g. from hev1 to dvhe). My understanding is OK since there is a method to handle the case (A non Dolby Vision licensed device to play Dolby Vision content.) But I didn't do a full testing.
Do you want to change the logic in DolbyVisionConfig::parse()? or using a new pull request to do that? At least, I need to provide a new PR for profile 10 handling in that method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we assume the dvcc' or 'dvvc' box is always there and we should always be able to tell from the actual media container which Dolby Vision codec we have? If so, I think it's better to fix the logic in DolbyVisionConfig::parse() and not make the change in
Format.withManifestFormatInfo
.The reason for that is that
withManifestFormatInfo
merges information from the actual media files and the manifest. In some cases like labels and language it's generally better to rely on the manifest. In other cases like codecs, it's usually better to rely on the actual media file as it's more likely to get it right (or has more details) than the manifest in case there are any differences. So if we can be certain that the dvcc' or 'dvvc' boxes always exist for a Dolby Vision stream (and we fix our util method to set the right codec strings for all profiles), then it seems better to rely on this logic.That seems like a separate change and I think it's easier if I continue to merge the current pull request as it is and we can look at the other change separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. I think there is always a Dolby Vision box (dvcc or dvvc) to indicate the codec info. I need to double confirm it.
I'll submit a new pull request after this one is merged. Is it fine for you?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked the latest spec today.
• For profiles less than or equal to 7: dvcC
• For profiles 8 to 10: dvvC
• For profile 11 to 19: dvwC
• For profile 20: dvcC
• For profiles greater than 20: dvwC
Currently, we just need to support profile 4/5/7/8/9/10 and potentially support profile 20 so that there is always a 'dvcC' or 'dvvC' box exist.