On 1/29/17, Michael Niedermayer wrote:
> 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
ok
On 1/29/17, Michael Niedermayer wrote:
> 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
ok
_
On 1/29/17, Michael Niedermayer wrote:
> 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
>
ok
__
Instead of just updating statistics, have it actually do the work
instead of leaving that job to the call site.
Also: skip the samples by updating the frame data pointers
instead of moving the samples. More efficient and avoid writing
into shared frames.
Found-By: Muhammad Faiz
Signed-off-by: Ni
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
On 29 January 2017 at 01:00, Marek Behun wrote:
> 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:
> > > >
> > > >> O
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
> Signed-off-by: Muhammad Faiz
> ---
> li
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> Please push this patch. It's a nice simplification.
I rejected this patch. This message is unacceptable.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sun, 29 Jan 2017 12:47:16 +0100
Nicolas George wrote:
> Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> > Please push this patch. It's a nice simplification.
>
> I rejected this patch. This message is unacceptable.
You hadn't anything to say my convincing arguments.
His 1/2 patch was a s
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> You hadn't anything to say my convincing arguments.
>
> His 1/2 patch was a strict improvement over the current internal API.
> In particular, it gets it into line with the current
> av_frame_make_writable() API. There are other good arguments. Why
On Sun, 29 Jan 2017 12:54:53 +0100
Nicolas George wrote:
> Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> > You hadn't anything to say my convincing arguments.
> >
> > His 1/2 patch was a strict improvement over the current internal API.
> > In particular, it gets it into line with the current
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> His 1/2 patch was a strict improvement over the current internal API.
> In particular, it gets it into line with the current
> av_frame_make_writable() API.
You purposefully ignore the fact, already stated, that moving away from
av_frame_make_writab
On Sun, 29 Jan 2017 13:00:38 +0100
Nicolas George wrote:
> Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> > His 1/2 patch was a strict improvement over the current internal API.
> > In particular, it gets it into line with the current
> > av_frame_make_writable() API.
>
> You purposefully ig
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> Then you should stop moving away from it. The av_frame_make_writable
> design is superior for multiple reasons, and was intentionally designed
> this way by an intelligent mind with a lot of API-foresight.
>
> If you "move away from it" just like t
On Sun, 29 Jan 2017 13:06:13 +0100
Nicolas George wrote:
> Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> > Then you should stop moving away from it. The av_frame_make_writable
> > design is superior for multiple reasons, and was intentionally designed
> > this way by an intelligent mind with
On 1/29/17, wm4 wrote:
> On Sun, 29 Jan 2017 13:06:13 +0100
> Nicolas George wrote:
>
>> Le decadi 10 pluviose, an CCXXV, wm4 a ecrit :
>> > Then you should stop moving away from it. The av_frame_make_writable
>> > design is superior for multiple reasons, and was intentionally designed
>> > this
On Sun, 29 Jan 2017 13:06:13 +0100
Nicolas George wrote:
> Le decadi 10 pluviôse, an CCXXV, wm4 a écrit :
> > Then you should stop moving away from it. The av_frame_make_writable
> > design is superior for multiple reasons, and was intentionally designed
> > this way by an intelligent mind with
On Sun, 29 Jan 2017 13:20:29 +0100
Paul B Mahol wrote:
> On 1/29/17, wm4 wrote:
> > On Sun, 29 Jan 2017 13:06:13 +0100
> > Nicolas George wrote:
> >
> >> Le decadi 10 pluviose, an CCXXV, wm4 a ecrit :
> >> > Then you should stop moving away from it. The av_frame_make_writable
> >> > design
Signed-off-by: Paul B Mahol
---
doc/utils.texi | 3 +++
libavutil/eval.c | 4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 30a962a..1734439 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -776,6 +776,9 @@ Compute arcsine of @var{x}
On 1/29/17, Nicolas George wrote:
> Instead of just updating statistics, have it actually do the work
> instead of leaving that job to the call site.
>
> Also: skip the samples by updating the frame data pointers
> instead of moving the samples. More efficient and avoid writing
> into shared frame
On Sun, 29 Jan 2017 22:35:12 +1100
Matt Oliver wrote:
> Well perhaps making a tls_libressl implementation would be the better
> way to go as the APIs are only going to diverge further. So perhaps
> in order to support LibreSSL there should be a separate
> implementation using LibreSSLs independen
Name and purpose are more appropriate there since the code isn't
an ideal example.
Signed-off-by: Rostislav Pehlivanov
---
doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename doc/examples/decoder_targeted.c => tools/target_dec
On Sun, 29 Jan 2017 15:31:39 +
Rostislav Pehlivanov wrote:
> Name and purpose are more appropriate there since the code isn't
> an ideal example.
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c | 0
> 1 file changed, 0 insertions
On 29 January 2017 at 15:55, wm4 wrote:
> On Sun, 29 Jan 2017 15:31:39 +
> Rostislav Pehlivanov wrote:
>
> > Name and purpose are more appropriate there since the code isn't
> > an ideal example.
> >
> > Signed-off-by: Rostislav Pehlivanov
> > ---
> > doc/examples/decoder_targeted.c => too
On Sat, Jan 28, 2017 at 10:23:53PM +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
> Signed-off-by: Muhammad Faiz
> ---
Michael Niedermayer wrote:
>But id like to ask everyone to NOT escalate this further,
>iam sure that nothing good would come out of that.
+
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Only lossy part is decoded for now.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 3 +
libavcodec/allcodecs.c | 2 +
libavcodec/atrac3.c| 77 +-
libavcodec/atrac3plusdec.c | 14 +++-
libavcodec/avcodec.h | 2 +
libavcodec/codec_desc.c
Attaching the new version.
Regards,
Rune
>From f563e57f7609cd890b655cb9d140849f0917a6d3 Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 16:40:27 +0100
Subject: [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)
Change the encoding of the original developer name from ISO-88
Attaching the new version.
Regards,
Rune
>From e6719743b78862f897133d3f69a5e88a6a9a803e Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 18:14:19 +0100
Subject: [PATCH 2/3] libavcodec/cinepakenc.c: comments style cleanup
Avoid the present mixture of comment styles (C vs C++)
by convertin
Attaching the new version.
Regards,
Rune
>From f2041c0aaa5209e5d52649f741b6ee1dbc7e9021 Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 18:28:25 +0100
Subject: [PATCH 3/3] libavcodec/cinepak.c: fix a wrong (inverted) misleading
comment
Make the comment message understandable and correc
Le decadi 10 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> LGTM
Thanks, pushed.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg
Le decadi 10 pluviôse, an CCXXV, Michael Niedermayer a écrit :
> also we need a maintainer for the libavfilter core or a area covering
> avfilter.c and that person should then make a decission.
I have more or less acted as the de-facto maintainer of all that has to
do with scheduling in the lavfi
Signed-off-by: Philip Langdale
---
libswscale/input.c| 32
libswscale/swscale_unscaled.c | 4 +++-
libswscale/utils.c| 2 ++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 1f4e
On Sat, Jan 28, 2017 at 10:40:18PM +0100, Michael Niedermayer wrote:
> 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
Hello devs,
I have a quick question about passing data from AVFrame to AVPacket. Assume
that we are encoding video and we have a custom metadata that needs to be
handled in a frame accurate manner. The AVFrame can refer to this using the
opaque pointer. However, due to the nature of video codi
On Sat, 28 Jan 2017, 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?
By the way, why av_frame_make_writable cop
On 29.01.2017 04:46, Ronald S. Bultje wrote:
> Hm ... So I guess I wasn't clear about this, but the reason I didn't reply
> to other patches with log messages was not because I'm OK with, but simply
> to keep the discussion contained in a single thread and not spam the list.
> I'd prefer if the log
I wonder how unknown layouts ever worked without this?
Signed-off-by: Marton Balint
---
libavutil/frame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index c2f5509..a08e0c5 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -72
On 29.01.2017 04:02, Marton Balint wrote:
>
> 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
On 29.01.2017 02:34, Michael Niedermayer wrote:
> 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
On 29.01.2017 09:51, Paul B Mahol wrote:
> On 1/29/17, Michael Niedermayer wrote:
>> 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 as
On 29.01.2017 09:51, Paul B Mahol wrote:
> On 1/29/17, Michael Niedermayer wrote:
>> 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 assum
On 29.01.2017 09:52, Paul B Mahol wrote:
> On 1/29/17, Michael Niedermayer wrote:
>> 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 assum
It seems ive written this thing though i cannot really remember
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 981d71b195..80721e183d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -384,6 +384,7 @@ Muxers/Demu
On 30 January 2017 at 00:09, Marton Balint wrote:
>
> On Sat, 28 Jan 2017, 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
Fixes out-of-bounds writes.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/speedhq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 385f779f83..6ae1e0f8df 100644
--- a/libavcodec/speedhq.c
+++ b/libavcodec/speedhq.c
@@ -198,
On Sun, Jan 29, 2017 at 01:53:22PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/utils.texi | 3 +++
> libavutil/eval.c | 4 +++-
> 2 files changed, 6 insertions(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FA
On Sun, Jan 29, 2017 at 7:43 PM, Nicolas George wrote:
>
> As for myself, I do not wish to have any further interactions at all
> with wm4. Starting now, as far as I am concerned, for all intents and
> purposes, they and their messages no longer exist. I will reconsider my
> position if I learn th
Hey everyone,
Sorry for the long wait, here's a new patch addressing the feedback. In
addition, we discovered that this current implementation of optimal huffman
encoding is not compatible with QP RD, so we chose to disable QP RD for
mjpeg or amv encoding. (Wondering if that's acceptable, since it
On Mon, 30 Jan 2017 01:09:27 +0100 (CET)
Marton Balint wrote:
> On Sat, 28 Jan 2017, 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 co
Le primidi 11 pluviôse, an CCXXV, Marton Balint a écrit :
> I wonder how unknown layouts ever worked without this?
>
> Signed-off-by: Marton Balint
> ---
> libavutil/frame.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM, but I do not maintain that file.
Regards,
--
Nicolas G
On Mon, Jan 30, 2017 at 1:37 AM, Marton Balint wrote:
> I wonder how unknown layouts ever worked without this?
>
> Signed-off-by: Marton Balint
> ---
> libavutil/frame.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index c2f5509
On Sun, 29 Jan 2017 19:43:04 +0100
Nicolas George wrote:
> Le decadi 10 pluviôse, an CCXXV, Michael Niedermayer a écrit :
> > also we need a maintainer for the libavfilter core or a area covering
> > avfilter.c and that person should then make a decission.
>
> I have more or less acted as the
On Sun, 29 Jan 2017 22:24:12 + (UTC)
wrote:
> Hello devs,
>
> I have a quick question about passing data from AVFrame to AVPacket. Assume
> that we are encoding video and we have a custom metadata that needs to be
> handled in a frame accurate manner. The AVFrame can refer to this using t
On Mon, 30 Jan 2017 01:37:02 +0100
Marton Balint wrote:
> I wonder how unknown layouts ever worked without this?
>
> Signed-off-by: Marton Balint
> ---
> libavutil/frame.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index c2
On Mon, Jan 30, 2017 at 8:40 AM, wm4 wrote:
> On Mon, 30 Jan 2017 01:37:02 +0100
> Marton Balint wrote:
>
>> I wonder how unknown layouts ever worked without this?
>>
>> Signed-off-by: Marton Balint
>> ---
>> libavutil/frame.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff
56 matches
Mail list logo
