HDR10 metadata copy by default if no icc changes (+ frontend for ffmpeg)

[Former user]

See https://trac.ffmpeg.org/ticket/7037

Pretty much you need to use long scripts like that https://forum.doom9.org/showthread.php?s=1e8582f9d692cbc7f04d205d05964122&p=1833683#post1833683 or

 ./src/mkvmerge \
      -o output.mkv\
      --colour-matrix 0:9 \
      --colour-range 0:1 \
      --colour-transfer-characteristics 0:16 \
      --colour-primaries 0:9 \
      --max-content-light 0:1000 \
      --max-frame-light 0:300 \
      --max-luminance 0:1000 \
      --min-luminance 0:0.01 \
      --chromaticity-coordinates 0:0.68,0.32,0.265,0.690,0.15,0.06 \
      --white-colour-coordinates 0:0.3127,0.3290 \
      input.mov 

User wants -export_HDR10 option that will copy container metatdata automatically, obviously for HDR10+/DV there will be default thing like that in the near future (HDR10+ patches are ready from Google, ETA 1-2 weeks); the obvious problem is that YOU yourself should give decoder patches to ffmpeg for that as it is decoder + encoder interconnect.

[delirio]

This is definitely a very needed feature and awaited by many. Without this, function you can’t actually encode x265 HDR videos using ffmpeg since the missing metadata.

[Mario66]

I agree that this needs attention. To tell you something about the big picture of this issue: ffmpeg, also an open source project and therefore an ally of yours, is in big trouble.

HDR videos transcoded within ffmpeg using the x265 codec are completely messed up, all HDR relevant meta data is lost. This is a very serious issue. Since more and more TV and customers adapt to HDR, more and more customers facing issues, and lots of people already move away from ffmpeg: https://trac.ffmpeg.org/ticket/7037#comment:56 This could mean fffmpeg might become obsolete.
However, ffmpeg is a great promoter of x265, ffmpeg in general promotes lots of open source codes. Your project benefits a lot from this.

Now ffmpeg needs your help. Please listen carefully to “Former user”, he has tackled this issue and thinks there is something you need to do. Please do so and stand with your open source allies. Thanks!

‌

[Former user]

Would be great to have for FFMPEG, HDR content encoding is tedious and often doesn’t work when brute-forcing HDR metadata.

[Mario66]

I think they abandoned x265, I see no response on the bug tracker here for months. Lots of other open bugs but no fixes. x265 probably shares the same fundamental flaw as ffmpeg. The developers do the first 80% of development, where it makes fun to code and you make a lot of progress. Then, when it comes to completing the implementation and making the software to work in the real world with all the little details you have to consider, like to make sure not to mess with meta data, then the developers run away and just say “I don’t care any more, makes not fun to fix this”. Probably developers already working on x266.

This way we always end up with software that is nearly close to ready and looks very promising but the last bit of coding will never be completed and therefore the software will never be actually usable by people in the real world. Too bad. I have hoped that by joining forces between you and ffmpeg we could finally find a way to make HDR content work with ffmpeg and x265 codec. But it seems that joining forces between two flawed developer communities will not lead to any substantially better result.

We have to fix the underlying flaw and that is no one cares, developers are only driven by fun and have no responsibility, causing harm to the whole idea of open source because end users are loosing trust in open source, thanks to you. They want to use software that works and was developed to the end, something they can, thanks to situations like this one, only find in commercial software. In our situation, if you want to transcode HDR videos - and HDR will be the future standard, everyone will use it - there is only the option to use commercial software that can deal with meta data because no one here or in ffmpeg is willing to develop this feature to the end.

[Nik McNulty]

I doubt MulticoreWare gives a damn about FFMPEG or anyone that uses it, because they are a commercial developer with their own commercial x265 “frontends”!

MCW only released x265 as open-source because they wanted an application base through GPLv2 adoption, similar to how x264 propagated throughout the scene all those years ago.

Understand this: MCW’s commercial products DO NOT USE FFMPEG, so they, as a company, have no interest in contributing! They’re not doing it for FUN, they are doing it for MONEY! That’s why a huge proportion of the development over the last several years provides no benefit at all to FFMPEG-using amateurs (e.g. analysis reuse).

That’s not to say that some of x265’s developers don’t use FFMPEG, or other open-source software, for their own personal projects. I have no idea who they are, but those are the people you should be asking for “patches”, not a media industry enterprise that provides expensive solutions for corporate clients who need to encode 5000 hours of real-time video a week.

Besides, if you knew anything at all about MulticoreWare, you’d know that x265 is a TINY aspect of their overall product line & direction, especially in 2020.

So, bottom line: if you want to encode HDR with x265, including full metadata management, MCW will sell you (tens of) thousands of dollars worth of stuff that will let you do that perfectly, or possibly farm you off to a licensed partner who’ll offer you the same 5-figure solution.

However, if you don’t want to BUY their products, then how you create HDR is YOUR problem, not theirs. They certainly have ZERO obligation to entertain entitled opinions like the ones I’ve been reading here.

‌

[Pradeep Ramachandran]

While I admit that the problem reported here (HDR meta-data not getting copied over when transcoding with ffmpeg), I don’t see how x265, as a library that takes in uncompressed video + meta-data and encodes it to an elementary stream can fix this. x265 doesn’t deal with, or have access to, the container at any level.

[Mario66]

Thanks for the honest answer! I didn’t know there were such big commercial interests behind x265. Then it is no wonder no one cares, MulticoreWare just doesn’t want another rival, especially none that is free and open source like ffmpeg. I was exactly right with what I said in the beginning. Only commercial companies are able to offer a complete, actually usable software. Open source failed (for now). And since MulticoreWare are the only one, no real competitor, they can charge such high prices. A situation MulticoreWare will want to keep as long as possible…

I now regret a bit that I spoke so openly about this weak spot of ffmpeg. Now MulticoreWare knows what they need to do to eliminate ffmpeg. Just sabotage as much as they can the integration of HDR meta data, e.g. hire people from ffmpeg who seem to work on that feature with high paying jobs, then let them no longer work on this feature. Or: Make the interface between x265 and ffmpeg as complicated as possible, prevent that ffmpeg can simply add HDR meta data support. And things like this. Maybe this already happened, I find it astonishing that ffmpeg just ignored this very important topic for so long. As if there was a dark force acting to prevent this feature from getting done. Just a speculation…

But it’s clear what the open source community need to do. We need to stand together, make our software actually usable, and break the monopoly of big companies like MulticoreWare. I’m sure there are a lot of smart people out there who can help to implement this feature. If you see this message please consider joining the ffmpeg team, make HDR video transcoding work in the real world, be the hero of free open source video processing. There once was a time when people had ideals, when they had the ideal that software should be free and open source. People like Richard Stallman. I can tell you this: ffmpeg will no longer be able to process “standard” videos, if you realize that HDR will be the new standard. Then ffmpeg will be dead, and free open source video processing will die with it.

[Валерий Заподовников]

“encodes it to an elementary stream”

Even static metadata can change on scene basis. Like here magnet:?xt=urn:btih:AB4E88D2999CEC65F1C59A55EE786E8DEFB0DC22

“have access to, the container at any level”

What about SEI?