[FFmpeg-devel] [PATCH] lavc/pngenc: Support writing colorspace tags.

These are defined in http://www.w3.org/TR/PNG/#11addnlcolinfo. --- libavcodec/pngenc.c | 87 + 1 file changed, 87 insertions(+) diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c index ef2..c0bce91 100644 --- a/libavcodec/pngenc.c +++

Re: [FFmpeg-devel] [FFmpeg-devel, RFC] lavfi: add opencl tonemap filter.

lso works well when viewing HDR material on HDR devices with a lower dynamic range than the original material, even when those devices are calibrated to SDR curves (search for `hdr_simulation` in that file). I hope that may provide some assistance in (ultimately) making the ffmpeg tone mapping filter as good as it can be. Thanks for reading, Niklas Haas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: fix configure check for lilv-0

From: Niklas Haas <g...@haasn.xyz> This should be included as ``, same as is done in af_lv2.c. Forcing the extra lilv-0 breaks platforms where the include dir is `/usr/include/lilv/lilv.h` rather than `/usr/include/lilv-0/lilv/lilv.h`. The new include path works for both, because the `pkg-

Re: [FFmpeg-devel] [FFmpeg-devel, RFC] lavfi: add opencl tonemap filter.

> The way my scene change detection heuristic works like this: I trigger a > scene change (and therefore discard the frame averaging buffer) if the > distance between the current frame average brightness and the current > running average exceeds a threshold value, that threshold being (by >

Re: [FFmpeg-devel] [FFmpeg-devel, RFC] lavfi: add opencl tonemap filter.

Hello Ruiling, > Thanks for sharing your idea with me. I basically also noticed some poor > quality tone mapping result for some hdr stream. > I will try your suggestion to see whether I can make it in good state so I > can include it in next version. > In fact I have not thought detecting

Re: [FFmpeg-devel] [FFmpeg-devel, RFC] lavfi: add opencl tonemap filter.

Another thing that came to my mind: On Fri, 4 May 2018 15:32:58 +0800, Ruiling Song wrote: > +static int tonemap_opencl_filter_frame(AVFilterLink *inlink, AVFrame *input) > +{ > +AVFilterContext*avctx = inlink->dst; > +AVFilterLink *outlink =

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

On Tue, 22 May 2018 08:56:37 +, "Song, Ruiling" wrote: > Yes, your idea sounds reasonable. But it may need much effort to re-structure > the code to make it (that would launch two kernels, and we may need a wait > between them) and evaluate the performance.

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

On Tue, 22 May 2018 01:18:30 +0100, Mark Thompson wrote: > On 21/05/18 07:50, Ruiling Song wrote: > > This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping. > > > > An example command to use this filter with vaapi codecs: > > FFMPEG -init_hw_device

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

> Excellent explanation. I think I get your idea. Will refine the code per your > suggestion. > But still some question, will people/tools tend to fill in the mastering > information for HLG video? > I currently see no document that recommend to fill the mastering display for > HLG. > I only

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

On Thu, 24 May 2018 08:58:22 +, "Song, Ruiling" wrote: > Where comes the "1000 cd/m² is the reference display peak"? seems no clear > statement in BT2100? The concept of there being a "standard" 1000 cd/m² display is introduced in multiple places. Refer to Table 5

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

On Mon, 21 May 2018 14:50:17 +0800, Ruiling Song wrote: > +float3 map_one_pixel_rgb(float3 rgb, float peak, float average) { > +float sig = max(max(rgb.x, max(rgb.y, rgb.z)), 1e-6f); > +// de-saturate > +if (desat_param > 0.0f) { > +float luma =

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

I see no obvious issues with the algorithm. (Though I haven't tested it) So "LGTM" On Tue, 29 May 2018 13:54:27 +0800, Ruiling Song wrote: > This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping. > > An example command to use this filter with vaapi codecs: > FFMPEG

[FFmpeg-devel] [PATCH] avfilter/af_loudnorm: correctly initialize PTS

From: Niklas Haas <g...@haasn.xyz> Right now, the PTS always starts out as 0, which causes problems on a seek or when inserting this filter mid-stream. Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first frame instead if this is the case. --- libavfilter/af_loudnorm

Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?

Hi, The important thing to consider is what constraints we are trying to solve. And I think the expected behavior is that an SDR signal in SDR mode should look identical to an SDR signal in HDR mode, to the end user. This is, of course, an impossible constraint to solve, since we don't know

Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?

Hi Harish, On Tue, 12 Feb 2019 19:43:33 +0530, Harish Krupo wrote: > Hi Niklas, > > Thanks a lot for your comments. Please find my reply inline. > > Niklas Haas writes: > > > Hi, > > > > The important thing to consider is what constraints we are trying to

Re: [FFmpeg-devel] [PATCH 2/2] hwcontext_vulkan: expose the enabled device features

Hi, I guess you already know this but just as a reminder: On Wed, 13 May 2020 17:53:33 +0200 (CEST), Lynne wrote: > +vkGetPhysicalDeviceFeatures(hwctx->phys_dev, _features); > +#define COPY_FEATURE(DST, NAME) (DST).NAME = dev_features.NAME; > +COPY_FEATURE(hwctx->device_features,

[FFmpeg-devel] [PATCH 1/2] hwcontext_vulkan: optionally enable more functionality

From: Niklas Haas These two extensions and two features are both optionally used by libplacebo to speed up rendering, so it makes sense for libavutil to automatically enable them as well. --- libavutil/hwcontext_vulkan.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libavutil

[FFmpeg-devel] [RFC] [PATCH 2/2] lavfi: add a libplacebo filter

From: Niklas Haas This filter conceptually maps the libplacebo `pl_renderer` API into libavfilter, which is a high-level image rendering API designed to produce RGB output. As such, there's no way to avoid e.g. chroma interpolation with this filter. That being said, `pl_renderer` supports

[FFmpeg-devel] [PATCH v2] lavfi: add a libplacebo filter

From: Niklas Haas This filter conceptually maps the libplacebo `pl_renderer` API into libavfilter, which is a high-level image rendering API designed to work with an RGB pipeline internally. As such, there's no way to avoid e.g. chroma interpolation with this filter, although new versions

Re: [FFmpeg-devel] [PATCH v2 2/3] libavcodec: add a new AV_CODEC_EXPORT_DATA_FILM_GRAIN flag and option

In terms of an API user needing this functionality, the way I see it working is that presence of the side-data will imply that it still needs to be applied, with the side data being removed the moment grain actually is applied. So that means that decoders applying film grain must never export this

Re: [FFmpeg-devel] [PATCH] lavfi: add a libplacebo filter

On Tue, 09 Mar 2021 23:55:36 +0100 Lynne wrote: > It's simpler because it makes no effort to integrate with anything > we use. To be clear, I agree that integration with the hwcontext is the ultimate goal. I'm just arguing about the usefulness of allowing vf_libplacebo to exist as-is until then.

Re: [FFmpeg-devel] [PATCH] lavfi: add a libplacebo filter

On Tue, 09 Mar 2021 13:53:20 -0300 James Almer wrote: > On 3/9/2021 1:38 PM, Niklas Haas wrote: > > +if (s->skip_av1_grain) > > +image.av1_grain = (struct pl_av1_grain_data) {0}; > > [...] > > > +if (!s->skip_av1_grain) > &

[FFmpeg-devel] [PATCH] lavfi: add a libplacebo filter

From: Niklas Haas This filter conceptually maps the libplacebo `pl_renderer` API into libavfilter, which is a high-level image rendering API designed to work with an RGB pipeline internally. As such, there's no way to avoid e.g. chroma interpolation with this filter, although new versions

Re: [FFmpeg-devel] [PATCH] lavfi: add a libplacebo filter

On Tue, 09 Mar 2021 22:53:18 +0100 Lynne wrote: > Sorry, as we discussed on IRC the Vulkan hwcontext should be > improved first and this filter should be kept as a pure hardware > filter. I changed my mind on this because: - I think it's reasonably self-contained as is, and actually simpler to

Re: [FFmpeg-devel] [PATCH v2 2/3] avcodec/h274: add film grain synthesis routine

On Wed, 18 Aug 2021 12:41:25 -0300 James Almer wrote: > Will this not break compilation with msvc and such? No. Unrecognized or unsupported pragmas are ignored by the implementation (this is specified C behavior). > Also, tree vectorization is know to cause issues in old GCC versions, > and

[FFmpeg-devel] [PATCH v2 2/3] avcodec/h274: add film grain synthesis routine

From: Niklas Haas This could arguably also be a vf, but I decided to put it here since decoders are technically required to apply film grain during the output step, and I would rather want to avoid requiring users insert the correct film grain synthesis filter on their own. The code, while in C

[FFmpeg-devel] [PATCH v2 3/3] avcodec/h264dec: apply H.274 film grain

From: Niklas Haas Because we need access to ref frames without film grain applied, we have to add an extra AVFrame to H264Picture to avoid messing with the original. This requires some amount of overhead to make the reference moves work out, but it allows us to benefit from frame multithreading

[FFmpeg-devel] [PATCH v2 1/3] avcodec/h264_slice: compute and export film grain seed

From: Niklas Haas >From SMPTE RDD 5-2006, the grain seed is to be computed from the following definition of `pic_offset`: > When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as > follows: > - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset &

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/h264dec: apply H.274 film grain

On Sun, 15 Aug 2021 19:11:42 +0200 Michael Niedermayer wrote: > On Sat, Aug 14, 2021 at 01:36:20PM +0200, Niklas Haas wrote: > > From: Niklas Haas > > > > Because we need access to ref frames without film grain applied, we have > > to add an extra AVFrame to H

Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec/h264dec: apply H.274 film grain

Oops, missing av_frame_unref() in the decoder uninit. Will fix. ___ 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

[FFmpeg-devel] [PATCH v3] avcodec/h264dec: apply H.274 film grain

From: Niklas Haas Because we need access to ref frames without film grain applied, we have to add an extra AVFrame to H264Picture to avoid messing with the original. This requires some amount of overhead to make the reference moves work out, but it allows us to benefit from frame multithreading

[FFmpeg-devel] [PATCH] avcodec/h264dec: fix possible out-of-bounds array access

From: Niklas Haas If slice_type is > 9, the access to ff_h264_golomb_to_pict_type is out-of-bounds. Fix this by simply setting the slice_type to 0 in this case. This is completely inconsequential because the value is only being used to being used as an offset in the calculation of the f

[FFmpeg-devel] [PATCH] avcodec/h274: slightly fix comments

From: Niklas Haas This comment was wrong. It does not require an FFT, a straight sum is enough. (An FFT is only required for high-passed grain, not generational grain) Also fix a misleading/redundant comment on avg_8x8_c - the right shift is just part of the averaging logic. --- libavcodec

[FFmpeg-devel] [PATCH 3/4] avcodec/h274: add film grain synthesis routine

From: Niklas Haas This could arguably also be a vf, but I decided to put it here since decoders are technically required to apply film grain during the output step, and I would rather want to avoid requiring users insert the correct film grain synthesis filter on their own. The code, while in C

[FFmpeg-devel] [PATCH 2/4] avcodec/h264_slice: compute and export film grain seed

From: Niklas Haas >From SMPTE RDD 5-2006, the grain seed is to be computed from the following definition of `pic_offset`: > When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as > follows: > - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset &

[FFmpeg-devel] [PATCH 4/4] avcodec/h264dec: apply H.274 film grain

From: Niklas Haas Because we need access to ref frames without film grain applied, we have to add an extra AVFrame to H264Picture to avoid messing with the original. This requires some amount of overhead to make the reference moves work out, but it allows us to benefit from frame multithreading

[FFmpeg-devel] [PATCH 1/4] avcodec/h264_sei: fix H.274 film grain parsing

From: Niklas Haas The current code reads the wrong number of bits for `fg_model_id`, which causes all of the values downstream of this to contain corrupt values. Fixes: corrupt SEI values Fixes: 4ff73add5dbe6c319d693355be44df2e17a0b8bf Signed-off-by: Niklas Haas --- libavcodec/h264_sei.c | 2

[FFmpeg-devel] [PATCH v2] avcodec/h274: don't read from uninitialized array members

From: Niklas Haas This bug flew under the radar because, in practice, these values are 0-initialized for the first invocation. But for subsequent invocations (with different h/v values), reading from the uninitialized parts of `out` is undefined behavior. Avoid this by simply adjusting

[FFmpeg-devel] [PATCH 1/2] avcodec/h274: don't read from uninitialized array members

From: Niklas Haas This bug flew under the radar because, in practice, these values are 0-initialized for the first invocation. But for subsequent invocations (with different h/v values), reading from the uninitialized parts of `out` is undefined behavior. Avoid this by simply adjusting

[FFmpeg-devel] [PATCH 2/2] avcodec/h274: trim unnecessarily large array

From: Niklas Haas We only ever read to idx+3, so 256 values are overkill. --- libavcodec/h274.c | 21 +++-- 1 file changed, 3 insertions(+), 18 deletions(-) diff --git a/libavcodec/h274.c b/libavcodec/h274.c index a59d09b66e..54e33030c2 100644 --- a/libavcodec/h274.c +++ b

Re: [FFmpeg-devel] [PATCH] avcodec/h264_sei: fix H.274 film grain parsing

On Mon, 02 Aug 2021 08:49:49 -0300 James Almer wrote: > On 8/2/2021 7:36 AM, Niklas Haas wrote: > > From: Niklas Haas > > > > The current code has a number of issues: > > 1. The fg_model_id is specified in H.274 as u(2), not u(8) > > Yes, good catch. > >

[FFmpeg-devel] [PATCH v2] avcodec/h264_sei: fix H.274 film grain parsing

From: Niklas Haas The current code reads the wrong number of bits for `fg_model_id`, which causes all of the values downstream of this to contain corrupt values. Fixes: corrupt SEI values Fixes: 4ff73add5dbe6c319d693355be44df2e17a0b8bf Signed-off-by: Niklas Haas --- libavcodec/h264_sei.c | 2

[FFmpeg-devel] [PATCH] avcodec/h264_sei: fix H.274 film grain parsing

From: Niklas Haas The current code has a number of issues: 1. The fg_model_id is specified in H.274 as u(2), not u(8) 2. This SEI has no ue(v) "repetition period", but a u(1) persistence flag Additionally, we can get away with using the non-long version of get_se_golomb() because th

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: compute and export film grain seed

On Wed, 04 Aug 2021 19:00:48 +0200 Niklas Haas wrote: > +if ((sd = av_frame_get_side_data(cur->f, > AV_FRAME_DATA_FILM_GRAIN_PARAMS))) { > +AVFilmGrainParams *fgp = (AVFilmGrainParams *) sd->data; > +fgp->seed = cur->poc + h->poc_offse

[FFmpeg-devel] [PATCH] avcodec/h264_slice: compute and export film grain seed

From: Niklas Haas >From SMPTE RDD 5-2006, the grain seed is to be computed from the following definition of `pic_offset`: > When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as > follows: > - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset &

[FFmpeg-devel] [PATCH v2] avcodec/hevcdec: apply H.274 film grain

From: Niklas Haas Similar in spirit and design to 66845cffc3bbb, but slightly simpler due to the lack of interlaced frames in HEVC. See that commit for more details. For the seed value, since no specification for this appears to exist, I semi-arbitrarily decided to base it off the POC id alone

[FFmpeg-devel] [PATCH] avcodec/hevcdec: apply H.274 film grain

From: Niklas Haas Similar in spirit and design to 66845cffc3bbb, but slightly simpler due to the lack of interlaced frames in HEVC. See that commit for more details. For the seed value, since no specification for this appears to exist, I semi-arbitrarily decided to base it off the POC id alone

[FFmpeg-devel] [PATCH v7 1/6] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas Signed-off-by: Niklas Haas --- doc/APIchanges| 3 + libavutil/dovi_meta.c | 12 libavutil/dovi_meta.h | 132 ++ libavutil/frame.c | 1 + libavutil/frame.h | 9 ++- libavutil/version.h | 2 +- 6 files

[FFmpeg-devel] [PATCH v8 6/6] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Update FATE results to match. It's worth documenting that this relies on the dovi configuration record being present on the first AVPacket fed to the decoder, which in practice is the case if if the API user has called something

[FFmpeg-devel] [PATCH v9 4/6] lavc: Implement Dolby Vision RPU parsing

From: Niklas Haas Based on a mixture of guesswork, partial documentation in patents, and reverse engineering of real-world samples. Confirmed working for all the samples I've thrown at it. Contains some annoying machinery to persist these values in between frames, which is needed in theory even

[FFmpeg-devel] [PATCH v9 6/6] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Update FATE results to match. It's worth documenting that this relies on the dovi configuration record being present on the first AVPacket fed to the decoder, which in practice is the case if if the API user has called something

[FFmpeg-devel] [PATCH v9 3/6] ffprobe: Support AV_FRAME_DATA_DOVI_METADATA

From: Jan Ekström Co-authored-by: Niklas Haas --- fftools/ffprobe.c | 173 +- 1 file changed, 170 insertions(+), 3 deletions(-) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 906bb03b16..20582ca7ac 100644 --- a/fftools/ffprobe.c +++ b

[FFmpeg-devel] [PATCH v9 2/6] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

From: Niklas Haas Signed-off-by: Niklas Haas --- libavfilter/vf_showinfo.c | 108 ++ 1 file changed, 108 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 62c7833247..909ad4f8d7 100644 --- a/libavfilter/vf_showinfo.c

[FFmpeg-devel] [PATCH v9 5/6] fate: Limit Dolby Vision RPU test frame count

From: Niklas Haas To avoid the ref for this growing to a very large size when attaching the parsed RPU side data. Since this sample does not have any dynamic metadata, two frames will serve just as well as 100. Signed-off-by: Niklas Haas --- tests/fate/hevc.mak| 2 +- tests/ref/fate

[FFmpeg-devel] [PATCH v10 4/6] lavc: Implement Dolby Vision RPU parsing

From: Niklas Haas Based on a mixture of guesswork, partial documentation in patents, and reverse engineering of real-world samples. Confirmed working for all the samples I've thrown at it. Contains some annoying machinery to persist these values in between frames, which is needed in theory even

[FFmpeg-devel] [PATCH v10 6/6] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Update FATE results to match. It's worth documenting that this relies on the dovi configuration record being present on the first AVPacket fed to the decoder, which in practice is the case if if the API user has called something

[FFmpeg-devel] [PATCH v10 1/6] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas In order to be able to extend this struct later (as the Dolby Vision RPU evolves), all of the structs are considered extensible, and the individual constituent fields must instead be accessed via offsets. The precedent for this style of access is set in Signed-off-by: Niklas

[FFmpeg-devel] [PATCH v10 3/6] ffprobe: Support AV_FRAME_DATA_DOVI_METADATA

From: Jan Ekström Co-authored-by: Niklas Haas --- fftools/ffprobe.c | 173 +- 1 file changed, 170 insertions(+), 3 deletions(-) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 906bb03b16..20582ca7ac 100644 --- a/fftools/ffprobe.c +++ b

[FFmpeg-devel] [PATCH v10 2/6] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

From: Niklas Haas Signed-off-by: Niklas Haas --- libavfilter/vf_showinfo.c | 108 ++ 1 file changed, 108 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 62c7833247..909ad4f8d7 100644 --- a/libavfilter/vf_showinfo.c

[FFmpeg-devel] [PATCH v10 5/6] fate: Limit Dolby Vision RPU test frame count

From: Niklas Haas To avoid the ref for this growing to a very large size when attaching the parsed RPU side data. Since this sample does not have any dynamic metadata, two frames will serve just as well as 100. Signed-off-by: Niklas Haas --- tests/fate/hevc.mak| 2 +- tests/ref/fate

[FFmpeg-devel] [PATCH] lavfi/libplacebo: support dovi metadata application

From: Niklas Haas libplacebo supports automatic dolby vision application, but it requires us to switch to a new API. Also add some logic to strip the dolby vision metadata from the output frames in any case where we end up changing the colorimetry. The libplacebo dependency bump is justified

Re: [FFmpeg-devel] [PATCH v10 1/6] lavu/frame: Add Dolby Vision metadata side data type

On Mon, 03 Jan 2022 01:27:22 +0100 Niklas Haas wrote: > +/** > + * Dolby Vision RPU data mapping parameters. > + * > + * @note sizeof(AVDOVIDataMapping) is not part of the public ABI. > + */ > +typedef struct AVDOVIDataMapping { > +uint8_t vdr_rpu_id; > +uin

[FFmpeg-devel] [PATCH v9 1/6] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas In order to be able to extend this struct later (as the Dolby Vision RPU evolves), all of the structs are considered extensible, and the individual constituent fields must instead be accessed via offsets. The precedent for this style of access is set in Signed-off-by: Niklas

Re: [FFmpeg-devel] GitHub Integration

On Tue, 28 Dec 2021 00:59:58 +1000 Zane van Iperen wrote: > > > On 27/12/21 11:41, lance.lmw...@gmail.com wrote: > > On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote: > >> > >>> I'm not sure. My

[FFmpeg-devel] [PATCH v11] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas Yeah, I think I agree that this is probably the best compromise here. Updated documentation (and also changed one unnecessarily-large uint64_t to uint16_t) --- In order to be able to extend this struct later (as the Dolby Vision RPU evolves), all of the 'container' structs

[FFmpeg-devel] [PATCH v8 4/6] lavc: Implement Dolby Vision RPU parsing

From: Niklas Haas Based on a mixture of guesswork, partial documentation in patents, and reverse engineering of real-world samples. Confirmed working for all the samples I've thrown at it. Contains some annoying machinery to persist these values in between frames, which is needed in theory even

[FFmpeg-devel] [PATCH v8 2/6] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

From: Niklas Haas Signed-off-by: Niklas Haas --- libavfilter/vf_showinfo.c | 108 ++ 1 file changed, 108 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 62c7833247..eb6684558a 100644 --- a/libavfilter/vf_showinfo.c

[FFmpeg-devel] [PATCH v8 1/6] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas Signed-off-by: Niklas Haas --- doc/APIchanges| 3 + libavutil/dovi_meta.c | 12 libavutil/dovi_meta.h | 143 ++ libavutil/frame.c | 1 + libavutil/frame.h | 9 ++- libavutil/version.h | 2 +- 6 files

[FFmpeg-devel] [PATCH v8 3/6] ffprobe: Support AV_FRAME_DATA_DOVI_METADATA

From: Jan Ekström Co-authored-by: Niklas Haas --- fftools/ffprobe.c | 173 +- 1 file changed, 170 insertions(+), 3 deletions(-) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 0711e02922..75263cd3a9 100644 --- a/fftools/ffprobe.c +++ b

[FFmpeg-devel] [PATCH v8 5/6] fate: Limit Dolby Vision RPU test frame count

From: Niklas Haas To avoid the ref for this growing to a very large size when attaching the parsed RPU side data. Since this sample does not have any dynamic metadata, two frames will serve just as well as 100. Signed-off-by: Niklas Haas --- tests/fate/hevc.mak| 2 +- tests/ref/fate

[FFmpeg-devel] [PATCH v7 4/6] lavc: Implement Dolby Vision RPU parsing

From: Niklas Haas Based on a mixture of guesswork, partial documentation in patents, and reverse engineering of real-world samples. Confirmed working for all the samples I've thrown at it. Contains some annoying machinery to persist these values in between frames, which is needed in theory even

[FFmpeg-devel] [PATCH v7 6/6] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Update FATE results to match. It's worth documenting that this relies on the dovi configuration record being present on the first AVPacket fed to the decoder, which in practice is the case if if the API user has called something

[FFmpeg-devel] [PATCH v7 3/6] ffprobe: Support AV_FRAME_DATA_DOVI_METADATA

From: Jan Ekström Co-authored-by: Niklas Haas --- fftools/ffprobe.c | 173 +- 1 file changed, 170 insertions(+), 3 deletions(-) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 0711e02922..75263cd3a9 100644 --- a/fftools/ffprobe.c +++ b

[FFmpeg-devel] [PATCH v7 2/6] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

From: Niklas Haas Signed-off-by: Niklas Haas --- libavfilter/vf_showinfo.c | 108 ++ 1 file changed, 108 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 62c7833247..8a7efc15b7 100644 --- a/libavfilter/vf_showinfo.c

[FFmpeg-devel] [PATCH v7 5/6] fate: Limit Dolby Vision RPU test frame count

From: Niklas Haas To avoid the ref for this growing to a very large size when attaching the parsed RPU side data. Since this sample does not have any dynamic metadata, two frames will serve just as well as 100. Signed-off-by: Niklas Haas --- tests/fate/hevc.mak| 2 +- tests/ref/fate

Re: [FFmpeg-devel] [PATCH v5 4/6] lavc: Implement Dolby Vision RPU parsing

On Mon, 20 Dec 2021 11:13:15 +0100 Anton Khirnov wrote: > nit: FF_ARRAY_ELEMS(s->vdr_ref) is considered better Done. > Would not calling ff_dovi_ctx_unref() be safer here? Good point, changed. > This is only used for logging (as it should be), so you can make this > void *logctx and drop the

[FFmpeg-devel] [PATCH v2] lavfi: add a libplacebo filter

From: Niklas Haas This filter conceptually maps the libplacebo `pl_renderer` API into libavfilter, which is a high-level image rendering API designed to work with an RGB pipeline internally. As such, there's no way to avoid e.g. chroma interpolation with this filter, although new versions

[FFmpeg-devel] [PATCH] lavfi/vf_libplacebo: pick log level dynamically

From: Niklas Haas In particular, allows users to go all the way up to PL_LOG_TRACE if desired. (While also avoiding some potentially unnecessary callbacks for filtered messages, including e.g. the CPU cost of printing out shader sources) Response to runtime log level changes by updating it once

Re: [FFmpeg-devel] [PATCH 0/14] Vulkan fixes and improvements

> > it's bug-free and extendable. > > > > Of interest to anyone who's only interested in public API changes > > are patches 2/14 and 6/14. The changes made are backwards compatible, > > and will not break API users. > > > > I've collaborated with Niklas H

Re: [FFmpeg-devel] [PATCH v2 1/4] lavu/frame: Add Dolby Vision metadata side data type

On Thu, 09 Dec 2021 17:21:58 + Derek Buitenhuis wrote: > On 12/8/2021 10:12 AM, Niklas Haas wrote: > > +/* based on guesswork, see mkvtoolnix and dovi_tool */ > > +int av_dovi_profile(const AVDOVIRpuDataHeader *hdr) > > +{ > > The correct way to find the profi

[FFmpeg-devel] [PATCH v3] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Signed-off-by: Niklas Haas --- libavcodec/hevcdec.c | 32 ++-- libavcodec/hevcdec.h | 2 ++ 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/libavcodec/hevcdec.c b/libavcodec

[FFmpeg-devel] [PATCH v2 3/4] lavc: Implement Dolby Vision RPU parsing

From: Niklas Haas Based on a mixture of guesswork, partial documentation in patents, and reverse engineering of real-world samples. Confirmed working for all the samples I've thrown at it. Contains some annoying machinery to persist these values in between frames, which is needed in theory even

[FFmpeg-devel] [PATCH v2 1/4] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas Signed-off-by: Niklas Haas --- doc/APIchanges| 3 ++ libavutil/dovi_meta.c | 23 libavutil/dovi_meta.h | 122 ++ libavutil/frame.c | 1 + libavutil/frame.h | 9 +++- libavutil/version.h | 2 +- 6

[FFmpeg-devel] [PATCH v2 2/4] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

From: Niklas Haas Signed-off-by: Niklas Haas --- libavfilter/vf_showinfo.c | 108 ++ 1 file changed, 108 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 62c7833247..79294f6891 100644 --- a/libavfilter/vf_showinfo.c

[FFmpeg-devel] [PATCH v2 4/4] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Signed-off-by: Niklas Haas --- libavcodec/hevcdec.c | 34 +++--- libavcodec/hevcdec.h | 2 ++ 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/libavcodec/hevcdec.c b/libavcodec

[FFmpeg-devel] [PATCH 4/4] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Signed-off-by: Niklas Haas --- libavcodec/hevcdec.c | 32 ++-- libavcodec/hevcdec.h | 2 ++ 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/libavcodec/hevcdec.c b/libavcodec

[FFmpeg-devel] [PATCH 3/4] lavc: Implement Dolby Vision RPU parsing

From: Niklas Haas Based on a mixture of guesswork, partial documentation in patents, and reverse engineering of real-world samples. Confirmed working for all the samples I've thrown at it. Contains some annoying machinery to persist these values in between frames, which is needed in theory even

[FFmpeg-devel] [PATCH 2/4] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

From: Niklas Haas Signed-off-by: Niklas Haas --- libavfilter/vf_showinfo.c | 108 ++ 1 file changed, 108 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 62c7833247..79294f6891 100644 --- a/libavfilter/vf_showinfo.c

[FFmpeg-devel] [PATCH 1/4] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas Signed-off-by: Niklas Haas --- doc/APIchanges| 3 ++ libavutil/dovi_meta.c | 23 libavutil/dovi_meta.h | 121 ++ libavutil/frame.c | 1 + libavutil/frame.h | 9 +++- libavutil/version.h | 2 +- 6

[FFmpeg-devel] [PATCH v5 6/6] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas And expose the parsed values as frame side data. Update FATE results to match. It's worth documenting that this relies on the dovi configuration record being present on the first AVPacket fed to the decoder, which in practice is the case if if the API user has called something

[FFmpeg-devel] [PATCH v5 4/6] lavc: Implement Dolby Vision RPU parsing

From: Niklas Haas Based on a mixture of guesswork, partial documentation in patents, and reverse engineering of real-world samples. Confirmed working for all the samples I've thrown at it. Contains some annoying machinery to persist these values in between frames, which is needed in theory even

[FFmpeg-devel] [PATCH v5 1/6] lavu/frame: Add Dolby Vision metadata side data type

From: Niklas Haas Signed-off-by: Niklas Haas --- doc/APIchanges| 3 + libavutil/dovi_meta.c | 12 libavutil/dovi_meta.h | 132 ++ libavutil/frame.c | 1 + libavutil/frame.h | 9 ++- libavutil/version.h | 2 +- 6 files

[FFmpeg-devel] [PATCH v5 3/6] ffprobe: Support AV_FRAME_DATA_DOVI_METADATA

From: Jan Ekström Co-authored-by: Niklas Haas --- fftools/ffprobe.c | 173 +- 1 file changed, 170 insertions(+), 3 deletions(-) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 0711e02922..75263cd3a9 100644 --- a/fftools/ffprobe.c +++ b

[FFmpeg-devel] [PATCH v5 2/6] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

From: Niklas Haas Signed-off-by: Niklas Haas --- libavfilter/vf_showinfo.c | 108 ++ 1 file changed, 108 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 62c7833247..8a7efc15b7 100644 --- a/libavfilter/vf_showinfo.c

[FFmpeg-devel] [PATCH v5 5/6] fate: Limit Dolby Vision RPU test frame count

From: Niklas Haas To avoid the ref for this growing to a very large size when attaching the parsed RPU side data. Since this sample does not have any dynamic metadata, two frames will serve just as well as 100. Signed-off-by: Niklas Haas --- tests/fate/hevc.mak| 2 +- tests/ref/fate

[FFmpeg-devel] [PATCH v6] lavc/hevcdec: Parse DOVI RPU NALs

From: Niklas Haas Oops. The previous version of this patch forgot to actually forward the dovi configuration record to the DOVIContext. --- And expose the parsed values as frame side data. Update FATE results to match. It's worth documenting that this relies on the dovi configuration record

Re: [FFmpeg-devel] [PATCH v4 2/5] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

On Sat, 11 Dec 2021 13:58:53 +0100 Andreas Rheinhardt wrote: > Why are you using so many av_log calls? Every one of them poses the risk > of the output being torn apart by other av_log calls (with a different > logctx); and of course, it also leads to lower performance and bigger > binary size.

Re: [FFmpeg-devel] [PATCH v4 4/5] lavc: Implement Dolby Vision RPU parsing

On Sat, 11 Dec 2021 15:02:14 +0100 Andreas Rheinhardt wrote: > verification Fixed > lavu Fixed > Why is this always compiled when only the HEVC decoder needs it? > (The way it is now will cause linking errors when CONFIG_GOLOMB is false.) In principle, parsing the RPU contents is orthogonal

Re: [FFmpeg-devel] [PATCH] hwcontext_vulkan: make 2 public functions always available

On Thu, 02 Dec 2021 19:13:17 +0100 Andreas Rheinhardt wrote: > Lynne: > > The issue is that if ffmpeg is compiled without Vulkan, and an API > > user includes and uses the functions exposed in hwcontext_vulkan.h, > > then a linking error will happen, as the hwcontext_vulkan.c file has > > not

[FFmpeg-devel] [PATCH] vf_libplacebo: switch to newer libplacebo helpers

From: Niklas Haas Support for mapping/unmapping hardware frames has been added into libplacebo itself, so we can scrap this code in favor of using the new functions. This has the additional benefit of being forwards-compatible as support for more complicated frame-related state management

  1   2   3   4   5   6   7   8   >