I have 950 PNG files which are intended to become individual frames in a 38 second video track á 25 frames per second. The file names are identical except for sequence number, as is customary in these kind of cases.
I want to produce a container of a widely-supported format, ideally WebM if all criteria can be met with it, or MPEG-4 for instance, with a codec that is supported by modern browsers for playback, from this series of PNG images I have. The problem is that the colors are shifted and the background color in the decoded video no longer matches the same RGB triplet sampled from the background color in the PNG images. This results in the video sticking out from intended background on my HTML page where the video is embedded.
I tried the simple:
ffmpeg -f image2 -i image%03d.png output.webm
which indeed gave me a 25 fps VP9 video track packed in a WebM container.
The PNG images are animation style, with solid background and simple shapes animating for foreground. They appear to be color untagged (that's what Adobe Bridge tells me, I assume this means no embedded color profile or a reference to one). The problem with my above attempt is that even though the container is played back in Chrome, the background color sampled from the PNG image, with RGB triplet
#ED4D56, does not perceptually match the background color that appears in the video being played back.
Is this an unavoidable side-effect of the RGB to YUV (encoding) to RGB (playback) color conversion? Is there any way to mitigate this? I don't insist the frames in the video track be encoded using RGB, I suppose YUV is fine, as long as a modern browser playing back these frames produces the same (within a negligible margin of error) RGB triplet when decoding and displaying the frame(s).
My question is, what command line using
ffmpeg can I try to mitigate this? I am open to switch the video codec, pixel format, enable color management in ffmpeg if it exists, etc.