Page MenuHome

FFMpeg color offset
Open, Confirmed, MediumPublic

Description

System Information
Operating system: Win7x64, Ubuntu18x64
Blender Version
2.80 beta

Short description of error
Files encoded through FFMpeg.h264 in Blender show up with a consistent color space offset (warmer and different gamma) in other software/players/viewers, but are viewed "as saved" if opened in Blender. At the same time h264 files produced in other software are open in Blender with no noticeable color shift, but re-rendering them through Blender introduces it.
Same content rendered into other formats, like PNG, does not have such effect.
At first I thought those are my codecs on a windows machine, but the output/behavior is the same on Ubuntu.

Given that the h264 files produced elsewhere are open in Blender without matching "negative" color offset (at least one I could see), could it be that FFMpeg in Blenders is set up to default to some particular color space for encoding?

Exact steps for others to reproduce the error


Open, render animation, compare to what is in the source image in any other software.

Details

Type
Bug

Event Timeline

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.

Yes, blender is set to use the "Filmic" view transform. You can set the colorspace and view transform in the Render tab -> Color Management.

Is it fine if you set it to "Default" instead?

It is already set to sRGB/Default in the attached file. I was talking about the color space used by the FFMpeg encoder inside Blender (FFMpeg in converters like Handbrake seems not to have this issue). The difference is less perceivable than that between Filmic and sRGB, but it is quite strong in terms of color correction.

On an unrelated side note, given Filmic was mentioned - applying Filmic color space transform to scene rendering by default may be a good strategy for many cases, but it probably will be a source of headache and many complaints for anything involving video editing as any imported file already has color transforms applied to it, which will damage external footage and will accumulate on re-rendering even on that made in Blender, unless paid attention to turn off.

It seems there is an option for sequencer to change view transform separately, which would solve that, but it seems to have no effect. Could that be a bug or am I missing the idea behind?

It wasn't clear from description, if this applies to renders from video sequencer(VSE bug) or all renders(FFMPEG bug).

Just to be on the same page - is the color difference of black background between PNG and video file symptom of a problem, we are talking about?

If this is the case:

  • you can see in render preview, that the color is unchanged
  • can not reproduce using FFV1 codec
  • can reproduce using multiple codecs
  • can reproduce this using color strip

When "bad output" loaded in blender, value of black is around 0.004 for RGB A=1

To me it looks like broken rendering

Now I am thinking that good question is why is this "bad output" displayed "correctly" in blender

Either way, to be fair I am quite familiar with VSE core, but other than that I have just a little knowledge.

I would pass this to somebody experienced with FFMPEG or if this turns out to be VSE problem, I am OK to work on it.
I wouldn't be probably able to localize the problem efficiently.

Tried rendering 3D scene, not VSE.

Rendered 3D scene as mp4, viewed in:

  • AfterEffects - shifted color/luminance curve
  • VLC player - shifted color/luminance curve
  • MPC-HC player - shifted color/luminance curve
  • Quick Time - shifted color/luminance curve
  • Blender - identical to source
  • DJV imaging viewer - identical to source
  • Firefox - identical to source
  • Youtube - no color shift, but luminance curve shift present (auto color space correction?)

Rendered as raw avi, viewed in:

  • AfterEffects - identical to source
  • Youtube - green tint in greys, no luminance curve shift

Rendered 3D scene as png, viewed in:

  • MSpreview - identical to source
  • AfterEffects - identical to source
  • Blender - identical to source
  • Firefox - identical to source
  • DJV imaging viewer - identical to source

This all might suggest that it's a matter of some obscure binary choice up to each application, however
for example files rendered in HandBrake video converter (using FFMpeg, AFAIK) in the same mp4+h264 format are opened correctly in any of AfterEffects, Firefox, VLC or Blender.
Yet same content re-coded with Blender is opened properly only in Blender and Firefox.

Attached - a screenshot showing color difference by cutting away overlay image with a diagonal rectangle (may seem minor, but is way more prominent in some situations), source renders, blend file.




Also - I might've written that too long previously, but what should ColorManagement->Sequencer option do? Logically it seems it should give an option not to have Filmic or other transform applied to sequencer when it is set for the 3D scene, but it seems not to have any effect at all.

Does this also happen with the 2.79 build from https://builder.blender.org/download/ ? Or is this just in 2.8?

It does happen in 2.79 on windows/linux too, however I was wrong - Converting in Handbrake (FFMpeg) directly from PNG does produce the color shift too. Converting from MOV+h264 that was created from the same PNG in AfterEffects however does not. Which suggests that there is a problem and that it is solvable, but it's unlikely to be a Blender's bug.

Googling leaves impression that some people have solved at least some color space problems converting with FFMpeg by passing some additional arguments. I'll try digging, but is there any info on how Blender communicates with FFMpeg? Are frames transferred directly or via files? Debug mode doesn't say anything upon saving animation.

Blender uses the ffmpeg C API to encode. So frames are encoded from memory not from disk.

Found it! Adding this option to ffmpeg seems to produce result with no color shifting:
-vf scale=out_color_matrix=bt709

And according to same stackoverflow post these ought to add proper metadata flags. Although not sure and didn't find difference in ffmpeg commandline output:
-color_primaries bt709 -color_trc bt709 -colorspace bt709

Edit: Ok, not so fast. Now it produces coolor shift in Blender, and those flags seem to dictate how exactly...

Ok, so this:
-vf scale=out_color_matrix=bt709
does the conversion for other programs to read colors identical to png.
And this:
-color_primaries 1 -color_trc 1 -colorspace 1
makes Blender recognize the converted colors properly.

Attached - source png, command line ffmpeg + options converted mp4.
Sans slight luminance variation due to noise smoothing, they look identical in Blender, Natron, VLC vs MSpreview, After Effects.
Now there is slight color variation in Firefox and DJV imaging viewer though.


Also Blender rendered mp4 for reference:

Thank you for reporting and investigating this.

I will assign this to Sergey - don't know anybody else with knowledge of FFMPEG

Jacques Lucke (JacquesLucke) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Mar 14 2019, 4:38 PM
Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.Mar 14 2019, 8:15 PM