[Webkit-unassigned] [Bug 110479] [Meta] Implement support for TTML

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=110479





--- Comment #20 from Glenn Adams <glenn at skynav.com>  2013-02-22 05:37:17 PST ---
(In reply to comment #18)
> (In reply to comment #4)
> > (In reply to comment #3)
> >> > 
> > > There are many possible interpretations of the FCC rules. Some say that it's not necessary to specifically implement SMPTE-TT, the safe harbor format, as long as a format with all the mandated capabilities is supported. I have yet to hear an interpretation it's required to implement a subset of TTML that's not the same profile as SMPTE-TT.
> > 
> > The real question is whether video service providers will or would like to reference TTML content directly as a delivery format. We have some preliminary input that they will. We also have a variety of downstream ports of WK that are deploying on devices covered by FCC rules that relate to captions. I agree that we don't have the final word on this subject. But I think absence of finality on this matter is not a reasonable objection to exclude TTML from WK. The WK community has added many other features that have less finality or concrete requirements.
> 
> I'm sure they'd like all sorts of things. That's not enough reason to add a duplicative feature to WebKit.

It is not a duplicative feature.

> 
> I think adding features primarily for specialized downstream ports is also a bad idea. Adding support for WML turned out to be a regrettable decision and we should have rejected it on the basis that it's not valuable to mainstream ports.

First, I did not say that was the primary reason. In any case, downstream ports should have as much standing as upstream ports with respect to feature addition. This is an open community intended to address many needs. All ports will find the addition of TTML support a useful feature, and can make their own decision about enabling.

> > In any case, I would be willing to claim that an implementation of all of TTML is at least one or two orders of magnitude simpler than SVG or HTML5, or even some of the more complex, recent additions to CSS.
> > 
> > What would be useful is an implementation of a subset of TTML that works in WK against which objective judgments about complexity, etc,  can be made. At present, the arguments are rather speculative in nature, wouldn't you agree?
> 
> I don't think there's any reason to natively support another caption format for out-of-band captions. If we do, then supporting an arbitrary subset of a spec rather than something actually defined by spec seems like a terrible idea for interoperability. So yes, I would object.

Who said anything about implementing an arbitrary subset? The intention is to implement at least one or more of the well defined profiles of TTML, such as SMPTE-TT and SDP-US. These profiles are well defined by published standards.

It sounds like you are objecting to the notion of incremental implementation of a feature in WK. From my observation, the implementation of features in WK doesn't happen in a binary fashion. Instead, new features are build behind an ENABLE flag and are filled out functionally speaking and tested up until a time that the feature can be announce as fully implemented. Take CSS for example, many extensions to CSS have been added to WK. What is the bar for deciding to add an implementation of one of these extensions? It seems rather arbitrary. A number of CSS extensions have been implemented upon the early availability of an editorial draft that is in a high state of flux. In the case of TTML, we have a published W3C REC and a number of profiles already published in a final form.

I just counted 65 features that are disabled by default in build-webkit. What was the criteria for determining if they were worthy of inclusion or not in WK? The OWP (and WK) has many features that can be considered duplicative at some level, but not identical. For example, XHR and WebSockets. Should one of these be rejected because the other can provide similar or even identical functionality (in some cases)? Perhaps. But I would consider a call for rejection of one of these in favor of the other as exclusionary and probably short sighted. TTML and WebVTT have different uses in the industry of Web content, and will never have the same feature set or user communities. Sure, in some cases one or the other may be sufficient, but in other cases this won't be so. Without trying to play one of these off against the other, I would suggest they both have a legitimate role in WK.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.