Re: [FFmpeg-devel] [PATCH v1] avformat/rtmpproto: support fourCcList property in enhanced rtmp
Jean-Baptiste Kempf 于2023年8月20日周日 16:29写道： > > Hello, Hi > > On Sun, 20 Aug 2023, at 06:10, Steven Liu wrote: > > As the enhanced rtmp Extending NetConnection connect Command section > > said, the rtmp should add a property named fourCcLive, but there should > > only one codec can be set for the video stream in rtmp+flv, so user can > > use the option rtmp_enhanced_flags to set the enhanced rtmp with av1, > > hevc or vp9. > > Technically, the protocol allows any type of FourCC, no? The protocol should allows any type of FourCC, i saw there have three codecs in the example["av01", "vp09", "hvc1"]. I think not all servers support fourCcList in connect command, so this should set by user. Thanks Steven ___ 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".
Re: [FFmpeg-devel] [PATCH] hwcontext_vulkan: always use create_pnext in vulkan_pool_alloc
Aug 20, 2023, 20:36 by spence...@gmail.com: > Currently, create_pnext is only used if an applicable external memory > extension is enabled. This will usually the case when used from the command > line, but may not be when the Vulkan context is created manually. > > For images used in video decoding, create_pnext contains the video profile > list, which is mandatory.[1] This fixes a GPU crash when using RADV. > > [1] > https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageCreateInfo.html#VUID-VkImageCreateInfo-usage-04815 > > Signed-off-by: Chris Spencer > --- > libavutil/hwcontext_vulkan.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c > index 75314f1407..54faf16a69 100644 > --- a/libavutil/hwcontext_vulkan.c > +++ b/libavutil/hwcontext_vulkan.c > @@ -2179,7 +2179,8 @@ static AVBufferRef *vulkan_pool_alloc(void *opaque, > size_t size) > } > > err = create_frame(hwfc, , hwctx->tiling, hwctx->usage, hwctx->img_flags, > - hwctx->nb_layers, eiinfo.handleTypes ? : > NULL); > + hwctx->nb_layers, > + eiinfo.handleTypes ? : hwctx->create_pnext); > if (err) > return NULL; > Thanks, pushed. ___ 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".
[FFmpeg-devel] [PATCH] hwcontext_vulkan: always use create_pnext in vulkan_pool_alloc
Currently, create_pnext is only used if an applicable external memory extension is enabled. This will usually the case when used from the command line, but may not be when the Vulkan context is created manually. For images used in video decoding, create_pnext contains the video profile list, which is mandatory.[1] This fixes a GPU crash when using RADV. [1] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageCreateInfo.html#VUID-VkImageCreateInfo-usage-04815 Signed-off-by: Chris Spencer --- libavutil/hwcontext_vulkan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c index 75314f1407..54faf16a69 100644 --- a/libavutil/hwcontext_vulkan.c +++ b/libavutil/hwcontext_vulkan.c @@ -2179,7 +2179,8 @@ static AVBufferRef *vulkan_pool_alloc(void *opaque, size_t size) } err = create_frame(hwfc, , hwctx->tiling, hwctx->usage, hwctx->img_flags, - hwctx->nb_layers, eiinfo.handleTypes ? : NULL); + hwctx->nb_layers, + eiinfo.handleTypes ? : hwctx->create_pnext); if (err) return NULL; -- 2.41.0 ___ 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".
Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion
On Sun, 20 Aug 2023 19:45:11 +0200, you wrote: >On Sun, Aug 20, 2023 at 07:16:14PM +0200, Michael Niedermayer wrote: >> On Sun, Aug 20, 2023 at 03:10:19PM +, John Cox wrote: >> > Add a rgb24->yuv420p conversion. Uses the same code as the existing >> > bgr24->yuv converter but permutes the conversion array to swap R & B >> > coefficients. >> > >> > Signed-off-by: John Cox >> > --- >> > libswscale/rgb2rgb.c | 5 + >> > libswscale/rgb2rgb.h | 7 +++ >> > libswscale/rgb2rgb_template.c | 38 ++- >> > libswscale/swscale_unscaled.c | 24 +- >> > 4 files changed, 68 insertions(+), 6 deletions(-) >> > >> > diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c >> > index 8707917800..de90e5193f 100644 >> > --- a/libswscale/rgb2rgb.c >> > +++ b/libswscale/rgb2rgb.c >> > @@ -83,6 +83,11 @@ void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t >> > *ydst, >> > int width, int height, >> > int lumStride, int chromStride, int srcStride, >> > int32_t *rgb2yuv); >> > +void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, >> > + uint8_t *udst, uint8_t *vdst, >> > + int width, int height, >> > + int lumStride, int chromStride, int srcStride, >> > + int32_t *rgb2yuv); >> > void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int height, >> > int srcStride, int dstStride); >> > void (*interleaveBytes)(const uint8_t *src1, const uint8_t *src2, uint8_t >> > *dst, >> > diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h >> > index 305b830920..f7a76a92ba 100644 >> > --- a/libswscale/rgb2rgb.h >> > +++ b/libswscale/rgb2rgb.h >> > @@ -79,6 +79,9 @@ voidrgb12to15(const uint8_t *src, uint8_t *dst, int >> > src_size); >> > void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, >> >uint8_t *vdst, int width, int height, int lumStride, >> >int chromStride, int srcStride, int32_t *rgb2yuv); >> > +void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, >> > + uint8_t *vdst, int width, int height, int lumStride, >> > + int chromStride, int srcStride, int32_t *rgb2yuv); >> > >> > /** >> > * Height should be a multiple of 2 and width should be a multiple of 16. >> > @@ -128,6 +131,10 @@ extern void (*ff_bgr24toyv12)(const uint8_t *src, >> > uint8_t *ydst, uint8_t *udst, >> >int width, int height, >> >int lumStride, int chromStride, int >> > srcStride, >> >int32_t *rgb2yuv); >> > +extern void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t >> > *udst, uint8_t *vdst, >> > + int width, int height, >> > + int lumStride, int chromStride, int >> > srcStride, >> > + int32_t *rgb2yuv); >> > extern void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int >> > height, >> > int srcStride, int dstStride); >> > >> > diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c >> > index 8ef4a2cf5d..e57bfa6545 100644 >> > --- a/libswscale/rgb2rgb_template.c >> > +++ b/libswscale/rgb2rgb_template.c >> >> >> > @@ -646,13 +646,14 @@ static inline void uyvytoyv12_c(const uint8_t *src, >> > uint8_t *ydst, >> > * others are ignored in the C version. >> > * FIXME: Write HQ version. >> > */ >> > -void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, >> > +static void rgb24toyv12_x(const uint8_t *src, uint8_t *ydst, uint8_t >> > *udst, >> >> this probably should be inline >> >> also i see now "FIXME: Write HQ version." above here. Do you really want to >> add a low quality rgb24toyv12 ? >> (it is vissible on the diagonal border (cyan / red )) in >> ./ffmpeg -f lavfi -i testsrc=size=5632x3168 -pix_fmt yuv420p -vframes 1 >> -qscale 1 -strict -1 new.jpg >> >> also on smaller sizes but for some reason its clearer on the big one zoomed >> in 400% with gimp >> (the gimp test was done with the whole patchset not after this patch) > >Also the reason why its LQ and looks like it does is because >1. half the RGB samples are ignored in computing the chroma samples I thought it was a bit light but it is what the existing code did >2. the chroma sample locations are ignored, the locations for yuv420 are >reaonable standard As I recall MPEG-1 has chroma at (0.5, 0.5), MPEG-II defaults to (0.5, 0), H.265 defaults to (0,0). Printing out dst_h_chr_pos, dst_v_chr_pos in the setup of your example yields -513, 128 which I'm guessing means (unset, 0.5) - am I looking at the correct vars? >this needs some simple filter to get from a few RGB samples to the RGB sample >co-located >with
Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion
On Sun, 20 Aug 2023 19:16:14 +0200, you wrote: >On Sun, Aug 20, 2023 at 03:10:19PM +, John Cox wrote: >> Add a rgb24->yuv420p conversion. Uses the same code as the existing >> bgr24->yuv converter but permutes the conversion array to swap R & B >> coefficients. >> >> Signed-off-by: John Cox >> --- >> libswscale/rgb2rgb.c | 5 + >> libswscale/rgb2rgb.h | 7 +++ >> libswscale/rgb2rgb_template.c | 38 ++- >> libswscale/swscale_unscaled.c | 24 +- >> 4 files changed, 68 insertions(+), 6 deletions(-) >> >> diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c >> index 8707917800..de90e5193f 100644 >> --- a/libswscale/rgb2rgb.c >> +++ b/libswscale/rgb2rgb.c >> @@ -83,6 +83,11 @@ void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t *ydst, >> int width, int height, >> int lumStride, int chromStride, int srcStride, >> int32_t *rgb2yuv); >> +void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, >> + uint8_t *udst, uint8_t *vdst, >> + int width, int height, >> + int lumStride, int chromStride, int srcStride, >> + int32_t *rgb2yuv); >> void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int height, >> int srcStride, int dstStride); >> void (*interleaveBytes)(const uint8_t *src1, const uint8_t *src2, uint8_t >> *dst, >> diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h >> index 305b830920..f7a76a92ba 100644 >> --- a/libswscale/rgb2rgb.h >> +++ b/libswscale/rgb2rgb.h >> @@ -79,6 +79,9 @@ voidrgb12to15(const uint8_t *src, uint8_t *dst, int >> src_size); >> void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, >>uint8_t *vdst, int width, int height, int lumStride, >>int chromStride, int srcStride, int32_t *rgb2yuv); >> +void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, >> + uint8_t *vdst, int width, int height, int lumStride, >> + int chromStride, int srcStride, int32_t *rgb2yuv); >> >> /** >> * Height should be a multiple of 2 and width should be a multiple of 16. >> @@ -128,6 +131,10 @@ extern void (*ff_bgr24toyv12)(const uint8_t *src, >> uint8_t *ydst, uint8_t *udst, >>int width, int height, >>int lumStride, int chromStride, int srcStride, >>int32_t *rgb2yuv); >> +extern void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t >> *udst, uint8_t *vdst, >> + int width, int height, >> + int lumStride, int chromStride, int srcStride, >> + int32_t *rgb2yuv); >> extern void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int >> height, >> int srcStride, int dstStride); >> >> diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c >> index 8ef4a2cf5d..e57bfa6545 100644 >> --- a/libswscale/rgb2rgb_template.c >> +++ b/libswscale/rgb2rgb_template.c > > >> @@ -646,13 +646,14 @@ static inline void uyvytoyv12_c(const uint8_t *src, >> uint8_t *ydst, >> * others are ignored in the C version. >> * FIXME: Write HQ version. >> */ >> -void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, >> +static void rgb24toyv12_x(const uint8_t *src, uint8_t *ydst, uint8_t *udst, > >this probably should be inline Could do, and I will if you deem it important, but the only bit that inline is going to help is the matrix coefficient loading and that happens once outside the main loops. >also i see now "FIXME: Write HQ version." above here. Do you really want to >add a low quality rgb24toyv12 ? >(it is vissible on the diagonal border (cyan / red )) in > ./ffmpeg -f lavfi -i testsrc=size=5632x3168 -pix_fmt yuv420p -vframes 1 > -qscale 1 -strict -1 new.jpg > > also on smaller sizes but for some reason its clearer on the big one zoomed > in 400% with gimp >(the gimp test was done with the whole patchset not after this patch) On the whole - yes - in the encode path on the Pi that I'm writing this for speed is more important than quality - the existing path is too slow to be usable. And honestly - using your example above comparing (Windows photo viewer zoomed in s.t. pixels are clearly individually visible) the general (bitexact), presumably HQ, output vs the new code I grant that the new is slightly muckier but not by a huge amount - sharp chroma transitions in 420 are always nasty. >[...] >> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c >> index 32e0d7f63c..751bdcb2e4 100644 >> --- a/libswscale/swscale_unscaled.c >> +++ b/libswscale/swscale_unscaled.c >> @@ -1654,6 +1654,23 @@ static int bgr24ToYv12Wrapper(SwsContext *c, const
Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion
On Sun, Aug 20, 2023 at 07:16:14PM +0200, Michael Niedermayer wrote: > On Sun, Aug 20, 2023 at 03:10:19PM +, John Cox wrote: > > Add a rgb24->yuv420p conversion. Uses the same code as the existing > > bgr24->yuv converter but permutes the conversion array to swap R & B > > coefficients. > > > > Signed-off-by: John Cox > > --- > > libswscale/rgb2rgb.c | 5 + > > libswscale/rgb2rgb.h | 7 +++ > > libswscale/rgb2rgb_template.c | 38 ++- > > libswscale/swscale_unscaled.c | 24 +- > > 4 files changed, 68 insertions(+), 6 deletions(-) > > > > diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c > > index 8707917800..de90e5193f 100644 > > --- a/libswscale/rgb2rgb.c > > +++ b/libswscale/rgb2rgb.c > > @@ -83,6 +83,11 @@ void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t *ydst, > > int width, int height, > > int lumStride, int chromStride, int srcStride, > > int32_t *rgb2yuv); > > +void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, > > + uint8_t *udst, uint8_t *vdst, > > + int width, int height, > > + int lumStride, int chromStride, int srcStride, > > + int32_t *rgb2yuv); > > void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int height, > > int srcStride, int dstStride); > > void (*interleaveBytes)(const uint8_t *src1, const uint8_t *src2, uint8_t > > *dst, > > diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h > > index 305b830920..f7a76a92ba 100644 > > --- a/libswscale/rgb2rgb.h > > +++ b/libswscale/rgb2rgb.h > > @@ -79,6 +79,9 @@ voidrgb12to15(const uint8_t *src, uint8_t *dst, int > > src_size); > > void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, > >uint8_t *vdst, int width, int height, int lumStride, > >int chromStride, int srcStride, int32_t *rgb2yuv); > > +void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, > > + uint8_t *vdst, int width, int height, int lumStride, > > + int chromStride, int srcStride, int32_t *rgb2yuv); > > > > /** > > * Height should be a multiple of 2 and width should be a multiple of 16. > > @@ -128,6 +131,10 @@ extern void (*ff_bgr24toyv12)(const uint8_t *src, > > uint8_t *ydst, uint8_t *udst, > >int width, int height, > >int lumStride, int chromStride, int > > srcStride, > >int32_t *rgb2yuv); > > +extern void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t > > *udst, uint8_t *vdst, > > + int width, int height, > > + int lumStride, int chromStride, int > > srcStride, > > + int32_t *rgb2yuv); > > extern void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int > > height, > > int srcStride, int dstStride); > > > > diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c > > index 8ef4a2cf5d..e57bfa6545 100644 > > --- a/libswscale/rgb2rgb_template.c > > +++ b/libswscale/rgb2rgb_template.c > > > > @@ -646,13 +646,14 @@ static inline void uyvytoyv12_c(const uint8_t *src, > > uint8_t *ydst, > > * others are ignored in the C version. > > * FIXME: Write HQ version. > > */ > > -void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst, > > +static void rgb24toyv12_x(const uint8_t *src, uint8_t *ydst, uint8_t *udst, > > this probably should be inline > > also i see now "FIXME: Write HQ version." above here. Do you really want to > add a low quality rgb24toyv12 ? > (it is vissible on the diagonal border (cyan / red )) in > ./ffmpeg -f lavfi -i testsrc=size=5632x3168 -pix_fmt yuv420p -vframes 1 > -qscale 1 -strict -1 new.jpg > > also on smaller sizes but for some reason its clearer on the big one zoomed > in 400% with gimp > (the gimp test was done with the whole patchset not after this patch) Also the reason why its LQ and looks like it does is because 1. half the RGB samples are ignored in computing the chroma samples 2. the chroma sample locations are ignored, the locations for yuv420 are reaonable standard this needs some simple filter to get from a few RGB samples to the RGB sample co-located with ths UV sample before RGB->UV thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ 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
Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion
On Sun, Aug 20, 2023 at 03:10:19PM +, John Cox wrote:
> Add a rgb24->yuv420p conversion. Uses the same code as the existing
> bgr24->yuv converter but permutes the conversion array to swap R & B
> coefficients.
>
> Signed-off-by: John Cox
> ---
> libswscale/rgb2rgb.c | 5 +
> libswscale/rgb2rgb.h | 7 +++
> libswscale/rgb2rgb_template.c | 38 ++-
> libswscale/swscale_unscaled.c | 24 +-
> 4 files changed, 68 insertions(+), 6 deletions(-)
>
> diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c
> index 8707917800..de90e5193f 100644
> --- a/libswscale/rgb2rgb.c
> +++ b/libswscale/rgb2rgb.c
> @@ -83,6 +83,11 @@ void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t *ydst,
> int width, int height,
> int lumStride, int chromStride, int srcStride,
> int32_t *rgb2yuv);
> +void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst,
> + uint8_t *udst, uint8_t *vdst,
> + int width, int height,
> + int lumStride, int chromStride, int srcStride,
> + int32_t *rgb2yuv);
> void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int height,
> int srcStride, int dstStride);
> void (*interleaveBytes)(const uint8_t *src1, const uint8_t *src2, uint8_t
> *dst,
> diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h
> index 305b830920..f7a76a92ba 100644
> --- a/libswscale/rgb2rgb.h
> +++ b/libswscale/rgb2rgb.h
> @@ -79,6 +79,9 @@ voidrgb12to15(const uint8_t *src, uint8_t *dst, int
> src_size);
> void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
>uint8_t *vdst, int width, int height, int lumStride,
>int chromStride, int srcStride, int32_t *rgb2yuv);
> +void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
> + uint8_t *vdst, int width, int height, int lumStride,
> + int chromStride, int srcStride, int32_t *rgb2yuv);
>
> /**
> * Height should be a multiple of 2 and width should be a multiple of 16.
> @@ -128,6 +131,10 @@ extern void (*ff_bgr24toyv12)(const uint8_t *src,
> uint8_t *ydst, uint8_t *udst,
>int width, int height,
>int lumStride, int chromStride, int srcStride,
>int32_t *rgb2yuv);
> +extern void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t
> *udst, uint8_t *vdst,
> + int width, int height,
> + int lumStride, int chromStride, int srcStride,
> + int32_t *rgb2yuv);
> extern void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int
> height,
> int srcStride, int dstStride);
>
> diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c
> index 8ef4a2cf5d..e57bfa6545 100644
> --- a/libswscale/rgb2rgb_template.c
> +++ b/libswscale/rgb2rgb_template.c
> @@ -646,13 +646,14 @@ static inline void uyvytoyv12_c(const uint8_t *src,
> uint8_t *ydst,
> * others are ignored in the C version.
> * FIXME: Write HQ version.
> */
> -void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
> +static void rgb24toyv12_x(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
this probably should be inline
also i see now "FIXME: Write HQ version." above here. Do you really want to
add a low quality rgb24toyv12 ?
(it is vissible on the diagonal border (cyan / red )) in
./ffmpeg -f lavfi -i testsrc=size=5632x3168 -pix_fmt yuv420p -vframes 1
-qscale 1 -strict -1 new.jpg
also on smaller sizes but for some reason its clearer on the big one zoomed in
400% with gimp
(the gimp test was done with the whole patchset not after this patch)
[...]
> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> index 32e0d7f63c..751bdcb2e4 100644
> --- a/libswscale/swscale_unscaled.c
> +++ b/libswscale/swscale_unscaled.c
> @@ -1654,6 +1654,23 @@ static int bgr24ToYv12Wrapper(SwsContext *c, const
> uint8_t *src[],
> return srcSliceH;
> }
>
> +static int rgb24ToYv12Wrapper(SwsContext *c, const uint8_t *src[],
> + int srcStride[], int srcSliceY, int srcSliceH,
> + uint8_t *dst[], int dstStride[])
> +{
> +ff_rgb24toyv12(
> +src[0],
> +dst[0] + srcSliceY * dstStride[0],
> +dst[1] + (srcSliceY >> 1) * dstStride[1],
> +dst[2] + (srcSliceY >> 1) * dstStride[2],
> +c->srcW, srcSliceH,
> +dstStride[0], dstStride[1], srcStride[0],
> +c->input_rgb2yuv_table);
> +if (dst[3])
> +fillPlane(dst[3], dstStride[3], c->srcW, srcSliceH, srcSliceY, 255);
> +return srcSliceH;
> +}
> +
> static int yvu9ToYv12Wrapper(SwsContext *c,
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Sun, 20 Aug 2023, at 15:01, Tomas Härdin wrote: > Will it be possible to attend via Jitsi Meet or similar? For the FFmpeg meeting, of course. For the rest, I dunno yet. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
[FFmpeg-devel] [PATCH v1 6/6] swscale: Add aarch64 functions for RGB24->YUV420P
Neon RGB24->YUV420P and BGR24->YUV420P functions. Works on 16 pixel
blocks and can do any width or height, though for widths less than 32 or
so the C is likely faster.
Signed-off-by: John Cox
---
libswscale/aarch64/rgb2rgb.c | 8 +
libswscale/aarch64/rgb2rgb_neon.S | 356 ++
2 files changed, 364 insertions(+)
diff --git a/libswscale/aarch64/rgb2rgb.c b/libswscale/aarch64/rgb2rgb.c
index a9bf6ff9e0..b2d68c1df3 100644
--- a/libswscale/aarch64/rgb2rgb.c
+++ b/libswscale/aarch64/rgb2rgb.c
@@ -30,6 +30,12 @@
void ff_interleave_bytes_neon(const uint8_t *src1, const uint8_t *src2,
uint8_t *dest, int width, int height,
int src1Stride, int src2Stride, int dstStride);
+void ff_bgr24toyv12_neon(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+ uint8_t *vdst, int width, int height, int lumStride,
+ int chromStride, int srcStride, int32_t *rgb2yuv);
+void ff_rgb24toyv12_neon(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+ uint8_t *vdst, int width, int height, int lumStride,
+ int chromStride, int srcStride, int32_t *rgb2yuv);
av_cold void rgb2rgb_init_aarch64(void)
{
@@ -37,5 +43,7 @@ av_cold void rgb2rgb_init_aarch64(void)
if (have_neon(cpu_flags)) {
interleaveBytes = ff_interleave_bytes_neon;
+ff_rgb24toyv12 = ff_rgb24toyv12_neon;
+ff_bgr24toyv12 = ff_bgr24toyv12_neon;
}
}
diff --git a/libswscale/aarch64/rgb2rgb_neon.S
b/libswscale/aarch64/rgb2rgb_neon.S
index d81110ec57..b15e69a3bd 100644
--- a/libswscale/aarch64/rgb2rgb_neon.S
+++ b/libswscale/aarch64/rgb2rgb_neon.S
@@ -77,3 +77,359 @@ function ff_interleave_bytes_neon, export=1
0:
ret
endfunc
+
+// Expand rgb2 into r0+r1/g0+g1/b0+b1
+.macro XRGB3Y r0, g0, b0, r1, g1, b1, r2, g2, b2
+uxtl\r0\().8h, \r2\().8b
+uxtl\g0\().8h, \g2\().8b
+uxtl\b0\().8h, \b2\().8b
+
+uxtl2 \r1\().8h, \r2\().16b
+uxtl2 \g1\().8h, \g2\().16b
+uxtl2 \b1\().8h, \b2\().16b
+.endm
+
+// Expand rgb2 into r0+r1/g0+g1/b0+b1
+// and pick every other el to put back into rgb2 for chroma
+.macro XRGB3YC r0, g0, b0, r1, g1, b1, r2, g2, b2
+XRGB3Y \r0, \g0, \b0, \r1, \g1, \b1, \r2, \g2, \b2
+
+bic \r2\().8h, #0xff, LSL #8
+bic \g2\().8h, #0xff, LSL #8
+bic \b2\().8h, #0xff, LSL #8
+.endm
+
+.macro SMLAL3 d0, d1, s0, s1, s2, c0, c1, c2
+smull \d0\().4s, \s0\().4h, \c0
+smlal \d0\().4s, \s1\().4h, \c1
+smlal \d0\().4s, \s2\().4h, \c2
+smull2 \d1\().4s, \s0\().8h, \c0
+smlal2 \d1\().4s, \s1\().8h, \c1
+smlal2 \d1\().4s, \s2\().8h, \c2
+.endm
+
+// d0 may be s0
+// s0, s2 corrupted
+.macro SHRN_Y d0, s0, s1, s2, s3, k128h
+shrn\s0\().4h, \s0\().4s, #12
+shrn2 \s0\().8h, \s1\().4s, #12
+add \s0\().8h, \s0\().8h, \k128h\().8h // +128 (>> 3 =
16)
+sqrshrun\d0\().8b, \s0\().8h, #3
+shrn\s2\().4h, \s2\().4s, #12
+shrn2 \s2\().8h, \s3\().4s, #12
+add \s2\().8h, \s2\().8h, \k128h\().8h
+sqrshrun2 \d0\().16b, v28.8h, #3
+.endm
+
+.macro SHRN_C d0, s0, s1, k128b
+shrn\s0\().4h, \s0\().4s, #14
+shrn2 \s0\().8h, \s1\().4s, #14
+sqrshrn \s0\().8b, \s0\().8h, #1
+add \d0\().8b, \s0\().8b, \k128b\().8b // +128
+.endm
+
+.macro STB2V s0, n, a
+st1 {\s0\().b}[(\n+0)], [\a], #1
+st1 {\s0\().b}[(\n+1)], [\a], #1
+.endm
+
+.macro STB4V s0, n, a
+STB2V \s0, (\n+0), \a
+STB2V \s0, (\n+2), \a
+.endm
+
+
+// void ff_bgr24toyv12_neon(
+// const uint8_t *src, // x0
+// uint8_t *ydst, // x1
+// uint8_t *udst, // x2
+// uint8_t *vdst, // x3
+// int width, // w4
+// int height, // w5
+// int lumStride, // w6
+// int chromStride,// w7
+// int srcStr, // [sp, #0]
+// int32_t *rgb2yuv); // [sp, #8]
+
+function ff_bgr24toyv12_neon, export=1
+ldr x15, [sp, #8]
+ld3 {v3.s, v4.s, v5.s}[0], [x15], #12
+ld3 {v3.s, v4.s, v5.s}[1], [x15], #12
+ld3 {v3.s, v4.s, v5.s}[2], [x15]
+mov v6.16b, v3.16b
+mov v3.16b, v5.16b
+mov v5.16b, v6.16b
+b 99f
[FFmpeg-devel] [PATCH v1 5/6] swscale: Add unscaled XRGB->YUV420P functions
Add simple C functions for converting XRGB to YUV420P. Same logic as the
RGB24 functions but dropping the A channel.
Signed-off-by: John Cox
---
libswscale/rgb2rgb.c | 20 +++
libswscale/rgb2rgb.h | 16 +
libswscale/rgb2rgb_template.c | 106 ++
libswscale/swscale_unscaled.c | 89
4 files changed, 231 insertions(+)
diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c
index de90e5193f..b976341e70 100644
--- a/libswscale/rgb2rgb.c
+++ b/libswscale/rgb2rgb.c
@@ -88,6 +88,26 @@ void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst,
int width, int height,
int lumStride, int chromStride, int srcStride,
int32_t *rgb2yuv);
+void (*ff_rgbxtoyv12)(const uint8_t *src, uint8_t *ydst,
+ uint8_t *udst, uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int
srcStride,
+ int32_t *rgb2yuv);
+void (*ff_bgrxtoyv12)(const uint8_t *src, uint8_t *ydst,
+ uint8_t *udst, uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int
srcStride,
+ int32_t *rgb2yuv);
+void (*ff_xrgbtoyv12)(const uint8_t *src, uint8_t *ydst,
+ uint8_t *udst, uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int
srcStride,
+ int32_t *rgb2yuv);
+void (*ff_xbgrtoyv12)(const uint8_t *src, uint8_t *ydst,
+ uint8_t *udst, uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int
srcStride,
+ int32_t *rgb2yuv);
void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int height,
int srcStride, int dstStride);
void (*interleaveBytes)(const uint8_t *src1, const uint8_t *src2, uint8_t *dst,
diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h
index f7a76a92ba..0015b1568a 100644
--- a/libswscale/rgb2rgb.h
+++ b/libswscale/rgb2rgb.h
@@ -135,6 +135,22 @@ extern void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t
*ydst, uint8_t *udst,
int width, int height,
int lumStride, int chromStride, int srcStride,
int32_t *rgb2yuv);
+extern void (*ff_rgbxtoyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int srcStride,
+ int32_t *rgb2yuv);
+extern void (*ff_bgrxtoyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int srcStride,
+ int32_t *rgb2yuv);
+extern void (*ff_xrgbtoyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int srcStride,
+ int32_t *rgb2yuv);
+extern void (*ff_xbgrtoyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int srcStride,
+ int32_t *rgb2yuv);
extern void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int
height,
int srcStride, int dstStride);
diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c
index 5503e58a29..22326807c5 100644
--- a/libswscale/rgb2rgb_template.c
+++ b/libswscale/rgb2rgb_template.c
@@ -742,6 +742,108 @@ void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst,
uint8_t *udst,
rgb24toyv12_x(src, ydst, udst, vdst, width, height, lumStride,
chromStride, srcStride, rgb2yuv, x_rgb);
}
+static void rgbxtoyv12_x(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+ uint8_t *vdst, int width, int height, int lumStride,
+ int chromStride, int srcStride, int32_t *rgb2yuv,
+ const uint8_t x[9])
+{
+int32_t ry = rgb2yuv[x[0]], gy = rgb2yuv[x[1]], by = rgb2yuv[x[2]];
+int32_t ru = rgb2yuv[x[3]], gu = rgb2yuv[x[4]], bu = rgb2yuv[x[5]];
+int32_t rv = rgb2yuv[x[6]], gv = rgb2yuv[x[7]], bv = rgb2yuv[x[8]];
+int y;
+const int chromWidth = width >> 1;
+//
[FFmpeg-devel] [PATCH v1 4/6] swscale: RGB24->YUV allow odd widths & improve C rounding
Allow odd widths for conversion it costs very little and simplifies
setup slightly. x86 asm will fall back to the C code if width is odd.
Round to nearest rather than just down. This reduces the Y error
reported by tests/swscale from 3 to 1. x86 asm doesn't mirror the C so
exact correspondence isn't an issue there.
Signed-off-by: John Cox
---
libswscale/rgb2rgb_template.c | 42 ++-
libswscale/swscale_unscaled.c | 5 ++--
libswscale/x86/rgb2rgb_template.c | 5
3 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c
index e57bfa6545..5503e58a29 100644
--- a/libswscale/rgb2rgb_template.c
+++ b/libswscale/rgb2rgb_template.c
@@ -656,6 +656,8 @@ static void rgb24toyv12_x(const uint8_t *src, uint8_t
*ydst, uint8_t *udst,
int32_t rv = rgb2yuv[x[6]], gv = rgb2yuv[x[7]], bv = rgb2yuv[x[8]];
int y;
const int chromWidth = width >> 1;
+const int32_t ky = ((16 << 1) + 1) << (RGB2YUV_SHIFT - 1);
+const int32_t kc = ((128 << 1) + 1) << (RGB2YUV_SHIFT - 1);
for (y = 0; y < height; y += 2) {
int i;
@@ -664,9 +666,9 @@ static void rgb24toyv12_x(const uint8_t *src, uint8_t
*ydst, uint8_t *udst,
unsigned int g = src[6 * i + 1];
unsigned int r = src[6 * i + 2];
-unsigned int Y = ((ry * r + gy * g + by * b) >> RGB2YUV_SHIFT) +
16;
-unsigned int V = ((rv * r + gv * g + bv * b) >> RGB2YUV_SHIFT) +
128;
-unsigned int U = ((ru * r + gu * g + bu * b) >> RGB2YUV_SHIFT) +
128;
+unsigned int Y = (ry * r + gy * g + by * b + ky) >> RGB2YUV_SHIFT;
+unsigned int V = (rv * r + gv * g + bv * b + kc) >> RGB2YUV_SHIFT;
+unsigned int U = (ru * r + gu * g + bu * b + kc) >> RGB2YUV_SHIFT;
udst[i] = U;
vdst[i] = V;
@@ -676,30 +678,36 @@ static void rgb24toyv12_x(const uint8_t *src, uint8_t
*ydst, uint8_t *udst,
g = src[6 * i + 4];
r = src[6 * i + 5];
-Y = ((ry * r + gy * g + by * b) >> RGB2YUV_SHIFT) + 16;
+Y = ((ry * r + gy * g + by * b + ky) >> RGB2YUV_SHIFT);
ydst[2 * i + 1] = Y;
}
-ydst += lumStride;
-src += srcStride;
-
-if (y+1 == height)
-break;
-
-for (i = 0; i < chromWidth; i++) {
+if ((width & 1) != 0) {
unsigned int b = src[6 * i + 0];
unsigned int g = src[6 * i + 1];
unsigned int r = src[6 * i + 2];
-unsigned int Y = ((ry * r + gy * g + by * b) >> RGB2YUV_SHIFT) +
16;
+unsigned int Y = (ry * r + gy * g + by * b + ky) >> RGB2YUV_SHIFT;
+unsigned int V = (rv * r + gv * g + bv * b + kc) >> RGB2YUV_SHIFT;
+unsigned int U = (ru * r + gu * g + bu * b + kc) >> RGB2YUV_SHIFT;
+udst[i] = U;
+vdst[i] = V;
ydst[2 * i] = Y;
+}
+ydst += lumStride;
+src += srcStride;
-b = src[6 * i + 3];
-g = src[6 * i + 4];
-r = src[6 * i + 5];
+if (y+1 == height)
+break;
-Y = ((ry * r + gy * g + by * b) >> RGB2YUV_SHIFT) + 16;
-ydst[2 * i + 1] = Y;
+for (i = 0; i < width; i++) {
+unsigned int b = src[3 * i + 0];
+unsigned int g = src[3 * i + 1];
+unsigned int r = src[3 * i + 2];
+
+unsigned int Y = (ry * r + gy * g + by * b + ky) >> RGB2YUV_SHIFT;
+
+ydst[i] = Y;
}
udst += chromStride;
vdst += chromStride;
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 751bdcb2e4..e10f967755 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1994,7 +1994,6 @@ void ff_get_unscaled_swscale(SwsContext *c)
const enum AVPixelFormat dstFormat = c->dstFormat;
const int flags = c->flags;
const int dstH = c->dstH;
-const int dstW = c->dstW;
int needsDither;
needsDither = isAnyRGB(dstFormat) &&
@@ -2052,12 +2051,12 @@ void ff_get_unscaled_swscale(SwsContext *c)
/* bgr24toYV12 */
if (srcFormat == AV_PIX_FMT_BGR24 &&
(dstFormat == AV_PIX_FMT_YUV420P || dstFormat == AV_PIX_FMT_YUVA420P)
&&
-!(flags & (SWS_ACCURATE_RND | SWS_BITEXACT)) && !(dstW&1))
+!(flags & (SWS_ACCURATE_RND | SWS_BITEXACT)))
c->convert_unscaled = bgr24ToYv12Wrapper;
/* rgb24toYV12 */
if (srcFormat == AV_PIX_FMT_RGB24 &&
(dstFormat == AV_PIX_FMT_YUV420P || dstFormat == AV_PIX_FMT_YUVA420P)
&&
-!(flags & (SWS_ACCURATE_RND | SWS_BITEXACT)) && !(dstW&1))
+!(flags & (SWS_ACCURATE_RND | SWS_BITEXACT)))
c->convert_unscaled = rgb24ToYv12Wrapper;
/* RGB/BGR -> RGB/BGR (no dither needed forms) */
diff --git a/libswscale/x86/rgb2rgb_template.c
b/libswscale/x86/rgb2rgb_template.c
index
[FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion
Add a rgb24->yuv420p conversion. Uses the same code as the existing
bgr24->yuv converter but permutes the conversion array to swap R & B
coefficients.
Signed-off-by: John Cox
---
libswscale/rgb2rgb.c | 5 +
libswscale/rgb2rgb.h | 7 +++
libswscale/rgb2rgb_template.c | 38 ++-
libswscale/swscale_unscaled.c | 24 +-
4 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c
index 8707917800..de90e5193f 100644
--- a/libswscale/rgb2rgb.c
+++ b/libswscale/rgb2rgb.c
@@ -83,6 +83,11 @@ void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t *ydst,
int width, int height,
int lumStride, int chromStride, int srcStride,
int32_t *rgb2yuv);
+void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst,
+ uint8_t *udst, uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int srcStride,
+ int32_t *rgb2yuv);
void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int height,
int srcStride, int dstStride);
void (*interleaveBytes)(const uint8_t *src1, const uint8_t *src2, uint8_t *dst,
diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h
index 305b830920..f7a76a92ba 100644
--- a/libswscale/rgb2rgb.h
+++ b/libswscale/rgb2rgb.h
@@ -79,6 +79,9 @@ voidrgb12to15(const uint8_t *src, uint8_t *dst, int
src_size);
void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst, int width, int height, int lumStride,
int chromStride, int srcStride, int32_t *rgb2yuv);
+void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+ uint8_t *vdst, int width, int height, int lumStride,
+ int chromStride, int srcStride, int32_t *rgb2yuv);
/**
* Height should be a multiple of 2 and width should be a multiple of 16.
@@ -128,6 +131,10 @@ extern void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t
*ydst, uint8_t *udst,
int width, int height,
int lumStride, int chromStride, int srcStride,
int32_t *rgb2yuv);
+extern void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t
*udst, uint8_t *vdst,
+ int width, int height,
+ int lumStride, int chromStride, int srcStride,
+ int32_t *rgb2yuv);
extern void (*planar2x)(const uint8_t *src, uint8_t *dst, int width, int
height,
int srcStride, int dstStride);
diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c
index 8ef4a2cf5d..e57bfa6545 100644
--- a/libswscale/rgb2rgb_template.c
+++ b/libswscale/rgb2rgb_template.c
@@ -646,13 +646,14 @@ static inline void uyvytoyv12_c(const uint8_t *src,
uint8_t *ydst,
* others are ignored in the C version.
* FIXME: Write HQ version.
*/
-void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+static void rgb24toyv12_x(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst, int width, int height, int lumStride,
- int chromStride, int srcStride, int32_t *rgb2yuv)
+ int chromStride, int srcStride, int32_t *rgb2yuv,
+ const uint8_t x[9])
{
-int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = rgb2yuv[BY_IDX];
-int32_t ru = rgb2yuv[RU_IDX], gu = rgb2yuv[GU_IDX], bu = rgb2yuv[BU_IDX];
-int32_t rv = rgb2yuv[RV_IDX], gv = rgb2yuv[GV_IDX], bv = rgb2yuv[BV_IDX];
+int32_t ry = rgb2yuv[x[0]], gy = rgb2yuv[x[1]], by = rgb2yuv[x[2]];
+int32_t ru = rgb2yuv[x[3]], gu = rgb2yuv[x[4]], bu = rgb2yuv[x[5]];
+int32_t rv = rgb2yuv[x[6]], gv = rgb2yuv[x[7]], bv = rgb2yuv[x[8]];
int y;
const int chromWidth = width >> 1;
@@ -707,6 +708,32 @@ void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst,
uint8_t *udst,
}
}
+static const uint8_t x_bgr[9] = {
+RY_IDX, GY_IDX, BY_IDX,
+RU_IDX, GU_IDX, BU_IDX,
+RV_IDX, GV_IDX, BV_IDX,
+};
+
+static const uint8_t x_rgb[9] = {
+ BY_IDX, GY_IDX, RY_IDX,
+ BU_IDX, GU_IDX, RU_IDX,
+ BV_IDX, GV_IDX, RV_IDX,
+};
+
+void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+ uint8_t *vdst, int width, int height, int lumStride,
+ int chromStride, int srcStride, int32_t *rgb2yuv)
+{
+rgb24toyv12_x(src, ydst, udst, vdst, width, height, lumStride,
chromStride, srcStride, rgb2yuv, x_bgr);
+}
+
+void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+ uint8_t *vdst, int width, int height, int lumStride,
+ int chromStride, int srcStride, int32_t *rgb2yuv)
+{
+rgb24toyv12_x(src, ydst, udst,
[FFmpeg-devel] [PATCH v1 2/6] swscale: Rename BGR24->YUV conversion functions as bgr...
Rename swscale conversion functions for converting BGR24 frames to YUV
as bgr24toyuv12 rather than rgb24toyuv12 as that is just confusing and
would be even more confusing with the addition of RGB24 converters.
Signed-off-by: John Cox
---
libswscale/bayer_template.c | 2 +-
libswscale/rgb2rgb.c | 2 +-
libswscale/rgb2rgb.h | 4 ++--
libswscale/rgb2rgb_template.c | 4 ++--
libswscale/swscale_unscaled.c | 2 +-
libswscale/x86/rgb2rgb_template.c | 8
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/libswscale/bayer_template.c b/libswscale/bayer_template.c
index 46b5a4984d..06d917c97f 100644
--- a/libswscale/bayer_template.c
+++ b/libswscale/bayer_template.c
@@ -188,7 +188,7 @@
* invoke ff_rgb24toyv12 for 2x2 pixels
*/
#define rgb24toyv12_2x2(src, dstY, dstU, dstV, luma_stride, src_stride,
rgb2yuv) \
-ff_rgb24toyv12(src, dstY, dstV, dstU, 2, 2, luma_stride, 0, src_stride,
rgb2yuv)
+ff_bgr24toyv12(src, dstY, dstV, dstU, 2, 2, luma_stride, 0, src_stride,
rgb2yuv)
static void BAYER_RENAME(rgb24_copy)(const uint8_t *src, int src_stride,
uint8_t *dst, int dst_stride, int width)
{
diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c
index e98fdac8ea..8707917800 100644
--- a/libswscale/rgb2rgb.c
+++ b/libswscale/rgb2rgb.c
@@ -78,7 +78,7 @@ void (*yuy2toyv12)(const uint8_t *src, uint8_t *ydst,
uint8_t *udst, uint8_t *vdst,
int width, int height,
int lumStride, int chromStride, int srcStride);
-void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst,
+void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t *ydst,
uint8_t *udst, uint8_t *vdst,
int width, int height,
int lumStride, int chromStride, int srcStride,
diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h
index f3951d523e..305b830920 100644
--- a/libswscale/rgb2rgb.h
+++ b/libswscale/rgb2rgb.h
@@ -76,7 +76,7 @@ void rgb15tobgr15(const uint8_t *src, uint8_t *dst, int
src_size);
void rgb12tobgr12(const uint8_t *src, uint8_t *dst, int src_size);
voidrgb12to15(const uint8_t *src, uint8_t *dst, int src_size);
-void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst, int width, int height, int lumStride,
int chromStride, int srcStride, int32_t *rgb2yuv);
@@ -124,7 +124,7 @@ extern void (*yuv422ptouyvy)(const uint8_t *ysrc, const
uint8_t *usrc, const uin
* Chrominance data is only taken from every second line, others are ignored.
* FIXME: Write high quality version.
*/
-extern void (*ff_rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t
*udst, uint8_t *vdst,
+extern void (*ff_bgr24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t
*udst, uint8_t *vdst,
int width, int height,
int lumStride, int chromStride, int srcStride,
int32_t *rgb2yuv);
diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c
index 42c69801ba..8ef4a2cf5d 100644
--- a/libswscale/rgb2rgb_template.c
+++ b/libswscale/rgb2rgb_template.c
@@ -646,7 +646,7 @@ static inline void uyvytoyv12_c(const uint8_t *src, uint8_t
*ydst,
* others are ignored in the C version.
* FIXME: Write HQ version.
*/
-void ff_rgb24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
+void ff_bgr24toyv12_c(const uint8_t *src, uint8_t *ydst, uint8_t *udst,
uint8_t *vdst, int width, int height, int lumStride,
int chromStride, int srcStride, int32_t *rgb2yuv)
{
@@ -979,7 +979,7 @@ static av_cold void rgb2rgb_init_c(void)
yuv422ptouyvy = yuv422ptouyvy_c;
yuy2toyv12 = yuy2toyv12_c;
planar2x = planar2x_c;
-ff_rgb24toyv12 = ff_rgb24toyv12_c;
+ff_bgr24toyv12 = ff_bgr24toyv12_c;
interleaveBytes= interleaveBytes_c;
deinterleaveBytes = deinterleaveBytes_c;
vu9_to_vu12= vu9_to_vu12_c;
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 9af2e7ecc3..32e0d7f63c 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1641,7 +1641,7 @@ static int bgr24ToYv12Wrapper(SwsContext *c, const
uint8_t *src[],
int srcStride[], int srcSliceY, int srcSliceH,
uint8_t *dst[], int dstStride[])
{
-ff_rgb24toyv12(
+ff_bgr24toyv12(
src[0],
dst[0] + srcSliceY * dstStride[0],
dst[1] + (srcSliceY >> 1) * dstStride[1],
diff --git a/libswscale/x86/rgb2rgb_template.c
b/libswscale/x86/rgb2rgb_template.c
index 4aba25dd51..dc2b4e205a 100644
--- a/libswscale/x86/rgb2rgb_template.c
+++ b/libswscale/x86/rgb2rgb_template.c
@@ -1544,7 +1544,7 @@ static inline void
[FFmpeg-devel] [PATCH v1 1/6] fate-filter-fps: Set swscale bitexact for tests that do conversions
-bitexact as a general flag doesn't affect swscale so add swscale option too to get correct CRCs in all circumstances. Signed-off-by: John Cox --- tests/fate/filter-video.mak | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 789ec6414c..811a96d124 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -391,8 +391,8 @@ fate-filter-fps-start-drop: CMD = framecrc -lavfi testsrc2=r=7:d=3.5,fps=3:start fate-filter-fps-start-fill: CMD = framecrc -lavfi testsrc2=r=7:d=1.5,setpts=PTS+14,fps=3:start_time=1.5 FATE_FILTER_SAMPLES-$(call FILTERDEMDEC, FPS SCALE, MOV, QTRLE) += fate-filter-fps-cfr fate-filter-fps -fate-filter-fps-cfr: CMD = framecrc -auto_conversion_filters -i $(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -r 30 -vsync cfr -pix_fmt yuv420p -fate-filter-fps: CMD = framecrc -auto_conversion_filters -i $(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -vf fps=30 -pix_fmt yuv420p +fate-filter-fps-cfr: CMD = framecrc -auto_conversion_filters -i $(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -r 30 -vsync cfr -vf scale=sws_flags=bitexact -pix_fmt yuv420p +fate-filter-fps: CMD = framecrc -auto_conversion_filters -i $(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -vf fps=30,scale=sws_flags=bitexact -pix_fmt yuv420p FATE_FILTER_ALPHAEXTRACT_ALPHAMERGE := $(addprefix fate-filter-alphaextract_alphamerge_, rgb yuv) FATE_FILTER_VSYNTH_PGMYUV-$(call ALLYES, SCALE_FILTER FORMAT_FILTER SPLIT_FILTER ALPHAEXTRACT_FILTER ALPHAMERGE_FILTER) += $(FATE_FILTER_ALPHAEXTRACT_ALPHAMERGE) -- 2.39.2 ___ 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".
[FFmpeg-devel] [PATCH v1 0/6] swscale: Add dedicated RGB->YUV unscaled functions & aarch64 asm
This patch set expands the set of dedicated RGB->YUV unscaled functions to help with encoding camera output on a Pi. Obviously there are other uses but that was the motivation. It enforces the general bitexact path for the fate tests that depend on it. It renames the existing bgr function as bgr... so we don't end up with the counterintuative situation where BGR is handled by rgb... and BGR would be handled by rgb.. Adds RGB functions Improves the rounding in the dedicated function as that improves its score when tested with test/swscale and fixes it to allow any width (contrary to the comment any height was already allowed). Adds XRGB->YUV functions to complete the set Adds Aarch64 neon for BGR24 & RGB24 I haven't built fate tests for this as I'm not quite sure what the appropriate tests would be. The x86 asm doesn't match either the C template with improved rounding or the previous template (I'm not quite sure what it does but it produces a different score out of tests/swscale to either method) so a simple results match isn't going to work. Regards John Cox John Cox (6): fate-filter-fps: Set swscale bitexact for tests that do conversions swscale: Rename BGR24->YUV conversion functions as bgr... swscale: Add explicit rgb24->yv12 conversion swscale: RGB24->YUV allow odd widths & improve C rounding swscale: Add unscaled XRGB->YUV420P functions swscale: Add aarch64 functions for RGB24->YUV420P libswscale/aarch64/rgb2rgb.c | 8 + libswscale/aarch64/rgb2rgb_neon.S | 356 ++ libswscale/bayer_template.c | 2 +- libswscale/rgb2rgb.c | 25 +++ libswscale/rgb2rgb.h | 23 ++ libswscale/rgb2rgb_template.c | 174 +-- libswscale/swscale_unscaled.c | 114 +- libswscale/x86/rgb2rgb_template.c | 13 +- tests/fate/filter-video.mak | 4 +- 9 files changed, 694 insertions(+), 25 deletions(-) -- 2.39.2 ___ 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".
Re: [FFmpeg-devel] [PATCH v3 11/12] avcodec/libx264: add support for writing out CLL and MDCV
On Sun, Aug 20, 2023 at 01:25:27AM +0300, Jan Ekström wrote: > On Sat, Aug 19, 2023 at 7:53 PM Michael Niedermayer > wrote: > > > > On Fri, Aug 18, 2023 at 12:48:49AM +0300, Jan Ekström wrote: > > > Both of these two structures were first available with X264_BUILD > > > 163, so make relevant functionality conditional on the version > > > being at least such. > > > > > > Keep handle_side_data available in all cases as this way X264_init > > > does not require additional version based conditions within it. > > > > > > Finally, add a FATE test which verifies that pass-through of the > > > MDCV/CLL side data is working during encoding. > > > --- > > > libavcodec/libx264.c | 79 > > > tests/fate/enc_external.mak | 5 +++ > > > tests/ref/fate/libx264-hdr10 | 15 +++ > > > 3 files changed, 99 insertions(+) > > > create mode 100644 tests/ref/fate/libx264-hdr10 > > > > fate fails with X264_BUILD 152 > > > > The filters 'Parsed_null_0' and 'format' do not have a common format and > > automatic conversion is disabled. > > [vf#0:0 @ 0x55eddf8d4780] Error reinitializing filters! > > Failed to inject frame into filter network: Invalid argument > > Error while filtering: Invalid argument > > [out#0/mp4 @ 0x55eddf87b980] Nothing was written into output file, because > > at least one of its streams received no packets. > > frame=0 fps=0.0 q=0.0 Lsize= 0kB time=N/A bitrate=N/A speed=N/A > > Conversion failed! > > threads=1 > > tests/Makefile:307: recipe for target 'fate-libx264-hdr10' failed > > make: *** [fate-libx264-hdr10] Error 234 > > > > Without having more information, that sounds more like a 8bit only > build rather than an X264_BUILD related issue, as the error seems to > come from a conversion from the input 10bit content to whatever not > being available. > > Can you check if that is the case? x264 152 was either 8bit or 10bit but not both. That box on which this fails has x264 builds for both for 8bit and 10bit. ffmpeg can at runtime be linked with either for example LD_PRELOAD=/usr/lib/x86_64-linux-gnu/x264-10bit/libx264.so.152 ./ffmpeg -i ~/videos/mm-short.mpg test.mkv produces a 10bit output maybe you should just disable this test for 152 and prior to avoid this complexity thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
Will it be possible to attend via Jitsi Meet or similar? /Tomas ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light
tor 2023-08-17 klockan 14:04 -0400 skrev Leo Izen: > On 8/17/23 08:59, Tomas Härdin wrote: > > ons 2023-08-16 klockan 01:20 -0400 skrev Leo Izen: > > > By default the OpenEXR decoder outputs linear light pixel data by > > > applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it > > > should tag the data as linear so color-managed filters or other > > > tools > > > can work with it correctly. > > > > > > Signed-off-by: Leo Izen > > > --- > > > libavcodec/exr.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/libavcodec/exr.c b/libavcodec/exr.c > > > index fae1d08ab0..518066facf 100644 > > > --- a/libavcodec/exr.c > > > +++ b/libavcodec/exr.c > > > @@ -2088,6 +2088,8 @@ static int decode_frame(AVCodecContext > > > *avctx, > > > AVFrame *picture, > > > > > > if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED) > > > avctx->color_trc = s->apply_trc_type; > > > + else if (s->gamma > 0.f && s->gamma < 1.0001f) > > > + avctx->color_trc = AVCOL_TRC_LINEAR; > > > > I'm going to be difficult here and point out that gamma=0.1 is > > not > > linear. It's probably linear *enough* most of the time, but also > > 1.0 > > can be exactly represented by float so an equality check seems > > appropriate. > > This exact check exists elsewhere in the source file. There's a > branch > where it sets up a LUT if gamma is not between those values, and has > a > no-op track otherwise - so in the event you request 0.5 or > something > of that form, the code that does the color conversion treats it as > 1.0f. Alright. I just find myself wondering how gamma could ever become some value that is close to 1.0 but not quite equal. /Tomas ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/channel_layout: make pre-defined channel layouts C++ friendly
tor 2023-08-17 klockan 22:03 +0800 skrev zhilizhao(赵志立):
>
>
> > On Aug 17, 2023, at 20:57, Tomas Härdin wrote:
> >
> > ons 2023-08-16 klockan 23:44 +0800 skrev Zhao Zhili:
> > > From: Zhao Zhili
> > >
> > > C++ doesn't support designated initializers until C++20. We have
> > > a bunch of pre-defined channel layouts, the gains to make them
> > > usable in C++ exceed the losses.
> > >
> > > Signed-off-by: Zhao Zhili
> > > ---
> > > libavutil/channel_layout.h | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavutil/channel_layout.h
> > > b/libavutil/channel_layout.h
> > > index f345415c55..817a5ad370 100644
> > > --- a/libavutil/channel_layout.h
> > > +++ b/libavutil/channel_layout.h
> > > @@ -359,7 +359,7 @@ typedef struct AVChannelLayout {
> > > } AVChannelLayout;
> > >
> > > #define AV_CHANNEL_LAYOUT_MASK(nb, m) \
> > > - { .order = AV_CHANNEL_ORDER_NATIVE, .nb_channels = (nb), .u
> > > = {
> > > .mask = (m) }}
> > > + { AV_CHANNEL_ORDER_NATIVE, (nb), { m }, NULL }
> > >
> > > /**
> > > * @name Common pre-defined channel layouts
> > > @@ -397,7 +397,7 @@ typedef struct AVChannelLayout {
> > > #define AV_CHANNEL_LAYOUT_STEREO_DOWNMIX
> > > AV_CHANNEL_LAYOUT_MASK(2, AV_CH_LAYOUT_STEREO_DOWNMIX)
> > > #define AV_CHANNEL_LAYOUT_22POINT2
> > > AV_CHANNEL_LAYOUT_MASK(24, AV_CH_LAYOUT_22POINT2)
> > > #define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
> > > - { .order = AV_CHANNEL_ORDER_AMBISONIC, .nb_channels = 4, .u
> > > = {
> > > .mask = 0 }}
> > > + { AV_CHANNEL_ORDER_AMBISONIC, 4, { 0 }, NULL }
> >
> > For C++ compat you could use some constructor magic instead, and
> > turn
> > these into proper constants. Hidden behind #ifdef __cplusplus of
> > course.
>
> I’m trying to avoid more debate to not refer to __cplusplus on
> purpose.
>
> >
> > IMO having untyped #defines like this is mega ugly. At the very
> > least
> > it should be (AVChannelLayout){...}. It's likely cargo culted from
> > when
> > channel layouts were bitmasks.
>
> (AVChannelLayout){…} can be invalid in C++. AV_TIME_BASE_Q has the
> problem
> already.
We could turn them into proper constants, like so:
static const AVChannelLayout AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER =
{...};
/Tomas
___
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".
Re: [FFmpeg-devel] [PATCH v3 07/12] avutil/frame: add helper for extending a set of side data
Jan Ekström:
> ---
> libavutil/frame.c | 23 +++
> libavutil/frame.h | 16
> 2 files changed, 39 insertions(+)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index d8910a2120..04d56853f0 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -880,6 +880,29 @@ AVFrameSideData
> *av_side_data_set_new_item(AVFrameSideDataSet *set,
> return ret;
> }
>
> +int av_side_data_set_extend(AVFrameSideDataSet *dst,
> +const AVFrameSideDataSet src,
> +unsigned int allow_duplicates)
> +{
> +for (int i = 0; i < src.nb_sd; i++) {
> +const AVFrameSideData *sd_src = src.sd[i];
> +AVFrameSideData *sd_dst =
> +av_side_data_set_new_item(dst, sd_src->type,
> + sd_src->size,
> + allow_duplicates);
> +if (!sd_dst) {
> +av_side_data_set_uninit(dst);
> +return AVERROR(ENOMEM);
> +}
> +
> +memcpy(sd_dst->data, sd_src->data, sd_src->size);
AVFrame side data is reference-counted.
> +
> +av_dict_copy(_dst->metadata, sd_src->metadata, 0);
Missing check.
> +}
> +
> +return 0;
> +}
> +
> AVFrameSideData *av_side_data_set_get_item(const AVFrameSideDataSet set,
> enum AVFrameSideDataType type)
> {
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 0cafc9c51f..2413000c9a 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -1083,6 +1083,22 @@ AVFrameSideData
> *av_side_data_set_new_item(AVFrameSideDataSet *set,
> size_t size,
> unsigned int allow_duplicates);
>
> +/**
> + * Add multiple side data entries to a set in one go.
> + *
> + * @param dst a set to which the side data should be added
> + * @param src a set from which the side data should be copied from
This needs to add something to ensure that dst and src refer to
different side-data (i.e. to disallow calls like
AVFrameSideDataSet set = { ... };
av_side_data_set_extend(, set, 0);)
> + * @param allow_duplicates an unsigned integer noting whether duplicates are
> + * allowed or not. If duplicates are not allowed, all
> + * entries of the same side data type are first
> removed
> + * and freed before the new entry is added.
Better use flags.
> + *
> + * @return negative error code on failure, >=0 on success.
> + */
> +int av_side_data_set_extend(AVFrameSideDataSet *dst,
> +const AVFrameSideDataSet src,
> +unsigned int allow_duplicates);
Do we really need this function? Are there enough potential users of it?
> +
> /**
> * Get a side data entry of a specific type from a set.
> *
___
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".
Re: [FFmpeg-devel] [PATCH v1] avformat/rtmpproto: support fourCcList property in enhanced rtmp
Hello, On Sun, 20 Aug 2023, at 06:10, Steven Liu wrote: > As the enhanced rtmp Extending NetConnection connect Command section > said, the rtmp should add a property named fourCcLive, but there should > only one codec can be set for the video stream in rtmp+flv, so user can > use the option rtmp_enhanced_flags to set the enhanced rtmp with av1, > hevc or vp9. Technically, the protocol allows any type of FourCC, no? jb ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Include objbase.h when checking for CoTaskMemFree
On 2023-08-20 02:42 am, Martin Storsjö wrote: ddc1cd5cdd2570bf3d6ab807ee0ecfacdf09431d defined WIN32_LEAN_AND_MEAN globally, which makes for much fewer transitive includes from windows.h. With that define, CoTaskMemFree no longer gets implicitly declared by just including windows.h, but one has to include the right header objbase.h too. That commit caused ole32 to no longer get detected, which caused dxva2 to no longer be enabled. This gets fixed by this patch. Signed-off-by: Martin Storsjö --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index ff6a5c3600..04bb9fe9dd 100755 --- a/configure +++ b/configure @@ -6488,7 +6488,7 @@ done check_lib advapi32 "windows.h"RegCloseKey -ladvapi32 check_lib bcrypt "windows.h bcrypt.h" BCryptGenRandom -lbcrypt && check_cpp_condition bcrypt bcrypt.h "defined BCRYPT_RNG_ALGORITHM" -check_lib ole32"windows.h"CoTaskMemFree-lole32 +check_lib ole32"windows.h objbase.h" CoTaskMemFree-lole32 check_lib shell32 "windows.h shellapi.h" CommandLineToArgvW -lshell32 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi Tested; LGTM. Regards, Gyan ___ 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".
Re: [FFmpeg-devel] [PATCH v3 10/12] avcodec/libsvtav1: add support for writing out CLL and MDCV
Jan Ekström:
> These two were added in 28e23d7f348c78d49a726c7469f9d4e38edec341
> and 3558c1f2e97455e0b89edef31b9a72ab7fa30550 for version 0.9.0 of
> SVT-AV1, which is also our minimum requirement right now.
>
> In other words, no additional version limiting conditions seem
> to be required.
>
> Additionally, add a FATE test which verifies that pass-through of
> the MDCV/CLL side data is working during encoding.
> ---
> libavcodec/libsvtav1.c | 70 ++
> tests/fate/enc_external.mak| 5 +++
> tests/ref/fate/libsvtav1-hdr10 | 14 +++
> 3 files changed, 89 insertions(+)
> create mode 100644 tests/ref/fate/libsvtav1-hdr10
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index f2b73361d8..d4f9fa14ba 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -24,9 +24,11 @@
> #include
> #include
>
> +#include "libavutil/bswap.h"
> #include "libavutil/common.h"
> #include "libavutil/frame.h"
> #include "libavutil/imgutils.h"
> +#include "libavutil/mastering_display_metadata.h"
> #include "libavutil/opt.h"
> #include "libavutil/pixdesc.h"
> #include "libavutil/avassert.h"
> @@ -146,6 +148,72 @@ static int alloc_buffer(EbSvtAv1EncConfiguration
> *config, SvtContext *svt_enc)
>
> }
>
> +static void handle_mdcv(struct EbSvtAv1MasteringDisplayInfo *dst,
> +const AVMasteringDisplayMetadata *mdcv)
> +{
> +struct EbSvtAv1ChromaPoints *points[] = {
> +>r,
> +>g,
> +>b,
> +};
> +
> +if (!mdcv->has_primaries)
> +goto skip_primaries;
> +
> +for (int i = 0; i < 3; i++) {
> +struct EbSvtAv1ChromaPoints *dst = points[i];
> +const AVRational *src = mdcv->display_primaries[i];
> +
> +dst->x =
> +AV_BSWAP16C(av_rescale_q(1, src[0],
> + (AVRational){ 1, (1 << 16) }));
Can you explain what's the matter with the AV_BSWAP16C here? And if I am
not mistaken, then the av_rescale_q() above is equivalent to src[0] * (1
<< 16) (if we had multiplications of AVRationals by integers).
> +dst->y =
> +AV_BSWAP16C(av_rescale_q(1, src[1],
> + (AVRational){ 1, (1 << 16) }));
> +}
> +
> +dst->white_point.x =
> +AV_BSWAP16C(av_rescale_q(1, mdcv->white_point[0],
> + (AVRational){ 1, (1 << 16) }));
> +dst->white_point.y =
> +AV_BSWAP16C(av_rescale_q(1, mdcv->white_point[1],
> + (AVRational){ 1, (1 << 16) }));
> +
> +skip_primaries:
> +if (!mdcv->has_luminance)
> +return;
> +
> +dst->max_luma =
> +AV_BSWAP32C(av_rescale_q(1, mdcv->max_luminance,
> + (AVRational){ 1, (1 << 8) }));
> +dst->min_luma =
> +AV_BSWAP32C(av_rescale_q(1, mdcv->min_luminance,
> + (AVRational){ 1, (1 << 14) }));
> +}
> +
> +static void handle_side_data(AVCodecContext *avctx,
> + EbSvtAv1EncConfiguration *param)
> +{
> +const AVFrameSideDataSet set = avctx->side_data_set;
> +const AVFrameSideData *cll_sd =
> +av_side_data_set_get_item(set, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
> +const AVFrameSideData *mdcv_sd =
> +av_side_data_set_get_item(set,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> +
> +if (cll_sd) {
> +const AVContentLightMetadata *cll =
> +(AVContentLightMetadata *)cll_sd->data;
> +
> +param->content_light_level.max_cll = AV_BSWAP16C(cll->MaxCLL);
> +param->content_light_level.max_fall = AV_BSWAP16C(cll->MaxFALL);
> +}
> +
> +if (mdcv_sd) {
> +handle_mdcv(>mastering_display,
> +(AVMasteringDisplayMetadata *)mdcv_sd->data);
> +}
> +}
> +
> static int config_enc_params(EbSvtAv1EncConfiguration *param,
> AVCodecContext *avctx)
> {
> @@ -273,6 +341,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
> /* 2 = IDR, closed GOP, 1 = CRA, open GOP */
> param->intra_refresh_type = avctx->flags & AV_CODEC_FLAG_CLOSED_GOP ? 2
> : 1;
>
> +handle_side_data(avctx, param);
> +
> #if SVT_AV1_CHECK_VERSION(0, 9, 1)
> while ((en = av_dict_get(svt_enc->svtav1_opts, "", en,
> AV_DICT_IGNORE_SUFFIX))) {
> EbErrorType ret = svt_av1_enc_parse_parameter(param, en->key,
> en->value);
> diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak
> index 7eabebcc51..d787941c16 100644
> --- a/tests/fate/enc_external.mak
> +++ b/tests/fate/enc_external.mak
> @@ -2,5 +2,10 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX264 H264, MOV,
> H264_DEMUXER) += fate-libx26
> fate-libx264-simple: CMD = enc_external
> $(TARGET_SAMPLES)/h264-conformance/BA1_Sony_D.jsv \
> mp4 "-c:v libx264" "-show_entries frame=width,height,pix_fmt,pts,pkt_dts
> -of flat"
>
> +# test for SVT-AV1 MDCV and CLL passthrough during
Re: [FFmpeg-devel] [PATCH v3 12/12] avcodec/libx265: add support for writing out CLL and MDCV
Jan Ekström:
> The newer of these two are the separate integers for content light
> level, introduced in 3952bf3e98c76c31594529a3fe34e056d3e3e2ea ,
> with X265_BUILD 75. As we already require X265_BUILD of at least
> 89, no further conditions are required.
> ---
> libavcodec/libx265.c | 82
> tests/fate/enc_external.mak | 5 +++
> tests/ref/fate/libx265-hdr10 | 16 +++
> 3 files changed, 103 insertions(+)
> create mode 100644 tests/ref/fate/libx265-hdr10
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 873b3021ee..2204b5146a 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -28,9 +28,11 @@
> #include
>
> #include "libavutil/avassert.h"
> +#include "libavutil/bprint.h"
> #include "libavutil/buffer.h"
> #include "libavutil/internal.h"
> #include "libavutil/common.h"
> +#include "libavutil/mastering_display_metadata.h"
> #include "libavutil/opt.h"
> #include "libavutil/pixdesc.h"
> #include "avcodec.h"
> @@ -179,6 +181,79 @@ static av_cold int
> libx265_param_parse_int(AVCodecContext *avctx,
> return 0;
> }
>
> +static int handle_mdcv(AVCodecContext *avctx, const x265_api *api,
You are not using an AVCodecContext* at all in this function; you only
need a logcontext (i.e. void*).
> + x265_param *params,
> + const AVMasteringDisplayMetadata *mdcv)
> +{
> +int ret = AVERROR_BUG;
> +static const char *option = "master-display";
This pointer is completely unnecessary.
> +AVBPrint buf;
> +av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
> +
> +// G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)
> +av_bprintf(
> +,
> +"G(%"PRId64",%"PRId64")B(%"PRId64",%"PRId64")R(%"PRId64",%"PRId64")"
> +"WP(%"PRId64",%"PRId64")L(%"PRId64",%"PRId64")",
> +av_rescale_q(1, mdcv->display_primaries[1][0], (AVRational){ 1,
> 5 }),
> +av_rescale_q(1, mdcv->display_primaries[1][1], (AVRational){ 1,
> 5 }),
> +av_rescale_q(1, mdcv->display_primaries[2][0], (AVRational){ 1,
> 5 }),
> +av_rescale_q(1, mdcv->display_primaries[2][1], (AVRational){ 1,
> 5 }),
> +av_rescale_q(1, mdcv->display_primaries[0][0], (AVRational){ 1,
> 5 }),
> +av_rescale_q(1, mdcv->display_primaries[0][1], (AVRational){ 1,
> 5 }),
> +av_rescale_q(1, mdcv->white_point[0], (AVRational){ 1, 5 }),
> +av_rescale_q(1, mdcv->white_point[1], (AVRational){ 1, 5 }),
> +av_rescale_q(1, mdcv->max_luminance, (AVRational){ 1, 1 }),
> +av_rescale_q(1, mdcv->min_luminance, (AVRational){ 1, 1 }));
> +
> +if (!av_bprint_is_complete()) {
> +ret = AVERROR(ENOMEM);
When using AV_BPRINT_SIZE_AUTOMATIC the buffer being incomplete does
not mean that an allocation failure occurred, as no allocations are
attempted at all.
Furthermore, I don't see the point of using the AVBPrint API here at
all. All you need is a big enough buffer and snprintf.
> +goto end;
> +}
> +
> +if (api->param_parse(params, option, buf.str) ==
> +X265_PARAM_BAD_VALUE) {
> +av_log(avctx, AV_LOG_ERROR,
> + "Invalid value \"%s\" for param \"%s\".\n",
> + buf.str, option);
> +ret = AVERROR(EINVAL);
> +goto end;
> +}
> +
> +ret = 0;
> +
> +end:
> +av_bprint_finalize(, NULL);
This is unnecessary: AV_BPRINT_SIZE_AUTOMATIC uses only the buffer
available in the AVBPrint itself; there are no dynamic allocations.
> +
> +return ret;
> +}
> +
> +static int handle_side_data(AVCodecContext *avctx, const x265_api *api,
> +x265_param *params)
> +{
> +const AVFrameSideDataSet set = avctx->side_data_set;
> +const AVFrameSideData *cll_sd =
> +av_side_data_set_get_item(set, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
> +const AVFrameSideData *mdcv_sd =
> +av_side_data_set_get_item(set,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> +
> +if (cll_sd) {
> +const AVContentLightMetadata *cll =
> +(AVContentLightMetadata *)cll_sd->data;
> +
> +params->maxCLL = cll->MaxCLL;
> +params->maxFALL = cll->MaxFALL;
> +}
> +
> +if (mdcv_sd) {
> +int ret = handle_mdcv(avctx, api, params,
> (AVMasteringDisplayMetadata *)mdcv_sd->data);
> +if (ret < 0)
> +return ret;
> +}
> +
> +return 0;
> +}
> +
> static av_cold int libx265_encode_init(AVCodecContext *avctx)
> {
> libx265Context *ctx = avctx->priv_data;
> @@ -339,6 +414,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> return AVERROR_BUG;
> }
>
> +ret = handle_side_data(avctx, ctx->api, ctx->params);
> +if (ret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Failed handling side data! (%s)\n",
> + av_err2str(ret));
> +return ret;
> +}
> +
> if (ctx->crf >= 0) {
> char crf[6];
Re: [FFmpeg-devel] [PATCH v3 11/12] avcodec/libx264: add support for writing out CLL and MDCV
Jan Ekström:
> Both of these two structures were first available with X264_BUILD
> 163, so make relevant functionality conditional on the version
> being at least such.
>
> Keep handle_side_data available in all cases as this way X264_init
> does not require additional version based conditions within it.
>
> Finally, add a FATE test which verifies that pass-through of the
> MDCV/CLL side data is working during encoding.
> ---
> libavcodec/libx264.c | 79
> tests/fate/enc_external.mak | 5 +++
> tests/ref/fate/libx264-hdr10 | 15 +++
> 3 files changed, 99 insertions(+)
> create mode 100644 tests/ref/fate/libx264-hdr10
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 1a7dc7bdd5..30ea3dae4c 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -25,6 +25,7 @@
> #include "libavutil/eval.h"
> #include "libavutil/internal.h"
> #include "libavutil/opt.h"
> +#include "libavutil/mastering_display_metadata.h"
> #include "libavutil/mem.h"
> #include "libavutil/pixdesc.h"
> #include "libavutil/stereo3d.h"
> @@ -842,6 +843,82 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
> return AVERROR(EINVAL);\
> }
>
> +#if X264_BUILD >= 163
> +static void handle_mdcv(x264_param_t *params,
> +const AVMasteringDisplayMetadata *mdcv)
> +{
> +int *points[][2] = {
> +{
> +>mastering_display.i_red_x,
> +>mastering_display.i_red_y
> +},
> +{
> +>mastering_display.i_green_x,
> +>mastering_display.i_green_y
> +},
> +{
> +>mastering_display.i_blue_x,
> +>mastering_display.i_blue_y
> +},
> +};
> +
> +if (!mdcv->has_primaries && !mdcv->has_luminance)
> +return;
> +
> +params->mastering_display.b_mastering_display = 1;
> +
> +if (!mdcv->has_primaries)
> +goto skip_primaries;
Normally we try to avoid gotos for non-error stuff. You are basically
replacing an ordinary "if" here.
> +
> +for (int i = 0; i < 3; i++) {
> +const AVRational *src = mdcv->display_primaries[i];
> +int *dst[2] = { points[i][0], points[i][1] };
> +
> +*dst[0] = av_rescale_q(1, src[0], (AVRational){ 1, 5 });
> +*dst[1] = av_rescale_q(1, src[1], (AVRational){ 1, 5 });
> +}
> +
> +params->mastering_display.i_white_x =
> +av_rescale_q(1, mdcv->white_point[0], (AVRational){ 1, 5 });
> +params->mastering_display.i_white_y =
> +av_rescale_q(1, mdcv->white_point[1], (AVRational){ 1, 5 });
> +
> +skip_primaries:
> +if (!mdcv->has_luminance)
> +return;
> +
> +params->mastering_display.i_display_max =
> +av_rescale_q(1, mdcv->max_luminance, (AVRational){ 1, 1 });
> +params->mastering_display.i_display_min =
> +av_rescale_q(1, mdcv->min_luminance, (AVRational){ 1, 1 });
> +}
> +#endif // X264_BUILD >= 163
> +
> +static void handle_side_data(AVCodecContext *avctx, x264_param_t *params)
> +{
> +#if X264_BUILD >= 163
> +const AVFrameSideDataSet set = avctx->side_data_set;
> +const AVFrameSideData *cll_sd =
> +av_side_data_set_get_item(set, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
> +const AVFrameSideData *mdcv_sd =
> +av_side_data_set_get_item(set,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
You can improve code locality by not using two variables for the side
data, but only one:
side_data = av_side_data_set_get_item(set,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
if (side_data) { ... }
side_data = av_side_data_set_get_item(set,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
if (side_data) { ... }
> +
> +if (cll_sd) {
> +const AVContentLightMetadata *cll =
> +(AVContentLightMetadata *)cll_sd->data;
> +
> +params->content_light_level.i_max_cll = cll->MaxCLL;
> +params->content_light_level.i_max_fall = cll->MaxFALL;
> +
> +params->content_light_level.b_cll = 1;
> +}
> +
> +if (mdcv_sd) {
> +handle_mdcv(params, (AVMasteringDisplayMetadata *)mdcv_sd->data);
> +}
> +#endif // X264_BUILD >= 163
> +}
> +
> static av_cold int X264_init(AVCodecContext *avctx)
> {
> X264Context *x4 = avctx->priv_data;
> @@ -1142,6 +1219,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
> x4->params.vui.i_chroma_loc = avctx->chroma_sample_location - 1;
>
> +handle_side_data(avctx, >params);
> +
> if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
> x4->params.b_repeat_headers = 0;
>
> diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak
> index d787941c16..90d8894d04 100644
> --- a/tests/fate/enc_external.mak
> +++ b/tests/fate/enc_external.mak
> @@ -7,5 +7,10 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBSVTAV1 HEVC, MOV,
> HEVC_DEMUXER LIBDAV1D_DECO
> fate-libsvtav1-hdr10: CMD = enc_external
>
Re: [FFmpeg-devel] [PATCH v3 11/12] avcodec/libx264: add support for writing out CLL and MDCV
Jan Ekström: > On Sat, Aug 19, 2023 at 7:53 PM Michael Niedermayer > wrote: >> >> On Fri, Aug 18, 2023 at 12:48:49AM +0300, Jan Ekström wrote: >>> Both of these two structures were first available with X264_BUILD >>> 163, so make relevant functionality conditional on the version >>> being at least such. >>> >>> Keep handle_side_data available in all cases as this way X264_init >>> does not require additional version based conditions within it. >>> >>> Finally, add a FATE test which verifies that pass-through of the >>> MDCV/CLL side data is working during encoding. >>> --- >>> libavcodec/libx264.c | 79 >>> tests/fate/enc_external.mak | 5 +++ >>> tests/ref/fate/libx264-hdr10 | 15 +++ >>> 3 files changed, 99 insertions(+) >>> create mode 100644 tests/ref/fate/libx264-hdr10 >> >> fate fails with X264_BUILD 152 >> >> The filters 'Parsed_null_0' and 'format' do not have a common format and >> automatic conversion is disabled. >> [vf#0:0 @ 0x55eddf8d4780] Error reinitializing filters! >> Failed to inject frame into filter network: Invalid argument >> Error while filtering: Invalid argument >> [out#0/mp4 @ 0x55eddf87b980] Nothing was written into output file, because >> at least one of its streams received no packets. >> frame=0 fps=0.0 q=0.0 Lsize= 0kB time=N/A bitrate=N/A speed=N/A >> Conversion failed! >> threads=1 >> tests/Makefile:307: recipe for target 'fate-libx264-hdr10' failed >> make: *** [fate-libx264-hdr10] Error 234 >> > > Without having more information, that sounds more like a 8bit only > build rather than an X264_BUILD related issue, as the error seems to > come from a conversion from the input 10bit content to whatever not > being available. > > Can you check if that is the case? > That is probably true, but your test nevertheless requires X264_BUILD >= 163, but the test requirements don't check for this. - Andreas ___ 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".
