W3C home > Mailing lists > Public > public-tt@w3.org > May 2014

Re: Liaison response - template on MIME type parameter for TimedText

From: Glenn Adams <glenn@skynav.com>
Date: Sat, 3 May 2014 10:06:15 -0600
Message-ID: <CACQ=j+cf+KV9uxV7yFUXELX1cqRre66-Oc+LkyoVqeh45J6Ntw@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: Michael Dolan <mdolan@newtbt.com>, Timed Text Working Group <public-tt@w3.org>
On Fri, May 2, 2014 at 12:23 PM, David Singer <singer@apple.com> wrote:

>
> On Apr 30, 2014, at 16:40 , Michael Dolan <mdolan@newtbt.com> wrote:
>
> > Nigel, Dave and all-
> >
> > Is there a TTWG Proposal?
> >
> > Would “stpp” be registered somewhere where it would be unambiguous from
> other Codecs strings unrelated to TTML?  I don’t mean the sample entry 4C
> code, but in the Codecs string namespace.  Wouldn’t it have to be
> “application/mp4+stpp….”?  Or why not use “application/ttml+xml” (and
> similar for WebVTT)?
>
> The codecs string starts with the 4CC of the sample entry.  After that,
> whoever defined that 4CC gets to say what’s the next element.  And they get
> to say what’s after that, and so on.
>
> stpp says “some sort of XML”,


since VTT isn't XML, then would it use something different from stpp?


> and is owned by MPEG.  So indeed the step that goes from ‘stpp’ to ‘some
> sort of TTML’ is owned by MPEG, and MPEG still needs to resolve this.
>
> The thrust is that IF MPEG solves that, THEN there will be names to
> identify TTML dialects, that could go next.  So you would see
>
> codecs=stpp.<some MPEG magic to say it is TTML
> happens>.TTMLFULL+IMSC+SDPUS+EBUTT
>

I would expect something more simple, e.g.

stpp.vtt
stpp.ttml.tt1f
stpp.ttml.tt1p
stpp.ttml.tt1t
stpp.ttml.sdpu
stpp.ttml.st10
stpp.ttml.st13

where we have a registry for mapping the third IDs above to TTML profile
designators, e.g.

tt1f -> http://www.w3.org/ns/ttml/dfxp-full
tt1p -> http://www.w3.org/ns/ttml/dfxp-presentation
tt1t -> http://www.w3.org/ns/ttml/dfxp-transformation
tt1u -> http://www.w3.org/ns/ttml/sdp-us
s10f -> http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full
s13f -> http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-full

we definitely do not want to create a new syntax/language for use in codecs
that describes some way to combine profiles; that function is already
defined by the ttml profile definition document syntax




>
> for example.
>
> For the TTWG to say “yes, we’ll take on dialect naming and forming that
> second-level parameter” is important; it then means that if MPEG finds a
> clean solution to the first level, the actual problem in hand is solved.
>  I’d like the MP4 people to realize before the July meeting that this is
> urgent, and come up with ideas and maybe online discussion ASAP.
>
> This is all provisional — on the TTWG getting agreement not only
> internally, but with the partners; and on us all liking the final result,
> of course.
>
> Makes sense?
>
> >
> > I understand how one could signal profiles of TTML that a document
> conformed to concurrently, as in the example – all of TTML and EBU-TT.  But
> the signaling requirements go beyond that – there is often multiple
> namespaces in use in one document that are not, as an aggregate, a single
> “profile”. So, these must be explicitly signaled as well since nearly all
> profiles permit foreign namespaces.  To accommodate this, the “short names”
> have to be defined as “profiles of namespaces” I think.
> >
> > For example, if a document uses the CFF-TT text profile of the TTML Full
> profile, plus SMPTE-TT #608 (US captions), plus CFF-TT metadata, and it was
> compatible with IMSC, SDP-US and EBU-TT, then it might look like:
> Codecs=xxxxx.TTMLFULL+IMSC+SDPUS+EBUTT+CFFT+CFFM+SMPTE608.
> >
> > Regards,
> >                 Mike
> >
> > p.s. I would give the SC29 Secretary a hint about the target of the
> liaison (MPEG v JPEG).  And, you understand you will not receive a reply
> until mid-to-late July, right?
> >
> >
> > From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
> > Sent: Wednesday, April 30, 2014 11:48 AM
> > To: watanabe@itscj.ipsj.or.jp
> > Cc: Timed Text Working Group
> > Subject: Liaison response - template on MIME type parameter for TimedText
> >
> > Dear Mr. Watanabe,
> >
> > Thank you for your liaison N14444 of April 2014.
> >
> > We think that we can indeed find a solution together.  We are looking
> into creating a table of formal "short names" for the profiles of W3C TTML
> and
> > the profiles of formats derived from it (such as SMPTE-TT, EBU-TT, and
> so on).  If MPEG were to propose how to step from the four-character-code of
> > the sample entry (XMLSubtitleSampleEntry and XMLMetaDataSampleEntry) to
> something that identifies "a document compatible with one or more profiles
> of TTML", then we could propose a string composed of a set of one or more
> these short names as the next parameter.
> >
> > For example, say W3C defines two profile short names "W3CTTML" and
> "EBUTTML", and MPEG defines the name "TTML" as referring to the overall
> > family, one might see
> >
> > codecs=stpp.TTML.W3CTTML+EBUTTML,avc1
> >
> > as a codecs string of a file carrying AVC (H.264) and TTML subtitles that
> > are additionally EBU-TT conformant.
> >
> > We would check with those deriving from TTML (e.g. at SMPTE, EBU and
> DECE) if this approach and design are acceptable, before we formalise this.
> >
> > Kind regards,
> >
> > Nigel Megitt, David Singer (chairs, Timed Text Working Group, W3C)
> >
> > --
> >
> > Nigel Megitt
> > Lead Technologist, BBC Technology, Distribution & Archives
> > Telephone: +44 (0)3030807996
> > Internal (Lync): 0807996
> > BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP
> >
> >
> >
> > ----------------------------
> >
> > http://www.bbc.co.uk
> > This e-mail (and any attachments) is confidential and may contain
> personal views which are not the views of the BBC unless specifically
> stated.
> > If you have received it in error, please delete it from your system.
> > Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> > Please note that the BBC monitors e-mails sent or received.
> > Further communication will signify your consent to this.
> >
> > ---------------------
> >
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>
>
Received on Saturday, 3 May 2014 16:07:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:15 UTC