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
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
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
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.
>>
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 |
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
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
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
> 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
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 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
>
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
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
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
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
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 |
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
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.
>
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.
>
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,
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:
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
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
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.
--
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
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
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
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
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):
> 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
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
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
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
---
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 +-
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
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
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
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
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
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.
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
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
___
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
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
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
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.
> >
>
> 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 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,
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
$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
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
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...
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
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
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
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
+++
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
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
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 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
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.
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
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
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
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
>
> 在 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
>
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"
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
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
Due to making the decode frames context use the coded size, the
filter started to display those artifacts as it reused the input frame's size.
Change it to instead output the real image size for images, not the input.
Patch attached.
>From 93d0b1012012b1a1a8d0701f9c78e4a1a9502d29 Mon Sep 17
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?
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
71 matches
Mail list logo
