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

Hi Simon,

Thank you for the feedback. Some more comments inline.

Le 27/10/2015 08:09, Simon Pieters a écrit :
> 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;
> }
Ok, then given the constraints, if we go in the direction of timed 
styles, that looks like a good approach to start with.
>
>> 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.
According to http://caniuse.com/#feat=style-scoped, the feature is 
removed from Chrome, only available in FF, not planned in IE. This does 
not look like it's a good candidate. One the other hand:
<video>
<track src="subtiles.vtt" kind="subtitles">
<track src="styles.vtt" kind="metadata">
</video>
where the styles.vtt only contains timed STYLE blocks looks more 
promising to me.

Streaming CSS is almost possible today anyway, since the CSS parser 
supports progressive loading, you can deliver CSS chunks at given times. 
The only missing part I think is unloading/removing CSS rules. That 
problem may be overcome by keeping tracks of all styles on all elements 
and expicitely resetting those that are not needed anymore, but that may 
be hard to do.  The advantage of the WebVTT timed STYLES blocks would be 
that timing explictly provided and that, once a style is not active 
anymore, it is removed, as if the rules had not been loaded without 
having to track styles. I don't know how hard this is to implement in 
browsers though.

>> 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?
I'm not a cache expert, you'd have to ask Akamai or others. I am told 
that all the adaptive HTTP Streaming approaches today rely on caching, 
even on live streams. I guess caching the live stream also helps when 
the stream is made ondemand as the caches are already populated.

Cyril


-- 
Cyril Concolato
Multimedia Group / Telecom ParisTech
http://concolato.wp.mines-telecom.fr/
@cconcolato

Received on Wednesday, 28 October 2015 09:01:26 UTC