Re: [FFmpeg-devel] h264_vaapi is using vaapi or va-api

2023-08-20 Thread Xiang, Haihao
> Hi, Folks, >     new FFMPEG user. I used gstreamer before. Now I am trying to build a rtsp > pipeline.Would like to know whether h264_vaapi uses vaapi or va-api? these two > are different ingstreamer. Both VA-API and VAAPI stands for Video Acceleration API, h264_vaapi in FFmpeg is based on this

Re: [FFmpeg-devel] [PATCH v1 1/1] lavc/qsvdec: fix dead loop of qsv decoding

2023-08-20 Thread Xiang, Haihao
On Do, 2023-08-17 at 19:39 +0800, Ting Hu wrote: > From: tinghu3 > > MFXVideoDECODE_DecodeFrameAsync always return MFX_WRN_DEVICE_BUSY in special > scenario. > > Signed-off-by: tinghu3 > --- >  libavcodec/qsvdec.c | 5 - >  1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/lib

Re: [FFmpeg-devel] [PATCH v1] avformat/rtmpproto: support fourCcList property in enhanced rtmp

2023-08-20 Thread Steven Liu
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 v

Re: [FFmpeg-devel] [PATCH] hwcontext_vulkan: always use create_pnext in vulkan_pool_alloc

2023-08-20 Thread Lynne
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 decodin

[FFmpeg-devel] [PATCH] hwcontext_vulkan: always use create_pnext in vulkan_pool_alloc

2023-08-20 Thread Chris Spencer
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

Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion

2023-08-20 Thread John Cox
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 conv

Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion

2023-08-20 Thread John Cox
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

Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion

2023-08-20 Thread Michael Niedermayer
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. > > >

Re: [FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion

2023-08-20 Thread Michael Niedermayer
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 + > l

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

2023-08-20 Thread Jean-Baptiste Kempf
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 mailin

[FFmpeg-devel] [PATCH v1 6/6] swscale: Add aarch64 functions for RGB24->YUV420P

2023-08-20 Thread John Cox
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 +

[FFmpeg-devel] [PATCH v1 5/6] swscale: Add unscaled XRGB->YUV420P functions

2023-08-20 Thread John Cox
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 +++

[FFmpeg-devel] [PATCH v1 4/6] swscale: RGB24->YUV allow odd widths & improve C rounding

2023-08-20 Thread John Cox
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'

[FFmpeg-devel] [PATCH v1 3/6] swscale: Add explicit rgb24->yv12 conversion

2023-08-20 Thread John Cox
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 |

[FFmpeg-devel] [PATCH v1 2/6] swscale: Rename BGR24->YUV conversion functions as bgr...

2023-08-20 Thread John Cox
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/rgb2r

[FFmpeg-devel] [PATCH v1 1/6] fate-filter-fps: Set swscale bitexact for tests that do conversions

2023-08-20 Thread John Cox
-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-v

[FFmpeg-devel] [PATCH v1 0/6] swscale: Add dedicated RGB->YUV unscaled functions & aarch64 asm

2023-08-20 Thread John Cox
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..

Re: [FFmpeg-devel] [PATCH v3 11/12] avcodec/libx264: add support for writing out CLL and MDCV

2023-08-20 Thread Michael Niedermayer
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 funct

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

2023-08-20 Thread Tomas Härdin
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 subjec

Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-20 Thread Tomas Härdin
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 > > > sho

Re: [FFmpeg-devel] [PATCH] avutil/channel_layout: make pre-defined channel layouts C++ friendly

2023-08-20 Thread Tomas Härdin
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

Re: [FFmpeg-devel] [PATCH v3 07/12] avutil/frame: add helper for extending a set of side data

2023-08-20 Thread Andreas Rheinhardt
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 > @@

Re: [FFmpeg-devel] [PATCH v1] avformat/rtmpproto: support fourCcList property in enhanced rtmp

2023-08-20 Thread Jean-Baptiste Kempf
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_e

Re: [FFmpeg-devel] [PATCH] configure: Include objbase.h when checking for CoTaskMemFree

2023-08-20 Thread Gyan Doshi
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

Re: [FFmpeg-devel] [PATCH v3 10/12] avcodec/libsvtav1: add support for writing out CLL and MDCV

2023-08-20 Thread Andreas Rheinhardt
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. > >

Re: [FFmpeg-devel] [PATCH v3 12/12] avcodec/libx265: add support for writing out CLL and MDCV

2023-08-20 Thread Andreas Rheinhardt
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