- From: David Singer <singer@apple.com>
- Date: Wed, 21 Oct 2015 15:54:38 +0200
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Philip Jägenstedt <philipj@opera.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>, "public-texttracks@w3.org" <public-texttracks@w3.org>
> On Oct 21, 2015, at 15:37 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: > > On 21/10/2015 14:00, "singer@apple.com on behalf of David Singer" > <singer@apple.com> wrote: > >> >> No, it’s not hypothetical. DASH/MP4/VTT relies on this, and it was (and >> is) seen as a core advantage of VTT over TTML. > > How curious. Live streaming with DASH/MP4/TTML works splendidly - there > were lots of implementations on show at IBC in September, of both coders > and presentation systems, based on EBU-TT-D, which is the profile of TTML > that is specified for HbbTV 2.0 and the DVB DASH profile. The dash.js > player is one. Samsung had a prototype television that was decoding and > presenting this format too - I'm pretty sure that there are others in the > works. The BBC has prototyped an implementation built on gstreamer that > works well also. > > What advantage was identified with VTT in this scenario? Flexible granularity is one. Live streaming of TTML means short TTML documents each of which describe a time interval. This means your segment size is basically that, or a multiple of it, and that is also then your minimum latency. David Singer Manager, Software Standards, Apple Inc.
Received on Wednesday, 21 October 2015 13:55:10 UTC