On Sun, 19 Jul 2020, lance.lmw...@gmail.com wrote:
On Sat, Jul 18, 2020 at 08:38:16PM +0200, Marton Balint wrote:
On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
> On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
> >
> >
> > On Sat, 18 Jul 2020, lance.lmw...@gmail.com wr
On Thu, Jun 18, 2020 at 1:36 PM Linjie Fu wrote:
>
> On Tue, May 12, 2020 at 9:49 PM Linjie Fu wrote:
> >
> > VA_ENC_SLICE_STRUCTURE_EQUAL_MULTI_ROWS is added to in the latest
> > libva (1.8.0) which matches the hardware behaviour:
> >
> > /** \brief Driver supports any number of rows per slice b
On Sun, Jul 19, 2020 at 12:05 PM Michael Niedermayer
wrote:
>
> On Sat, Jul 18, 2020 at 06:46:22PM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan
> >
> > This patch adds support for PPM marker for JPEG2000
> > decoder. It allows the samples p1_03.j2k and p1_05.j2k
> > to be deco
Marton Balint 于2020年7月19日周日 上午6:04写道：
>
> Also query time only once, not for every variant stream, otherwise variant
> streams might get a slightly different initial program date time. And we can
> set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
> elsewhere.
>
> Signed-off-b
Hello folks,
Here are the results of the Technical and Community committee elections.
Community committee:
--
https://vote.ffmpeg.org/cgi-bin/civs/results.pl?num_winners=5&id=E_8dc4c448379a9d54&algorithm=runoff
1. Jean-Baptiste Kempf (Condorcet winner: wins conte
> On Jul 19, 2020, at 5:20 PM, Steven Liu wrote:
>
> Marton Balint 于2020年7月19日周日 上午6:04写道：
>>
>> Also query time only once, not for every variant stream, otherwise variant
>> streams might get a slightly different initial program date time. And we can
>> set this unconditionally because HLS_P
Am Sa., 18. Juli 2020 um 15:16 Uhr schrieb :
>
> From: Gautam Ramakrishnan
>
> The JPEG2000 standard reserves marker values 0xFF30
> to 0xFF3F to be used as parameterless markers. This
> patch adds support to decode codestream with such
> markers.
> This allows decoding of p0_02.j2k.
I wonder if
On Sun, Jul 19, 2020 at 12:09 AM Carl Eugen Hoyos wrote:
>
> Am Di., 9. Juni 2020 um 20:25 Uhr schrieb Carl Eugen Hoyos
> :
> >
> > Am Di., 9. Juni 2020 um 19:12 Uhr schrieb Gautam Ramakrishnan
> > :
> > >
> > > On Tue, Jun 9, 2020 at 10:24 PM Carl Eugen Hoyos
> > > wrote:
> > > >
> > > > Am Di
On Thu, 2020-07-16 at 18:11 +0200, Andreas Rheinhardt wrote:
> Hongcheng Zhong:
> > From: spartazhc
> >
> > hls_read_header will add all streams to s->internal->packet_buffer.
> > Use av_packet_buffer_filter to remove the AVPackets from other
> > streams that
> > are not needed, otherwise abr wil
Zhao Zhili 于2020年7月19日周日 下午6:26写道：
>
>
>
> > On Jul 19, 2020, at 5:20 PM, Steven Liu wrote:
> >
> > Marton Balint 于2020年7月19日周日 上午6:04写道：
> >>
> >> Also query time only once, not for every variant stream, otherwise variant
> >> streams might get a slightly different initial program date time. An
Please revert immediately:
libavcodec/gif.c:347:40: warning: incompatible pointer types passing
'void (PutBitContext *, int, BitBuf)' (aka 'void (struct PutBitContext
*, int, unsigned long)') to parameter of type 'void (*)(struct
PutBitContext *, int, unsigned int)' [-Wincompatible-pointer-types]
On Sun, 19 Jul 2020, Steven Liu wrote:
Zhao Zhili 于2020年7月19日周日 下午6:26写道：
> On Jul 19, 2020, at 5:20 PM, Steven Liu wrote:
>
> Marton Balint 于2020年7月19日周日 上午6:04写道：
>>
>> Also query time only once, not for every variant stream, otherwise variant
>> streams might get a slightly different
> On Jul 19, 2020, at 7:45 PM, Steven Liu wrote:
>
> Zhao Zhili 于2020年7月19日周日 下午6:26写道：
>>
>>
>>
>>> On Jul 19, 2020, at 5:20 PM, Steven Liu wrote:
>>>
>>> Marton Balint 于2020年7月19日周日 上午6:04写道：
Also query time only once, not for every variant stream, otherwise variant
str
Will apply.
On 7/18/20, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 46
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 2 +
> libavfilter/vf_rblur.c | 560 +++
> 4 files changed, 610 inserti
Paul B Mahol (12020-07-19):
> Will apply.
Certainly not before Steinar has had time to review it and tell us
whether you addressed all the concerns.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-dev
On 7/19/20, Nicolas George wrote:
> Paul B Mahol (12020-07-19):
>> Will apply.
>
> Certainly not before Steinar has had time to review it and tell us
> whether you addressed all the concerns.
>
I do not need to listen to you at all.
You all dislike me on discrimination basis and also object just
Fixes warnings introduced by c63c303a1f
Signed-off-by: James Almer
---
Maybe gif should be benchmarked as well?
libavcodec/lzw.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/lzw.h b/libavcodec/lzw.h
index 6af8a6b83a..338b4ef623 100644
--- a/libavcodec/lzw.h
Is your issue reproducible with current FFmpeg git head, the only version
supported on this bug tracker?
As I'm a Newbie to this mailing list, I'm not sure that I'm doing it
properly.
I was asked the above question by email from t...@avcodec.org.
As I stated in my defect report, I'm using ff
On Sun, 19 Jul 2020, at 16:05, Paul B Mahol wrote:
> You all dislike me on discrimination basis and also object just for objecting.
Discriminate you based on what?
Noone has ever seen you, and therefore noone knows your gender, religion, skin
color, race, or any other personal thing on you.
--
Paul B Mahol (12020-07-19):
> I do not need to listen to you at all.
> You all dislike me on discrimination basis and also object just for objecting.
>
> When I have objections to any patches they are silently ignored, other
> way around
> is different as this patch yet again demonstrates.
I will
On Sun, Jul 19, 2020 at 03:58:32PM +0200, Nicolas George wrote:
>> Will apply.
> Certainly not before Steinar has had time to review it and tell us
> whether you addressed all the concerns.
The primary change that I see is the addition of bilinear filtering in the
polar to Cartesian step. This mak
On Thu, Jul 16, 2020 at 11:45 PM Carl Eugen Hoyos wrote:
>
> Am Do., 16. Juli 2020 um 19:42 Uhr schrieb Gautam Ramakrishnan
> :
>
> > How could I get access to some stream/file for testing this feature if
> > I implement this?
>
> GStreamer should allow you to test your implementation.
>
> Carl Eu
On 7/19/20, Steinar H. Gunderson wrote:
> On Sun, Jul 19, 2020 at 03:58:32PM +0200, Nicolas George wrote:
>>> Will apply.
>> Certainly not before Steinar has had time to review it and tell us
>> whether you addressed all the concerns.
>
> The primary change that I see is the addition of bilinear f
On 7/19/20, Jean-Baptiste Kempf wrote:
> On Sun, 19 Jul 2020, at 16:05, Paul B Mahol wrote:
>> You all dislike me on discrimination basis and also object just for
>> objecting.
>
> Discriminate you based on what?
> Noone has ever seen you, and therefore noone knows your gender, religion,
> skin co
lzwenc stores a function pointer to either put_bits or put_bits_le.
Update the function pointer's prototype after the recent change.
---
libavcodec/lzw.h| 4 +++-
libavcodec/lzwenc.c | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/lzw.h b/libavcodec/lzw.h
in
On Sun, 19 Jul 2020, at 18:14, Paul B Mahol wrote:
> On 7/19/20, Jean-Baptiste Kempf wrote:
> > On Sun, 19 Jul 2020, at 16:05, Paul B Mahol wrote:
> >> You all dislike me on discrimination basis and also object just for
> >> objecting.
> >
> > Discriminate you based on what?
> > Noone has ever see
On 7/19/20, Nicolas George wrote:
> Paul B Mahol (12020-07-19):
>> I do not need to listen to you at all.
>> You all dislike me on discrimination basis and also object just for
>> objecting.
>>
>> When I have objections to any patches they are silently ignored, other
>> way around
>> is different
On 7/19/20, Jean-Baptiste Kempf wrote:
> On Sun, 19 Jul 2020, at 18:14, Paul B Mahol wrote:
>> On 7/19/20, Jean-Baptiste Kempf wrote:
>> > On Sun, 19 Jul 2020, at 16:05, Paul B Mahol wrote:
>> >> You all dislike me on discrimination basis and also object just for
>> >> objecting.
>> >
>> > Discri
/Is your issue reproducible with current FFmpeg git head, the only
version //
// supported on this bug tracker? /
As I'm a Newbie to this mailing list, I'm not sure that I'm doing it
properly.
I was asked the above question by email from t...@avcodec.org.
As I stated in my defect report, I'm
On Sun, 19 Jul 2020, at 18:20, Paul B Mahol wrote:
> On 7/19/20, Jean-Baptiste Kempf wrote:
> > On Sun, 19 Jul 2020, at 18:14, Paul B Mahol wrote:
> >> On 7/19/20, Jean-Baptiste Kempf wrote:
> >> > On Sun, 19 Jul 2020, at 16:05, Paul B Mahol wrote:
> >> >> You all dislike me on discrimination bas
Will apply soon.
On 7/16/20, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/rpzaenc.c | 857 +
> 3 files changed, 859 insertions(+)
> create mode 100644 libavcode
On 7/19/20, Jean-Baptiste Kempf wrote:
> On Sun, 19 Jul 2020, at 18:20, Paul B Mahol wrote:
>> On 7/19/20, Jean-Baptiste Kempf wrote:
>> > On Sun, 19 Jul 2020, at 18:14, Paul B Mahol wrote:
>> >> On 7/19/20, Jean-Baptiste Kempf wrote:
>> >> > On Sun, 19 Jul 2020, at 16:05, Paul B Mahol wrote:
>>
On Sun, 19 Jul 2020, at 18:37, Paul B Mahol wrote:
> > Here, Steinar gives a substantiated remark on your code, which could improve
> > quality and speed, which matches the goal of this project.
> >
> > Why not just apply what he did, and give us a better filter?
> > This is not discrimination, jus
On 7/16/2020 11:54 AM, Paul B Mahol wrote:
> +if (!s->prev_frame->data[0]) {
> +s->first_frame = 1;
> +ret = ff_get_buffer(avctx, s->prev_frame, 0);
This is for decoders only. Fill format, width and height on
s->prev_frame then call av_frame_get_buffer() instead.
> +if
On 7/19/2020 1:13 PM, Paul B Mahol wrote:
> On 7/19/20, Steinar H. Gunderson wrote:
>> On Sun, Jul 19, 2020 at 03:58:32PM +0200, Nicolas George wrote:
Will apply.
>>> Certainly not before Steinar has had time to review it and tell us
>>> whether you addressed all the concerns.
>>
>> The prima
On Sun, Jul 19, 2020 at 06:37:16PM +0200, Paul B Mahol wrote:
> About radial blur center issues, i think Steinar is confusing radial
> blur with zoom blur.
I must admit I don't know any such difference; this is one of many things
that would be useful to have in comments or the commit message (many
On 7/19/20, Steinar H. Gunderson wrote:
> On Sun, Jul 19, 2020 at 06:37:16PM +0200, Paul B Mahol wrote:
>> About radial blur center issues, i think Steinar is confusing radial
>> blur with zoom blur.
>
> I must admit I don't know any such difference; this is one of many things
> that would be usef
On 7/2/20, Paul B Mahol wrote:
> On 7/2/20, Nicolas George wrote:
>> Paul B Mahol (12020-07-02):
>>> I think anyone agreed that change is ok so i gonna apply this.
>>
>> Absolutely not, and your intimidation tactics are unacceptable.
>
> You are not absolute judge in this matter.
>
I officially
On Sun, Jul 19, 2020 at 6:15 PM Steinar H. Gunderson
wrote:
>
> lzwenc stores a function pointer to either put_bits or put_bits_le.
> Update the function pointer's prototype after the recent change.
> ---
> libavcodec/lzw.h| 4 +++-
> libavcodec/lzwenc.c | 4 ++--
> 2 files changed, 5 inserti
Fixes: memleak
Fixes:
23660/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6007508031504384
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/wc3movie.c | 32 +++--
Fixes: signed integer overflow: 8398407 * 300 cannot be represented in type
'int'
Fixes:
23914/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4702539290509312
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niederm
Such values are not supported by ff_subtitles_queue*
Fixes: signed integer overflow: 10 - -9223372036854775808 cannot be represented
in type 'long'
Fixes:
24193/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5714901855895552
Found-by: continuous fuzzing process
https://github.com/google/
Signed-off-by: Michael Niedermayer
---
libavformat/wc3movie.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavformat/wc3movie.c b/libavformat/wc3movie.c
index 657700..c59b5bf6cc 100644
--- a/libavformat/wc3movie.c
+++ b/libavformat/wc3movie.c
@@
This should improve coverage and should improve the efficiency of seed files
Signed-off-by: Michael Niedermayer
---
Makefile | 3 +++
tools/Makefile| 5 -
tools/target_dem_fuzzer.c | 9 -
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Mak
Fixes: signed integer overflow: 339867072 + 9195561788997000192 cannot
be represented in type 'long'
Fixes:
23790/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6554232198266880
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Sig
On 7/19/2020 2:42 PM, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes:
> 23660/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6007508031504384
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
Michael Niedermayer (12020-07-19):
> Fixes: signed integer overflow: 339867072 + 9195561788997000192
> cannot be represented in type 'long'
> Fixes:
> 23790/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6554232198266880
>
> Found-by: continuous fuzzing process
> https://github.co
James Almer:
> On 7/19/2020 2:42 PM, Michael Niedermayer wrote:
>> Fixes: memleak
>> Fixes:
>> 23660/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6007508031504384
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by:
Andreas Rheinhardt (12020-07-19):
> it is possible to use
> an older libavdevice together with a newer libavformat.
I move we make it impossible.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
Hi,
On 19.07.2020 18:10, Gautam Ramakrishnan wrote:
> On Thu, Jul 16, 2020 at 11:45 PM Carl Eugen Hoyos wrote:
>> Am Do., 16. Juli 2020 um 19:42 Uhr schrieb Gautam Ramakrishnan
>> :
>>
>>> How could I get access to some stream/file for testing this feature if
>>> I implement this?
>> GStreamer sh
On 7/19/20, Paul B Mahol wrote:
> On 7/2/20, Paul B Mahol wrote:
>> On 7/2/20, Nicolas George wrote:
>>> Paul B Mahol (12020-07-02):
I think anyone agreed that change is ok so i gonna apply this.
>>>
>>> Absolutely not, and your intimidation tactics are unacceptable.
>>
>> You are not absol
On Sun, Jul 19, 2020 at 07:32:18PM +0200, Paul B Mahol wrote:
> I see nothing wrong with that image.
Let me provide some zooms. First, center artifacts (the “flower” should not
be there):
http://storage.sesse.net/ffmpeg-radialblur3-zoom1.png
Then, staircase/uneven horizontal line near the edge
On Sun, Jul 19, 2020 at 07:37:15PM +0200, Paul B Mahol wrote:
> I officially request technical committee to give final decision on this
> subject.
I will reiterate that I do not intend to block this patch if you can get some
other developer to approve it.
/* Steinar */
--
Homepage: https://www.
On Sun, Jul 19, 2020 at 08:07:27PM +0200, Steinar H. Gunderson wrote:
>> I officially request technical committee to give final decision on this
>> subject.
> I will reiterate that I do not intend to block this patch if you can get some
> other developer to approve it.
I'm sorry, I replied to the
Steinar H. Gunderson (12020-07-19):
> I will reiterate that I do not intend to block this patch if you can get some
> other developer to approve it.
You are confusing two discussions. I am blocking this patch, because it
makes an important and shared code path significantly more complex, for
the s
Hendrik Leppkes:
> On Sun, Jul 19, 2020 at 6:15 PM Steinar H. Gunderson
> wrote:
>>
>> lzwenc stores a function pointer to either put_bits or put_bits_le.
>> Update the function pointer's prototype after the recent change.
>> ---
>> libavcodec/lzw.h| 4 +++-
>> libavcodec/lzwenc.c | 4 ++--
>>
On Sun, Jul 19, 2020 at 11:33 PM Thomas Volkert wrote:
>
> Hi,
>
> On 19.07.2020 18:10, Gautam Ramakrishnan wrote:
> > On Thu, Jul 16, 2020 at 11:45 PM Carl Eugen Hoyos
> > wrote:
> >> Am Do., 16. Juli 2020 um 19:42 Uhr schrieb Gautam Ramakrishnan
> >> :
> >>
> >>> How could I get access to some
On Sun, Jul 19, 2020 at 07:48:47PM +0200, Andreas Rheinhardt wrote:
> The reason is probably that gif and tiff (the two users of this) use
> different endianness (gif uses LE). A scenario like
>
> #include "lzw.h"
> #define BITSTREAM_WRITER_LE
> #include "put_bits.h"
>
> would be silently broken
On 7/19/20, Steinar H. Gunderson wrote:
> On Sun, Jul 19, 2020 at 07:32:18PM +0200, Paul B Mahol wrote:
>> I see nothing wrong with that image.
>
> Let me provide some zooms. First, center artifacts (the “flower” should not
> be there):
>
> http://storage.sesse.net/ffmpeg-radialblur3-zoom1.png
>
On 7/19/20, Nicolas George wrote:
> Steinar H. Gunderson (12020-07-19):
>> I will reiterate that I do not intend to block this patch if you can get
>> some
>> other developer to approve it.
>
> You are confusing two discussions. I am blocking this patch, because it
> makes an important and shared
On Sun, Jul 19, 2020 at 08:20:40PM +0200, Paul B Mahol wrote:
>> If you can explain what you mean the difference between radial and zoom blur
>> is, it would probably be possible to adapt the idea.
> That algorithm is very slow for big lengths, it takes ages to process
> single small image.
Yes, t
lzwenc stores a function pointer to either put_bits or put_bits_le;
however, after the recent change, the function pointer's prototype
would depend on BitBuf. BitBuf is defined in put_bits.h, whose
definition depends on whether BITSTREAM_WRITER_LE is #defined or not.
For safety, we set a boolean fl
Am So., 19. Juli 2020 um 20:18 Uhr schrieb Gautam Ramakrishnan
:
>
> On Sun, Jul 19, 2020 at 11:33 PM Thomas Volkert wrote:
> >
> > Hi,
> >
> > On 19.07.2020 18:10, Gautam Ramakrishnan wrote:
> > > On Thu, Jul 16, 2020 at 11:45 PM Carl Eugen Hoyos
> > > wrote:
> > >> Am Do., 16. Juli 2020 um 19:
On 7/19/20, Steinar H. Gunderson wrote:
> On Sun, Jul 19, 2020 at 08:20:40PM +0200, Paul B Mahol wrote:
>>> If you can explain what you mean the difference between radial and zoom
>>> blur
>>> is, it would probably be possible to adapt the idea.
>> That algorithm is very slow for big lengths, it t
On Sun, Jul 19, 2020 at 09:02:30PM +0200, Paul B Mahol wrote:
>> Yes, this is the non-recursive version, which is O(n) in the number of
>> samples. This is why I recommended the recursive version, which is O(log n)
>> in the number of samples and thus avoids the problem with big lengths.
>> It is f
On 7/19/20, Steinar H. Gunderson wrote:
> On Sun, Jul 19, 2020 at 09:02:30PM +0200, Paul B Mahol wrote:
>>> Yes, this is the non-recursive version, which is O(n) in the number of
>>> samples. This is why I recommended the recursive version, which is O(log
>>> n)
>>> in the number of samples and th
Am So., 19. Juli 2020 um 16:38 Uhr schrieb John Rose
:
>
> Is your issue reproducible with current FFmpeg git head, the only version
> supported on this bug tracker?
>
> As I'm a Newbie to this mailing list, I'm not sure that I'm doing it
> properly.
> I was asked the above question by email fr
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 46
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/vf_rblur.c | 558 +++
4 files changed, 608 insertions(+)
create mode 100644 libavfilter/vf_rblur.c
diff --gi
On 7/19/20, Paul B Mahol wrote:
> On 7/19/20, Steinar H. Gunderson wrote:
>> On Sun, Jul 19, 2020 at 09:02:30PM +0200, Paul B Mahol wrote:
Yes, this is the non-recursive version, which is O(n) in the number of
samples. This is why I recommended the recursive version, which is
O(log
From: Andriy Gelman
This fixes several mem leaks when init of encoder/decoder failed.
Fixes ticket #8285
Signed-off-by: Andriy Gelman
---
- Changes in v3
rebased and moved av_packet_unref(&s->buf_pkt) to v4l2_m2m_destroy_context()
to be consistent with another patch
libavcodec/v4l2_m2m.c
On Sun, Jul 19, 2020 at 02:50:45PM -0300, James Almer wrote:
> On 7/19/2020 2:42 PM, Michael Niedermayer wrote:
> > Fixes: memleak
> > Fixes:
> > 23660/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6007508031504384
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google
If reading the header fails, the demuxer's read_close() function (if
existing) is not called automatically; instead several demuxers call it
via "goto fail" in read_header().
This commit intends to change this by adding a flag to AVInputFormat
that can be used to set on a per-AVInputFormat basis w
wc3_read_header() might fail after having read some data into a packet
in which case this data would leak. Fix this by setting the
AVFMT_HEADER_CLEANUP flag that ensures that the demuxer's read_close
function is called (it unrefs the packet) if reading the header failed.
Fixes: memleak
Fixes:
236
Hi Andreas,
no objections for the patchset as a whole.
Just for the first in the series I have some questions.
The commit message is:
avformat/au: Store strings instead of pointers to strings in array
This tells the what, but not the why.
On 2020-07-17 13:14 +0200, Andreas Rheinhardt wro
Hi all,
this mail thread has turned into an example of exactly what I would
not like to see in a patch discussion!
It doesn't really respect the first sentence of our code of conduct:
Be friendly and respectful towards others and third parties.
Furthermore it discourages testing, code revi
On 2020-07-16 23:54 -0400, Andriy Gelman wrote:
> On Tue, 14. Jul 14:14, Moritz Barsnick wrote:
[...]
> > Subject: [PATCH] avdevice/xcbgrab: check return values of xcb query
> > functions
> >
> > Fixes #7312, segmentation fault on close of X11 server
> >
> > xcb_query_pointer_reply() and xcb_get_g
On Sun, 19. Jul 15:36, Andriy Gelman wrote:
> From: Andriy Gelman
>
> This fixes several mem leaks when init of encoder/decoder failed.
>
> Fixes ticket #8285
>
> Signed-off-by: Andriy Gelman
> ---
>
> - Changes in v3
> rebased and moved av_packet_unref(&s->buf_pkt) to v4l2_m2m_destroy_contex
Alexander Strasser:
> Hi Andreas,
>
> no objections for the patchset as a whole.
>
> Just for the first in the series I have some questions.
>
> The commit message is:
>
> avformat/au: Store strings instead of pointers to strings in array
>
> This tells the what, but not the why.
>
I thou
On Sun, Jul 19, 2020 at 11:05:37AM -0300, James Almer wrote:
> Fixes warnings introduced by c63c303a1f
>
> Signed-off-by: James Almer
> ---
> Maybe gif should be benchmarked as well?
>
> libavcodec/lzw.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Steinar also send a related pa
On Sun, 19. Jul 23:19, Alexander Strasser wrote:
> On 2020-07-16 23:54 -0400, Andriy Gelman wrote:
> > On Tue, 14. Jul 14:14, Moritz Barsnick wrote:
> [...]
> > > Subject: [PATCH] avdevice/xcbgrab: check return values of xcb query
> > > functions
> > >
> > > Fixes #7312, segmentation fault on clos
On Sat, Jul 18, 2020 at 11:34 PM Gyan Doshi wrote:
>
>
>
> On 18-07-2020 05:26 pm, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > remove the timeout option docs part for HTTP protocol and add
> > auth_type option part.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > doc/protocols.texi | 27 +++
This fixed FATE fail report by filter-pixfmts* for x2rgb10le on big
endian hardware.
---
libswscale/input.c | 11 ++-
libswscale/yuv2rgb.c | 6 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 0bd1aa7bc9..064ed5902f 100
> -Original Message-
> From: Andriy Gelman
> Sent: Tuesday, July 7, 2020 12:27 PM
> To: Wang, Fei W
> Cc: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] swscale: Add swscale
> input/output support for X2RGB10LE
>
> On Mon, 06. Jul 02:33, Wang,
Jun Zhao 于2020年7月18日周六 下午7:56写道：
>
> From: Jun Zhao
>
> Enable the custom callback in sub-demuxer
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/hls.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index ba17c4e..cf0b71d 100644
> --- a/libavfor
Jun Zhao 于2020年7月18日周六 下午8:19写道：
>
> From: Jun Zhao
>
> Enable the custom callback in sub-demuxer
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/dashdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 694782c..c5a5ff6 100644
> --
김동원님(Dongwon Kim) 于2020年7月17日周五 上午8:43写道：
>
> Signed-off-by: Dongwon Kim
> ---
> libavformat/hls.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c index
> ba17c4ed96..5e331ab68f 100644
> --- a/libavformat/hls.c
> +++ b/libavforma
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: 2020年7月17日 23:23
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/2] dnn/native: add native support for
> avg_pool
>
> It can be tested with the model generated with below python script:
>
> import t
When parsing MXF encountering some tags leads to allocations. And when
these tags were encountered repeatedly, this could lead to memleaks,
because the pointer to the old data got simply overwritten with a
pointer to the new data (or to NULL on allocation failure). This has
been fixed.
Signed-off-
Said array contains pointers to other structs and both the designated
new element as well as other stuff contained in it (e.g. strings) leak
if the new element can't be added to the array.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfdec.c | 14 +++---
1 file changed, 7 insertion
The MXF demuxer uses an array of pointers to different structures of
metadata (all containing a common initial sequence containing a type
field to distinguish them) and some of these structures contain pointers
to separately allocated subelements. If an error happens while reading
and creating the
90 matches
Mail list logo
