-
Notifications
You must be signed in to change notification settings - Fork 781
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
Caption files embedded inside the media wrapper should not fail #816
Comments
@johnfoliot what is this "existing API" – do you have any examples or references? Can we even look inside of those media wrappers with client-side Javascript? Also IIRC that rule is returned as "needs review", and can be marked as "not an issue". Not that it solves y/our use case, but it does explain why we don't mark it as a clear violation (it's too hard to tell for certain). |
I believe what you seek can be found here: www.w3.org/TR/media-source.
At this point, it is operating a a level higher than my tech skills allow, but if the right info you seek isn't there, let me know and I can reach out to some folks who may have a clearer indication. |
@johnfoliot Do you have any cases where we've seen this get used? |
As for the false positive, I believe you're right. It looks like both for caption and description we make it needs review if there are no track elements at all, and we fail it if there are track elements but none of them are description (or caption). Given how many ways there are to provide a caption / description, this probably should never fail. At best we can tell that we couldn't figure out where you put it. |
Do not require media captions / descriptions Closes #816 ## Reviewer checks **Required fields, to be filled out by PR reviewer(s)** - [x] Follows the commit message policy, appropriate for next version - [x] Has documentation updated, a DU ticket, or requires no documentation change - [x] Includes new tests, or was unnecessary - [x] Code is reviewed for security by: @JKODU
Wilco, sorry i didn't see your questions earlier... Is this of any use? |
Thanks John. I think we've got it covered :) |
Currently it appears that aXe-core is only looking for the presence of the element to deliver caption files, but there is a second method of doing so: place the h.265 encoded video and the AAC encoded audio AND the Vtt/TTML file all inside of the media wrapper (traditionally either .mp4 or .mkv files).
There is an existing API that "looks inside" the wrapper when being rendered onscreen, which looks for those files to deliver the captioning. Ideally, aXe-core would use a similar method to detect whether the time-stamped file is bundled inside of the media wrapper, as a second test (after checking for the presence of as it does today)
The text was updated successfully, but these errors were encountered: