Use av_realloc() rather than av_malloc() when normalizing noncompliant
private data in get_qt_codec(). Based on your comments, Michael, it
seems to be OK, and is more "elegant" in my book than using
av_malloc()/memcpy()/av_free().
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From a
On 01/11/2016 01:46 AM, Michael Niedermayer wrote:
On Sun, Jan 10, 2016 at 04:04:47AM +0100, Mats Peterson wrote:
How about this one, Michael? Rather than using the obviously
dangerous av_realloc() it uses av_malloc() to allocate new memory
for the private data, then copies the private data to i
On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
This fixes segmentation faults due to out of bounds writes, when
color_start is interpreted as negative number.
This regression was introduced in commit 57631f.
Signed-off-by: Andreas Cadhalpun
---
Seriously, changing the code behavior when "fa
On 01/11/2016 01:46 AM, Michael Niedermayer wrote:
that documentation is misleading, av_malloc() is if one is really
pedantic not safe to be passed to av_free or av_realloc()
if one isnt pedantic it safe to be passed to both
Is the pointer from av_malloc() not safe to be passed to av_free()? Yo
On 01/11/2016 03:53 AM, Mats Peterson wrote:
What do you mean by "separating them" by the way? I haven't separated
anything as far as I know.
Mats
Another thing regarding the av_realloc() function: Even if I had been
using av_realloc(), it won't cause any memory leak if it exits the
functio
On 01/11/2016 03:53 AM, Mats Peterson wrote:
av_malloc(), and which might use memalign(), of which the pointer is
apparently not safe to pass to av_malloc(), according to the FFmpeg
Not safe to pass to *av_realloc()*, I mean.
Mats
___
ffmpeg-devel ma
On 01/11/2016 01:46 AM, Michael Niedermayer wrote:
On Sun, Jan 10, 2016 at 04:04:47AM +0100, Mats Peterson wrote:
How about this one, Michael? Rather than using the obviously
dangerous av_realloc() it uses av_malloc() to allocate new memory
for the private data, then copies the private data to i
On Sun, Jan 10, 2016 at 04:04:47AM +0100, Mats Peterson wrote:
> How about this one, Michael? Rather than using the obviously
> dangerous av_realloc() it uses av_malloc() to allocate new memory
> for the private data, then copies the private data to it, frees the
> pointer to the original private d
On Sun, Jan 10, 2016 at 03:05:49 +0100, Mats Peterson wrote:
> OK, but I thought an AVERROR(ENOMEM) eventually causes FFmpeg to exit?
Even if so, this code is in libavformat, and may be called by any other
application than ffmpeg.
Moritz
___
ffmpeg-deve
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 3 +++
libavfilter/avf_showspectrum.c | 56 +++---
2 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index efb050d..45d22f4 100644
--- a/doc/filt
Signed-off-by: Paul B Mahol
---
Only gray input supported, chroma is ignored. (float pixel format would come
handy)
Only fullframe slide mode implemented.
No overlaping and only rectangular window for now.
Only power of 2 height supported and tested.
---
libavfilter/Makefile| 1 +
Signed-off-by: Paul B Mahol
---
libavfilter/avf_showspectrum.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 7fd0ea9..424d1f2 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/av
Hi,
Great work, but I found some issues.
This I got with fuzzed file:
==13422== Invalid read of size 4
==13422==at 0x834D003: cfhd_decode (cfhd.c:293)
==13422==by 0x863D051: frame_worker_thread (pthread_frame.c:147)
==13422==by 0x40ECF6F: start_thread (pthread_create.c:312)
==13422==
On 2016-01-10 00:28:49 +, Kieran Kunhya wrote:
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/cfhd.c | 565
>
> libavcodec/cfhd.h | 99 +
> libavc
On 10 January 2016 at 19:54, Michael Niedermayer
wrote:
>
> please explain in the commit message why secmem is disabled
>
>
0001-rtmpdh-Initialize-gcrypt-before-using-it.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On Fri, 8 Jan 2016, Nicolas George wrote:
Le decadi 10 nivôse, an CCXXIV, Marton Balint a écrit :
Signed-off-by: Marton Balint
---
libavformat/concatdec.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
LGTM, thanks, and sorry to have forgotten.
Applied, thanks.
Marton
On Sun, Jan 10, 2016 at 07:34:27PM +, Ricardo Constantino wrote:
> Tried with 1.5.4 with the link on the first email and another one from
> Crunchyroll and it worked.
> Tried compiling 1.5.0 but didn't work (on MinGW).
> rtmpdh.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 delet
On Sun, Jan 10, 2016 at 12:28:50AM +, Kieran Kunhya wrote:
> ---
> libavformat/riff.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/riff.c b/libavformat/riff.c
> index f297dd4..faf0f86 100644
> --- a/libavformat/riff.c
> +++ b/libavformat/riff.c
> @@ -377,6 +377,7 @@ co
Tried with 1.5.4 with the link on the first email and another one from
Crunchyroll and it worked.
Tried compiling 1.5.0 but didn't work (on MinGW).
0001-rtmpdh-Initialize-gcrypt-before-using-it.patch
Description: Binary data
___
ffmpeg-devel mailing lis
On Sun, 10 Jan 2016 19:57:17 +0100
Clément Bœsch wrote:
> On Sun, Jan 10, 2016 at 02:03:46PM +0100, wm4 wrote:
> > On Sat, 9 Jan 2016 14:46:52 +0100
> > Clément Bœsch wrote:
> >
> > > From: Clément Bœsch
> > >
> > > ---
> > > TODO
> > > - ass_split needs to be able to handle dialog event w
On Sun, Jan 10, 2016 at 02:03:46PM +0100, wm4 wrote:
> On Sat, 9 Jan 2016 14:46:52 +0100
> Clément Bœsch wrote:
>
> > From: Clément Bœsch
> >
> > ---
> > TODO
> > - ass_split needs to be able to handle dialog event without "Dialogue:
> > ..." so our encoding chain can handle the sane decoded
On 1/10/16, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch improves display of the samples from ticket #4535.
>
> Please comment, Carl Eugen
>
Pure guessing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmp
Michael Niedermayer niedermayer.cc> writes:
> > Attached patch fixes ticket #5142.
> > libx264.c |2 ++
> > 1 file changed, 2 insertions(+)
> > 98178e28de0e96f9e4c9f1f1ddcc4d75055d48bd patchx264coder.diff
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>
> LGTM
Patch applied
Hi!
Attached patch improves display of the samples from ticket #4535.
Please comment, Carl Eugen
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 3859810..a6e3b6a 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -834,6 +834,8 @@ static int avi_read_header(AVFormatCont
On Sat, 9 Jan 2016 14:46:52 +0100
Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> TODO
> - ass_split needs to be able to handle dialog event without "Dialogue:
> ..." so our encoding chain can handle the sane decoded subtitles
> - zvbi needs testing
> - option sub_text_format needs to b
On Fri, 8 Jan 2016, Rodger Combs wrote:
On Jan 8, 2016, at 18:30, Marton Balint wrote:
On Fri, 8 Jan 2016, Rodger Combs wrote:
[...]
+ * APIC frame in ID3v2). The first (usually only) packet associated with it
+ * will be returned among the first few packets read from the file unless
+ *
On 1/10/2016 1:54 AM, James Almer wrote:
>> +AVCodec ff_cfhd_decoder = {
>> +.name = "cfhd",
>> +.long_name = NULL_IF_CONFIG_SMALL("Cineform HD"),
>> +.type = AVMEDIA_TYPE_VIDEO,
>> +.id = AV_CODEC_ID_CFHD,
>> +.priv_data_size = sizeof(CFHDCo
On 01/10/2016 01:03 PM, Mats Peterson wrote:
dYes Anreas, until my normalization patch for matroskadec.c is applied,
of course it's very easy for these variables to be negative when using
an int, because of the invalid private data. I stand corrected.
Sorry, ANDREAS. This Thunderbird is killing
On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
This fixes segmentation faults due to out of bounds writes, when
color_start is interpreted as negative number.
dYes Anreas, until my normalization patch for matroskadec.c is applied,
of course it's very easy for these variables to be negative wh
On 01/10/2016 12:29 PM, Mats Peterson wrote:
Good advice to a hysterical person like me. Thanks.
At least I'm able to admit that I've been wrong, unlike some other
people (no names mentioned).
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On 01/10/2016 12:29 PM, Andreas Cadhalpun wrote:
Just take the 5 minutes to check the facts before sending
the first reply.
Best regards,
Andreas
Good advice to a hysterical person like me. Thanks.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
On 10.01.2016 12:24, Mats Peterson wrote:
> On 01/10/2016 12:23 PM, Andreas Cadhalpun wrote:
>
>> Please check the facts before writing a reply. Thanks.
>
> It's human to err;) Thanks, anyway.
But it's bad style to send two mails contradicting each other
within 5 minutes.
Just take the 5 minute
On 01/10/2016 12:23 PM, Andreas Cadhalpun wrote:
Please check the facts before writing a reply. Thanks.
It's human to err;) Thanks, anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 10.01.2016 12:17, Mats Peterson wrote:
> On 01/10/2016 12:14 PM, Mats Peterson wrote:
>> On 01/10/2016 12:13 PM, Mats Peterson wrote:
>>> As far as I remember, those variables were ints in the original code in
>>> mov.c, and they will hardly reach a value where they could be
>>> interpreted as i
On 10.01.2016 12:13, Mats Peterson wrote:
> On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
>> This fixes segmentation faults due to out of bounds writes, when
>> color_start is interpreted as negative number.
>>
>> This regression was introduced in commit 57631f.
>>
>> Signed-off-by: Andreas Cadh
On 01/10/2016 12:14 PM, Mats Peterson wrote:
On 01/10/2016 12:13 PM, Mats Peterson wrote:
As far as I remember, those variables were ints in the original code in
mov.c, and they will hardly reach a value where they could be
interpreted as ints. But it's of course better to be on the safe side.
T
On 01/10/2016 12:13 PM, Mats Peterson wrote:
As far as I remember, those variables were ints in the original code in
mov.c, and they will hardly reach a value where they could be
interpreted as ints. But it's of course better to be on the safe side.
Thanks for the heads-up.
Interpreted as negati
On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
This fixes segmentation faults due to out of bounds writes, when
color_start is interpreted as negative number.
This regression was introduced in commit 57631f.
Signed-off-by: Andreas Cadhalpun
---
Seriously, changing the code behavior when "fa
This fixes segmentation faults due to out of bounds writes, when
color_start is interpreted as negative number.
This regression was introduced in commit 57631f.
Signed-off-by: Andreas Cadhalpun
---
Seriously, changing the code behavior when "factoring out" is a
very bad practice.
---
libavfor
39 matches
Mail list logo
