Sep 29, 2023, 00:10 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> Sep 28, 2023, 23:40 by andreas.rheinha...@outlook.com:
>>
>>> Andreas Rheinhardt:
>>>
Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
On Thu, Sep 28, 2023 at 05:07:17PM -0400, Vittorio Giovara wrote:
> On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer
> wrote:
>
> > On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-09-23 18:43:44)
> > > > Is a seperate library really the
On Fri, Sep 29, 2023 at 12:05:56AM +0300, Rémi Denis-Courmont wrote:
>
>
> Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer
> a écrit :
> >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2023-09-23 18:43:44)
> >> > Is a seperate
Lynne:
> Sep 28, 2023, 23:40 by andreas.rheinha...@outlook.com:
>
>> Andreas Rheinhardt:
>>
>>> Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616.
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> configure | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git
Sep 28, 2023, 23:40 by andreas.rheinha...@outlook.com:
> Andreas Rheinhardt:
>
>> Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> configure | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
Andreas Rheinhardt:
> Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index e1afcaa586..762311ae51 100755
> --- a/configure
> +++
Signed-off-by: Andreas Rheinhardt
---
libavcodec/bgmc.c | 4 ++--
libavcodec/bgmc.h | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/bgmc.c b/libavcodec/bgmc.c
index 361f7c52e6..0e41a39e00 100644
--- a/libavcodec/bgmc.c
+++ b/libavcodec/bgmc.c
@@ -457,7 +457,7
It more directly shows that ff_flac_decode_frame_header() does not
modify the AVCodecContext given to it at all; and it would not be
allowed to do so, given that it is used by the parser when it is
still unknown whether said frame header is even valid.
Signed-off-by: Andreas Rheinhardt
---
Signed-off-by: Andreas Rheinhardt
---
libavcodec/lagarith.c| 14 +++---
libavcodec/lagarithrac.h | 3 +--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/lagarith.c b/libavcodec/lagarith.c
index 3288c0517c..9574f78871 100644
--- a/libavcodec/lagarith.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavcodec/opus_silk.c | 10 +-
libavcodec/opus_silk.h | 3 +--
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
index cf8b16acff..27671516a0 100644
--- a/libavcodec/opus_silk.c
+++
Also stop setting the field once per encode-frame.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/roqvideo.c| 4 ++--
libavcodec/roqvideo.h| 4 ++--
libavcodec/roqvideodec.c | 8
libavcodec/roqvideoenc.c | 8 +++-
4 files changed, 11 insertions(+), 13 deletions(-)
diff
Signed-off-by: Andreas Rheinhardt
---
libavcodec/sipr.c | 1 -
libavcodec/sipr.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/libavcodec/sipr.c b/libavcodec/sipr.c
index 692b59b3e8..3ddc579f09 100644
--- a/libavcodec/sipr.c
+++ b/libavcodec/sipr.c
@@ -532,7 +532,6 @@ static int
In particular the encoder used only a small part of the context:
The new encoder context is only 128B here. It used to be 32992.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/utvideo.h| 35 +--
libavcodec/utvideodec.c | 28
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vorbis.c | 8 +---
libavcodec/vorbis.h | 4 +---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vorbis.c b/libavcodec/vorbis.c
index d0b660b44a..3d85997576 100644
--- a/libavcodec/vorbis.c
+++ b/libavcodec/vorbis.c
This may break some command lines, because the --disable-*
options are no longer recognized.
Signed-off-by: Andreas Rheinhardt
---
This could be squashed together with the preceding commit.
configure | 8
1 file changed, 8 deletions(-)
diff --git a/configure b/configure
index
This avoids using dct.c and will allow removing it.
Signed-off-by: Andreas Rheinhardt
---
configure | 1 -
libavcodec/Makefile | 3 ++-
libavcodec/mpegaudiodsp.c | 6 +-
libavcodec/x86/Makefile | 2 +-
libavcodec/x86/mpegaudiodsp.c | 6 ++
5 files
The AVDCT API used by this filter does in no way depend
upon the FFT subsystem.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 11f232165f..28f1753ecb 100755
--- a/configure
+++ b/configure
@@
Forgotten in 4acd08be6c4f39736179a3d90fd56b508e42ff6d.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 762311ae51..11f232165f 100755
--- a/configure
+++ b/configure
@@ -3915,7 +3915,7 @@
Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index e1afcaa586..762311ae51 100755
--- a/configure
+++ b/configure
@@ -3033,7 +3033,7 @@
From: Niklas Haas
This is mathematically equivalent to what we were doing before, but
gives subtly different results due to rounding (rows first vs columns
first). Doing it this way makes our film grain database generation match
reference implementation and now produces bit-exact outputs in my
On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer
wrote:
> On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-09-23 18:43:44)
> > > Is a seperate library really the right choice for SDR in FFmpeg at
> this stage ?
> > >
> > > Also code can
Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer
a écrit :
>On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2023-09-23 18:43:44)
>> > Is a seperate library really the right choice for SDR in FFmpeg at this
>> > stage ?
>> >
>> > Also
tor 2023-09-28 klockan 16:19 +0200 skrev Michael Niedermayer:
> Hi all
>
> I think the 2 commmittteees we have should produce an anual report
> so that the developers who vote for members know the perfomance and
> what the last comite did
> like # of cases, # of times people where contacted, %
Attached.
From 80e70d4cde1734b01809352d280f43a9d4ba79dc Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Thu, 28 Sep 2023 21:22:34 +0200
Subject: [PATCH] avcodec/ffv1*: add GBRAP14, GRAY14, YUVA422P12, YUVA444P12
formats support
Signed-off-by: Paul B Mahol
---
libavcodec/ffv1dec.c | 11
On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-09-23 18:43:44)
> > Is a seperate library really the right choice for SDR in FFmpeg at this
> > stage ?
> >
> > Also code can always be moved into an seperate library
>
> we've had postproc in the
On Thu, 28 Sep 2023 12:03:08 -0400 Vittorio Giovara
wrote:
> On Thu, Sep 28, 2023 at 11:08 AM Niklas Haas wrote:
>
> > On Wed, 27 Sep 2023 21:07:55 +0200 Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> > > where can i find the text describing this that you refer to ?
> >
> > It is
On Thu, 28 Sep 2023 20:53:44 +0200 Michael Niedermayer
wrote:
> On Wed, Sep 27, 2023 at 03:56:15PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > The spec specifies x^31 + x^3 + 1 as the polynomial, but the diagram in
> > Figure 1-1 omits the +1 offset. The initial implementation was
On Wed, Sep 27, 2023 at 03:56:15PM +0200, Niklas Haas wrote:
> From: Niklas Haas
>
> The spec specifies x^31 + x^3 + 1 as the polynomial, but the diagram in
> Figure 1-1 omits the +1 offset. The initial implementation was based on
> the diagram, but this is wrong (produces subtly incorrect
Le torstaina 28. syyskuuta 2023, 17.19.18 EEST Michael Niedermayer a écrit :
> Hi all
>
> I think the 2 commmittteees we have should produce an anual report
> so that the developers who vote for members know the perfomance and
> what the last comite did
> like # of cases, # of times people where
Le torstaina 28. syyskuuta 2023, 19.43.57 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Calling BBB, Kieran and myself dishonest is.
>
> I call your arguments dishonest.
You almost had me doubting my recollection for a minute. But:
Michael wrote:
> > People did not ask
On 14.09.2023 18:52, Roman Arzumanyan wrote:
Got it, thanks.
Please find the patches in attachment.
Just for my own understanding - could you please explain how this magic
works in the configure script? I mean this section:
if ! disabled ffnvcodec; then
Hi,
I think the 2 commmittteees we have should produce an anual report
so that the developers who vote for members know the perfomance and
what the last comite did
like # of cases, # of times people where contacted, % where committi
intervention produced a noticable improvment ...
not sure
Rémi Denis-Courmont (12023-09-28):
> Calling BBB, Kieran and myself dishonest is.
I call your arguments dishonest.
> I take that as an admission of guilt.
Take it as you want.
--
Nicolas George
signature.asc
Description: PGP signature
___
Rémi Denis-Courmont (12023-09-28):
> And this puts me in a bit of a conundrum. See, if you did figure that much
> out,
> then you would be willfully committing defamation against me, by calling me
> dishonest.
I am calling your argument dishonest. I stand by it.
>I suppose that I
Le torstaina 28. syyskuuta 2023, 19.41.06 EEST Nicolas George a écrit :
> (1) There was no violations in my message. Calling your arguments
> bullshit is not a personal attack, by definition.
Calling BBB, Kieran and myself dishonest is.
> (2) Even if there were any violation, there is nobody to
Rémi Denis-Courmont (12023-09-28):
> Literally the exact same verb even.
So what are you saying, that I noticed you moved the goalposts one
message too late?
> P.S.: Your repeated CoC violations will be reported shortly.
So, for your information:
(1) There was no violations in my message.
Le torstaina 28. syyskuuta 2023, 19.32.44 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Err, it is very much an issue w.r.t. "catching on".
>
> Moving the goalpost much.
I think obviously not, considering the original quote (EMPHASIS ADDED):
> In fact, the SDR code has
On 9/28/23, Nicolas George wrote:
> Rémi Denis-Courmont (12023-09-28):
>> Err, it is very much an issue w.r.t. "catching on".
>
> Moving the goalpost much.
>
>> Also that's an ad hominem attack, which violates the CC.
>
> No it is not.
>
> This mail is no longer part of a honest discussion, and
Le torstaina 28. syyskuuta 2023, 19.13.37 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Thanks for making my point.
>
> Stealing the other person rhetoric device does not make you right.
>
> > That does not change the fact that it won't make it any popular, and thus
> >
Rémi Denis-Courmont (12023-09-28):
> Err, it is very much an issue w.r.t. "catching on".
Moving the goalpost much.
> Also that's an ad hominem attack, which violates the CC.
No it is not.
This mail is no longer part of a honest discussion, and therefore I will
save myself the time of answering
Le torstaina 28. syyskuuta 2023, 18.28.50 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > You can repeat the contrary as much as you want, we do not believe that
> > your SDR code fits in FFmpeg. Why do you not understand this?
>
> We understand that very well. Once again,
Rémi Denis-Courmont (12023-09-28):
> Thanks for making my point.
Stealing the other person rhetoric device does not make you right.
> That does not change the fact that it won't make it any popular, and thus
> your
> postulate is wrong.
It reach more popular included in FFmpeg than if users
On Thu, Sep 28, 2023 at 11:08 AM Niklas Haas wrote:
> On Wed, 27 Sep 2023 21:07:55 +0200 Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> > where can i find the text describing this that you refer to ?
>
> It is in SMPTE RDD 5 (DOI 10.5594/SMPTE.RDD5.2006), you can find it on
> the usual
Le torstaina 28. syyskuuta 2023, 18.33.33 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Strange, I thought FFmpeg really became popular as a back-end library for
> > mplayer, before it was picked up by all other OSS multimedia at the time
> > (gstreamer, VLC, Xine, etc.).
Anton Khirnov:
> Quoting Andreas Rheinhardt (2023-09-19 21:56:56)
>> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
>> index 5657327f0c..632f5b23b2 100644
>> --- a/libavcodec/h264_slice.c
>> +++ b/libavcodec/h264_slice.c
>> @@ -363,25 +361,16 @@ int
Rémi Denis-Courmont (12023-09-28):
> Strange, I thought FFmpeg really became popular as a back-end library for
> mplayer, before it was picked up by all other OSS multimedia at the time
> (gstreamer, VLC, Xine, etc.).
Fortunately, I know the history of our projects better than you:
First,
Rémi Denis-Courmont (12023-09-28):
> You can repeat the contrary as much as you want, we do not believe that your
> SDR code fits in FFmpeg. Why do you not understand this?
We understand that very well. Once again, it is you who do not
understand something: your BELIEF that SDR does not belong
Michael Niedermayer (12023-09-28):
> I think the 2 commmittteees we have
We do not have two committees, their mandate expired more than a year
ago.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
From: Niklas Haas
Buggy ICCv4 profiles are unfortunately used in the wild, and it's quite
easy to work around them by just forcing the white point to the correct
value. Display a warning just in case.
See-Also: https://trac.ffmpeg.org/ticket/9673
---
libavcodec/fflcms2.c | 51
From: Niklas Haas
Fixes: https://trac.ffmpeg.org/ticket/9673
---
libavcodec/decode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 466c393c1e2..6f4ef7da0c2 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@
From: Niklas Haas
---
libavfilter/vf_iccdetect.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_iccdetect.c b/libavfilter/vf_iccdetect.c
index 5288b0320d2..16eacbbb560 100644
--- a/libavfilter/vf_iccdetect.c
+++ b/libavfilter/vf_iccdetect.c
@@ -93,7 +93,9
On Wed, 27 Sep 2023 21:07:55 +0200 Michael Niedermayer
wrote:
> where can i find the text describing this that you refer to ?
It is in SMPTE RDD 5 (DOI 10.5594/SMPTE.RDD5.2006), you can find it on
the usual places.
___
ffmpeg-devel mailing list
audiodsp.vector_clip_int32_c: 17500.7
audiodsp.vector_clip_int32_rvv_i32: 8404.7 (m1)
audiodsp.vector_clip_int32_rvv_i32: 2689.9 (m8)
audiodsp.vector_clipf_c: 33679.7
audiodsp.vector_clipf_rvf: 7019.7
audiodsp.vector_clipf_rvv_f32: 8328.0 (m1)
audiodsp.vector_clipf_rvv_f32: 2209.4
Le keskiviikkona 27. syyskuuta 2023, 23.27.40 EEST Nicolas George a écrit :
> Michael Niedermayer (12023-09-27):
> > With SDR they do ask for a seperate library.
>
> And they are being dishonest in that. Nothing successful starts as a
> library,
Strange, I thought FFmpeg really became popular as
Andreas Rheinhardt:
> Only used by the encoder.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/snow.c| 25 -
> libavcodec/snowenc.c | 26 ++
> 2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/libavcodec/snow.c
Le keskiviikkona 27. syyskuuta 2023, 23.18.29 EEST Michael Niedermayer a écrit
:
> And you can repeat it as often as you want, iam not interrested.
> Why do you not understand this ?
You can repeat the contrary as much as you want, we do not believe that your
SDR code fits in FFmpeg. Why do you
Hi all
I think the 2 commmittteees we have should produce an anual report
so that the developers who vote for members know the perfomance and
what the last comite did
like # of cases, # of times people where contacted, % where committi
intervention produced a noticable improvment ...
# of cases
Le 28 septembre 2023 08:45:44 GMT+03:00, flow gg a écrit
:
>Okay, I revert the volatile in ff_read_time
>
>How about this version?
It's still using register stride which is all but guaranteed to be slow on any
hardware and should only be used as a last resort.
The code is also missing
Quoting Andreas Rheinhardt (2023-09-19 21:56:57)
> Avoids allocations and error checks for these allocations;
> e.g. syncing buffers across threads can't fail any more
> and needn't be checked. It also gets rid of casts and
> indirections.
>
> Signed-off-by: Andreas Rheinhardt
> ---
>
Quoting Andreas Rheinhardt (2023-09-19 21:56:56)
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 5657327f0c..632f5b23b2 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -363,25 +361,16 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
>
Quoting Andreas Rheinhardt (2023-09-19 21:56:55)
> Avoids allocations and frees and error checks for said allocations;
> also avoids a few indirections and casts.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/avcodec.c | 3 ++-
> libavcodec/get_buffer.c| 44
fre 2023-09-15 klockan 15:10 -0300 skrev James Almer:
> On 9/13/2023 6:34 AM, Tomas Härdin wrote:
> > ons 2023-09-06 klockan 16:16 -0300 skrev James Almer:
> > > On 9/6/2023 2:53 PM, Tomas Härdin wrote:
> > > > ons 2023-09-06 klockan 11:38 -0300 skrev James Almer:
> > > > > Signed-off-by: James
tis 2023-09-19 klockan 17:12 +0200 skrev Michael Riedl:
> MXF muxer requires rangecoder otherwise static linking fails.
>
> Signed-off-by: Michael Riedl
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index
ons 2023-09-27 klockan 23:12 +0200 skrev Michael Niedermayer:
> Hi
>
> On Wed, Sep 27, 2023 at 01:37:40PM +0200, Tomas Härdin wrote:
> > fre 2023-09-22 klockan 21:13 +0200 skrev Michael Niedermayer:
> > > Suggested-by: Tomas Härdin
> > > Fixes: 51896/clusterfuzz-testcase-minimized-
> > >
Quoting Michael Niedermayer (2023-09-21 20:09:12)
> Fixes: leak
> Fixes:
> 62164/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6674082962997248
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
Martin Storsjö:
> On Tue, 26 Sep 2023, Andreas Rheinhardt wrote:
>
>> Martin Storsjö:
>>> On Tue, 26 Sep 2023, Anton Khirnov wrote:
>>>
Quoting Andreas Rheinhardt (2023-09-26 01:54:30)
> It is of no value to the user, because every muxer can always
> be flushed with a NULL packet. As
Quoting Michael Niedermayer (2023-09-23 18:43:44)
> Is a seperate library really the right choice for SDR in FFmpeg at this stage
> ?
>
> Also code can always be moved into an seperate library
we've had postproc in the tree for ages, nobody maintains it or
cares about it, yet it seems
What list would you suggest instead, main?
The command was just a snipped, normally would do something like this:
/usr/bin/ffmpeg -i "/home/robin/dolby_vision_test_8_1 - [2160p].mp4"
-map 0:0 -c:v libx265 -preset slower -ss 00:00:00 -to 00:00:10 -crf 20
-vf
Quoting Andreas Rheinhardt (2023-09-26 11:17:25)
> James Almer:
> > On 9/25/2023 8:55 PM, Andreas Rheinhardt wrote:
> >> It is also used by AVCodecContext.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> doc/APIchanges | 3 +++
> >> libavcodec/codec_par.h | 10 +-
>
On Wed, Sep 27, 2023 at 07:24:50PM +0200, Paul B Mahol wrote:
> Attached.
> pixdesc.c | 28
> pixfmt.h |4
> 2 files changed, 32 insertions(+)
> dc323faf13db2ffbefdd8ce2c25ba3a97633e0eb
> 0001-avutil-add-GBRAP14-format-support.patch
> From
Quoting Paul B Mahol (2023-09-28 11:48:14)
> On 9/28/23, Anton Khirnov wrote:
> > Quoting Paul B Mahol (2023-09-27 21:53:54)
> >> Attached.
> >>
> >> From 6b7e51e2b4facead9c45fb94647c85b58e6fdf22 Mon Sep 17 00:00:00 2001
> >> From: Paul B Mahol
> >> Date: Wed, 27 Sep 2023 21:48:49 +0200
> >>
Robin van der Linden via ffmpeg-devel:
> Hello,
>
> I've observed that the "-x265-params dolby-vision-rpu /path/to/rpu"
> doesn't seem to work in my ffmpeg command. Though the libx265
> documentation indicates the presence of this parameter, ffmpeg appears
> to be having trouble recognizing it.
Hello,
I've observed that the "-x265-params dolby-vision-rpu /path/to/rpu"
doesn't seem to work in my ffmpeg command. Though the libx265
documentation indicates the presence of this parameter, ffmpeg appears
to be having trouble recognizing it. In fact, ffmpeg reports it as an
unknown
On 9/28/23, Anton Khirnov wrote:
> Quoting Paul B Mahol (2023-09-27 21:53:54)
>> Attached.
>>
>> From 6b7e51e2b4facead9c45fb94647c85b58e6fdf22 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Wed, 27 Sep 2023 21:48:49 +0200
>> Subject: [PATCH] avcodec/photocd: allow decoding vlc with
When linking the main tools, the object files to link are set up
via the variable OBJS-, but for the tools, we've only
used the target's list of dependencies.
In most cases, this has been fine, but it has caused specifying
the libraries to link in a duplicate fashion; the linking command
has
Quoting Paul B Mahol (2023-09-27 21:53:54)
> Attached.
>
> From 6b7e51e2b4facead9c45fb94647c85b58e6fdf22 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Wed, 27 Sep 2023 21:48:49 +0200
> Subject: [PATCH] avcodec/photocd: allow decoding vlc with errors
>
> Also rename option that no longer
Hi Vignesh,
On Thu, Sep 28, 2023 at 12:14 AM Vignesh Venkatasubramanian via
ffmpeg-devel wrote:
> SVT-AV1 does not support requesting keyframes at arbitrary points
> by setting pic_type to EB_AV1_KEY_PICTURE.
>
> This patch changes the following:
> * Set pic_type to EB_AV1_KEY_PICTURE only
Hi,
On Wed, Sep 27, 2023 at 10:27 PM Nicolas George wrote:
> Michael Niedermayer (12023-09-27):
> > With SDR they do ask for a seperate library.
>
> And they are being dishonest in that. Nothing successful starts as a
> library
>
Didn't dav1d start as a library? (Or maybe it's not very
杨亚磊 via ffmpeg-devel (12023-09-14):
> Hello everyone.
> I submitted a patch, the details are as follows:
>
> framequeue: Remove redundant logic code
>
> In this logical branch, fq->queued and fq->allocated must be equal.
> Deleting this code will make it easier to understand
79 matches
Mail list logo
