[Matroska-devel] Storage of WebVTT subtitles in Matroska

[Denis Charmet via Matroska-devel]

Hi,

On 2016-03-14 11:24, Moritz Bunkus via Matroska-devel wrote:
> 3. NOTE blocks between entries
> 
> A comment block ("NOTE …") can appear between subtitle entries (see
> above between example entries 1 and 2). We have to decide whether or
> not we want to keep them when muxing into Matroska. If we do we need
> to store them somehow.
> 
> I defer a proposal until I've mentioned the remaining points.

I'd, personnaly, remove them.

> 4. tags/numbers preceding an entry
> 
> Each entry always has a timestamp line, but that line may be preceded
> by a line containing an entry number (example entry 3) or a free-form
> tag of some kind (example entry 1). Those tags/numbers are irrelevant
> for playback, but they may convey information to a person editing the
> entries.
> 
> We have to decide whether or not we want to keep them when muxing into
> Matroska. If we do we need to store them somehow.
> 
> I defer a proposal until I've mentioned the remaining points.
> 

That's basically useless... I'd remove it too, the less useless stuff 
the decoder/muxer has to handle, the better.

> 
> 5. cue settings
> 
> These are the things listed after the timestamps (example entries 5
> and 6). They are very relevant to playback and must be included,
> either out of band or in band.
> 
> I defer a proposal until I've mentioned the remaining points.
> 

Why not using block additions to store cues? We can consider that style 
is less important than data actual data and let a player treat it if it 
can. This could even allow limited player to reuse their srt decoder to 
support basic styleless webvtt.

> 6. cue timestamps in entries
> 
> Cue timestamps occur within an entry (example entry 7) and tell the
> player to process parts of the entry only at a certain point in
> time. Cue timestamps are absolute, unfortunately, and not relative to
> the start of the entry itself. The example entry 7 contains two parts,
> one that is shown at 3:10, and the second part that's shown five
> seconds later.
> 
> Storing such absolute timestamps in-band makes manipulation at the
> container level (e.g. applying some kind of delays or splitting and
> joining files) very difficult.
> 
> I therefore propose that a muxer MUST change cue timestamps to be
> relative to the start of the entry during muxing and that a demuxer
> MUST change the cue timestamps back to be absolute during demuxing.
> As several other modifications of each entry's content will be
> necessary (see below) this should be OK.
> 

Wouldn't it be easier to just create another block starting with the 
new timestamp and ending with containing block end?

Regards,
-- 
Denis Charmet - TypX
Le mauvais esprit est un art de vivre