5

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!

1 Answers1

3

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...

Kaiido
  • 123,334
  • 13
  • 219
  • 285
  • Thank you, Kaiido! This is definitely a possibility. However, this should mean that everyone using MediaStream from HTMLCanvas should be getting much bigger WebM videos in Firefox compared to Chrome. Upto 9x bigger. It just feels weird that nobody would have noticed this issue and talked about it online. That makes us wonder if there's something wrong on our side. Have you seen any such dramatic differences between Firefox / Chrome due to different internal encoding settings? – Sinatra Feb 12 '19 at 23:03
  • @Sinatra 9x bigger? With your examples? On how long of a video? Could you try to upload these somewhere public? On ~20s videos from your fiddle I have a difference of roughly 100KB (on 500~600). Far from 9x. On my phone the diff is bigger though but still far from 9x (700KB vs 500) – Kaiido Feb 12 '19 at 23:38
  • And now you get me wondering, in your real world tests, you do use the same code structure? I.e you use the single ondataavailable.data Blob? This event may fire any time (max limit set by the browser), so maybe you were comparing the whole file in FF vs just a chunk in Chrome? Usually, we push all ondataavailable.data into an Array and build the final Blob from all these chunks. FF has a very high limit, Chrome until recently had a very low one, producing chunks of a few seconds only, and it's quite recently only they raised it up. – Kaiido Feb 12 '19 at 23:44
  • Thanks for the answer! What you said really makes sense. But do we have a clue to what extent these settings can affect the file size? Our worry is not that we have different file sizes, which is something totally expected; it's just that they are so much bigger in Firefox. As for our real-world usage, we already use the approach you mentioned - pushing the output chunks from `ondataavailable` into an array and respectively creating a `Blob` from them afterwards. Haven't implemented this in the fiddle though. – Georgi Serev Feb 13 '19 at 08:37
  • And yeah, the fiddle doesn't result in huge output difference primarily because I am looping between 4 frames which have a small delta. – Georgi Serev Feb 13 '19 at 08:37
  • This is a fiddle which merges the chunks just in case, uses 8 landscape images with slightly increased resolution and performs the canvas updates every 1/5th of the second: https://jsfiddle.net/f2upgs8j/3/. The difference is now more prominent. – Georgi Serev Feb 13 '19 at 09:51
  • Yes, the results from this fiddle are actually more consistent with the parameters I talked about. I edited my answer to include snapshots of both Chrome and FF. You can see the difference of quality. – Kaiido Feb 13 '19 at 12:20
  • Appreciate the help. Yeah, there is definitely a noticeable difference in the quality. Strangely, in our app the FF videos sometimes looks worse. Anyway, apparently we cannot do much about it. Thanks again! – Georgi Serev Feb 14 '19 at 09:39