-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Improve TTML caption rendering #1080
Comments
Text display is currently handled by the browser or the application. Browsers do not currently support regions, but we do parse them and make the information available to text display plugins. Adding this to the backlog. We will consider a complete DOM-based implementation of TextDisplayer. |
In the mean time, feel free to write your own plugin for this. We would be happy to review a pull request if you decide to work on this. |
@joeyparrish Thanks for the feedback. Is the following possible for a plug-in to:
At each callback, the TTML plugin would draw the subtitle/captions in the target rendering DOM element. |
It's not a TTML plugin, but rather a text display plugin. It receivers cues which it is responsible for rendering. Here's the interface documentation: https://shaka-player-demo.appspot.com/docs/api/shakaExtern.TextDisplayer.html Here's the documentation for the cue objects: https://shaka-player-demo.appspot.com/docs/api/shaka.text.Cue.html This system is more general than TTML. It will be used by the player for all subtitle/caption rendering, regardless of the input format. You can pass whatever state you want into the constructor or into additional methods you have on your class. |
Ok. Thanks for the details. As I understand it,
Is that right? If so, what happens if the current I am thinking the media track parser could return a TTML cue that implements the current interface (for minimal compatibility) but also contains the information (as private members) needed to fully render the TTML cue. Would that work? Thanks for your help. Happy to continue the discussion offline. Feel free to DM me at pal@sandflow.com. |
The The exact |
TTML supports capabilities beyond what
Couple of options:
imscJS can readily support the second and third options. Thoughts? |
Makes sense to allow the Some approach like that will be required to support TTML properly since it allows style attributes to be specified on spans within what are considered "cues" here. |
First, let me address using imscJS for TTML support: Our current TTML parser, limited though it may be, compiles to about 7,939 bytes. imscJS + its sax dependency is 159,787 bytes. That's a 20x increase in size for the TTML parser itself. Shaka Player as a whole is currently 185,141 bytes (in my working directory, anyway), so adding imscJS + sax would be an 86% increase in the size of Shaka Player itself. That is way too big for a built-in subtitle parser. If you want to use imscJS to handle TTML, you can always have a text-parsing plugin at the application level which replaces our default TTML parser. See the API docs on TextParser if you want to pursue that: https://shaka-player-demo.appspot.com/docs/api/shakaExtern.TextParser.html As for enriching our existing TTML parser, I'm completely open to that. But since it sounds like our Thanks! |
Seems a reasonable approach: have the application provide text parser and cue renderer implementations, e.g. using imscJS. Perhaps a simple example is all that is required. |
@joeyparrish P.S.: I very much appreciate your taking the time to explore these various options. |
This issue is quite old, and our TTML and rendering capabilities have grown a lot. If there are still gaps in our support of TTML parsing or rendering, please feel free to open new issues for them. Thanks! |
The captions in the following MPD should be presented in a region that starts 30% for the left and ends 10% to the right, and the font size should be 1/30 of the height of the video.
https://palemieux.com/public/foms2017/CEP150_512kb.mpd
Happy to provide additional information.
P.S.: consider using the W3C IMSC1 test suite to validate IMSC1 rendering, or using the imscJS polyfill, which is also used by dash.js.
The text was updated successfully, but these errors were encountered: