-
Notifications
You must be signed in to change notification settings - Fork 31
feat(OPTIP-303): bridge inBandMetadataTrackDispatchType to React Native #833
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
tvanlaerhoven
merged 4 commits into
develop
from
feature/OPTIP-303-bridge-inBandMetadataTrackDispatchType
Jun 18, 2026
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
08beeff
feat(OPTIP-303): bridge inBandMetadataTrackDispatchType to React Native
devin-ai-integration[bot] 3f70ed8
feat(OPTIP-303): add inBandMetadataTrackDispatchType to fromNativeTex…
danieldallos-dolby d55fafb
feat(OPTIP-303): default inBandMetadataTrackDispatchType to empty str…
danieldallos-dolby f9a04d8
feat(OPTIP-303): default inBandMetadataTrackDispatchType to empty str…
danieldallos-dolby 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
Oops, something went wrong.
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.
This class also aggregates TextTracks from sideloaded metadata (not supported on native iOS player) which are handled by the iOS bridge (function: aggregatedMetadataAndChapterTrackInfo())
Should we also add the property there?
The iOS API is not very clear on the usage:
/** The text track in-band metadata track dispatch type of the text track that the TextTrack object represents. */
It's just a string, so what could these be?
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.
Good question. I'd say no —
aggregatedMetadataAndChapterTrackInfo()constructs entries fromTextTrackDescription(sideloaded WebVTT files), which are out-of-band by definition.inBandMetadataTrackDispatchTypeis specifically about metadata embedded within the stream (DASH EventStream, HLS ID3, CMAF emsg, etc.), so it wouldn't apply to sideloaded tracks — andTextTrackDescriptiondoesn't expose this property.As for what the values can be: it originates from the W3C MSE spec. Typical values are scheme URIs or type identifiers that disambiguate in-band metadata tracks — e.g. an EventStream
schemeIdUriin DASH, or an ID3 metadata type in HLS. The native SDK passes it through as an opaque string so consumers can identify which kind of in-band metadata a track carries.Happy to add it there too if you disagree, but I think leaving sideloaded tracks without it is correct.
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.
Just wanted to make sure the bridging of the property works fine. It's not optional on the Typescript side.
I'm adding it to the fromNativeTextTrack TrackUtil and will set the value explicitely to "" on the metadata track aggregation
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.
Good catch on the non-optional TS type. Since on Android we already guard with
?.let(so the key is omitted when null), and on iOS native it can also be nil, an alternative would be to make the TS property optional:readonly inBandMetadataTrackDispatchType?: string. That would match the native nullability and avoid needing to set""explicitly for sideloaded tracks.Happy to make that change here if you'd prefer, or leave it as-is if you'd rather default to
""on the sideloaded path. Let me know which approach you prefer.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.
@Danesz what do you prefer?
Note: I think we should at least add the property to fromNativeTextTrack in TrackUtils.ts?
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.
You're right about
TrackUtils.ts— I missed adding it tofromNativeTextTrack. The destructuring on line 44 and the return object needinBandMetadataTrackDispatchTypeas well. I'll add it once you and @Danesz decide on optional vs non-optional.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.
On the iOS SDK the property is not nullable?
On web either?
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.
You're right — it's non-optional on both iOS and web native SDKs. My suggestion about making it optional was wrong. Keeping it as
string(non-optional) is correct, and defaulting to""for sideloaded tracks makes sense.I'll go ahead and add it to
fromNativeTextTrackinTrackUtils.tsnow.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'm missing the defaulting to "" for sideloaded tracks in the commit
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.
Added in d55fafb —
track[PROP_IN_BAND_METADATA_TRACK_DISPATCH_TYPE] = ""inaggregatedMetadataAndChapterTrackInfo()for sideloaded tracks.