Re: A new proposal for how to deal with text track cues

On 16 Jun 2013 06:29, "David Ronca" <dronca@netflix.com> wrote:
>
> > They buy the formats that they need and as long as they publish to TV
> > & Film - not the Web - they don't need WebVTT.
>
> Our client spec mandates TTML support (a Netflix profile), and is
> unlikely to change.  For ingest, our preferred format is SMPTE-TT
> (profile restrictions in development).  I believe that the momentum is
> behind TTML (due in part to the FCC safe-harbor clause for SMPTE-TT).

Indeed - there was some strong lobbying going on at the FCC to make this
happen so this is your problem now.

> I guess tool vendors will support WebVTT, but the large use case will
> be converting TTML to WebVTT in order to deliver to one of the few
> companies that will require WebVTT.  I don't expect much authoring to
> be done in WebVTT.  Just my two cents.

WebVTT is created for everyone on the Web. If you don't use it , that's not
WebVTT's problem.

If however your statement implies that this group should ignore WebVTT
because it's not relevant to this group, then that's a fair statement and
I'll go away and stop bothering this group.

Regard,
Silvia.

>
> David
>
> >
> > On Sat, Jun 15, 2013 at 3:17 AM, Silvia Pfeiffer
> > <silviapfeiffer1@gmail.com> wrote:
> >> On Fri, Jun 14, 2013 at 9:37 PM, John Birch <
John.Birch@screensystems.tv> wrote:
> >>> Hi Silvia,
> >>>
> >>> Thanks for your email... I've commented in-line below. (>>)
> >>>
> >>> As I state below, please do not misunderstand, I am not against the
implementation of another subtitle / caption *output* format. I am
concerned however about an output format that seeks to 'gloss over' the
potential inadequacies of the caption / subtitle authoring. Captions and
subtitles should never be considered 'second rate' ancillary content that
can be fixed up by a 'clever' browser. For accessibility there is a clear
ethical desire to have the best authored content. For translation, (where
as much as 90% of the audience may need a quality translation experience)
the commercial driver for high quality subtitles is even more important.
Garbage in , garbage out. My primary concern with WebVTT is that far too
much attention is being paid to supporting a 'garbage in' mentality.
> >>
> >>
> >> I think you're still misunderstanding what WebVTT does. If a file is
> >> of high quality and captions/subtitles are authored as to a high
> >> standard (as I would expect from commercial entities), and the video
> >> is being displayed at a sufficient size to display the authored
> >> content as intended, the rendering algorithm will not do any, as you
> >> call it, 'fix up'.
> >>
> >> However, the browser has to do something when a line of text has to be
> >> wrapped because the video's width is too small to render the text.
> >> Also, the current spec will - in the unlikely event that several cues
> >> are rendered at the same time and have been poorly authored to overlap
> >> each other - try to move the cues slighly to make the text not
> >> overlap. These are the only two situations in which the WebVTT
> >> rendering algorithm will make any changes to the positioning of the
> >> text.
> >>
> >> Also, you might want to talk with the people at YouTube that have to
> >> deal with a lot of garbage captions that they are getting as input,
> >> but they still manage to extract a lot of good quality captions out of
> >> them, so your "garbage in - garbage out" argument wouldn't hold for
> >> YouTube. Note, however, that YouTube does a lot more than what we have
> >> codified into the WebVTT rendering algorithm.
> >>
> >>
> >>>>>TTML is a **markup** language. It is intended to contain the
necessary structure to convey the intention of an author as to how text
should appear timed against external content. It does NOT define a specific
rendering implementation, the referenced rendering aspect is illustrative
of the specification, and any rendering implementation is permitted.
> >>
> >> When defining a markup language, but not defining the means of
> >> rendering, you allow rendering devices the freedom to interpret the
> >> markup differently, thus leading to different visual experiences.
> >> Surely that is not the a good thing.
> >>
> >>
> >>>>>This has been the case since inception (over 10 years). It has been
unequivocal how TTML should be interpreted, (barring a few corner cases
that are well documented and will be resolved in the next edition).
> >>
> >> WebVTT is in the same position - we're also sorting out some corner
cases.
> >>
> >>
> >>>>> BTW. SMPTE-TT has more to say about practical rendering
implementations in the captioning sense than TTML. For many of the use
cases that TTML was intended, it is much further along than WebVTT.
> >>
> >> Can you point out which use cases TTML is ahead of WebVTT? I'd like to
> >> understand what shortcomings there are so we can make sure to cover
> >> all use cases, or clarify any misunderstandings.
> >>
> >>
> >>>>> I stand by my ("half-finished strawman") statement. I have followed
the public **incremental** development of the WebVTT standard.
> >>
> >> That's how all standards are written.
> >>
> >>
> >>>>> I have had no inclination to attempt implementation against a
moving target. All formats do not evolve to support more features. The
better the requirements analysis and scoping phase is, the less radical
evolution is required in the specification. Writing the spec should be the
easy part - working out what to put in it is the difficult trick. By
comparison to WebVTT, TTML had a long gestation, but the published standard
was IMHO clearer and has certainly not evolved so much since publication.
> >>
> >>  You might want to check back with the beginnings of TTML to an email
> >> about "Iterating toward a solution":
> >> http://lists.w3.org/Archives/Public/public-tt/2003Feb/0039.html . That
> >> was in February 2003 - and TTML is still fixing bugs. That's
> >> continuous incremental improvement and it's the norm with all
> >> specifications that continue to be in active use and adapt to reality,
> >> which is a good thing.
> >>
> >>
> >>
> >>>>> I don't disagree. But my comment was more about why it seemed
necessary to develop a standard that effectively contests some of the same
space as TTML? Especially when TTML was already well formed and published
at the time that WebVTT was conceived? If WebVTT had been positioned and
defined as a rendering environment for TTML (which is now being discussed)
we would not be having this discussion.
> >>
> >> I'm not going there - that was a decision of the browsers that made
> >> after looking at TTML. It's history and we can't change it any more.
> >>
> >>
> >>> You may have missed that there is an actual spec for this:
> >>>
https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
> >>> Other conversions are planned, but have not been required yet.
> >>>
> >>>>> I must have missed the announcement last week! ;-) BTW, from an
admittedly cursory look I have reservations about mapping 608 row positions
to (recurring) fractional percentages. The potential problems this can
create is one of the reasons why the TTML standard includes a cell
positioning concept.
> >>
> >> It has been around for at least a year and I've been pointing people
> >> toward it. The fractional percentage is simply the outcome of
> >> converting the CEA608 columns to exact percentages on the video.
> >>
> >>
> >>>> There does not seem to be a huge awareness of the role of a
professional captioner or subtitler. Or of the role of commercial
subtitling and captioning organisations, or of the existence of (internal)
quality standards for caption / subtitling services that are adopted
(insisted upon) by those organisations.
> >>>> The professional captioning and subtitling profession is largely
ignorant of WebVTT.
> >>>
> >>> If this statements implies that professional captioning and
subtitling organisations are ignoring WebVTT, then you may have overlooked
that some are already supporting it and others are keeping a close eye.
> >>> They don't seem to be making a big fuss about it though. For example:
> >>>
> >>> http://www.cpcweb.com/webcasts/webcast_samples.htm#WebVTT
> >>>
http://www.automaticsync.com/captionsync/captionsync-delivers-webvtt-output/
> >>> http://www.synchrimedia.com/
> >>>
http://www.longtailvideo.com/support/jw-player/29360/basic-vtt-captions/
> >>>
http://www.wowza.com/forums/content.php?498-How-to-stream-WebVTT-subtitles-to-iOS-for-closed-captioning
> >>>
> >>>>> Most of the organisations you mention are not captioning or
subtitling companies operating in the TV / Film / Content creation
marketplace. They are mostly organisations involved in the
**redistribution** of media (excluding CPC). Captioning and subtitling (as
creative activities) takes place at (or on behalf of) content owners /
creators as well as at re-distributors. It is this former (professional
level) authoring community that I do not believe WebVTT is connected with.
> >>
> >> CPC is captioning for the TV market FAIK. TV & Film companies don't
> >> create captions themselves but get them made by captioning companies.
> >> They buy the formats that they need and as long as they publish to TV
> >> & Film - not the Web - they don't need WebVTT.
> >>
> >>
> >>
> >>>>>Captions should be positioned, styled and timed using a concise,
structured and partitioned framework. It should not be necessary to have an
in depth knowledge of an arcane set of rules in order to achieve these
requirements.
> >>
> >> Right. WebVTT has a very clear approach to how to position, style and
> >> time captions - I don't see the problem.
> >>
> >>
> >>>>> My biggest reservations about WebVTT are that it appears that it is
being promoted as a container for subtitling and caption content at the
**authoring and archive** level.
> >>
> >> WebVTT is a captioning format for the Web - that's all. Nobody is
> >> promoting it for anything else. If companies see a need to archive
> >> content in this format, I wouldn't have any problem with that. Why
> >> would that be a problem for you?
> >>
> >>
> >>>>>> In truth I have no problem with WebVTT as a delivery format to be
interpreted by a browser or agent, although clearly I would prefer that
there was only one such format. However, WebVTT is late in the game, and it
does not IMHO address the requirements of authoring and archive. This may
be due to a lack of appreciation of the number of phases that subtitle and
caption content goes through in a 'professional' broadcast environment.
Like video, subtitles and captions exist in different 'silos' and are
transformed (often repeatedly) depending on the final target application.
The US captioning model (that of captioning near output or creating caption
master tapes) is NOT representative of captioning globally, nor is it at
all representative of subtitling (multiple language translation) workflows.
> >>
> >>
> >> WebVTT was built for an international market and has taken such
> >> requirements on board - it even supported <ruby> before TTML
> >> introduced it. It had to do so because the Web is a global phenomenon.
> >> Some features were driven later by US law, but the initial target was
> >> always an international use.
> >>
> >>
> >>>>> I hope that clarifies my reservations about WebVTT.
> >>
> >> Yes, thanks. I don't believe I will be able to change your mind about
> >> WebVTT, so I'll just have to focus on improving it to meet your bar.
> >> :-)
> >>
> >> Cheers,
> >> Silvia.
> >>
> >
>