Quoting Paul B Mahol (2021-02-16 21:57:47)
> Do you have actual proof for such claims?
The burden of proof is on you here - you are supposed to prove that your
commit fixes something. And when I asked you about details, you couldn't
even tell me what the bug was, much less why would switching the
The FATE suite already contains a file containing mastering display
and content light level metadata: Meridian-Apple_ProResProxy-HDR10.mxf
This file is used to test both the Matroska muxer and demuxer.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/matroska.mak | 15 +++
Up until now, the generic EBML reader used by the Matroska demuxer did
not have the capability to record whether an element was actually
present or not; instead, in cases where it mattered one typically added
an invalid default value and checked whether the value is valid (in
which case it is guara
In the absence of an explicitly coded minimal luminance, the current
code inferred it to be -1, an invalid value. Yet it did not check the
value lateron at all, so that if a valid maximum luminance is
encountered, but no minimal luminance, an invalid minimal luminance of
-1 is exported. If an minim
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 786fa41cba..746c0b347a 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1191,6 +1191,8 @@ sta
Needs a CountedElement in order to distinguish the case of the element
not being present and the element being present with a value of zero.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroska.h| 1 +
libavformat/matroskadec.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(
This has been done in order to find out whether this element is present
at all; but this can now be done in a cleaner way by using a CountedElement
for it.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/li
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index bfc6641a5f..636ed23f0d 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matros
This is the equivalent of the WebM "D_WEBVTT/DESCRIPTIONS" and is
therefore only exported for subtitles.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroska.h| 1 +
libavformat/matroskadec.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/matrosk
This provides coverage for writing BlockGroups with BlockAdditional
and ReferenceBlock elements. It also tests setting the hearing impaired
disposition (it fits given that this video has no audio so one needs to
be able to read lips to understand anything).
Signed-off-by: Andreas Rheinhardt
---
The tests also test the other dispositions: commentary, descriptions
as well as dub and original language. Furthermore they test e.g. muxing
alac in Matroska.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/matroska.mak | 23 +
tests/ref/fate/matroska-mpegts-remux | 52 ++
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 0dd093ae8b..86ffb51051 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1198,6 +1198,10 @@
Given that our disposition flags provide no way to distinguish the
cases of "track is unsuitable for hearing impaired users" and "it is
unknown whether the track is suitable for hearing impaired users" we do
not need to use a CountedElement for these flags.
Signed-off-by: Andreas Rheinhardt
---
According to the new EBML specifications, a string element of length
zero would be read as the default value by a compliant parser.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskaenc.c b/liba
Hint: Matroska actually provides a way to distinguish the cases of
"track is no commentary track" and "it is unknown whether the track
is a commentary track", but our disposition flags do not. Therefore
we need not use a CountedElement.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroska.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 746c0b347a..0dd093ae8b 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1193,6 +1193,12 @
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 636ed23f0d..b9c6047f56 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskad
Signed-off-by: Andreas Rheinhardt
---
tests/fate/matroska.mak | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
index b907da40f3..c7da2465b5 100644
--- a/tests/fate/matroska.mak
+++ b/tests/fate/matroska.mak
@@ -129,3 +129,5 @@ fate-matroska-s
This is the Matroska equivalent of D_WEBVTT_DESCRIPTIONS and is
therefore only enabled for subtitles.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 86ffb51051..4242
For a very long time, the payload of integer and float elements had to
have a length > 0. Our parser treated such invalid elements as having a
value zero. But now it has been defined what an EBML element with length
zero means: It is a shorthand for the default value. This has also been
defined for
On Fri, 12 Feb 2021, Martin Storsjö wrote:
This is much less precise than the cycle counter register, but
the cycle counter register is not available on apple platforms
(and on linux, it requires a kernel module for allowing user mode
access).
---
libavutil/aarch64/timer.h | 8 +++-
libavutil
On Wed, Feb 17, 2021 at 9:14 AM Anton Khirnov wrote:
> Quoting Paul B Mahol (2021-02-16 21:57:47)
> > Do you have actual proof for such claims?
>
> The burden of proof is on you here - you are supposed to prove that your
> commit fixes something. And when I asked you about details, you couldn't
>
On Tue, Feb 16, 2021 at 9:26 PM Anton Khirnov wrote:
> Current code is very confused and confusing. It uses two different
> reference frames - "previous" and "last" - when only one is really
> necessary. It also confuses the two, leading to incorrect output with
> APNG_DISPOSE_OP_PREVIOUS mode.
>
Wonkap Jang (12021-02-16):
> While parsing ref_frame_config, AVdictionary needs to be manually
> deallocated.
> ---
> libavcodec/libvpxenc.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
NAK.
This code is all wrong, it looks like Java or Python, it should not be
us
On Wed, 17 Feb 2021, at 11:45, Paul B Mahol wrote:
> > It didn't fix anything though. Before your commit, frame 69 of the
> > sample in #9017 is almost black with 1 thread and looks okay with 2
> > threads. After your commit, it is almost black in both cases. So your
> > commit made it consistently
> Could you elaborate?
> I would have expected that the normal use case is not have a
> lossy input and that the new feature is always useful if data
> was lost.
The use-case for FEC is typically RTP stream where audio is compressed
with opus. In that case, depending on the network conditions, pac
>> Am Di., 16. Feb. 2021 um 15:02 Uhr schrieb Philip-Dylan Gleonec
>> :
>>
>>>
>>> Adds FEC/PLC support to libopus. The lost packets are detected as a
>>> discontinuity in the audio stream. When a discontinuity is used, this
>>> patch tries to decode the FEC data. If FEC data is present in the
>>>
> I've added him to the CC list
Now done.
___
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".
Philip-Dylan Gleonec:
>> Could you elaborate?
>> I would have expected that the normal use case is not have a
>> lossy input and that the new feature is always useful if data
>> was lost.
>
> The use-case for FEC is typically RTP stream where audio is compressed
> with opus. In that case, dependin
Quoting Paul B Mahol (2021-02-17 11:45:02)
> On Wed, Feb 17, 2021 at 9:14 AM Anton Khirnov wrote:
>
> > Quoting Paul B Mahol (2021-02-16 21:57:47)
> > > Do you have actual proof for such claims?
> >
> > The burden of proof is on you here - you are supposed to prove that your
> > commit fixes some
Nicolas George (12020-11-30):
> Good idea, thanks.
Pushed.
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,
Quoting Paul B Mahol (2021-02-17 11:52:31)
> On Tue, Feb 16, 2021 at 9:26 PM Anton Khirnov wrote:
> > @@ -1088,23 +1084,23 @@ static int handle_p_frame_apng(AVCodecContext
> > *avctx, PNGDecContext *s,
> > if (!buffer)
> > return AVERROR(ENOMEM);
> >
> > +ff_thread_await_progress
James Almer (12021-02-01):
> I support the idea of it being a build option (Perhaps simply
> --enable-libev, like any other external dep). There's a precedent of
> external libraries being used as backend for certain features, with the most
> prominent example being libsoxr as the resample engine i
Hello,
I am Sanskar Khandelwal, a 3rd year undergrad student ,I am interested in
contributing to ffmpeg and also participating in gsoc along with this year.
I have a few questions if someone can answer them and help me get started
it'll be nice.
1. Is this a right platform to ask questions, I saw
On Wed, Feb 17, 2021 at 12:31 PM Anton Khirnov wrote:
> Quoting Paul B Mahol (2021-02-17 11:45:02)
> > On Wed, Feb 17, 2021 at 9:14 AM Anton Khirnov wrote:
> >
> > > Quoting Paul B Mahol (2021-02-16 21:57:47)
> > > > Do you have actual proof for such claims?
> > >
> > > The burden of proof is on
On Wed, Feb 17, 2021 at 12:33 PM Anton Khirnov wrote:
> Quoting Paul B Mahol (2021-02-17 11:52:31)
> > On Tue, Feb 16, 2021 at 9:26 PM Anton Khirnov wrote:
> > > @@ -1088,23 +1084,23 @@ static int handle_p_frame_apng(AVCodecContext
> > > *avctx, PNGDecContext *s,
> > > if (!buffer)
> > >
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/exr_parser.c | 217
libavcodec/parsers.c| 1 +
3 files changed, 219 insertions(+)
create mode 100644 libavcodec/exr_parser.c
diff --git a/libavcodec/Makefile b/libavcodec/M
Feb 17, 2021, 12:47 by geo...@nsup.org:
> James Almer (12021-02-01):
>
>> I support the idea of it being a build option (Perhaps simply
>> --enable-libev, like any other external dep). There's a precedent of
>> external libraries being used as backend for certain features, with the most
>> promine
Lynne (12021-02-17):
> I think I'd prefer an asynchronous library rather than libev.
> So libuv?
I have on occasion straced node to debug things, and what I have
observed is: I don't want to touch it even with a very long stick.
Wan you explain more precisely why you think libuv would be a better
Hi,
while looking into mediacodec for unrelated reasons I saw some room for
improvement.
Therefore, here's a series with two small patches.
>From cadd2b2d4a5ffbb4dcc34faf2d3e139e1d4d608b Mon Sep 17 00:00:00 2001
From: sfan5
Date: Thu, 11 Feb 2021 19:23:26 +0100
Subject: [PATCH 1/2] avcodec/m
>From 22ebde779f61fb030633a881ef320264ea446b6b Mon Sep 17 00:00:00 2001
From: sfan5
Date: Thu, 11 Feb 2021 20:48:54 +0100
Subject: [PATCH 2/2] avcodec/mediacodec_wrapper: use
MediaCodecInfo.isSoftwareOnly() when available
Added in Android 10 it provides a reliable way of filtering out
software
Hi,
I've noticed that the MxPEG decoder fails to read a video stream if the
bitmask used to track updated blocks has a length which is not a multiple
of 8. The attached patch provides a tentative fix.
Best,
Gabriele
0001-Fix-test-for-complete-frame-in-MxPEG-decoder.patch
Description: Binary d
x86_32 ABI does not pass float arguments directly on xmm regs, and the Win64
ABI uses only the first four regs for this purpose.
Signed-off-by: James Almer
---
libavfilter/vf_gblur.c | 3 +--
libavfilter/x86/vf_gblur.asm | 29 +
2 files changed, 14 insertions(+
Signed-off-by: James Almer
---
tests/checkasm/vf_gblur.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tests/checkasm/vf_gblur.c b/tests/checkasm/vf_gblur.c
index 8ff47a338f..b9fe2f9a36 100644
--- a/tests/checkasm/vf_gblur.c
+++ b/tests/checkasm/vf_gblur.c
@@ -16,6 +
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
probably ok if tested
___
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".
Hi Nicolas,
On Wed, Feb 17, 2021 at 3:00 AM Nicolas George wrote:
> Wonkap Jang (12021-02-16):
> > While parsing ref_frame_config, AVdictionary needs to be manually
> > deallocated.
> > ---
> > libavcodec/libvpxenc.c | 19 ---
> > 1 file changed, 12 insertions(+), 7 deletions(-)
On Wed, Feb 17, 2021 at 8:52 AM Wonkap Jang wrote:
> Hi Nicolas,
>
> On Wed, Feb 17, 2021 at 3:00 AM Nicolas George wrote:
>
>> Wonkap Jang (12021-02-16):
>> > While parsing ref_frame_config, AVdictionary needs to be manually
>> > deallocated.
>> > ---
>> > libavcodec/libvpxenc.c | 19 +
On 2/17/2021 1:47 PM, Paul B Mahol wrote:
probably ok if tested
Set pushed. 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...
Fixes: left shift of negative value -1
Fixes:
30714/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4867823371419648
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cfhd.c | 4 ++
While parsing ref_frame_config, AVdictionary needs to be manually
deallocated.
---
libavcodec/libvpxenc.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 284cb9a108..56a1b5aafe 100644
--- a/libavcodec/
Wonkap Jang (12021-02-17):
> Or are you saying after getting the string with en->value, I should just
> parse through the string without dictionary?
Yes, exactly.
You would use a dictionary if you need to keep all the values for a
later use. But in this case, there is no later use, you only itera
Wonkap Jang (12021-02-17):
> While parsing ref_frame_config, AVdictionary needs to be manually
> deallocated.
> ---
> libavcodec/libvpxenc.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 284c
On Wed, Feb 17, 2021 at 01:41:04PM -0300, James Almer wrote:
> x86_32 ABI does not pass float arguments directly on xmm regs, and the Win64
> ABI uses only the first four regs for this purpose.
>
> Signed-off-by: James Almer
> ---
> libavfilter/vf_gblur.c | 3 +--
> libavfilter/x86/vf_gbl
On 2/17/2021 3:34 PM, Michael Niedermayer wrote:
On Wed, Feb 17, 2021 at 01:41:04PM -0300, James Almer wrote:
x86_32 ABI does not pass float arguments directly on xmm regs, and the Win64
ABI uses only the first four regs for this purpose.
Signed-off-by: James Almer
---
libavfilter/vf_gblur.c
On Tue, Feb 02, 2021 at 10:48:13AM +0100, Michael Niedermayer wrote:
> Hi all
>
> Most people probably already know but just to be sure everyone knows
> GSoC 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
>
> Some project ideas may need to be
On Sun, Feb 14, 2021 at 12:27 PM Christopher Degawa
wrote:
> That said, if you have a general use-case where this is helpful and the
>> documentation explains what it is doing (and warns about the bad cases)
>> then maybe?
>>
>
> The main use case we have internally is to able to run multiple ins
---
libavformat/dashenc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 2d757b3a87..fbdee126e9 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -844,7 +844,11 @@ static int write_adaptation_set(AVFormat
Hello Sanskar
On Wed, Feb 17, 2021 at 06:54:05PM +0530, Sanskar Khandelwal wrote:
> Hello,
>
> I am Sanskar Khandelwal, a 3rd year undergrad student ,I am interested in
> contributing to ffmpeg and also participating in gsoc along with this year.
> I have a few questions if someone can answer the
Will come in handy for the following commit.
Signed-off-by: James Almer
---
tests/checkasm/vf_gblur.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/tests/checkasm/vf_gblur.c b/tests/checkasm/vf_gblur.c
index 1d63fc22a0..8ff47a338f 100644
--- a
On Wed, Feb 17, 2021 at 9:50 AM Nicolas George wrote:
> Wonkap Jang (12021-02-17):
> > While parsing ref_frame_config, AVdictionary needs to be manually
> > deallocated.
> > ---
> > libavcodec/libvpxenc.c | 21 +
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > di
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/imx.c| 160 +++
3 files changed, 162 insertions(+)
create mode 100644 libavformat/imx.c
diff --git a/libavformat/Makefile b/libavformat/Mak
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/codec_id.h | 1 +
libavcodec/imx.c| 153
5 files changed, 163 insertions(+)
create mode 100644 libav
Will apply with these issues fixed soon.
___
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".
Hi all
If you mentored a project in 2020, please fill the results on the results page
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results
Its empty ATM and previous years it was filled
If you where a student of 2020 you can of course fill in your projects results
too :)
also anyon
On Tue, Feb 16, 2021 at 6:31 PM Alan Kelly <
alankelly-at-google@ffmpeg.org> wrote:
> Looks like there are no comments, is this OK to be applied? Thanks
>
Applied, thanks for pinging.
>
> On Tue, Feb 9, 2021 at 6:25 PM Paul B Mahol wrote:
>
> > Will apply in no comments.
> > __
On 01/02/2021 19:14, Nicolas George wrote:
Based on this discussion, I say that the need for an event loop is
confirmed.
I will now start discussing actual plans for going forward. Since the
coding work will be significant and not incremental, I want the outcome
of this discussion to be binding:
Mark Thompson (12021-02-17):
> I can see that this is all sensible stuff on Unix, but can you explain
> a bit more of what your Windows implementation is going to look like?
I have no intention to write Windows code for this. Our current
protocols use poll() internally, this event loop will do the
Feb 17, 2021, 15:38 by geo...@nsup.org:
> Lynne (12021-02-17):
>
>> I think I'd prefer an asynchronous library rather than libev.
>> So libuv?
>>
>
> I have on occasion straced node to debug things, and what I have
> observed is: I don't want to touch it even with a very long stick.
>
> Wan you ex
On 17/02/2021 18:58, Christopher Degawa wrote:
On Sun, Feb 14, 2021 at 12:27 PM Christopher Degawa
wrote:
That said, if you have a general use-case where this is helpful and the
documentation explains what it is doing (and warns about the bad cases)
then maybe?
The main use case we have in
On 17/02/2021 20:57, Nicolas George wrote:
Mark Thompson (12021-02-17):
I can see that this is all sensible stuff on Unix, but can you explain
a bit more of what your Windows implementation is going to look like?
I have no intention to write Windows code for this. Our current
protocols use pol
On Tue, Feb 16, 2021 at 03:53:08PM +, Jeremy Leconte wrote:
> ---
> libavfilter/vf_scale.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index 58eee96744..98cef5eb4b 100644
> --- a/libavfilter/vf_scale.c
> +++ b/liba
On 17/02/2021 01:51, Nuo Mi wrote:
---
libavcodec/vvc.h | 142 +++
1 file changed, 142 insertions(+)
create mode 100644 libavcodec/vvc.h
diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
new file mode 100644
index 00..ca15297d7a
--- /dev/nu
Michael Niedermayer:
> On Tue, Feb 16, 2021 at 03:53:08PM +, Jeremy Leconte wrote:
>> ---
>> libavfilter/vf_scale.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
>> index 58eee96744..98cef5eb4b 100644
>> --- a/libavf
On 17/02/2021 01:51, Nuo Mi wrote:
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/vvcdec.c | 61
3 files changed, 63 insertions(+)
create mode 100644 libavformat/vvcdec.c
diff --git a/libavformat/Makefile b/li
---
Open for bikeshedding, as I'm not too sure of
the names, but I didn't want to use anything
too close to regular AV_CODEC_ID* defines.
libavformat/avisynth.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.
On 06/02/2021 22:04, Paul B Mahol wrote:
Trivial, thus lgtm.
Rebased and applied, apologies for the delay.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit l
Stephen Hutchinson:
> ---
> Open for bikeshedding, as I'm not too sure of
> the names, but I didn't want to use anything
> too close to regular AV_CODEC_ID* defines.
> libavformat/avisynth.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/libavforma
---
libavformat/avisynth.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index f029a0e842..4cd6d6bc90 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -42,6 +42,13 @@
#define AVISYNTH_LIB A
On 17/02/2021 01:51, Nuo Mi wrote:
---
configure |2 +
libavcodec/Makefile |1 +
libavcodec/cbs.c |6 +
libavcodec/cbs_h2645.c| 541 -
libavcodec/cbs_h266.h | 817 +++
l
On 17/02/2021 01:51, Nuo Mi wrote:
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/parsers.c| 1 +
libavcodec/vvc_parser.c | 310
4 files changed, 313 insertions(+)
create mode 100644 libavcodec/vvc_parser.c
Getting rid of unnecessary use of AVDictionary object in parsing
vpx_svc_ref_frame_config.
---
libavcodec/libvpxenc.c | 76 --
1 file changed, 58 insertions(+), 18 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 284cb9a108..a
>
> It does seem like the number correlates somehow with how much CPU it
> uses, but it's not an upper bound.
>
If it isn't, then that might be an issue, but the idea is that with the
logical_processor option you can limit the amount of ram a single encoder
instance will use since on a system wit
Forgotten in 604fbb3132e88727e496c96c92cfe02748c25a1a.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
libavcodec/Makefile | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure b/configure
index a76c2ec4ae..c28a7403db 100755
--- a/configure
+++ b/config
It does not need dca.c.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f43e717714..92a3dcf0fc 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -276,7 +276,7
The avrn decoder does not use any internals of the MJPEG decoder since
e0031ca29a471c4a540ba2e01b3f81af03ef757b.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avrndec.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/avrndec.c b/libavcodec/avrndec.c
index d85e3c2000..9380d8688
It only existed because some code in mjpegenc_common.c relied on it;
yet said code was actually only used by mjpegenc.c and has been moved
there.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 21139b
The avrn decoder actually only needs one thing: The MJPEG decoder.
Instead the Makefile made it compile mjpegdec and configure required
some of the prerequisites of the MJPEG decoder (exif and jpegtables).
Even if all the prerequisites of the MJPEG decoder were required, it
would still not make the
The MJPEG decoder is already activated by configure whenever the tiff
decoder is selected; ergo it is unnecessary to add a dependency in the
Makefile.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/Makefile
Signed-off-by: Andreas Rheinhardt
---
libavcodec/scpr3.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/libavcodec/scpr3.c b/libavcodec/scpr3.c
index 1ed764baa1..78c58889cb 100644
--- a/libavcodec/scpr3.c
+++ b/libavcodec/scpr3.c
@@ -524,32 +524,16 @
While just at it, remove the nb_codes parameter: It is redundant
(the number of codes is implicitly contained in the array containing how
many entries of a specific size there are) and for this reason it might
even be wrong, so it is better to check what is actually used instead.
Signed-off-by: An
Unneeded since f96a653184e63cea91e08ea75ae60d309e431f40 and
b2bb09bcc330156e9d79d7ddfa59f9c5d05ca149.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8a835a26ab..24725d8666 100644
--- a/l
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4audio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index 77cf2fb61c..2286303b54 100644
--- a/libavcodec/mpeg4audio.c
+++ b/libavcodec/mpeg4audio.c
@@ -30,7 +30,7
Since g2meet.c doesn't use it any more, only encoders use it and
the place for their common code is mjpegenc_common.c.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/jpegtables.c | 21 -
libavcodec/jpegtables.h | 4
libavcodec/mjpegenc_common.c | 21
This is a result of the mov channel parsing stuff being factored out
of mov.c twice: Once in 91b782720fd0df5571775b6591bc41797d6ecf78
to isom.c and later in 3bab7cd12802dc5abf2c5cc6dec49e9e249ce204.
Also remove the isom.h header; and while just at it, remove an unused
mathematics.h inclusion.
(is
This allows to make ff_init_uni_ac_vlc static;
ff_mjpeg_encode_picture_frame has also been made static, but it could
always have been made static.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ljpegenc.c| 2 +
libavcodec/mjpegenc.c| 191 +-
li
Only the mjpeg and amv encoders as well as its testprogram actually need
it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c427de78be..8a835a26ab 100644
--- a/libavco
There is another ff_mov_read_chan in mov_chan.c.
Signed-off-by: Andreas Rheinhardt
---
libavformat/isom.c | 39 ---
1 file changed, 39 deletions(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index e0e50f71b1..df98779149 100644
--- a/libavformat/isom
Also saves a relocation.
Signed-off-by: Andreas Rheinhardt
---
libavformat/au.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/au.c b/libavformat/au.c
index 4f2b81119f..c2c1b7a3a3 100644
--- a/libavformat/au.c
+++ b/libavformat/au.c
@@ -53,6 +53,8 @@ static
Also saves relocations.
Signed-off-by: Andreas Rheinhardt
---
libavformat/asfenc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/asfenc.c b/libavformat/asfenc.c
index 8b24264c94..23a09efe05 100644
--- a/libavformat/asfenc.c
+++ b/libavformat/asfenc.
1 - 100 of 114 matches
Mail list logo
