From: Niklas Haas <ffmpeg@haasn.xyz>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Cosmin Stejerean <cosmin@cosmin.at>
Subject: Re: [FFmpeg-devel] [PATCH 4/4] avcodec/libx265: encode dovi RPUs
Date: Thu, 21 Mar 2024 13:09:55 +0100
Message-ID: <20240321130955.GF11428@haasn.xyz> (raw)
In-Reply-To: <CABLWnS9Nn-nm_UtE_+jAucNMR0i8rjYUZ1M0wz8Mfff9zVzUQA@mail.gmail.com>
On Tue, 19 Mar 2024 19:19:29 -0400 Vittorio Giovara <vittorio.giovara@gmail.com> wrote:
> On Tue, Mar 19, 2024 at 7:04 PM Niklas Haas <ffmpeg@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.buitenhuis@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?
Adding a flag to the encoder to control whether to write dolby vision
RPUs (defaulting to off) seems like a good idea. At some level, we
fundamentally have to rely on the user to tell us whether dolby vision
metadata is still valid after filtering.
There is still the separate concern of how to control whether or not
a dovi *configuration* record should be emitted when muxing, which
should be done on a remux but should not be done on a decode or when
stripping DV metadata.
That said, including a dolby configuration record but without
corresponding RPUs at the very least appears to be harmless, though
I have not verified with actual hardware.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-03-21 12:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 19:16 [FFmpeg-devel] [PATCH 1/4] fftools/ffmpeg_enc: strip DOVI config record for AV1 Niklas Haas
2024-03-19 19:16 ` [FFmpeg-devel] [PATCH 2/4] avcodec/dovi_rpu: implement T.35 payload synthesis Niklas Haas
2024-03-19 19:16 ` [FFmpeg-devel] [PATCH 3/4] avcodec/libaomenc: encode dovi RPUs as T.35 metadata Niklas Haas
2024-03-19 19:16 ` [FFmpeg-devel] [PATCH 4/4] avcodec/libx265: encode dovi RPUs Niklas Haas
2024-03-19 21:39 ` Derek Buitenhuis
[not found] ` <9183F034-A7F5-4683-A932-273E15B9886C@cosmin.at>
2024-03-19 21:59 ` Cosmin Stejerean via ffmpeg-devel
2024-03-19 23:04 ` Niklas Haas
2024-03-19 23:19 ` Vittorio Giovara
2024-03-21 12:09 ` Niklas Haas [this message]
2024-03-20 19:30 ` Michael Niedermayer
2024-03-20 21:22 ` Jan Ekström
2024-03-21 12:02 ` Niklas Haas
2024-03-21 10:16 ` [FFmpeg-devel] [PATCH 1/4] fftools/ffmpeg_enc: strip DOVI config record for AV1 Anton Khirnov
2024-03-21 12:11 ` Niklas Haas
2024-03-22 9:41 ` Anton Khirnov
2024-03-22 13:08 ` Niklas Haas
2024-03-22 17:04 ` Niklas Haas
2024-03-23 17:45 ` Niklas Haas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240321130955.GF11428@haasn.xyz \
--to=ffmpeg@haasn.xyz \
--cc=cosmin@cosmin.at \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git