Change in color while reencoding with ffmpeg

[Epaminaidos]

I am still struggling with the details of video-conversion.
Now I notice a very noticable change in colors I cannot explain.
I just reencoded the original and extracted the same frame from both videos:

%ffmpeg% -i Original.mp4 -c:v libx264 -preset fast -crf 10 -an "264.CRF10.mp4"

%ffmpeg% -i "Original.mp4" -ss 00:00:05 -vframes 1 -s 1920x1080 "Original.png"
%ffmpeg% -i "264.CRF10.mp4" -ss 00:00:05 -vframes 1 -s 1920x1080 "264.CRF10.png"

In the resulting images, some colors do not match. This becomes very visible if you open them in two tabs and switch between them.

I had a look into the details of the original using mediaInfo.

Color space               : YUV
Chroma subsampling        : 4:2:0
Bit depth                 : 8 bits
Scan type                 : Progressive
Bits/(Pixel*Frame)        : 0.402
Stream size               : 58.4 MiB (100%)
Color range               : Limited
Color primaries           : BT.709
Transfer characteristics  : IEC 61966-2-4
Matrix coefficients       : BT.709

The last 4 rows are missing in the newly encoded video.
Is this the issue? How do I get the settings there?

Original:

264.CRF10:

[jagabo]

The x264 image is being converted to RGB with rec.601 colors, not rec.709 colors (internally the video is stored as YUV, so it has to be converted to RGB for display). The important setting is the Matrix Coefficients. You can add them while encoding with x264 adding "--colormatrix bt709" to the x264 command line. The other flags don't really need to be set but you can do so with --colorprim "bt709", --transfer "bt709", and don't use --fullrange (there's not an explicit limited range command). For SD video use bt470bg instead of bt709. Note that ffmpeg uses a single hyphen instead of two.

If the colormatrix isn't specified most players will assume rec.709 for HD, rec.601 for SD, limited range for both. In between 720x576 (SD) and 1280x720 (HD) behavior depends on the particular player. Some players always use one or the other matrix, even if the matrix is specified. And your graphics card settings can effect this too.

In AviSynth you can use the ColorMatrix() filter to convert between rec.601 and rec.709. ColorMatrix(mode="rec.601->rec.709") or ColorMatrix(mode="rec.601->rec.709"). Also, when converting back and forth between YUV and RGB ConvertToRGB(matrix="rec709"), ConvertToRGB(matrix="rec601") and similar arguments for ConvertToYV24(), ConvertToYV12(), ConvertToYUY2(), etc.

https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830

[Epaminaidos]

Thank you!
Using your information, I found another hint, how to set the parameters without having to know the details:
-color_primaries 1 -color_trc 1 -colorspace 1

Seems to be working fine as well.

Only the value for "Transfer characteristics" is set to "BT.709" instead of "IEC 61966-2-4".
I really cannot see any difference in the picture...

[shekh]

Using your information, I found another hint, how to set the parameters without having to know the details:
-color_primaries 1 -color_trc 1 -colorspace 1

Where is this written? When I search any ffmpeg docs it does not even have a word "colorspace".

[Epaminaidos]

Where is this written?

http://stackoverflow.com/questions/37255690/ffmpeg-format-settings-matrix-bt709
I do not find these parameters in the docs either.

[KarMa]

I noticed in your comparison pictures you posted in the other thread, that the colors did change. But when I indexed all your videos with L-SMASH and Avisynth, none of them had any real color difference, besides normal compression artifacts. And decoding all your videos in VLC seemed to also have the same color. However when trying to capture snapshots through VLC, I would get different image snapshot sizes between videos like 1920x1088 and 1920x1090. But using L-SMASH and Avisynth I managed to get standard 1920x1080. So I'm not sure what is going on.

[jagabo]

I noticed in your comparison pictures you posted in the other thread, that the colors did change. But when I indexed all your videos with L-SMASH and Avisynth, none of them had any real color difference, besides normal compression artifacts.

Yes, one has to be careful how one views the videos. Different players/editors may display the video differently. Even the the same player/editor may display different (containers, codecs) sources differently.

[pandy]

Using your information, I found another hint, how to set the parameters without having to know the details:
-color_primaries 1 -color_trc 1 -colorspace 1

Where is this written? When I search any ffmpeg docs it does not even have a word "colorspace".

https://forum.videohelp.com/threads/379991-Transcode-M2TS-to-ProRes?p=2456204&viewfull=1#post2456204

[SameSelf]

Color issues are virtually impossible to diagnose unless you have a color managed workflow that can bypass the YUV to RGB conversion. Avisynth and its legion of filters fail miserably at this. ffmpeg exhibits similar shortcomings as well. If you care about color, you should eliminate Avisynth and ffmpeg from your workflow. Otherwise, you need to be extremely careful, and even then, success can be fleeting.

[sneaker]

Color issues are virtually impossible to diagnose unless you have a color managed workflow that can bypass the YUV to RGB conversion. Avisynth and its legion of filters fail miserably at this.

AviSynth is fine for the job, problem are the users not understanding why there's a problem when doing RGB screenshots via e.g. VirtualDub from an YUV script. AviSynth gives you good control over all involved conversions and you can check at all points via info() that you didn't accidentally do any color conversion.

[SameSelf]

AviSynth is fine for the job

Sure, if all your video is ripped or capped. But for those who produce their own video, it is so woefully inadequate; I don't even know where to begin. Vapoursynth reportedly picks up where Avisynth left off, but I have yet to get it running on my system. And honestly, the world of video is moving too fast now to wait on these tools anymore.

[KarMa]

AviSynth is fine for the job

Sure, if all your video is ripped or capped. But for those who produce their own video, it is so woefully inadequate; I don't even know where to begin.

Because reasons. REASONS! This higher than thou mentality with you is pretty amusing.

I've never had a color issue that I could source to avisynth, but instead just about always comes from the player.

[shekh]

Where is this written? When I search any ffmpeg docs it does not even have a word "colorspace".

https://forum.videohelp.com/threads/379991-Transcode-M2TS-to-ProRes?p=2456204&viewfull=1#post2456204

Thanks, it was in my blind spot.

Do yo have an idea why this example does nothing:

ffmpeg.exe -i color.tga -pix_fmt yuv444p -strict -1 -c:v ffvhuff -colorspace 1 -color_range 2 color.mov

I see no trace of colorspace metadata with mediainfo.

[pandy]

"[QUOTE=shekh;2460978]

Thanks, it was in my blind spot.

Do yo have an idea why this example does nothing:

ffmpeg.exe -i color.tga -pix_fmt yuv444p -strict -1 -c:v ffvhuff -colorspace 1 -color_range 2 color.mov

I see no trace of colorspace metadata with mediainfo.

Oh - it was not to point anything to anyone except information, this settings was added to ffmpeg relatively not so long ago (year, maybe 1.5) - they are present in documentation but i can imagine not many people search for this.
Ffmpeg can be nasty as some conversions are performed in background silently without telling anything as such i prefer to disable for example level quantization changes by explicitly guiding ffmpeg - i would advise you to specify clearly all information before and after invoking source - this should force ffmpeg to at least some quasi static state, additionally scaler with not changed size but defined colour space and quantization range may be recommended - this is a bit overkill but at least you can restore partially control over process.

for example:

ffmpeg.exe -color_primaries 1 -color_trc 1 -colorspace 1 -color_range 2 -i "file" -color_primaries 1 -color_trc 1 -colorspace 1 -color_range 2

btw ffvhuf may not use such thing - don't know - maybe you are fully responsible for "knowing" all this.

[shekh]

btw ffvhuf may not use such thing - don't know - maybe you are fully responsible for "knowing" all this.

This is what I was trying to learn this way: whether colorspace is responsibility of container, stream or metadata.
Since it does not work the state is much worse than I expected.

[SameSelf]

Because reasons. REASONS! This higher than thou mentality with you is pretty amusing.

I've never had a color issue that I could source to avisynth, but instead just about always comes from the player.

LOL, I know bashing Avisynth is flamebait on VH and a bannable offense on doom9, but I think users need to be made aware of Avisynth's problems. How is acting like Avisynth is flawless not a higher than thou mentality?

Like I said, I can't even begin to list all the "reasons" I don't like Avisynth. Color is just one area where Avisynth really struggles, and I thought pandy's link to my M2TS->ProRes thread was a good starting point. You can also read the vapoursynth blog. He clearly hates Avisynth, probably as much as I hate Python.

[sneaker]

AviSynth is not responsible for your user errors.

[SameSelf]

The higher than thou camp recruited a new member.

[sneaker]

I did look into your "Transcode M2TS to ProRes" thread. AviSynth input and output are YUV, all intermediate steps are YUV. It didn't introduce any problems.

[pandy]

btw ffvhuf may not use such thing - don't know - maybe you are fully responsible for "knowing" all this.

This is what I was trying to learn this way: whether colorspace is responsibility of container, stream or metadata.
Since it does not work the state is much worse than I expected.

This is main difference between industry standard and developer standard formats (codecs, containers etc) - in broadcast standards all this is specified as multiple sources and customers need to have full control over content, in developer world usually such things are meaningless as "it works for me" - classical example are VPx codecs - they are developed by developers for developers and usually don't care for such things.

To address your question more technically than socially - i would expect that information like this is carry by elementary stream itself so it can be remuxed to various containers without loosing this information - elementary stream must be self sustained.

[KarMa]

LOL, I know bashing Avisynth is flamebait on VH and a bannable offense on doom9, but I think users need to be made aware of Avisynth's problems. How is acting like Avisynth is flawless not a higher than thou mentality?

The higher than thou statement was refering to you saying that avisynth is only good if you are a capper/ripper.

Like I said, I can't even begin to list all the "reasons" I don't like Avisynth. Color is just one area where Avisynth really struggles, and I thought pandy's link to my M2TS->ProRes thread was a good starting point. You can also read the vapoursynth blog. He clearly hates Avisynth, probably as much as I hate Python.

More REASONS!, but you don't have the time to explain. Maybe you could make thread on the downfalls on avisynth (especially 4:2:0 only Avisynth), along with samples and scripts to recreate these many many problems that you find.

As you have been hitting this 4:2:0 only drum for awhile now on VH, without any proof. I've seen other members here get banned for spreading false information.

The higher than thou camp recruited a new member.

Not all of us are as fortunate as you to produce 4K content through our cellphones.

[SameSelf]

I stand by all my statements and make no apologies. What is stupid and higher than thou is the wave of backlashes inflicted on anyone who criticizes Avisynth unless they go through strenuous efforts to document in painstaking detail every problem as you suggest. If you are unaware of its limitations, then you haven't pushed it very hard. And since it works for you, there really is no need for me to provide reasons; is there? How about this, since you are tired of my drum? If you ever encounter an issue, why don't we compare notes then?

[pandy]

I stand by all my statements and make no apologies. What is stupid and higher than thou is the wave of backlashes inflicted on anyone who criticizes Avisynth unless they go through strenuous efforts to document in painstaking detail every problem as you suggest. If you are unaware of its limitations, then you haven't pushed it very hard. And since it works for you, there really is no need for me to provide reasons; is there? How about this, since you are tired of my drum? If you ever encounter an issue, why don't we compare notes then?

Any free alternative free from it's (Avisynth) limitations?

[SameSelf]

Any free alternative free from it's (Avisynth) limitations?

Of course, there are always alternatives. I already mentioned vapoursynth above which has ported most of the important filters from Avisynth and has fixed some of the nagging bugs/limitations. But you didn't really need me to tell you that did you?

[pandy]

Of course, there are always alternatives. I already mentioned vapoursynth above which has ported most of the important filters from Avisynth and has fixed some of the nagging bugs/limitations. But you didn't really need me to tell you that did you?

Well - vapoursynth doesn't change fundamentally concept of a tool - and as i understand most of your complains is the Avisynth idea itself.