Re: Inband styling (was Re: Evidence of 'Wide Review' needed for VTT)

> Is caching relevant for a live stream?

Very much so.



On 27/10/2015 16:09, "Simon Pieters" <simonp@opera.com> wrote:

>On Thu, 22 Oct 2015 22:40:20 +0900, Cyril Concolato
><cyril.concolato@telecom-paristech.fr> wrote:
>
>> ...
>>
>> By timed styles, I imagine something like:
>>
>> 00:01:00.000 --> 00:02:00.000 type:style
>> .myRedClass {
>>     color: red;
>> }
>> .myGreenClass {
>>     color: green;
>> }
>>
>> 00:01:00.000 --> 00:01:30.000
>> <v.myGreenClass>Some green text
>>
>> 00:01:20.000 --> 00:02:00.000
>> <v.myRedClass>Some red text
>>
>> A cue of with a 'type' settings whose value is 'style' carries style
>> content not text content. This has the advantage of giving precise
>> timing for the styles, and we can force styles to appear in start time
>> order (like cues) and before a cue that has a similar start time. There
>> 
>> are probably problems with the syntax (blank lines in CSS, I did not
>> follow that part of the discussion). Also, if you want to have seekable
>> 
>> streams you probably would have to split cues to remove overlap
>>(nothing  
>> different from normal cues).
>
>A problem syntax-wise is that it would be rendered as a normal cue in
>legacy implementations. It would be better to put something before the
>timings, i.e.:
>
>STYLE 00:01:00.000 --> 00:02:00.000
>.myRedClass {
>     color: red;
>}
>.myGreenClass {
>     color: green;
>}
>
>> Alternatively, I could also imagine something simpler like:
>> 00:01:00.000 --> 00:01:30.000 style:color:green;
>> Some green text
>>
>> 00:01:20.000 --> 00:02:00.000 style:color:red;
>> Some red text
>
>Settings can't use spaces, but CSS requires spaces for lots of things, so
> 
>this doesn't work.
>
>> Maybe this could modified to import styles instead of inlining them, I
>> didn't think about that.
>
>Nope, see  
>https://lists.w3.org/Archives/Public/public-texttracks/2015Oct/0025.html

>
>> Also, as I pointed out in my previous email, such VTT file starts to
>> become a multiplex with styles and content. It may be more appropriate
>> to define a Style stream (maybe using the WebVTT syntax) and to link
>>the  
>> style stream with the content stream, either from the WebVTT content
>> file or from an additional <track> element.
>
>There is a mechanism to point to a stylesheet in HTML already -- e.g.
><video><style scoped>@import ... It doesn't stream, but we don't have
>support for streaming CSS.
>
>>> your only
>>> recourse is to add a new text track at the point where new style is
>>> needed.
>> Without defining timed styles (as above), adding a new text track is an
>> 
>> option, but not the only one, you can use one text track and fill it
>> with cues coming from different WebVTT files. In the HLS approach,
>>every  
>> WebVTT segment would (re-)define its styles. That does not mean you
>>have  
>> to maintain multiple tracks.
>>> This will involve scripts, at which point handling multiple
>>> WebVTT tracks will compare unfavorably with just using a WebSocket
>>> connection to deliver cues and style using a custom syntax.
>> Maybe in some cases the WebSocket approach can be useful, but there are
>> 
>> other issues as well like caching.
>
>Is caching relevant for a live stream?
>
>-- 
>Simon Pieters
>Opera Software
>

Received on Tuesday, 27 October 2015 07:20:10 UTC