> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Pedro Arthur
> Sent: Friday, September 20, 2019 11:14 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/dnn: add layer maximum for
> n
This bug has been introduced in 9e0a071e.
Signed-off-by: Andreas Rheinhardt
---
libavutil/opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 35dc9e153d..7c2649725f 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1200,7 +1200,7
From: Jun Zhao
add chan_config check to avoid indeterminate channels.
Signed-off-by: Jun Zhao
---
libavcodec/mpeg4audio.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index 2197147..0ada239 100644
--- a/libavcodec
Am Do., 19. Sept. 2019 um 09:10 Uhr schrieb Tomas Härdin :
> Non-free originally came to be because of fdk-aac, which is open
> source but doesn't meet the requirements of the (L)GPL.
How is that different from libg7221?
Carl Eugen
___
ffmpeg-devel mai
Carl Eugen Hoyos (12019-09-21):
> > Non-free originally came to be because of fdk-aac, which is open
> > source but doesn't meet the requirements of the (L)GPL.
> How is that different from libg7221?
libg7221 is not open-source, AFAICT.
Regards,
--
Nicolas George
signature.asc
Description:
Am Sa., 21. Sept. 2019 um 13:41 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > > Non-free originally came to be because of fdk-aac, which is open
> > > source but doesn't meet the requirements of the (L)GPL.
> > How is that different from libg7221?
>
> libg7221 is not open-sou
Carl Eugen Hoyos (12019-09-21):
> Could you elaborate?
I can point you to the license file:
https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpe
Am Sa., 21. Sept. 2019 um 13:56 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > Could you elaborate?
>
> I can point you to the license file:
>
> https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING
So what is the difference between open-source software
Carl Eugen Hoyos (12019-09-21):
> So what is the difference between open-source software with a license
> incompatible
> with the GPL and an open-source software with a license incompatible
> with the GPL?
Please fix your question. As it is, it is absurd.
Regards,
--
Nicolas George
signatur
Am Sa., 21. Sept. 2019 um 14:29 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > So what is the difference between open-source software with a license
> > incompatible
> > with the GPL and an open-source software with a license incompatible
> > with the GPL?
>
> Please fix your
Carl Eugen Hoyos (12019-09-21):
> Both libraries are open-source
Please re-read my mail from 13:41:34 +0200 and the license I pointed at
13:55:53 +0200.
And just in case you managed to stay for more than a decade contributing
to an open-source project without knowing what it means, read the Open
Am Sa., 21. Sept. 2019 um 14:35 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > Both libraries are open-source
>
> Please re-read my mail from 13:41:34 +0200 and the license I pointed at
> 13:55:53 +0200.
>
> And just in case you managed to stay for more than a decade contribut
From: Limin Wang
With the patch, we simply reuse the same source chroma line for each pair
of lines in the output and the yuv420 and yuv420p10 format of the decoder
can go to the v210 encoder without having to touch the pixels at all with
autoscale by swscale filter.
The end effect is swscale fi
Carl Eugen Hoyos (12019-09-21):
> Thanks for the repeated ad-hominem
Repeated?
> but are you sure that you are not
> mixing up Free Software and Open Source?
Are you sure you know the difference between Free Software and Open
Source? This question shows that you do not. There is almost no
practi
Am Sa., 21. Sept. 2019 um 14:43 Uhr schrieb Nicolas George :
> There is almost no practical difference between Free Software
> and Open Source.
This is obviously not true as there are licenses that - for example -
only allow non-commercial distribution.
Carl Eugen
___
Carl Eugen Hoyos (12019-09-21):
> This is obviously not true as there are licenses that - for example -
> only allow non-commercial distribution.
They are therefore not Open Source. You obviously have acquired less
documentation about the subject than me: I ask that you either trust
that I am righ
Am Sa., 21. Sept. 2019 um 14:48 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > This is obviously not true as there are licenses that - for example -
> > only allow non-commercial distribution.
>
> They are therefore not Open Source. You obviously have acquired less
> documenta
Carl Eugen Hoyos (12019-09-21):
> The FSF does make a difference between open-source software and
> free software, I believe they are more qualified than you are.
The FSF is known to make a fuss about minute details. But in this case
you are wrong and I was right. Please read about it.
Regards,
On Sat, Sep 21, 2019 at 19:29:47 +0800, Jun Zhao wrote:
> +else {
> +av_log(NULL, AV_LOG_ERROR, "Invalid chan_config %d\n",
> c->chan_config);
> +return -1;
> +}
I know the function definition says it returns -1 on error, but that's
already not the case: It can return AVER
Am Sa., 21. Sept. 2019 um 15:03 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > The FSF does make a difference between open-source software and
> > free software, I believe they are more qualified than you are.
>
> The FSF is known to make a fuss about minute details. But in th
Carl Eugen Hoyos (12019-09-21):
> But I wonder now which specific part of the OSI definition is not met
> by libg7221 in your opinion?
Read the license, read the OSD.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-d
Am Sa., 21. Sept. 2019 um 14:42 Uhr schrieb :
>
> From: Limin Wang
>
> With the patch, we simply reuse the same source chroma line for each pair
> of lines in the output
Is there really no quality hit for a 20% speed-up?
Carl Eugen
___
ffmpeg-devel mai
Am Sa., 21. Sept. 2019 um 15:11 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > But I wonder now which specific part of the OSI definition is not met
> > by libg7221 in your opinion?
>
> Read the license, read the OSD.
I did and I ask you.
Note that in this case, cutting the
Carl Eugen Hoyos (12019-09-21):
> I did and I ask you.
Please tell me how you can think that "require the licencing of patents
from Polycom" is compatible with "shall not restrict any party from
selling or giving away the software"?
> Note that in this case, cutting the remaining message seems no
Michael Niedermayer (12019-09-06):
> Fixes: signed integer overflow: 9223371075321077760 * 2 cannot be represented
> in type 'long'
> Fixes:
> 16447/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5698937431785472
>
> Found-by: continuous fuzzing process
> https://github.co
Am Sa., 21. Sept. 2019 um 15:19 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > I did and I ask you.
>
> Please tell me how you can think that "require the licencing of patents
> from Polycom" is compatible with "shall not restrict any party from
> selling or giving away the so
Carl Eugen Hoyos (12019-09-21):
> I now wonder if this isn't much nicer than "You may use this FDK AAC
> Codec software or modifications thereto only for purposes that are
> authorized by appropriate patent licenses."
> (In the sense that it doesn't try to conceal the true terms)
It is not "nicer"
Am Sa., 21. Sept. 2019 um 16:07 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12019-09-21):
> > I now wonder if this isn't much nicer than "You may use this FDK AAC
> > Codec software or modifications thereto only for purposes that are
> > authorized by appropriate patent licenses."
> > (In th
Carl Eugen Hoyos (12019-09-21):
> Interesting how different we interpret the licenses.
There should be no interpreting a license: it is a legal document, what
counts is what is written explicitly.
> I believe you misunderstand.
You are entitled to your beliefs. Let us discuss arguments on this
m
Am Sa., 21. Sept. 2019 um 16:25 Uhr schrieb Nicolas George :
> > I believe you misunderstand.
>
> You are entitled to your beliefs. Let us discuss arguments on this
> mailing-list.
>
> Can we close the subject now?
And again, you cut the relevant part:
Are you maybe less interested in arguments t
Carl Eugen Hoyos (12019-09-21):
> And again, you cut the relevant part:
> Are you maybe less interested in arguments than you claim?
> Or just having a bad day?
I am having a bad day because I find this very discussion with you very
annoying. If you have anything to add to the discussion, do it in
On Sat, Sep 21, 2019 at 03:13:46PM +0200, Carl Eugen Hoyos wrote:
> Am Sa., 21. Sept. 2019 um 14:42 Uhr schrieb :
> >
> > From: Limin Wang
> >
> > With the patch, we simply reuse the same source chroma line for each pair
> > of lines in the output
>
> Is there really no quality hit for a 20% spee
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/filters.texi | 2 ++
libavfilter/vf_framerate.c | 17 +++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index bbfdad4..fce4ef4 100644
--- a/doc/filters.texi
+++ b/do
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/framerate.h| 3 +--
libavfilter/vf_framerate.c | 58 +-
2 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/libavfilter/framerate.h b/libavfilter/framerate.h
index 3d8200b..8
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/framerate.h| 1 +
libavfilter/vf_framerate.c | 35 +--
2 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/libavfilter/framerate.h b/libavfilter/framerate.h
index 8048dfa..3d8200b 100644
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_framerate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 6383f69..59d58e7 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@
Hi,
On Sat, Sep 21, 2019 at 10:07 AM Nicolas George wrote:
> Carl Eugen Hoyos (12019-09-21):
> > I now wonder if this isn't much nicer than "You may use this FDK AAC
> > Codec software or modifications thereto only for purposes that are
> > authorized by appropriate patent licenses."
> > (In the
lgtm
On 9/21/19, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_framerate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
> index 6383f69..59d58e7 100644
>
Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje
:
> So it appears, from the discussion (..), that although there is source
> code, it is not actually "open" in the sense that it's not redistributable
> (at least not explicitly so) or modifiable? If I were hosting a copy on,
> say, git
On 9/21/2019 10:07 AM, Moritz Barsnick wrote:
> On Sat, Sep 21, 2019 at 19:29:47 +0800, Jun Zhao wrote:
>> +else {
>> +av_log(NULL, AV_LOG_ERROR, "Invalid chan_config %d\n",
>> c->chan_config);
>> +return -1;
>> +}
>
> I know the function definition says it returns -1 on e
lgtm
On 9/21/19, Andreas Rheinhardt wrote:
> This bug has been introduced in 9e0a071e.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavutil/opt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index 35dc9e153d..7c2649725f 100644
>
On 9/21/2019 8:29 AM, Jun Zhao wrote:
> From: Jun Zhao
>
> add chan_config check to avoid indeterminate channels.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/mpeg4audio.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/libavcodec/mpeg4audio.c b/libavcodec/m
This is an ABI change, so it's scheduled for the next bump.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 2 +-
libavcodec/alsdec.c| 4
libavcodec/mpeg4audio.c| 11 +--
libavcodec/mpeg4audio.h| 8 +++-
libavcodec/m
Hi,
On Sat, Sep 21, 2019 at 11:05 AM Carl Eugen Hoyos
wrote:
> Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje
> :
>
> > So it appears, from the discussion (..), that although there is source
> > code, it is not actually "open" in the sense that it's not
> redistributable
> > (at le
This is an ABI change, so it's scheduled for the next bump.
Signed-off-by: James Almer
---
libavcodec/alsdec.c| 2 +-
libavcodec/mpeg4audio.c| 12
libavcodec/mpeg4audio.h| 2 +-
libavcodec/mpegaudiodec_template.c | 2 +-
libavformat/adtsenc
Signed-off-by: James Almer
---
libavcodec/mpeg4audio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index 79ab352ce2..3774dc79c2 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -54,7 +54,7 @@ extern
Hi,
On Sat, Sep 21, 2019 at 11:53 AM Ronald S. Bultje
wrote:
> Hi,
>
> On Sat, Sep 21, 2019 at 11:05 AM Carl Eugen Hoyos
> wrote:
>
>> Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje
>> :
>>
>> > So it appears, from the discussion (..), that although there is source
>> > code, it i
Ronald S. Bultje (12019-09-21):
> I take that back, there's a COPYING that addresses this:
>
> https://github.com/traviscross/freeswitch/blob/master/docs/COPYING
You are not looking at the relevant file:
https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING
Regards,
--
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index 0af5626e35..883421202a 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -72,7 +72,7 @@ static int sunras
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index 883421202a..baf184968f 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -132,8 +132,8 @@ static int
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index baf184968f..98bc4ffa63 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -100,14 +100,14 @@ static
Fixes: Timeout (17sec -> 15ms)
Fixes:
17224/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SUNRAST_fuzzer-5663218491457536
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 10 +++
Fixes: Memleaks
Fixes:
17219/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5720539124989952
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mpsubdec.c | 3 +++
1 file changed, 3 insert
LGTM
On 9/21/19, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/sunrast.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
> index 0af5626e35..883421202a 100644
> --- a/libavcodec/sunrast.c
>
This allows reading packets linearly, which prevents large numbers of
unnecessary seeks in poorly-interleaved files with consumer software that
handles those cases well on its own.
---
libavformat/isom.h| 1 +
libavformat/mov.c | 11 +++
libavformat/version.h | 2 +-
3 files chan
This can be used to resolve particular hosts offline without affecting
HTTP headers, TLS SNI, or cross-domain redirects. It works similarly to
curl's --resolve option, but without port-specific handling.
---
libavformat/tcp.c | 27 +++
libavformat/version.h | 2 +-
2 f
Fixes some files misdetecting as MPEG PS
---
libavformat/mp3dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 258f19174b..d9aaee50b9 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -100,13 +100,13 @@ stat
Rodger Combs (12019-09-21):
> This can be used to resolve particular hosts offline without affecting
> HTTP headers, TLS SNI, or cross-domain redirects. It works similarly to
> curl's --resolve option, but without port-specific handling.
> ---
> libavformat/tcp.c | 27 +
Am Sa., 21. Sept. 2019 um 19:58 Uhr schrieb Rodger Combs
:
> +{ "position_order", "Read packets in position order (rather than
> timestamp order)",
> +OFFSET(position_order), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS },
Should this also say "avoids seeks"?
Carl Eugen
___
On Fri, Sep 20, 2019 at 12:38 AM Paul B Mahol wrote:
>
> LGTM
>
> On 9/20/19, James Zern wrote:
> > this conflicts with the current contributing guidance:
> > http://ffmpeg.org/developer.html#Contributing
> > FFmpeg is programmed in the ISO C90 language with a few additional
> > features from ISO
On Fri, Sep 20, 2019 at 03:19:52PM -0400, Devin Heitmueller wrote:
> Hello Michael,
>
>
> > On Sep 20, 2019, at 12:10 PM, Michael Niedermayer
> > wrote:
> >
> > On Fri, Sep 20, 2019 at 11:55:17PM +0800, lance.lmw...@gmail.com wrote:
> >> From: Limin Wang
> >>
> >> Signed-off-by: Limin Wang
On Thu, Aug 29, 2019 at 03:54:21PM -0700, William Martin wrote:
> From: Will Martin
>
> Some rtmp streamers (i.e. AWS Elemental Encoder, Wirecast) send C0 and C1
> together and expect S0 and S1 returned together. When sent in different
> packets, this results in a C2 handshake. This patch fixes
Am Sa., 21. Sept. 2019 um 16:49 Uhr schrieb Limin Wang :
> however the patch try to fix the autoscale, if user prefer to use
> swscale conversion, he can use it still by claims pix_fmt clearly.
This seems like a very bad argument assuming there is a quality
hit and the speed gain is very limited.
On Sat, Sep 21, 2019 at 07:45:58AM +0800, Limin Wang wrote:
> On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> > On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > The multithread is avoid one core cpu is full with othe
Am Sa., 21. Sept. 2019 um 20:16 Uhr schrieb Rodger Combs
:
>
> Fixes some files misdetecting as MPEG PS
The reason for the misdetection (mp3 file with 50k header that contains a
mjpeg cover) are the following "lame tags" (I couldn't immediately find out
what they really are) which nearly all conta
Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer :
> This is an ABI change, so it's scheduled for the next bump.
Why don't you add avpriv_mpeg4audio_get_config2() now?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote:
> Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer :
>
>> This is an ABI change, so it's scheduled for the next bump.
>
> Why don't you add avpriv_mpeg4audio_get_config2() now?
I don't like the idea of adding a function that will be gone as so
Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer :
>
> On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote:
> > Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer :
> >
> >> This is an ABI change, so it's scheduled for the next bump.
> >
> > Why don't you add avpriv_mpeg4audio_get_config2() no
On 9/21/2019 7:38 PM, Carl Eugen Hoyos wrote:
> Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer :
>>
>> On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote:
>>> Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer :
>>>
This is an ABI change, so it's scheduled for the next bump.
>>>
>>> Wh
Am So., 22. Sept. 2019 um 00:40 Uhr schrieb James Almer :
>
> On 9/21/2019 7:38 PM, Carl Eugen Hoyos wrote:
> > Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer :
> >>
> >> On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote:
> >>> Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer
> >>> :
>
Am Sa., 21. Sept. 2019 um 04:06 Uhr schrieb Andriy Gelman
:
>
> From: Andriy Gelman
>
> Since reading 4 bits always returns a value in the range [0, 15], the
> check for vps_id >= HEVC_MAX_VPS_COUNT, where HEVC_MAX_VPS_COUNT = 16, is
> redudant.
> ---
> libavcodec/hevc_ps.c | 12 ++--
>
On 9/21/2019 7:42 PM, Carl Eugen Hoyos wrote:
> Am So., 22. Sept. 2019 um 00:40 Uhr schrieb James Almer :
>>
>> On 9/21/2019 7:38 PM, Carl Eugen Hoyos wrote:
>>> Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer :
On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote:
> Am Sa., 21. Sept.
Signed-off-by: James Almer
---
libavformat/adtsenc.c | 2 +-
libavformat/isom.c| 4 ++--
libavformat/latmenc.c | 2 +-
libavformat/matroskaenc.c | 3 +--
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/adtsenc.c b/libavformat/adtsenc.c
index 3c2840c6ab..
Identical to avpriv_mpeg4audio_get_config() except taking a size argument in
bytes, and featuring a new logging context paremeter.
Schedule avpriv_mpeg4audio_get_config() for removal as soon as major is bumped
as well.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 2 +-
libavco
Signed-off-by: James Almer
---
libavcodec/aac_adtstoasc_bsf.c | 4 ++--
libavcodec/alsdec.c| 4 ++--
libavcodec/mpegaudiodec_template.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/aac_adtstoasc_bsf.c b/libavcodec/aac_adtstoasc_bsf.c
inde
> On Sep 21, 2019, at 4:44 PM, Michael Niedermayer
> wrote:
>
>> The patch just expands 4:2:0 to 4:2:2 while properly supporting interlaced
>> chroma.
>
> 4:2:0 and 4:2:2 have a chroma plane with different resolution.
> converting between planes of different resolution is what i called scal
On Sat, Sep 21, 2019 at 11:04:27PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 21, 2019 at 07:45:58AM +0800, Limin Wang wrote:
> > On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> > > On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> > > > From: Lim
From: Limin Wang
The multithread is avoid one core cpu is full with other filter like scale etc.
About the performance, the gain is very small, below is my testing for
performance.
In order to avoid the disk bottleneck, I'll use stream_loop mode for 10 frame
only.
./ffmpeg -y -i ~/Movies/4k_Rec7
From: Andriy Gelman
Since reading 4 bits always returns a value in the range [0, 15], the
check for vps_id >= HEVC_MAX_VPS_COUNT, where HEVC_MAX_VPS_COUNT = 16, is
redundant.
Signed-off-by: Andriy Gelman
---
libavcodec/hevc_ps.c | 8
1 file changed, 8 deletions(-)
diff --git a/libav
On Sun, 22. Sep 00:44, Carl Eugen Hoyos wrote:
> Am Sa., 21. Sept. 2019 um 04:06 Uhr schrieb Andriy Gelman
> :
> >
> > From: Andriy Gelman
> >
> > Since reading 4 bits always returns a value in the range [0, 15], the
> > check for vps_id >= HEVC_MAX_VPS_COUNT, where HEVC_MAX_VPS_COUNT = 16, is
>
80 matches
Mail list logo
