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()
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 li
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
> 在 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
> ___
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
>
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@
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 thi
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@ffm
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
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 wit
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
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 lengt
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
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
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 opportun
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
___
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 Bo
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...
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 ffm
$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
f
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://ffmp
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
>
> 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
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.
> >
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
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 w
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 ++
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
___
ff
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 t
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 (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
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
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 backport
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
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 w
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 +-
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
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(+
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
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
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
__
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
__
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 pref
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
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
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.
--
Nico
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
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 Niederm
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:
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,
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.
>
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.
>
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
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 |
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 1006
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 c
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 att
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
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-Rem
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'
> 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
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
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 1
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
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
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.
>> ___
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 f
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 41dfcbbacfa9232d2308d0229dc
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 o
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
70 matches
Mail list logo
