Opened 14 months ago

Last modified 3 months ago

#7037 open defect

ffmpeg destroys HDR information when encoding

Reported by: mario66 Owned by: cehoyos
Priority: normal Component: avcodec
Version: git-master Keywords: libx265 hdr
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

Hi,

I have a new 4k bluray with a 10 bit HDR movie and I now want to convert it to 1080p with x265, but keep the HDR.

I downloaded a ffmpeg binary build against 10 bit x265 and started the conversion with '-vf "scale=1920x1080"' option. While the resultsing video is indeed encoded with the Main10 profile, the video itself looks dull and as if the HDR information was lost. I notice that metadata changed.

In the original video, there are the following tags:

colour_range                             : Limited
colour_primaries                         : BT.2020
transfer_characteristics                 : PQ
matrix_coefficients                      : BT.2020 non-constant
MasteringDisplay_ColorPrimaries          : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
MasteringDisplay_Luminance               : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
MaxCLL                                   : 500 cd/m2
MaxFALL                                  : 200 cd/m2

In my new video, these are not included any more. I consider this to be a BUG because I never told ffmpeg to mess with color spaces etc. therefore ffmpeg should just leave everything as it is including the metadata.

How to reproduce:

% ffmpeg -i in.mkv -vf "scale=1920x1080" -map 0:v -map 0:a? -map 0:s? -c:v libx265 [-pix_fmt yuv420p10le] -c:a copy -c:s copy out.mkv

The argument in square brackets is an alternative I tried but the result is the same.

Version:
ffmpeg-20180220-a877d22-win64-static

Change History (24)

comment:1 Changed 14 months ago by jamrial

What's lost, only the MasteringDisplay?, MaxCLL and MaxFALL values, or also colour_range, colour_primaries, transfer_characteristics and matrix_coefficients?

Also, can you provide us with a sample to reproduce this? What's the x265 version you're using?

comment:2 Changed 14 months ago by mario66

Everything is gone. Also colour_range, etc.

Sample:
https://we.tl/xpeDCFJYDH

It's only the Time Warner logo, but you can see the difference very clearly. And you can see the that the tags are lost. (Note: Not the original video, but the bug is still reproducible on that)

It says "ffmpeg version N-90094-ga877d22d9a" and "x265 2.6+37-1949157705ce:[Windows][GCC 7.2.0][64 bit] 10bit" (for the x265 included in ffmpeg)

Last edited 14 months ago by mario66 (previous) (diff)

comment:3 Changed 14 months ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords libx265 added
  • Priority changed from important to normal

comment:4 Changed 14 months ago by mario66

Could someone from the ffmpeg team please download the sample and store it somewhere internally? I just saw that WeTransfer? deletes the file after 7 days automatically. Unfortunately I couldn't upload to your website because you have a filesize limit of 2,5 MB...

Last edited 14 months ago by mario66 (previous) (diff)

comment:5 Changed 14 months ago by mario66

  • deleted -
Last edited 14 months ago by mario66 (previous) (diff)

comment:7 Changed 3 months ago by mario66

I don't understand. Why is no one working on this? There is clearly a demand for this. People have to write awfully long script for this to compensate this shortcoming. Here is one example: https://forum.doom9.org/showthread.php?s=1e8582f9d692cbc7f04d205d05964122&p=1833683#post1833683

comment:8 Changed 3 months ago by mario66

  • Priority changed from normal to important

comment:9 Changed 3 months ago by cehoyos

  • Priority changed from important to normal

This is not a regression afaict.

comment:10 follow-ups: Changed 3 months ago by mario66

If you were as fast fixing this bug as you are to downplay the importance, we would have no issue here.

I created a forum thread here https://forum.doom9.org/showthread.php?t=175278 and it got lots of attention. People wrote me personal messages because they had the exact same problem and asked me if I meanwhile found a solution. The truth is, however, that still no solution exists. I'm disappointed. ffmpeg is just another failing open source project where the developers only focus on integrating fancy cool stuff no one needs. If you read the changelog it mentions dozens of unnecessary filters you added but it never says that something was fixed.

This is why open source always fails because the glorified people who work in their spare time for this project just do things that make fun not things that are actually necessary.
Only if people get payed to fix bugs there is a chance that the project will become usable. That's the sad truth.

Libav was so right. It had much better developers with a much better mindset, too bad it was abandoned.

comment:11 Changed 3 months ago by mario66

  • Owner set to cehoyos
  • Status changed from new to open

comment:12 Changed 3 months ago by mario66

cehoyos, so you are going to fix this bug now? Great!

comment:13 in reply to: ↑ 10 Changed 3 months ago by cehoyos

Replying to mario66:

Libav was so right. It had much better developers with a much better mindset, too bad it was abandoned.

I am curious: So why did you report the issue here?

comment:14 follow-up: Changed 3 months ago by mario66

Libav was focused on getting things right before working on fancy new stuff. This was the absolute correct thing to focus on. Unfortunately, it got abandoned because, like I said, doing things right doesn't attract developers. It's the fancy new stuff that attracts developers, because they just want to have fun while coding. This is how "open source development" always works. Libav was the rare exception but too few people followed them. It's so sad. I would definitively use it if it was actively developed, this I can tell you.

HDR is just not usable with ffmpeg because of this. It was not developed until the end. Probably something more fancy was on the way.

"ffmpeg HDR metadata" is the among the top 4 (!) suggestions in Google if you type "ffmpeg HDR". Because everyone who wants to encode HDR will stumble across this. HDR is already in the mass market. Even cheap TV supports it. I would consider this as a major drawback of ffmpeg that it cannot properly handle HDR. And I am sure some people haven't even noticed but they will be screwed once they find out that in their media backup collection important metadata is missing.

I'm just telling the truth.

Last edited 3 months ago by mario66 (previous) (diff)

comment:15 in reply to: ↑ 14 Changed 3 months ago by cehoyos

Replying to mario66:

Libav was focused on getting things right before working on fancy new stuff. This was the absolute correct thing to focus on. Unfortunately, it got abandoned because, like I said, doing things right doesn't attract developers. It's the fancy new stuff that attracts developers, because they just want to have fun while coding. This is how "open source development" always works. Libav was the rare exception but too few people followed them.

Again: If any of this were true why did you report your issue here?

It's so sad. I would definitively use it if it was actively developed, this I can tell you.

Why do you believe it is not actively developed?

comment:16 in reply to: ↑ 10 Changed 3 months ago by jamrial

Replying to mario66:

This is why open source always fails because the glorified people who work in their spare time for this project just do things that make fun not things that are actually necessary.
Only if people get payed to fix bugs there is a chance that the project will become usable. That's the sad truth.

You're chastising people for doing something fun and interesting in what you acknowledged is their spare time, and not what you think should be done instead. I hope you realize how absurd and entitled that sounds.

Libav was so right. It had much better developers with a much better mindset, too bad it was abandoned.

Adding color information to the filter chain during format negotiation in encoding scenarios is a huge change that no one capable of implementing has felt like doing. And that includes every developer from ffmpeg and libav for the better part of the past two decades.

This is a bug tracker, not a discussion forum. Stick to technical reports here, and criticize development elsewhere.

comment:17 follow-ups: Changed 3 months ago by mario66

I'm not chastising anyone, I just analyze the situation. Look, there is no problem with having fun. I didn't mean it in an insulting way. I also like to have fun. One just should be honest about it.

What I want to say is this: if we have a wrong model of reality, bad things can happen. Like a complete misalignment of incentives. Under the correct world model (where devs do coding for fun, not for the greater good), you will realize there is absolutely zero incentive for anyone to fix this bug. That's a serious issue. One step could be to build some gamification elements into this. Like every new feature submission has to be followed by one bugfix submission, otherwise you can not submit new features any more. Bugs like the present one would be fixed within weeks. You are really fast. Just look how fast cehoyos was to downplay the importance of this very serious issue. It was like few minutes reaction time - on a Sunday! There is lots of spare time and energy but the incentives must be misaligned if this time and energy is not converted into good code. This is what I wanted to tell right from the beginning.

You can transfer this discussion and my arguments to other places if you want. But it was important for me to tell it here since this is an issue that prevents this particular bug from being fixed.

comment:18 in reply to: ↑ 17 Changed 3 months ago by cehoyos

Replying to mario66:

I'm not chastising anyone, I just analyze the situation. Look, there is no problem with having fun. I didn't mean it in an insulting way. I also like to have fun.

One just should be honest about it.

I am sorry, could you elaborate what (or whom) you mean here?

It is one thing that you post complete BS above (some of which absolutely makes me laugh after all those years) but if this is meant as an insult, I'd like to know;-)

comment:19 Changed 3 months ago by mario66

No one was insulting anyone, jamrial was suggesting I was chastising people but this is obviously not true. I was reacting to his post. You are allowed to do everything, and I will also not chastise you for having fun with my analysis here. :-)

It is important, however, to talk about reality even if this collides with the self-image some developers may have that they are serving the greater good. I know lots of people don't like their self-image being challenged and they will either react enraged or they start laughing (like you did) as a mechanism of self-defense.

This self-image of serving the greater good is not what we can observe in reality. It is a fact that this bug is objectively more important than most of the fancy new features added in the latest releases. I proved this with Google statistics. Still, this bug is open. Thus, the developers must have a different motivation. q.e.d.

Last edited 3 months ago by mario66 (previous) (diff)

comment:20 in reply to: ↑ 17 Changed 3 months ago by cehoyos

Replying to mario66:

One just should be honest about it.

I am not a native speaker: Please explain what this means and who you mean.

comment:21 follow-up: Changed 3 months ago by mario66

I will put it in other words:
People who do coding for fun should be honest that they do coding for fun (and not for charity). I didn't target that to any specific people, there may be some people with a more noble motivation (like the ones who started libav), but as I have proved above there is a significant percentage of people contributing here who do not care what is actually important but just care for having fun. And it is important to point that out. Not to chastise those people but because if we accept this reality, we can change the system and the incentives such that people can continue to have fun but the resulting product will be much better. There is a whole research area called Mechanism design that tells us how we can change incentives toward desired objectives. Gamification is one approach that takes the "fun" element into account.

Last edited 3 months ago by mario66 (previous) (diff)

comment:22 in reply to: ↑ 21 Changed 3 months ago by cehoyos

Replying to mario66:

People who do coding for fun should be honest that they do coding for fun (and not for charity).

Who claims to code for charity?
(I wonder what this even means...)

I didn't target that to any specific people, there may be some people with a more noble motivation (like the ones who started libav)

Do you realize how offending this sentence is?

Last edited 3 months ago by cehoyos (previous) (diff)

comment:23 follow-up: Changed 3 months ago by mario66

I'm not sure why you keep responding here since jamrial didn't want this to be used as a discussion forum. However, if I am asked directly I feel eligible to answer to that. ;-)

ffmpeg has a donate button on their website. With a red heart next to it. This appears like charity to me.

Ok, but you are right. Not everyone here claims to work for the greater good. Like for example you. You're contributing here to be hired as a freelancer. (Also shown on the website) Your motivation is to appear as competent as possible to potential employers. This may not necessarily lead to the most valuable technical contributions, just to contributions that appear valuable to outsiders. We are all just Homo economicus, and this would be the best strategy if you act according to your incentives.

However, there should be someone at the top of the organization who knows what's going on at the lower level. Someone who knows the motivation of the people and can set the rules accordingly. I'm not sure if someone like this exists. Because what we can observe is that major functionality that is used by millions of people (like HDR) is broken and does not get fixed within years (!).

It's like social market economy. You are from Austria, you should know this. In a social market economy, people are still allowed (and even encouraged) to act according to their incentives. However, the system is designed in such a way that if everyone followes his or her personal incentives, the prosperity of the society is maximized. This does not work in a free marked. There must be boundaries and regulations. (Although some far-right Austrians - even in the government - don't think so and disastrously want to strip away as much government regulation as possible) A free marked will degenerate since the incentives are not aligned with what is best for the society.

Same for ffmpeg. ffmpeg is currently managed like a free marked. Everyone can contribute anything without coordination or regulations or special programs to encourage fixing of important bugs. People just do what's best for their curriculum vitae or what makes fun. But no one concentrates those forces towards the desired outcome of a stable and usable medial library.

comment:24 in reply to: ↑ 23 Changed 3 months ago by cehoyos

Replying to mario66:

ffmpeg has a donate button on their website. With a red heart next to it. This appears like charity to me.

I am not a native speaker, but I strongly believe this argumentation makes absolutely no sense (even more so after reading our donations site).

You're contributing here to be hired as a freelancer. (Also shown on the website)

(While I partly understand your argumentation)
No.

Your motivation is to appear as competent as possible to potential employers.

LOL
No.

Note: See TracTickets for help on using tickets.