Fix VTTRegion support

[avelad]

Have you read the FAQ and checked for duplicate issues: Yes

What version of Shaka Player are you using: 2.2.8

Can you reproduce the issue with our latest release version: Yes

Can you reproduce the issue with the latest code from master: Yes

Are you using the demo app or your own custom app: demo app

What browser and OS are you using: Chrome 63, Ubuntu 17.10

What did you do? Load Angel One and enable the subtitles

What did you expect to happen? Subtitles are shown correctly

What actually happened?

[joeyparrish]

I am also using Chrome 63 on Linux, but I do not see the same results as you. For me, the subtitles are at the bottom, as they should be. Are you seeing this consistently across machines and OSes? Is it possible that you have some customized style sheet for cues installed in the browser?

[avelad]

It's very strange, with other pages work (using native text track)

[avelad]

In Firefox & Opera work as expected in the same machine.

[joeyparrish]

Very strange. We are using a native TextTrack as well, but instead of setting src='sub.vtt', we are using the addCue() API on the TextTrack. It's not clear to me why it would display differently on your Linux machine than mine, with the same browser & version.

Do you have any extensions installed which could be affecting it? Do you get the same results in incognito mode?

[avelad]

It is something related to my browser.

[joeyparrish]

@avelad, can you please share what the cause of the issue was? I'm sure this could be useful to others in the future if they run into similar symptoms.

[avelad]

I reset all experiments in chrome://flags/, and now it works!

[joeyparrish]

Interesting. I would like to figure out what flag it is. It could be a bug in some experimental thing in Chrome, or it could be a bug in Shaka Player that is only activated by some future-looking feature.

[joeyparrish]

With "experimental web platform features" turned on, we get an implementation of VTTRegion. This is the root cause of your issue.

I don't yet know if it's VTTRegion itself which is broken or if we are using it incorrectly.

[joeyparrish]

There are several things about our use of this upcoming region feature that are wrong. We will push a quick fix for v2.3 that disables region-related functionality until it can be verified against this experimental implementation in Chrome.

[joeyparrish]

Issues remaining for v2.4:

• TTML regions are specified in px
• VTT regions are in percentage of the video frame
• VTT regions are not being parsed yet
• Shaka Cue interface is in percentage
• VTTRegion web API is in percentage
• Our use of VTTRegion is out-of-date with regard to the spec and may be wrong in other ways
• None of this is well-tested

To support both VTT and TTML input, the Shaka Cue interface needs to be able to represent both px and percentage values. The TextDisplayer needs to be able to render either. SimpleTextDisplayer, which uses VTTCue and VTTRegion web APIs, should convert px to percentage to get the browser to render the region correctly.

[kocoten1992]

hope this help, https://github.com/mozilla/vtt.js

[joeyparrish]

We have removed our broken usage of VTTRegion so that the apps of today won't break on the Chrome of tomorrow. This change will be in v2.2.9 and v2.3.0. We will try to fix VTTRegion support in the default TextDisplayer for v2.4.

[nigelmegitt]

TTML regions are specified in px

@joeyparrish In general (dependent on profile), TTML regions can be specified in other units too - percentages are very common, being percentage of the "root container region" which is usually aligned to something related to the video, like the decoded video image area or the viewport.

It is also common to require that the root container region's extent in pixels is specified on the tt element if pixel units are used which means that any pixel values can be converted simply to percentages. IMSC requires this. EBU-TT-D prohibits use of px units altogether.

[avelad]

Hi @ismena , I tested your commit and I found it:

Stream: https://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestARD.mpd

[joeyparrish]

@avelad, although that looks odd, it's not clear to me if this is the expected result or not. Can you please clarify?

[avelad]

@joeyparrish, for me it a unexpected result.

This is the ttml with the region:

<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tt="http://www.w3.org/ns/ttml" xmlns:ttm="http://www.w3.org/ns/ttml#metadata" xmlns:tts="http://www.w3.org/ns/ttml#styling" xmlns:ttp="http://www.w3.org/ns/ttml#parameter" xmlns:ebutts="urn:ebu:tt:style" xmlns:ebuttm="urn:ebu:tt:metadata" xml:lang="" ttp:timeBase="media">
  <head>
    <metadata>
      <ebuttm:documentMetadata>
        <ebuttm:conformsToStandard>urn:ebu:tt:distribution:2014-01</ebuttm:conformsToStandard>
      </ebuttm:documentMetadata>
    </metadata>
    <styling>
      <style xml:id="Style0_27" tts:fontFamily="proportionalSansSerif" tts:backgroundColor="#00000099" tts:color="#FFFFFF" tts:fontSize="100%" tts:lineHeight="normal" ebutts:linePadding="0.5c" />
      <style xml:id="textAlignment_27" tts:textAlign="center" />
    </styling>
    <layout>
      <region xml:id="Region" tts:origin="10% 10%" tts:extent="80% 80%" tts:displayAlign="after" />
    </layout>
  </head>
  <body>
    <div>
      <p region="Region" style="textAlignment_27" begin="93:06:29.180" end="93:06:30.140" xml:id="sub_0">
        <span style="Style0_27">Und der Kartoffelsalat</span>
        <br />
        <span style="Style0_27">ganz fangfrisch.</span>
      </p>
    </div>
  </body>
</tt>

I can reproduce it with https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=https://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestARD.mpd;lang=es-es;build=uncompiled and Chrome 64 in Ubuntu 17.04

[joeyparrish]

Okay. I'll reopen and we will take a look. Thanks!

[joeyparrish]

The region origin is "10%, 10%", and the extent is "80%, 80%", which is what the screenshot looks like: it starts close to the top-left corner (10% in) and takes up 80% of the width (stops 10% from the right).

@avelad, why is this wrong? What should it look like instead?

[avelad]

tts:origin="10% 10%" is working as expected tts:extent="80% 80%" is working as expected with the width but the height is not 80% (see https://www.w3.org/TR/ttml1/#style-attribute-extent ) tts:displayAlign="after" is wrong (see https://www.w3.org/TR/ttml1/#style-attribute-displayAlign ) Why is the region black?

[joeyparrish]

Height is not working as expected because we have to specify it to the browser in terms of lines. See the VTTRegion interface, which is the only API for this available in the browser. I filed https://github.com/google/shaka-player/issues/1290 to discuss ways to improve this, if possible.

The background is black because we aren't extracting the background style from TTML, not manipulating the CSS for the cue region. I filed https://github.com/google/shaka-player/issues/1289 for style support.

Translation of TTML to VTTCue+VTTRegion is not perfect, and it likely never will be. You may want to consider writing your own TextDisplayer plugin, which will allow you to render the cues yourself, rather than relying on the browser APIs for this.

I filed those two new issues for further enhancements, so I will go ahead and close this issue again. We have fixed what was originally broken in our previous VTTRegion code. Thanks!

[avelad]

VTTRegion is enabled with chrome://flags/#enable-experimental-web-platform-features after investigate, I think that the issue with the background color is a Chrome issue. I tested with: `video::cue { background: transparent; }

video::cue-region { background: transparent; }` and I doesn't work.

[joeyparrish]

Ah, okay. If you file a Chrome bug about that, please link to it on #1289 (cue style support).

[joeyparrish]

This feature will be out in v2.4 this week.