On 3/31/17, Paolo Prete wrote:
> ---
> configure | 2 +
> doc/Makefile| 41 ++--
> doc/examples/.gitignore | 1 +
> doc/examples/Makefile | 1 +
> doc/examples/encode_raw_audio_file_
On 5/6/17, Muhammad Faiz wrote:
> On Sat, May 6, 2017 at 2:30 AM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> configure| 2 +
>> doc/filters.texi | 10 +
>> libavfilter/Makefile | 1 +
>> libavfilter/af_afir.c| 484
>> +++
A lot of filters require aligned frame data, but do not document it.
It can result in crashes with perfectly valid uses of the API.
Signed-off-by: Nicolas George
---
libavfilter/avfilter.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.
A lot of codecs require aligned frame data, but do not document it.
It can result in crashes with perfectly valid uses of the API.
TODO Implementation missing.
Design rationale:
- requiring frame data to be always aligned would be wasteful;
- alignment requirements will evolve
(the 16->32 bum
TODO Actual implementation.
Signed-off-by: Nicolas George
---
libavutil/frame.h | 9 +
1 file changed, 9 insertions(+)
Here is a proposal for actually fixing the alignment problems that are all
over the place in the current code base.
Note that it is only a design proposal, all the ac
Le sextidi 16 floréal, an CCXXV, Kieran Kunhya a écrit :
> I sent a patch about this nearly three years ago, it wasn't applied for
> whatever reason.
> This is pretty common if you don't use av_malloc.
Thanks for pointing it.
As for the rest, I can observe that my hope that some people will start
On Sat, 6 May 2017 11:20:13 +0200
Nicolas George wrote:
> Le sextidi 16 floréal, an CCXXV, Kieran Kunhya a écrit :
> > I sent a patch about this nearly three years ago, it wasn't applied for
> > whatever reason.
> > This is pretty common if you don't use av_malloc.
>
> Thanks for pointing it.
On Sat, May 6, 2017 at 11:20 AM, Nicolas George wrote:
> A lot of codecs require aligned frame data, but do not document it.
> It can result in crashes with perfectly valid uses of the API.
>
> TODO Implementation missing.
>
> Design rationale:
>
> - requiring frame data to be always aligned would
Tiny fix: missed inline attr.
On Thu, May 4, 2017 at 1:17 AM, Даниил Чередник
wrote:
> All notices were fixed. Also I found issue with uninitialized subband
> buffer - fixed. New patch attached.
>
> On Wed, May 3, 2017 at 7:49 AM, Rostislav Pehlivanov
> wrote:
>
>> On 2 May 2017 at 22:53, Дании
This fixes early abort on ALSA playback
---
libavdevice/alsa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavdevice/alsa.c b/libavdevice/alsa.c
index 8d27913..1bbff30 100644
--- a/libavdevice/alsa.c
+++ b/libavdevice/alsa.c
@@ -300,6 +300,8 @@ av_cold int ff_alsa_close(AVFormatContex
Third ping.
This patch is trivial, and makes behavior of librtmp and ffrtmp consistent
when using rtmp_swfverify.
What's blocking this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
On Sat, May 6, 2017 at 5:20 AM, Nicolas George wrote:
> +/**
> + * Minimum alignment of frame data required by the codec.
> + * All frame data pointers must have the alignment lower bits cleared,
> + * i.e. be a multiple of 1< + * - encoding: set by the encoder and used b
On Sat, May 6, 2017 at 3:54 PM, Paul B Mahol wrote:
> On 5/6/17, Muhammad Faiz wrote:
>> On Sat, May 6, 2017 at 2:30 AM, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> configure| 2 +
>>> doc/filters.texi | 10 +
>>> libavfilter/Makefile | 1 +
On Fri, May 5, 2017 at 11:22 PM, Nicolas George wrote:
> Le sextidi 16 floréal, an CCXXV, Muhammad Faiz a écrit :
>> But if documentation
>> says that data should be aligned to 4-bytes but I align it to
>> 32-bytes, then there are no violations at
On Sat, May 6, 2017 at 4:20 PM, Nicolas George wrote:
> TODO Actual implementation.
>
> Signed-off-by: Nicolas George
> ---
> libavutil/frame.h | 9 +
> 1 file changed, 9 insertions(+)
>
>
> Here is a proposal for actually fixing the alignment problems that are all
> over the place in th
Hi Muhammad,
On Sat, May 6, 2017 at 10:13 AM, Muhammad Faiz wrote:
> On Fri, May 5, 2017 at 11:22 PM, Nicolas George wrote:
> > Le sextidi 16 floréal, an CCXXV, Muhammad Faiz a écrit :
> >> But if documentation
> >> says that data should be alig
Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit :
> Whatever the result here (accepted or rejected), we still need a fix
> without API change. Otherwise, it can't go to 3.3 branch.
There is no API change as is (except for the extra function in lavu, but
that is only an add, and can be worke
Hi,
On Fri, May 5, 2017 at 12:17 PM, Nicolas George wrote:
> Le sextidi 16 floréal, an CCXXV, Hendrik Leppkes a écrit :
> > Blocking crash fixes on silly arguments doesn't help anyone. Send a
>
> My argument is not silly: the code to align the frame will be needed,
> but NOT HERE.
I actually t
On Sat, May 6, 2017 at 9:39 PM, Nicolas George wrote:
> Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit :
>> Whatever the result here (accepted or rejected), we still need a fix
>> without API change. Otherwise, it can't go to 3.3 branch.
>
> There is no API change as is (except for the ext
On Sat, May 6, 2017 at 9:36 PM, Ronald S. Bultje wrote:
> Hi Muhammad,
>
> On Sat, May 6, 2017 at 10:13 AM, Muhammad Faiz wrote:
>
>> On Fri, May 5, 2017 at 11:22 PM, Nicolas George wrote:
>> > Le sextidi 16 floréal, an CCXXV, Muhammad Faiz a écrit :
>> >>
On Sat, May 6, 2017 at 9:35 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, May 5, 2017 at 12:17 PM, Nicolas George wrote:
>
>> Le sextidi 16 floréal, an CCXXV, Hendrik Leppkes a écrit :
>> > Blocking crash fixes on silly arguments doesn't help anyone. Send a
>>
>> My argument is not silly: the cod
On Sat, May 6, 2017 at 5:40 PM, Muhammad Faiz wrote:
> On Sat, May 6, 2017 at 9:39 PM, Nicolas George wrote:
>> Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit :
>>> Whatever the result here (accepted or rejected), we still need a fix
>>> without API change. Otherwise, it can't go to 3.3 b
Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit :
> - fix framequeue (this patch).
Once again, this patch is not correct. In particular it is NOT ENOUGH
to fix the crash in all cases.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
On Fri, May 05, 2017 at 09:30:54PM +, Kieran Kunhya wrote:
> From d43c0366d4ba128772dc7909152f4e9635f269cb Mon Sep 17 00:00:00 2001
> From: Kieran Kunhya
> Date: Fri, 5 May 2017 14:29:59 -0700
> Subject: [PATCH] libavcodec/h264_sei: Don't log random user data. This
> prevents terminal junk.
>
On Sat, 6 May 2017, Ronald S. Bultje wrote:
Hi,
On Sat, May 6, 2017 at 5:20 AM, Nicolas George wrote:
+/**
+ * Minimum alignment of frame data required by the codec.
+ * All frame data pointers must have the alignment lower bits cleared,
+ * i.e. be a multiple of 1<
I agre
On 5/6/2017 1:37 PM, Michael Niedermayer wrote:
> On Fri, May 05, 2017 at 09:30:54PM +, Kieran Kunhya wrote:
>> From d43c0366d4ba128772dc7909152f4e9635f269cb Mon Sep 17 00:00:00 2001
>> From: Kieran Kunhya
>> Date: Fri, 5 May 2017 14:29:59 -0700
>> Subject: [PATCH] libavcodec/h264_sei: Don't l
On Sat, May 6, 2017 at 6:35 PM, Nicolas George wrote:
> Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit :
>> - fix framequeue (this patch).
>
> Once again, this patch is not correct. In particular it is NOT ENOUGH
> to fix the crash in all cases.
>
It is enough to restore the situation to
Le septidi 17 floréal, an CCXXV, Ronald S. Bultje a écrit :
> I agree it's likely that one codec (e.g. h264) would need 32-byte alignment
> on a particular system (e.g. x86/haswell), whereas another codec on the
> same system (e.g. wmavoice) might not.
>
> However, I find it unlikely that one code
Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit :
> As far as I know. No new features can go to release branch.
> Or maybe I'm wrong.
As I said, if this is the only issue, then it is not: just copy-paste
av_frame_realign() at the two places where it will be needed and make it
static.
But r
On 2017-05-05 09:28 PM, wm4 wrote:
On Fri, 5 May 2017 20:55:05 -0400
Micah Galizia wrote:
Signed-off-by: Micah Galizia
---
libavformat/hls.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4350..bda9abecfa
On 5/5/2017 2:23 PM, Nicolas George wrote:
> Le sextidi 16 floréal, an CCXXV, James Almer a écrit :
>> stuff you broke
>
> Please stop spreading wm4's lies. The bug was already there.
>
> Regards,
>
Take a look at https://trac.ffmpeg.org/ticket/6346. That ticket re
Le septidi 17 floréal, an CCXXV, Hendrik Leppkes a écrit :
> I don't think this is very practical. We have a bunch of generic DSPs
> and if a codec uses those it would need to be constantly updated if
> the requirements of those DSPs change. Today it may only use SSE and
> be happy with 16-byte ali
Le septidi 17 floréal, an CCXXV, Takayuki 'January June' Suwa a écrit :
> This fixes early abort on ALSA playback
>
> ---
> libavdevice/alsa.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavdevice/alsa.c b/libavdevice/alsa.c
> index 8d27913..1bbff30 100644
> --- a/libavdevice/al
On 5/2/2017 8:06 PM, wm4 wrote:
> Fixes e.g.:
>
> ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -filter_complex
> "[0:v][1:v]psnr[out]" -f null none
This should be backported to release/3.3 before 3.3.1 is tagged.
___
ffmpeg-devel mailing list
ffmpeg-
On 5/6/17, Muhammad Faiz wrote:
> On Sat, May 6, 2017 at 2:33 AM, Paul B Mahol wrote:
>> On 5/5/17, Muhammad Faiz wrote:
>> Is pts handled correctly here? Seem it is not derived from input pts.
>>
>
> It can not be derived in any other way.
Probably, at least, first pts
Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/aacdec_fixed.c| 2 +-
libavcodec/aacdec_template.c | 4 ++--
libavcodec/sbrdsp_f
On 4/21/2017 3:30 AM, Aaron Levinson wrote:
> From 4f27e910aca6dae6642b4d73cf07fa0d6c4b1618 Mon Sep 17 00:00:00 2001
> From: Aaron Levinson
> Date: Thu, 20 Apr 2017 23:20:20 -0700
> Subject: [PATCH] Fixed memory leaks associated with AVStream objects if
> FF_API_LAVF_AVCTX is defined
>
> Purpose
It's not used by anything, has dubious usefulness, the reasons for which
it was introduced are no longer valid, and only serves to add complexity
to the build system.
Signed-off-by: James Almer
---
Makefile | 6 --
configure | 2 --
ffbuild/library.mak | 2 +-
ffbu
On Sat, May 06, 2017 at 01:13:41PM +0100, Ricardo Constantino wrote:
> Third ping.
>
> This patch is trivial, and makes behavior of librtmp and ffrtmp consistent
> when using rtmp_swfverify.
>
> What's blocking this?
lack of maintainer for this code
If you would be interrested in maintaining th
On 6 May 2017 at 23:05, Michael Niedermayer wrote:
> On Sat, May 06, 2017 at 01:13:41PM +0100, Ricardo Constantino wrote:
> > Third ping.
> >
> > This patch is trivial, and makes behavior of librtmp and ffrtmp
> consistent
> > when using rtmp_swfverify.
> >
> > What's blocking this?
>
> lack of m
On Sun, May 7, 2017 at 2:49 AM, Paul B Mahol wrote:
> On 5/6/17, Muhammad Faiz wrote:
>> On Sat, May 6, 2017 at 2:33 AM, Paul B Mahol wrote:
>>> On 5/5/17, Muhammad Faiz wrote:
>>> Is pts handled correctly here? Seem it is not derived from input pts.
>>>
>>
>> It can not be deri
On Sat, May 06, 2017 at 11:13:10PM +0100, Ricardo Constantino wrote:
> On 6 May 2017 at 23:05, Michael Niedermayer wrote:
>
> > On Sat, May 06, 2017 at 01:13:41PM +0100, Ricardo Constantino wrote:
> > > Third ping.
> > >
> > > This patch is trivial, and makes behavior of librtmp and ffrtmp
> > co
On Sat, May 06, 2017 at 08:40:46PM +0200, Nicolas George wrote:
> Le septidi 17 floréal, an CCXXV, Takayuki 'January June' Suwa a écrit :
> > This fixes early abort on ALSA playback
> >
> > ---
> > libavdevice/alsa.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavdevice/al
On Sat, May 6, 2017 at 2:30 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure| 2 +
> doc/filters.texi | 10 +
> libavfilter/Makefile | 1 +
> libavfilter/af_afir.c| 484
> +++
> libavfilter/a
On Wed, May 03, 2017 at 09:29:14AM +, Saverio Blasi wrote:
> Dear Carl,
>
> Thanks for your email.
> Yes, I can confirm that the patch as it is generated with "git format-patch
> -1" passes the patcheck test without highlighting any trailing whitespaces.
> I can see though that the email that
On 5/6/2017 2:59 PM, James Almer wrote:
It's not used by anything, has dubious usefulness, the reasons for which
it was introduced are no longer valid, and only serves to add complexity
to the build system.
Signed-off-by: James Almer
---
Makefile | 6 --
configure
On 5/6/2017 11:19 PM, Aaron Levinson wrote:
> On 5/6/2017 2:59 PM, James Almer wrote:
>> It's not used by anything, has dubious usefulness, the reasons for which
>> it was introduced are no longer valid, and only serves to add complexity
>> to the build system.
>>
>> Signed-off-by: James Almer
>>
On Sat, 6 May 2017 15:29:18 -0300
James Almer wrote:
> On 5/5/2017 2:23 PM, Nicolas George wrote:
> > Le sextidi 16 floréal, an CCXXV, James Almer a écrit :
> >> stuff you broke
> >
> > Please stop spreading wm4's lies. The bug was already there.
Oh, now he's acc
On Wed, 3 May 2017 05:26:04 +0200
wm4 wrote:
> This adds tons of code for no other benefit than making VideoToolbox
> support conform with the new hwaccel API (using hw_device_ctx and
> hw_frames_ctx).
>
> Since VideoToolbox decoding does not actually require the user to
> allocate frames, the
49 matches
Mail list logo
