Re: [FFmpeg-devel] [PATCH v4 1/3] lavc/libaribcaption.c: FIX: change all `boot` option var to `int`
On Tue, Oct 17, 2023 at 4:14 PM TADANO Tokumei wrote: > > This patch fixes a bug in curret version. > > On some environments, a `bool` variable is small space than `int`. > If a `bool` option was specified by command line, following > variables would be filled and may be destroyed by av_opt_copy(). > > This patch change all the `bool` option variables in > `ARIBCaptionContext` to `int`. > > Signed-off-by: TADANO Tokumei Change LGTM. I changed the commit message to more match our guide lines (no ".c" at the end, rephrased the commit message) in https://github.com/jeeb/ffmpeg/commits/aribcaption_msz_patches_v3 . Just tell me if you're OK with this and I'll pull it in. Jan ___ 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 2/3] lavc/libaribcaption.c: add MSZ characters related options
On Tue, Oct 17, 2023 at 4:14 PM TADANO Tokumei wrote: > > This patch add MSZ (Middle Size; half width) characters related > options. > > * add `-replace_msz_japanese` option introduced in version 1.0.1 > of libaribcaption. > * add `-replace_msz_glyph` option introduced in version 1.1.0 > of libaribcaption. > > If specified fonts contain half-width glyphs (e.g., BIZ UDGothic), > it make better rendering with `-replace_msz_ascii false` and > `-replace_msz_japanese false` option for bitmap sub_type. > > Signed-off-by: TADANO Tokumei Change-wise LGTM. I reworked the commit message (starting with the removal of ".c" at the end), and hopefully I understood correctly what you were trying to mean with what I expect you were meaning with regards to the latter option. The adjusted commits are visible in https://github.com/jeeb/ffmpeg/commits/aribcaption_msz_patches_v3 . Otherwise the only thing I adjusted was diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c index 2a058a4992..e87f303aa8 100644 --- a/libavcodec/libaribcaption.c +++ b/libavcodec/libaribcaption.c @@ -1008,7 +1008,7 @@ static int aribcaption_init(AVCodecContext *avctx) aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder, ctx->replace_msz_ascii); aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder, - ctx->replace_msz_japanese); + ctx->replace_msz_japanese); /* Similar behavior as ffmpeg tool to set canvas size */ if (ctx->canvas_width > 0 && ctx->canvas_height > 0 && as there was a mismatching offset. If this is fine by you, I'll pull this in. Jan ___ 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 3/3] lavc/libaribcaption.c: rename `-replace_fullwidth_ascii` option
On Tue, Oct 17, 2023 at 4:14 PM TADANO Tokumei wrote: > > This patch renames `-replace_fullwidth_ascii` option to > `-replace_msz_ascii` to clarify option meaning. > > Signed-off-by: TADANO Tokumei Asked around and James seemed to be OK with just replacing this option as this is a "niche" module and since it had not yet been in any release. Thus LGTM change-wise. Same things as with the rest of the set, did adjustments to the commit message. If you're fine with it, I'll pull these in. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil/hwcontext_vulkan: cuda doesn't belong to valid_sw_formats
> 在 2023年10月29日，下午2:12，Lynne 写道： > > Oct 27, 2023, 09:37 by quinkbl...@foxmail.com: > >> From: Zhao Zhili >> >> Move it to transfer_get_formats. >> > > Could you backport this, along with the other two patches to the v6.1 branch > too? Of course, done. > Thanks > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
Quoting James Almer (2023-10-24 01:23:44)
> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> "Channel
> Configuration 14", and it being the first layout with top layer channels, it's
> best to use a different scheme to properly convey the presence and amount of
> said
> channels.
> The new name will also be a better fit for the additions in the following
> commits.
>
> Signed-off-by: James Almer
> ---
> doc/utils.texi| 2 +-
> libavutil/channel_layout.c| 2 +-
> libavutil/channel_layout.h| 8 ++--
> tests/ref/fate/channel_layout | 2 +-
> 4 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/doc/utils.texi b/doc/utils.texi
> index 8e8bfa76d4..1388e5dabe 100644
> --- a/doc/utils.texi
> +++ b/doc/utils.texi
> @@ -713,7 +713,7 @@ FL+FR+FC+LFE+BL+BR+SL+SR
> FL+FR+FC+LFE+BL+BR+FLC+FRC
> @item 7.1(wide-side)
> FL+FR+FC+LFE+FLC+FRC+SL+SR
> -@item 7.1(top)
> +@item 5.1.2
> FL+FR+FC+LFE+BL+BR+TFL+TFR
> @item octagonal
> FL+FR+FC+BL+BR+BC+SL+SR
> diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
> index 9b581ae6b3..b259e75d37 100644
> --- a/libavutil/channel_layout.c
> +++ b/libavutil/channel_layout.c
> @@ -200,7 +200,7 @@ static const struct channel_layout_name
> channel_layout_map[] = {
> { "7.1",AV_CHANNEL_LAYOUT_7POINT1 },
> { "7.1(wide)", AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK },
> { "7.1(wide-side)", AV_CHANNEL_LAYOUT_7POINT1_WIDE},
> -{ "7.1(top)", AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK},
Doesn't this need deprecation?
--
Anton Khirnov
___
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] Release 6.1
Michael Niedermayer (12023-10-28): > It was just that jb told me > "6.1 opportunity is gone. Unsubstantiated opinion, let us ignore it. Regards, -- Nicolas George 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] [ANNOUNCE] upcoming GA vote
Hi all, updating the answers according to received comments: vote question (unchanged): How do we update the list of active members of the general assembly? Available answers: * twice a year (1st Jan & 1st July, 0:00 UTC); as an exception, the list will also be updated immediately after this vote (suggested at VDD, added time and the exceptional update clause) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each 1st Jan and 1st July, 0:00 UTC; as an exception, the list will also be updated immediately after this vote (suggested by Michael on the ML, clarified date and time, added the exceptional update clause) If nobody has significant objections, we will go with the above for the actual vote tomorrow. Cheers, -- Anton Khirnov ___ 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-28): > I did proper analysis already. Pushed. Thanks for the precedent, I will gladly do the same to you in the future. -- Nicolas George 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] [ANNOUNCE] upcoming GA vote
Hi, To test the voting beforehand this time, I created a test vote with a fake-GA member list. All of the following people should have received a corresponding mail. If you are part of this list, but did not receive an email, check your spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you didn't get the mail. The list is as follows: [...] the language issue had been resolved and no further complains arrived. Thus I ended the testvote and we should be good to go. -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 2/2] fftools/ffplay: add hwaccel decoding support
On Sun, 29 Oct 2023 10:31:17 +0800 Zhao Zhili wrote: > libplacebo doesn't support that: > > // Creates a new vulkan device based on the given parameters and initializes > // a new GPU. This function will internally initialize a VkDevice. There is > // currently no way to share a vulkan device with the caller. If `params` is > // left as NULL, it defaults to &pl_vulkan_default_params. > // > // Thread-safety: Safe > PL_API pl_vulkan pl_vulkan_create(pl_log log, const struct > pl_vulkan_params *params); Pretty sure this comment is ancient and wrong/misleading, I removed it in master. ___ 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] avformat/hls: use av_strlcopy instead of strncpy
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..39440176c9 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -543,8 +543,8 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
int langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
-sizeof(rend->language) - langlen - 2);
+av_strlcpy(rend->language + langlen + 1, info->assoc_language,
+sizeof(rend->language) - langlen - 1);
}
}
--
2.42.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 v2] avformat/hls: use av_strlcopy instead of strncpy
On 10/29/23 08:47, Leo Izen wrote: Avoids a -Wstringop-truncation warning by using av_strlcopy instead of strncpy. Changes from v1: - changed the length attribute, so now it has similar semantics to earlier. This patch has the same semantics with regard to the null-termination and the length of the string. However, it avoids a compiler warning because the compiler thinks strncpy is unsafe. - Leo Izen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/pixblockdsp: remove R-V V get_pixels_16
In the aligned case, the existing RVI assembler is actually much
faster. In the unaligned case, there is nothing much to gain over C.
---
libavcodec/riscv/pixblockdsp_init.c | 7 +--
libavcodec/riscv/pixblockdsp_rvv.S | 7 ---
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/libavcodec/riscv/pixblockdsp_init.c
b/libavcodec/riscv/pixblockdsp_init.c
index 7d259a032f..6b1efd16f8 100644
--- a/libavcodec/riscv/pixblockdsp_init.c
+++ b/libavcodec/riscv/pixblockdsp_init.c
@@ -36,8 +36,6 @@ void ff_get_pixels_8_rvv(int16_t *block, const uint8_t
*pixels,
ptrdiff_t stride);
void ff_get_pixels_unaligned_8_rvv(int16_t *block, const uint8_t *pixels,
ptrdiff_t stride);
-void ff_get_pixels_unaligned_16_rvv(int16_t *block, const uint8_t *pixels,
-ptrdiff_t stride);
void ff_diff_pixels_rvv(int16_t *block, const uint8_t *s1,
const uint8_t *s2, ptrdiff_t stride);
void ff_diff_pixels_unaligned_rvv(int16_t *block, const uint8_t *s1,
@@ -58,10 +56,7 @@ av_cold void ff_pixblockdsp_init_riscv(PixblockDSPContext *c,
#if HAVE_RVV
if ((cpu_flags & AV_CPU_FLAG_RVV_I32) && ff_get_rv_vlenb() >= 16) {
-if (high_bit_depth) {
-c->get_pixels = ff_get_pixels_unaligned_16_rvv;
-c->get_pixels_unaligned = ff_get_pixels_unaligned_16_rvv;
-} else {
+if (!high_bit_depth) {
c->get_pixels = ff_get_pixels_unaligned_8_rvv;
c->get_pixels_unaligned = ff_get_pixels_unaligned_8_rvv;
}
diff --git a/libavcodec/riscv/pixblockdsp_rvv.S
b/libavcodec/riscv/pixblockdsp_rvv.S
index 80c7415acf..7e35fc5b46 100644
--- a/libavcodec/riscv/pixblockdsp_rvv.S
+++ b/libavcodec/riscv/pixblockdsp_rvv.S
@@ -45,13 +45,6 @@ func ff_get_pixels_unaligned_8_rvv, zve32x
ret
endfunc
-func ff_get_pixels_unaligned_16_rvv, zve32x
-vsetivli zero, 8, e16, m1, ta, ma
-vlsseg8e16.v v0, (a1), a2
-vsseg8e16.v v0, (a0)
-ret
-endfunc
-
func ff_diff_pixels_rvv, zve64x
vsetivli zero, 8, e8, mf2, ta, ma
li t0, 8 * 8
--
2.42.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] avutil/video_enc_params: fix doxy for av_video_enc_params_block()
Signed-off-by: James Almer
---
libavutil/video_enc_params.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
index fc0c3bc1a5..62265a5c06 100644
--- a/libavutil/video_enc_params.h
+++ b/libavutil/video_enc_params.h
@@ -136,8 +136,8 @@ typedef struct AVVideoBlockParams {
int32_t delta_qp;
} AVVideoBlockParams;
-/*
- * Get the block at the specified {@code idx}. Must be between 0 and nb_blocks.
+/**
+ * Get the block at the specified {@code idx}. Must be between 0 and nb_blocks
- 1.
*/
static av_always_inline AVVideoBlockParams*
av_video_enc_params_block(AVVideoEncParams *par, unsigned int idx)
--
2.42.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] Release 6.1
On Sun, 29 Oct 2023, at 10:30, Nicolas George wrote: > Michael Niedermayer (12023-10-28): >> It was just that jb told me >> "6.1 opportunity is gone. > > Unsubstantiated opinion, let us ignore it. Not like your opinions that are always substantiated... Except I explain many times why the opportunity has passed for 6.1, but you, once again, don't listen, or refuse to be on the means where we discuss. Again, a personal attack, from you. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > > Unsubstantiated opinion, let us ignore it. > Again, a personal attack, from you. YOU are not an OPINION, so, no, this is not a personal attack, this is a lie. -- Nicolas George 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] financial sustainability Plan A (SPI)
Hi, Le 28 octobre 2023 21:01:57 GMT+03:00, Michael Niedermayer a écrit : >On Sat, Oct 28, 2023 at 07:21:03PM +0200, Michael Niedermayer wrote: >> Hi ronald >> >> On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote: >> > Hi Thilo, >> > >> > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel < >> > ffmpeg-devel@ffmpeg.org> wrote: >> > >> > > What this is about, is to set up a way to properly spend the SPI money >> > > aside >> > > from travel & hw. Why we should not do it because some companies >> > > beurocracy, I >> > > cannot see. >> > > >> > >> > I sincerely don't think the above description is what Kieran meant when he >> > talked about sustainability at Demuxed, which this thread seems to be a >> > response to. >> >> a quick reply here. I have not watched kierans presentation from demuxed yet. >> So theres absolutly no chance anything i wrote till now can be a respone to >> it. > >some more words about what the intend of this plan was, again not a respone >to any presentation of anyone else > >Donations from people vs companies: both really. I think Ronald's point is that you need to pick one, and clarify which it is, because as Ronald explained, it's unlikely that a *good* plan could address both (conversely a plan that tries to address both is probably poor and flawed). In other words, if you want to cover both cases, you need two separate plans. And unfortunately, I do believe that Ronald is correct in pointing out that big companies will want oversight in exchange for money. This is very much counter to the current project setup, which (depending whom you ask) is governed by the GA, or by Fabrice Bellard through his delegates. This is not to say that these corporate wishes should or should not be accomodated. It is just an observation of those wishes. >Peoples donations would only matter if we can increase awareness of people >using FFmpeg. We have over a billion users but they dont know it. >if each user gives us 1cent per year our sustainability is solved. >So driving awareness alone would solve this already, even if only 0.1% >of users would donate 10$ per year that would do. How do you plan to gain visibility from those billion users? Call me pessimistic but this has been a known problem for 20+ years, and I have yet to glimpse a credible solution. But again, if somebody has those incredibly cool feature projects in their head, lets hear them first, and then plan accordingly. Otherwise, we.are just debating hypotheticals and that will go nowhere. >companies? >will any company donate 500k$ per year into SPI? Most companies will be >very hesitatnt before seeing us using funds effectively from SPI. >Thats why we need to show this Err no. Companies will want some control/oversight/whatever you call want to call it. They are also probably interested in different features that end users. Mozilla didn't get their big corporate funding for just making cool stuff. It was compensation for provided services such as choice of default search engine. Similarly LF gets funding in exchange for influence in Linux kernel development and other LF activities. But that sense, you did pick one side: users (and companies donating on behalf of user emloyees), as opposed to big corporations. Then let's hear what those cool features are *first*, and adjust the plan accordingly *next*. >And yes many companies will prefer doing it over a company >But some will favor a donation to 501(3) where everything is transparent. > >I cannot understand the hostility that kieran has towards this plan. >And i find his toxicity towards it very troubbling > >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".
Re: [FFmpeg-devel] [RFC] Release 6.1
Am 29.10.23 um 14:51 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 10:30, Nicolas George wrote: Michael Niedermayer (12023-10-28): It was just that jb told me "6.1 opportunity is gone. Unsubstantiated opinion, let us ignore it. Not like your opinions that are always substantiated... Except I explain many times why the opportunity has passed for 6.1, but you, once again, don't listen, or refuse to be on the means where we discuss. Where? I don't see you saying that in this thread. If you said so at VDD, that's not many times. Not being at where you say s.th. does not imply anything and is not an argument. Again, a personal attack, from you. If you find calling your opinion unsubstantiated a personal attack, then why do you reply with the same personal attack? -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] financial sustainability Plan A (SPI)
On Sat, Oct 28, 2023 at 10:17:50PM +0100, Kieran Kunhya wrote: > On Sat, 28 Oct 2023 at 18:21, Michael Niedermayer > wrote: > > > Hi ronald > > > > On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote: > > > Hi Thilo, > > > > > > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel < > > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > What this is about, is to set up a way to properly spend the SPI money > > > > aside > > > > from travel & hw. Why we should not do it because some companies > > > > beurocracy, I > > > > cannot see. > > > > > > > > > > I sincerely don't think the above description is what Kieran meant when > > he > > > talked about sustainability at Demuxed, which this thread seems to be a > > > response to. > > > > a quick reply here. I have not watched kierans presentation from demuxed > > yet. > > So theres absolutly no chance anything i wrote till now can be a respone to > > it. > > > > For the record, I gave the Demuxed lightning talk on Wednesday 25th October > at 1400 PST (2100 UTC). > The first email in this chain was on Thursday 26th October at 1845 EEST > (1545 UTC). We should make a more complete timeline and then do proper statistics to analyze it :) Iam not offended by this, if people want to investigate where similarities came from. in fact i still didnt listen to the talk (but i will once i find the time) what similarities do you see ? is it just the word sustainability and the general subject ? or more ? Also giving 100 people the problem of financial sustainability for FFmpeg how many different solutions do you expect ? I found 4 (legal) ones and this was the first (which is why it says "A" in the subject. I did reject several probably illegal ideas like ICOs ... The word sustainability is quite rare it occured only 4 times on ffmpeg IRC 3 of these are a week before my mail and a few days before my SWS cleanup mail. And maybe also on VDD, i dont remember. What i do remember is that roanld mentioned sustainability, "no longer crashing with our parents. some of us have kids" on okt 11th on IRC privatly to me i have the log still and can post the line if ronald agrees appendix A searching for sustainability on IRC: FreeNode-#ffmpeg-devel.log:Jun 11 18:41:28 About: Archive - Cloud - Formats - sustainability - Outsourcing about? or is it about spending SPI money that we have (which is what thilo seems to imply) and then maybe see if we can get more, although that's not the primary goal? or some mix of the two? libera.chat-#ffmpeg-devel.log:Okt 09 23:12:59 that comment on daemon404's sustainability linkedin post misses the point a bit ? libera.chat-#ffmpeg-devel.log:Okt 10 03:00:47 durandal_1707: it jumps from (ffmpeg/videolan dev) sustainability to storage, av1, routing and hardware dev. I don't follow that jump, I guess libera.chat-#ffmpeg-devel.log:Okt 10 03:18:10 BBB: I think confusion over the word sustainability appendix B the SWS cleanup mail "1013 21:19 To FFmpeg devel (2,3K) [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion" This also had some replies that inspired some parts thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. 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] libavcodec/mpeg12: Remove "fast" mode
$subj as discussed at VDD Kieran 0001-libavcodec-mpeg12-Remove-fast-mode.patch Description: Binary data ___ 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] libavcodec/mpeg12: Remove "fast" mode
Oct 29, 2023, 16:43 by kier...@obe.tv: > $subj as discussed at VDD > > Kieran > This isn't Opus or JPEG-XL, there should be a single correct way of decoding something. Looks good to me. ___ 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] financial sustainability Plan A (SPI)
On Sun, Oct 29, 2023 at 04:35:35PM +0200, Rémi Denis-Courmont wrote: > Hi, > > Le 28 octobre 2023 21:01:57 GMT+03:00, Michael Niedermayer > a écrit : > >On Sat, Oct 28, 2023 at 07:21:03PM +0200, Michael Niedermayer wrote: > >> Hi ronald > >> > >> On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote: > >> > Hi Thilo, > >> > > >> > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel < > >> > ffmpeg-devel@ffmpeg.org> wrote: > >> > > >> > > What this is about, is to set up a way to properly spend the SPI money > >> > > aside > >> > > from travel & hw. Why we should not do it because some companies > >> > > beurocracy, I > >> > > cannot see. > >> > > > >> > > >> > I sincerely don't think the above description is what Kieran meant when > >> > he > >> > talked about sustainability at Demuxed, which this thread seems to be a > >> > response to. > >> > >> a quick reply here. I have not watched kierans presentation from demuxed > >> yet. > >> So theres absolutly no chance anything i wrote till now can be a respone to > >> it. > > > >some more words about what the intend of this plan was, again not a respone > >to any presentation of anyone else > > > >Donations from people vs companies: both really. > > I think Ronald's point is that you need to pick one, and clarify which it is, > because as Ronald explained, it's unlikely that a *good* plan could address > both (conversely a plan that tries to address both is probably poor and > flawed). > > In other words, if you want to cover both cases, you need two separate plans. you are correct, i agree here but this is a RFC so its not a final plan. i think for the donations from users the real question is how many of our users can we reach to explain them that they are using FFmpeg and a tiny donation would help us alot. if thats only a few thousand users then this will not work > > And unfortunately, I do believe that Ronald is correct in pointing out that > big companies will want oversight in exchange for money. This is very much > counter to the current project setup, which (depending whom you ask) is > governed by the GA, or by Fabrice Bellard through his delegates. > > This is not to say that these corporate wishes should or should not be > accomodated. It is just an observation of those wishes. if i look at spi.txt, it says "SPI needs a contract in place which describes the work to be done. " so if we have someone do some payed development work be that one time or continous. There would be a contract that says what is going to be done. That also would have been approved by the community or GA or whatver and the company paying would have a say in whats in that contract, really limited by what we are ok with and what the law allows > > >Peoples donations would only matter if we can increase awareness of people > >using FFmpeg. We have over a billion users but they dont know it. > >if each user gives us 1cent per year our sustainability is solved. > >So driving awareness alone would solve this already, even if only 0.1% > >of users would donate 10$ per year that would do. > > How do you plan to gain visibility from those billion users? Call me > pessimistic but this has been a known problem for 20+ years, and I have yet > to glimpse a credible solution. It depends on the community. If the commuity wants to do it Just look at some online service which annoy you telling you to disable a add blocker we could detect a specific usecase we intend to target and print a simple message once that will not annoy the user a 2nd time This is very controversal and iam not sure if 99% are against it or find it funny. Iam just awnsering the "how it can be done" not saying iam in favor or against [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
> > so if we have someone do some payed development work be that one time or > continous. There would be a contract that says what is going to be done. > That also would have been approved by the community or GA or whatver and > the company paying would have a say in whats in that contract, really > limited by what we are ok with and what the law allows Do you think a paying company would be happy with the private terms of a contract being discussed on a public ML? Or within a large group of people in the GA. You already mentioned that some of your work is covered under NDA so how does that fit within what you propose above about community approval? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 2/3] lavc/libaribcaption.c: add MSZ characters related options
On Sun, Oct 29, 2023 at 10:51 AM Jan Ekström wrote: > > On Tue, Oct 17, 2023 at 4:14 PM TADANO Tokumei wrote: > > > > This patch add MSZ (Middle Size; half width) characters related > > options. > > > > * add `-replace_msz_japanese` option introduced in version 1.0.1 > > of libaribcaption. > > * add `-replace_msz_glyph` option introduced in version 1.1.0 > > of libaribcaption. > > > > If specified fonts contain half-width glyphs (e.g., BIZ UDGothic), > > it make better rendering with `-replace_msz_ascii false` and > > `-replace_msz_japanese false` option for bitmap sub_type. > > > > Signed-off-by: TADANO Tokumei > > Change-wise LGTM. I reworked the commit message (starting with the > removal of ".c" at the end), and hopefully I understood correctly what > you were trying to mean with what I expect you were meaning with > regards to the latter option. The adjusted commits are visible in > https://github.com/jeeb/ffmpeg/commits/aribcaption_msz_patches_v3 . > > Otherwise the only thing I adjusted was > > diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c > index 2a058a4992..e87f303aa8 100644 > --- a/libavcodec/libaribcaption.c > +++ b/libavcodec/libaribcaption.c > @@ -1008,7 +1008,7 @@ static int aribcaption_init(AVCodecContext *avctx) > aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder, > ctx->replace_msz_ascii); > aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder, > - > ctx->replace_msz_japanese); > + > ctx->replace_msz_japanese); > > /* Similar behavior as ffmpeg tool to set canvas size */ > if (ctx->canvas_width > 0 && ctx->canvas_height > 0 && > > as there was a mismatching offset. If this is fine by you, I'll pull this in. Received an OK from the author regarding the commit message adjustments and such privately, so will be merging this in. ___ 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] Release 6.1
On Sun, 29 Oct 2023, at 16:10, Thilo Borgmann via ffmpeg-devel wrote: > Where? I don't see you saying that in this thread. > If you said so at VDD, that's not many times. Explained three times at VDD and several time on IRC. > Not being at where you say s.th. does not imply anything and is not an > argument. Refusing to attend the developer meetups and also refusing to be on one of the major discussion media and then complaining about not receiving information is a problem in an open source community. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 15:17, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> > Unsubstantiated opinion, let us ignore it. >> Again, a personal attack, from you. > > YOU are not an OPINION, so, no, this is not a personal attack, Because instead of doing the polite and normal thing which would be: "jb, I did not hear your opinion, can you restate it?" you said "jb, I did not hear his opinion, he should be ignored". -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] web: move 4.1 to olddownloads
On Sat, Oct 28, 2023 at 10:06:41PM -0300, James Almer wrote: > our downstream list shows no maintained users of that release > https://trac.ffmpeg.org/wiki/Downstreams > > Signed-off-by: James Almer > --- > src/download| 37 - > src/olddownload | 37 + > 2 files changed, 37 insertions(+), 37 deletions(-) if noone objects within a week the LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. 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] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Because instead of doing the polite and normal thing which would be: Politeness or not does not make it a personal attack. Moving goalposts much? -- Nicolas George 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] Release 6.1
Hello, On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote: > noone mentioned 5.1.x and 6.0.x to me before Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS branch) and a 6.0.0. Both of those have not had backports and releases of all the security issues, nor on the major regressions found (if any). Also, if they had some commits for security reasons, we should have a release at least every 90 days (3 months), because this is the standard for the security issues reporting (after that time, the security community makes them public). And seeing the number of fuzzing fixes, this is likely important. So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the utmost importance. > It was just that jb told me > "6.1 opportunity is gone. > We're too late on the schedule, and noone had time to work on it, so > it is wiser to target 7.0 in January" Yes, we said we would make a new major version for January (which will slip in February, as usual :D). So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and it might not worth it. Notably since at the time of 7.0, there might be not enough new things to cut a release. So I'm not against a release for 6.1 at all, but I believe focusing on minor releases for security and on 7.0 with the next major deprecations is more important. If we can do all of those, and keep more or less the timing for 7.0, please be my guest for 6.1. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 17:40, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> Because instead of doing the polite and normal thing which would be: > > Politeness or not does not make it a personal attack. Moving goalposts > much? Being not polite to someone is a personal attack. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Being not polite to someone is a personal attack. No. -- Nicolas George ___ 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] financial sustainability Plan A (SPI)
Rémi Denis-Courmont (12023-10-29): > And unfortunately, I do believe that Ronald is correct in pointing out > that big companies will want oversight in exchange for money. And this is why the only acceptable answer is: to hell with them and anybody who supports them. That might make less money in donations and that more of us will have to keep a day job, but it is the price of freedom. -- Nicolas George 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] Release 6.1
On 10/29/2023 1:42 PM, Jean-Baptiste Kempf wrote: Hello, On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote: noone mentioned 5.1.x and 6.0.x to me before Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS branch) and a 6.0.0. Both of those have not had backports and releases of all the security issues, nor on the major regressions found (if any). Also, if they had some commits for security reasons, we should have a release at least every 90 days (3 months), because this is the standard for the security issues reporting (after that time, the security community makes them public). And seeing the number of fuzzing fixes, this is likely important. So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the utmost importance. It was just that jb told me "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" Yes, we said we would make a new major version for January (which will slip in February, as usual :D). So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and it might not worth it. Notably since at the time of 7.0, there might be not enough new things to cut a release. So I'm not against a release for 6.1 at all, but I believe focusing on minor releases for security and on 7.0 with the next major deprecations is more important. If we can do all of those, and keep more or less the timing for 7.0, please be my guest for 6.1. Lynne made a list of the things that should (hopefully) make it to 7.0 for early 2024 (E.g. YUVJ removal, D3D12 hwdec, Vulkan encode, VVC, IAMF) plus Anton's CLI scheduler work, not to mention it will feature a major version bump and all the deprecated API removal that brings. So even with not a lot of things, the few it will get in these few months will be pretty big and appealing. 6.1 doesn't need to be supported for too long, but it's a good release to have as it will feature a year worth of development while being 6.0 ABI compatible, for those distros that care. ___ 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] Release 6.1
On Sun, 29 Oct 2023, at 17:49, James Almer wrote: > On 10/29/2023 1:42 PM, Jean-Baptiste Kempf wrote: >> Hello, >> >> On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote: >>> noone mentioned 5.1.x and 6.0.x to me before >> >> Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS >> branch) and a 6.0.0. >> >> Both of those have not had backports and releases of all the security >> issues, nor on the major regressions found (if any). >> >> Also, if they had some commits for security reasons, we should have a >> release at least every 90 days (3 months), because this is the standard for >> the security issues reporting (after that time, the security community makes >> them public). >> And seeing the number of fuzzing fixes, this is likely important. >> >> So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the >> utmost importance. >> >>> It was just that jb told me >>> "6.1 opportunity is gone. >>> We're too late on the schedule, and noone had time to work on it, so >>> it is wiser to target 7.0 in January" >> >> Yes, we said we would make a new major version for January (which will slip >> in February, as usual :D). >> So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and >> it might not worth it. >> Notably since at the time of 7.0, there might be not enough new things to >> cut a release. >> >> So I'm not against a release for 6.1 at all, but I believe focusing on minor >> releases for security and on 7.0 with the next major deprecations is more >> important. >> If we can do all of those, and keep more or less the timing for 7.0, please >> be my guest for 6.1. > > Lynne made a list of the things that should (hopefully) make it to 7.0 > for early 2024 (E.g. YUVJ removal, D3D12 hwdec, Vulkan encode, VVC, > IAMF) plus Anton's CLI scheduler work, not to mention it will feature a > major version bump and all the deprecated API removal that brings. So > even with not a lot of things, the few it will get in these few months > will be pretty big and appealing. > > 6.1 doesn't need to be supported for too long, but it's a good release > to have as it will feature a year worth of development while being 6.0 > ABI compatible, for those distros that care. Excellent then. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Am 29.10.23 um 17:25 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 16:10, Thilo Borgmann via ffmpeg-devel wrote: Where? I don't see you saying that in this thread. If you said so at VDD, that's not many times. Explained three times at VDD and several time on IRC. Very well. Assuming with "explained" you mean that you gave your reasoning as well, instead of just that statement which was quoted. Because the lack of that is what Nicolas led to refuse your opinion. Not being at where you say s.th. does not imply anything and is not an argument. Refusing to attend the developer meetups and also refusing to be on one of the major discussion media and then complaining about not receiving information is a problem in an open source community. Communication is the biggest problem indeed. In this case as well, I think you should have transported your reasoning back to this thread on the ML - you cannot blame anyone for not following live discussion like VDD or IRC. If you would have done so, your opinion could not have been waived away like Nicolas did. -Thilo p.s. sure, IRC is not really live, yet we expect to follow up on history only on the ML. Which is one reason why we say things like "as agreed on by X on IRC" in patch threads, for example. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] configure: fix _Pragma check.
From: Reimar Döffinger
The test can current pass when _Pragma is not supported, since
_Pragma might be treated as a implicitly declared function.
This happens e.g. with tinycc.
Extending the check to 2 pragmas both matches the actual use
better and avoids this misdetection.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index ff3ac9f4de..e2bcf4e1c2 100755
--- a/configure
+++ b/configure
@@ -5987,7 +5987,7 @@ for restrict_keyword in restrict __restrict__ __restrict
""; do
test_code cc "" "char * $restrict_keyword p" && break
done
-check_cc pragma_deprecated "" '_Pragma("GCC diagnostic ignored
\"-Wdeprecated-declarations\"")'
+check_cc pragma_deprecated "" '_Pragma("GCC diagnostic push") _Pragma("GCC
diagnostic ignored \"-Wdeprecated-declarations\"")'
# The global variable ensures the bits appear unchanged in the object file.
test_cc
[FFmpeg-devel] [PATCH 2/3] libavutil/aarch64/cpu.c: HWCAPS requires inline asm support.
From: Reimar Döffinger Fixes compilation with tcc, which does not have aarch64 inline asm support. --- libavutil/aarch64/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c index bd780e8591..0d7c1e268d 100644 --- a/libavutil/aarch64/cpu.c +++ b/libavutil/aarch64/cpu.c @@ -34,7 +34,7 @@ static int detect_flags(void) hwcap = getauxval(AT_HWCAP); -#if defined(HWCAP_CPUID) +#if defined(HWCAP_CPUID) && HAVE_INLINE_ASM // We can check for DOTPROD and I8MM using HWCAP_ASIMDDP and // HWCAP2_I8MM too, avoiding to read the CPUID registers (which triggers // a trap, handled by the kernel). However the HWCAP_* defines for these -- 2.39.3 (Apple Git-145) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] libavutil/log.c: only include valgrind header when used.
From: Reimar Döffinger This is cleaner, but it is also a workaround for when the header exists, but cannot be compiled. This will happen when the compiler has no inline asm support. Possibly the configure check should be improved as well. --- libavutil/log.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/log.c b/libavutil/log.c index 5948e50467..2d358b7ab9 100644 --- a/libavutil/log.c +++ b/libavutil/log.c @@ -47,7 +47,7 @@ static AVMutex mutex = AV_MUTEX_INITIALIZER; #define LINE_SZ 1024 -#if HAVE_VALGRIND_VALGRIND_H +#if HAVE_VALGRIND_VALGRIND_H && CONFIG_VALGRIND_BACKTRACE #include /* this is the log level at which valgrind will output a full backtrace */ #define BACKTRACE_LOGLEVEL AV_LOG_ERROR -- 2.39.3 (Apple Git-145) ___ 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] Release 6.1
On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: > In this case as well, I think you > should have transported your reasoning back to this thread on the ML - It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1. I even send a longer email to explain. > cannot blame anyone for not following live discussion like VDD or IRC. Sorry, I can. Being on IRC is necessary, IMHO. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Sorry, I can. Being on IRC is necessary, IMHO. Completely unacceptable and fortunately not true at all. The mailing-list has always been the main channel of development, anything synchronous, that requires people to be on line at the same time, is unsuited for a project on multiple timezones where everybody is equal but nobody has an obligation. And I think it is very bad that some body with apparent authority suggests otherwise. -- Nicolas George 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] Release 6.1
On Sun, 29 Oct 2023, at 19:12, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> Sorry, I can. Being on IRC is necessary, IMHO. > > Completely unacceptable and fortunately not true at all. We'll have to agree to disagree. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > We'll have to agree to disagree. So you disagree that ffmpeg is not a corporate project where developers can be forced to have fixed work hours. Interesting. -- Nicolas George 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] Release 6.1
Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: In this case as well, I think you should have transported your reasoning back to this thread on the ML - It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1. I even send a longer email to explain. I wonder why you didn't say that one iteration back when I asked you where to find it. (Your answer was "at VDD & on IRC", just not to delete too much history here.) Anyway, in this very thread (and in the Release 6.1 thread started from Michael before this thread of Lynne) I can see exactly 3 prior mails from you. 06.07.23, "good idea lets do 6.1" 26.09.23, "calling people liars is bad" 21.09.23, "+1" As well as the many mails from today, of course. So is this problem on my mail client end? Can you provide links into the archives regarding the mails you are referring to? -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] Release 6.1
Am 29.10.23 um 19:12 schrieb Nicolas George: Jean-Baptiste Kempf (12023-10-29): Sorry, I can. Being on IRC is necessary, IMHO. Completely unacceptable and fortunately not true at all. The mailing-list has always been the main channel of development, anything synchronous, that requires people to be on line at the same time, is unsuited for a project on multiple timezones where everybody is equal but nobody has an obligation. And I think it is very bad that some body with apparent authority suggests otherwise. +1 -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] Release 6.1
On Sun, 29 Oct 2023, at 19:31, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> We'll have to agree to disagree. > > So you disagree that ffmpeg is not a corporate project where developers > can be forced to have fixed work hours. Interesting. IRC has logs and many people having fixed work hours are on IRC. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > IRC has logs That are good to know what has been said, not for participating in the decision making. Therefore IRC is unacceptable for making decisions. > and many people having fixed work hours are on IRC. The problem is the people who cannot be. -- Nicolas George 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] Release 6.1
On Sun, 29 Oct 2023, at 19:46, Thilo Borgmann via ffmpeg-devel wrote: > Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf: >> On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: >>> In this case as well, I think you >>> should have transported your reasoning back to this thread on the ML - >> >> It's actually in this very thread on the ML about the timing and prefering >> 7.0 over 6.1. >> >> I even send a longer email to explain. > > I wonder why you didn't say that one iteration back when I asked you > where to > find it. (Your answer was "at VDD & on IRC", just not to delete too > much history > here.) > > Anyway, in this very thread (and in the Release 6.1 thread started from > Michael > before this thread of Lynne) I can see exactly 3 prior mails from you. Mail are not just from me, but about me. Quoting the mail that supposedly quotes me: "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" I think it's very clear about "opportunity" and "late on the schedule" and what they mean. You decided then it was not clear and "unsubstantiated", and therefore that my opinion had no value, so I had to expand on it. So, I spoke about it at VDD, several time, on IRC and it refers to me on this very mailing list. And instead of asking me to clarify, you started to say that my opinion had no value, and then attacking me. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Le sunnuntaina 29. lokakuuta 2023, 18.12.58 EET Michael Niedermayer a écrit : > On Sun, Oct 29, 2023 at 04:35:35PM +0200, Rémi Denis-Courmont wrote: > > Hi, > > > > Le 28 octobre 2023 21:01:57 GMT+03:00, Michael Niedermayer a écrit : > > >On Sat, Oct 28, 2023 at 07:21:03PM +0200, Michael Niedermayer wrote: > > >> Hi ronald > > >> > > >> On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote: > > >> > Hi Thilo, > > >> > > > >> > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel < > > >> > > > >> > ffmpeg-devel@ffmpeg.org> wrote: > > >> > > What this is about, is to set up a way to properly spend the SPI > > >> > > money > > >> > > aside > > >> > > from travel & hw. Why we should not do it because some companies > > >> > > beurocracy, I > > >> > > cannot see. > > >> > > > >> > I sincerely don't think the above description is what Kieran meant > > >> > when he > > >> > talked about sustainability at Demuxed, which this thread seems to be > > >> > a > > >> > response to. > > >> > > >> a quick reply here. I have not watched kierans presentation from > > >> demuxed yet. So theres absolutly no chance anything i wrote till now > > >> can be a respone to it. > > > > > >some more words about what the intend of this plan was, again not a > > >respone > > >to any presentation of anyone else > > > > > >Donations from people vs companies: both really. > > > > I think Ronald's point is that you need to pick one, and clarify which it > > is, because as Ronald explained, it's unlikely that a *good* plan could > > address both (conversely a plan that tries to address both is probably > > poor and flawed). > > > > In other words, if you want to cover both cases, you need two separate > > plans. > you are correct, i agree here but this is a RFC so its not a final > plan. > > i think for the donations from users the real question is how many > of our users can we reach to explain them that they are using FFmpeg > and a tiny donation would help us alot. > if thats only a few thousand users then this will not work > > > And unfortunately, I do believe that Ronald is correct in pointing out > > that big companies will want oversight in exchange for money. This is > > very much counter to the current project setup, which (depending whom you > > ask) is governed by the GA, or by Fabrice Bellard through his delegates. > > > > This is not to say that these corporate wishes should or should not be > > accomodated. It is just an observation of those wishes. > if i look at spi.txt, it says > "SPI needs a contract in place which describes the work to be done. " > > so if we have someone do some payed development work be that one time or > continous. There would be a contract that says what is going to be done. > That also would have been approved by the community or GA or whatver and > the company paying would have a say in whats in that contract, really > limited by what we are ok with and what the law allows Unfortunately, that is missing the point. If a company wants to pay someone for some specific tasks, they can already do that, with or without the intervention of SPI. And they already know that they can do that, at least without SPI. Your plan A is unnecessary for this case. If SPI has any benefit here, it's maybe fiscal. If there is really a tax benefit, you could emphasize on the website and social networks tha SPI is available as an option. Some companies could be willing to provide more sustainable funding for more general maintenance, but they would probably require something like what Ronald mentioned - especially for FFmpeg whose community has a poor reputation. > > How do you plan to gain visibility from those billion users? Call me > > pessimistic but this has been a known problem for 20+ years, and I have > > yet to glimpse a credible solution. > It depends on the community. If the commuity wants to do it > Just look at some online service which annoy you telling you to disable a > add blocker we could detect a specific usecase we intend to target and > print a simple message once that will not annoy the user a 2nd time > This is very controversal and iam not sure if 99% are against it or find it > funny. Iam just awnsering the "how it can be done" not saying iam in favor > or against That's not a credible solution for a library. All reverse dependency developers would disable that before they ship affected FFmpeg versions, or worse, just stop updating their vendored FFmpeg. The FFmpeg CLI tool print stuff, but that's going to be seen by a tiny fraction of the user base. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Hi Nicolas, On Sun, Oct 29, 2023 at 12:47 PM Nicolas George wrote: > Rémi Denis-Courmont (12023-10-29): > > And unfortunately, I do believe that Ronald is correct in pointing out > > that big companies will want oversight in exchange for money. > > And this is why the only acceptable answer is: to hell with them and > anybody who supports them. > No. *You* may well end up not accepting their offered help, and that's your call to make. But if others in our community end up accepting their offered help, there's nothing you can do against it. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Ronald S. Bultje (12023-10-29): > *You* may well end up not accepting their offered help, and that's your > call to make. But if others in our community end up accepting their offered > help, there's nothing you can do against it. Other in the community are free to do as they choose on their own, of course. But the project itself should never accept obligations to a corporate entity. Never. -- Nicolas George 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] financial sustainability Plan A (SPI)
On Sun, Oct 29, 2023 at 3:46 PM Nicolas George wrote: > Ronald S. Bultje (12023-10-29): > > *You* may well end up not accepting their offered help, and that's your > > call to make. But if others in our community end up accepting their > offered > > help, there's nothing you can do against it. > > Other in the community are free to do as they choose on their own, of > course. > > But the project itself should never accept obligations to a corporate > entity. Never. > "The project" is not a legal entity, how could it? It's not even possible. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Sun, Oct 29, 2023 at 8:46 PM Nicolas George wrote: > Ronald S. Bultje (12023-10-29): > > *You* may well end up not accepting their offered help, and that's your > > call to make. But if others in our community end up accepting their > offered > > help, there's nothing you can do against it. > > Other in the community are free to do as they choose on their own, of > course. > > But the project itself should never accept obligations to a corporate > entity. Never. > Project already accepted several obligations to a several corporate entities. > > -- > Nicolas George > ___ > 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] financial sustainability Plan A (SPI)
Le sunnuntaina 29. lokakuuta 2023, 18.47.34 EET Nicolas George a écrit : > Rémi Denis-Courmont (12023-10-29): > > And unfortunately, I do believe that Ronald is correct in pointing out > > that big companies will want oversight in exchange for money. > > And this is why the only acceptable answer is: to hell with them and > anybody who supports them. You are entitled to your opinion. There are pros and cons either way, that different people will weigh differently. If I had meaningful say and stake, I would probably feel conflicted. So I will neither agree nor disagree with you here. However your choice of word is very disagreeable, and makes your side of the argument a disservice. > That might make less money in donations and that more of us will have to > keep a day job, but it is the price of freedom. Be careful what you wish for. Michael started this thread, so I suppose that he wants funding for himself and/or for some other key developers. They are who you are opposing here, rather than bottom feeders such as myself. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] lavc/sbrdsp: R-V V sum64x5
sum64x5_c: 385.0
sum64x5_rvv_f32: 116.0
---
libavcodec/riscv/Makefile | 4 +--
libavcodec/riscv/sbrdsp_init.c | 37 +
libavcodec/riscv/sbrdsp_rvv.S | 50 ++
libavcodec/sbrdsp.h| 1 +
libavcodec/sbrdsp_template.c | 2 ++
5 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/riscv/sbrdsp_init.c
create mode 100644 libavcodec/riscv/sbrdsp_rvv.S
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 06815d3170..2c9af16782 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -1,5 +1,5 @@
-OBJS-$(CONFIG_AAC_DECODER) += riscv/aacpsdsp_init.o
-RVV-OBJS-$(CONFIG_AAC_DECODER) += riscv/aacpsdsp_rvv.o
+OBJS-$(CONFIG_AAC_DECODER) += riscv/aacpsdsp_init.o riscv/sbrdsp_init.o
+RVV-OBJS-$(CONFIG_AAC_DECODER) += riscv/aacpsdsp_rvv.o riscv/sbrdsp_rvv.o
OBJS-$(CONFIG_AC3DSP) += riscv/ac3dsp_init.o \
riscv/ac3dsp_rvb.o
OBJS-$(CONFIG_ALAC_DECODER) += riscv/alacdsp_init.o
diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
new file mode 100644
index 00..837f24e1e0
--- /dev/null
+++ b/libavcodec/riscv/sbrdsp_init.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * 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 "config.h"
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavcodec/sbrdsp.h"
+
+void ff_sbr_sum64x5_rvv(float *z);
+
+av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_F32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+c->sum64x5 = ff_sbr_sum64x5_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
new file mode 100644
index 00..e1d548b41b
--- /dev/null
+++ b/libavcodec/riscv/sbrdsp_rvv.S
@@ -0,0 +1,50 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * 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/riscv/asm.S"
+
+func ff_sbr_sum64x5_rvv, zve32f
+li a5, 64
+addia1, a0, 64 * 4
+addia2, a0, 128 * 4
+addia3, a0, 192 * 4
+addia4, a0, 256 * 4
+1:
+vsetvli t0, a5, e32, m8, ta, ma
+sub a5, a5, t0
+vle32.v v0, (a0)
+vle32.v v8, (a1)
+sh2add a1, t0, a1
+vle32.v v16, (a2)
+vfadd.vv v0, v0, v8
+sh2add a2, t0, a2
+vle32.v v24, (a3)
+vfadd.vv v0, v0, v16
+sh2add a3, t0, a3
+vle32.v v8, (a4)
+vfadd.vv v0, v0, v24
+sh2add a4, t0, a4
+vfadd.vv v0, v0, v8
+vse32.v v0, (a0)
+sh2add a0, t0, a0
+bneza5, 1b
+
+ret
+endfunc
diff --git a/libavcodec/sbrdsp.h b/libavcodec/sbrdsp.h
index 8513c423af..49782202a7 100644
--- a/libavcodec/sbrdsp.h
+++ b/libavcodec/sbrdsp.h
@@ -48,6 +48,7 @@ extern const INTFLOAT AAC_RENAME(ff_sbr_noise_table)[][2];
void AAC_RENAME(ff_sbrdsp_init)(SBRDSPContext *s);
void ff_sbrdsp_init_arm(SBRDSPContext *s);
void ff_sbrdsp_init_aarch64(SBRDSPContext *s);
+void ff_sbrdsp_init_riscv(SBRDSPContext *s);
void ff_sbrdsp_init_x86(SBRDSPContext *s);
void ff_sbrdsp_init_mips(SBRDSPContext *s);
diff --git a/libavcodec/sbrdsp_template.c b/libavcodec/sbrdsp_template.c
index 89e389d9a0..79cd2156d9 100644
--- a/libavcodec/sbrdsp_template.c
+++ b/libavcodec/sbrdsp_template.c
@@ -98,6 +98,8 @@ av_cold void AAC_RENAME(ff_sbrdsp_init)(SBRDSPContex
[FFmpeg-devel] [PATCH 2/3] lavc/sbrdsp: R-V V sum_square
sum_square_c: 803.5
sum_square_rvv_f32: 283.2
---
libavcodec/riscv/sbrdsp_init.c | 2 ++
libavcodec/riscv/sbrdsp_rvv.S | 19 +++
2 files changed, 21 insertions(+)
diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
index 837f24e1e0..e0e62278b0 100644
--- a/libavcodec/riscv/sbrdsp_init.c
+++ b/libavcodec/riscv/sbrdsp_init.c
@@ -24,6 +24,7 @@
#include "libavcodec/sbrdsp.h"
void ff_sbr_sum64x5_rvv(float *z);
+float ff_sbr_sum_square_rvv(float (*x)[2], int n);
av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
{
@@ -32,6 +33,7 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
if ((flags & AV_CPU_FLAG_RVV_F32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
c->sum64x5 = ff_sbr_sum64x5_rvv;
+c->sum_square = ff_sbr_sum_square_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
index e1d548b41b..4684630953 100644
--- a/libavcodec/riscv/sbrdsp_rvv.S
+++ b/libavcodec/riscv/sbrdsp_rvv.S
@@ -48,3 +48,22 @@ func ff_sbr_sum64x5_rvv, zve32f
ret
endfunc
+
+func ff_sbr_sum_square_rvv, zve32f
+vsetvli t0, zero, e32, m8, ta, ma
+sllia1, a1, 1
+vmv.v.x v8, zero
+vmv.s.x v0, zero
+1:
+vsetvli t0, a1, e32, m8, tu, ma
+vle32.v v16, (a0)
+sub a1, a1, t0
+vfmacc.vv v8, v16, v16
+sh2add a0, t0, a0
+bneza1, 1b
+
+vfredusum.vs v0, v8, v0
+vfmv.f.s fa0, v0
+NOHWF fmv.x.w a0, fa0
+ret
+endfunc
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] lavc/sbrdsp: R-V V neg_odd_64
With 128-bit vectors, this is mostly pointless but also harmless.
Performance gains should be more noticeable with larger vector sizes.
neg_odd_64_c: 76.2
neg_odd_64_rvv_i64: 74.7
---
libavcodec/riscv/sbrdsp_init.c | 5 +
libavcodec/riscv/sbrdsp_rvv.S | 17 +
2 files changed, 22 insertions(+)
diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
index e0e62278b0..1b85b2cae9 100644
--- a/libavcodec/riscv/sbrdsp_init.c
+++ b/libavcodec/riscv/sbrdsp_init.c
@@ -25,6 +25,7 @@
void ff_sbr_sum64x5_rvv(float *z);
float ff_sbr_sum_square_rvv(float (*x)[2], int n);
+void ff_sbr_neg_odd_64_rvv(float *x);
av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
{
@@ -35,5 +36,9 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
c->sum64x5 = ff_sbr_sum64x5_rvv;
c->sum_square = ff_sbr_sum_square_rvv;
}
+#if __riscv_xlen >= 64
+if ((flags & AV_CPU_FLAG_RVV_I64) && (flags & AV_CPU_FLAG_RVB_ADDR))
+c->neg_odd_64 = ff_sbr_neg_odd_64_rvv;
+#endif
#endif
}
diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
index 4684630953..b510190b15 100644
--- a/libavcodec/riscv/sbrdsp_rvv.S
+++ b/libavcodec/riscv/sbrdsp_rvv.S
@@ -67,3 +67,20 @@ func ff_sbr_sum_square_rvv, zve32f
NOHWF fmv.x.w a0, fa0
ret
endfunc
+
+#if __riscv_xlen >= 64
+func ff_sbr_neg_odd_64_rvv, zve64x
+li a1, 32
+li t1, 1 << 63
+1:
+vsetvli t0, a1, e64, m8, ta, ma
+vle64.v v8, (a0)
+sub a1, a1, t0
+vxor.vx v8, v8, t1
+vse64.v v8, (a0)
+sh3add a0, t0, a0
+bnezt0, 1b
+
+ret
+endfunc
+#endif
--
2.42.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] financial sustainability Plan A (SPI)
Rémi Denis-Courmont (12023-10-29): > Be careful what you wish for. Michael started this thread, so I suppose that > he wants funding for himself and/or for some other key developers. They are It would be hypocritical of me to take this into considerations. Corporate sponsorships with strings attached are dangerous and should be refused, whoever they are offered to. > who you are opposing here, rather than bottom feeders such as myself. Please refrain from insinuating that I have insulted you like that. -- Nicolas George 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 2/3] libavutil/aarch64/cpu.c: HWCAPS requires inline asm support.
On Sun, 29 Oct 2023, reimar.doeffin...@gmx.de wrote: From: Reimar Döffinger Fixes compilation with tcc, which does not have aarch64 inline asm support. --- libavutil/aarch64/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c index bd780e8591..0d7c1e268d 100644 --- a/libavutil/aarch64/cpu.c +++ b/libavutil/aarch64/cpu.c @@ -34,7 +34,7 @@ static int detect_flags(void) hwcap = getauxval(AT_HWCAP); -#if defined(HWCAP_CPUID) +#if defined(HWCAP_CPUID) && HAVE_INLINE_ASM // We can check for DOTPROD and I8MM using HWCAP_ASIMDDP and // HWCAP2_I8MM too, avoiding to read the CPUID registers (which triggers // a trap, handled by the kernel). However the HWCAP_* defines for these -- 2.39.3 (Apple Git-145) 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] libavcodec/mpeg12: Remove "fast" mode
On Sun, Oct 29, 2023 at 03:43:27PM +, Kieran Kunhya wrote: > $subj as discussed at VDD > > Kieran > mpeg12dec.c | 265 > > 1 file changed, 265 deletions(-) > 94ecfc53b5e1b5c130eb68e1848078b7f1a43beb > 0001-libavcodec-mpeg12-Remove-fast-mode.patch > From aebab0825cb6c50d5f496fde2e9e9e5ad0cef87b Mon Sep 17 00:00:00 2001 > From: Kieran Kunhya > Date: Sun, 29 Oct 2023 15:32:49 + > Subject: [PATCH] libavcodec/mpeg12: Remove "fast" mode LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
On Sun, Oct 29, 2023 at 10:38 AM Nicolas George wrote: > Paul B Mahol (12023-10-28): > > I did proper analysis already. Pushed. > > Thanks for the precedent, I will gladly do the same to you in the > future. > Haven't yet pushed it. This was a test. That you failed. Still awaiting your 'proper' review. Note that I will not wait too much. > > -- > Nicolas George > ___ > 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] web: move 5.0 to olddownloads
> On Oct 20, 2023, at 9:01 AM, Michael Niedermayer > wrote: > > our downstream list shows no maintained users of that release > https://trac.ffmpeg.org/wiki/Downstreams I was trying to track down the status of OpenMandriva Lx 3 because it's listed as a downstream for ffmpeg 4.0. While doing this I noticed that Lx 3 is EOL as of 2019-07-16. The current active version of OpenMandriva is Lx 4.3, and it seems to be packaging ffmpeg 5.0 based on https://openmandriva.pkgs.org/4.3/openmandriva-main-release-x86_64/ffmpeg-5.0-1-omv4050.x86_64.rpm.html I'm not directly familiar with OpenMandriva I was just chasing up the 4.0 relationship. I updated the wiki based on this information but it would be good for someone familiar with OpenMandriva to confirm. Based on that it might make sense to keep 5.0 and consider moving 4.0 to old downloads. - Cosmin ___ 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] libavcodec/mpeg12: Remove "fast" mode
On 10/29/23 11:48, Lynne wrote: Oct 29, 2023, 16:43 by kier...@obe.tv: $subj as discussed at VDD Kieran This isn't Opus or JPEG-XL, there should be a single correct way of decoding something. Looks good to me. ___ I'm not sure I understand what you mean - JPEG XL is fully specified. Are you thinking of mjpeg? - Leo Izen ___ 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] avformat/hls: use av_strlcopy instead of strncpy
Leo Izen:
> Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
> strncpy.
>
> Signed-off-by: Leo Izen
> ---
> libavformat/hls.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index f5f549b24d..39440176c9 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -543,8 +543,8 @@ static struct rendition *new_rendition(HLSContext *c,
> struct rendition_info *inf
> int langlen = strlen(rend->language);
> if (langlen < sizeof(rend->language) - 3) {
> rend->language[langlen] = ',';
> -strncpy(rend->language + langlen + 1, info->assoc_language,
> -sizeof(rend->language) - langlen - 2);
> +av_strlcpy(rend->language + langlen + 1, info->assoc_language,
> +sizeof(rend->language) - langlen - 1);
> }
> }
>
As I said before: You are merely hiding the truncation issue instead of
fixing it.
- 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] avformat/hls: use av_strlcopy instead of strncpy
On 10/29/23 20:23, Andreas Rheinhardt wrote:
Leo Izen:
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..39440176c9 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -543,8 +543,8 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
int langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
-sizeof(rend->language) - langlen - 2);
+av_strlcpy(rend->language + langlen + 1, info->assoc_language,
+sizeof(rend->language) - langlen - 1);
}
}
As I said before: You are merely hiding the truncation issue instead of
fixing it.
I don't see how? It will only be truncated if info->assoc_language is
very very long, and in that case it won't fit inside a 64-byte buffer so
it will *have* to be truncated. But it will be nul-terminated in either
case, so there's no real difference between the old and new code, other
than the warning.
___
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] Extract av_hls_codec_attr
The logic for extracting HLS codec attribute strings is very useful and
can be re-used in many different situations when working with HLS
streams using libavcodec/libavformat.
This patch extracts the function's code and places it into a publicly
available function.
---
libavcodec/Makefile | 2 +
libavcodec/hls.c | 105 +++
libavcodec/hls.h | 42 +
libavformat/hlsenc.c | 83 +++---
4 files changed, 155 insertions(+), 77 deletions(-)
create mode 100644 libavcodec/hls.c
create mode 100644 libavcodec/hls.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 580a8d6b54..b3b2b18980 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -16,6 +16,7 @@ HEADERS = ac3_parser.h
\
dirac.h \
dv_profile.h \
dxva2.h \
+ hls.h \
jni.h \
mediacodec.h \
packet.h \
@@ -47,6 +48,7 @@ OBJS = ac3_parser.o
\
get_buffer.o \
imgconvert.o \
jni.o\
+ hls.o\
mathtables.o \
mediacodec.o \
mpeg12framerate.o\
diff --git a/libavcodec/hls.c b/libavcodec/hls.c
new file mode 100644
index 00..59ab0c4819
--- /dev/null
+++ b/libavcodec/hls.c
@@ -0,0 +1,105 @@
+/*
+ * HLS public API
+ *
+ * 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 "hls.h"
+#include "libavutil/intreadwrite.h"
+#include "libavformat/avc.h"
+
+int av_hls_codec_attr(AVStream *st, char *attr, size_t attr_len) {
+ if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+ uint8_t *data = st->codecpar->extradata;
+ if (data) {
+ const uint8_t *p;
+
+ if (AV_RB32(data) == 0x01 && (data[4] & 0x1F) == 7)
+ p = &data[5];
+ else if (AV_RB24(data) == 0x01 && (data[3] & 0x1F) == 7)
+ p = &data[4];
+ else if (data[0] == 0x01) /* avcC */
+ p = &data[1];
+ else
+ return AVERROR_INVALIDDATA;
+ snprintf(attr, attr_len,
+ "avc1.%02x%02x%02x", p[0], p[1], p[2]);
+ } else {
+ return AVERROR_INVALIDDATA;
+ }
+ } else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
+ uint8_t *data = st->codecpar->extradata;
+ int profile = AV_PROFILE_UNKNOWN;
+ int level = AV_LEVEL_UNKNOWN;
+
+ if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
+ profile = st->codecpar->profile;
+ if (st->codecpar->level != AV_LEVEL_UNKNOWN)
+ level = st->codecpar->level;
+
+ /* check the boundary of data which from current position is small than
extradata_size */
+ while (data && (data - st->codecpar->extradata + 19) <
st->codecpar->extradata_size) {
+ /* get HEVC SPS NAL and seek to profile_tier_level */
+ if (!(data[0] | data[1] | data[2]) && data[3] == 1 && ((data[4] &
0x7E) == 0x42)) {
+ uint8_t *rbsp_buf;
+ int remain_size = 0;
+ int rbsp_size = 0;
+ /* skip start code + nalu header */
+ data += 6;
+ /* process by reference General NAL unit syntax */
+ remain_size = st->codecpar->extradata_size - (data -
st->codecpar->extradata);
+ rbsp_buf = ff_nal_unit_extract_rbsp(data, remain_size,
&rbsp_size, 0);
+ if (!rbsp_buf)
+ return AVERROR_INVALIDDATA;
+ i
Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12: Remove "fast" mode
Oct 30, 2023, 01:02 by leo.i...@gmail.com: > On 10/29/23 11:48, Lynne wrote: > >> Oct 29, 2023, 16:43 by kier...@obe.tv: >> >>> $subj as discussed at VDD >>> >>> Kieran >>> >> >> This isn't Opus or JPEG-XL, there should be a single correct way of decoding >> something. >> Looks good to me. >> ___ >> > > I'm not sure I understand what you mean - JPEG XL is fully specified. Are you > thinking of mjpeg? > Anything that does not have a decoder fully defined with fixed-point math or at least does not define a specific floating point format, with all constants being given in that float format unambiguously (e.g. regular IEEE 32-bit floats, with all constant values being given as 32-bit hex), along with a defined and bitexact mathematical operations (i.e. IEEE). Giving only float constants up to a reasonable decimal point and defining a maximum error is just not how video codecs are defined. Yeah, compared to Opus, JPEG-XL is really ordinary and shouldn't have been there, and it can be argued that the error margins are small enough to permit bitexactness up to a bit depth, but I nevertheless would've liked to see fixed-point specifications. ___ 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] libavcodec/mpeg12: Remove "fast" mode
On 10/29/23 21:22, Lynne wrote: it can be argued that the error margins are small enough to permit bitexactness For what it's worth, the error margins for compliance are specified in 18181-3 and they're definitely within one pixel value for the various bit depths supported by the codestream format. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] decode: add ff_decode_skip_samples function
This is a convenience function, which is required to be called by decoders
needing to skip samples every time.
It automatically creates and increments side data.
The idea is to get rid of skip_samples eventually and replace it with this
function.
Patch attached.
>From 41dfcbbacfa9232d2308d0229dcd172309b32f9f Mon Sep 17 00:00:00 2001
From: Lynne
Date: Mon, 30 Oct 2023 05:38:17 +0100
Subject: [PATCH 1/2] decode: add ff_decode_skip_samples function
This is a convenience function, which is required to be called by decoders
needing to skip samples every time.
It automatically creates and increments side data.
The idea is to get rid of skip_samples eventually and replace it with this
function.
---
libavcodec/decode.c | 18 ++
libavcodec/decode.h | 9 +
2 files changed, 27 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index ad39021354..f971723ff7 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -299,6 +299,24 @@ static int64_t guess_correct_pts(AVCodecContext *ctx,
return pts;
}
+int ff_decode_skip_samples(AVCodecContext *avctx, AVFrame *frame, uint32_t base_skip, uint32_t additional)
+{
+uint32_t val = 0;
+AVFrameSideData *side = av_frame_get_side_data(frame, AV_FRAME_DATA_SKIP_SAMPLES);
+if (!side) {
+side = av_frame_new_side_data(frame, AV_FRAME_DATA_SKIP_SAMPLES, 10);
+if (!side)
+return AVERROR(ENOMEM);
+AV_WL32(side->data, base_skip);
+}
+
+val += AV_RL32(side->data);
+val += additional;
+AV_WL32(side->data, val);
+
+return 0;
+}
+
static int discard_samples(AVCodecContext *avctx, AVFrame *frame, int64_t *discarded_samples)
{
AVCodecInternal *avci = avctx->internal;
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index daf1a67444..647f091da9 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -155,4 +155,13 @@ int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx, void **hwaccel_picture_pr
const AVPacketSideData *ff_get_coded_side_data(const AVCodecContext *avctx,
enum AVPacketSideDataType type);
+/**
+ * Skip samples in an AVFrame.
+ *
+ * @param base_skip amount of samples to skip if no side data is present
+ * @param additional amount of samples to skip unconditionally
+ */
+int ff_decode_skip_samples(AVCodecContext *avctx, AVFrame *frame,
+ uint32_t base_skip, uint32_t additional);
+
#endif /* AVCODEC_DECODE_H */
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] aacdec: correctly skip padding at the start of frames and during seeking
Presently, our AAC decoder didn't skip any samples, unless the side data
contained skip information.
This uses the newly added ff_decoder_skip_samples function to skip samples
on two levels: base, and additional.
Base is the inherent decoder delay. Most containers already specify it,
hence it is overwritten in that case.
Additional is any extra samples that have to be skipped, in AAC's case,
it's the delay introduced by SBR.
Patch attached.
>From 82120460459cf90c330ff11fe0ccf4b954736b5c Mon Sep 17 00:00:00 2001
From: Lynne
Date: Mon, 30 Oct 2023 05:40:22 +0100
Subject: [PATCH 2/2] aacdec: correctly skip padding at the start of frames and
during seeking
Presently, our AAC decoder didn't skip any samples, unless the side data
contained skip information.
This uses the newly added ff_decoder_skip_samples function to skip samples
on two levels: base, and additional.
Base is the inherent decoder delay. Most containers already specify it,
hence it is overwritten in that case.
Additional is any extra samples that have to be skipped, in AAC's case,
it's the delay introduced by SBR.
---
libavcodec/aac.h | 1 +
libavcodec/aacdec_template.c | 24 +++-
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 285d3b7482..06aecf 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -298,6 +298,7 @@ struct AACContext {
AVCodecContext *avctx;
AVFrame *frame;
+int skip_samples;
int is_saved; ///< Set if elements have stored overlap from previous frame.
DynamicRangeControl che_drc;
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 954399f86b..ab3037c0d5 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -532,6 +532,8 @@ static void flush(AVCodecContext *avctx)
}
}
}
+
+ac->skip_samples = 1;
}
/**
@@ -1251,6 +1253,7 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
return AVERROR(ENOMEM);
}
+ac->skip_samples = 1;
ac->random_state = 0x1f2e3d4c;
#define MDCT_INIT(s, fn, len, sval)\
@@ -2419,7 +2422,7 @@ static int decode_dynamic_range(DynamicRangeControl *che_drc,
static int decode_fill(AACContext *ac, GetBitContext *gb, int len) {
uint8_t buf[256];
-int i, major, minor;
+int i;
if (len < 13+7*8)
goto unknown;
@@ -2433,10 +2436,6 @@ static int decode_fill(AACContext *ac, GetBitContext *gb, int len) {
if (ac->avctx->debug & FF_DEBUG_PICT_INFO)
av_log(ac->avctx, AV_LOG_DEBUG, "FILL:%s\n", buf);
-if (sscanf(buf, "libfaac %d.%d", &major, &minor) == 2){
-ac->avctx->internal->skip_samples = 1024;
-}
-
unknown:
skip_bits_long(gb, len);
@@ -3403,6 +3402,21 @@ static int aac_decode_frame(AVCodecContext *avctx, AVFrame *frame,
if (buf[buf_offset])
break;
+if (ac->skip_samples) {
+int additional = 0;
+
+if (ac->oc[1].m4ac.sbr)
+additional = 3010;
+
+err = ff_decode_skip_samples(avctx, frame,
+ ac->oc[1].m4ac.frame_length_short ? 960 : 1024,
+ additional);
+if (err < 0)
+return err;
+
+ac->skip_samples = 0;
+}
+
return buf_size > buf_offset ? buf_consumed : buf_size;
}
--
2.42.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] libavcodec/mpeg12: Remove "fast" mode
On 29.10.23 16:43, Kieran Kunhya wrote: $subj as discussed at VDD Kieran IMHO the commit message should have contained some reason as to *why* this was removed. Now, someone looking at the log needs to find this patch on the ML, then follow the reference to find VDD meeting notes where they finally find... nothing. Because all the notes say is: > We should remove it Unfortunately, I'm too late and it's pushed now, but maybe you can at least give a short explanation here on the ML? Matthias ___ 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".
