Hi Omar,
Thanks for updating. I have some final comments below.
Otherwise patch lgtm.
Hopefully others find time to test or comment.
On Wed, 08. Jul 11:55, Omar Emara wrote:
> This patch adds a select_region option to the xcbgrab input device.
> If set to 1, the user will be prompted to select
On Wed, 08 Jul 2020 12:54:46 +
"Zane van Iperen" wrote:
>
> v6: [8]
> * split out header and extradata fixes
> * add more-descriptive commit messages
> * fix bit_rate overflow
>
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:/
On 7/10/2020 7:26 PM, Carl Eugen Hoyos wrote:
> Am Fr., 10. Juli 2020 um 23:02 Uhr schrieb James Almer :
>>
>> And return the proper AVERROR value.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/libx264.c | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git
On Thu, Jul 9, 2020 at 4:54 PM James Almer wrote:
> @@ -38,7 +38,7 @@ pb_255: times 16 db 255
>
> SECTION .text
>
> -%macro BLEND_INIT 2-3
> +%macro BLEND_INIT 2
> %if ARCH_X86_64
> cglobal blend_%1, 6, 9, %2, top, top_linesize, bottom, bottom_linesize, dst,
> dst_linesize, width, end, x
>
Am Fr., 10. Juli 2020 um 23:02 Uhr schrieb James Almer :
>
> And return the proper AVERROR value.
>
> Signed-off-by: James Almer
> ---
> libavcodec/libx264.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 4a
Yo,
Since some people did not understand the way to propose their candidacy, or
maybe it was not explicit enough, the elections are now shut down and will be
relaunched tomorrow...
If you are NOT on the list of the candidates and want to be a candidate, please
mail me RIGHT NOW.
I will relaun
On 7/10/2020 6:01 PM, James Almer wrote:
> And return the proper AVERROR value.
>
> Signed-off-by: James Almer
> ---
> libavcodec/libx264.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 4a82e1ba25..b39b89
The documentation states it should be used to free any memory allocated
by x264_param_parse().
Signed-off-by: James Almer
---
libavcodec/libx264.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index b39b89b565..0c30bfe895 100644
--- a/libavco
And return the proper AVERROR value.
Signed-off-by: James Almer
---
libavcodec/libx264.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 4a82e1ba25..b39b89b565 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/lib
This is needed for the following patch.
Signed-off-by: James Almer
---
libavcodec/libx264.c | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index d4b1fd0d53..4a82e1ba25 100644
--- a/lib
Since xcbgrab is getting some attention recently...
Fixes a segfault, as reported in #7312.
To reproduce:
Terminal 1:
$ Xvfb :1 -nolisten tcp -screen 0 800x600x24
Terminal 2:
$ ffmpeg -f x11grab -i :1 -f null -
or rather
$ gdb -ex r --args ffmpeg_g -f x11grab -i :1 -f null -
Then terminate Xvfb w
Jul 10, 2020, 14:48 by andreas.rheinha...@gmail.com:
> This happened in get_ue_golomb() if the cached bitstream reader was in
> use, because there was no check to handle the case of the read value
> not being in the range 0..8190.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/golomb.h
On Fri, Jul 10, 2020 at 07:52:44PM +0200, Michael Niedermayer wrote:
> Fixes: Out of array read
> Fixes:
> 24043/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5084566275751936.fuzz
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects
On Fri, Jul 10, 2020 at 05:47:30PM +0200, Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes:
> 24034/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5111884337119232
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpe
On Fri, Jul 10, 2020 at 12:55:49AM +0200, Michael Niedermayer wrote:
> Fixes: 86987846-429c8d80-c197-11ea-916b-bb4738e09687.jpg
> Fixes: Regression since ec3d8a0e6945fe015d16cd98a1e7dbb4be815c15
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mjpeg_parser.c | 2 +-
> 1 file changed, 1
On Thu, Jul 09, 2020 at 12:35:38PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/sdp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/sdp.c b/libavformat/sdp.c
> index 34e9839b67..2ce1a62262 100644
> --- a/libavform
On Thu, Jul 09, 2020 at 12:35:39PM +0200, Andreas Rheinhardt wrote:
> No audio stream is created unconditionally and if none has been created,
> no packet with stream_index 1 may be returned. This fixes an assert in
> ff_read_packet() in libavformat/utils reported in ticket #8782.
>
> Signed-off-b
Fixes: Out of array read
Fixes:
24043/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5084566275751936.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_jpeg.c | 1 +
1 f
From: Kenneth Klette Jonassen
Enable s302m decoder to process AVPacket buffers containing multiple
ST 302 frames.
Validate that frame_size is within packet bounds. Change return value to
reflect only number of processed bytes instead of entire packet.
This patch allows us to decode the entire f
On 7/9/2020 11:53 AM, James Almer wrote:
> From: Henrik Gramner
>
> Some new warnings regarding use of empty macro parameters has been
> added, so adjust some x86inc code to silence those
>
> Signed-off-by: James Almer
> ---
> libavutil/x86/x86inc.asm | 46 ++---
From: Kenneth Klette Jonassen
ST 302:2007 is the latest iteration of the transport specification
and replaces the older SMPTE 302M name. To avoid possible end-user
confusion, we'll update the description in source code comments only.
Fill in a few important pieces of the bitstream documentation
> On 7 Jul 2020, at 16.23, Nicolas George wrote:
>
> Mathias Rasmussen (12020-06-25):
>>
>> +// non-linear mapping of target frame pixel
>> +// x-coordinate to position in the source frame.
>> +#define SIGN(x) (x < 0 ? -1 : 1)
>
>> +static double stretch_x(int target_x, int target_width, int s
On 7/10/2020 12:31 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 7/9/2020 7:35 AM, Andreas Rheinhardt wrote:
>>> The current code for parsing unsigned exponential-golomb codes is not
>>> suitable for long codes: If there are enough leading zeroes, it
>>> left-shifts 1 by 32 places and uses get
On 7/10/20, Jean-Baptiste Kempf wrote:
> On Fri, 10 Jul 2020, at 17:34, Paul B Mahol wrote:
>> On 7/10/20, Jean-Baptiste Kempf wrote:
>> > On Fri, 10 Jul 2020, at 17:31, Paul B Mahol wrote:
>> >> Why the second biggest contributor is not on any of those lists?
>> >
>> > Because he did not ask to
The include was not used, and revision.h has
been removed from glslang master.
See: https://github.com/KhronosGroup/glslang/pull/2277
---
libavfilter/glslang.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavfilter/glslang.cpp b/libavfilter/glslang.cpp
index 497df6e245..125eb5c364 1006
Fixes: out of array read
Fixes:
24034/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5111884337119232
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 3 +++
1 file chan
On Fri, 10 Jul 2020, at 17:34, Paul B Mahol wrote:
> On 7/10/20, Jean-Baptiste Kempf wrote:
> > On Fri, 10 Jul 2020, at 17:31, Paul B Mahol wrote:
> >> Why the second biggest contributor is not on any of those lists?
> >
> > Because he did not ask to be on the list?
>
> Nobody cared to add such c
On 7/10/20, Jean-Baptiste Kempf wrote:
> On Fri, 10 Jul 2020, at 17:31, Paul B Mahol wrote:
>> Why the second biggest contributor is not on any of those lists?
>
> Because he did not ask to be on the list?
Nobody cared to add such contributor.
>
> --
> Jean-Baptiste Kempf - President
> +33 672
James Almer:
> On 7/9/2020 7:35 AM, Andreas Rheinhardt wrote:
>> The current code for parsing unsigned exponential-golomb codes is not
>> suitable for long codes: If there are enough leading zeroes, it
>> left-shifts 1 by 32 places and uses get_bitsz to read 32 bits, although
>> it is only suitable
On Fri, 10 Jul 2020, at 17:31, Paul B Mahol wrote:
> Why the second biggest contributor is not on any of those lists?
Because he did not ask to be on the list?
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-dev
On 7/10/20, Jean-Baptiste Kempf wrote:
> Hello,
>
> You should have received an email about the elections for the TC and the CC.
> Please note that most candidates where nominated by other people than
> themselves.
>
> TC candidates
> Martin Storsjö
> Michael Niedermayer
> Marton Balint
> James Al
Hello,
You should have received an email about the elections for the TC and the CC.
Please note that most candidates where nominated by other people than
themselves.
TC candidates
Martin Storsjö
Michael Niedermayer
Marton Balint
James Almer
Nicolas George
Mark Thompson
Anton Khirnov
Kieran Kunhy
Lynne:
> Jul 10, 2020, 14:48 by andreas.rheinha...@gmail.com:
>
>> This happened in get_ue_golomb() if the cached bitstream reader was in
>> use, because there was no check to handle the case of the read value
>> not being in the range 0..8190.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> l
On 10/07/2020 15:48, Lynne wrote:
> That's in an extremely hot path. Any alternatives?
Anothe thing of note is that basically nothing in the entire
codebase checks the return value of this function. Possibly
literally nothing.
- Derek
___
ffmpeg-devel m
On 7/10/2020 11:29 AM, Nicolas George wrote:
> James Almer (12020-07-10):
>> It's adding an extra parameter to get a value that ultimately can be
>> derived from the output of another parameter. If you can use the >0 part
>> of the return value for that,
>
> Yes. And for me, it is totally a good t
James Almer (12020-07-10):
> It's adding an extra parameter to get a value that ultimately can be
> derived from the output of another parameter. If you can use the >0 part
> of the return value for that,
Yes. And for me, it is totally a good thing.
So why are you calling it ugly?
This discussio
This happened in get_ue_golomb() if the cached bitstream reader was in
use, because there was no check to handle the case of the read value
not being in the range 0..8190.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/golomb.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec
On 7/10/2020 9:03 AM, Nicolas George wrote:
> James Almer (12020-07-09):
>> int av_image_fill_plane_sizes(size_t *size, size_t planesizes[4], enum
>> AVPixelFormat pix_fmt, int height, const ptrdiff_t linesizes[4])
>>
>> But it's also somewhat ugly and inconsistent with other functions in
>> this m
Kieran O Leary (12020-07-10):
> Same here, been using email to reply to github issues and pull requests
> over the years. The only things i have to watch out for are:
> * People can edit their post in a github issue, so the email version you
> receive may be outdated as it could be updated on githu
From: Limin Wang
Signed-off-by: Limin Wang
---
libavutil/frame.h| 4 ++--
libavutil/timecode.h | 13 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 3fb8c56..3bd240f 100644
--- a/libavutil/frame.h
+++ b/libavutil/fra
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index a499972..8adc00b 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/deckli
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index df84e6487d..1d816a61e6 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1723,7 +1723,7 @@ static int hls_start(A
fix ticket: 8783
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1d816a61e6..cce6b2faa5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1722,6 +1722,15 @@ static int
James Almer (12020-07-09):
> int av_image_fill_plane_sizes(size_t *size, size_t planesizes[4], enum
> AVPixelFormat pix_fmt, int height, const ptrdiff_t linesizes[4])
>
> But it's also somewhat ugly and inconsistent with other functions in
> this module.
I find this is by far the best solution. E
On 2020-07-07 23:09 -0400, Cristian Bicheru wrote:
> It's been some time since there was any activity on this thread so I'm
> wondering if this new patch with just the NV16 format is okay?
Only to be clear, I think adding NV61 too, would be more logical,
but in no way should my opinion be a blocke
On 10-07-2020 04:36 pm, Moritz Barsnick wrote:
On Thu, Jun 25, 2020 at 18:59:58 +0800, myp...@gmail.com wrote:
On Thu, Jun 25, 2020 at 6:46 PM Moritz Barsnick wrote:
One of them can be triggered by https://samples.ffmpeg.org/F4V/H263_NM_f.mp4.
Signed-off-by: Moritz Barsnick
---
libavform
On Thu, Jun 25, 2020 at 18:59:58 +0800, myp...@gmail.com wrote:
> On Thu, Jun 25, 2020 at 6:46 PM Moritz Barsnick wrote:
> >
> > One of them can be triggered by
> > https://samples.ffmpeg.org/F4V/H263_NM_f.mp4.
> >
> > Signed-off-by: Moritz Barsnick
> > ---
> > libavformat/mov.c | 4 ++--
> > 1
On 7/8/20, Ben Hutchinson wrote:
> According to the documentation on the TINTERLACE video filter, the filter
> mode called MERGEX2 will "Move odd frames into the upper field, even into
> the lower field, generating a double height frame at same frame rate." But
> it doesn't do this, at least in so
Hi,
On Thu, Jul 9, 2020 at 1:56 AM Manolis Stamatogiannakis
wrote:
> On Tue, 7 Jul 2020 at 16:27, Nicolas George wrote:
>
> > Manolis Stamatogiannakis (12020-07-07):
> > > If I reply to the email, my response will appear online in the issue/PR
> > > page.
> >
> > That is good to know. I have ne
49 matches
Mail list logo
