On Tue, Mar 19, 2024 at 7:04 PM Niklas Haas <ffm...@haasn.xyz> wrote:
> On Tue, 19 Mar 2024 21:59:53 +0000 Cosmin Stejerean via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > On Mar 19, 2024, at 2:39 PM, Derek Buitenhuis < > derek.buitenh...@gmail.com> wrote: > > > > > > The reason I never implemented this back when I adde RPU side data is > that > > > there is a strong chance of generating broken files. > > > > > > That's because if we do anything to the video with swscale, etc., we're > > > now encoding RPUs that aren't meant to be applied to that converted > video. > > > > > > For example, this could end up propagating RPUs when the user is > tonemapping. > > > > Would it be possible to only propagate RPUs if the color params are not > changing? If there's any change from say PQ to HLG or HLG to PQ or > tonemapping then we wouldn't want to propagate RPUs. If the color params > are not changing then propagating RPUs by default seems sensible, and > perhaps a filter can be added to explicitly clear RPUs if they should not > be propagated. > > One way to accomplish this would be to simply strip the metadata in all > filters > that can change the colorspace. Maybe we should do the same for HDR+ etc. > metadata. > > Probably it would make sense to add a common helper function for this. > I'll see > what I can do. > In the meantime maybe just adding an encoder option to preserve existing metadata would help? -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
