[FFmpeg-devel] [PATCH] avcodec/ac3: Remove unused fixed-point ARMv7 DSP
This diff removes 4 unused ARMv7 NEON fixed-point DSP functions.
The function were originally moved here by 4958f35a2 (Dec 2013).
After 9e05421db (Jan 2021), as part of the refactor of the AC3
DSP to consistently use 32-bit sample format in the encoder, these
functions were removed from the DSP function table, but the ARMv7
implementations were kept.
Signed-off-by: Geoff Hill
---
libavcodec/arm/ac3dsp_neon.S | 63
1 file changed, 63 deletions(-)
diff --git a/libavcodec/arm/ac3dsp_neon.S b/libavcodec/arm/ac3dsp_neon.S
index 89d0ae8048..dc829541aa 100644
--- a/libavcodec/arm/ac3dsp_neon.S
+++ b/libavcodec/arm/ac3dsp_neon.S
@@ -20,25 +20,6 @@
#include "libavutil/arm/asm.S"
-function ff_ac3_max_msb_abs_int16_neon, export=1
-vmov.i16q0, #0
-vmov.i16q2, #0
-1: vld1.16 {q1}, [r0,:128]!
-vabs.s16q1, q1
-vld1.16 {q3}, [r0,:128]!
-vabs.s16q3, q3
-vorrq0, q0, q1
-vorrq2, q2, q3
-subsr1, r1, #16
-bgt 1b
-vorrq0, q0, q2
-vorrd0, d0, d1
-vpmax.u16 d0, d0, d0
-vpmax.u16 d0, d0, d0
-vmov.u16r0, d0[0]
-bx lr
-endfunc
-
function ff_ac3_exponent_min_neon, export=1
cmp r1, #0
it eq
@@ -59,27 +40,6 @@ function ff_ac3_exponent_min_neon, export=1
pop {pc}
endfunc
-function ff_ac3_lshift_int16_neon, export=1
-vdup.16 q0, r2
-1: vld1.16 {q1}, [r0,:128]
-vshl.s16q1, q1, q0
-vst1.16 {q1}, [r0,:128]!
-subsr1, r1, #8
-bgt 1b
-bx lr
-endfunc
-
-function ff_ac3_rshift_int32_neon, export=1
-rsb r2, r2, #0
-vdup.32 q0, r2
-1: vld1.32 {q1}, [r0,:128]
-vshl.s32q1, q1, q0
-vst1.32 {q1}, [r0,:128]!
-subsr1, r1, #4
-bgt 1b
-bx lr
-endfunc
-
function ff_float_to_fixed24_neon, export=1
1: vld1.32 {q0-q1}, [r1,:128]!
vcvt.s32.f32q0, q0, #24
@@ -109,29 +69,6 @@ function ff_ac3_extract_exponents_neon, export=1
bx lr
endfunc
-function ff_apply_window_int16_neon, export=1
-push{r4,lr}
-add r4, r1, r3, lsl #1
-add lr, r0, r3, lsl #1
-sub r4, r4, #16
-sub lr, lr, #16
-mov r12, #-16
-1:
-vld1.16 {q0}, [r1,:128]!
-vld1.16 {q2}, [r2,:128]!
-vld1.16 {q1}, [r4,:128], r12
-vrev64.16 q3, q2
-vqrdmulh.s16q0, q0, q2
-vqrdmulh.s16d2, d2, d7
-vqrdmulh.s16d3, d3, d6
-vst1.16 {q0}, [r0,:128]!
-vst1.16 {q1}, [lr,:128], r12
-subsr3, r3, #16
-bgt 1b
-
-pop {r4,pc}
-endfunc
-
function ff_ac3_sum_square_butterfly_int32_neon, export=1
vmov.i64q0, #0
vmov.i64q1, #0
--
2.44.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] 5 year plan & Inovation
The best option is to figure stuff out. I don't see positive stuff in this mailing list - I lurk a lot in these emails. I see what you mean. I somewhat disagree/agree. New codecs or new formats is innovative to a certain extent. There is no creativity or motivation here to improve the functionality of FFmpeg. Just arguing! Having a Native VVC decoder is great. Most of us will be using it after a few years once the codec becomes used. I use FFmpeg to download HLS streams from the internet or convert files like probably most people do. FFmpeg is the ultimate way of doing this because there is no better option. But there are issues: 1. "#ext-x-discontinuity" exists. Makes FFmpeg completely unable to function with HLS depending on the circumstance. 2. TTML is used a lot on the internet as subtitles. FFmpeg doesn't have a decoder at all. TTML is rarely supported other than browsers. There is no way to convert and preserve formatting. 3. There is no encoder for cea-608 subtitles. Tons of services support decoding but there's no way to encode it. 4. Services selling HLS encoder services. FFmpeg can generate an HLS playlist. However, it's an important part: the web server. I submitted a patch for a TTML decoder because I thought it would be great. It was completely ignored. If my patch was seriously bad, then fine. But seriously *no one cared*. Y'all can disagree with me. You are slowly digging a pit. Kind regards, Aidan / TheDaChicken ___ 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] 5 year plan & Inovation
On Thu, Apr 18, 2024 at 02:22:33AM +0200, Michael Niedermayer wrote: > On Wed, Apr 17, 2024 at 08:31:42PM +0200, Timo Rothenpieler wrote: > > On 17.04.2024 20:22, Michael Niedermayer wrote: > > > On Wed, Apr 17, 2024 at 05:55:04PM +0200, Jean-Baptiste Kempf wrote: > > > > Hello, > > > > > > > > On Wed, 17 Apr 2024, at 17:22, Michael Niedermayer wrote: > > > > > > > * ffchat > > > > > > > (expand into realtime chat / zoom) this would > > > > > > > bring in more users and developers, and we basically have almost > > > > > > > > > > > > > > > > > > > Better leave that for others. > > > > > > There's an infinite amount of discord clones already. > > > > > > > > > > iam not following that genre that much ... > > > > > so let me ask > > > > > are there any that > > > > > * preserve privacy (discord is not secure/private) > > > > > * allow audio / video / text chat > > > > > * scalable > > > > > * need no central server > > > > > > > > Matrix? Elements? Mattermost? Rocket.chat? Jitsi? > > > > > > These seem quite complex systems > > > > > > Matrix says "(optional) end-to-end encryption" which for me is a fail > > > > > > https://jitsi.org/security/ > > > nicely explains their security. And i agree that anything running > > > primarely in a browser controlled by google cannot provide > > > security/privacy > > > > > > what i had in mind with ffchat initially was a much simpler system > > > simply something where 2+ people could connect and communicate with > > > video and audio (text being easy to add). > > > > > > The complexity of ffchat would be more between /doc/examples and > > > ffplay. > > > My basic idea was that people would be identified by their public key > > > hash + DNS name. And then just setup a connection in a ffplay like > > > interface. > > > > That sounds a bit like re-inventing Tox. > > indeed, i didnt know tox. So this would leave this just being a code > example or a much more massive project both seem not that usefull or > realistic ATM. the only problem is > > > > Which sadly seems a bit dead. > > yes, tox seems dead actually, it seems not dead, just their ML is dead, their IRC is pointing to tox group one cant join with the current tox clients in ubuntu (or i dont know how) then several git repositories are dead but https://github.com/TokTok/c-toxcore seems alive, it has a release 3 weeks ago I dont know how all these relate but things link a bit in circles thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban 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] [RFC] 5 year plan & Inovation
On Wed, Apr 17, 2024 at 08:31:42PM +0200, Timo Rothenpieler wrote: > On 17.04.2024 20:22, Michael Niedermayer wrote: > > On Wed, Apr 17, 2024 at 05:55:04PM +0200, Jean-Baptiste Kempf wrote: > > > Hello, > > > > > > On Wed, 17 Apr 2024, at 17:22, Michael Niedermayer wrote: > > > > > > * ffchat > > > > > > (expand into realtime chat / zoom) this would > > > > > > bring in more users and developers, and we basically have almost > > > > > > > > > > > > > > > > Better leave that for others. > > > > > There's an infinite amount of discord clones already. > > > > > > > > iam not following that genre that much ... > > > > so let me ask > > > > are there any that > > > > * preserve privacy (discord is not secure/private) > > > > * allow audio / video / text chat > > > > * scalable > > > > * need no central server > > > > > > Matrix? Elements? Mattermost? Rocket.chat? Jitsi? > > > > These seem quite complex systems > > > > Matrix says "(optional) end-to-end encryption" which for me is a fail > > > > https://jitsi.org/security/ > > nicely explains their security. And i agree that anything running > > primarely in a browser controlled by google cannot provide security/privacy > > > > what i had in mind with ffchat initially was a much simpler system > > simply something where 2+ people could connect and communicate with > > video and audio (text being easy to add). > > > > The complexity of ffchat would be more between /doc/examples and > > ffplay. > > My basic idea was that people would be identified by their public key > > hash + DNS name. And then just setup a connection in a ffplay like > > interface. > > That sounds a bit like re-inventing Tox. indeed, i didnt know tox. So this would leave this just being a code example or a much more massive project both seem not that usefull or realistic ATM. the only problem is > Which sadly seems a bit dead. yes, tox seems dead thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 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 v12 0/8] [WIP] webp: add support for animated WebP decoding
On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel wrote: > > From: Thilo Borgmann > > Marked WIP because we'd want to introduce private bsf's first; review > welcome before that though > VP8 decoder decoupled again > The whole animated sequence goes into one packet > The (currently public) bitstream filter splits animations up into > non-conformant packets > Now with XMP metadata support (as string, like MOV) > Tests mostly work for me. There are a few images (that I reported earlier) that give: Canvas change detected. The output will be damaged. Use -threads 1 to try decoding with best effort. They don't animate without that option and with it render incorrectly. A few other notes: - should ffprobe report anything with files containing xmp? - 0 duration behaves differently than web browsers, which use the gif behavior and set it to 10; as long as it's consistent in ffmpeg between the two either is fine to me. - The files in https://crbug.com/690848 don't exit cleanly from ffplay, other corrupt files do; ffmpeg exits, so maybe it's a non-issue. > > Patch 5/8 is still there for making changes in lavc/webp reviewable but shall > be stashed when pushing. > > -Thilo > > Josef Zlomek (2): > libavcodec/webp: add support for animated WebP > libavformat/webp: add WebP demuxer > > Thilo Borgmann via ffmpeg-devel (6): > avcodec/webp: remove unused definitions > avcodec/webp: separate VP8 decoding > avcodec/bsf: Add awebp2webp bitstream filter > avcodec/webp: make init_canvas_frame static > fate: add test for animated WebP > avcodec/webp: export XMP metadata > > Changelog | 2 + > configure | 1 + > doc/demuxers.texi | 28 + > libavcodec/bitstream_filters.c| 1 + > libavcodec/bsf/Makefile | 1 + > libavcodec/bsf/awebp2webp.c | 350 > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h | 2 +- > libavcodec/webp.c | 796 -- > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/version.h | 2 +- > libavformat/webpdec.c | 383 + > tests/fate/image.mak | 3 + > tests/ref/fate/exif-image-webp| 4 +- > tests/ref/fate/webp-anim | 22 + > tests/ref/fate/webp-rgb-lena-lossless | 2 +- > tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > tests/ref/fate/webp-rgb-lossless | 2 +- > .../fate/webp-rgb-lossless-palette-predictor | 2 +- > tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > tests/ref/fate/webp-rgba-lossless | 2 +- > tests/ref/fate/webp-rgba-lossy-q80| 2 +- > 23 files changed, 1530 insertions(+), 84 deletions(-) > create mode 100644 libavcodec/bsf/awebp2webp.c > create mode 100644 libavformat/webpdec.c > create mode 100644 tests/ref/fate/webp-anim > > -- > 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". ___ 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 table at NAB
Hi, > Am 16.04.2024 um 16:21 schrieb Devin Heitmueller > : > > Hello all, > > I wasn't looking to start trouble, but I didn't see any discussion of > this on the mailing list so wanted to bring it to the developer > community's attention. > > I attended the NAB conference and went by the "ffmpeg" booth on > Sunday. What I found was a single table with the official ffmpeg > banner hanging right next to a banner for the GPAC project, and two > salespeople from GPAC handing out marketing literature and trying to > educate me on why I should use their framework for my next project. > > I'm not saying that GPAC shouldn't be able to have a table at the > conference, but it feels pretty misleading to have an "ffmpeg" booth > listed in the conference materials, with a table prominently > displaying the ffmpeg logo, with zero people from ffmpeg and people > pushing users to use an alternative framework that some might actually > considered to be a competitor to ffmpeg. so I talked to the GPAC folks and Devin as well. The missing part of the information exchanged was apparently that there‘s nobody from FFmpeg here _at the moment_. Devin did circle around a bit for a while, never saw FFpeople in that time. Thing is that in the afternoons, Ramiro and me were out for lunch off-site, for around 90 minutes - plenty of time never to be seen by Devin. Additionally, not having followed the November announcement and subsequent posts too closely, lead to even more suspicion. So, Devin, as I told you earlier, thank you very much for your mail - in case that would have actually been some sort of misuse of our name, we’d totally want to become aware of. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 0/2] lavc/aarch64/fdct: add neon-optimized fdct for aarch64
On Wed, 17 Apr 2024, Ramiro Polla wrote: This patch set adds fdct to checkasm and neon-optimized fdct for aarch64. Ramiro Polla (2): checkasm: add test for fdct lavc/aarch64/fdct: add neon-optimized fdct for aarch64 libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/fdct.h | 26 ++ libavcodec/aarch64/fdctdsp_init_aarch64.c | 39 +++ libavcodec/aarch64/fdctdsp_neon.S | 368 ++ libavcodec/avcodec.h | 1 + libavcodec/fdctdsp.c | 4 +- libavcodec/fdctdsp.h | 2 + libavcodec/options_table.h| 1 + libavcodec/tests/aarch64/dct.c| 2 + tests/checkasm/Makefile | 1 + tests/checkasm/checkasm.c | 3 + tests/checkasm/checkasm.h | 1 + tests/checkasm/fdctdsp.c | 68 tests/fate/checkasm.mak | 1 + 14 files changed, 518 insertions(+), 1 deletion(-) create mode 100644 libavcodec/aarch64/fdct.h create mode 100644 libavcodec/aarch64/fdctdsp_init_aarch64.c create mode 100644 libavcodec/aarch64/fdctdsp_neon.S create mode 100644 tests/checkasm/fdctdsp.c LGTM, thanks! // 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] [PATCH v4 0/1] avfilter/vf_colorspace: use colorspace negotiation API
On Thu, 04 Apr 2024 19:05:13 +0200 Nicolas Gaullier wrote: > v4: > - remove dynamic color_range pass-through (which requires changing outlink > dynamically and is forbidden) > - nits style > - commit msg: simplified example (+ removed example for dynamic color_range > pass-through) > > Nicolas Gaullier (1): > avfilter/vf_colorspace: use colorspace negotiation API > > libavfilter/vf_colorspace.c | 62 + > 1 file changed, 36 insertions(+), 26 deletions(-) > > -- > 2.30.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Pushed as 376b3d53c54791c1be58709df4303ba2b90851bc Sorry for the delay; it is really not clear to me who has push rights and who does not, and whose job it is to merge patches. ___ 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] Mailinglist conduct
On 4/17/2024 4:43 PM, Derek Buitenhuis wrote: On 4/17/2024 8:33 PM, James Almer wrote: This was an unnecessary personal attack, please don't do that again. Repeat offense may result in temporary bans on the mailinglist and/or IRC. Please keep it civil. That does not make it untrue, however. It's ok to have opinions. But there are better way to express them. It is not an opinion if it is true. I would have preferred a ban. Let's drop it here, please. I will say what I said earlier in private. [16:15] i am tired of the whole thing where the person pointing out the insanity is punished because they were mean [16:15] and the people doing long term damage keep on scott free [16:17] focusing on Mean Words [16:17] instead of deeper issues What i saw were questions that went unanswered a few months ago, and now you being angry with said person that you say gets scott free. Can you please explain the overall situation, from your PoV? I swear a lot of stuff just happens behind curtains and i and others only notice it when it explodes. I agree I was out of line, but for the above reason (among others), the CC is a lame duck, One email saying one thing out of the line is no reason for a ban. Why would you want to force anyone to do that? Seriously, there's a lot of missing context here, and my work as part of the CC gets complex. Half the stuff i know about this i learned on IRC only a few hours ago, which apparently was common knowledge for some and news for others. lacking the ability to enact actual meaningful change. The modus operandi here is to drive anyone sane into eventually getting angry and saying regretful things. Gaslighting, sort of. More like [1]. Coupled with the complacent attitude of Please Just Stop So I Can Code from a chunk of the rest of the community, I find myself screaming into the void. I am tired of screaming into the void. This is what i mean when i say things only become apparent when they explode. I have taken this opportunity to unsubscribe for a while, as a self imposed temp ban for my own benefit. I did that last time I felt like [1] here, and it was beneficial. - Derek [1] https://www.youtube.com/watch?v=HOK6mE7sdvs ___ 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] Mailinglist conduct
On 4/17/2024 8:33 PM, James Almer wrote: >>> This was an unnecessary personal attack, please don't do that again. Repeat >>> offense may result in temporary bans on the mailinglist and/or IRC. Please >>> keep it civil. >> >> That does not make it untrue, however. > > It's ok to have opinions. But there are better way to express them. It is not an opinion if it is true. >> I would have preferred a ban. > > Let's drop it here, please. I will say what I said earlier in private. [16:15] i am tired of the whole thing where the person pointing out the insanity is punished because they were mean [16:15] and the people doing long term damage keep on scott free [16:17] focusing on Mean Words [16:17] instead of deeper issues I agree I was out of line, but for the above reason (among others), the CC is a lame duck, lacking the ability to enact actual meaningful change. The modus operandi here is to drive anyone sane into eventually getting angry and saying regretful things. Gaslighting, sort of. More like [1]. Coupled with the complacent attitude of Please Just Stop So I Can Code from a chunk of the rest of the community, I find myself screaming into the void. I am tired of screaming into the void. I have taken this opportunity to unsubscribe for a while, as a self imposed temp ban for my own benefit. I did that last time I felt like [1] here, and it was beneficial. - Derek [1] https://www.youtube.com/watch?v=HOK6mE7sdvs ___ 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 v12 3/8] avcodec/bsf: Add awebp2webp bitstream filter
On 17.04.24 21:19, Thilo Borgmann via ffmpeg-devel wrote: From: Thilo Borgmann via ffmpeg-devel Splits a packet containing a webp animations into one non-compliant packet per frame of the animation. Skips RIFF and WEBP chunks for those packets except for the first. Copyies ICC, EXIF and XMP chunks first into each of the packets except for the first. --- configure | 1 + libavcodec/bitstream_filters.c | 1 + libavcodec/bsf/Makefile| 1 + libavcodec/bsf/awebp2webp.c| 350 + 4 files changed, 353 insertions(+) create mode 100644 libavcodec/bsf/awebp2webp.c build failed here. Updated patch attached. Sorry, ThiloFrom 536dfc772ac273b0d3607545b8aea7a26ba84ac1 Mon Sep 17 00:00:00 2001 From: Thilo Borgmann via ffmpeg-devel Date: Thu, 28 Mar 2024 15:08:53 +0100 Subject: [PATCH v12 3/8] avcodec/bsf: Add awebp2webp bitstream filter Splits a packet containing a webp animations into one non-compliant packet per frame of the animation. Skips RIFF and WEBP chunks for those packets except for the first. Copyies ICC, EXIF and XMP chunks first into each of the packets except for the first. --- configure | 1 + libavcodec/bitstream_filters.c | 1 + libavcodec/bsf/Makefile| 1 + libavcodec/bsf/awebp2webp.c| 351 + 4 files changed, 354 insertions(+) create mode 100644 libavcodec/bsf/awebp2webp.c diff --git a/configure b/configure index 55f1fc354d..2d08bc1fd8 100755 --- a/configure +++ b/configure @@ -3425,6 +3425,7 @@ aac_adtstoasc_bsf_select="adts_header mpeg4audio" av1_frame_merge_bsf_select="cbs_av1" av1_frame_split_bsf_select="cbs_av1" av1_metadata_bsf_select="cbs_av1" +awebp2webp_bsf_select="" dts2pts_bsf_select="cbs_h264 h264parse" eac3_core_bsf_select="ac3_parser" evc_frame_merge_bsf_select="evcparse" diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c index 12860c332b..af88283a8c 100644 --- a/libavcodec/bitstream_filters.c +++ b/libavcodec/bitstream_filters.c @@ -28,6 +28,7 @@ extern const FFBitStreamFilter ff_aac_adtstoasc_bsf; extern const FFBitStreamFilter ff_av1_frame_merge_bsf; extern const FFBitStreamFilter ff_av1_frame_split_bsf; extern const FFBitStreamFilter ff_av1_metadata_bsf; +extern const FFBitStreamFilter ff_awebp2webp_bsf; extern const FFBitStreamFilter ff_chomp_bsf; extern const FFBitStreamFilter ff_dump_extradata_bsf; extern const FFBitStreamFilter ff_dca_core_bsf; diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile index fb70ad0c21..48c67dd210 100644 --- a/libavcodec/bsf/Makefile +++ b/libavcodec/bsf/Makefile @@ -5,6 +5,7 @@ OBJS-$(CONFIG_AAC_ADTSTOASC_BSF) += bsf/aac_adtstoasc.o OBJS-$(CONFIG_AV1_FRAME_MERGE_BSF)+= bsf/av1_frame_merge.o OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= bsf/av1_frame_split.o OBJS-$(CONFIG_AV1_METADATA_BSF) += bsf/av1_metadata.o +OBJS-$(CONFIG_AWEBP2WEBP_BSF) += bsf/awebp2webp.o OBJS-$(CONFIG_CHOMP_BSF) += bsf/chomp.o OBJS-$(CONFIG_DCA_CORE_BSF) += bsf/dca_core.o OBJS-$(CONFIG_DTS2PTS_BSF)+= bsf/dts2pts.o diff --git a/libavcodec/bsf/awebp2webp.c b/libavcodec/bsf/awebp2webp.c new file mode 100644 index 00..7edacee48f --- /dev/null +++ b/libavcodec/bsf/awebp2webp.c @@ -0,0 +1,351 @@ +/* + * Animated WebP into non-compliant WebP bitstream filter + * Copyright (c) 2024 Thilo Borgmann + * + * 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 + */ + +/** + * @file + * Animated WebP into non-compliant WebP bitstream filter + * Splits a packet containing a webp animations into + * one non-compliant packet per frame of the animation. + * Skips RIFF and WEBP chunks for those packets except + * for the first. Copyies ICC, EXIF and XMP chunks first + * into each of the packets except for the first. + * @author Thilo Borgmann + */ + +#include +#include + +#include "codec_id.h" +#include "bytestream.h" +#include "libavutil/error.h" +#include "libavutil/mem.h" + +#include "bsf.h" +#include "bsf_internal.h" +#include "packet.h" + +#define VP8X_FLAG_ANIMATION 0x02 +#define VP8X_FLAG_XMP_METADATA 0x04 +#define VP8X_FLAG_EXIF_METADATA 0x08 +#define
Re: [FFmpeg-devel] Mailinglist conduct
On 4/17/2024 4:30 PM, Derek Buitenhuis wrote: On 4/17/2024 8:00 PM, Ronald S. Bultje wrote: This was an unnecessary personal attack, please don't do that again. Repeat offense may result in temporary bans on the mailinglist and/or IRC. Please keep it civil. That does not make it untrue, however. It's ok to have opinions. But there are better way to express them. I would have preferred a ban. Let's drop it here, please. ___ 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] Mailinglist conduct
On 4/17/2024 8:00 PM, Ronald S. Bultje wrote: > This was an unnecessary personal attack, please don't do that again. Repeat > offense may result in temporary bans on the mailinglist and/or IRC. Please > keep it civil. That does not make it untrue, however. I would have preferred a ban. - 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] [PATCH v11 4/8] libavcodec/webp: add support for animated WebP
On 17.04.24 19:30, James Zern via ffmpeg-devel wrote: On Thu, Mar 28, 2024 at 7:10 AM Thilo Borgmann via ffmpeg-devel wrote: From: Josef Zlomek Fixes: 4907 Adds support for decoding of animated WebP. The WebP decoder adds the animation related features according to the specs: https://developers.google.com/speed/webp/docs/riff_container#animation The frames of the animation may be smaller than the image canvas. Therefore, the frame is decoded to a temporary frame, then it is blended into the canvas, the canvas is copied to the output frame, and finally the frame is disposed from the canvas. The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported. The background color is specified only as BGRA in the WebP file so it is converted to YUVA if YUV formats are output. Signed-off-by: Josef Zlomek --- Changelog | 1 + libavcodec/codec_desc.c | 3 +- libavcodec/version.h| 2 +- libavcodec/webp.c | 710 4 files changed, 653 insertions(+), 63 deletions(-) I'm late trying to test these. I think these need to be rebased. version.h is easy enough to skip. I didn't look at the conflict in webp.c. error: patch failed: libavcodec/version.h:30 error: libavcodec/version.h: patch does not apply error: patch failed: libavcodec/webp.c:35 error: libavcodec/webp.c: patch does not apply Patch failed at 0004 libavcodec/webp: add support for animated WebP just posted v12 which applies to master again, also tagged it WIP. Thanks for having a look, Thilo ___ 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] Query from Reuters on XZ, open source, and Microsoft
On 11 Apr 2024, at 5:59, Vittorio Giovara wrote: > On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer > wrote: > >> […] >> >> To bring some of the new blood into the project the project needs to >> first understand why they dont. And asking thouse who manage with >> difficulty >> to join could be a biased oppinion. >> > > In my experience this boils down to three points > 1. there is a legit barrier of entry in a large codebase such as ffmpeg, > but over time newcomers can learn about it > 2. the review process can be though and it's easy to miss a ping and > patches get lost, very defeating for a new developer This has honestly been one of the most discouraging things when contributing here. The ML workflow just contributes to make this even worse for me, as it makes it really hard to keep track of things. (Of course everyone is different and I get why some people like the ML-patches workflow, but having experienced both at VLC, I can say for myself I vastly prefer Gitlab-like solutions) > 3. there is net negative help from trolls who spread toxic poison, which is > confusing and uninteresting for the new blood > > 2 out of 3 can be solved technically, while the last one needs a cultural > shift - overall I think we're doing a good job at slowly changing pace and > having a bit of a better structure to solve situations when they arise, but > there is still a lot of work to do Another factor is IMO the general tone here on the ML, let’s just say it is not the most welcoming environment. It doesn’t help that sometimes technical discussion and „politics“ are mixed together so you have no way to escape it when you don’t feel like being dragged down by the state of this community some days… > -- > Vittorio > ___ > 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".
[FFmpeg-devel] [PATCH v12 8/8] avcodec/webp: export XMP metadata
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 42 --
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 4a244c1b67..35851ef3da 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -38,8 +38,8 @@
* @author Josef Zlomek, Pexeso Inc.
* Animation
*
- * Unimplemented:
- * - XMP metadata
+ * @author Thilo Borgmann
+ * XMP metadata
*/
#include "libavutil/imgutils.h"
@@ -217,6 +217,7 @@ typedef struct WebPContext {
int alpha_data_size;/* alpha chunk data size */
int has_exif; /* set after an EXIF chunk has been
processed */
int has_iccp; /* set after an ICCP chunk has been
processed */
+int has_xmp;/* set after an XMP chunk has been
processed */
int width; /* image width */
int height; /* image height */
int vp8x_flags; /* global flags from VP8X chunk */
@@ -1464,6 +1465,7 @@ static int webp_decode_frame_common(AVCodecContext
*avctx, uint8_t *data, int si
// reset metadata bit for each packet
s->has_exif = 0;
s->has_iccp = 0;
+s->has_xmp = 0;
while (bytestream2_get_bytes_left() > 8) {
char chunk_str[5] = { 0 };
@@ -1495,6 +1497,7 @@ static int webp_decode_frame_common(AVCodecContext
*avctx, uint8_t *data, int si
s->canvas_height = 0;
s->has_exif = 0;
s->has_iccp = 0;
+s->has_xmp = 0;
ff_thread_release_ext_buffer(>canvas_frame);
break;
case MKTAG('V', 'P', '8', ' '):
@@ -1680,12 +1683,39 @@ exif_end:
}
s->vp8x_flags |= VP8X_FLAG_ANIMATION;
break;
-case MKTAG('X', 'M', 'P', ' '):
-AV_WL32(chunk_str, chunk_type);
-av_log(avctx, AV_LOG_WARNING, "skipping unsupported chunk: %s\n",
- chunk_str);
+case MKTAG('X', 'M', 'P', ' '): {
+GetByteContext xmp_gb;
+AVDictionary **xmp_metadata = NULL;
+uint8_t *buffer;
+int xmp_offset = bytestream2_tell();
+
+if (s->has_xmp) {
+av_log(avctx, AV_LOG_VERBOSE, "Ignoring extra XMP chunk\n");
+goto xmp_end;
+}
+if (!(s->vp8x_flags & VP8X_FLAG_XMP_METADATA))
+av_log(avctx, AV_LOG_WARNING,
+ "XMP chunk present, but XMP bit not set in the "
+ "VP8X header\n");
+
+// there are at least chunk_size bytes left to read
+buffer = av_malloc(chunk_size + 1);
+if (!buffer) {
+return AVERROR(ENOMEM);
+}
+
+s->has_xmp = 1;
+bytestream2_init(_gb, data + xmp_offset, size - xmp_offset);
+bytestream2_get_buffer(_gb, buffer, chunk_size);
+buffer[chunk_size] = '\0';
+
+xmp_metadata = (s->vp8x_flags & VP8X_FLAG_ANIMATION) ?
>metadata : >frame->metadata;
+av_dict_set(xmp_metadata, "xmp", buffer, AV_DICT_DONT_STRDUP_VAL);
+
+xmp_end:
bytestream2_skip(, chunk_size);
break;
+}
default:
AV_WL32(chunk_str, chunk_type);
av_log(avctx, AV_LOG_VERBOSE, "skipping unknown chunk: %s\n",
--
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".
[FFmpeg-devel] [PATCH v12 7/8] fate: add test for animated WebP
From: Thilo Borgmann via ffmpeg-devel --- tests/fate/image.mak | 3 +++ tests/ref/fate/webp-anim | 22 ++ 2 files changed, 25 insertions(+) create mode 100644 tests/ref/fate/webp-anim diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 753936ec20..b6a4cd2ba3 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -566,6 +566,9 @@ fate-webp-rgb-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_q80.webp FATE_WEBP += fate-webp-rgba-lossy-q80 fate-webp-rgba-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgba_q80.webp +FATE_WEBP += fate-webp-anim +fate-webp-anim: CMD = framecrc -i $(TARGET_SAMPLES)/webp/130227-100431-6817p.webp + FATE_WEBP-$(call DEMDEC, IMAGE2, WEBP) += $(FATE_WEBP) FATE_IMAGE_FRAMECRC += $(FATE_WEBP-yes) fate-webp: $(FATE_WEBP-yes) diff --git a/tests/ref/fate/webp-anim b/tests/ref/fate/webp-anim new file mode 100644 index 00..f0d3f1a88f --- /dev/null +++ b/tests/ref/fate/webp-anim @@ -0,0 +1,22 @@ +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 100x70 +#sar 0: 0/1 +0, 0, 0, 80,28000, 0x2023ba6e +0, 80, 80, 80,28000, 0x4292b778 +0,160,160, 80,28000, 0x1c972ef1 +0,240,240, 80,28000, 0xa98d8d04 +0,320,320, 80,28000, 0xd323b6af +0,400,400, 80,28000, 0x508aba99 +0,480,480, 80,28000, 0x5c672dda +0,560,560, 80,28000, 0xc8961ebb +0,640,640, 1000,28000, 0x82460e1b +0, 1640, 1640, 80,28000, 0x3debbfc9 +0, 1720, 1720, 80,28000, 0x427ab31f +0, 1800, 1800, 80,28000, 0x6bbdec2e +0, 1880, 1880, 80,28000, 0x5690b56b +0, 1960, 1960, 80,28000, 0xb62963f3 +0, 2040, 2040, 80,28000, 0x68dd37b2 +0, 2120, 2120, 80,28000, 0x465c47d2 +0, 2200, 2200,1,28000, 0xa92033df -- 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".
[FFmpeg-devel] [PATCH v12 6/8] libavformat/webp: add WebP demuxer
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.
The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
doc/demuxers.texi | 28 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/version.h | 2 +-
libavformat/webpdec.c | 383 ++
tests/ref/fate/exif-image-webp| 4 +-
tests/ref/fate/webp-rgb-lena-lossless | 2 +-
tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
tests/ref/fate/webp-rgb-lossless | 2 +-
.../fate/webp-rgb-lossless-palette-predictor | 2 +-
tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
tests/ref/fate/webp-rgba-lossless | 2 +-
tests/ref/fate/webp-rgba-lossy-q80| 2 +-
14 files changed, 424 insertions(+), 10 deletions(-)
create mode 100644 libavformat/webpdec.c
diff --git a/Changelog b/Changelog
index 03ac047cea..698182aca3 100644
--- a/Changelog
+++ b/Changelog
@@ -94,6 +94,7 @@ version 6.1:
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
- animated WebP decoder
+- animated WebP demuxer
version 6.0:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 04293c4813..9c9d0fee17 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -1158,4 +1158,32 @@ this is set to 0, which means that a sensible value is
chosen based on the
input format.
@end table
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
@c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8efe26b6df..6e7969846b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -628,6 +628,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
av1.o avlanguage.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 305fa46532..23f6ef7f7d 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -511,6 +511,7 @@ extern const FFInputFormat ff_webm_dash_manifest_demuxer;
extern const FFOutputFormat ff_webm_dash_manifest_muxer;
extern const FFOutputFormat ff_webm_chunk_muxer;
extern const FFOutputFormat ff_webp_muxer;
+extern const FFInputFormat ff_webp_demuxer;
extern const FFInputFormat ff_webvtt_demuxer;
extern const FFOutputFormat ff_webvtt_muxer;
extern const FFInputFormat ff_wsaud_demuxer;
diff --git a/libavformat/version.h b/libavformat/version.h
index 7ff1483912..ee91990360 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VERSION_MINOR 3
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index
[FFmpeg-devel] [PATCH v12 5/8] avcodec/webp: make init_canvas_frame static
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 142 +++---
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index f882c3e187..4a244c1b67 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1380,7 +1380,76 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return ret;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas->data[0] &&
+canvas->format == format &&
+canvas->width == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will lose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas->data[0]) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_thread_report_progress(>canvas_frame, INT_MAX, 0);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+canvas->format= format;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_thread_release_ext_buffer(>canvas_frame);
+ret = ff_thread_get_ext_buffer(s->avctx, >canvas_frame,
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+ height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int
size,
int *got_frame, int key_frame, AVFrame *p)
@@ -1629,77 +1698,6 @@ exif_end:
return size;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas->data[0] &&
-canvas->format == format &&
-canvas->width == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will loose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas->data[0]) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_thread_report_progress(>canvas_frame, INT_MAX, 0);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
-}
-}
-
-s->avctx->pix_fmt = format;
-canvas->format= format;
-canvas->width = s->canvas_width;
-canvas->height= s->canvas_height;
-
-// VP8 decoder changed the width and height
[FFmpeg-devel] [PATCH v12 4/8] libavcodec/webp: add support for animated WebP
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.
The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
libavcodec/codec_desc.c | 3 +-
libavcodec/version.h| 2 +-
libavcodec/webp.c | 710
4 files changed, 653 insertions(+), 63 deletions(-)
diff --git a/Changelog b/Changelog
index 5c8f505211..03ac047cea 100644
--- a/Changelog
+++ b/Changelog
@@ -93,6 +93,7 @@ version 6.1:
- ffprobe XML output schema changed to account for multiple
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
+- animated WebP decoder
version 6.0:
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 7dba61dc8b..2873f91479 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.type = AVMEDIA_TYPE_VIDEO,
.name = "webp",
.long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
.mime_types= MT("image/webp"),
},
{
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f0958eee14..3d2de546b3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 5
-#define LIBAVCODEC_VERSION_MICRO 103
+#define LIBAVCODEC_VERSION_MICRO 104
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 3075321e86..f882c3e187 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,13 +35,16 @@
* Exif metadata
* ICC profile
*
+ * @author Josef Zlomek, Pexeso Inc.
+ * Animation
+ *
* Unimplemented:
- * - Animation
* - XMP metadata
*/
#include "libavutil/imgutils.h"
#include "libavutil/mem.h"
+#include "libavutil/colorspace.h"
#define BITSTREAM_READER_LE
#include "avcodec.h"
@@ -68,6 +71,14 @@
#define NUM_SHORT_DISTANCES 120
#define MAX_HUFFMAN_CODE_LENGTH 15
+#define ANMF_DISPOSAL_METHOD0x01
+#define ANMF_DISPOSAL_METHOD_UNCHANGED 0x00
+#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01
+
+#define ANMF_BLENDING_METHOD0x02
+#define ANMF_BLENDING_METHOD_ALPHA 0x00
+#define ANMF_BLENDING_METHOD_OVERWRITE 0x02
+
static const uint16_t alphabet_sizes[HUFFMAN_CODES_PER_META_CODE] = {
NUM_LITERAL_CODES + NUM_LENGTH_CODES,
NUM_LITERAL_CODES, NUM_LITERAL_CODES, NUM_LITERAL_CODES,
@@ -192,6 +203,8 @@ typedef struct ImageContext {
typedef struct WebPContext {
VP8Context v; /* VP8 Context used for lossy decoding
*/
GetBitContext gb; /* bitstream reader for main image
chunk */
+ThreadFrame canvas_frame; /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
@@ -206,7 +219,22 @@ typedef struct WebPContext {
int has_iccp; /* set after an ICCP chunk has been
processed */
int width; /* image width */
int height; /* image height */
-int lossless; /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width; /* canvas width */
+int canvas_height; /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int pos_x; /* frame position X */
+int pos_y; /* frame position Y */
+int prev_anmf_flags;/* previous frame flags from ANMF
chunk */
+int prev_width; /* previous frame width */
+int prev_height;/* previous frame height */
+int
[FFmpeg-devel] [PATCH v12 3/8] avcodec/bsf: Add awebp2webp bitstream filter
From: Thilo Borgmann via ffmpeg-devel
Splits a packet containing a webp animations into
one non-compliant packet per frame of the animation.
Skips RIFF and WEBP chunks for those packets except
for the first. Copyies ICC, EXIF and XMP chunks first
into each of the packets except for the first.
---
configure | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile| 1 +
libavcodec/bsf/awebp2webp.c| 350 +
4 files changed, 353 insertions(+)
create mode 100644 libavcodec/bsf/awebp2webp.c
diff --git a/configure b/configure
index 55f1fc354d..2d08bc1fd8 100755
--- a/configure
+++ b/configure
@@ -3425,6 +3425,7 @@ aac_adtstoasc_bsf_select="adts_header mpeg4audio"
av1_frame_merge_bsf_select="cbs_av1"
av1_frame_split_bsf_select="cbs_av1"
av1_metadata_bsf_select="cbs_av1"
+awebp2webp_bsf_select=""
dts2pts_bsf_select="cbs_h264 h264parse"
eac3_core_bsf_select="ac3_parser"
evc_frame_merge_bsf_select="evcparse"
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 12860c332b..af88283a8c 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -28,6 +28,7 @@ extern const FFBitStreamFilter ff_aac_adtstoasc_bsf;
extern const FFBitStreamFilter ff_av1_frame_merge_bsf;
extern const FFBitStreamFilter ff_av1_frame_split_bsf;
extern const FFBitStreamFilter ff_av1_metadata_bsf;
+extern const FFBitStreamFilter ff_awebp2webp_bsf;
extern const FFBitStreamFilter ff_chomp_bsf;
extern const FFBitStreamFilter ff_dump_extradata_bsf;
extern const FFBitStreamFilter ff_dca_core_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index fb70ad0c21..48c67dd210 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -5,6 +5,7 @@ OBJS-$(CONFIG_AAC_ADTSTOASC_BSF) += bsf/aac_adtstoasc.o
OBJS-$(CONFIG_AV1_FRAME_MERGE_BSF)+= bsf/av1_frame_merge.o
OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= bsf/av1_frame_split.o
OBJS-$(CONFIG_AV1_METADATA_BSF) += bsf/av1_metadata.o
+OBJS-$(CONFIG_AWEBP2WEBP_BSF) += bsf/awebp2webp.o
OBJS-$(CONFIG_CHOMP_BSF) += bsf/chomp.o
OBJS-$(CONFIG_DCA_CORE_BSF) += bsf/dca_core.o
OBJS-$(CONFIG_DTS2PTS_BSF)+= bsf/dts2pts.o
diff --git a/libavcodec/bsf/awebp2webp.c b/libavcodec/bsf/awebp2webp.c
new file mode 100644
index 00..ebd123c667
--- /dev/null
+++ b/libavcodec/bsf/awebp2webp.c
@@ -0,0 +1,350 @@
+/*
+ * Animated WebP into non-compliant WebP bitstream filter
+ * Copyright (c) 2024 Thilo Borgmann
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Animated WebP into non-compliant WebP bitstream filter
+ * Splits a packet containing a webp animations into
+ * one non-compliant packet per frame of the animation.
+ * Skips RIFF and WEBP chunks for those packets except
+ * for the first. Copyies ICC, EXIF and XMP chunks first
+ * into each of the packets except for the first.
+ * @author Thilo Borgmann
+ */
+
+#include
+#include
+
+#include "codec_id.h"
+#include "bytestream.h"
+#include "libavutil/error.h"
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "packet.h"
+
+#define VP8X_FLAG_ANIMATION 0x02
+#define VP8X_FLAG_XMP_METADATA 0x04
+#define VP8X_FLAG_EXIF_METADATA 0x08
+#define VP8X_FLAG_ALPHA 0x10
+#define VP8X_FLAG_ICC 0x20
+
+typedef struct WEBPBSFContext {
+const AVClass *class;
+GetByteContext gb;
+
+AVPacket *last_pkt;
+uint8_t *last_iccp;
+uint8_t *last_exif;
+uint8_t *last_xmp;
+
+int iccp_size;
+int exif_size;
+int xmp_size;
+
+int add_iccp;
+int add_exif;
+int add_xmp;
+
+uint64_t last_pts;
+} WEBPBSFContext;
+
+static int save_chunk(WEBPBSFContext *ctx, uint8_t **buf, int *buf_size,
uint32_t chunk_size)
+{
+if (*buf || !buf_size || !chunk_size)
+return 0;
+
+*buf = av_malloc(chunk_size + 8);
+if (!*buf)
+return AVERROR(ENOMEM);
+
+*buf_size = chunk_size + 8;
+
+bytestream2_seek(>gb, -8, SEEK_CUR);
+bytestream2_get_buffer(>gb, *buf, chunk_size + 8);
+
+return 0;
+}
+
+static int awebp2webp_filter(AVBSFContext *ctx, AVPacket *out)
+{
+
[FFmpeg-devel] [PATCH v12 2/8] avcodec/webp: separate VP8 decoding
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 50 +--
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 3c153d78d1..3075321e86 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -195,6 +195,7 @@ typedef struct WebPContext {
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
+AVCodecContext *avctx_vp8; /* wrapper context for VP8 decoder */
int initialized;/* set once the VP8 context is
initialized */
int has_alpha; /* has a separate alpha chunk */
enum AlphaCompression alpha_compression; /* compression type for alpha
chunk */
@@ -1299,12 +1300,13 @@ static int vp8_lossy_decode_frame(AVCodecContext
*avctx, AVFrame *p,
int ret;
if (!s->initialized) {
-ff_vp8_decode_init(avctx);
+VP8Context *s_vp8 = s->avctx_vp8->priv_data;
+s_vp8->actually_webp = 1;
s->initialized = 1;
-s->v.actually_webp = 1;
}
avctx->pix_fmt = s->has_alpha ? AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
s->lossless = 0;
+s->avctx_vp8->pix_fmt = avctx->pix_fmt;
if (data_size > INT_MAX) {
av_log(avctx, AV_LOG_ERROR, "unsupported chunk size\n");
@@ -1315,14 +1317,32 @@ static int vp8_lossy_decode_frame(AVCodecContext
*avctx, AVFrame *p,
s->pkt->data = data_start;
s->pkt->size = data_size;
-ret = ff_vp8_decode_frame(avctx, p, got_frame, s->pkt);
-if (ret < 0)
+ret = avcodec_send_packet(s->avctx_vp8, s->pkt);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Error submitting a packet for
decoding\n");
return ret;
+}
-if (!*got_frame)
+ret = avcodec_receive_frame(s->avctx_vp8, p);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "VP8 decoding error: %s.\n",
av_err2str(ret));
return AVERROR_INVALIDDATA;
+}
+
+ret = ff_decode_frame_props(avctx, p);
+if (ret < 0) {
+return ret;
+}
+
+if (!p->private_ref) {
+ret = ff_attach_decode_data(p);
+if (ret < 0) {
+return ret;
+}
+}
-update_canvas_size(avctx, avctx->width, avctx->height);
+*got_frame = 1;
+update_canvas_size(avctx, s->avctx_vp8->width, s->avctx_vp8->height);
if (s->has_alpha) {
ret = vp8_lossy_decode_alpha(avctx, p, s->alpha_data,
@@ -1539,11 +1559,28 @@ exif_end:
static av_cold int webp_decode_init(AVCodecContext *avctx)
{
WebPContext *s = avctx->priv_data;
+int ret;
+const AVCodec *codec;
s->pkt = av_packet_alloc();
if (!s->pkt)
return AVERROR(ENOMEM);
+
+/* Prepare everything needed for VP8 decoding */
+codec = avcodec_find_decoder(AV_CODEC_ID_VP8);
+if (!codec)
+return AVERROR_BUG;
+s->avctx_vp8 = avcodec_alloc_context3(codec);
+if (!s->avctx_vp8)
+return AVERROR(ENOMEM);
+s->avctx_vp8->flags = avctx->flags;
+s->avctx_vp8->flags2 = avctx->flags2;
+s->avctx_vp8->pix_fmt = avctx->pix_fmt;
+ret = avcodec_open2(s->avctx_vp8, codec, NULL);
+if (ret < 0) {
+return ret;
+}
return 0;
}
@@ -1552,6 +1589,7 @@ static av_cold int webp_decode_close(AVCodecContext
*avctx)
WebPContext *s = avctx->priv_data;
av_packet_free(>pkt);
+avcodec_free_context(>avctx_vp8);
if (s->initialized)
return ff_vp8_decode_free(avctx);
--
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".
[FFmpeg-devel] [PATCH v12 1/8] avcodec/webp: remove unused definitions
From: Thilo Borgmann via ffmpeg-devel --- libavcodec/webp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/webp.c b/libavcodec/webp.c index dbcc5e73eb..3c153d78d1 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -60,8 +60,6 @@ #define VP8X_FLAG_ALPHA 0x10 #define VP8X_FLAG_ICC 0x20 -#define MAX_PALETTE_SIZE256 -#define MAX_CACHE_BITS 11 #define NUM_CODE_LENGTH_CODES 19 #define HUFFMAN_CODES_PER_META_CODE 5 #define NUM_LITERAL_CODES 256 -- 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".
[FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding
From: Thilo Borgmann Marked WIP because we'd want to introduce private bsf's first; review welcome before that though VP8 decoder decoupled again The whole animated sequence goes into one packet The (currently public) bitstream filter splits animations up into non-conformant packets Now with XMP metadata support (as string, like MOV) Patch 5/8 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP libavformat/webp: add WebP demuxer Thilo Borgmann via ffmpeg-devel (6): avcodec/webp: remove unused definitions avcodec/webp: separate VP8 decoding avcodec/bsf: Add awebp2webp bitstream filter avcodec/webp: make init_canvas_frame static fate: add test for animated WebP avcodec/webp: export XMP metadata Changelog | 2 + configure | 1 + doc/demuxers.texi | 28 + libavcodec/bitstream_filters.c| 1 + libavcodec/bsf/Makefile | 1 + libavcodec/bsf/awebp2webp.c | 350 libavcodec/codec_desc.c | 3 +- libavcodec/version.h | 2 +- libavcodec/webp.c | 796 -- libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 383 + tests/fate/image.mak | 3 + tests/ref/fate/exif-image-webp| 4 +- tests/ref/fate/webp-anim | 22 + tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless | 2 +- .../fate/webp-rgb-lossless-palette-predictor | 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80| 2 +- 23 files changed, 1530 insertions(+), 84 deletions(-) create mode 100644 libavcodec/bsf/awebp2webp.c create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim -- 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".
[FFmpeg-devel] Mailinglist conduct (was: [EXT] Re: Query from Reuters on XZ, open source, and Microsoft)
Nicolas, On Mon, Apr 8, 2024 at 10:41 AM Nicolas George wrote: > This, sadly, your ilk has the power to enforce. > Some CC members believe it would be helpful for you (and maybe to others) if we explicitly laid out some ground rules more explicitly, so let us try: - you are entitled to any opinion or belief you wish to hold. We are no thought police. - you are allowed to express non-defamatory versions of these opinions when it is relevant to the discussion, or in new discussions, on our mailinglist. - you are explicitly asked to *not* derail ongoing (e.g. technical) discussions with these opinions where they are not relevant; do not bring up Libav-vs-FFmpeg history or other us-vs-them conspiracies. The CC has previously requested that you refrain from such conduct [1]. Therefore, we have decided to remove your mailinglist participation privilege for 2 weeks. Yours, the CC [Ronald, JB & James supporting the decision and Michael dissenting] (Michael mentioned that he is in favor of pointing out the "negative interactions" but only for a ban if a further "negative interaction" occurs after that.) [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2023-December/318316.html ___ 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] Mailinglist conduct (was: FFmpeg table at NAB)
Derek, On Wed, Apr 17, 2024 at 9:50 AM Derek Buitenhuis wrote: > I assume Thilo was hung over, and thus not on the booth. > > It is a disgrace. > This was an unnecessary personal attack, please don't do that again. Repeat offense may result in temporary bans on the mailinglist and/or IRC. Please keep it civil. Signed unanimously, your CC (Ronald, Michael, JB, James) ___ 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] 5 year plan & Inovation
On 17.04.2024 20:22, Michael Niedermayer wrote: On Wed, Apr 17, 2024 at 05:55:04PM +0200, Jean-Baptiste Kempf wrote: Hello, On Wed, 17 Apr 2024, at 17:22, Michael Niedermayer wrote: * ffchat (expand into realtime chat / zoom) this would bring in more users and developers, and we basically have almost Better leave that for others. There's an infinite amount of discord clones already. iam not following that genre that much ... so let me ask are there any that * preserve privacy (discord is not secure/private) * allow audio / video / text chat * scalable * need no central server Matrix? Elements? Mattermost? Rocket.chat? Jitsi? These seem quite complex systems Matrix says "(optional) end-to-end encryption" which for me is a fail https://jitsi.org/security/ nicely explains their security. And i agree that anything running primarely in a browser controlled by google cannot provide security/privacy what i had in mind with ffchat initially was a much simpler system simply something where 2+ people could connect and communicate with video and audio (text being easy to add). The complexity of ffchat would be more between /doc/examples and ffplay. My basic idea was that people would be identified by their public key hash + DNS name. And then just setup a connection in a ffplay like interface. That sounds a bit like re-inventing Tox. Which sadly seems a bit dead. ___ 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 1/3] avcodec/x86/vvc/vvcdsp_init: add put prototypes
> 发件人: Nuo Mi > 发送时间: 2024年4月17日 6:14 > 收件人: FFmpeg development discussions and patches > 抄送: Wu Jianhua > 主题: Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/x86/vvc/vvcdsp_init: add put > prototypes > > Hi Jianhua, > thank you for the patches. > could you add a log for each commit to explain why we need this commit? Sure. v3 sent. > > On Tue, Apr 16, 2024 at 1:36 AM > mailto:toq...@outlook.com>> wrote: > From: Wu Jianhua mailto:toq...@outlook.com>> > > Signed-off-by: Wu Jianhua mailto:toq...@outlook.com>> > --- > libavcodec/x86/vvc/vvcdsp_init.c | 35 +++- > 1 file changed, 34 insertions(+), 1 deletion(-) ___ 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 v3 3/3] avcodec/x86/vvc/vvcdsp_init: fix linking error when configuring with --disable-ssse3 --disable-optimizations options
From: Wu Jianhua
Signed-off-by: Wu Jianhua
---
libavcodec/x86/vvc/vvcdsp_init.c | 46 +---
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/libavcodec/x86/vvc/vvcdsp_init.c b/libavcodec/x86/vvc/vvcdsp_init.c
index aef6699c35..985d750472 100644
--- a/libavcodec/x86/vvc/vvcdsp_init.c
+++ b/libavcodec/x86/vvc/vvcdsp_init.c
@@ -88,6 +88,7 @@ AVG_PROTOTYPES(10, avx2)
AVG_PROTOTYPES(12, avx2)
#if ARCH_X86_64
+#if HAVE_SSE4_EXTERNAL
#define FW_PUT(name, depth, opt) \
void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const uint8_t
*src, ptrdiff_t srcstride,\
int height, const int8_t *hf,
const int8_t *vf, int width)\
@@ -125,7 +126,9 @@ void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t
*dst, const uint8_t *sr
FW_PUT_SSE4( 8)
FW_PUT_SSE4(10)
FW_PUT_SSE4(12)
+#endif
+#if HAVE_AVX2_EXTERNAL
#define FW_PUT_TAP_AVX2(n, bitd)\
FW_PUT(n ## tap_h32, bitd, avx2) \
FW_PUT(n ## tap_h64, bitd, avx2) \
@@ -161,6 +164,25 @@ FW_PUT_AVX2(12)
FW_PUT_16BPC_AVX2(10)
FW_PUT_16BPC_AVX2(12)
+#define AVG_FUNCS(bpc, bd, opt)
\
+void bf(ff_vvc_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+const int16_t *src0, const int16_t *src1, int width, int height)
\
+{
\
+BF(ff_vvc_avg, bpc, opt)(dst, dst_stride, src0, src1, width, height, (1 <<
bd) - 1); \
+}
\
+void bf(ff_vvc_w_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+const int16_t *src0, const int16_t *src1, int width, int height,
\
+int denom, int w0, int w1, int o0, int o1)
\
+{
\
+BF(ff_vvc_w_avg, bpc, opt)(dst, dst_stride, src0, src1, width, height,
\
+denom, w0, w1, o0, o1, (1 << bd) - 1);
\
+}
+
+AVG_FUNCS(8, 8, avx2)
+AVG_FUNCS(16, 10, avx2)
+AVG_FUNCS(16, 12, avx2)
+#endif
+
#define PEL_LINK(dst, C, W, idx1, idx2, name, D, opt)
\
dst[C][W][idx1][idx2] = ff_vvc_put_## name ## _ ## D ## _##opt;
\
dst ## _uni[C][W][idx1][idx2] = ff_h2656_put_uni_ ## name ## _ ## D ##
_##opt; \
@@ -226,27 +248,9 @@ FW_PUT_16BPC_AVX2(12)
MC_TAP_LINKS_16BPC_AVX2(LUMA, 8, bd); \
MC_TAP_LINKS_16BPC_AVX2(CHROMA, 4, bd);
-#define AVG_FUNCS(bpc, bd, opt)
\
-void bf(ff_vvc_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
-const int16_t *src0, const int16_t *src1, int width, int height)
\
-{
\
-BF(ff_vvc_avg, bpc, opt)(dst, dst_stride, src0, src1, width, height, (1 <<
bd) - 1); \
-}
\
-void bf(ff_vvc_w_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
-const int16_t *src0, const int16_t *src1, int width, int height,
\
-int denom, int w0, int w1, int o0, int o1)
\
-{
\
-BF(ff_vvc_w_avg, bpc, opt)(dst, dst_stride, src0, src1, width, height,
\
-denom, w0, w1, o0, o1, (1 << bd) - 1);
\
-}
-
-AVG_FUNCS(8, 8, avx2)
-AVG_FUNCS(16, 10, avx2)
-AVG_FUNCS(16, 12, avx2)
-
-#define AVG_INIT(bd, opt) do { \
-c->inter.avg= bf(ff_vvc_avg, bd, opt); \
-c->inter.w_avg = bf(ff_vvc_w_avg, bd, opt);\
+#define AVG_INIT(bd, opt) do { \
+c->inter.avg= bf(ff_vvc_avg, bd, opt); \
+c->inter.w_avg = bf(ff_vvc_w_avg, bd, opt); \
} while (0)
#endif
--
2.44.0.windows.1
___
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 v3 2/3] avcodec/x86/vvc/vvcdsp_init: add avg prototypes
From: Wu Jianhua
When we used the --disable-ssse3 --disable-optimizations options,
the compiler would not skip the MC_LINKS like the compilation that
enabled the optimization, so it would fail to find the function
prototypes. Hence, this commit uses the same way to add prototypes
for the functions as HEVC DSP.
And, when prototypes are added for the functions, we cannot add the static
qualifier.
Therefore, the ff_vvc prefix is needed to avoid the naming conflict.
Signed-off-by: Wu Jianhua
---
libavcodec/x86/vvc/vvcdsp_init.c | 45
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/libavcodec/x86/vvc/vvcdsp_init.c b/libavcodec/x86/vvc/vvcdsp_init.c
index d9203f4d5f..aef6699c35 100644
--- a/libavcodec/x86/vvc/vvcdsp_init.c
+++ b/libavcodec/x86/vvc/vvcdsp_init.c
@@ -63,6 +63,30 @@ PUT_TAP_PROTOTYPES(8, sse4)
PUT_TAP_PROTOTYPES(4, avx2)
PUT_TAP_PROTOTYPES(8, avx2)
+#define bf(fn, bd, opt) fn##_##bd##_##opt
+#define BF(fn, bpc, opt) fn##_##bpc##bpc_##opt
+
+#define AVG_BPC_PROTOTYPES(bpc, opt)
\
+void BF(ff_vvc_avg, bpc, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+const int16_t *src0, const int16_t *src1, intptr_t width, intptr_t height,
intptr_t pixel_max); \
+void BF(ff_vvc_w_avg, bpc, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+const int16_t *src0, const int16_t *src1, intptr_t width, intptr_t height,
\
+intptr_t denom, intptr_t w0, intptr_t w1, intptr_t o0, intptr_t o1,
intptr_t pixel_max);
+
+#define AVG_PROTOTYPES(bd, opt)
\
+void bf(ff_vvc_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+const int16_t *src0, const int16_t *src1, int width, int height);
\
+void bf(ff_vvc_w_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+const int16_t *src0, const int16_t *src1, int width, int height,
\
+int denom, int w0, int w1, int o0, int o1);
+
+AVG_BPC_PROTOTYPES( 8, avx2)
+AVG_BPC_PROTOTYPES(16, avx2)
+
+AVG_PROTOTYPES( 8, avx2)
+AVG_PROTOTYPES(10, avx2)
+AVG_PROTOTYPES(12, avx2)
+
#if ARCH_X86_64
#define FW_PUT(name, depth, opt) \
void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const uint8_t
*src, ptrdiff_t srcstride,\
@@ -202,23 +226,13 @@ FW_PUT_16BPC_AVX2(12)
MC_TAP_LINKS_16BPC_AVX2(LUMA, 8, bd); \
MC_TAP_LINKS_16BPC_AVX2(CHROMA, 4, bd);
-#define bf(fn, bd, opt) fn##_##bd##_##opt
-#define BF(fn, bpc, opt) fn##_##bpc##bpc_##opt
-
-#define AVG_BPC_FUNC(bpc, opt)
\
-void BF(ff_vvc_avg, bpc, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
-const int16_t *src0, const int16_t *src1, intptr_t width, intptr_t height,
intptr_t pixel_max); \
-void BF(ff_vvc_w_avg, bpc, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
-const int16_t *src0, const int16_t *src1, intptr_t width, intptr_t height,
\
-intptr_t denom, intptr_t w0, intptr_t w1, intptr_t o0, intptr_t o1,
intptr_t pixel_max);
-
#define AVG_FUNCS(bpc, bd, opt)
\
-static void bf(avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+void bf(ff_vvc_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
const int16_t *src0, const int16_t *src1, int width, int height)
\
{
\
BF(ff_vvc_avg, bpc, opt)(dst, dst_stride, src0, src1, width, height, (1 <<
bd) - 1); \
}
\
-static void bf(w_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
+void bf(ff_vvc_w_avg, bd, opt)(uint8_t *dst, ptrdiff_t dst_stride,
\
const int16_t *src0, const int16_t *src1, int width, int height,
\
int denom, int w0, int w1, int o0, int o1)
\
{
\
@@ -226,16 +240,13 @@ static void bf(w_avg, bd, opt)(uint8_t *dst, ptrdiff_t
dst_stride,
denom, w0, w1, o0, o1, (1 << bd) - 1);
\
}
-AVG_BPC_FUNC(8, avx2)
-AVG_BPC_FUNC(16, avx2)
-
AVG_FUNCS(8, 8, avx2)
AVG_FUNCS(16, 10, avx2)
AVG_FUNCS(16, 12, avx2)
#define
[FFmpeg-devel] [PATCH v3 1/3] avcodec/x86/vvc/vvcdsp_init: add put prototypes
From: Wu Jianhua
When we used the --disable-ssse3 --disable-optimizations options,
the compiler would not skip the MC_LINKS like the compilation that
enabled the optimization, so it would fail to find the function
prototypes. Hence, this commit uses the same way to add prototypes
for the functions as HEVC DSP.
Signed-off-by: Wu Jianhua
---
libavcodec/x86/vvc/vvcdsp_init.c | 35 +++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/vvc/vvcdsp_init.c b/libavcodec/x86/vvc/vvcdsp_init.c
index 23a3172c45..d9203f4d5f 100644
--- a/libavcodec/x86/vvc/vvcdsp_init.c
+++ b/libavcodec/x86/vvc/vvcdsp_init.c
@@ -30,9 +30,42 @@
#include "libavcodec/vvc/dsp.h"
#include "libavcodec/x86/h26x/h2656dsp.h"
+#define PUT_PROTOTYPE(name, depth, opt) \
+void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const uint8_t
*src, ptrdiff_t srcstride, int height, const int8_t *hf, const int8_t *vf, int
width);
+
+#define PUT_PROTOTYPES(name, bitd, opt) \
+PUT_PROTOTYPE(name##2, bitd, opt) \
+PUT_PROTOTYPE(name##4, bitd, opt) \
+PUT_PROTOTYPE(name##8, bitd, opt) \
+PUT_PROTOTYPE(name##12, bitd, opt) \
+PUT_PROTOTYPE(name##16, bitd, opt) \
+PUT_PROTOTYPE(name##24, bitd, opt) \
+PUT_PROTOTYPE(name##32, bitd, opt) \
+PUT_PROTOTYPE(name##48, bitd, opt) \
+PUT_PROTOTYPE(name##64, bitd, opt) \
+PUT_PROTOTYPE(name##128, bitd, opt)
+
+#define PUT_BPC_PROTOTYPES(name, opt) \
+PUT_PROTOTYPES(name, 8, opt) \
+PUT_PROTOTYPES(name, 10, opt) \
+PUT_PROTOTYPES(name, 12, opt)
+
+#define PUT_TAP_PROTOTYPES(n, opt) \
+PUT_BPC_PROTOTYPES(n##tap_h, opt) \
+PUT_BPC_PROTOTYPES(n##tap_v, opt) \
+PUT_BPC_PROTOTYPES(n##tap_hv, opt)
+
+PUT_BPC_PROTOTYPES(pixels, sse4)
+PUT_BPC_PROTOTYPES(pixels, avx2)
+
+PUT_TAP_PROTOTYPES(4, sse4)
+PUT_TAP_PROTOTYPES(8, sse4)
+PUT_TAP_PROTOTYPES(4, avx2)
+PUT_TAP_PROTOTYPES(8, avx2)
+
#if ARCH_X86_64
#define FW_PUT(name, depth, opt) \
-static void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const
uint8_t *src, ptrdiff_t srcstride, \
+void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const uint8_t
*src, ptrdiff_t srcstride,\
int height, const int8_t *hf,
const int8_t *vf, int width)\
{
\
ff_h2656_put_## name ## _ ## depth ## _##opt(dst, 2 * MAX_PB_SIZE, src,
srcstride, height, hf, vf, width); \
--
2.44.0.windows.1
___
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] 5 year plan & Inovation
On Wed, Apr 17, 2024 at 05:55:04PM +0200, Jean-Baptiste Kempf wrote: > Hello, > > On Wed, 17 Apr 2024, at 17:22, Michael Niedermayer wrote: > >> > * ffchat > >> > (expand into realtime chat / zoom) this would > >> > bring in more users and developers, and we basically have almost > >> > > >> > >> Better leave that for others. > >> There's an infinite amount of discord clones already. > > > > iam not following that genre that much ... > > so let me ask > > are there any that > > * preserve privacy (discord is not secure/private) > > * allow audio / video / text chat > > * scalable > > * need no central server > > Matrix? Elements? Mattermost? Rocket.chat? Jitsi? These seem quite complex systems Matrix says "(optional) end-to-end encryption" which for me is a fail https://jitsi.org/security/ nicely explains their security. And i agree that anything running primarely in a browser controlled by google cannot provide security/privacy what i had in mind with ffchat initially was a much simpler system simply something where 2+ people could connect and communicate with video and audio (text being easy to add). The complexity of ffchat would be more between /doc/examples and ffplay. My basic idea was that people would be identified by their public key hash + DNS name. And then just setup a connection in a ffplay like interface. Its a good example on how to use our libs in a realtime chat app and it allows us to grow it if we want at any time thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin 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".
[FFmpeg-devel] [PATCH v3 2/2] lavc/aarch64/fdct: add neon-optimized fdct for aarch64
The code is imported from libjpeg-turbo-3.0.1. The neon registers used
have been changed to avoid modifying v8-v15.
Reviewed-by: Martin Storsjö
---
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/fdct.h | 26 ++
libavcodec/aarch64/fdctdsp_init_aarch64.c | 39 +++
libavcodec/aarch64/fdctdsp_neon.S | 368 ++
libavcodec/avcodec.h | 1 +
libavcodec/fdctdsp.c | 4 +-
libavcodec/fdctdsp.h | 2 +
libavcodec/options_table.h| 1 +
libavcodec/tests/aarch64/dct.c| 2 +
9 files changed, 444 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/fdct.h
create mode 100644 libavcodec/aarch64/fdctdsp_init_aarch64.c
create mode 100644 libavcodec/aarch64/fdctdsp_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 95ad4dd202..a3256bb1cc 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -1,5 +1,6 @@
# subsystems
OBJS-$(CONFIG_AC3DSP) += aarch64/ac3dsp_init_aarch64.o
+OBJS-$(CONFIG_FDCTDSP) += aarch64/fdctdsp_init_aarch64.o
OBJS-$(CONFIG_FMTCONVERT) += aarch64/fmtconvert_init.o
OBJS-$(CONFIG_H264CHROMA) += aarch64/h264chroma_init_aarch64.o
OBJS-$(CONFIG_H264DSP) += aarch64/h264dsp_init_aarch64.o
@@ -37,6 +38,7 @@ ARMV8-OBJS-$(CONFIG_VIDEODSP) += aarch64/videodsp.o
# subsystems
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/sbrdsp_neon.o
NEON-OBJS-$(CONFIG_AC3DSP) += aarch64/ac3dsp_neon.o
+NEON-OBJS-$(CONFIG_FDCTDSP) += aarch64/fdctdsp_neon.o
NEON-OBJS-$(CONFIG_FMTCONVERT) += aarch64/fmtconvert_neon.o
NEON-OBJS-$(CONFIG_H264CHROMA) += aarch64/h264cmc_neon.o
NEON-OBJS-$(CONFIG_H264DSP) += aarch64/h264dsp_neon.o
\
diff --git a/libavcodec/aarch64/fdct.h b/libavcodec/aarch64/fdct.h
new file mode 100644
index 00..0901b53a83
--- /dev/null
+++ b/libavcodec/aarch64/fdct.h
@@ -0,0 +1,26 @@
+/*
+ * 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
+ */
+
+#ifndef AVCODEC_AARCH64_FDCT_H
+#define AVCODEC_AARCH64_FDCT_H
+
+#include
+
+void ff_fdct_neon(int16_t *block);
+
+#endif /* AVCODEC_AARCH64_FDCT_H */
diff --git a/libavcodec/aarch64/fdctdsp_init_aarch64.c
b/libavcodec/aarch64/fdctdsp_init_aarch64.c
new file mode 100644
index 00..59d91bc8fc
--- /dev/null
+++ b/libavcodec/aarch64/fdctdsp_init_aarch64.c
@@ -0,0 +1,39 @@
+/*
+ * 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/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/aarch64/cpu.h"
+#include "libavcodec/avcodec.h"
+#include "libavcodec/fdctdsp.h"
+#include "fdct.h"
+
+av_cold void ff_fdctdsp_init_aarch64(FDCTDSPContext *c, AVCodecContext *avctx,
+ unsigned high_bit_depth)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags)) {
+if (!high_bit_depth) {
+if (avctx->dct_algo == FF_DCT_AUTO ||
+avctx->dct_algo == FF_DCT_NEON) {
+c->fdct = ff_fdct_neon;
+}
+}
+}
+}
diff --git a/libavcodec/aarch64/fdctdsp_neon.S
b/libavcodec/aarch64/fdctdsp_neon.S
new file mode 100644
index 00..53fa4debe5
--- /dev/null
+++ b/libavcodec/aarch64/fdctdsp_neon.S
@@ -0,0 +1,368 @@
+/*
+ * Armv8 Neon optimizations for libjpeg-turbo
+ *
+ * Copyright (C) 2009-2011, Nokia Corporation and/or
[FFmpeg-devel] [PATCH v3 1/2] checkasm: add test for fdct
Reviewed-by: Martin Storsjö
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/fdctdsp.c | 68 +++
tests/fate/checkasm.mak | 1 +
5 files changed, 74 insertions(+)
create mode 100644 tests/checkasm/fdctdsp.c
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 2673e1d098..70a6120c70 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -4,6 +4,7 @@ AVCODECOBJS-$(CONFIG_AC3DSP)+= ac3dsp.o
AVCODECOBJS-$(CONFIG_AUDIODSP) += audiodsp.o
AVCODECOBJS-$(CONFIG_BLOCKDSP) += blockdsp.o
AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
+AVCODECOBJS-$(CONFIG_FDCTDSP) += fdctdsp.o
AVCODECOBJS-$(CONFIG_FMTCONVERT)+= fmtconvert.o
AVCODECOBJS-$(CONFIG_G722DSP) += g722dsp.o
AVCODECOBJS-$(CONFIG_H264CHROMA)+= h264chroma.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 8be6cb0f55..92c3a30ad3 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -106,6 +106,9 @@ static const struct {
#if CONFIG_EXR_DECODER
{ "exrdsp", checkasm_check_exrdsp },
#endif
+#if CONFIG_FDCTDSP
+{ "fdctdsp", checkasm_check_fdctdsp },
+#endif
#if CONFIG_FLAC_DECODER
{ "flacdsp", checkasm_check_flacdsp },
#endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index f90920dee7..d3e8f9a37a 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -85,6 +85,7 @@ void checkasm_check_blockdsp(void);
void checkasm_check_bswapdsp(void);
void checkasm_check_colorspace(void);
void checkasm_check_exrdsp(void);
+void checkasm_check_fdctdsp(void);
void checkasm_check_fixed_dsp(void);
void checkasm_check_flacdsp(void);
void checkasm_check_float_dsp(void);
diff --git a/tests/checkasm/fdctdsp.c b/tests/checkasm/fdctdsp.c
new file mode 100644
index 00..68a9b5e435
--- /dev/null
+++ b/tests/checkasm/fdctdsp.c
@@ -0,0 +1,68 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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
+
+#include "checkasm.h"
+
+#include "libavcodec/avcodec.h"
+#include "libavcodec/fdctdsp.h"
+
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/mem_internal.h"
+
+static int int16_cmp_off_by_n(const int16_t *ref, const int16_t *test, size_t
n, int accuracy)
+{
+for (size_t i = 0; i < n; i++) {
+if (abs(ref[i] - test[i]) > accuracy)
+return 1;
+}
+return 0;
+}
+
+static void check_fdct(void)
+{
+LOCAL_ALIGNED_16(int16_t, block0, [64]);
+LOCAL_ALIGNED_16(int16_t, block1, [64]);
+
+AVCodecContext avctx = { 0 };
+FDCTDSPContext h;
+
+ff_fdctdsp_init(, );
+
+if (check_func(h.fdct, "fdct")) {
+declare_func(void, int16_t *);
+for (int i = 0; i < 64; i++) {
+uint8_t r = rnd();
+block0[i] = r;
+block1[i] = r;
+}
+call_ref(block0);
+call_new(block1);
+if (int16_cmp_off_by_n(block0, block1, 64, 2))
+fail();
+bench_new(block1);
+}
+}
+
+void checkasm_check_fdctdsp(void)
+{
+check_fdct();
+report("fdctdsp");
+}
diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
index 3b5b867a97..10a42f2f9d 100644
--- a/tests/fate/checkasm.mak
+++ b/tests/fate/checkasm.mak
@@ -8,6 +8,7 @@ FATE_CHECKASM = fate-checkasm-aacencdsp
\
fate-checkasm-blockdsp \
fate-checkasm-bswapdsp \
fate-checkasm-exrdsp\
+fate-checkasm-fdctdsp \
fate-checkasm-fixed_dsp \
fate-checkasm-flacdsp \
fate-checkasm-float_dsp \
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 0/2] lavc/aarch64/fdct: add neon-optimized fdct for aarch64
This patch set adds fdct to checkasm and neon-optimized fdct for aarch64. Ramiro Polla (2): checkasm: add test for fdct lavc/aarch64/fdct: add neon-optimized fdct for aarch64 libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/fdct.h | 26 ++ libavcodec/aarch64/fdctdsp_init_aarch64.c | 39 +++ libavcodec/aarch64/fdctdsp_neon.S | 368 ++ libavcodec/avcodec.h | 1 + libavcodec/fdctdsp.c | 4 +- libavcodec/fdctdsp.h | 2 + libavcodec/options_table.h| 1 + libavcodec/tests/aarch64/dct.c| 2 + tests/checkasm/Makefile | 1 + tests/checkasm/checkasm.c | 3 + tests/checkasm/checkasm.h | 1 + tests/checkasm/fdctdsp.c | 68 tests/fate/checkasm.mak | 1 + 14 files changed, 518 insertions(+), 1 deletion(-) create mode 100644 libavcodec/aarch64/fdct.h create mode 100644 libavcodec/aarch64/fdctdsp_init_aarch64.c create mode 100644 libavcodec/aarch64/fdctdsp_neon.S create mode 100644 tests/checkasm/fdctdsp.c -- 2.30.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v11 4/8] libavcodec/webp: add support for animated WebP
On Thu, Mar 28, 2024 at 7:10 AM Thilo Borgmann via ffmpeg-devel wrote: > > From: Josef Zlomek > > Fixes: 4907 > > Adds support for decoding of animated WebP. > > The WebP decoder adds the animation related features according to the specs: > https://developers.google.com/speed/webp/docs/riff_container#animation > The frames of the animation may be smaller than the image canvas. > Therefore, the frame is decoded to a temporary frame, > then it is blended into the canvas, the canvas is copied to the output frame, > and finally the frame is disposed from the canvas. > > The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported. > The background color is specified only as BGRA in the WebP file > so it is converted to YUVA if YUV formats are output. > > Signed-off-by: Josef Zlomek > --- > Changelog | 1 + > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h| 2 +- > libavcodec/webp.c | 710 > 4 files changed, 653 insertions(+), 63 deletions(-) > I'm late trying to test these. I think these need to be rebased. version.h is easy enough to skip. I didn't look at the conflict in webp.c. error: patch failed: libavcodec/version.h:30 error: libavcodec/version.h: patch does not apply error: patch failed: libavcodec/webp.c:35 error: libavcodec/webp.c: patch does not apply Patch failed at 0004 libavcodec/webp: add support for animated WebP ___ 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] 5 year plan & Inovation
On 17/04/2024 14:58, Michael Niedermayer wrote: Hi all The pace of inovation in FFmpeg has been slowing down. Most work is concentarted nowadays on code refactoring, and adding support for new codecs and formats. Should we * make a list of longer term goals * vote on them * and then together work towards implementing them ? (The idea here is to increase the success of larger efforts than adding codecs and refactoring code) It would then also not be possible for individuals to object to a previously agreed goal. And it would add ideas for which we can try to get funding/grants for (larger scale changes need consensus first that we as a whole want them before we would be able to ask for funding/grants for them) Some ideas and why they would help FFmpeg: * Switch to a plugin architecture (Increase the number of developers willing to contribute and reduce friction as the team and community grows) * ffchat (expand into realtime chat / zoom) this would bring in more users and developers, and we basically have almost all parts for it already but some people where against it * client side / in browser support (expand towards webapps, webpages using ffmpeg client side in the browser) bring in more users and developers, and it will be costly for us if we let others take this area as its important and significant * AI / neural network filters and codecs The future seems to be AI based. Future Filters and Codecs will use neural networks. FFmpeg can be at the forefront, developing these * [your idea here] thx ___ 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". I've occasionally tried getting into ffmpeg for over a decade now, and have lurked here for the past few months as I put in the effort to grok it. On behalf of people who could contribute but don't, I'd like to suggest ffmpeg focus on *learnability*. Whenever I've tried to learn ffmpeg, I've always been rebuffed by documentation that seems needlessly hard to use. I understand some of these reflect deeper issues - for example there's a reason the words "ffmpeg" and "libav" are used ambiguously, even though it makes it hard to differentiate between the library and the command-line tool. But other issues seem like quick wins - for example I've lost count of all the times I typed two functions into Google, spent hours trying to make them work together, then finally realised I was looking at the documentation for 3.0 in one tab and 5.0 in the other. Surely you can just add a line to the top of the documentation like "click here to see the trunk version of this file"? Here's a small example to demonstrate the larger issue - what does it mean for something to be a "context"? When I started learning how to write ffmpeg code, I read through the docs and saw various things calling themselves "context" structs, but never found a link to explain what that meant. If I was a young developer, I would probably have just assumed it was standard programming jargon I was too dumb to know, and walked away to find something more my speed. But I'm old and stubborn and have nothing better to do right now, so I kept going... I tried to learn by going through the examples, but the nearest thing to an explanation was e.g. `transcode.c` making up a new type and calling it a `FilteringContext`. I ignored the AVClass documentation for a long time because the name made me think it was some kind of GObject-style C-with-classes thing. It was only when I noticed that it says it describes "the class of an AVClass context structure" that I realised what I was looking at. And it was only when I convinced myself that the documentation for AVOptions was using "AVOptions-enabled struct" to mean the same thing as "AVClass context structure" that I felt able to disregard the `FilteringContext`. So my current opinion is that "AVOptions-enabled struct", "AVClass context structure" and "context structure" are different terms for the same thing - but now I've said that publicly, I will no doubt find an "SwrClass context structure" or something tomorrow. To bring this back to ffmpeg development - I made a note to write a patch saying they were synonyms and linking that explanation from e.g. AVCodecContext, but the job has been rotting away in my todo list for a month now waiting for me to be "sure I've got it right" (i.e. to give up a perfect excuse for procrastination). To be blunt, on some level it feels like I've put more in than I've got out of that problem, and haven't been able to psych myself up to submit a patch that could get me laughed out of the room (or worse, politely ignored). If the project was otherwise easy-to-learn, I would have felt a much stronger sense of obligation to pay that back. - Andrew Sayers
Re: [FFmpeg-devel] [PATCH] avdevice/avfoundation: fix macOS/iOS/tvOS SDK conditional checks
Hi, On 17.04.24 17:12, Marvin Scholz wrote: This fixes the checks to properly use runtime feature detection and check the SDK version (*_MAX_ALLOWED) instead of the targeted version for the relevant APIs. The target is still checked (*_MIN_REQUIRED) to avoid using deprecated methods when targeting new enough versions. --- libavdevice/avfoundation.m | 164 ++--- 1 file changed, 116 insertions(+), 48 deletions(-) this is probably the extension to what we started at FOSDEM, right? LGTM if tested. Please apply, I can't in the next couple of days. Thanks, Thilo ___ 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] 5 year plan & Inovation
On 17/04/2024 16:22, Michael Niedermayer wrote: > On Wed, Apr 17, 2024 at 04:22:03PM +0200, Lynne wrote: >> Apr 17, 2024, 15:58 by mich...@niedermayer.cc: >>> Some ideas and why they would help FFmpeg: >>> >>> [...] >>> >> >> Just no. >> >>> * ffchat >>> (expand into realtime chat / zoom) this would >>> bring in more users and developers, and we basically have almost >>> >> >> Better leave that for others. >> There's an infinite amount of discord clones already. > > iam not following that genre that much ... > so let me ask > are there any that > * preserve privacy (discord is not secure/private) > * allow audio / video / text chat > * scalable > * need no central server > > ? > This is what Matrix (https://matrix.org/) is attempting as I understand it, among others I'm sure. This is very ambitious, and I suspect outside most FFmpeg developers' specialisms. -- Frank ___ 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] 5 year plan & Inovation
Hello, On Wed, 17 Apr 2024, at 17:22, Michael Niedermayer wrote: >> > * ffchat >> > (expand into realtime chat / zoom) this would >> > bring in more users and developers, and we basically have almost >> > >> >> Better leave that for others. >> There's an infinite amount of discord clones already. > > iam not following that genre that much ... > so let me ask > are there any that > * preserve privacy (discord is not secure/private) > * allow audio / video / text chat > * scalable > * need no central server Matrix? Elements? Mattermost? Rocket.chat? Jitsi? -- Jean-Baptiste Kempf - President +33 672 704 734 https://jbkempf.com/ ___ 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] avdevice/avfoundation: fix macOS/iOS/tvOS SDK conditional checks
This fixes the checks to properly use runtime feature detection and
check the SDK version (*_MAX_ALLOWED) instead of the targeted version
for the relevant APIs.
The target is still checked (*_MIN_REQUIRED) to avoid using deprecated
methods when targeting new enough versions.
---
libavdevice/avfoundation.m | 164 ++---
1 file changed, 116 insertions(+), 48 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index e558ad7d90..a52e7df37b 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -28,6 +28,7 @@
#import
#include
+#include "libavutil/avassert.h"
#include "libavutil/channel_layout.h"
#include "libavutil/mem.h"
#include "libavutil/pixdesc.h"
@@ -764,57 +765,124 @@ static int get_audio_config(AVFormatContext *s)
}
static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
-#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 10) ||
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101500))
-NSMutableArray *deviceTypes = nil;
-if (mediaType == AVMediaTypeVideo) {
-deviceTypes = [NSMutableArray
arrayWithArray:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]];
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 10)
-[deviceTypes addObject: AVCaptureDeviceTypeBuiltInDualCamera];
-[deviceTypes addObject: AVCaptureDeviceTypeBuiltInTelephotoCamera];
-#endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 110100)
-[deviceTypes addObject: AVCaptureDeviceTypeBuiltInTrueDepthCamera];
-#endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 13)
-[deviceTypes addObject: AVCaptureDeviceTypeBuiltInTripleCamera];
-[deviceTypes addObject: AVCaptureDeviceTypeBuiltInDualWideCamera];
-[deviceTypes addObject: AVCaptureDeviceTypeBuiltInUltraWideCamera];
-#endif
-#if (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 13)
-[deviceTypes addObject: AVCaptureDeviceTypeDeskViewCamera];
-#endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 150400)
-[deviceTypes addObject:
AVCaptureDeviceTypeBuiltInLiDARDepthCamera];
-#endif
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 17 ||
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 14))
-[deviceTypes addObject: AVCaptureDeviceTypeContinuityCamera];
-#endif
-} else if (mediaType == AVMediaTypeAudio) {
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 17 ||
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 14))
-deviceTypes = [NSMutableArray
arrayWithArray:@[AVCaptureDeviceTypeMicrophone]];
-#else
-deviceTypes = [NSMutableArray
arrayWithArray:@[AVCaptureDeviceTypeBuiltInMicrophone]];
-#endif
-} else if (mediaType == AVMediaTypeMuxed) {
-#if (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 17 ||
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED >= 14))
-deviceTypes = [NSMutableArray
arrayWithArray:@[AVCaptureDeviceTypeExternal]];
-#elif (TARGET_OS_OSX && __MAC_OS_X_VERSION_MIN_REQUIRED < 14)
-deviceTypes = [NSMutableArray
arrayWithArray:@[AVCaptureDeviceTypeExternalUnknown]];
-#else
+
+#if (TARGET_OS_OSX&& defined(__MAC_10_15) &&
MAC_OS_X_VERSION_MAX_ALLOWED>= __MAC_10_15) || \
+(TARGET_OS_IOS&& defined(__IPHONE_10_0) &&
__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_10_0) || \
+(TARGET_OS_TV && defined(__TVOS_17_0) && __TV_OS_VERSION_MAX_ALLOWED
>= __TVOS_17_0)
+if (__builtin_available(macOS 10.15, iOS 10, tvOS 17, *)) {
+
+NSMutableArray *deviceTypes = nil;
+
+if (mediaType == AVMediaTypeVideo) {
+deviceTypes = [NSMutableArray
arrayWithArray:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]];
+
+#if (TARGET_OS_IOS || TARGET_OS_TV)
+// Devices only available on iOS/tvOS
+[deviceTypes addObject: AVCaptureDeviceTypeBuiltInDualCamera];
+[deviceTypes addObject:
AVCaptureDeviceTypeBuiltInTelephotoCamera];
+
+#if (TARGET_OS_IOS && defined(__IPHONE_11_1) &&
__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_11_1) || \
+(TARGET_OS_TV && defined(__TVOS_17_0) &&
__TV_OS_VERSION_MAX_ALLOWED >= __TVOS_17_0)
+if (__builtin_available(iOS 11.1, tvOS 17, *)) {
+[deviceTypes addObject:
AVCaptureDeviceTypeBuiltInTrueDepthCamera];
+}
+#endif
+
+#if (TARGET_OS_IOS && defined(__IPHONE_13_0) &&
__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_13_0) || \
+(TARGET_OS_TV && defined(__TVOS_17_0) &&
__TV_OS_VERSION_MAX_ALLOWED >= __TVOS_17_0)
+
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Wed, Apr 17, 2024 at 04:50:29PM +0200, Lynne wrote: > Apr 17, 2024, 16:34 by jamr...@gmail.com: > > > On 4/17/2024 11:22 AM, Lynne wrote: > > > >> Apr 17, 2024, 15:58 by mich...@niedermayer.cc: > >> > >>> Hi all > >>> > >>> The pace of inovation in FFmpeg has been slowing down. > >>> Most work is concentarted nowadays on code refactoring, and adding > >>> support for new codecs and formats. > >>> > >>> Should we > >>> * make a list of longer term goals > >>> * vote on them > >>> * and then together work towards implementing them > >>> ? > >>> > >>> (The idea here is to increase the success of larger efforts > >>> than adding codecs and refactoring code) > >>> It would then also not be possible for individuals to object > >>> to a previously agreed goal. > >>> And it would add ideas for which we can try to get funding/grants for > >>> > >>> (larger scale changes need consensus first that we as a whole want > >>> them before we would be able to ask for funding/grants for them) > >>> > >>> Some ideas and why they would help FFmpeg: > >>> > >>> * Switch to a plugin architecture > >>> (Increase the number of developers willing to contribute and reduce > >>> friction as the team and community grows) > >>> > >> > >> Just no. > >> > > > > Can you elaborate on why? The one thing i think would be problematic is > > making the AVCodec internals public, which could get in the way of > > improvements. > > > > First, we'd have the bad SoC vendors making binary plugins, with Make the plugin interface AGPL, problem solved thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 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] [RFC] 5 year plan & Inovation
On Wed, Apr 17, 2024 at 04:22:03PM +0200, Lynne wrote: > Apr 17, 2024, 15:58 by mich...@niedermayer.cc: > > > Hi all > > > > The pace of inovation in FFmpeg has been slowing down. > > Most work is concentarted nowadays on code refactoring, and adding > > support for new codecs and formats. > > > > Should we > > * make a list of longer term goals > > * vote on them > > * and then together work towards implementing them > > ? > > > > (The idea here is to increase the success of larger efforts > > than adding codecs and refactoring code) > > It would then also not be possible for individuals to object > > to a previously agreed goal. > > And it would add ideas for which we can try to get funding/grants for > > > > (larger scale changes need consensus first that we as a whole want > > them before we would be able to ask for funding/grants for them) > > > > Some ideas and why they would help FFmpeg: > > > > * Switch to a plugin architecture > > (Increase the number of developers willing to contribute and reduce > > friction as the team and community grows) > > > > Just no. > > > > * ffchat > > (expand into realtime chat / zoom) this would > > bring in more users and developers, and we basically have almost > > > > Better leave that for others. > There's an infinite amount of discord clones already. iam not following that genre that much ... so let me ask are there any that * preserve privacy (discord is not secure/private) * allow audio / video / text chat * scalable * need no central server ? > > > > all parts for it already but some people where against it > > * client side / in browser support > > (expand towards webapps, webpages using ffmpeg client side in the browser) > > bring in more users and developers, and it will be costly for us > > if we let others take this area as its important and significant > > > > Maybe. Some WASM-based converter would be helpful. i think jb once said you where working on something I do think this would be very cool > Though it may put us on fire, as we'd be distributing binaries > of our code which may cause issues with "rights holders". We dont have to it would be nice if someone does. But thats not strictly needed it could be simply a git clone https://ffmpeg.org/... make ffwasm and dumping the result on once own webserver Important is, that its easy to use. If one needs to spend hours installing packages and trial and erroring until it works that would kill it If someone just has to clone a repo and run ./configure ;make then put that on ones own server and then can use it from their webstuff or maybe a Dockerfile that automates the whole build no idea whats the most convenient > > > > * AI / neural network filters and codecs > > The future seems to be AI based. Future Filters and Codecs will use > > neural networks. FFmpeg can be at the forefront, developing these > > > > These take enormous amounts of compute power to > train, vast amounts of good high-quality data, and at > the end, you'd have something as lasting as wet paper, reminds me of researchers saying in the ninties that videocrypt needs dedicated hardware FPGAs implementing FFTs to decrypt in bad grayscale quality. around 1997 i implemented that in color without FFTs on my pentium MMX in realtime to watch satelite TV others independantly did similar things When i hear needs "enormous amounts" for an algorithm i tend to add a few "?" in my mind But as a open source project with millions of users iam not sure if "compute" would actually be such a big problem you would only have to figure out how to distribute that compute over volunteers > because a competitor is literally weeks away, and they > beat us with inferior methods by simply having vastly > more compute than we do. i think a question is, if one enjoys working on the technology and algorithms > > > > * [your idea here] > > > > We keep doing what we're doing. It's what we're good at. Coordinating a bit more than that would help bigger efforts thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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".
[FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: Make qsv hardware transfers thread safe
The QSV hardware context currently uses pthreads to lock initilization,
which is not available on windows builds. Instead, use the AVMutex
object. Also lock uses of the realigned_upload_frame and
realigned_download_frame objects, so multiple threads do not attempt
to write to them at the same time.
---
Here is a new patch addressing your comments
Fixed the nested calls to ff_mutex_lock
Fixed the two accidental tabs
Fixed the two violations of K style
Fixed the two incidents of mixing declaration and code
libavutil/hwcontext_qsv.c | 93 +++
1 file changed, 56 insertions(+), 37 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index c7c7878644..ed462d440a 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -23,10 +23,7 @@
#include
#include "config.h"
-
-#if HAVE_PTHREADS
-#include
-#endif
+#include "thread.h"
#define COBJMACROS
#if CONFIG_VAAPI
@@ -98,9 +95,7 @@ typedef struct QSVFramesContext {
atomic_int session_download_init;
mfxSession session_upload;
atomic_int session_upload_init;
-#if HAVE_PTHREADS
-pthread_mutex_t session_lock;
-#endif
+AVMutex session_lock;
AVBufferRef *child_frames_ref;
mfxFrameSurface1 *surfaces_internal;
@@ -354,9 +349,7 @@ static void qsv_frames_uninit(AVHWFramesContext *ctx)
s->session_upload = NULL;
s->session_upload_init = 0;
-#if HAVE_PTHREADS
-pthread_mutex_destroy(>session_lock);
-#endif
+ff_mutex_destroy(>session_lock);
av_freep(>mem_ids);
#if QSV_HAVE_OPAQUE
@@ -1302,9 +1295,7 @@ static int qsv_frames_init(AVHWFramesContext *ctx)
s->session_download_init = 0;
s->session_upload_init = 0;
-#if HAVE_PTHREADS
-pthread_mutex_init(>session_lock, NULL);
-#endif
+ff_mutex_init(>session_lock, NULL);
return 0;
}
@@ -1629,24 +1620,20 @@ static int
qsv_internal_session_check_init(AVHWFramesContext *ctx, int upload)
if (atomic_load(inited))
return 0;
-#if HAVE_PTHREADS
-pthread_mutex_lock(>session_lock);
-#endif
+ff_mutex_lock(>session_lock);
if (!atomic_load(inited)) {
ret = qsv_init_internal_session(ctx, session, upload);
atomic_store(inited, 1);
}
-#if HAVE_PTHREADS
-pthread_mutex_unlock(>session_lock);
-#endif
+ff_mutex_unlock(>session_lock);
return ret;
}
-static int qsv_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
- const AVFrame *src)
+static int qsv_transfer_data_from_internal(AVHWFramesContext *ctx, AVFrame
*dst,
+ const AVFrame *src, int realigned)
{
QSVFramesContext *s = ctx->hwctx;
mfxFrameSurface1 out = {{ 0 }};
@@ -1658,17 +1645,11 @@ static int qsv_transfer_data_from(AVHWFramesContext
*ctx, AVFrame *dst,
/* download to temp frame if the output is not padded as libmfx requires */
AVFrame *tmp_frame = >realigned_download_frame;
AVFrame *dst_frame;
-int realigned = 0;
-
-ret = qsv_internal_session_check_init(ctx, 0);
-if (ret < 0)
-return ret;
/* According to MSDK spec for mfxframeinfo, "Width must be a multiple of
16.
* Height must be a multiple of 16 for progressive frame sequence and a
* multiple of 32 otherwise.", so allign all frames to 16 before
downloading. */
-if (dst->height & 15 || dst->linesize[0] & 15) {
-realigned = 1;
+if (realigned) {
if (tmp_frame->format != dst->format ||
tmp_frame->width != FFALIGN(dst->linesize[0], 16) ||
tmp_frame->height != FFALIGN(dst->height, 16)) {
@@ -1728,8 +1709,30 @@ static int qsv_transfer_data_from(AVHWFramesContext
*ctx, AVFrame *dst,
return 0;
}
-static int qsv_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
-const AVFrame *src)
+static int qsv_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
+ const AVFrame *src)
+{
+QSVFramesContext *s = ctx->hwctx;
+int realigned = 0;
+int ret = 0;
+
+ret = qsv_internal_session_check_init(ctx, 0);
+if (ret < 0)
+return ret;
+
+if (dst->height & 15 || dst->linesize[0] & 15) {
+realigned = 1;
+ff_mutex_lock(>session_lock);
+}
+ret = qsv_transfer_data_from_internal(ctx, dst, src, realigned);
+if (realigned)
+ff_mutex_unlock(>session_lock);
+
+return ret;
+}
+
+static int qsv_transfer_data_to_internal(AVHWFramesContext *ctx, AVFrame *dst,
+ const AVFrame *src, int realigned)
{
QSVFramesContext *s = ctx->hwctx;
mfxFrameSurface1 in = {{ 0 }};
@@ -1742,17 +1745,11 @@ static int qsv_transfer_data_to(AVHWFramesContext *ctx,
AVFrame *dst,
/* make a copy if the input is not padded as libmfx requires */
AVFrame *tmp_frame = >realigned_upload_frame;
const AVFrame *src_frame;
-int realigned = 0;
Re: [FFmpeg-devel] [PATCH 1/6] avcodec/ac3enc: Avoid allocation for windowed_samples
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ac3enc.c | 4
> libavcodec/ac3enc.h | 7 ++-
> libavcodec/ac3enc_template.c | 12 +---
> 3 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
> index 1ba4ba549e..a31b528597 100644
> --- a/libavcodec/ac3enc.c
> +++ b/libavcodec/ac3enc.c
> @@ -2184,7 +2184,6 @@ av_cold int ff_ac3_encode_close(AVCodecContext *avctx)
> AC3EncodeContext *s = avctx->priv_data;
>
> av_freep(>mdct_window);
> -av_freep(>windowed_samples);
> if (s->planar_samples)
> for (ch = 0; ch < s->channels; ch++)
> av_freep(>planar_samples[ch]);
> @@ -2459,9 +2458,6 @@ static av_cold int allocate_buffers(AC3EncodeContext *s)
> int total_coefs= AC3_MAX_COEFS * channel_blocks;
> const unsigned sampletype_size = SAMPLETYPE_SIZE(s);
>
> -if (!(s->windowed_samples = av_malloc(sampletype_size *
> AC3_WINDOW_SIZE)))
> -return AVERROR(ENOMEM);
> -
> if (!FF_ALLOCZ_TYPED_ARRAY(s->planar_samples, s->channels))
> return AVERROR(ENOMEM);
>
> diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
> index 227744d27f..618c952a18 100644
> --- a/libavcodec/ac3enc.h
> +++ b/libavcodec/ac3enc.h
> @@ -30,6 +30,7 @@
>
> #include
>
> +#include "libavutil/mem_internal.h"
> #include "libavutil/opt.h"
> #include "libavutil/tx.h"
>
> @@ -232,7 +233,6 @@ typedef struct AC3EncodeContext {
> int frame_bits; ///< all frame bits except
> exponents and mantissas
> int exponent_bits; ///< number of bits used for
> exponents
>
> -void *windowed_samples;
> uint8_t **planar_samples;
> uint8_t *bap_buffer;
> uint8_t *bap1_buffer;
> @@ -259,6 +259,11 @@ typedef struct AC3EncodeContext {
>
> /* AC-3 vs. E-AC-3 function pointers */
> void (*output_frame_header)(struct AC3EncodeContext *s);
> +
> +union {
> +DECLARE_ALIGNED(32, float,
> windowed_samples_float)[AC3_WINDOW_SIZE];
> +DECLARE_ALIGNED(32, int32_t,
> windowed_samples_fixed)[AC3_WINDOW_SIZE];
> +};
> } AC3EncodeContext;
>
> extern const AVChannelLayout ff_ac3_ch_layouts[19];
> diff --git a/libavcodec/ac3enc_template.c b/libavcodec/ac3enc_template.c
> index b0f9e69ee8..6070e14961 100644
> --- a/libavcodec/ac3enc_template.c
> +++ b/libavcodec/ac3enc_template.c
> @@ -37,6 +37,11 @@
> #include "ac3enc.h"
> #include "eac3enc.h"
>
> +#if AC3ENC_FLOAT
> +#define RENAME(element) element ## _float
> +#else
> +#define RENAME(element) element ## _fixed
> +#endif
>
> /*
> * Apply the MDCT to input samples to generate frequency coefficients.
> @@ -51,15 +56,16 @@ static void apply_mdct(AC3EncodeContext *s)
> for (blk = 0; blk < s->num_blocks; blk++) {
> AC3Block *block = >blocks[blk];
> const SampleType *input_samples =
> (SampleType*)s->planar_samples[ch] + blk * AC3_BLOCK_SIZE;
> +SampleType *windowed_samples = s->RENAME(windowed_samples);
>
> -s->fdsp->vector_fmul(s->windowed_samples, input_samples,
> +s->fdsp->vector_fmul(windowed_samples, input_samples,
> s->mdct_window, AC3_BLOCK_SIZE);
> -s->fdsp->vector_fmul_reverse((SampleType*)s->windowed_samples +
> AC3_BLOCK_SIZE,
> +s->fdsp->vector_fmul_reverse(windowed_samples + AC3_BLOCK_SIZE,
> _samples[AC3_BLOCK_SIZE],
> s->mdct_window, AC3_BLOCK_SIZE);
>
> s->tx_fn(s->tx, block->mdct_coef[ch+1],
> - s->windowed_samples, sizeof(float));
> + windowed_samples, sizeof(*windowed_samples));
> }
> }
> }
Will apply this patchset tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Apr 17, 2024, 16:34 by jamr...@gmail.com: > On 4/17/2024 11:22 AM, Lynne wrote: > >> Apr 17, 2024, 15:58 by mich...@niedermayer.cc: >> >>> Hi all >>> >>> The pace of inovation in FFmpeg has been slowing down. >>> Most work is concentarted nowadays on code refactoring, and adding >>> support for new codecs and formats. >>> >>> Should we >>> * make a list of longer term goals >>> * vote on them >>> * and then together work towards implementing them >>> ? >>> >>> (The idea here is to increase the success of larger efforts >>> than adding codecs and refactoring code) >>> It would then also not be possible for individuals to object >>> to a previously agreed goal. >>> And it would add ideas for which we can try to get funding/grants for >>> >>> (larger scale changes need consensus first that we as a whole want >>> them before we would be able to ask for funding/grants for them) >>> >>> Some ideas and why they would help FFmpeg: >>> >>> * Switch to a plugin architecture >>> (Increase the number of developers willing to contribute and reduce >>> friction as the team and community grows) >>> >> >> Just no. >> > > Can you elaborate on why? The one thing i think would be problematic is > making the AVCodec internals public, which could get in the way of > improvements. > First, we'd have the bad SoC vendors making binary plugins, with no attempts made of using existing standards like V4L2 or Vulkan. Then, we'd have the shit companies making hardware CUDA encoders and decoders life much easier by no longer having to ship patches, point to a git version, plus a binary. We'd have closed-source filters circulating around. Closed-source improved MPEG-TS or HLS demuxers that we haven't had enough power to fix. All of the users of those will send their issues to us. None of the authors will open-source their work. We'd receive zero benefits from any of this. The whole multimedia ecosystem will not benefit from it. License-wise, it would be like we have an MIT license. We'd be bound to keep the ABI stable for what may very well be a very long time, with any breakage creating a Python 3 situation. It's a bad idea. ___ 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] 5 year plan & Inovation
On 4/17/2024 11:22 AM, Lynne wrote: Apr 17, 2024, 15:58 by mich...@niedermayer.cc: Hi all The pace of inovation in FFmpeg has been slowing down. Most work is concentarted nowadays on code refactoring, and adding support for new codecs and formats. Should we * make a list of longer term goals * vote on them * and then together work towards implementing them ? (The idea here is to increase the success of larger efforts than adding codecs and refactoring code) It would then also not be possible for individuals to object to a previously agreed goal. And it would add ideas for which we can try to get funding/grants for (larger scale changes need consensus first that we as a whole want them before we would be able to ask for funding/grants for them) Some ideas and why they would help FFmpeg: * Switch to a plugin architecture (Increase the number of developers willing to contribute and reduce friction as the team and community grows) Just no. Can you elaborate on why? The one thing i think would be problematic is making the AVCodec internals public, which could get in the way of improvements. * ffchat (expand into realtime chat / zoom) this would bring in more users and developers, and we basically have almost Better leave that for others. There's an infinite amount of discord clones already. all parts for it already but some people where against it * client side / in browser support (expand towards webapps, webpages using ffmpeg client side in the browser) bring in more users and developers, and it will be costly for us if we let others take this area as its important and significant Maybe. Some WASM-based converter would be helpful. Though it may put us on fire, as we'd be distributing binaries of our code which may cause issues with "rights holders". * AI / neural network filters and codecs The future seems to be AI based. Future Filters and Codecs will use neural networks. FFmpeg can be at the forefront, developing these These take enormous amounts of compute power to train, vast amounts of good high-quality data, and at the end, you'd have something as lasting as wet paper, because a competitor is literally weeks away, and they beat us with inferior methods by simply having vastly more compute than we do. And we can't ship models. * [your idea here] We keep doing what we're doing. It's what we're good at. ___ 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] avcodec/nvenc: High bit depth encoding for HEVC
On 15/04/2024 16:39, Diego Felix de Souza via ffmpeg-devel wrote:
From: Diego Felix de Souza
Adding 10-bit encoding support for HEVC if the input is 8-bit. In
case of 8-bit input content, NVENC performs an internal CUDA 8 to
10-bit conversion of the input prior to encoding. Currently, only
AV1 supports encoding 8-bit content as 10-bit.
I'm not sure about this one.
Since it's just "SW", or rather CUDA based, conversion, this job could
also be done by scale_cuda, outside of some niche formats it doesn't
support yet.
Which would also allow for more consistent command lines across versions.
Signed-off-by: Diego Felix de Souza
---
libavcodec/nvenc.c | 8
libavcodec/nvenc_hevc.c | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 794174a53f..c302cc7dc4 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext *avctx)
}
ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
-if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
+if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0) {
av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
return AVERROR(ENOSYS);
}
@@ -1421,7 +1421,7 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
}
// force setting profile as main10 if input is 10 bit
-if (IS_10BIT(ctx->data_pix_fmt)) {
+if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
Won't this need guarded behind the NVENC_HAVE_NEW_BIT_DEPTH_API as well?
Or would this also work fine with older headers, by just setting this?
cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
avctx->profile = AV_PROFILE_HEVC_MAIN_10;
}
@@ -1435,8 +1435,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
-hevc->inputBitDepth = hevc->outputBitDepth =
-IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
+hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
NV_ENC_BIT_DEPTH_8;
+hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth)
? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
#else
hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
#endif
diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index b949cb1bd7..02e9c9c8eb 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -183,6 +183,7 @@ static const AVOption options[] = {
{ "fullres", "Two Pass encoding is enabled where first Pass is full
resolution",
0,
AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },0,
0, VE, .unit = "multipass" },
#endif
+{ "highbitdepth", "Enable 10 bit encode for 8 bit
input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
Same question as above, does this always work, even without the new bit
depth API?
If not, it also needs the #ifdef.
#ifdef NVENC_HAVE_LDKFS
{ "ldkfs","Low delay key frame scale; Specifies the Scene Change frame
size increase allowed in case of single frame VBV and CBR",
OFFSET(ldkfs),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UCHAR_MAX, VE },
--
2.34.1
---
NVIDIA GmbH
Wuerselen
Amtsgericht Aachen
HRB 8361
Managing Directors: Rebecca Peters, Donald Robertson, Janet Hall, Ludwig von
Reiche
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
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] 5 year plan & Inovation
Apr 17, 2024, 15:58 by mich...@niedermayer.cc: > Hi all > > The pace of inovation in FFmpeg has been slowing down. > Most work is concentarted nowadays on code refactoring, and adding > support for new codecs and formats. > > Should we > * make a list of longer term goals > * vote on them > * and then together work towards implementing them > ? > > (The idea here is to increase the success of larger efforts > than adding codecs and refactoring code) > It would then also not be possible for individuals to object > to a previously agreed goal. > And it would add ideas for which we can try to get funding/grants for > > (larger scale changes need consensus first that we as a whole want > them before we would be able to ask for funding/grants for them) > > Some ideas and why they would help FFmpeg: > > * Switch to a plugin architecture > (Increase the number of developers willing to contribute and reduce > friction as the team and community grows) > Just no. > * ffchat > (expand into realtime chat / zoom) this would > bring in more users and developers, and we basically have almost > Better leave that for others. There's an infinite amount of discord clones already. > all parts for it already but some people where against it > * client side / in browser support > (expand towards webapps, webpages using ffmpeg client side in the browser) > bring in more users and developers, and it will be costly for us > if we let others take this area as its important and significant > Maybe. Some WASM-based converter would be helpful. Though it may put us on fire, as we'd be distributing binaries of our code which may cause issues with "rights holders". > * AI / neural network filters and codecs > The future seems to be AI based. Future Filters and Codecs will use > neural networks. FFmpeg can be at the forefront, developing these > These take enormous amounts of compute power to train, vast amounts of good high-quality data, and at the end, you'd have something as lasting as wet paper, because a competitor is literally weeks away, and they beat us with inferior methods by simply having vastly more compute than we do. > * [your idea here] > We keep doing what we're doing. It's what we're good at. ___ 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] [RFC] 5 year plan & Inovation
Hi all The pace of inovation in FFmpeg has been slowing down. Most work is concentarted nowadays on code refactoring, and adding support for new codecs and formats. Should we * make a list of longer term goals * vote on them * and then together work towards implementing them ? (The idea here is to increase the success of larger efforts than adding codecs and refactoring code) It would then also not be possible for individuals to object to a previously agreed goal. And it would add ideas for which we can try to get funding/grants for (larger scale changes need consensus first that we as a whole want them before we would be able to ask for funding/grants for them) Some ideas and why they would help FFmpeg: * Switch to a plugin architecture (Increase the number of developers willing to contribute and reduce friction as the team and community grows) * ffchat (expand into realtime chat / zoom) this would bring in more users and developers, and we basically have almost all parts for it already but some people where against it * client side / in browser support (expand towards webapps, webpages using ffmpeg client side in the browser) bring in more users and developers, and it will be costly for us if we let others take this area as its important and significant * AI / neural network filters and codecs The future seems to be AI based. Future Filters and Codecs will use neural networks. FFmpeg can be at the forefront, developing these * [your idea here] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. 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] FFmpeg table at NAB
On 4/17/2024 2:54 PM, James Almer wrote: > But why were there GPAC people at the FFmpeg booth? > And i don't think a single person should represent the project in these > conferences to begin with. All this should go through the GA, including > who funds it and how. That is a good question, and one that I asked weeks ago (as per link). - 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 table at NAB
On 4/17/2024 10:49 AM, Derek Buitenhuis wrote: On 4/17/2024 12:21 AM, Devin Heitmueller wrote: Hello all, [...] Yeah, this is exactly what I was screaming into the void about for literal months, no literally 0 response. Look for the thread: [FFmpeg-devel] FFmpeg at NAB 2024 It spans months. My last mail is particularily relevant to your experience: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/324816.html I assume Thilo was hung over, and thus not on the booth. But why were there GPAC people at the FFmpeg booth? And i don't think a single person should represent the project in these conferences to begin with. All this should go through the GA, including who funds it and how. It is a disgrace. - 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 table at NAB
On 4/17/2024 12:21 AM, Devin Heitmueller wrote: > Hello all, [...] Yeah, this is exactly what I was screaming into the void about for literal months, no literally 0 response. Look for the thread: [FFmpeg-devel] FFmpeg at NAB 2024 It spans months. My last mail is particularily relevant to your experience: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/324816.html I assume Thilo was hung over, and thus not on the booth. It is a disgrace. - 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] [PATCH v2 1/3] avcodec/x86/vvc/vvcdsp_init: add put prototypes
Hi Jianhua,
thank you for the patches.
could you add a log for each commit to explain why we need this commit?
On Tue, Apr 16, 2024 at 1:36 AM wrote:
> From: Wu Jianhua
>
> Signed-off-by: Wu Jianhua
> ---
> libavcodec/x86/vvc/vvcdsp_init.c | 35 +++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/x86/vvc/vvcdsp_init.c
> b/libavcodec/x86/vvc/vvcdsp_init.c
> index 23a3172c45..d9203f4d5f 100644
> --- a/libavcodec/x86/vvc/vvcdsp_init.c
> +++ b/libavcodec/x86/vvc/vvcdsp_init.c
> @@ -30,9 +30,42 @@
> #include "libavcodec/vvc/dsp.h"
> #include "libavcodec/x86/h26x/h2656dsp.h"
>
> +#define PUT_PROTOTYPE(name, depth, opt) \
> +void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const
> uint8_t *src, ptrdiff_t srcstride, int height, const int8_t *hf, const
> int8_t *vf, int width);
> +
> +#define PUT_PROTOTYPES(name, bitd, opt) \
> +PUT_PROTOTYPE(name##2, bitd, opt) \
> +PUT_PROTOTYPE(name##4, bitd, opt) \
> +PUT_PROTOTYPE(name##8, bitd, opt) \
> +PUT_PROTOTYPE(name##12, bitd, opt) \
> +PUT_PROTOTYPE(name##16, bitd, opt) \
> +PUT_PROTOTYPE(name##24, bitd, opt) \
> +PUT_PROTOTYPE(name##32, bitd, opt) \
> +PUT_PROTOTYPE(name##48, bitd, opt) \
> +PUT_PROTOTYPE(name##64, bitd, opt) \
> +PUT_PROTOTYPE(name##128, bitd, opt)
> +
> +#define PUT_BPC_PROTOTYPES(name, opt) \
> +PUT_PROTOTYPES(name, 8, opt) \
> +PUT_PROTOTYPES(name, 10, opt) \
> +PUT_PROTOTYPES(name, 12, opt)
> +
> +#define PUT_TAP_PROTOTYPES(n, opt) \
> +PUT_BPC_PROTOTYPES(n##tap_h, opt) \
> +PUT_BPC_PROTOTYPES(n##tap_v, opt) \
> +PUT_BPC_PROTOTYPES(n##tap_hv, opt)
> +
> +PUT_BPC_PROTOTYPES(pixels, sse4)
> +PUT_BPC_PROTOTYPES(pixels, avx2)
> +
> +PUT_TAP_PROTOTYPES(4, sse4)
> +PUT_TAP_PROTOTYPES(8, sse4)
> +PUT_TAP_PROTOTYPES(4, avx2)
> +PUT_TAP_PROTOTYPES(8, avx2)
> +
> #if ARCH_X86_64
> #define FW_PUT(name, depth, opt) \
> -static void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst,
> const uint8_t *src, ptrdiff_t srcstride, \
> +void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const
> uint8_t *src, ptrdiff_t srcstride,\
> int height, const int8_t
> *hf, const int8_t *vf, int width)\
> {
> \
> ff_h2656_put_## name ## _ ## depth ## _##opt(dst, 2 * MAX_PB_SIZE,
> src, srcstride, height, hf, vf, width); \
> --
> 2.44.0.windows.1
>
> ___
> 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] Remove .travis.yml
Apr 17, 2024, 13:46 by mar...@martin.st: > Travis is no longer relevant for attempting to run CI jobs in our > setup. > --- > .travis.yml | 30 -- > 1 file changed, 30 deletions(-) > delete mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > deleted file mode 100644 > index 784b7bdf73..00 > --- a/.travis.yml > +++ /dev/null > @@ -1,30 +0,0 @@ > -language: c > -sudo: false > -os: > - - linux > - - osx > -addons: > - apt: > -packages: > - - nasm > - - diffutils > -compiler: > - - clang > - - gcc > -matrix: > -exclude: > -- os: osx > - compiler: gcc > -cache: > - directories: > -- ffmpeg-samples > -before_install: > - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update; fi > -install: > - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew install nasm; fi > -script: > - - mkdir -p ffmpeg-samples > - - ./configure --samples=ffmpeg-samples --cc=$CC > - - make -j 8 > - - make fate-rsync > - - make check -j 8 > -- > 2.39.3 (Apple Git-146) > lgtm ___ 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] avformat/ivfenc: remove unused var
On 2024-04-17 05:25 pm, James Almer wrote:
On 4/17/2024 8:31 AM, Gyan Doshi wrote:
sum_delta_pts is unused since 3b358f151d
---
libavformat/ivfenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 09782eecd6..9feaea3516 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -24,7 +24,7 @@
typedef struct IVFEncContext {
unsigned frame_cnt;
- uint64_t last_pts, sum_delta_pts, last_pkt_duration;
+ uint64_t last_pts, last_pkt_duration;
} IVFEncContext;
static int ivf_init(AVFormatContext *s)
@@ -80,8 +80,6 @@ static int ivf_write_packet(AVFormatContext *s,
AVPacket *pkt)
avio_wl32(pb, pkt->size);
avio_wl64(pb, pkt->pts);
avio_write(pb, pkt->data, pkt->size);
- if (ctx->frame_cnt)
- ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
ctx->last_pkt_duration = pkt->duration;
ctx->frame_cnt++;
ctx->last_pts = pkt->pts;
Ok.
Thanks. Pushed as 38c322681e9715b288172eaed1e90205aa46e969
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Remove .travis.yml
On 17 Apr 2024, at 13:45, Martin Storsjö wrote: > Travis is no longer relevant for attempting to run CI jobs in our > setup. LGTM > --- > .travis.yml | 30 -- > 1 file changed, 30 deletions(-) > delete mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > deleted file mode 100644 > index 784b7bdf73..00 > --- a/.travis.yml > +++ /dev/null > @@ -1,30 +0,0 @@ > -language: c > -sudo: false > -os: > - - linux > - - osx > -addons: > - apt: > -packages: > - - nasm > - - diffutils > -compiler: > - - clang > - - gcc > -matrix: > -exclude: > -- os: osx > - compiler: gcc > -cache: > - directories: > -- ffmpeg-samples > -before_install: > - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update; fi > -install: > - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew install nasm; fi > -script: > - - mkdir -p ffmpeg-samples > - - ./configure --samples=ffmpeg-samples --cc=$CC > - - make -j 8 > - - make fate-rsync > - - make check -j 8 > -- > 2.39.3 (Apple Git-146) > > ___ > 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 v1 1/6] avcodec/evc: Set the AV_FRAME_FLAG_KEY flag for a decoded frame when the decoded packet contains a keyframe
On 4/17/2024 2:22 AM, Dawid Kozinski wrote:
Signed-off-by: Dawid Kozinski
---
libavcodec/libxevd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/libxevd.c b/libavcodec/libxevd.c
index c6c7327e65..e864bd5200 100644
--- a/libavcodec/libxevd.c
+++ b/libavcodec/libxevd.c
@@ -391,6 +391,11 @@ static int libxevd_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
if (stat.read != nalu_size)
av_log(avctx, AV_LOG_INFO, "Different reading of bitstream (in:%d,
read:%d)\n,", nalu_size, stat.read);
+if (stat.stype == XEVD_ST_I) {
+frame->pict_type = AV_PICTURE_TYPE_I;
+frame->flags |= AV_FRAME_FLAG_KEY;
+}
Shouldn't this be inside the stat.fnum >= 0 block below?
+
// stat.fnum - has negative value if the decoded data is not frame
if (stat.fnum >= 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 v3 00/13] avcodec: add Dolby Vision encoding
On Fri, 12 Apr 2024 13:35:14 +0200 Niklas Haas wrote: > Changes since v2: > - Split up dovi_rpu.c into dovi_rpudec.c and dovi_rpueenc. > - Added missing dependencies of encoders onto dovi_rpueenc > - Clarified and documented semantics of guess_profile() > - Changed misleading commit message > > ___ > 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". Ping for review ___ 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] Remove .travis.yml
Travis is no longer relevant for attempting to run CI jobs in our setup. --- .travis.yml | 30 -- 1 file changed, 30 deletions(-) delete mode 100644 .travis.yml diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 784b7bdf73..00 --- a/.travis.yml +++ /dev/null @@ -1,30 +0,0 @@ -language: c -sudo: false -os: - - linux - - osx -addons: - apt: -packages: - - nasm - - diffutils -compiler: - - clang - - gcc -matrix: -exclude: -- os: osx - compiler: gcc -cache: - directories: -- ffmpeg-samples -before_install: - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update; fi -install: - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew install nasm; fi -script: - - mkdir -p ffmpeg-samples - - ./configure --samples=ffmpeg-samples --cc=$CC - - make -j 8 - - make fate-rsync - - make check -j 8 -- 2.39.3 (Apple Git-146) ___ 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] avformat/ivfenc: remove unused var
sum_delta_pts is unused since 3b358f151d
---
libavformat/ivfenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 09782eecd6..9feaea3516 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -24,7 +24,7 @@
typedef struct IVFEncContext {
unsigned frame_cnt;
-uint64_t last_pts, sum_delta_pts, last_pkt_duration;
+uint64_t last_pts, last_pkt_duration;
} IVFEncContext;
static int ivf_init(AVFormatContext *s)
@@ -80,8 +80,6 @@ static int ivf_write_packet(AVFormatContext *s, AVPacket *pkt)
avio_wl32(pb, pkt->size);
avio_wl64(pb, pkt->pts);
avio_write(pb, pkt->data, pkt->size);
-if (ctx->frame_cnt)
-ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
ctx->last_pkt_duration = pkt->duration;
ctx->frame_cnt++;
ctx->last_pts = pkt->pts;
--
2.44.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 03/10] lavc/hevcdec: allocate local_ctx as array of structs rather than pointers
Anton Khirnov: > It is more efficient and easier to manage. > --- Allocating structures used by slice contexts jointly has the potential downside of false sharing if the structures are not sufficiently aligned/padded. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 2/6] avformat/nut: Added EVC codec tag to the list of supported codec_id-codec_tag pairs for NUT muxer
Dawid Kozinski:
> Signed-off-by: Dawid Kozinski
> ---
> libavformat/nut.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/nut.c b/libavformat/nut.c
> index 9692336ece..8c536719b1 100644
> --- a/libavformat/nut.c
> +++ b/libavformat/nut.c
> @@ -47,6 +47,7 @@ const AVCodecTag ff_nut_video_tags[] = {
> { AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
> { AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
> { AV_CODEC_ID_CPIA, MKTAG('C', 'P', 'i', 'A') },
> +{ AV_CODEC_ID_EVC, MKTAG('e', 'v', 'c', '1') },
> { AV_CODEC_ID_RAWVIDEO, MKTAG('R', 'G', 'B', 15 ) },
> { AV_CODEC_ID_RAWVIDEO, MKTAG('B', 'G', 'R', 15 ) },
> { AV_CODEC_ID_RAWVIDEO, MKTAG('R', 'G', 'B', 16 ) },
The nut muxer also uses the riff/avi tags, so this patch is unnecessary
with patch 4/6.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavc/aarch64/fdct: add neon-optimized fdct for aarch64
On Wed, 17 Apr 2024, Ramiro Polla wrote: The code is imported from libjpeg-turbo-3.0.1. The neon registers used have been changed to avoid modifying v8-v15. --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/fdct.h | 26 ++ libavcodec/aarch64/fdctdsp_init_aarch64.c | 39 +++ libavcodec/aarch64/fdctdsp_neon.S | 368 ++ libavcodec/avcodec.h | 1 + libavcodec/fdctdsp.c | 4 +- libavcodec/fdctdsp.h | 2 + libavcodec/options_table.h| 1 + libavcodec/tests/aarch64/dct.c| 2 + tests/checkasm/Makefile | 1 + tests/checkasm/checkasm.c | 3 + tests/checkasm/checkasm.h | 1 + tests/checkasm/fdctdsp.c | 68 tests/fate/checkasm.mak | 1 + 14 files changed, 518 insertions(+), 1 deletion(-) create mode 100644 libavcodec/aarch64/fdct.h create mode 100644 libavcodec/aarch64/fdctdsp_init_aarch64.c create mode 100644 libavcodec/aarch64/fdctdsp_neon.S create mode 100644 tests/checkasm/fdctdsp.c Overall LGTM, thanks! You may wish to split adding the checkasm test to a separate patch, before adding the new implementation. I was surprised by the header libavcodec/aarch64/fdct.h which seemed redundant on first glance, but I see that this is needed for the dct test executable in libavcodec/tests/aarch64/dct.c, so I guess this is reasonable. (In most other asm implementations, we just declare the functions at the start of the *_init.c files.) // 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] [PATCH] libavutil/hwcontext_qsv: Make qsv hardware transfers thread safe
On Sa, 2024-04-13 at 07:57 -0500, Mark Samuelson wrote:
> The QSV hardware context currently uses pthreads to lock initilization,
> which is not available on windows builds. Instead, use the AVMutex
> object. Also lock uses of the realigned_upload_frame and
> realigned_download_frame objects, so multiple threads do not attempt
> to write to them at the same time.
> ---
> libavutil/hwcontext_qsv.c | 75 ---
> 1 file changed, 46 insertions(+), 29 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index c7c7878644..92bab134e4 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -23,10 +23,7 @@
> #include
>
> #include "config.h"
> -
> -#if HAVE_PTHREADS
> -#include
> -#endif
> +#include "thread.h"
>
> #define COBJMACROS
> #if CONFIG_VAAPI
> @@ -98,9 +95,7 @@ typedef struct QSVFramesContext {
> atomic_int session_download_init;
> mfxSession session_upload;
> atomic_int session_upload_init;
> -#if HAVE_PTHREADS
> - pthread_mutex_t session_lock;
> -#endif
> + AVMutex session_lock;
>
> AVBufferRef *child_frames_ref;
> mfxFrameSurface1 *surfaces_internal;
> @@ -354,9 +349,7 @@ static void qsv_frames_uninit(AVHWFramesContext *ctx)
> s->session_upload = NULL;
> s->session_upload_init = 0;
>
> -#if HAVE_PTHREADS
> - pthread_mutex_destroy(>session_lock);
> -#endif
> + ff_mutex_destroy(>session_lock);
>
> av_freep(>mem_ids);
> #if QSV_HAVE_OPAQUE
> @@ -1302,9 +1295,7 @@ static int qsv_frames_init(AVHWFramesContext *ctx)
> s->session_download_init = 0;
> s->session_upload_init = 0;
>
> -#if HAVE_PTHREADS
> - pthread_mutex_init(>session_lock, NULL);
> -#endif
> + ff_mutex_init(>session_lock, NULL);
>
> return 0;
> }
> @@ -1629,24 +1620,20 @@ static int
> qsv_internal_session_check_init(AVHWFramesContext *ctx, int upload)
> if (atomic_load(inited))
> return 0;
>
> -#if HAVE_PTHREADS
> - pthread_mutex_lock(>session_lock);
> -#endif
> + ff_mutex_lock(>session_lock);
ff_mutex_lock is called twice in the same thread when realigned is 1, the
current thread is blocked. You may run the command below to reproduce this
issue:
./ffmpeg -init_hw_device qsv -f lavfi -i testsrc=size=352x280,format=nv12 -vf
"hwupload=extra_hw_frames=16" -f null -
>
> if (!atomic_load(inited)) {
> ret = qsv_init_internal_session(ctx, session, upload);
> atomic_store(inited, 1);
> }
>
> -#if HAVE_PTHREADS
> - pthread_mutex_unlock(>session_lock);
> -#endif
> + ff_mutex_unlock(>session_lock);
>
> return ret;
> }
>
> -static int qsv_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
> - const AVFrame *src)
> +static int qsv_transfer_data_from_internal(AVHWFramesContext *ctx, AVFrame
> *dst,
> + const AVFrame *src, int realigned)
> {
> QSVFramesContext *s = ctx->hwctx;
> mfxFrameSurface1 out = {{ 0 }};
> @@ -1658,7 +1645,6 @@ static int qsv_transfer_data_from(AVHWFramesContext
> *ctx, AVFrame *dst,
> /* download to temp frame if the output is not padded as libmfx requires
> */
> AVFrame *tmp_frame = >realigned_download_frame;
> AVFrame *dst_frame;
> - int realigned = 0;
>
> ret = qsv_internal_session_check_init(ctx, 0);
> if (ret < 0)
> @@ -1667,8 +1653,7 @@ static int qsv_transfer_data_from(AVHWFramesContext
> *ctx, AVFrame *dst,
> /* According to MSDK spec for mfxframeinfo, "Width must be a multiple of
> 16.
> * Height must be a multiple of 16 for progressive frame sequence and a
> * multiple of 32 otherwise.", so allign all frames to 16 before
> downloading. */
> - if (dst->height & 15 || dst->linesize[0] & 15) {
> - realigned = 1;
> + if (realigned) {
> if (tmp_frame->format != dst->format ||
> tmp_frame->width != FFALIGN(dst->linesize[0], 16) ||
> tmp_frame->height != FFALIGN(dst->height, 16)) {
> @@ -1728,8 +1713,25 @@ static int qsv_transfer_data_from(AVHWFramesContext
> *ctx, AVFrame *dst,
> return 0;
> }
>
> -static int qsv_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
> - const AVFrame *src)
> +static int qsv_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
> + const AVFrame *src)
> +{
> + QSVFramesContext *s = ctx->hwctx;
Please do not use tab for indentation.
> + int realigned = 0;
> + if (dst->height & 15 || dst->linesize[0] & 15)
> + {
{ and if statement should be on the same line to keep the consistent code style.
> + realigned = 1;
> + ff_mutex_lock(>session_lock);
> + }
> + int ret = qsv_transfer_data_from_internal(ctx, dst, src, realigned);
Please do not mix declaration and code.
> + if (realigned)
> + ff_mutex_unlock(>session_lock);
> +
> + return
Re: [FFmpeg-devel] FFmpeg table at NAB
On Wed, Apr 17, 2024 at 1:21 AM Devin Heitmueller < devin.heitmuel...@ltnglobal.com> wrote: > Hello all, > > I wasn't looking to start trouble, but I didn't see any discussion of > this on the mailing list so wanted to bring it to the developer > community's attention. > > I attended the NAB conference and went by the "ffmpeg" booth on > Sunday. What I found was a single table with the official ffmpeg > banner hanging right next to a banner for the GPAC project, and two > salespeople from GPAC handing out marketing literature and trying to > educate me on why I should use their framework for my next project. > > I'm not saying that GPAC shouldn't be able to have a table at the > conference, but it feels pretty misleading to have an "ffmpeg" booth > listed in the conference materials, with a table prominently > displaying the ffmpeg logo, with zero people from ffmpeg and people > pushing users to use an alternative framework that some might actually > considered to be a competitor to ffmpeg. > > Agreed, forget about FFmpeg. Use Librempeg. > Devin > > -- > Devin Heitmueller, Senior Software Engineer > LTN Global Communications > o: +1 (301) 363-1001 > w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com > ___ > 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".
