L'octidi 8 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> affect filters that set partial_buf_size
> test-case
> ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, asplit
> [a][b];
> [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1];
> [b] firequalizer=fixed=on, showcqt=s=1280x360
Hi,
On Sat, Jan 28, 2017 at 7:25 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 27.01.2017 03:27, Michael Niedermayer wrote:
> > On Thu, Jan 26, 2017 at 02:14:09AM +0100, Andreas Cadhalpun wrote:
> >> Signed-off-by: Andreas Cadhalpun
> >>
On Sun, 29 Jan 2017, Andreas Cadhalpun wrote:
On 28.01.2017 12:44, Marton Balint wrote:
If we reduce the number of extra lines (not at any cost), I think that helps.
There is also a solution which keeps the traditional C syntax, and is easy to
undestand even at first glance.
if
On Sat, Jan 28, 2017 at 04:09:20PM -0800, Christopher Snowhill wrote:
> Disregard those two, they were mistaken transcodes. These two are supposed to
> be gapless, however. Same signal, just not transcoded and downsampled first.
where should they be uploaded to ?
also is there a corresponding
On Thu, Jan 26, 2017 at 02:13:48AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/xvag.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM assuming the author/maintainer does not object
[...]
--
Michael
On Thu, Jan 26, 2017 at 02:13:33AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/epafdec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM assuming the author/maintainer does not object
[...]
--
Michael
On Thu, Jan 26, 2017 at 02:12:19AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/ircamdec.c | 6 ++
> 1 file changed, 6 insertions(+)
LGTM assuming the author/maintainer does not object, maybe he
prefers this without
On Thu, Jan 26, 2017 at 02:11:54AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/genh.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM assuming the author/maintainer does not object
[...]
--
Michael
On 27.01.2017 01:44, Michael Niedermayer wrote:
> On Thu, Jan 26, 2017 at 02:11:31AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/electronicarts.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM
On 27.01.2017 03:27, Michael Niedermayer wrote:
> On Thu, Jan 26, 2017 at 02:14:09AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/boadec.c | 14 +-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>
>
On 26.01.2017 09:37, Paul B Mahol wrote:
> On 1/26/17, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/pvfdec.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>
> lgtm
On 26.01.2017 03:21, Michael Niedermayer wrote:
> On Thu, Jan 26, 2017 at 02:11:02AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/4xm.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> LGTM
>
> thx
On 29.01.2017 00:26, Paul B Mahol wrote:
> On 1/29/17, Andreas Cadhalpun wrote:
>> On 28.01.2017 12:44, Marton Balint wrote:
>>> If we reduce the number of extra lines (not at any cost), I think that
>>> helps.
>>> There is also a solution which keeps the
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 39
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vsrc_mkmap.c | 163 +++
4 files changed, 204 insertions(+)
create mode
On 1/29/17, Andreas Cadhalpun wrote:
> On 28.01.2017 12:44, Marton Balint wrote:
>> If we reduce the number of extra lines (not at any cost), I think that
>> helps.
>> There is also a solution which keeps the traditional C syntax, and is easy
>> to undestand even
On 28.01.2017 12:44, Marton Balint wrote:
> If we reduce the number of extra lines (not at any cost), I think that helps.
> There is also a solution which keeps the traditional C syntax, and is easy to
> undestand even at first glance.
>
> if (st->codecpar->channels > FF_SANE_NB_CHANNELS)
>
On 28.01.2017 03:48, Ronald S. Bultje wrote:
> I agree a macro here doesn't help. My concern wasn't with the check itself,
> I agree a file with 100 channels should error out. My concern is that these
> files will universally be the result of fuzzing, so I don't want to spam
> stderr with messages
On Sat, Jan 28, 2017 at 09:33:35PM +0100, Marijn Meijles wrote:
> On Sat, Jan 28, 2017 at 07:56:51PM +0100, Michael Niedermayer wrote:
> > On Sat, Jan 28, 2017 at 01:52:30PM +0100, Marijn Meijles wrote:
> > > Signed-off-by: Marijn Meijles
> > > ---
> > > libavformat/ac3dec.c |
On Sat, Jan 28, 2017 at 01:59:10PM +0100, Matthieu Bouron wrote:
> On Sat, Jan 28, 2017 at 12:59:39PM +0100, Matthieu Bouron wrote:
> > On Sat, Jan 28, 2017 at 02:25:34AM +0100, Michael Niedermayer wrote:
> > > On Fri, Jan 27, 2017 at 09:47:18AM +0100, Matthieu Bouron wrote:
> > > > On Fri, Jan
On Sat, Jan 28, 2017 at 06:55:15PM +0100, wm4 wrote:
> On Sat, 28 Jan 2017 17:28:29 +0100
> Paul Arzelier wrote:
>
> > Hopefuly, everything is okay right now :)
>
> Patch is fine with me.
applied
thx
[...]
--
Michael GnuPG fingerprint:
On 1/25/17, Paul B Mahol wrote:
> Only lossy part is decoded for now.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile| 3 +
> libavcodec/allcodecs.c | 2 +
> libavcodec/atrac3.c| 134 ++-
>
On Sat, Jan 28, 2017 at 06:04:02PM +, Kieran Kunhya wrote:
> On Sat, 28 Jan 2017 at 12:53 Marijn Meijles wrote:
>
> > This is a fix for https://trac.ffmpeg.org/ticket/6106 .
> >
> > The issue is that when detecting a swapped AC3 marker the data of the
> > frame is swapped.
On Sat, Jan 28, 2017 at 07:56:51PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 28, 2017 at 01:52:30PM +0100, Marijn Meijles wrote:
> > Signed-off-by: Marijn Meijles
> > ---
> > libavformat/ac3dec.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
> the
On Sat, Jan 28, 2017 at 07:53:06PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 28, 2017 at 11:42:24AM +0100, u-9...@aetey.se wrote:
> > Attaching the patch.
>
> please provide a git compatible patch
> git format-patch / send-email
>
> git is quite flexible and often takes diffs in mails too
On Sat, Jan 28, 2017 at 08:30:34PM +0100, Moritz Barsnick wrote:
> On Sat, Jan 28, 2017 at 11:50:27 +0100, u-9...@aetey.se wrote:
> > -// MAX_STRIPS limits the maximum quality you can reach
> > -//when you want high quality on high resolutions,
> > -// MIN_STRIPS limits the minimum
On Sat, Jan 28, 2017 at 11:50:27 +0100, u-9...@aetey.se wrote:
> -// MAX_STRIPS limits the maximum quality you can reach
> -//when you want high quality on high resolutions,
> -// MIN_STRIPS limits the minimum efficiently encodable bit rate
> -//on low resolutions
> -// the
On Sat, Jan 28, 2017 at 01:52:30PM +0100, Marijn Meijles wrote:
> Signed-off-by: Marijn Meijles
> ---
> libavformat/ac3dec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
the previous mail contains a description but the patch itself lacks
a commit message
On Sat, Jan 28, 2017 at 11:42:24AM +0100, u-9...@aetey.se wrote:
> Comments cleanup:
> - change the encoding of the original developer name from ISO-8859-1 to UTF-8
> - remove the stale/completed TODO list
> - fix a typo
>
> No code changes, only improved consistency in the comments.
>
> I
On 1/28/17, Michael Niedermayer wrote:
> On Fri, Jan 27, 2017 at 09:48:05PM -0500, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Fri, Jan 27, 2017 at 9:28 PM, Michael Niedermayer
>> wrote:
>>
>> > On Sat, Jan 28, 2017 at 01:26:40AM +0100, Andreas Cadhalpun wrote:
>>
On Fri, Jan 27, 2017 at 09:48:05PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Jan 27, 2017 at 9:28 PM, Michael Niedermayer
> wrote:
>
> > On Sat, Jan 28, 2017 at 01:26:40AM +0100, Andreas Cadhalpun wrote:
> > > On 27.01.2017 02:56, Marton Balint wrote:
> > > > I see 3
On Sat, 28 Jan 2017 at 12:53 Marijn Meijles wrote:
> This is a fix for https://trac.ffmpeg.org/ticket/6106 .
>
> The issue is that when detecting a swapped AC3 marker the data of the
> frame is swapped. However, in subsequent frames the data swapped is
> taken from the first
On Sat, 28 Jan 2017 18:35:01 +0100
Nicolas George wrote:
> Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> > So, if ff_inlink_make_frame_writable() takes AVFrame**, it will be
> > incompatible with framequeue framework, because it stores AVFrame*, so
> > it will
On Sat, 28 Jan 2017 17:28:29 +0100
Paul Arzelier wrote:
> Hopefuly, everything is okay right now :)
Patch is fine with me.
Bonus points for adding a fate tests for conflicting tags (I suppose
that would be a tiny FLAC file), and maybe one for mp3+ID3 tags. Of
course that
Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> So, if ff_inlink_make_frame_writable() takes AVFrame**, it will be
> incompatible with framequeue framework, because it stores AVFrame*, so
> it will contain dangling AVFrame*.
There is nothing "incompatible" about it, what would it even
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 2 +-
libavformat/sccenc.c | 122 +++
3 files changed, 124 insertions(+), 1 deletion(-)
create mode 100644 libavformat/sccenc.c
diff
Hopefuly, everything is okay right now :)
Le 27/01/2017 à 17:42, wm4 a écrit :
On Fri, 27 Jan 2017 17:32:08 +0100
Paul Arzelier wrote:
From 227d7d1f4b5665f824900cf2b14863621180dd1c Mon Sep 17 00:00:00 2001
From: Polochon-street
Date: Fri, 27
On 1/28/17, Nicolas George wrote:
> Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
>> so the behavior will be similar to
>> av_frame_make_writable().
>
> The point was to move away from that. Who copies a struct when you can
> move a pointer?
So, if
Fix a plainly wrong (inverted) misleading comment in the cinepak decoder.
No code changes.
I kindly ask to apply this fix, which of course was due from the beginning.
Attaching the patch.
Regards,
Rune
--- libavcodec/cinepak.c.orig 2017-01-28 17:00:37.0 +0100
+++ libavcodec/cinepak.c
On Sat, 28 Jan 2017 16:43:36 +0100
Nicolas George wrote:
> Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> > so the behavior will be similar to
> > av_frame_make_writable().
>
> The point was to move away from that. Who copies a struct when you can
> move a pointer?
Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> so the behavior will be similar to
> av_frame_make_writable().
The point was to move away from that. Who copies a struct when you can
move a pointer?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
On Sat, 28 Jan 2017 22:23:53 +0700
Muhammad Faiz wrote:
> so the behavior will be similar to
> av_frame_make_writable().
>
> Also use av_frame_copy() replacing
> av_image_copy()/av_samples_copy().
>
> Needed for the next patch.
>
> Suggested-by: wm4
>
On 1/28/17, wm4 wrote:
> On Sat, 28 Jan 2017 15:59:11 +0700
> Muhammad Faiz wrote:
>
>> On 1/28/17, Nicolas George wrote:
>> > L'octidi 8 pluviôse, an CCXXV, Muhammad Faiz a écrit :
>> >> affect filters that set partial_buf_size
>> >>
so the behavior will be similar to
av_frame_make_writable().
Also use av_frame_copy() replacing
av_image_copy()/av_samples_copy().
Needed for the next patch.
Suggested-by: wm4
Signed-off-by: Muhammad Faiz
---
libavfilter/avfilter.c | 26
On Sat, 28 Jan 2017 22:23:54 +0700
Muhammad Faiz wrote:
> affect filters that set partial_buf_size
> test-case
> ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, asplit
> [a][b];
> [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1];
> [b]
affect filters that set partial_buf_size
test-case
ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, asplit
[a][b];
[a] firequalizer=fixed=on, showcqt=s=1280x360 [a1];
[b] firequalizer=fixed=on, showcqt=s=1280x360 [b1];
[a1][b1] vstack'
Signed-off-by: Muhammad Faiz
On Sat, 28 Jan 2017 14:07:45 +0100
wm4 wrote:
> On Sat, 28 Jan 2017 13:01:54 +
> Mark Thompson wrote:
>
> > On 28/01/17 11:28, wm4 wrote:
> > > On Fri, 27 Jan 2017 19:53:50 +
> > > Mark Thompson wrote:
> > >
> > >> On
On Sat, 28 Jan 2017 13:01:54 +
Mark Thompson wrote:
> On 28/01/17 11:28, wm4 wrote:
> > On Fri, 27 Jan 2017 19:53:50 +
> > Mark Thompson wrote:
> >
> >> On 27/01/17 19:15, Marek Behun wrote:
> >>> On Fri, 27 Jan 2017 18:41:09 +
> >>> Mark
On 28/01/17 11:28, wm4 wrote:
> On Fri, 27 Jan 2017 19:53:50 +
> Mark Thompson wrote:
>
>> On 27/01/17 19:15, Marek Behun wrote:
>>> On Fri, 27 Jan 2017 18:41:09 +
>>> Mark Thompson wrote:
>>>
On 27/01/17 17:31, Marek Behún wrote:
> Use the
On Sat, Jan 28, 2017 at 12:59:39PM +0100, Matthieu Bouron wrote:
> On Sat, Jan 28, 2017 at 02:25:34AM +0100, Michael Niedermayer wrote:
> > On Fri, Jan 27, 2017 at 09:47:18AM +0100, Matthieu Bouron wrote:
> > > On Fri, Jan 27, 2017 at 02:30:40AM +0100, Michael Niedermayer wrote:
> > > > On Thu,
Signed-off-by: Marijn Meijles
---
libavformat/ac3dec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/ac3dec.c b/libavformat/ac3dec.c
index 363a32e..e85b0ac 100644
--- a/libavformat/ac3dec.c
+++ b/libavformat/ac3dec.c
@@ -49,8 +49,8 @@
This is a fix for https://trac.ffmpeg.org/ticket/6106 .
The issue is that when detecting a swapped AC3 marker the data of the
frame is swapped. However, in subsequent frames the data swapped is
taken from the first frame rather than the current frame. So all frames
are considered to be correct
On Fri, Jan 27, 2017 at 01:20:31PM -0800, Christopher Snowhill wrote:
> From: Chris Moeller
>
> ---
> libavformat/id3v2.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint:
On 1/28/17, wm4 wrote:
> On Fri, 27 Jan 2017 15:09:28 +0300
> Aleksandr Slobodenyuk wrote:
>
>> From 8d4c7c25674f1967d9ffab69b7ef15381df42ca8 Mon Sep 17 00:00:00 2001
>> From: Aleksandr Slobodeniuk
>> Date: Fri, 27 Jan
On Sat, Jan 28, 2017 at 12:31:33PM +0100, wm4 wrote:
> On Sat, 28 Jan 2017 11:50:27 +0100
> u-9...@aetey.se wrote:
>
> > Comments style cleanup:
> > - make all comments follow the same style (C-style)
> >
> > No code changes, only improved consistency and clarity in the comments.
> > No changes
On Sat, 28 Jan 2017, Michael Niedermayer wrote:
On Sat, Jan 28, 2017 at 01:26:40AM +0100, Andreas Cadhalpun wrote:
On 27.01.2017 02:56, Marton Balint wrote:
I see 3 problems (wm4 explicitly named them, but I also had them in mind)
- Little benefit, yet
- Makes the code less clean, more
On Sat, 28 Jan 2017 11:50:27 +0100
u-9...@aetey.se wrote:
> Comments style cleanup:
> - make all comments follow the same style (C-style)
>
> No code changes, only improved consistency and clarity in the comments.
> No changes in the comments besides whitespace and the syntactic delimiters.
>
On Fri, 27 Jan 2017 19:53:50 +
Mark Thompson wrote:
> On 27/01/17 19:15, Marek Behun wrote:
> > On Fri, 27 Jan 2017 18:41:09 +
> > Mark Thompson wrote:
> >
> >> On 27/01/17 17:31, Marek Behún wrote:
> >>> Use the LIBRESSL_VERSION_NUMBER macro to
On Fri, 27 Jan 2017 15:09:28 +0300
Александр Слободенюк wrote:
> From 8d4c7c25674f1967d9ffab69b7ef15381df42ca8 Mon Sep 17 00:00:00 2001
> From: Aleksandr Slobodeniuk
> Date: Fri, 27 Jan 2017 14:57:30 +0300
> Subject: [PATCH]
On Sat, 28 Jan 2017 15:59:11 +0700
Muhammad Faiz wrote:
> On 1/28/17, Nicolas George wrote:
> > L'octidi 8 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> >> affect filters that set partial_buf_size
> >> test-case
> >> ffplay -i lavfi 'aevalsrc=sin(1000*t*t),
On Fri, 27 Jan 2017 21:48:05 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Fri, Jan 27, 2017 at 9:28 PM, Michael Niedermayer
> wrote:
>
> > On Sat, Jan 28, 2017 at 01:26:40AM +0100, Andreas Cadhalpun wrote:
> > > On 27.01.2017 02:56, Marton Balint wrote:
Comments style cleanup:
- make all comments follow the same style (C-style)
No code changes, only improved consistency and clarity in the comments.
No changes in the comments besides whitespace and the syntactic delimiters.
The original file uses a mixture of C and C++ style comments, not for
Comments cleanup:
- change the encoding of the original developer name from ISO-8859-1 to UTF-8
- remove the stale/completed TODO list
- fix a typo
No code changes, only improved consistency in the comments.
I kindly ask to apply this cleanup, which of course was due from the beginning.
On 1/28/17, Nicolas George wrote:
> L'octidi 8 pluviôse, an CCXXV, Muhammad Faiz a écrit :
>> affect filters that set partial_buf_size
>> test-case
>> ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, asplit
>> [a][b];
>> [a] firequalizer=fixed=on,
63 matches
Mail list logo