Say an editor asks you for a transparent clip with the person already cut out. I had one: an 8-second, 540×960 WebM from ImgIng (https://imging.ai/), 2,394,232 bytes, audio included. Converting it to something an editing app accepts made the file 26 to 38 times bigger. I live on free tiers and I hate paying for egress, so I did the arithmetic before picking a format.
ImgIng's video matting is Beta, runs in desktop Chrome or Edge, processes locally, and does not work on phones. Transparent output is WebM only, which is why this question exists at all. The footage is a VOA Learning English clip from Wikimedia Commons (public domain), cut to its first 8 seconds. Everything below is that one clip, one run, FFmpeg 7.1 on an M4 Mac. MB here means 1,000,000 bytes. The ImgIng UI counts 1,048,576, so its numbers read smaller.
Three formats keep the alpha at different prices
I converted the same WebM to ProRes 4444, a PNG sequence and QuickTime Animation (qtrle), then read the alpha back from each file. All three matched the source exactly: mean alpha 46.762 on frame 60, range 0 to 255. The outputs have no audio, while the source WebM still carries about 0.3 MB of sound, so the true ratios are slightly worse than the ones below.
ProRes 4444 came out at 62,034,554 bytes, about 26 times the WebM. The PNG sequence, 240 files, was 63,857,616 bytes, about 26.7 times. qtrle was 92,176,076 bytes, about 38.5 times. Per second of footage that is roughly 7.8 MB for ProRes and 11.5 MB for qtrle, and about 16 ProRes clips of this length would fill a 1 GB budget. That is plain division on this clip. I would not scale it to a 10-minute video without converting a slice of it first.
ProRes and PNG frames cost the same and qtrle costs half again
An image sequence sounds like the heavy, safe option, and ProRes sounds like the compromise. On this clip they are 62.0 and 63.9 MB, three percent apart. The odd one out is qtrle, about 49 percent bigger than ProRes for the same alpha.
So size alone settles one thing: qtrle has to earn its place some other way, for example because the editor's tool only takes that codec. Between ProRes and PNG frames the bytes are a wash and the choice moves to handling. One .mov is one upload and one link. Two hundred and forty PNGs are a zip and a numbering convention to agree on, and every extra file is a chance to lose one on the way.
One flag decides whether the alpha survives
$ ffmpeg -hide_banner -c:v libvpx-vp9 -i input.webm -an -c:v qtrle -pix_fmt argb out_qtrle.mov
frame= 240 fps=0.0 q=-0.0 Lsize= 90016KiB time=00:00:08.00 bitrate=92176.1kbits/s speed=12.2x
The -c:v libvpx-vp9 before -i picks the decoder. The ProRes run is the same command with -c:v prores_ks -profile:v 4444 -pix_fmt yuva444p10le on the output side. Leave the decoder flag off and FFmpeg's built-in VP9 decoder reads every alpha value as 255. That gave me a 41,105,728-byte ProRes file, smaller and playable, with no error and the whole frame opaque. The cheaper file was the broken one.
What I send
ProRes 4444 as a single .mov by default, because it is the smallest of the three I verified. PNG frames if the editor asks for frames or wants to touch single ones. QuickTime Animation only when someone names it. I also keep the 2.4 MB WebM, since that is the copy worth archiving.
One thing stays open. I have no source on how a given editing app treats a transparent WebM, so I cannot tell you which editors would take the small file directly and skip all of this. If yours does, the 2.4 MB file saves you about 60 MB. Test one short clip first.
Top comments (0)