Bug 219810 – [Cocoa] Add Experimental Vorbis support

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Eric Carlson]

Add experimental Vorbis support

[Radar WebKit Bug Importer]

<rdar://problem/72242614>

[Eric Carlson]

Created attachment 416063 [details]
Patch

[Jer Noble]

Comment on attachment 416063 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=416063&action=review

> Source/WebCore/page/RuntimeEnabledFeatures.h:399
> +    bool m_VorbisDecoderEnabled { false };

Nit: the capitalization here is weird.

[Eric Carlson]

Created attachment 416066 [details]
Patch

[Jer Noble]

Comment on attachment 416066 [details]
Patch

Clearing flags on attachment: 416066

Committed r270722: <https://trac.webkit.org/changeset/270722>

[Jer Noble]

All reviewed patches have been landed.  Closing bug.

[Sam Weinig]

Comment on attachment 416066 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=416066&action=review

> Source/WebCore/platform/graphics/cocoa/WebMAudioUtilitiesCocoa.mm:181
> +    if (!RuntimeEnabledFeatures::sharedFeatures().vorbisDecoderEnabled())
> +        return false;

Hey Eric, this is a layering violation in WebCore. By rule, you cannot use the RuntimeEnabledFeatures in the platform/ part of WebCore (platform is the platform abstraction layer and therefore should not be directly influence by WebCore level concepts like this). 

The pattern I suggest for things like this having the platform level classes provide some configuration options (much like any API would) and having the parts of WebCore outside the platform directory that need to use platform concepts pass in setting state using those configuration options.

[Eric Carlson]

Comment on attachment 416066 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=416066&action=review

>> Source/WebCore/platform/graphics/cocoa/WebMAudioUtilitiesCocoa.mm:181
>> +        return false;
> 
> Hey Eric, this is a layering violation in WebCore. By rule, you cannot use the RuntimeEnabledFeatures in the platform/ part of WebCore (platform is the platform abstraction layer and therefore should not be directly influence by WebCore level concepts like this). 
> 
> The pattern I suggest for things like this having the platform level classes provide some configuration options (much like any API would) and having the parts of WebCore outside the platform directory that need to use platform concepts pass in setting state using those configuration options.

Oops! 

https://bugs.webkit.org/show_bug.cgi?id=220052 cleans this up a bit.