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

Parser dropping values from AdaptionSet #119

Open
fedgrant opened this issue Jan 21, 2021 · 9 comments
Open

Parser dropping values from AdaptionSet #119

fedgrant opened this issue Jan 21, 2021 · 9 comments

Comments

@fedgrant
Copy link

fedgrant commented Jan 21, 2021

It looks like the parser is not including certain values. For example, in this AdaptationSet, we are completely dropping the Accessibility tag

<AdaptationSet contentType="video" minWidth="640" maxWidth="1280" minHeight="360" maxHeight="720" segmentAlignment="true" mimeType="video/mp4" startWithSAP="1">
  <ContentProtection schemeIdUri="" value="cenc"/>
  <ContentProtection schemeIdUri=""></ContentProtection>
  <ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
  <Accessibility schemeIdUri="urn:scte:dash:cc:cea-608:2015" value="CC3=spa" id=""/>
  <Accessibility schemeIdUri="urn:scte:dash:cc:cea-608:2015" value="CC1=eng" id=""/>
  <Representation id="" bandwidth="2700000" width="1280" height="720" frameRate="30000/1001" codecs="avc1.64001F">
  <SegmentTemplate media="" initialization="" duration="120120" startNumber="0" timescale="30000"/
</Representation>

I believe its tied to the toM3U8 -

export const formatVideoPlaylist = ({ attributes, segments, sidx }) => {
. Was there a particular reason for dropping these values?

@gkatsev
Copy link
Member

gkatsev commented Jan 22, 2021

We've never parsed them, partially because the output of this project uses the same output as m3u8-parser, so, it's sort of based on HLS. HLS doesn't have a way of mapping the 608 streams into languages/labels.
We should still be parsing out the 608 captions form the video stream in VHS, though.

We definitely should parse the items out.

@BucherTomas
Copy link

We have a use case for this as well, we need to parse Accessibility elements as well to discern audio description tracks from regular tracks.

We need to look for <Accessibility schemeIdUri="urn:tva:metadata:cs:AudioPurposeCS:2007" value="1" />

@MCab93
Copy link

MCab93 commented Feb 21, 2024

Hello, what is status of this issue - is it gonna be implemented ? We need to parse elements of Accessibility tag.
@fedgrant have you managed to get those elements other way ?

@mdwyer-od
Copy link

I have run into the same issue as BucherTomas above, and would appreciate this being implemented :)

@gkatsev
Copy link
Member

gkatsev commented May 6, 2024

So, my initial comment was incorrect and HLS did have the mapping for these. For regular Accessibility tags with 608/708 data, we should be parsing those now via #131

Is there a list of other potential values for the schemeIdUri?

@BucherTomas
Copy link

@gkatsev The existing implementation takes care of embededded CEA captions in video track. However, there are other cases where Accessibility element is useful, namely for specific alternate audio tracks.

Please see:

dashif https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part8-v5.0.0.pdf and chapters 4.2 and 4.3 with schemeIdUri "urn:mpeg:dash:role:2011", i.e. the same as for the Role element.

Dolby https://ott.dolby.com/OnDelKits/AC-4/Dolby_AC-4_Online_Delivery_Kit_1.5/Documentation/Specs/AC4_DASH/help_files/topics/MPEG_dynmc_adpt_strmg_c_mpd_accessibility_ac4.html or
DVB https://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.03.01_60/ts_103285v010301p.pdf Table 5 in chapter 6.1.2. both with schemeIdUri "urn:tva:metadata:cs:AudioPurposeCS:2007" which we want to identify in our own player application logic.

@gkatsev
Copy link
Member

gkatsev commented May 7, 2024

Thanks, @BucherTomas! Do you have or know of any streams that include these elements? Though, the documents have examples, so, that's a good starting place.

If I'm reading it correctly, in the case of urn:mpeg:dash:role:2011, the value can be 1 if present and for urn:tva:metadata:cs:AudioPurposeCS:2007 it's either 1 or 2?

Also, are you using mpd-parser directly or via VHS? Wondering if and how it should be available in VHS and also how these should get marked in the default Video.js UI.

Also, wonder whether HLS has similar properties, maybe via characteristics?

@BucherTomas
Copy link

Do you have or know of any streams that include these elements? Though, the documents have examples, so, that's a good starting place.

Have a look at our simulated test stream https://1798253129.ssl.cdn.cra.cz/POC/ad/advector.ism/.mpd, we are currently trying to use Label elements to discern the audio tracks, but this is just a workaround.

If I'm reading it correctly, in the case of urn:mpeg:dash:role:2011, the value can be 1 if present and for urn:tva:metadata:cs:AudioPurposeCS:2007 it's either 1 or 2?

The way I see it, the values based on dashif specification for "urn:mpeg:dash:role:2011" should be "description", "enhanced-audio-intelligibility" and "emergency" as per table 4.5 in chapter 4.3. Values for "urn:tva:metadata:cs:AudioPurposeCS:2007" are correct.

Also, are you using mpd-parser directly or via VHS? Wondering if and how it should be available in VHS and also how these should get marked in the default Video.js UI.

We just lost our main html5 player developer so I am unable to respond precisely, but from what I remember, he should have been able to leverage mpd-parser directly. On the other hand, we already read output from VHS, too, so both should be usable. With regards to other potential people trying to use this as well, the VHS method seems more accessible to me.

The default Video.js UI can use for mpeg-dash the same approach what it is already doing for HLS. An audio track tagged as one carrying audio description already has an appropriate AD icon in the track selector UI. Quite honestly, I have never seen any production streams based on dashif accessibility specification, so not sure whether unique icons are needed for their three audio accessibility alternatives.

Also, wonder whether HLS has similar properties, maybe via characteristics?

Yes, it is done via the CHARACTERISTICS attribute, video.js is already handling this for HLS. It is mpeg-dash that is a little behind in this aspect.

@gkatsev
Copy link
Member

gkatsev commented May 9, 2024

Thanks! Yeah, I guess we should parse these out and set the appropriate characteristics/values similar to how m3u8-parser does them currently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants