Re: [FFmpeg-devel] [RFC] What to do with 15k euro from STF?
On 12.11.24 08:51, Martin Storsjö wrote: On Tue, 12 Nov 2024, martin schitter wrote: The git history of Patches here on this mailinglist are usually rewritten whenever one of the reviewers requests some change, but the typical workflow in github/gitlab doesn't use or even forbids this kind of changes in uploaded code resp. forced pushes. It's enforcing a strict incremental timeline of changes. This is entirely up to the policy of each individual project; it's totally possible to use the exact same workflow with rewriting and force pushing the PR/MR branch, with both github and gitlab. Gitlab is usually a bit better at tracking review state across such events than github though. Anyway, this is how all such reviews are conducted on e.g. the videolan gitlab/projects. Well -- you can try to work around these limitations to some degree, but as a rule of thumb you should simply avoid git history rewrites and forced push's in MRs and any other form of published/shared remote branches in GitLab, although no strict protection mechanism will hinder you to use it in your own forks or any other unprotected branch, where you have sufficient access privileges, but the system simply doesn't like this kind of handling -- i.e. it will cause unwanted side effects: see: https://gitlab.com/gitlab-org/gitlab/-/issues/241509 https://gitlab.com/gitlab-org/gitlab-foss/-/issues/31484 https://gitlab.com/gitlab-org/gitlab/-/issues/232630 https://docs.gitlab.com/ee/topics/git/git_rebase.html#force-push-to-a-remote-branch This shift towards the commonly advised workflow of strict unmodified incremental change sets and final squash merges on this kind of platforms also affects the placement of patch related comments, otherwise they get silently lost at the end. martin ___ 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] [RFC] What to do with 15k euro from STF?
On Tue, Nov 12, 2024 at 9:44 AM martin schitter wrote: > > > > On 12.11.24 08:51, Martin Storsjö wrote: > > On Tue, 12 Nov 2024, martin schitter wrote: > > > >> The git history of Patches here on this mailinglist are usually > >> rewritten whenever one of the reviewers requests some change, but the > >> typical workflow in github/gitlab doesn't use or even forbids this > >> kind of changes in uploaded code resp. forced pushes. It's enforcing a > >> strict incremental timeline of changes. > > > > This is entirely up to the policy of each individual project; it's > > totally possible to use the exact same workflow with rewriting and force > > pushing the PR/MR branch, with both github and gitlab. Gitlab is usually > > a bit better at tracking review state across such events than github > > though. Anyway, this is how all such reviews are conducted on e.g. the > > videolan gitlab/projects. > > Well -- you can try to work around these limitations to some degree, but > as a rule of thumb you should simply avoid git history rewrites and > forced push's in MRs and any other form of published/shared remote > branches in GitLab, although no strict protection mechanism will hinder > you to use it in your own forks or any other unprotected branch, where > you have sufficient access privileges, but the system simply doesn't > like this kind of handling -- i.e. it will cause unwanted side effects: Wouldn't the solution be for each new version of a patch to be a new merge request, linked in the message to the previous MR (which is closed when the new version is posted)? Cheers, Dee ___ 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] [RFC] What to do with 15k euro from STF?
On 12 Nov 2024, at 9:44, martin schitter wrote: > On 12.11.24 08:51, Martin Storsjö wrote: >> On Tue, 12 Nov 2024, martin schitter wrote: >> >>> The git history of Patches here on this mailinglist are usually rewritten >>> whenever one of the reviewers requests some change, but the typical >>> workflow in github/gitlab doesn't use or even forbids this kind of changes >>> in uploaded code resp. forced pushes. It's enforcing a strict incremental >>> timeline of changes. >> >> This is entirely up to the policy of each individual project; it's totally >> possible to use the exact same workflow with rewriting and force pushing the >> PR/MR branch, with both github and gitlab. Gitlab is usually a bit better at >> tracking review state across such events than github though. Anyway, this is >> how all such reviews are conducted on e.g. the videolan gitlab/projects. > > Well -- you can try to work around these limitations to some degree, but as a > rule of thumb you should simply avoid git history rewrites and forced push's > in MRs and any other form of published/shared remote branches in GitLab, > although no strict protection mechanism will hinder you to use it in your own > forks or any other unprotected branch, where you have sufficient access > privileges, but the system simply doesn't like this kind of handling -- i.e. > it will cause unwanted side effects: > > see: > https://gitlab.com/gitlab-org/gitlab/-/issues/241509 > https://gitlab.com/gitlab-org/gitlab-foss/-/issues/31484 > https://gitlab.com/gitlab-org/gitlab/-/issues/232630 > https://docs.gitlab.com/ee/topics/git/git_rebase.html#force-push-to-a-remote-branch > > This shift towards the commonly advised workflow of strict unmodified > incremental change sets and final squash merges on this kind of platforms > also affects the placement of patch related comments, otherwise they get > silently lost at the end. > Force pushing is a common way to update merge requests and I did not observe much issues at all with that workflow at VideoLAN where we do that for years already or elsewhere tbh. Sure the status change in the MR is not ideally reflected in all cases but you anyway have to re-review a MR when its code changes, so it is not much different to having to have a look again to when someone sends a v2 or a patchset. (The commits listed in the commit list will always reflect the accurate MR contents.) The documentation states „Force pushing is not recommended on shared branches, because you risk destroying others’ changes.“ emphasis here on „shared branches“, which of course makes sense as when you work on branches together, force pushing can be annoying and accidentally cause lost work if you aren’t careful and don’t use `--force-with-lease`, but generally a MR is authored by a single user (although not necessarily). > martin > ___ > 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 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] [RFC] What to do with 15k euro from STF?
On 12 Nov 2024, at 10:09, Diederick C. Niehorster wrote: > On Tue, Nov 12, 2024 at 9:44 AM martin schitter wrote: >> >> >> >> On 12.11.24 08:51, Martin Storsjö wrote: >>> On Tue, 12 Nov 2024, martin schitter wrote: >>> The git history of Patches here on this mailinglist are usually rewritten whenever one of the reviewers requests some change, but the typical workflow in github/gitlab doesn't use or even forbids this kind of changes in uploaded code resp. forced pushes. It's enforcing a strict incremental timeline of changes. >>> >>> This is entirely up to the policy of each individual project; it's >>> totally possible to use the exact same workflow with rewriting and force >>> pushing the PR/MR branch, with both github and gitlab. Gitlab is usually >>> a bit better at tracking review state across such events than github >>> though. Anyway, this is how all such reviews are conducted on e.g. the >>> videolan gitlab/projects. >> >> Well -- you can try to work around these limitations to some degree, but >> as a rule of thumb you should simply avoid git history rewrites and >> forced push's in MRs and any other form of published/shared remote >> branches in GitLab, although no strict protection mechanism will hinder >> you to use it in your own forks or any other unprotected branch, where >> you have sufficient access privileges, but the system simply doesn't >> like this kind of handling -- i.e. it will cause unwanted side effects: > > Wouldn't the solution be for each new version of a patch to be a new > merge request, linked in the message to the previous MR (which is > closed when the new version is posted)? IMO thats a terrible workflow as it looses context (but of course nothing prevents you from doing it). Like I said in my other reply, I have yet to see any big issues by force-pushing to MRs, we do it at VideoLAN for years already. > > Cheers, > Dee > ___ > 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 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 1/2] lavf/mxfenc: Make write_desc return int
fre 2024-11-08 klockan 11:29 +0100 skrev Tomas Härdin: > Passes fate-mxf Will push in a day or two /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] [RFC] libpostproc splitout
Le maanantaina 11. marraskuuta 2024, 1.06.12 EET Michael Niedermayer a écrit : > > On the other hand, if we assume that it does not get separated, I think > > the lack of activity tells about the impopularity of the library. I don't > > see the point in spending time and/or money if nobody cares anymore, > > unless this is a research project but that does not seem to be what you > > are proposing. > libpostproc needs bugtracking, selftests, fuzzer support, documentation, > its API would need to be updated to match todays features. > (like any library would need) To summarise my previous message: that is moot. If libpostproc goes on to live (and maybe quietly die) outside FFmpeg.git, then those technical and finance questions do not belong on FFmpeg-devel. You get to raise those questions on libpostproc-devel after you have split the project out. > libpostproc is part of FFmpeg it is not "outside" FFmpeg or "outside" > the STF scope. The question is not if it is in scope of FFmpeg. It can be argued that it is, or at least that it was. With the benefit of hindsight, it is however clear that it won't flourish in FFmpeg.git and on FFmpeg-devel. So if you want to resurrect it, you'd better split it out. And if you do split it out, then the questions about its funding do not belong here. > The reason for me to consider to split libpostproc out is to be able to > work on the code without the eternal debates here. That's one way to put it. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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 v2] avcodec/dxva2: add support for HEVC RExt DXVA profiles
Microsoft has formally standardized DXVA GUIDs for HEVC Range Extension
profiles in the Windows 11 24H2 SDK. They are supported by Intel GPUs
starting with Tiger Lake.
Like VDPAU and VAAPI, DXVA has separate GUIDs for each RExt profile, so
we must parse the SPS like those hwaccels do to figure out which one to
use when creating our decoder.
The new RExt profiles are supported with DXVA2 and D3D11VA (depending on
driver support).
Signed-off-by: Cameron Gutman
---
v2 addresses some off-list feedback regarding the duplicate definition
of some DXVA GUIDs and incorrect handling of the pixel format of the
hw_frames_ctx when FFmpeg creates one internally.
---
libavcodec/d3d12va_hevc.c | 21 ---
libavcodec/dxva2.c | 77 +---
libavcodec/dxva2_hevc.c | 115 ++--
libavcodec/dxva2_internal.h | 47 ++-
libavcodec/hevc/hevcdec.c | 28 +
5 files changed, 266 insertions(+), 22 deletions(-)
diff --git a/libavcodec/d3d12va_hevc.c b/libavcodec/d3d12va_hevc.c
index 7686f0eb6c..f4272cec1e 100644
--- a/libavcodec/d3d12va_hevc.c
+++ b/libavcodec/d3d12va_hevc.c
@@ -33,12 +33,15 @@
#define MAX_SLICES 256
typedef struct HEVCDecodePictureContext {
-DXVA_PicParams_HEVCpp;
-DXVA_Qmatrix_HEVC qm;
-unsigned slice_count;
-DXVA_Slice_HEVC_Short slice_short[MAX_SLICES];
-const uint8_t *bitstream;
-unsigned bitstream_size;
+union {
+DXVA_PicParams_HEVC pp;
+ff_DXVA_PicParams_HEVC_RangeExt ppext;
+};
+DXVA_Qmatrix_HEVC qm;
+unsignedslice_count;
+DXVA_Slice_HEVC_Short slice_short[MAX_SLICES];
+const uint8_t *bitstream;
+unsignedbitstream_size;
} HEVCDecodePictureContext;
static void fill_slice_short(DXVA_Slice_HEVC_Short *slice, unsigned position,
unsigned size)
@@ -62,7 +65,7 @@ static int d3d12va_hevc_start_frame(AVCodecContext *avctx,
av_unused const uint8
ctx->used_mask = 0;
-ff_dxva2_hevc_fill_picture_parameters(avctx, (AVDXVAContext *)ctx,
&ctx_pic->pp);
+ff_dxva2_hevc_fill_picture_parameters(avctx, (AVDXVAContext *)ctx,
&ctx_pic->ppext);
ff_dxva2_hevc_fill_scaling_lists(avctx, (AVDXVAContext *)ctx,
&ctx_pic->qm);
@@ -152,11 +155,13 @@ static int d3d12va_hevc_end_frame(AVCodecContext *avctx)
HEVCDecodePictureContext *ctx_pic = h->cur_frame->hwaccel_picture_private;
int scale = ctx_pic->pp.dwCodingParamToolFlags & 1;
+int rext = avctx->profile == AV_PROFILE_HEVC_REXT;
if (ctx_pic->slice_count <= 0 || ctx_pic->bitstream_size <= 0)
return -1;
-return ff_d3d12va_common_end_frame(avctx, h->cur_frame->f, &ctx_pic->pp,
sizeof(ctx_pic->pp),
+return ff_d3d12va_common_end_frame(avctx, h->cur_frame->f, &ctx_pic->pp,
+ rext ? sizeof(ctx_pic->ppext) : sizeof(ctx_pic->pp),
scale ? &ctx_pic->qm : NULL, scale ? sizeof(ctx_pic->qm) : 0,
update_input_arguments);
}
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 22ecd5acaf..ed6036e099 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -48,7 +48,6 @@
DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_Profile0,0x463707f8,0xa1d0,0x4585,0x87,0x6d,0x8
DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_10bit_Profile2,0xa4c749ef,0x6ecf,0x48aa,0x84,0x48,0x50,0xa7,0xa1,0x16,0x5f,0xf7);
DEFINE_GUID(ff_DXVA2_ModeAV1_VLD_Profile0,0xb8be4ccb,0xcf53,0x46ba,0x8d,0x59,0xd6,0xb8,0xa6,0xda,0x5d,0x2a);
DEFINE_GUID(ff_DXVA2_NoEncrypt, 0x1b81beD0,
0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
-DEFINE_GUID(ff_GUID_NULL,0x,
0x,0x,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00);
DEFINE_GUID(ff_IID_IDirectXVideoDecoderService,
0xfc51a551,0xd5e7,0x11d9,0xaf,0x55,0x00,0x05,0x4e,0x43,0xff,0x02);
typedef struct dxva_mode {
@@ -70,6 +69,8 @@ static const int prof_hevc_main[]= {AV_PROFILE_HEVC_MAIN,
AV_PROFILE_UNKNOWN};
static const int prof_hevc_main10[] = {AV_PROFILE_HEVC_MAIN_10,
AV_PROFILE_UNKNOWN};
+static const int prof_hevc_rext[]= {AV_PROFILE_HEVC_REXT,
+AV_PROFILE_UNKNOWN};
static const int prof_vp9_profile0[] = {AV_PROFILE_VP9_0,
AV_PROFILE_UNKNOWN};
static const int prof_vp9_profile2[] = {AV_PROFILE_VP9_2,
@@ -95,8 +96,14 @@ static const dxva_mode dxva_modes[] = {
{ &ff_DXVA2_ModeVC1_D, AV_CODEC_ID_WMV3 },
/* HEVC/H.265 */
-{ &ff_DXVA2_ModeHEVC_VLD_Main10, AV_CODEC_ID_HEVC, prof_hevc_main10 },
-{ &ff_DXVA2_ModeHEVC_VLD_Main, AV_CODEC_ID_HEVC, prof_hevc_main },
+{ &ff_DXVA2_ModeHEVC_VLD_Main10, AV_CODEC_ID_HEVC, prof_hevc_main10 },
+{ &ff_DXVA2_ModeHEVC_VLD_Main, AV_CODEC_ID_HEVC, prof_hevc_main },
+{ &ff_DXVA2_ModeHEVC_VLD_Main12,
Re: [FFmpeg-devel] [RFC] dormant git accounts
On 11/12/2024 5:05 PM, James Almer wrote: > This is not true. I have write access to the website, for example, as do > others. And Michael cuts releases because he was given the task, not > because nobody else can or want. And nobody prevents anyone from just > fetching a git tag instead (Distros like Arch do, after all). It is true, he has acecss to do all of it. Just because others do, doesn't mean he can't. I am nto syaing he *will*, I'm using it as an example of the issue. > > Also, the xz fiasco is precisely what prompted him to write a script to > compare the contents of tarballs with their respective git tags, and a > patch for the security page on the website. It's on the ML. Not discoverable, for sure. - Derek ___ 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] [FFmpeg-cvslog] fate/pixfmts: extend the high bit depth test
On Thu, Nov 07, 2024 at 01:19:58AM +, James Almer wrote: > ffmpeg | branch: master | James Almer | Sat Nov 2 > 20:06:24 2024 -0300| [271aea60a4cd211d92923c53b72cd074c3030897] | committer: > James Almer > > fate/pixfmts: extend the high bit depth test > > Also test 8bit formats, and try bitdepth conversion paths. > > Signed-off-by: James Almer > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=271aea60a4cd211d92923c53b72cd074c3030897 > --- this causes "make fate-list" to sometimes fail with make: execvp: /bin/sh: Argument list too long make: execvp: printf: Argument list too long make: *** [tests/Makefile:314: fate-list] Error 127 when run from within scripts, i cannot reproduce it from the command line directly and dont have a small testcase. Do you want me to look into creating a testcase for this or you already know where its coming from ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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] [PATCH] lavfi/zscale: Fix unaligned data ptr issues in realign_frame
On Sat, Nov 9, 2024 at 10:31 AM Pavel Koshevoy wrote: > > > On Sat, Nov 9, 2024 at 9:53 AM James Almer wrote: > >> On 11/9/2024 12:55 PM, Pavel Koshevoy wrote: >> > On Sat, Nov 9, 2024 at 6:22 AM James Almer wrote: >> > >> >> On 11/9/2024 1:40 AM, Pavel Koshevoy wrote: >> >>> On Fri, Nov 8, 2024 at 7:29 PM James Almer wrote: >> >>> >> On 11/8/2024 10:51 PM, Pavel Koshevoy wrote: >> > I ran into segfaults in zimg when I attempted to use zscale >> > to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709 >> > with this filter chain: >> > >> > >> >> >> >> buffer=width=512:height=538:pix_fmt=yuv444p16le:time_base=1/1:sar=1/1,zscale=min=2020_ncl:rin=limited:pin=2020:tin=arib-std-b67:cin=left:t=linear,format=gbrpf32le,tonemap=gamma:desat=0,zscale=tin=linear:npl=100:p=709:m=709:r=limited:t=709,format=pix_fmts=yuv444p16le,buffersink >> > >> > I found several issues: >> > - realign_frame called av_pix_fmt_count_planes with incorrect >> >> parameter. >> > - av_frame_get_buffer did not align data pointers to specified >> >> alignment. >> >> Because it's not supposed to. The align parameter doxy states "buffer >> size alignment", which is the result of aligning the >> stride/linesizes, >> not the data pointers. >> >> You may want to use ff_default_get_video_buffer2(), which will add >> align >> amount of bytes to the allocated buffers (On top of aligning the >> linesizes to it), and then align the pointers with FFALIGN(). >> >> >>> >> >>> I am not the maintainer of vf_zscale, and I am not intimately familiar >> >> with >> >>> private ffmpeg APIs such as ff_default_get_video_buffer2, and at first >> >>> glance that function >> >>> doesn't appear to be a drop-in replacement for av_frame_get_buffer. >> >>> >> >>> ff_default_get_video_buffer2 requires AVFilterLink parameter?! -- >> >>> realign_frame doesn't >> >>> have that, it has an AVFrame which it needs to re-align to make it >> >>> compatible with libzimg API. >> >> >> >> It's trivial to make realign_frame take the necessary AVFilterLink as >> >> input argument. >> >> >> >>> >> >>> ... and why isn't av_frame_get_buffer populating AVFrame.data pointers >> >>> aligned >> >>> as specified by the align parameter? It costs at most (align - 1) more >> >>> padding bytes >> >>> to make it align the pointers, so I don't understand why it doesn't do >> >> that. >> >> >> >> Buffer alignment is set at configure time. It will be set to the >> highest >> >> needed alignment for the enabled simd (64 if avx512, else 32 if avx, >> >> else 16 if neon/sse, else 8). This is handled by av_malloc(), which is >> >> ultimately used by all alloc functions. >> >> >> > >> > Yes, I have noticed this while stepping through ffmpeg and zimg code. >> > The surprising thing I've observed is that ff_get_cpu_max_align_x86() >> > (called from av_cpu_max_align()) returned 8 ... it's surprising for an >> > ffmpeg >> > built and running on a Ryzen R9 5950x -- I would have expected 32. >> >> Yeah, av_cpu_max_align() returns a value depending on runtime >> parameters, so unless you force cpuflags using av_force_cpu_flags() to >> disable everything SSE and above (or it being disabled during >> configure), it should not return 8. >> > > I certainly did not call av_force_cpu_flags myself, and as far as I can > see > conan ffmpeg recipe does not pass any --disable-sse or --disable-avx > options > to ffmpegs configure script ... I will have to investigate this separately > when I am back at work. > > > > >> > >> > As a side note ... this ffmpeg build (and zimg build) were produced by >> > conan, >> > so perhaps the conan recipe for ffmpeg needs some changes to make >> > av_cpu_max_align() work as expected on 5950x. >> > (https://conan.io/center/recipes/ffmpeg) >> >> The conan recipe for ffmpeg adds --disable-mmx to ffmpeg configure options when building a Debug package. Unfortunately, this disabled not only MMX, but also SSE and AVX, and affected av_cpu_max_align(). I've modified my local ffmpeg conan recipe to omit the --disable-mmx option from Debug builds. Pavel. ___ 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] lavc/x86/videodsp: Drop MMX usage
Hi,
On Tue, Nov 12, 2024 at 2:14 PM Frank Plowman wrote:
> Remove the MMX versions of these functions and modify the SSE
> implementations to avoid using MMX registers.
>
> Signed-off-by: Frank Plowman
> ---
> This wasn't wholly straightforward as the existing SSE implementation did
> not only use SSE but rather a blend of SSE and MMX. I would appreciate
> some review, as I am not particularly familiar with x86 assembly. Of
> particular interest are the changes to {READ,WRITE}_NUM_BYTES. The new
> implementation does not make economic use of the XMM registers like the
> old one did, but it still does not exhaust them -- was this more of a
> concern when this was originally written?
>
I wrote the original SIMD code (IIRC), and back then MMX usage was
acceptable. Nowadays, it carries performance penalties with it and is
deprecated, so the baseline assumptions are just very different.
Your changes look reasonable, thanks for working on this. OK from me.
Ronald
___
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] [RFC] dormant git accounts
On Tue, 12 Nov 2024 17:30:57 + Derek Buitenhuis wrote: > On 11/12/2024 5:05 PM, James Almer wrote: > > This is not true. I have write access to the website, for example, > > as do others. And Michael cuts releases because he was given the > > task, not because nobody else can or want. And nobody prevents > > anyone from just fetching a git tag instead (Distros like Arch do, > > after all). > > It is true, he has acecss to do all of it. Just because others do, > doesn't mean he can't. I am nto syaing he *will*, I'm using it as an > example of the issue. concern trolling? you're concerned about one developer adding in a backdoor, so the solution is to add more developers? if you dont trust the 1 how would you trust the n+1 or the n-1 ? just because they meet you in person and watch you eat a bunch of mosquitos at a dinner ? thats your level of security? its fine, i'm just curious. (you'd think korea would have superior anti-mosquito technology by now) -compn ___ 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] [RFC] dormant git accounts
Hi Kyle On Tue, Nov 12, 2024 at 02:09:25PM -0800, Kyle Swanson wrote: > Hi, > > Should we consult with someone (a professional) outside of FFmpeg to > assess the situation and provide a set of recommendations? This would > be money well spent IMO. I do have a list of ideas from people (not the quite vocal people in the recent threads) about infra. And i intend to go through that list. (which will take time) That said, more ideas are certainly welcome. (please send any and all ideas about improving infra to me and or to ffmpeg-devel, only nice and polite mails welcome) A proper review/audit of our infra is not a bad idea. But that should be done after we ourselfs have reviewed and evaluated suggestions we have come up with ourselfs. So we dont waste money on things we can find ourselfs. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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] [PATCH] avcodec/jpeg2000: Fix undefined behaviour in left shift operations
This patch is incomplete because the UBSAN error in
libavcodec/tests/jpeg2000dwt.c has not been fixed.
I will send the v2 patch soon.
> On Nov 11, 2024, at 17:34, WATANABE Osamu
> wrote:
>
> This patch fixes undefined behaviour error in left shift
> operations in jpeg2000dec.c and jpeg2000htdec.c.
>
> Signed-off-by: Osamu Watanabe
> ---
> libavcodec/jpeg2000dec.c | 6 +++---
> libavcodec/jpeg2000htdec.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index c9d8b025b1..8054129589 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -1886,10 +1886,10 @@ static void decode_sigpass(Jpeg2000T1Context *t1, int
> width, int height,
> if (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states +
> ff_jpeg2000_getsigctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
> bandno))) {
> int xorbit, ctxno =
> ff_jpeg2000_getsgnctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
> &xorbit);
> if (t1->mqc.raw) {
> -t1->data[(y) * t1->stride + x] |=
> ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) << 31;
> +t1->data[(y) * t1->stride + x] |=
> (int)((uint32_t)(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno)) << 31);
> t1->data[(y) * t1->stride + x] |= mask;
> } else {
> -t1->data[(y) * t1->stride + x] |=
> (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit) << 31;
> +t1->data[(y) * t1->stride + x] |=
> (int)((uint32_t)(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit)
> << 31);
> t1->data[(y) * t1->stride + x] |= mask;
> }
> ff_jpeg2000_set_significance(t1, x, y,
> @@ -1969,7 +1969,7 @@ static void decode_clnpass(const Jpeg2000DecoderContext
> *s, Jpeg2000T1Context *t
> int xorbit;
> int ctxno = ff_jpeg2000_getsgnctxno(t1->flags[(y + 1) *
> t1->stride + x + 1] & flags_mask,
> &xorbit);
> -t1->data[(y) * t1->stride + x] |=
> (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit) << 31;
> +t1->data[(y) * t1->stride + x] |=
> (int)((uint32_t)(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit)
> << 31);
> t1->data[(y) * t1->stride + x] |= mask;
> ff_jpeg2000_set_significance(t1, x, y, t1->data[(y) *
> t1->stride + x] & INT32_MIN);
> }
> diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> index 186a6873ac..b4bb6dcf33 100644
> --- a/libavcodec/jpeg2000htdec.c
> +++ b/libavcodec/jpeg2000htdec.c
> @@ -1070,7 +1070,7 @@ static void jpeg2000_process_stripes_block(StateVars
> *sig_prop, int i_s, int j_s
> uint8_t *state_p = block_states + (i + 1) * stride + (j + 1);
> if ((state_p[0] >> HT_SHIFT_REF) & 1) {
> bit = jpeg2000_peek_bit(sig_prop, magref_segment,
> magref_length);
> -*sp |= (int32_t)bit << 31;
> +*sp |= (int32_t)((uint32_t)bit << 31);
> }
> }
> }
> @@ -1160,7 +1160,7 @@ jpeg2000_decode_magref_segment( uint16_t width,
> uint16_t block_height, const int
> jpeg2000_modify_state(i, j, stride, 1 <<
> HT_SHIFT_REF_IND, block_states);
> bit = jpeg2000_import_magref_bit(&mag_ref,
> magref_segment, magref_length);
> tmp = 0xFFFE | (uint32_t)bit;
> -tmp <<= pLSB;
> +tmp = (int32_t)((uint32_t)tmp << pLSB);
> sp[0] &= tmp;
> sp[0] |= 1 << (pLSB - 1); // Add 0.5 (reconstruction
> parameter = 1/2)
> }
> @@ -1176,7 +1176,7 @@ jpeg2000_decode_magref_segment( uint16_t width,
> uint16_t block_height, const int
> jpeg2000_modify_state(i, j, stride, 1 << HT_SHIFT_REF_IND,
> block_states);
> bit = jpeg2000_import_magref_bit(&mag_ref, magref_segment,
> magref_length);
> tmp = 0xFFFE | (uint32_t)bit;
> -tmp <<= pLSB;
> +tmp = (int32_t)((uint32_t)tmp << pLSB);
> sp[0] &= tmp;
> sp[0] |= 1 << (pLSB - 1); // Add 0.5 (reconstruction
> parameter = 1/2)
> }
> --
> 2.43.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] [RFC] dormant git accounts
Hi On Tue, Nov 12, 2024 at 10:38:09PM +, Kieran Kunhya via ffmpeg-devel wrote: > On Tue, 12 Nov 2024, 21:03 Michael Niedermayer, > wrote: > > > On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote: > > > On 11/12/2024 5:07 PM, James Almer wrote: > > > > I personally don't agree with giving the domain/trademark to the > > general > > > > assembly, as some have argued. It's just not safe at all. > > > > > > Sorry, I didn't necessarily mean giving it ot the GA. I mean having it > > in a > > > better state than being held hostage by someone who hasn't been around > > in 20 > > > years and only talks to one person. > > > > > > > > It essentially gives that one person the ability to hold the whole > > project hostage. > > > > This statement is true for every case where a person holds a trademark or > > domain > > Its also true for every legal entity holding them, as said legal entity is > > generally > > controlled by one person at some level. > > > > It's possible to have entities where no single person is in control. which then have a single person applying their decission. Again a single person who holds the password for the domain registrar. One can stack more and more complexity to battle all this. But to go back to the start. The domain and trademark owner has not abused his power ever in the whole lifetime of the project. Some people maybe dont trust anyone they have not personally met, but that is unsolvable unless you limit the size of the community, there will always be community members who never met. > > Most importantly though, if one person is in control, it's documented and > legally required to be on the public record. In the past the community preferred not to publically list individuals so as to make the project and its members harder to attack. Also everyone in the community knows who owns the domain and trademark. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell 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] root access voting
On Tue, 12 Nov 2024 21:17:01 +0200 Rémi Denis-Courmont wrote: > Le sunnuntaina 3. marraskuuta 2024, 19.25.50 EET Michael Niedermayer > a écrit : > > Hi > > > > On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote: > > [...] > > > > > >Thats besides the root admins should generally be professional > > > >admins and not "popular politicans". > > > > > > You have blocked Josh and Marvin, neither of whom strike me as > > > popular politicians (sorry, no offence intended). They're not JB, > > > Ronald or Kieran (again, no offence intended). > > Thats not true in that way. > > That is a straight-up lie, by your own admission. > > > Josh asked for admin access > > I asked if josh is a professional admin and what he does for a > > living. He did refuse to say what he does for a living. > > which is 100% his right but, for me raised a small red flag > > I asked some other people why josh is asking for root access, > > because it seemed a odd request. And was told that theres may be a > > connection to FFlabs > That is a major red flag, very similar to what you yourself claimed > as motivation to reject Josh - precarious employment situation. are you talking about the same Josh who asked not to have their photo taken during vdd? you want a root admin who doesnt tell what their profession is, and have no way of verifying who they are via photograph? and who says they "worked on embedded devices across ... military sectors" (on the about page of their website)? thanks -compn ___ 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] [RFC] dormant git accounts
On Tue, 12 Nov 2024, 21:03 Michael Niedermayer, wrote: > On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote: > > On 11/12/2024 5:07 PM, James Almer wrote: > > > I personally don't agree with giving the domain/trademark to the > general > > > assembly, as some have argued. It's just not safe at all. > > > > Sorry, I didn't necessarily mean giving it ot the GA. I mean having it > in a > > better state than being held hostage by someone who hasn't been around > in 20 > > years and only talks to one person. > > > > > It essentially gives that one person the ability to hold the whole > project hostage. > > This statement is true for every case where a person holds a trademark or > domain > Its also true for every legal entity holding them, as said legal entity is > generally > controlled by one person at some level. > It's possible to have entities where no single person is in control. Most importantly though, if one person is in control, it's documented and legally required to be on the public record. Kieran > ___ 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] [RFC] dormant git accounts
On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote: > On 11/12/2024 5:07 PM, James Almer wrote: > > I personally don't agree with giving the domain/trademark to the general > > assembly, as some have argued. It's just not safe at all. > > Sorry, I didn't necessarily mean giving it ot the GA. I mean having it in a > better state than being held hostage by someone who hasn't been around in 20 > years and only talks to one person. > > It essentially gives that one person the ability to hold the whole project > hostage. This statement is true for every case where a person holds a trademark or domain Its also true for every legal entity holding them, as said legal entity is generally controlled by one person at some level. Thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle 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] [PATCH] avcodec/jpegxl_parser: fix reading lz77-pair as initial entropy symbol
On Thu, 7 Nov 2024 at 17:31, Leo Izen wrote:
>
> The JPEG XL parser has an entropy decoder inside, which supports LZ77
> length-distance pairs. If the first symbol from the entropy stream is an
> LZ77 pair, the bitstream is invalid, so we should abort immediately rather
> than attempt to read it anyway (which would read from the uninitialized
> starting window).
>
> Reported-by: Kacper Michajłow
> Found-by: ossfuzz
> Fixes:
> 368725676/clusterfuzz-testcase-minimized-fuzzer_protocol_file-6022251122589696-cut
> Fixes:
> 42537758/clusterfuzz-testcase-minimized-fuzzer_protocol_file-5818969469026304-cut
> Signed-off-by: Leo Izen
> ---
> libavcodec/jpegxl_parser.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
> index 746c429b9c..76122af54a 100644
> --- a/libavcodec/jpegxl_parser.c
> +++ b/libavcodec/jpegxl_parser.c
> @@ -352,6 +352,8 @@ static int decode_hybrid_varlen_uint(GetBitContext *gb,
> JXLEntropyDecoder *dec,
>
> if (bundle->lz77_enabled && token >= bundle->lz77_min_symbol) {
> const JXLSymbolDistribution *lz77dist =
> &bundle->dists[bundle->cluster_map[bundle->num_dist - 1]];
> +if (!dec->num_decoded)
> +return AVERROR_INVALIDDATA;
> ret = read_hybrid_uint(gb, &bundle->lz_len_conf, token -
> bundle->lz77_min_symbol, &dec->num_to_copy);
> if (ret < 0)
> return ret;
> @@ -531,6 +533,7 @@ static int read_dist_clustering(GetBitContext *gb,
> JXLEntropyDecoder *dec, JXLDi
> dec->state = -1;
> /* it's not going to necessarily be zero after reading */
> dec->num_to_copy = 0;
> +dec->num_decoded = 0;
> dist_bundle_close(&nested);
> if (use_mtf) {
> uint8_t mtf[256];
> --
> 2.47.0
I can confirm it works, thanks.
- Kacper
___
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] root access voting
this mail might have come off angry, i didnt mean for this to be an angry email. can safely ignore this mail. -compn On Tue, 12 Nov 2024 12:51:23 -1000 compn wrote: > are you talking about the same Josh who asked not to have their photo > taken during vdd? > > you want a root admin who doesnt tell what their profession is, and > have no way of verifying who they are via photograph? and who says > they "worked on embedded devices across ... military sectors" (on the > about page of their website)? > > thanks > -compn ___ 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] [RFC] dormant git accounts
On Wed, 13 Nov 2024, 00:10 Michael Niedermayer, wrote: > Hi > > On Tue, Nov 12, 2024 at 10:38:09PM +, Kieran Kunhya via ffmpeg-devel > wrote: > > On Tue, 12 Nov 2024, 21:03 Michael Niedermayer, > > wrote: > > > > > On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote: > > > > On 11/12/2024 5:07 PM, James Almer wrote: > > > > > I personally don't agree with giving the domain/trademark to the > > > general > > > > > assembly, as some have argued. It's just not safe at all. > > > > > > > > Sorry, I didn't necessarily mean giving it ot the GA. I mean having > it > > > in a > > > > better state than being held hostage by someone who hasn't been > around > > > in 20 > > > > years and only talks to one person. > > > > > > > > > > > It essentially gives that one person the ability to hold the whole > > > project hostage. > > > > > > This statement is true for every case where a person holds a trademark > or > > > domain > > > Its also true for every legal entity holding them, as said legal > entity is > > > generally > > > controlled by one person at some level. > > > > > > > It's possible to have entities where no single person is in control. > > which then have a single person applying their decission. Again a single > person who holds the password for the domain registrar. > > One can stack more and more complexity to battle all this. But to > go back to the start. The domain and trademark owner has not abused his > power ever in the whole lifetime of the project. Some people maybe > dont trust anyone they have not personally met, but that is unsolvable > unless you limit the size of the community, there will always be > community members who never met. > > > > > > Most importantly though, if one person is in control, it's documented and > > legally required to be on the public record. > > In the past the community preferred not to publically list individuals so > as to > make the project and its members harder to attack. > > Also everyone in the community knows who owns the domain and trademark. > Who owns avcodec.org? As Derek says this domain also matters. Kieran > ___ 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] [RFC] dormant git accounts
On 11/11/2024 7:33 PM, Michael Niedermayer wrote: >> This only convinces me further that it this whole setup ins't for for >> purpose, >> and is being run by people who have no concept of actual security. This is >> totally insane. Honestly, this is so exhausting and painful, I dread responding. I know you cannot be convinced, per previous mails. Probably why most others stay silent on the list but complain in person, lest they draw the insanity on themselves. > So "publically listing every admins and server owner (where its not the > company) > name" is the normal and sane thing and not listing them publically is totally > insane ? Yes. > Do i understand this correctly? Doubtful. > If so, then iam sure that every security related company lists these > publically? > Likewise the FBI, financial institutions, and so forth. Strawman. > These are organisations where security is very important, but none of them > lists server owners and admins publically. And iam not even sure what they > would do if you called them and asked, but they probably would ask you for > your name, intend and at least internally report this without awnsering your > question. None of these things are community run open source projects, and your comparisons are nuts. Even if you don't think they should be publically known (which I disagree with), the should be known to the project itself outside of your Michael-approved cabal. > But lets go back the original question > 1. what exact information do you ask for ? Complete list of infra, where it is hosted, who has what access (physical and remote/software). This is what VideoLAN does. Yes, I know you are paranoid as hell about a "VideoLAN/j-b takeover", which is... well, others can judge. > 2. why ? See previous endless mails and discussion. > 3. what do you intend to do with this information ? This info is pertinent for a lot of security and stabiltiy reasons. For example, right now, one person (you) has the ability to cut release, modify the website, sign the tarballs, etc. It's all you. I'm sure that's great in your mind, as you deem yourself trustworthy. From our end, nothing stops it from being xz part 2. There is no way to know the tarballs are un-tampered with, other than trusting you. I'm sure this makes perfect sense if you agree with the whole "michael, as person nobody has ever met, and nobody agreed to give absolute power, is trustworthy and infallable" thing, but I sure don't. It's a fiefdom that you rule. > 4. The names of the developers providing the infra have been provided before, > did you look through past discussion? The list is not complete even back then, and it was not documented since. > 5. Do you ask these questions to every project or just FFmpeg ? >(i have been told these questions only happen toward FFmpeg, can you >explain why ?) Every serious and large open source project has this responsibiltiy. We're not some rag tag show, we're a project used by every big company on Earth. > Last years i tried to simply awnser all the questions, but that didnt make > anyone happy. I must be missing something. Answers aren't sufficient or complete, and you purposely avoid giving community power over the ifnrastructure, domains, or trademark. It is solely at your discretion. > I mean we can go through the whole again if people want but I really > think most developers would prefer to work on the code and project instead. Yes, I suppose your banking on the silence == complicity aspect of this. - Derek ___ 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] [RFC] dormant git accounts
Hi, Le 12 novembre 2024 19:07:56 GMT+02:00, James Almer a écrit : >On 11/12/2024 1:58 PM, Derek Buitenhuis wrote: >> Answers aren't sufficient or complete, and you purposely avoid giving >> community >> power over the ifnrastructure, domains, or trademark. It is solely at your >> discretion. > >I personally don't agree with giving the domain/trademark to the general >assembly, as some have argued. It's just not safe at all. I don't think that Derek meant that literally. The GA is not a legal entity so it can't hold a domain name or a trademark in the first place, or for that matter physical servers or hosting service contracts. Just like the bank account, these things should be held by a non-profit - preferably the same one that already has the bank account(s). I think Derek's point is what the governance should be, not what the legal ownership should be. >I do however think the infrastructure needs clarifications and transparency. > ___ 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] [RFC] dormant git accounts
On 11/12/2024 1:58 PM, Derek Buitenhuis wrote: For example, right now, one person (you) has the ability to cut release, modify the website, sign the tarballs, etc. It's all you. I'm sure that's great in your mind, as you deem yourself trustworthy. From our end, nothing stops it from being xz part 2. There is no way to know the tarballs are un-tampered with, other than trusting you. This is not true. I have write access to the website, for example, as do others. And Michael cuts releases because he was given the task, not because nobody else can or want. And nobody prevents anyone from just fetching a git tag instead (Distros like Arch do, after all). Also, the xz fiasco is precisely what prompted him to write a script to compare the contents of tarballs with their respective git tags, and a patch for the security page on the website. It's on the ML. OpenPGP_signature.asc Description: OpenPGP digital 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] [RFC] dormant git accounts
On 11/11/2024 7:34 PM, compn wrote: > if your goal is to post old quotes, thats cool. Woosh. > one of my goals is to make sure that certain developers, who made their > own project and then ran it into the ground, arent made as admins > again. they had a good run but couldnt even make an > announcement that their project had died. the last one out, did not > turn out the lights. I appreciate you going mask off. I don't consider this at all acceptable behavior. - Derek ___ 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 1/3] avcodec/h2645_sei: move some common SEI syncing code to ff_h2645_sei_ctx_replace()
Instead of duplicating it across all supported decoders. Signed-off-by: James Almer --- libavcodec/h2645_sei.c| 3 +++ libavcodec/h264_slice.c | 2 -- libavcodec/hevc/hevcdec.c | 2 -- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c index 62369dd37f..986d1d250a 100644 --- a/libavcodec/h2645_sei.c +++ b/libavcodec/h2645_sei.c @@ -556,6 +556,9 @@ int ff_h2645_sei_ctx_replace(H2645SEI *dst, const H2645SEI *src) } dst->aom_film_grain.enable = src->aom_film_grain.enable; +dst->mastering_display = src->mastering_display; +dst->content_light = src->content_light; + ff_refstruct_replace(&dst->film_grain_characteristics, src->film_grain_characteristics); diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c index 84595b1a8b..08376ffa6d 100644 --- a/libavcodec/h264_slice.c +++ b/libavcodec/h264_slice.c @@ -442,8 +442,6 @@ int ff_h264_update_thread_context(AVCodecContext *dst, return ret; h->sei.common.unregistered.x264_build = h1->sei.common.unregistered.x264_build; -h->sei.common.mastering_display = h1->sei.common.mastering_display; -h->sei.common.content_light = h1->sei.common.content_light; if (!h->cur_pic_ptr) return 0; diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c index 19080255cb..fe8897fb6e 100644 --- a/libavcodec/hevc/hevcdec.c +++ b/libavcodec/hevc/hevcdec.c @@ -4003,8 +4003,6 @@ static int hevc_update_thread_context(AVCodecContext *dst, s->sei.common.frame_packing= s0->sei.common.frame_packing; s->sei.common.display_orientation = s0->sei.common.display_orientation; s->sei.common.alternative_transfer = s0->sei.common.alternative_transfer; -s->sei.common.mastering_display= s0->sei.common.mastering_display; -s->sei.common.content_light= s0->sei.common.content_light; s->sei.tdrdi = s0->sei.tdrdi; return 0; -- 2.47.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".
[FFmpeg-devel] [PATCH 3/3] avcodec/hevc/sei: remove unnecessary inline function
It's a pointless indirection.
Signed-off-by: James Almer
---
libavcodec/h264_sei.h | 6 --
libavcodec/h264_slice.c | 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index bb9275e569..8c8f6e6c73 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -129,12 +129,6 @@ struct H264ParamSets;
int ff_h264_sei_decode(H264SEIContext *h, GetBitContext *gb,
const struct H264ParamSets *ps, void *logctx);
-static inline int ff_h264_sei_ctx_replace(H264SEIContext *dst,
- const H264SEIContext *src)
-{
-return ff_h2645_sei_ctx_replace(&dst->common, &src->common);
-}
-
/**
* Reset SEI values at the beginning of the frame.
*/
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 08376ffa6d..c35ad9b910 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -437,7 +437,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
h->frame_recovered = h1->frame_recovered;
-ret = ff_h264_sei_ctx_replace(&h->sei, &h1->sei);
+ret = ff_h2645_sei_ctx_replace(&h->sei.common, &h1->sei.common);
if (ret < 0)
return ret;
--
2.47.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".
[FFmpeg-devel] [PATCH 2/3] avcodec/hevc/sei: remove unused inline function
It's also a pointless indirection.
Signed-off-by: James Almer
---
libavcodec/hevc/sei.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavcodec/hevc/sei.h b/libavcodec/hevc/sei.h
index 806540fac6..ee640003bc 100644
--- a/libavcodec/hevc/sei.h
+++ b/libavcodec/hevc/sei.h
@@ -109,11 +109,6 @@ struct HEVCParamSets;
int ff_hevc_decode_nal_sei(GetBitContext *gb, void *logctx, HEVCSEI *s,
const struct HEVCParamSets *ps, enum
HEVCNALUnitType type);
-static inline int ff_hevc_sei_ctx_replace(HEVCSEI *dst, const HEVCSEI *src)
-{
-return ff_h2645_sei_ctx_replace(&dst->common, &src->common);
-}
-
/**
* Reset SEI values that are stored on the Context.
* e.g. Caption data that was extracted during NAL
--
2.47.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] remove arpi from MAINTAINERS
On Tue, 12 Nov 2024 10:00:56 + Kieran Kunhya via ffmpeg-devel wrote: > On Tue, 12 Nov 2024, 04:07 compn, wrote: > > > haven't seen arpi in a while so remove his root authorized key + > > remove him from maintainers. maybe he'll come back? > > > > anyone know how to contact tim nicholson? his mails are > > bouncing. https://uk.linkedin.com/in/tim-nicholson-7a2a3963 > > > This is all well and good patch applied. > but arpi still (potentially?) controls some > of our infrastructure yet "hasn't been seen in a while" no. its just this guy who set up ff infrastructure in 2011 [1]. he picked some roots at the time. some were active for a while but then dropped off as they didnt have enough free time. the usual problem with volunteer open source projects. [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2011-March/109620.html > Tim is active on X: https://x.com/TheExecEditor does tim have some spare time to review bugs on trac? -compn ___ 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] [RFC] dormant git accounts
On 11/12/2024 5:07 PM, James Almer wrote: > I personally don't agree with giving the domain/trademark to the general > assembly, as some have argued. It's just not safe at all. Sorry, I didn't necessarily mean giving it ot the GA. I mean having it in a better state than being held hostage by someone who hasn't been around in 20 years and only talks to one person. It essentially gives that one person the ability to hold the whole project hostage. > I do however think the infrastructure needs clarifications and transparency. [...] - Derek ___ 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] [RFC] dormant git accounts
On 11/12/2024 1:58 PM, Derek Buitenhuis wrote: Answers aren't sufficient or complete, and you purposely avoid giving community power over the ifnrastructure, domains, or trademark. It is solely at your discretion. I personally don't agree with giving the domain/trademark to the general assembly, as some have argued. It's just not safe at all. I do however think the infrastructure needs clarifications and transparency. OpenPGP_signature.asc Description: OpenPGP digital 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] [RFC] dormant git accounts
On Tue, 12 Nov 2024 16:46:42 + Derek Buitenhuis wrote: > On 11/11/2024 7:34 PM, compn wrote: > > if your goal is to post old quotes, thats cool. > > Woosh. the quotes are from michael in 2015 saying elect a new leader. pretty sure we never elected one. feel free to start a vote. > > one of my goals is to make sure that certain developers, who made > > their own project and then ran it into the ground, arent made as > > admins again. they had a good run but couldnt even make an > > announcement that their project had died. the last one out, did not > > turn out the lights. > > I appreciate you going mask off. > > I don't consider this at all acceptable behavior. my personal opinion of who can be root in our project is not acceptable behavior ? feel free to explain. i dont think you were an admin there, i wasnt including you in that list. although since you are listed as a member on https://github.com/libav/ , and you asked to be root @ ffmpeg, i'm asking you to do an administrative task and either update that github repo or take the steps to close it down. i asked you in person at vdd last week if you met the requirements to administer ffmpeg (which iirc is just bare minimum "do you have 1+ years of server administration experience"), and you declined to tell me if you met the requirements. which is fine, no one has to tell me anything. not answering simple questions in person, and not updating old github repositories makes me less inclined to vote for you as an administrator in the future. in my personal opinion. -compn ___ 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] lavc/x86/videodsp: Drop MMX usage
Remove the MMX versions of these functions and modify the SSE
implementations to avoid using MMX registers.
Signed-off-by: Frank Plowman
---
This wasn't wholly straightforward as the existing SSE implementation did
not only use SSE but rather a blend of SSE and MMX. I would appreciate
some review, as I am not particularly familiar with x86 assembly. Of
particular interest are the changes to {READ,WRITE}_NUM_BYTES. The new
implementation does not make economic use of the XMM registers like the
old one did, but it still does not exhaust them -- was this more of a
concern when this was originally written?
---
libavcodec/x86/videodsp.asm| 63 ++
libavcodec/x86/videodsp_init.c | 99 +-
2 files changed, 65 insertions(+), 97 deletions(-)
diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
index 3cc07878d3..20dcd3e2b9 100644
--- a/libavcodec/x86/videodsp.asm
+++ b/libavcodec/x86/videodsp.asm
@@ -123,54 +123,43 @@ hvar_fn
; - if (%2 & 8) fills 8 bytes into xmm$next
; - if (%2 & 4) fills 4 bytes into xmm$next
; - if (%2 & 3) fills 1, 2 or 4 bytes in eax
-; on mmx, - fills mm0-7 for consecutive sets of 8 pixels
-; - if (%2 & 4) fills 4 bytes into mm$next
-; - if (%2 & 3) fills 1, 2 or 4 bytes in eax
; writing data out is in the same way
%macro READ_NUM_BYTES 2
%assign %%off 0 ; offset in source buffer
-%assign %%mmx_idx 0 ; mmx register index
%assign %%xmm_idx 0 ; xmm register index
%rep %2/mmsize
-%if mmsize == 16
movu xmm %+ %%xmm_idx, [srcq+%%off]
%assign %%xmm_idx %%xmm_idx+1
-%else ; mmx
-movumm %+ %%mmx_idx, [srcq+%%off]
-%assign %%mmx_idx %%mmx_idx+1
-%endif
%assign %%off %%off+mmsize
%endrep ; %2/mmsize
-%if mmsize == 16
%if (%2-%%off) >= 8
%if %2 > 16 && (%2-%%off) > 8
movu xmm %+ %%xmm_idx, [srcq+%2-16]
%assign %%xmm_idx %%xmm_idx+1
%assign %%off %2
%else
-movqmm %+ %%mmx_idx, [srcq+%%off]
-%assign %%mmx_idx %%mmx_idx+1
+movq xmm %+ %%xmm_idx, [srcq+%%off]
+%assign %%xmm_idx %%xmm_idx+1
%assign %%off %%off+8
%endif
%endif ; (%2-%%off) >= 8
-%endif
%if (%2-%%off) >= 4
%if %2 > 8 && (%2-%%off) > 4
-movqmm %+ %%mmx_idx, [srcq+%2-8]
+movq xmm %+ %%xmm_idx, [srcq+%2-8]
%assign %%off %2
%else
-movdmm %+ %%mmx_idx, [srcq+%%off]
+movd xmm %+ %%xmm_idx, [srcq+%%off]
%assign %%off %%off+4
%endif
-%assign %%mmx_idx %%mmx_idx+1
+%assign %%xmm_idx %%xmm_idx+1
%endif ; (%2-%%off) >= 4
%if (%2-%%off) >= 1
%if %2 >= 4
-movd mm %+ %%mmx_idx, [srcq+%2-4]
+movd xmm %+ %%xmm_idx, [srcq+%2-4]
%elif (%2-%%off) == 1
movvalb, [srcq+%2-1]
%elif (%2-%%off) == 2
@@ -185,48 +174,40 @@ hvar_fn
%macro WRITE_NUM_BYTES 2
%assign %%off 0 ; offset in destination buffer
-%assign %%mmx_idx 0 ; mmx register index
%assign %%xmm_idx 0 ; xmm register index
%rep %2/mmsize
-%if mmsize == 16
movu [dstq+%%off], xmm %+ %%xmm_idx
%assign %%xmm_idx %%xmm_idx+1
-%else ; mmx
-movu [dstq+%%off], mm %+ %%mmx_idx
-%assign %%mmx_idx %%mmx_idx+1
-%endif
%assign %%off %%off+mmsize
%endrep ; %2/mmsize
-%if mmsize == 16
%if (%2-%%off) >= 8
%if %2 > 16 && (%2-%%off) > 8
movu [dstq+%2-16], xmm %+ %%xmm_idx
%assign %%xmm_idx %%xmm_idx+1
%assign %%off %2
%else
-movq [dstq+%%off], mm %+ %%mmx_idx
-%assign %%mmx_idx %%mmx_idx+1
+movq [dstq+%%off], xmm %+ %%xmm_idx
+%assign %%xmm_idx %%xmm_idx+1
%assign %%off %%off+8
%endif
%endif ; (%2-%%off) >= 8
-%endif
%if (%2-%%off) >= 4
%if %2 > 8 && (%2-%%off) > 4
-movq[dstq+%2-8], mm %+ %%mmx_idx
+movq[dstq+%2-8], xmm %+ %%xmm_idx
%assign %%off %2
%else
-movd [dstq+%%off], mm %+ %%mmx_idx
+movd [dstq+%%off], xmm %+ %%xmm_idx
%assign %%off %%off+4
%endif
-%assign %%mmx_idx %%mmx_idx+1
+%assign %%xmm_idx %%xmm_idx+1
%endif ; (%2-%%off) >= 4
%if (%2-%%off) >= 1
%if %2 >= 4
-movd[dstq+%2-4], mm %+ %%mmx_idx
+movd[dstq+%2-4], xmm %+ %%xmm_idx
%elif (%2-%%off) == 1
mov [dstq+%2-1], valb
%elif (%2-%%off) == 2
@@ -318,11 +299,8 @@ cglobal emu_edge_vfix %+ %%n, 1, 5, 1, dst, src, start_y,
end_y, bh
%endrep ; 1+%2-%1
%endmacro ; VERTICAL_EXTEND
-INIT_MMX mmx
-VERTICAL_EXTEND 1, 15
-
-INIT_XMM sse
-VERTICAL_EXTEND 16, 22
+INIT_XMM sse2
+VERTICAL_EXTEND 1, 22
; left/right (horizontal) fast extend functions
; these are essentially identical to the vertical extend ones above,
@@ -337,11 +315,7 @@ VERTICAL_EXTEND 16, 22
imul vald, 0x01010101
%if %1 >= 8
movd m0, vald
-%if mmsize == 16
pshufd m0, m0, q
-%else
-punpckldqm0, m0
-%endif ; mmsize == 16
%endif ; %1 > 16
%endif ; avx2
%endmacro ; READ_V_PIXEL
@@ -356,7 +330,6 @@ VERTICAL_EXTEND 16, 22
%assign %%off %%off+mmsize
%endrep ; %1/mmsize
-%if mmsize == 16
%if %1-%%off >= 8
%if %1 > 16 && %1-%%off > 8
movu [%2+%1-16], m0
@@ -3
Re: [FFmpeg-devel] root access voting
Le sunnuntaina 3. marraskuuta 2024, 19.25.50 EET Michael Niedermayer a écrit : > Hi > > On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote: > [...] > > > >Thats besides the root admins should generally be professional admins and > > >not "popular politicans". > > > > You have blocked Josh and Marvin, neither of whom strike me as popular > > politicians (sorry, no offence intended). They're not JB, Ronald or > > Kieran (again, no offence intended). > Thats not true in that way. That is a straight-up lie, by your own admission. > Josh asked for admin access > I asked if josh is a professional admin and what he does for a living. He > did refuse to say what he does for a living. > which is 100% his right but, for me raised a small red flag > I asked some other people why josh is asking for root access, because it > seemed a odd request. And was told that theres may be a connection to > FFlabs > I don t remember Marvin asking for root, maybe he did and i forgot, i do get > a awfull lot of mail and a lot but less chat. > Also i did not conciously know/remember Marvin is a professional admin. In other words, whatever the good or bad reasons may be, you did block them. > > How do you trust the ghost mplayer/FFmpeg people? How do you trust the > > Bulgarian hosting company? It doesn't help that Bulgaria is statistically > > the most corrupt country in the EU. > seriously ? > the mplayer developers who in some cases risked their job to protect the > server That is a major red flag, very similar to what you yourself claimed as motivation to reject Josh - precarious employment situation. It also makes it sounds like the current hosting situation is unsafe, which is even worse than I'd hypothesised. > and the company in Bulgaria gave us a free, and for our purposes powerfull > and new server, free hosting, unlimited bandwidth IIRC > and some admin in Bulgaria who had physical access if needed. "If [you] recall correctly"? "some admin"? Again, those are big red flags. That sounds a hell of a lot less trustworthy than an FFlabs affiliate that we know in first person. > > Germany, Austria or Switzerland seem a lot more trustworthy places to host > > than Bulgaria. How do you even trust the physical access to hosting? Did > > you visit and see the servers? Otherwise your point about trusting admins > > is completely moot, plain and simple. > I live in Austria, we have corruption here. > with germany, i remember hetzner, just recently had police shutdown tons of > illegal servers So what? My point is about relative corruption statistics, not absence of any corruption, e.g.: https://tradingeconomics.com/country-list/corruption-index?continent=europe -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] [RFC] dormant git accounts
Hi, Should we consult with someone (a professional) outside of FFmpeg to assess the situation and provide a set of recommendations? This would be money well spent IMO. Thanks, Kyle ___ 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] lavc/x86/videodsp: Fix clobbered FPU state on x86-32
Hi, On Mon, Nov 11, 2024 at 4:03 AM Frank Plowman wrote: > I thought the same before submitting this patch, and tried only adding > the line conditionally based on the mmsize, but found neither wrapping > it in an a) mmsize == 8, nor b) mmsize != 8 block alone worked. > Can we just get rid of the MMX version and replace it with a "movd" or "movq" SSE2 version? Ronald ___ 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] lavc/x86/videodsp: Fix clobbered FPU state on x86-32
On 11/12/2024 9:37 AM, Ronald S. Bultje wrote: Hi, On Mon, Nov 11, 2024 at 4:03 AM Frank Plowman wrote: I thought the same before submitting this patch, and tried only adding the line conditionally based on the mmsize, but found neither wrapping it in an a) mmsize == 8, nor b) mmsize != 8 block alone worked. Can we just get rid of the MMX version and replace it with a "movd" or "movq" SSE2 version? No need to replace it, there's an SSE version already using movups. So just delete it. OpenPGP_signature.asc Description: OpenPGP digital 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] [PATCH] remove arpi from MAINTAINERS
On Mon, Nov 11, 2024 at 06:06:07PM -1000, compn wrote: > haven't seen arpi in a while so remove his root authorized key + remove > him from maintainers. maybe he'll come back? it would be cool if arpi came back :) but until then, patch is ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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] [PATCH v6 08/12] swscale/graph: add new high-level scaler dispatch mechanism
On Tue, 12 Nov 2024 10:50:42 +0100 Niklas Haas wrote: > From: Niklas Haas > > This interface has been designed from the ground up to serve as a new > framework for dispatching various scaling operations at a high level. This > will eventually replace the old ad-hoc system of using cascaded contexts, > as well as allowing us to plug in more dynamic scaling passes requiring > intermediate steps, such as colorspace conversions, etc. > > The starter implementation merely piggybacks off the existing sws_init() and > sws_scale(), functions, though it does bring the immediate improvement of > splitting up cascaded functions and pre/post conversion functions into > separate filter passes, which allows them to e.g. be executed in parallel > even when the main scaler is required to be single threaded. Additionally, > a dedicated (multi-threaded) noop memcpy pass substantially improves > throughput of that fast path. > > Follow-up commits will eventually expand this to move all of the scaling > decision logic into the graph init function, and also eliminate some of the > current special cases. FWIW, I am currently working on another branch that pulls all per slice state out of SwsContext and into a separate struct, so we can simplify our threading wrappers in the new API. ___ 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] remove arpi from MAINTAINERS
On Tue, 12 Nov 2024, 04:07 compn, wrote: > haven't seen arpi in a while so remove his root authorized key + remove > him from maintainers. maybe he'll come back? > > anyone know how to contact tim nicholson? his mails are > bouncing. https://uk.linkedin.com/in/tim-nicholson-7a2a3963 This is all well and good but arpi still (potentially?) controls some of our infrastructure yet "hasn't been seen in a while" Tim is active on X: https://x.com/TheExecEditor Kieran ___ 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 v6 05/12] swscale: eliminate redundant SwsInternal accesses
From: Niklas Haas
This is a purely cosmetic commit aimed at replacing accesses to
SwsInternal.opts by direct access to SwsContext wherever convenient.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/options.c | 2 +-
libswscale/swscale.c | 93 ++--
libswscale/utils.c| 233 +++---
tests/checkasm/sw_gbrp.c | 16 +-
tests/checkasm/sw_range_convert.c | 16 +-
tests/checkasm/sw_rgb.c | 29 ++--
tests/checkasm/sw_scale.c | 22 +--
7 files changed, 203 insertions(+), 208 deletions(-)
diff --git a/libswscale/options.c b/libswscale/options.c
index 6248e5f4b5..5eef26de06 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -27,7 +27,7 @@ static const char *sws_context_to_name(void *ptr)
return "swscaler";
}
-#define OFFSET(x) offsetof(SwsInternal, opts.x)
+#define OFFSET(x) offsetof(SwsContext, x)
#define DEFAULT 0
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 5b5a009f1b..45172dcea4 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -895,7 +895,7 @@ static int scale_cascaded(SwsInternal *c,
uint8_t * const dstSlice[], const int dstStride[],
int dstSliceY, int dstSliceH)
{
-const int dstH0 = sws_internal(c->cascaded_context[0])->opts.dst_h;
+const int dstH0 = c->cascaded_context[0]->dst_h;
int ret = scale_internal(c->cascaded_context[0],
srcSlice, srcStride, srcSliceY, srcSliceH,
c->cascaded_tmp[0], c->cascaded_tmpStride[0],
@@ -915,13 +915,13 @@ static int scale_internal(SwsContext *sws,
int dstSliceY, int dstSliceH)
{
SwsInternal *c = sws_internal(sws);
-const int scale_dst = dstSliceY > 0 || dstSliceH < c->opts.dst_h;
+const int scale_dst = dstSliceY > 0 || dstSliceH < sws->dst_h;
const int frame_start = scale_dst || !c->sliceDir;
int i, ret;
const uint8_t *src2[4];
uint8_t *dst2[4];
-int macro_height_src = isBayer(c->opts.src_format) ? 2 : (1 <<
c->chrSrcVSubSample);
-int macro_height_dst = isBayer(c->opts.dst_format) ? 2 : (1 <<
c->chrDstVSubSample);
+int macro_height_src = isBayer(sws->src_format) ? 2 : (1 <<
c->chrSrcVSubSample);
+int macro_height_dst = isBayer(sws->dst_format) ? 2 : (1 <<
c->chrDstVSubSample);
// copy strides, so they can safely be modified
int srcStride2[4];
int dstStride2[4];
@@ -933,25 +933,25 @@ static int scale_internal(SwsContext *sws,
}
if ((srcSliceY & (macro_height_src - 1)) ||
-((srcSliceH & (macro_height_src - 1)) && srcSliceY + srcSliceH !=
c->opts.src_h) ||
-srcSliceY + srcSliceH > c->opts.src_h ||
-(isBayer(c->opts.src_format) && srcSliceH <= 1)) {
+((srcSliceH & (macro_height_src - 1)) && srcSliceY + srcSliceH !=
sws->src_h) ||
+srcSliceY + srcSliceH > sws->src_h ||
+(isBayer(sws->src_format) && srcSliceH <= 1)) {
av_log(c, AV_LOG_ERROR, "Slice parameters %d, %d are invalid\n",
srcSliceY, srcSliceH);
return AVERROR(EINVAL);
}
if ((dstSliceY & (macro_height_dst - 1)) ||
-((dstSliceH & (macro_height_dst - 1)) && dstSliceY + dstSliceH !=
c->opts.dst_h) ||
-dstSliceY + dstSliceH > c->opts.dst_h) {
+((dstSliceH & (macro_height_dst - 1)) && dstSliceY + dstSliceH !=
sws->dst_h) ||
+dstSliceY + dstSliceH > sws->dst_h) {
av_log(c, AV_LOG_ERROR, "Slice parameters %d, %d are invalid\n",
dstSliceY, dstSliceH);
return AVERROR(EINVAL);
}
-if (!check_image_pointers(srcSlice, c->opts.src_format, srcStride)) {
+if (!check_image_pointers(srcSlice, sws->src_format, srcStride)) {
av_log(c, AV_LOG_ERROR, "bad src image pointers\n");
return AVERROR(EINVAL);
}
-if (!check_image_pointers((const uint8_t* const*)dstSlice,
c->opts.dst_format, dstStride)) {
+if (!check_image_pointers((const uint8_t* const*)dstSlice,
sws->dst_format, dstStride)) {
av_log(c, AV_LOG_ERROR, "bad dst image pointers\n");
return AVERROR(EINVAL);
}
@@ -960,22 +960,19 @@ static int scale_internal(SwsContext *sws,
if (srcSliceH == 0)
return 0;
-if (c->opts.gamma_flag && c->cascaded_context[0])
+if (sws->gamma_flag && c->cascaded_context[0])
return scale_gamma(c, srcSlice, srcStride, srcSliceY, srcSliceH,
dstSlice, dstStride, dstSliceY, dstSliceH);
-if (c->cascaded_context[0] && srcSliceY == 0 &&
-srcSliceH == sws_internal(c->cascaded_context[0])->opts.src_h)
-{
+if (c->cascaded_context[0] && srcSliceY == 0 && srcSliceH ==
c->cascaded_context[0]->src_h)
return scale_cascaded(c, srcSlice, srcStride, srcSliceY, srcSliceH,
ds
[FFmpeg-devel] [PATCH v6 01/12] swscale/options: cosmetic changes
From: Niklas Haas
Reorganize the list, fix whitespace, make indentation consistent, and
rename some descriptions for clarity, consistency or informativeness.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/options.c | 86 ++--
1 file changed, 44 insertions(+), 42 deletions(-)
diff --git a/libswscale/options.c b/libswscale/options.c
index 56b1d2235d..e64e289cf3 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -32,55 +32,57 @@ static const char *sws_context_to_name(void *ptr)
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption swscale_options[] = {
-{ "sws_flags", "scaler flags", OFFSET(flags),
AV_OPT_TYPE_FLAGS, { .i64 = SWS_BICUBIC}, 0, UINT_MAX,
VE, .unit = "sws_flags" },
-{ "fast_bilinear", "fast bilinear", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_FAST_BILINEAR }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bilinear","bilinear", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_BILINEAR }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bicubic", "bicubic", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_BICUBIC}, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "experimental","experimental", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_X }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "neighbor","nearest neighbor", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_POINT }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "area","averaging area",0,
AV_OPT_TYPE_CONST, { .i64 = SWS_AREA }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bicublin","luma bicubic, chroma bilinear", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_BICUBLIN }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "gauss", "Gaussian", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_GAUSS }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "sinc","sinc", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_SINC }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "lanczos", "Lanczos", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_LANCZOS}, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "spline", "natural bicubic spline",0,
AV_OPT_TYPE_CONST, { .i64 = SWS_SPLINE }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "print_info", "print info",0,
AV_OPT_TYPE_CONST, { .i64 = SWS_PRINT_INFO }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "accurate_rnd","accurate rounding", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_ACCURATE_RND }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "full_chroma_int", "full chroma interpolation", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_FULL_CHR_H_INT }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "full_chroma_inp", "full chroma input", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_FULL_CHR_H_INP }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bitexact","", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_BITEXACT }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "error_diffusion", "error diffusion dither",0,
AV_OPT_TYPE_CONST, { .i64 = SWS_ERROR_DIFFUSION}, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
+{ "sws_flags", "swscale flags", OFFSET(flags),
AV_OPT_TYPE_FLAGS, { .i64 = SWS_BICUBIC}, .flags = VE, .unit =
"sws_flags", .max = UINT_MAX },
+{ "fast_bilinear", "fast bilinear", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_FAST_BILINEAR }, .flags = VE, .unit =
"sws_flags" },
+{ "bilinear","bilinear", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_BILINEAR }, .flags = VE, .unit =
"sws_flags" },
+{ "bicubic", "bicubic", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_BICUBIC}, .flags = VE, .unit =
"sws_flags" },
+{ "experimental","experimental", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_X }, .flags = VE, .unit =
"sws_flags" },
+{ "neighbor","nearest neighbor", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_POINT }, .flags = VE, .unit =
"sws_flags" },
+{ "area","averaging area",
[FFmpeg-devel] [PATCH v6 02/12] swscale/internal: use static_assert for enforcing offsets
From: Niklas Haas
Instead of sprinkling av_assert0 into random init functions.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale_internal.h | 11 +++
libswscale/utils.c| 2 --
libswscale/x86/swscale.c | 4
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 0035168997..0ab4e67270 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -22,6 +22,7 @@
#define SWSCALE_SWSCALE_INTERNAL_H
#include
+#include
#include "config.h"
#include "swscale.h"
@@ -705,6 +706,16 @@ struct SwsInternal {
};
//FIXME check init (where 0)
+static_assert(offsetof(SwsInternal, redDither) + DITHER32_INT ==
offsetof(SwsInternal, dither32),
+ "dither32 must be at the same offset as redDither +
DITHER32_INT");
+
+#if ARCH_X86_64
+/* x86 yuv2gbrp uses the SwsInternal for yuv coefficients
+ if struct offsets change the asm needs to be updated too */
+static_assert(offsetof(SwsInternal, yuv2rgb_y_offset) == 40292,
+ "yuv2rgb_y_offset must be updated in x86 asm");
+#endif
+
SwsFunc ff_yuv2rgb_get_func_ptr(SwsInternal *c);
int ff_yuv2rgb_c_init_tables(SwsInternal *c, const int inv_table[4],
int fullRange, int brightness,
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 5c21f9de4a..f71c63c17f 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1228,8 +1228,6 @@ SwsContext *sws_alloc_context(void)
{
SwsInternal *c = av_mallocz(sizeof(SwsInternal));
-av_assert0(offsetof(SwsInternal, redDither) + DITHER32_INT ==
offsetof(SwsInternal, dither32));
-
if (c) {
c->av_class = &ff_sws_context_class;
av_opt_set_defaults(c);
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index ceafdf4aef..40bfe4a2f6 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -791,10 +791,6 @@ switch(c->dstBpc){ \
if(c->flags & SWS_FULL_CHR_H_INT) {
-/* yuv2gbrp uses the SwsInternal for yuv coefficients
- if struct offsets change the asm needs to be updated too */
-av_assert0(offsetof(SwsInternal, yuv2rgb_y_offset) == 40292);
-
#define YUV2ANYX_FUNC_CASE(fmt, name, opt) \
case fmt: \
c->yuv2anyX = ff_yuv2##name##_full_X_##opt; \
--
2.47.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".
[FFmpeg-devel] [PATCH v6 00/12] swscale: introduce new, dynamic scaling API
Changes since v5: - Fix FATE regression introduced in v5 - Fix build error on loongson introduced by rebase ___ 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 v6 12/12] avfilter/vf_scale: switch to new swscale API
From: Niklas Haas
Most logic from this filter has been co-opted into swscale itself,
allowing the resulting filter to be substantially simpler as it no
longer has to worry about context initialization, interlacing, etc.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libavfilter/vf_scale.c | 354 +
1 file changed, 72 insertions(+), 282 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index a89ebe8c47..4afad8d958 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -31,6 +31,7 @@
#include "filters.h"
#include "formats.h"
#include "framesync.h"
+#include "libavutil/pixfmt.h"
#include "scale_eval.h"
#include "video.h"
#include "libavutil/eval.h"
@@ -131,10 +132,7 @@ enum EvalMode {
typedef struct ScaleContext {
const AVClass *class;
-struct SwsContext *sws; ///< software scaler context
-struct SwsContext *isws[2]; ///< software scaler context for interlaced
material
-// context used for forwarding options to sws
-struct SwsContext *sws_opts;
+SwsContext *sws;
FFFrameSync fs;
/**
@@ -149,8 +147,6 @@ typedef struct ScaleContext {
int hsub, vsub; ///< chroma subsampling
int slice_y;///< top of current output slice
-int input_is_pal; ///< set to 1 if the input format is paletted
-int output_is_pal; ///< set to 1 if the output format is paletted
int interlaced;
int uses_ref;
@@ -170,10 +166,6 @@ typedef struct ScaleContext {
int in_chroma_loc;
int out_chroma_loc;
-int out_h_chr_pos;
-int out_v_chr_pos;
-int in_h_chr_pos;
-int in_v_chr_pos;
int force_original_aspect_ratio;
int force_divisible_by;
@@ -334,40 +326,24 @@ revert:
static av_cold int preinit(AVFilterContext *ctx)
{
ScaleContext *scale = ctx->priv;
-int ret;
-scale->sws_opts = sws_alloc_context();
-if (!scale->sws_opts)
+scale->sws = sws_alloc_context();
+if (!scale->sws)
return AVERROR(ENOMEM);
// set threads=0, so we can later check whether the user modified it
-ret = av_opt_set_int(scale->sws_opts, "threads", 0, 0);
-if (ret < 0)
-return ret;
+scale->sws->threads = 0;
ff_framesync_preinit(&scale->fs);
return 0;
}
-static const int sws_colorspaces[] = {
-AVCOL_SPC_UNSPECIFIED,
-AVCOL_SPC_RGB,
-AVCOL_SPC_BT709,
-AVCOL_SPC_BT470BG,
-AVCOL_SPC_SMPTE170M,
-AVCOL_SPC_FCC,
-AVCOL_SPC_SMPTE240M,
-AVCOL_SPC_BT2020_NCL,
--1
-};
-
static int do_scale(FFFrameSync *fs);
static av_cold int init(AVFilterContext *ctx)
{
ScaleContext *scale = ctx->priv;
-int64_t threads;
int ret;
if (ctx->filter == &ff_vf_scale2ref)
@@ -407,14 +383,13 @@ static av_cold int init(AVFilterContext *ctx)
if (ret < 0)
return ret;
-if (scale->in_color_matrix != -1 &&
-!ff_fmt_is_in(scale->in_color_matrix, sws_colorspaces)) {
+if (scale->in_color_matrix != -1 &&
!sws_test_colorspace(scale->in_color_matrix, 0)) {
av_log(ctx, AV_LOG_ERROR, "Unsupported input color matrix '%s'\n",
av_color_space_name(scale->in_color_matrix));
return AVERROR(EINVAL);
}
-if (!ff_fmt_is_in(scale->out_color_matrix, sws_colorspaces)) {
+if (scale->out_color_matrix != -1 &&
!sws_test_colorspace(scale->out_color_matrix, 1)) {
av_log(ctx, AV_LOG_ERROR, "Unsupported output color matrix '%s'\n",
av_color_space_name(scale->out_color_matrix));
return AVERROR(EINVAL);
@@ -424,25 +399,18 @@ static av_cold int init(AVFilterContext *ctx)
scale->w_expr, scale->h_expr, (char
*)av_x_if_null(scale->flags_str, ""), scale->interlaced);
if (scale->flags_str && *scale->flags_str) {
-ret = av_opt_set(scale->sws_opts, "sws_flags", scale->flags_str, 0);
+ret = av_opt_set(scale->sws, "sws_flags", scale->flags_str, 0);
if (ret < 0)
return ret;
}
for (int i = 0; i < FF_ARRAY_ELEMS(scale->param); i++)
-if (scale->param[i] != DBL_MAX) {
-ret = av_opt_set_double(scale->sws_opts, i ? "param1" : "param0",
-scale->param[i], 0);
-if (ret < 0)
-return ret;
-}
+if (scale->param[i] != DBL_MAX)
+scale->sws->scaler_params[i] = scale->param[i];
// use generic thread-count if the user did not set it explicitly
-ret = av_opt_get_int(scale->sws_opts, "threads", 0, &threads);
-if (ret < 0)
-return ret;
-if (!threads)
-av_opt_set_int(scale->sws_opts, "threads",
ff_filter_get_nb_threads(ctx), 0);
+if (!scale->sws->threads)
+scale->sws->threads = ff_filter_get_nb_threads(ctx);
if (ctx->filter != &ff_vf_scale2ref && scale->uses_ref) {
AVFilterPad pad = {
@@ -464,11 +432,7 @@ static av_cold void uni
[FFmpeg-devel] [PATCH v6 04/12] swscale: expose SwsContext publicly
From: Niklas Haas
Following in the footsteps of the work in the previous commit, it's now
relatively straightforward to expose the options struct publicly as
SwsContext. This is a step towards making this more user friendly, as
well as following API conventions established elsewhere.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.h | 93 +++--
libswscale/swscale_internal.h | 45 +
libswscale/utils.c| 123 +++---
3 files changed, 144 insertions(+), 117 deletions(-)
diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index 50c705ae06..4baef532b6 100644
--- a/libswscale/swscale.h
+++ b/libswscale/swscale.h
@@ -42,8 +42,6 @@
#include "version.h"
#endif
-typedef struct SwsContext SwsContext;
-
/**
* @defgroup libsws libswscale
* Color conversion and scaling library.
@@ -65,17 +63,98 @@ const char *swscale_configuration(void);
const char *swscale_license(void);
/**
- * Get the AVClass for swsContext. It can be used in combination with
+ * Get the AVClass for SwsContext. It can be used in combination with
* AV_OPT_SEARCH_FAKE_OBJ for examining options.
*
* @see av_opt_find().
*/
const AVClass *sws_get_class(void);
-/**
- * Allocate an empty SwsContext. This must be filled and passed to
- * sws_init_context(). For filling see AVOptions, options.c and
- * sws_setColorspaceDetails().
+/**
+ * Flags and quality settings *
+ **/
+
+typedef enum SwsDither {
+SWS_DITHER_NONE = 0, /* disable dithering */
+SWS_DITHER_AUTO, /* auto-select from preset */
+SWS_DITHER_BAYER,/* ordered dither matrix */
+SWS_DITHER_ED, /* error diffusion */
+SWS_DITHER_A_DITHER, /* arithmetic addition */
+SWS_DITHER_X_DITHER, /* arithmetic xor */
+SWS_DITHER_NB, /* not part of the ABI */
+} SwsDither;
+
+typedef enum SwsAlphaBlend {
+SWS_ALPHA_BLEND_NONE = 0,
+SWS_ALPHA_BLEND_UNIFORM,
+SWS_ALPHA_BLEND_CHECKERBOARD,
+SWS_ALPHA_BLEND_NB, /* not part of the ABI */
+} SwsAlphaBlend;
+
+/***
+ * Context creation and management *
+ ***/
+
+/**
+ * Main external API structure. New fields can be added to the end with
+ * minor version bumps. Removal, reordering and changes to existing fields
+ * require a major version bump. sizeof(SwsContext) is not part of the ABI.
+ */
+typedef struct SwsContext {
+const AVClass *av_class;
+
+/**
+ * Private data of the user, can be used to carry app specific stuff.
+ */
+void *opaque;
+
+/**
+ * Bitmask of SWS_*.
+ */
+unsigned flags;
+
+/**
+ * Extra parameters for fine-tuning certain scalers.
+ */
+double scaler_params[2];
+
+/**
+ * How many threads to use for processing, or 0 for automatic selection.
+ */
+int threads;
+
+/**
+ * Dither mode.
+ */
+SwsDither dither;
+
+/**
+ * Alpha blending mode. See `SwsAlphaBlend` for details.
+ */
+SwsAlphaBlend alpha_blend;
+
+/**
+ * Use gamma correct scaling.
+ */
+int gamma_flag;
+
+/**
+ * Frame property overrides.
+ */
+int src_w, src_h; ///< Width and height of the source frame
+int dst_w, dst_h; ///< Width and height of the destination frame
+int src_format;///< Source pixel format
+int dst_format;///< Destination pixel format
+int src_range; ///< Source is full range
+int dst_range; ///< Destination is full range
+int src_v_chr_pos; ///< Source vertical chroma position in luma grid / 256
+int src_h_chr_pos; ///< Source horizontal chroma position
+int dst_v_chr_pos; ///< Destination vertical chroma position
+int dst_h_chr_pos; ///< Destination horizontal chroma position
+} SwsContext;
+
+/**
+ * Allocate an empty SwsContext and set its fields to default values.
*/
SwsContext *sws_alloc_context(void);
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 643177d14d..5218ab0921 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -73,23 +73,6 @@ static inline SwsInternal *sws_internal(const SwsContext
*sws)
return (SwsInternal *) sws;
}
-typedef enum SwsDither {
-SWS_DITHER_NONE = 0,
-SWS_DITHER_AUTO,
-SWS_DITHER_BAYER,
-SWS_DITHER_ED,
-SWS_DITHER_A_DITHER,
-SWS_DITHER_X_DITHER,
-SWS_DITHER_NB,
-} SwsDither;
-
-typedef enum SwsAlphaBlend {
-SWS_ALPHA_BLEND_NONE = 0,
-SWS_ALPHA_BLEND_UNIFORM,
-SWS_ALPHA_BLEND_CHECKERBOARD,
-SWS_ALPHA_BLEND_NB,
-} SwsAlphaBlend;
-
typedef struct Range {
unsigned int start;
unsigned int len;
@@ -329,32 +312,10 @@ struct SwsFilterDescriptor;
/* This struct should be aligned on at least a 32-byte boundary. */
struct SwsInternal {
-/* Currently active user-facing options. */
-struct {
-
[FFmpeg-devel] [PATCH v6 06/12] swscale: organize and better document flags
From: Niklas Haas
Group them into an enum rather than random #defines, and document their
behavior a bit more obviously.
Of particular note, I discovered that SWS_DIRECT_BGR is not referenced
anywhere else in the code base. As such, I have moved it to the deprecated
section, alongside SWS_ERROR_DIFFUSION.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.h | 116 ---
1 file changed, 66 insertions(+), 50 deletions(-)
diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index 4baef532b6..3996411dc8 100644
--- a/libswscale/swscale.h
+++ b/libswscale/swscale.h
@@ -91,6 +91,71 @@ typedef enum SwsAlphaBlend {
SWS_ALPHA_BLEND_NB, /* not part of the ABI */
} SwsAlphaBlend;
+typedef enum SwsFlags {
+/**
+ * Scaler selection options. Only one may be active at a time.
+ */
+SWS_FAST_BILINEAR = 1 << 0, ///< fast bilinear filtering
+SWS_BILINEAR = 1 << 1, ///< bilinear filtering
+SWS_BICUBIC = 1 << 2, ///< 2-tap cubic B-spline
+SWS_X = 1 << 3, ///< experimental
+SWS_POINT = 1 << 4, ///< nearest neighbor
+SWS_AREA = 1 << 5, ///< area averaging
+SWS_BICUBLIN = 1 << 6, ///< bicubic luma, bilinear chroma
+SWS_GAUSS = 1 << 7, ///< gaussian approximation
+SWS_SINC = 1 << 8, ///< unwindowed sinc
+SWS_LANCZOS = 1 << 9, ///< 3-tap sinc/sinc
+SWS_SPLINE= 1 << 10, ///< cubic Keys spline
+
+/**
+ * Emit verbose log of scaling parameters.
+ */
+SWS_PRINT_INFO= 1 << 12,
+
+/**
+ * Perform full chroma upsampling when upscaling to RGB.
+ *
+ * For example, when converting 50x50 yuv420p to 100x100 rgba, setting
this flag
+ * will scale the chroma plane from 25x25 to 100x100 (4:4:4), and then
convert
+ * the 100x100 yuv444p image to rgba in the final output step.
+ *
+ * Without this flag, the chroma plane is instead scaled to 50x100 (4:2:2),
+ * with a single chroma sample being re-used for both of the horizontally
+ * adjacent RGBA output pixels.
+ */
+SWS_FULL_CHR_H_INT = 1 << 13,
+
+/**
+ * Perform full chroma interpolation when downscaling RGB sources.
+ *
+ * For example, when converting a 100x100 rgba source to 50x50 yuv444p,
setting
+ * this flag will generate a 100x100 (4:4:4) chroma plane, which is then
+ * downscaled to the required 50x50.
+ *
+ * Without this flag, the chroma plane is instead generated at 50x100
(dropping
+ * every other pixel), before then being downscaled to the required 50x50
+ * resolution.
+ */
+SWS_FULL_CHR_H_INP = 1 << 14,
+
+/**
+ * Force bit-exact output. This will prevent the use of platform-specific
+ * optimizations that may lead to slight difference in rounding, in favor
+ * of always maintaining exact bit output compatibility with the reference
+ * C code.
+ *
+ * Note: It is recommended to set both of these flags simultaneously.
+ */
+SWS_ACCURATE_RND = 1 << 18,
+SWS_BITEXACT = 1 << 19,
+
+/**
+ * Deprecated flags.
+ */
+SWS_DIRECT_BGR = 1 << 15, ///< This flag has no effect
+SWS_ERROR_DIFFUSION = 1 << 23, ///< Set `SwsContext.dither` instead
+} SwsFlags;
+
/***
* Context creation and management *
***/
@@ -109,7 +174,7 @@ typedef struct SwsContext {
void *opaque;
/**
- * Bitmask of SWS_*.
+ * Bitmask of SWS_*. See `SwsFlags` for details.
*/
unsigned flags;
@@ -225,60 +290,11 @@ int sws_test_frame(const AVFrame *frame, int output);
*/
int sws_is_noop(const AVFrame *dst, const AVFrame *src);
-/* values for the flags, the stuff on the command line is different */
-#define SWS_FAST_BILINEAR 1
-#define SWS_BILINEAR 2
-#define SWS_BICUBIC 4
-#define SWS_X 8
-#define SWS_POINT 0x10
-#define SWS_AREA 0x20
-#define SWS_BICUBLIN 0x40
-#define SWS_GAUSS 0x80
-#define SWS_SINC 0x100
-#define SWS_LANCZOS 0x200
-#define SWS_SPLINE0x400
-
#define SWS_SRC_V_CHR_DROP_MASK 0x3
#define SWS_SRC_V_CHR_DROP_SHIFT16
#define SWS_PARAM_DEFAULT 123456
-#define SWS_PRINT_INFO 0x1000
-
-//the following 3 flags are not completely implemented
-
-/**
- * Perform full chroma upsampling when upscaling to RGB.
- *
- * For example, when converting 50x50 yuv420p to 100x100 rgba, setting this
flag
- * will scale the chroma plane from 25x25 to 100x100 (4:4:4), and then convert
- * the 100x100 yuv444p image to rgba in the final output step.
- *
- * Without this flag, the chroma plane is instead scaled to 50x100 (4:2:2),
- * with a single chroma sample being re-used for both of the horizontally
- * adjacent RGBA output pixels.
- */
-#define SWS_FULL_CHR_H_INT0x2000
-
[FFmpeg-devel] [PATCH v6 07/12] swscale/internal: expose sws_init_single_context() internally
From: Niklas Haas
Used by the graph API swscale wrapper, for now.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale_internal.h | 3 +++
libswscale/utils.c| 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 5218ab0921..7c9517975b 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -958,6 +958,9 @@ extern const int32_t ff_yuv2rgb_coeffs[11][4];
extern const AVClass ff_sws_context_class;
+int sws_init_single_context(SwsContext *sws, SwsFilter *srcFilter,
+SwsFilter *dstFilter);
+
/**
* Set c->convert_unscaled to an unscaled converter if one exists for the
* specific source and destination formats, bit depths, flags, etc.
diff --git a/libswscale/utils.c b/libswscale/utils.c
index a01138d11b..1b6f54fc30 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1312,8 +1312,8 @@ static enum AVPixelFormat alphaless_fmt(enum
AVPixelFormat fmt)
}
}
-static av_cold int sws_init_single_context(SwsContext *sws, SwsFilter
*srcFilter,
- SwsFilter *dstFilter)
+av_cold int sws_init_single_context(SwsContext *sws, SwsFilter *srcFilter,
+SwsFilter *dstFilter)
{
int i;
int usesVFilter, usesHFilter;
--
2.47.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".
[FFmpeg-devel] [PATCH v6 11/12] tests/swscale: add a benchmarking mode
From: Niklas Haas
With the ability to set the thread count as well. This benchmark includes
the constant overhead of context initialization.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/tests/swscale.c | 93 --
1 file changed, 68 insertions(+), 25 deletions(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index c11a46024e..f5ad4b3132 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -31,21 +31,22 @@
#include "libavutil/lfg.h"
#include "libavutil/sfc64.h"
#include "libavutil/frame.h"
+#include "libavutil/opt.h"
+#include "libavutil/time.h"
#include "libavutil/pixfmt.h"
#include "libavutil/avassert.h"
#include "libavutil/macros.h"
#include "libswscale/swscale.h"
-enum {
-WIDTH = 96,
-HEIGHT = 96,
-};
-
struct options {
enum AVPixelFormat src_fmt;
enum AVPixelFormat dst_fmt;
double prob;
+int w, h;
+int threads;
+int iters;
+int bench;
};
struct mode {
@@ -53,9 +54,6 @@ struct mode {
SwsDither dither;
};
-const int dst_w[] = { WIDTH, WIDTH - WIDTH / 3, WIDTH + WIDTH / 3 };
-const int dst_h[] = { HEIGHT, HEIGHT - HEIGHT / 3, HEIGHT + HEIGHT / 3 };
-
const struct mode modes[] = {
{ SWS_FAST_BILINEAR },
{ SWS_BILINEAR },
@@ -114,7 +112,8 @@ static void get_mse(int mse[4], const AVFrame *a, const
AVFrame *b, int comps)
}
}
-static int scale_legacy(AVFrame *dst, const AVFrame *src, struct mode mode)
+static int scale_legacy(AVFrame *dst, const AVFrame *src, struct mode mode,
+struct options opts)
{
SwsContext *sws_legacy;
int ret;
@@ -131,23 +130,28 @@ static int scale_legacy(AVFrame *dst, const AVFrame *src,
struct mode mode)
sws_legacy->dst_format = dst->format;
sws_legacy->flags = mode.flags;
sws_legacy->dither = mode.dither;
+sws_legacy->threads= opts.threads;
+
+if ((ret = sws_init_context(sws_legacy, NULL, NULL)) < 0)
+goto error;
-ret = sws_init_context(sws_legacy, NULL, NULL);
-if (!ret)
+for (int i = 0; i < opts.iters; i++)
ret = sws_scale_frame(sws_legacy, dst, src);
+error:
sws_freeContext(sws_legacy);
return ret;
}
/* Runs a series of ref -> src -> dst -> out, and compares out vs ref */
static int run_test(enum AVPixelFormat src_fmt, enum AVPixelFormat dst_fmt,
-int dst_w, int dst_h, struct mode mode, const AVFrame *ref,
-const int mse_ref[4])
+int dst_w, int dst_h, struct mode mode, struct options
opts,
+const AVFrame *ref, const int mse_ref[4])
{
AVFrame *src = NULL, *dst = NULL, *out = NULL;
int mse[4], mse_sws[4], ret = -1;
const int comps = fmt_comps(src_fmt) & fmt_comps(dst_fmt);
+int64_t time, time_ref = 0;
src = av_frame_alloc();
dst = av_frame_alloc();
@@ -174,12 +178,20 @@ static int run_test(enum AVPixelFormat src_fmt, enum
AVPixelFormat dst_fmt,
sws[1]->flags = mode.flags;
sws[1]->dither = mode.dither;
-if (sws_scale_frame(sws[1], dst, src) < 0) {
-fprintf(stderr, "Failed %s ---> %s\n",
av_get_pix_fmt_name(src->format),
-av_get_pix_fmt_name(dst->format));
-goto error;
+sws[1]->threads = opts.threads;
+
+time = av_gettime_relative();
+
+for (int i = 0; i < opts.iters; i++) {
+if (sws_scale_frame(sws[1], dst, src) < 0) {
+fprintf(stderr, "Failed %s ---> %s\n",
av_get_pix_fmt_name(src->format),
+av_get_pix_fmt_name(dst->format));
+goto error;
+}
}
+time = av_gettime_relative() - time;
+
if (sws_scale_frame(sws[2], out, dst) < 0) {
fprintf(stderr, "Failed %s ---> %s\n",
av_get_pix_fmt_name(dst->format),
av_get_pix_fmt_name(out->format));
@@ -196,11 +208,13 @@ static int run_test(enum AVPixelFormat src_fmt, enum
AVPixelFormat dst_fmt,
if (!mse_ref) {
/* Compare against the legacy swscale API as a reference */
-if (scale_legacy(dst, src, mode) < 0) {
+time_ref = av_gettime_relative();
+if (scale_legacy(dst, src, mode, opts) < 0) {
fprintf(stderr, "Failed ref %s ---> %s\n",
av_get_pix_fmt_name(src->format),
av_get_pix_fmt_name(dst->format));
goto error;
}
+time_ref = av_gettime_relative() - time_ref;
if (sws_scale_frame(sws[2], out, dst) < 0)
goto error;
@@ -221,6 +235,15 @@ static int run_test(enum AVPixelFormat src_fmt, enum
AVPixelFormat dst_fmt,
}
}
+if (opts.bench && time_ref) {
+printf(" time=%"PRId64" us, ref=%"PRId64" us, speedup=%.3fx %s\n",
+time / opts.iters, time_ref / opts.iters,
+(double) time_ref / time,
+time <= time_ref ? "faster" : "\033[1;33mslower\033[0m");
+} else if (o
[FFmpeg-devel] [PATCH v6 08/12] swscale/graph: add new high-level scaler dispatch mechanism
From: Niklas Haas
This interface has been designed from the ground up to serve as a new
framework for dispatching various scaling operations at a high level. This
will eventually replace the old ad-hoc system of using cascaded contexts,
as well as allowing us to plug in more dynamic scaling passes requiring
intermediate steps, such as colorspace conversions, etc.
The starter implementation merely piggybacks off the existing sws_init() and
sws_scale(), functions, though it does bring the immediate improvement of
splitting up cascaded functions and pre/post conversion functions into
separate filter passes, which allows them to e.g. be executed in parallel
even when the main scaler is required to be single threaded. Additionally,
a dedicated (multi-threaded) noop memcpy pass substantially improves
throughput of that fast path.
Follow-up commits will eventually expand this to move all of the scaling
decision logic into the graph init function, and also eliminate some of the
current special cases.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/Makefile | 1 +
libswscale/graph.c | 597
libswscale/graph.h | 122 +
3 files changed, 720 insertions(+)
create mode 100644 libswscale/graph.c
create mode 100644 libswscale/graph.h
diff --git a/libswscale/Makefile b/libswscale/Makefile
index 757997b401..81f32f4dd7 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -9,6 +9,7 @@ OBJS = alphablend.o \
hscale.o \
hscale_fast_bilinear.o \
gamma.o \
+ graph.o \
half2float.o \
input.o \
options.o\
diff --git a/libswscale/graph.c b/libswscale/graph.c
new file mode 100644
index 00..e0388bac61
--- /dev/null
+++ b/libswscale/graph.c
@@ -0,0 +1,597 @@
+/*
+ * Copyright (C) 2024 Niklas Haas
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/error.h"
+#include "libavutil/macros.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/slicethread.h"
+
+#include "libswscale/swscale.h"
+#include "libswscale/utils.h"
+
+#include "swscale_internal.h"
+#include "graph.h"
+
+/* slice_align should be a power of two, or 0 to disable slice threading */
+static SwsPass *pass_add(SwsGraph *graph, void *priv, int w, int h,
+ sws_filter_run_t run, SwsImg in, SwsImg out,
+ int slice_align)
+{
+SwsPass *pass = av_mallocz(sizeof(*pass));
+int ret;
+
+pass->graph = graph;
+pass->run= run;
+pass->input = in;
+pass->output = out;
+pass->priv = priv;
+pass->width = w;
+pass->height = h;
+
+if (!slice_align) {
+pass->slice_h = pass->height;
+pass->num_slices = 1;
+} else {
+pass->slice_h = (pass->height + graph->num_threads - 1) /
graph->num_threads;
+pass->slice_h = FFALIGN(pass->slice_h, slice_align);
+pass->num_slices = (pass->height + pass->slice_h - 1) / pass->slice_h;
+}
+
+ret = av_dynarray_add_nofree(&graph->passes, &graph->num_passes, pass);
+if (ret < 0)
+av_freep(&pass);
+return pass;
+}
+
+/* Set output linesize before calling this */
+static int pass_alloc_output(SwsPass *pass)
+{
+const int aligned_h = pass->num_slices * pass->slice_h;
+const int *linesize = pass->output.linesize;
+
+size_t offset[4];
+size_t total_size = 0;
+for (int i = 0; i < 4; i++) {
+const size_t size = FFABS(linesize[i]) * aligned_h;
+offset[i] = total_size;
+total_size = FFALIGN(total_size + size, 16);
+}
+
+av_assert0(!pass->buf);
+pass->buf = av_malloc(total_size);
+if (!pass->buf)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < 4; i++) {
+uint8_t *base = pass->buf + offset[i];
+if (linesize[i] < 0)
+base -= linesize[i] *
[FFmpeg-devel] [PATCH v6 10/12] tests/swscale: rewrite on top of new API
From: Niklas Haas
This rewrite cleans up the code to use AVFrames and the new swscale API. The
log format has also been simplified and expanded to account for the new
options. (Not yet implemented)
The self testing code path has also been expanded to test the new swscale
implementation against the old one, to serve as an unchanging reference. This
does not accomplish much yet, but serves as a framework for future work.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/tests/swscale.c | 665 -
1 file changed, 284 insertions(+), 381 deletions(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index af8069f728..c11a46024e 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (C) 2024 Nikles Haas
* Copyright (C) 2003-2011 Michael Niedermayer
*
* This file is part of FFmpeg.
@@ -26,424 +27,307 @@
#undef HAVE_AV_CONFIG_H
#include "libavutil/cpu.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/mem.h"
-#include "libavutil/avutil.h"
-#include "libavutil/crc.h"
-#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/lfg.h"
#include "libavutil/sfc64.h"
+#include "libavutil/frame.h"
+#include "libavutil/pixfmt.h"
+#include "libavutil/avassert.h"
+#include "libavutil/macros.h"
#include "libswscale/swscale.h"
-/* HACK Duplicated from swscale_internal.h.
- * Should be removed when a cleaner pixel format system exists. */
-#define isGray(x) \
-((x) == AV_PIX_FMT_GRAY8 || \
- (x) == AV_PIX_FMT_YA8 || \
- (x) == AV_PIX_FMT_GRAY16BE|| \
- (x) == AV_PIX_FMT_GRAY16LE|| \
- (x) == AV_PIX_FMT_YA16BE || \
- (x) == AV_PIX_FMT_YA16LE)
-#define hasChroma(x) \
-(!(isGray(x)|| \
- (x) == AV_PIX_FMT_MONOBLACK || \
- (x) == AV_PIX_FMT_MONOWHITE))
-
-static av_always_inline int isALPHA(enum AVPixelFormat pix_fmt)
-{
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
-return desc->flags & AV_PIX_FMT_FLAG_ALPHA;
-}
+enum {
+WIDTH = 96,
+HEIGHT = 96,
+};
-static double prob = 1;
-FFSFC64 prng_state;
+struct options {
+enum AVPixelFormat src_fmt;
+enum AVPixelFormat dst_fmt;
+double prob;
+};
-static uint64_t getSSD(const uint8_t *src1, const uint8_t *src2,
- int stride1, int stride2, int w, int h)
-{
-int x, y;
-uint64_t ssd = 0;
+struct mode {
+SwsFlags flags;
+SwsDither dither;
+};
-for (y = 0; y < h; y++) {
-for (x = 0; x < w; x++) {
-int d = src1[x + y * stride1] - src2[x + y * stride2];
-ssd += d * d;
-}
-}
-return ssd;
-}
+const int dst_w[] = { WIDTH, WIDTH - WIDTH / 3, WIDTH + WIDTH / 3 };
+const int dst_h[] = { HEIGHT, HEIGHT - HEIGHT / 3, HEIGHT + HEIGHT / 3 };
+
+const struct mode modes[] = {
+{ SWS_FAST_BILINEAR },
+{ SWS_BILINEAR },
+{ SWS_BICUBIC },
+{ SWS_X | SWS_BITEXACT },
+{ SWS_POINT },
+{ SWS_AREA | SWS_ACCURATE_RND },
+{ SWS_BICUBIC | SWS_FULL_CHR_H_INT | SWS_FULL_CHR_H_INP },
+{0}, // test defaults
+};
-static uint64_t getSSD0(int ref, const uint8_t *src1, int stride1,
-int w, int h)
-{
-int x, y;
-uint64_t ssd = 0;
+static FFSFC64 prng_state;
+static SwsContext *sws[3]; /* reused between tests for efficiency */
-for (y = 0; y < h; y++) {
-for (x = 0; x < w; x++) {
-int d = src1[x + y * stride1] - ref;
-ssd += d * d;
-}
-}
-return ssd;
+static int fmt_comps(enum AVPixelFormat fmt)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+int comps = desc->nb_components >= 3 ? 0b111 : 0b1;
+if (desc->flags & AV_PIX_FMT_FLAG_ALPHA)
+comps |= 0b1000;
+return comps;
}
-struct Results {
-uint64_t ssdY;
-uint64_t ssdU;
-uint64_t ssdV;
-uint64_t ssdA;
-uint32_t crc;
-};
-
-// test by ref -> src -> dst -> out & compare out against ref
-// ref & out are YV12
-static int doTest(const uint8_t * const ref[4], int refStride[4], int w, int h,
- enum AVPixelFormat srcFormat, enum AVPixelFormat dstFormat,
- int srcW, int srcH, int dstW, int dstH, int flags,
- struct Results *r)
+static void get_mse(int mse[4], const AVFrame *a, const AVFrame *b, int comps)
{
-const AVPixFmtDescriptor *desc_yuva420p =
av_pix_fmt_desc_get(AV_PIX_FMT_YUVA420P);
-const AVPixFmtDescriptor *desc_src = av_pix_fmt_desc_get(srcFormat);
-const AVPixFmtDescriptor *desc_dst = av_pix_fmt_desc_get(dstFormat);
-static enum AVPixelFormat cur_srcFormat;
-static int cur_srcW, cur_srcH;
-static const uint8_t *src[4];
-static int srcStride[4];
-uint8_t *dst[4] = { 0 };
-uint8_t *out[4] = { 0 };
-int dstStride[4] = {0};
[FFmpeg-devel] [PATCH v6 09/12] swscale: introduce new, dynamic scaling API
From: Niklas Haas
As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the existing one.
Most of the API work has been already accomplished in the previous commits,
this commit merely introduces the ability to use sws_scale_frame()
dynamically, without prior sws_init_context() calls. Instead, the new API
takes frame properties from the frames themselves, and the implementation is
based on the new SwsGraph API, which we simply reinitialize as needed.
This high-level wrapper also recreates the logic that used to live inside
vf_scale for scaling interlaced frames, enabling it to be reused more easily
by end users.
Finally, this function is designed to simply copy refs directly when nothing
needs to be done, substantially improving throughput of the noop fast path.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.c | 196 --
libswscale/swscale.h | 89 +++
libswscale/swscale_internal.h | 7 +-
libswscale/utils.c| 4 +
libswscale/x86/output.asm | 2 +-
5 files changed, 269 insertions(+), 29 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 45172dcea4..d3dac44d04 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1219,21 +1219,205 @@ int sws_receive_slice(SwsContext *sws, unsigned int
slice_start,
dst, c->frame_dst->linesize, slice_start,
slice_height);
}
+static void get_frame_pointers(const AVFrame *frame, uint8_t *data[4],
+ int linesize[4], int field)
+{
+for (int i = 0; i < 4; i++) {
+data[i] = frame->data[i];
+linesize[i] = frame->linesize[i];
+}
+
+if (!(frame->flags & AV_FRAME_FLAG_INTERLACED)) {
+av_assert1(!field);
+return;
+}
+
+if (field == FIELD_BOTTOM) {
+/* Odd rows, offset by one line */
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+for (int i = 0; i < 4; i++) {
+data[i] += linesize[i];
+if (desc->flags & AV_PIX_FMT_FLAG_PAL)
+break;
+}
+}
+
+/* Take only every second line */
+for (int i = 0; i < 4; i++)
+linesize[i] <<= 1;
+}
+
+/* Subset of av_frame_ref() that only references (video) data buffers */
+static int frame_ref(AVFrame *dst, const AVFrame *src)
+{
+/* ref the buffers */
+for (int i = 0; i < FF_ARRAY_ELEMS(src->buf); i++) {
+if (!src->buf[i])
+continue;
+dst->buf[i] = av_buffer_ref(src->buf[i]);
+if (!dst->buf[i])
+return AVERROR(ENOMEM);
+}
+
+memcpy(dst->data, src->data, sizeof(src->data));
+memcpy(dst->linesize, src->linesize, sizeof(src->linesize));
+return 0;
+}
+
int sws_scale_frame(SwsContext *sws, AVFrame *dst, const AVFrame *src)
{
int ret;
+SwsInternal *c = sws_internal(sws);
+if (!src || !dst)
+return AVERROR(EINVAL);
+
+if (c->frame_src) {
+/* Context has been initialized with explicit values, fall back to
+ * legacy API */
+ret = sws_frame_start(sws, dst, src);
+if (ret < 0)
+return ret;
+
+ret = sws_send_slice(sws, 0, src->height);
+if (ret >= 0)
+ret = sws_receive_slice(sws, 0, dst->height);
-ret = sws_frame_start(sws, dst, src);
+sws_frame_end(sws);
+
+return ret;
+}
+
+ret = sws_frame_setup(sws, dst, src);
if (ret < 0)
return ret;
-ret = sws_send_slice(sws, 0, src->height);
-if (ret >= 0)
-ret = sws_receive_slice(sws, 0, dst->height);
+if (!src->data[0])
+return 0;
-sws_frame_end(sws);
+if (c->graph[FIELD_TOP]->noop &&
+(!c->graph[FIELD_BOTTOM] || c->graph[FIELD_BOTTOM]->noop) &&
+src->buf[0] && !dst->buf[0] && !dst->data[0])
+{
+/* Lightweight refcopy */
+ret = frame_ref(dst, src);
+if (ret < 0)
+return ret;
+} else {
+if (!dst->data[0]) {
+ret = av_frame_get_buffer(dst, 0);
+if (ret < 0)
+return ret;
+}
-return ret;
+for (int field = 0; field < 2; field++) {
+SwsGraph *graph = c->graph[field];
+uint8_t *dst_data[4], *src_data[4];
+int dst_linesize[4], src_linesize[4];
+get_frame_pointers(dst, dst_data, dst_linesize, field);
+get_frame_pointers(src, src_data, src_linesize, field);
+sws_graph_run(graph, dst_data, dst_linesize,
+ (const uint8_t **) src_data, src_linesize);
+if (!graph->dst.interlaced)
+break;
+}
+}
+
+return 0;
+}
+
+s
