It's nice to present a unified API across our version numbers, it makes it easier for developers to reason about the capabilities of Chrome. If the only thing blocking us is binary size, and we're going to do it soon anyway, I say let's go for it now. If the binary size increase isn't acceptable today we should rethink shipping the API on other platforms until we have a strategy to ship everywhere. :)
What's the increase?
On Nov 26, 2015 12:39 PM, "Elliott Sprehn" <esp...@chromium.org> wrote:
>
> It's nice to present a unified API across our version numbers, it makes it easier for developers to reason about the capabilities of Chrome. If the only thing blocking us is binary size, and we're going to do it soon anyway, I say let's go for it now. If the binary size increase isn't acceptable today we should rethink shipping the API on other platforms until we have a strategy to ship everywhere. :)
>
> What's the increase?
Last time I checked it was 12KB in Debug, 10KB in Release. (in my Linux box).
That doesn't seem bad for the added functionality and compatability with other browsers. I'm sure we'll get 10k back as we simplify the codebase post merge. :)
Can we get a UseCounter for this feature before it ships though? It's nice to track adoption.
That doesn't seem bad for the added functionality and compatability with other browsers. I'm sure we'll get 10k back as we simplify the codebase post merge. :)
Can we get a UseCounter for this feature before it ships though? It's nice to track adoption.
On 26 November 2015 at 14:08, Elliott Sprehn <esp...@chromium.org> wrote:That doesn't seem bad for the added functionality and compatability with other browsers. I'm sure we'll get 10k back as we simplify the codebase post merge. :)
I'll patch together a CL adding third_party/libwebm and the MediaRecorder classes to Cr Android builds. Is it safe to assume that, aside from this issue, the rest of this ITS looks OK?
On 26 November 2015 at 14:08, Elliott Sprehn <esp...@chromium.org> wrote:That doesn't seem bad for the added functionality and compatability with other browsers. I'm sure we'll get 10k back as we simplify the codebase post merge. :)
I'll patch together a CL adding third_party/libwebm and the MediaRecorder classes to Cr Android builds. Is it safe to assume that, aside from this issue, the rest of this ITS looks OK?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
The supported video codecs are VP8 and VP9. The only supported audio codec is Opus. The only container format currently is Webm (simplified Matroska) in streaming format.MediaRecorder.canRecordMimeType("bla/foo") [1] will answer "maybe" if it's supported, and currently it says so for video/vp8, video/vp9, audio/opus, video/webm and audio/webm.
On Wed, Dec 2, 2015 at 9:26 AM, 'Miguel Casas' via blink-dev <blin...@chromium.org> wrote:The supported video codecs are VP8 and VP9. The only supported audio codec is Opus. The only container format currently is Webm (simplified Matroska) in streaming format.MediaRecorder.canRecordMimeType("bla/foo") [1] will answer "maybe" if it's supported, and currently it says so for video/vp8, video/vp9, audio/opus, video/webm and audio/webm.Do you mean 'video/webm; codecs="vp8"' and similar? 'video/vp8' is not a valid MIME type.The spec says "A MimeType, including parameters..." so using the codecs parameter seems correct. The spec should probably be more explicit and reference other definitions, such as http://www.w3.org/TR/html5/embedded-content-0.html#mime-types and/or RFC(s).