Open evandipietro opened 7 years ago
Are you sure they're not TTML captions? I don't think we made any changes to WebVTT captioning between 2.4.0 and 2.4.1.
@ojw28 My mistake, it is TTML. Updating the issue.
We fixed TTML positioning in 2.4.1 (at least in theory). It's quite possible that your TTML caption files are actually specifying that the captions should be rendered at the top of the screen (or that the implicitly specify this by not specifying something else), and that what the previous behavior was incorrect.
There's nothing we can do to look at this without test content (or at least the TTML part of it).
We also encountered this problem with the ExoPlayer 2.4.1/2.4.2. The subtitles we use do not define the alignment so the subtitles are displayed at the top of the screen. Would it be possible to add a way to change the default position from top to bottom, in case the position isn't defined in the subtitles?
We need to see sample TTML files to investigate this properly.
I extracted a snippet from our ttml stream (and swapped out the texts just in case) and attached it here. My initial investigation suggests that ExoPlayer doesn't support (chained?) referential styling as described by TTML
sidenote: I work with @soutua
@zharf - Yes, that looks like the problem for your case. Thanks for the sample. We should fix that, after which you'll get proper positioning as is defined in your TTML file. @evandipietro - There's no way we can verify whether your case is the same or different without a sample TTML file, so we'll use this issue to track supporting referential styling as in @zharf 's case unless we learn more.
Thanks!
The best short term fix for this is probably to ignore regions that don't directly define origin and extent, which will cause the the captions to go back to being displayed at the bottom again. We currently set default origin and extent in this case, but that results in unexpected behavior when the origin and extent are actually defined in the chained styles that we're not currently resolving. Does that sound sensible?
I'm not fully familiar with how this thing works as of right now but from what I understand it sounds like it could work for now. We can also test any suggested fixes.
I have the same issue so +1
Please could you verify that the above change resolves the issue, up until the point at which we can properly support resolving of chained styles. You can either try on the dev-v2
branch, or cherry-pick the change into release-v2
if you want everything else to stay the same. We may cut a small release picking up a few bug fixes, including this one, if verification is received. Thanks!
@ojw28 I can verify that the fix works in dev-v2
! Will this be released soon?
The fix will be in 2.4.3, which will be released today or early next week. Renaming this issue to track the enhancement of properly supporting referential styling.
Hi Can any one post how to load a TTML subtitle file in EXO
@atkGit, our guide provides useful information. Look for the section "Side-loading a subtitle file".
Hi Santiago , Thanks a lot . We tried and it is working now for external subtitle file (.xml - IMSC1 format) . Is there any way we can load the subtitles embedded in .fmp4/.mp4 containers as well ?
Thanks Ambika
If it's a format we support then it should "just work". When you try playing a sample stream in our demo app, do you see a "Text" button and does it allow enabling the track? If you don't see that then you'll have to provide some sample media, and it'll likely be a feature request to support whatever format you're using.
Also, this is off topic (this issue was closed a long time ago). Please file a new issue.
Issue description
Observed: MP4-Encapsulated TTML subtitles default to top position (with
positionAnchor
defaulting to Float.MIN_VALUE) Expected: Subtitles appear at the bottom of the screen with a valid positionReproduction steps
Using a dash steam w/ MP4-Encapsulated TTML subtitles, enable subtitles. Subtitles appear at the top.
Link to test content
Cannot provide (legal reasons)
Version of ExoPlayer being used
2.4.1 (Was not an issue in 2.4.0)
Device(s) and version(s) of Android being used
Device: FireTV
OS: Fire OS v5.2.4.1 (Android v5.1.1)