[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