Why does Firefox produce larger WebM video files compared with Chrome? - google-chrome

Question

I and my team have been struggling lately to find an explanation why does Firefox produce larger WebM/VP8 video files compared with Chrome when using the MediaRecorder API in our project.
In short, we record a MediaStream from a HTMLCanvas via the captureStream method. In attempt to isolate everything from our app that might affect this, I developed a small dedicated test app which records a <canvas> and produces WebM files. I've been performing tests with the same footage, video duration, codec, A/V bit rate and frame rate. However, Firefox still ends up creating up to 4 times larger files compared with Chrome. I also tried using a different MediaStream source like the web camera but the results were similar.
Here is a fiddle which should demonstrate what I am talking about: https://jsfiddle.net/nzwasv8k/1/ https://jsfiddle.net/f2upgs8j/3/.
You can try recording 10-sec or 20-sec long videos on both FF and Chrome, and notice the difference between the file sizes. Note that I am using only 4 relatively simple frames/images in this demo. In real-world usage, like in our app where we record a video stream of a desktop, we reached the staggering 9 times difference.
I am not a video codec guru in any way but I believe that the browsers should follow the same specifications when implementing a certain technology; therefore, such a tremendous difference shouldn't occur, I guess. Considering my knowledge is limited, I cannot conclude whether this is a bug or something totally expected. This is why, I am addressing the question here since my research on the topic, so far, led to absolutely nothing. I'll be really glad, if someone can point what is the logical explanation behind it. Thanks in advance!

Answer 1

Because they don't use the same settings...
The webm encoder has a lot of other params than the ones we've got access to from the MediaRecorder.
These params may all have an influence on the output file's size, and are up to implementors to set.
Here are snapshots I took of the videos generated from your updated fiddle [click to enlarge]:
Chrome 1
Firefox 1
Chrome 2
Firefox 2
I hope you can appreciate the difference of quality, it's about the same as between webp's 0.15 vs 0.8 quality params, and the sizes also reflects these changes.
const supportWebPExport = document.createElement('canvas').toDataURL('image/webp').indexOf('webp') > -1;
const mime = supportWebPExport ? 'image/webp' : 'image/jpeg';
const img = new Image();
img.onload = doit;
img.crossOrigin = 'anonymous';
img.src = "https://i.imgur.com/gwytj0N.jpg";
function doit() {
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
canvas.width = this.width,
canvas.height = this.height;
ctx.drawImage(this, 0,0);
canvas.toBlob(b => appendToDoc(b, '0.15'), mime, 0.15);
canvas.toBlob(b => appendToDoc(b, '0.8'),mime, 0.8);
}
function appendToDoc(blob, qual) {
const p = document.createElement('p');
p.textContent = `quality: ${qual} size: ${blob.size/1000}kb`;
p.appendChild(new Image).src = URL.createObjectURL(blob);
document.body.appendChild(p);
}
So yes, that's how it is... One way or the other could be better for your cases, but the best would be that we, web-devs, get access to these parameters. Unfortunately, this is not an easy thing to do from the specs point-of-view...