[Webkit-unassigned] [Bug 110479] [Meta] Implement support for TTML
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Feb 25 21:05:23 PST 2013
https://bugs.webkit.org/show_bug.cgi?id=110479
--- Comment #28 from Pierre Lemieux <pal at sandflow.com> 2013-02-25 21:07:47 PST ---
(In reply to comment #27)
> (In reply to comment #26)
> >
> > As pointed out earlier, there are many TTML-based applications worldwide, including EBU-TT [1], SMPTE-TT [2], SDP-US [3] and CFF-TT [4].
>
> These are, in fact, different specs and not different applications.
In fact they are distinct profiles of the same core specification (TTML). As such, they share a common document syntax and structure, timing model, and layout and rendering model. In fact, SMPTE-TT is a minor extension of TTML (it adds support for sub-picture), with CFF-TT being essentially a subset of SMPTE-TT and SDP-US essentially being a subset of SMPTE-TT.
Let me know if your understanding is different. Happy to dig deeper and provide additional information.
> > Why then introduce friction for TTML authors and end-users by actively discouraging the implementation of TTML rendering in WebKit, which is used in client devices?
>
> See comment #17
Yes. I am sympathetic with the goal of minimizing proliferation of formats (or versions of the same format!) on the web, or everywhere for that matter.
In the specific case of TTML, I however see no evidence that preventing the implementation of TTML rendering in WebKit will prevent the use of TTML on the Internet -- based on my observations, the FCC safe-harbor provision has a strong influence in the entertainment media community.
I in fact see strong evidence that preventing the implementation of TTML rendering in WebKit will frustrate and confuse content authors and end-users alike.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list