On 08.08.2019, at 10:36, Michael Niedermayer wrote:
> This provides an alternative to retry counters.
> Useful if there is no reasonable maximum number of iterations and
> no ordering that naturally avoids loops.
Going by the old principle of "an API is not tested until it has at least 3
users"
On 05.08.2019, at 23:34, Marton Balint wrote:
> These functions can be used to print a variable number of strings
> consecutively
> to the IO context. Unlike av_bprintf, no temporery buffer is necessary.
Hm, is there a use-example patch I missed?
Also is the #define ugliness worth it compared t
On 11.08.2019, at 20:41, Reimar Döffinger wrote:
> On 05.08.2019, at 23:34, Marton Balint wrote:
>
>> These functions can be used to print a variable number of strings
>> consecutively
>> to the IO context. Unlike av_bprintf, no temporery buffer is necessary.
>
&
On 07.08.2019, at 19:39, Daniel Kolesa wrote:
> The argument to vec_splat_u16 must be a literal. By making the
> function always inline and marking the arguments const, gcc can
> turn those into literals, and avoid build errors like:
Why marking the arguments const?
If it depends on that it soun
On 07.08.2019, at 19:39, Daniel Kolesa wrote:
> While this technically compiles in current ffmpeg, this is only
> because ffmpeg is compiled in strict ISO C mode, which disables
> the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
> replaced with a macro inside altivec.h, which defin
On 11.08.2019, at 21:24, Reimar Döffinger wrote:
> On 07.08.2019, at 19:39, Daniel Kolesa wrote:
>
>> The argument to vec_splat_u16 must be a literal. By making the
>> function always inline and marking the arguments const, gcc can
>> turn those into literals, and
On 11.08.2019, at 21:51, Marton Balint wrote:
>
>
> On Sun, 11 Aug 2019, Reimar Döffinger wrote:
>
>> On 11.08.2019, at 20:41, Reimar Döffinger wrote:
>>
>>> On 05.08.2019, at 23:34, Marton Balint wrote:
>>>> These functions can
On 12.08.2019, at 21:53, Michael Niedermayer wrote:
> On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote:
>> On 08.08.2019, at 10:36, Michael Niedermayer wrote:
>>
>>> This provides an alternative to retry counters.
>>> Useful if there i
on who might be unavoidable to involve anyway, or who has access
anyway.
Thus Michael's reply of not needing help is relevant - without a need the
default response is likely
to involve people only on a case-by-case basis (generally, maintainers would
and should be involved if the issu
On 14.08.2019, at 11:45, Paul B Mahol wrote:
> I strongly disagree with you. Why some people have subscription to security
> mailing list and I'm not allowed also?
Long version, explaining to the best of my knowledge and memory:
The people on it are on it because at some point it was considered n
On 15.08.2019, at 13:15, Vittorio Giovara wrote:
> I think being on the security list may have some professional implications
> too: if you use ffmpeg in your $dayjob, being notified of security problem
> in ffmpeg, and acting upon it before the fix lands in the tree, may be
> crucial. I think Pau
On 15.08.2019, at 19:38, Paul B Mahol wrote:
> On Thu, Aug 15, 2019 at 7:20 PM Reimar Döffinger
> wrote:
>
>> On 15.08.2019, at 13:15, Vittorio Giovara
>> wrote:
>>> I think being on the security list may have some professional
>> implications
>&g
On 15.08.2019, at 13:15, Vittorio Giovara wrote:
> if you use ffmpeg in your $dayjob, being notified of security problem
> in ffmpeg, and acting upon it before the fix lands in the tree, may be
> crucial.
I realize I only responded to this specific part only in the context of this
discussion.
W
On 18.08.2019, at 01:28, Michael Niedermayer wrote:
> 30M cycles -> 5M cycles
I see nothing wrong with it, but:
You could save reviewers a lot of time if you gave them a hint of what the
change
contains instead of them having to reverse-engineer.
In this case for example something like
"add inn
On 20.08.2019, at 10:57, Paul B Mahol wrote:
> Because of current overall toxic situation in FFmpeg, meeting will not be
> held until situation improves considerably.
It's a bit strange to read a such a opposite statement without any reason given
for the change of mind.
Also while I can see that
On Thu, Aug 22, 2019 at 12:06:03PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes usage of uninitialized data reading broken r3d files.
>
> Please review, Carl Eugen
> From efce9940b890b9cf5a9e7400b05be10f6906fbb1 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 22 Au
Hi Martin!
> On 10 Feb 2021, at 22:53, Martin Storsjö wrote:
>
> +.macro idct_16x16 bitdepth
> +function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1
> +//r0 - coeffs
> +mov x15, lr
> +
Binutils doesn't recognize "lr" as alias for x30
>>> It didn’t
Hi!
> On 24 Jan 2021, at 17:35, Andriy Gelman wrote:
>
> On Sat, 07. Nov 16:31, Andriy Gelman wrote:
>> On Sat, 31. Oct 10:17, Andriy Gelman wrote:
>>> On Fri, 16. Oct 00:02, Andriy Gelman wrote:
On Fri, 09. Oct 20:17, Andriy Gelman wrote:
> From: Chip Kerchner
>
> ---
> l
> On 25 Feb 2021, at 07:38, Guo, Yejun wrote:
> --- a/libavformat/smoothstreamingenc.c
> +++ b/libavformat/smoothstreamingenc.c
> @@ -501,7 +501,7 @@ static int ism_flush(AVFormatContext *s, int final)
>
> for (i = 0; i < s->nb_streams; i++) {
> OutputStream *os = &c->streams[i];
> -
> On 25 Feb 2021, at 18:52, Chad Fraleigh wrote:
>
> On 2/24/2021 10:38 PM, Guo, Yejun wrote:
>> libavdevice/v4l2.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
>> index 365bacd771..e11d10d20e 100644
>> --- a/libavdevice/v4l2.c
> On 27 Feb 2021, at 06:37, Guo, Yejun wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Reimar
>> D?ffinger
>>>
>
> For the code in this function, max length of file name is fixed, see the code
> below.
> Anyway, it still increases the on-stack variable size which
> On 27 Feb 2021, at 09:14, Guo, Yejun wrote:
>
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Paul B
>> Mahol
>> Sent: 2021年2月26日 19:37
>> To: FFmpeg development discussions and patches
>> Cc: Guo, Yejun
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/5] libavformat/proto
>
> I have never come around to setting up postfix for forwarding mails
> externally on my current system. So, for now, I am using the second best
> solution. Please see the attachment.
Maybe not worth the effort, but FYI git can communicate directly with
a SMTP server nowadays, and msmtmp is a
> On 9 Mar 2021, at 10:44, zsugabubus
> wrote:
>
> Hi all,
>
> I was not able to find any patches or mails, only two open tickets that
> mention DRM decryption in some way:
>
> https://trac.ffmpeg.org/ticket/1793
> https://trac.ffmpeg.org/ticket/1800
>
> ...however there were no updates for
On 6 February 2019 11:46:52 CET, Michael Niedermayer
wrote:
>On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote:
>> I'm getting an ssl error
>> with pwclient today. This is the first time I've tried using
>pwclient since this
>> upgrade, so not sure if it's related.
>>
>> ssl.SSL
This is the equivalent to what 7d317d4706b49d572a1eb5269438753be18362c7
did for the codec-specific options.
av_opt_copy has specific handling so it's fine that we already copied
the whole context before.
Signed-off-by: Reimar Döffinger
---
libavcodec/frame_thread_encoder.c | 3 +++
1
On Wed, Aug 23, 2017 at 10:26:45PM +0200, Alexander Strasser wrote:
> On 2017-08-22 17:23 +, Michael Niedermayer wrote:
> > ffmpeg | branch: master | Michael Niedermayer |
> > Tue Aug 22 18:36:26 2017 +0200| [a2e444d5bb2e3115d3afcc0cca9d1506c90436a2]
> > | committer: Michael Niedermayer
> >
On Wed, Sep 13, 2017 at 07:12:48PM +0200, Reimar Döffinger wrote:
> This is the equivalent to what 7d317d4706b49d572a1eb5269438753be18362c7
> did for the codec-specific options.
> av_opt_copy has specific handling so it's fine that we already copied
> the whole context before.
Bt
On Wed, Sep 13, 2017 at 02:49:59PM -0300, James Almer wrote:
> On 9/13/2017 2:23 PM, Carl Eugen Hoyos wrote:
> > 2017-09-13 19:10 GMT+02:00 James Almer :
> >> Some targets, like NetBSD and DJGPP, don't seem to support it.
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> configure | 6 ++
> >
On Fri, Sep 15, 2017 at 02:16:58AM +0200, Michael Niedermayer wrote:
> On Wed, Sep 13, 2017 at 08:11:38PM +0200, Reimar Döffinger wrote:
> > On Wed, Sep 13, 2017 at 07:12:48PM +0200, Reimar Döffinger wrote:
> > > This is the equivalent to what 7d317d4706b49d572a1eb5269438753be183
code a larger video that we
allocated data structures for, causing out-of-bounds writes.
Signed-off-by: Reimar Döffinger
---
libavcodec/mss12.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mss12.c b/libavcodec/mss12.c
index 6b58aa29..d42093b 100644
--- a/libavcodec
On Thu, Feb 25, 2016 at 09:25:08PM +0100, wm4 wrote:
> On Thu, 25 Feb 2016 21:06:46 +0100
> Reimar Döffinger wrote:
>
> > Reported as https://trac.mplayerhq.hu/ticket/2264 but have
> > not been able to reproduce with FFmpeg-only.
> > I have no idea what coded_heig
(documented)
API in addition though.
Signed-off-by: Reimar Döffinger
---
libavcodec/mjpegdec.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 113022f..b6fbeab 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec
On 26.02.2016, at 02:38, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 12:15:19AM +0100, Reimar Döffinger wrote:
>> We do neither document nor check such a requirement
>> and for application-provided get_buffer2 they could
>> contain the result of a malloc(0) or whate
On 26.02.2016, at 11:42, Hendrik Leppkes wrote:
> On Fri, Feb 26, 2016 at 11:35 AM, Reimar Döffinger
> wrote:
>> On 26.02.2016, at 02:38, Michael Niedermayer wrote:
>>
>>> On Fri, Feb 26, 2016 at 12:15:19AM +0100, Reimar Döffinger wrote:
>>>>
On Fri, Feb 26, 2016 at 12:40:19PM +0100, Clément Bœsch wrote:
> On Fri, Feb 26, 2016 at 11:29:05AM +0100, wm4 wrote:
> > Unfortunately I have to agree. I got some crashes in libavfilter when I
> > didn't set some "unused" plane pointers to NULL. Some code is just lazy
> > and checks plane pointers
On Fri, Feb 26, 2016 at 12:59:08PM +0100, Michael Niedermayer wrote:
> This should return an error to the decoder if the struct it tried to
> getbuffer is dirty
It seems like a good idea, however it likely won't help
for programs providing their own getbuffer2 as they will
probably fill the data[
Well, there I go, doing my own idle discussions
I just complained about ;)
On Fri, Feb 26, 2016 at 01:00:23PM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 12:19:18 +0100
> Reimar Döffinger wrote:
> > I am not exactly sure what their opinion is to be honest.
> > However this at
On 26.02.2016, at 11:26, wm4 wrote:
> On Thu, 25 Feb 2016 22:39:51 +0100
> Reimar Döffinger wrote:
>
>> On Thu, Feb 25, 2016 at 09:25:08PM +0100, wm4 wrote:
>>> On Thu, 25 Feb 2016 21:06:46 +0100
>>> Reimar Döffinger wrote:
>>>
>>>> Repo
On 26.02.2016, at 14:01, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 01:17:29PM +0100, Reimar Döffinger wrote:
>> Well, there I go, doing my own idle discussions
>> I just complained about ;)
>>
>> On Fri, Feb 26, 2016 at 01:00:23PM +0100, wm4 wrote:
>&
Check that the required plane pointers and only
those are set up.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 15 +++
libavutil/frame.h | 3 +++
2 files changed, 18 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..56c8d7c 100644
--- a
On Fri, Feb 26, 2016 at 06:13:04PM +, Derek Buitenhuis wrote:
> On 2/26/2016 5:42 PM, Reimar Döffinger wrote:
> > +av_assert0(frame->format == avctx->pix_fmt);
>
> Is this valid? Mid-stream colorspace changes are fairly common.
I believed we enforce a sequenc
Check that the required plane pointers and only
those are set up.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 14 ++
libavutil/frame.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..af5ff93 100644
--- a
On Fri, Feb 26, 2016 at 10:39:41PM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 22:25:21 +0100
> Reimar Döffinger wrote:
>
> > Check that the required plane pointers and only
> > those are set up.
> >
> > Signed-off-by: Reimar Döffinger
>
Check that the required plane pointers and only
those are set up.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 20
libavutil/frame.h | 3 +++
2 files changed, 23 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..1b6397c 100644
Check that the required plane pointers and only
those are set up.
Currently does not enforce anything for the palette
pointer of pseudopal formats as I am unsure about the
requirements.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 27 +++
libavutil/frame.h
On Sat, Feb 27, 2016 at 02:21:18AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 11:06:22PM +0100, Reimar Döffinger wrote:
> > +static void validate_avframe_allocation(const AVCodecContext *avctx,
> > AVFrame *frame)
> > +{
> > +if (avctx->co
On Fri, Feb 26, 2016 at 11:41:41PM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 22:59:17 +0100
> Reimar Döffinger wrote:
> > > Can you move it to a separate function? Say, ff_verify_frame(). This
> > > could get much more complicated too when checking AVBufferRef usage or
>
Check that the required plane pointers and only
those are set up.
Currently does not enforce anything for the palette
pointer of pseudopal formats as I am unsure about the
requirements.
Signed-off-by: Reimar Döffinger
---
doc/APIchanges | 6 ++
libavcodec/utils.c | 27
On Sat, Feb 27, 2016 at 01:01:40PM +0100, Reimar Döffinger wrote:
> Check that the required plane pointers and only
> those are set up.
> Currently does not enforce anything for the palette
> pointer of pseudopal formats as I am unsure about the
> requirements.
>
> Signed-off
On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:
> On 02/27/2016 02:03 PM, Mats Peterson wrote:
> >Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
> >In case there will be other palettized formats in the future, I have
> >"guarded" myself by using 1 << bits_pe
On Sat, Feb 27, 2016 at 02:58:39PM +0100, Mats Peterson wrote:
> And yes, QuickTime has a "default palette" for each bit depth that it can
> use, and no palette will be stored in the video sample description in that
> case. But that's only sensible to use for 1 bpp black & white or 8 bpp
> grayscal
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
> On 02/27/2016 03:37 PM, Mats Peterson wrote:
> >
> >
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> I suppose
On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote:
> On 02/27/2016 04:13 PM, Mats Peterson wrote:
> >On 02/27/2016 04:08 PM, Mats Peterson wrote:
> >>On 02/27/2016 04:07 PM, Mats Peterson wrote:
> >>>On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
>
On Sat, Feb 27, 2016 at 06:05:20PM +0100, Mats Peterson wrote:
> On 02/27/2016 05:45 PM, Reimar Döffinger wrote:
> >>Not that it couldn't be done with side data packets, though.
> >
> >If it doesn't support side data then the muxers are plain broken.
>
>
On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
> On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
> >That's not what e.g. the matroska demuxer produces, so stream
> >copying with some generic remuxing example I am really sure that is
> >NOT how the packet
On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
> should rawvideo AVPackets palette use data[] or sidedata, honestly i
> do not know, but i dont think it makes a big difference
> even supporting both, likely only adds 3-5 lines of code or so
> its more a philosophical question
On Sat, Feb 27, 2016 at 07:52:52PM +0100, Mats Peterson wrote:
> On 02/27/2016 07:46 PM, Reimar Döffinger wrote:
> >On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
> >>On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
> >>>That's not what e.g. the m
On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote:
> On 02/27/2016 09:21 PM, Mats Peterson wrote:
> >On 02/27/2016 08:42 PM, Reimar Döffinger wrote:
> >>Well, then we know I can only blame Mats for "only" making it
&
On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
> -if (!avist->hdr_pal_done) {
> -int64_t cur_offset = avio_tell(pb);
> -avio_seek(pb, avist->pal_offset, SEEK_SET);
> -for (i = 0; i < pal_size; i++) {
> -
On 28.02.2016, at 01:13, Mats Peterson wrote:
> On 02/28/2016 12:34 AM, Reimar Döffinger wrote:
>
>> On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
>>> -if (!avist->hdr_pal_done) {
>>> -
On 28.02.2016, at 03:10, Mats Peterson wrote:
> On 02/28/2016 03:00 AM, Mats Peterson wrote:
>>
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Why is the packet data
On 28.02.2016, at 11:19, Mats Peterson wrote:
> From libavutil/pixfmt.h:
>
> * @note
> * AV_PIX_FMT_RGB32 is handled in an endian-specific manner. An RGBA
> * color is put together as:
> * (A << 24) | (R << 16) | (G << 8) | B
> * This is stored as BGRA on little-endian CPU architectures and ARGB
On Sun, Feb 28, 2016 at 06:11:27AM +0100, Mats Peterson wrote:
> On 02/28/2016 05:38 AM, Mats Peterson wrote:
> >On 02/28/2016 05:27 AM, Mats Peterson wrote:
> >>Use "palette side data" instead of "palette extradata" in error message.
> >>
> >>
> >>
> >>_
On Sun, Feb 28, 2016 at 12:33:16PM +0100, Mats Peterson wrote:
> On 02/28/2016 12:26 PM, Mats Peterson wrote:
> >On 02/28/2016 12:16 PM, Reimar Döffinger wrote:
> >Well, the documentation says that avio_seek() is a variant of the
> >fseek() function. I would rather say it
On Sun, Feb 28, 2016 at 12:26:15PM +0100, Mats Peterson wrote:
> >Also it might be helpful for you to have a look at tests/fate/demux.mak
> >and tests/fate/video.mak and use copy-paste to write some basic tests
> >for all the things you implement, so it doesn't get broken the moment
> >you look the
On Sun, Feb 28, 2016 at 12:53:18PM +0100, Mats Peterson wrote:
> -avist->pal_offset = avio_tell(pb) + 40;
> +if (pb->seekable)
> +avist->pal_offset = avio_tell(pb) + 40;
I don't mind, but the check seems unnecessary here?
> -if (enc->codec_i
I cannot see any point whatsoever to use
double here instead of float.
Using float allows for use of SIMD.
---
libavcodec/aacenc_utils.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
index cb5bc8d..571b1e6 100644
---
Avoids trashing the CPU cache each time the
cost cache is cleared.
---
libavcodec/aaccoder_twoloop.h | 20
libavcodec/aacenc.c | 7 +--
libavcodec/aacenc.h | 4 +---
libavcodec/aacenc_quantization_misc.h | 17 +++--
On 02.03.2016, at 04:34, Ganesh Ajjanagadde wrote:
> On Tue, Mar 1, 2016 at 6:34 PM, Reimar Döffinger
> wrote:
>> Avoids trashing the CPU cache each time the
>> cost cache is cleared.
>
> Just curious as to roughly the magnitude of perf improvement? No
> comments o
On 02.03.2016, at 04:48, Ganesh Ajjanagadde wrote:
> On Tue, Mar 1, 2016 at 4:55 PM, Reimar Döffinger
> wrote:
>> I cannot see any point whatsoever to use
>> double here instead of float.
>
> There can be some negligible accuracy differences, but I do not see
>
On 04.03.2016, at 11:24, Nicolas George wrote:
> Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit :
>> Neither a good play on words nor elaborative; not even helpful.
>>
>> You say they are random numbers, CE says it is continuous. What is correct?
>>
>> Let's assume the N-tag is not r
On Sat, Mar 05, 2016 at 02:32:56PM +0100, Mats Peterson wrote:
> On 03/05/2016 02:24 PM, Mats Peterson wrote:
> >
> >The original toon.avi doesn't contain xxpc chunks at keyframes either,
> >if that can be of any comfort. It only contains two xxpc chunks, at
> >that. If you're able to invent someth
On Sat, Mar 05, 2016 at 01:41:32PM +0100, Michael Niedermayer wrote:
> + * Note, for variable framerate material this has undefined meaning
> currently
> + * and is not set to the actual framerate nor {0,1} but can be set to
> + * 1/timebase (FIXME) the code in some parts assumes frame
On Sat, Mar 05, 2016 at 06:56:30PM +0100, Michael Niedermayer wrote:
> On Sat, Mar 05, 2016 at 06:01:11PM +0100, Reimar Döffinger wrote:
> > On Sat, Mar 05, 2016 at 01:41:32PM +0100, Michael Niedermayer wrote:
> > > + * Note, for variable framerate material this has
FFmpeg currently lacks a fallback inflate algorithm
when zlib is not available.
We have a lot of infrastructure for it already available
though, like VLC code reading (though only in libavcodec,
not libavutil).
This is a hackish quick-and-dirty version.
It certainly is not optimized, and I would wa
On 06.03.2016, at 02:50, Timothy Gu wrote:
> To Michael and all release makers: after this patchset when making a
> release in a release branch, please do ALL of the following in the
> following order.
Been absent a while from the list, but this sounds like we do not have
documentation on the rel
Makes it far easier to spot the issue if e.g.
caused by a typo in the code table.
Signed-off-by: Reimar Döffinger
---
libavcodec/bitstream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/bitstream.c b/libavcodec/bitstream.c
index 1acb7a3..9344175 100644
--- a
On Sat, Mar 05, 2016 at 06:38:40PM +0100, Michael Niedermayer wrote:
> diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> index 0cfffb7..357dd34 100644
> --- a/libavformat/avienc.c
> +++ b/libavformat/avienc.c
> @@ -306,8 +306,7 @@ static int avi_write_header(AVFormatContext *s)
>
On Wed, Mar 02, 2016 at 07:33:31PM +, Rostislav Pehlivanov wrote:
> On 1 March 2016 at 21:55, Reimar Döffinger wrote:
> > I cannot see any point whatsoever to use
> > double here instead of float.
> > Using float allows for use of SIMD.
> > ---
> > libavcode
On Wed, Mar 02, 2016 at 07:19:08PM +, Rostislav Pehlivanov wrote:
> > -entry->cb = cb;
> > -entry->rtz = rtz;
> > + cb, 1.0f, INFINITY, &entry->bits,
> > &entry->energy, 0);
> > +*cache_state = cb;
> > }
> > -if (bits)
> > -
On Sun, Mar 06, 2016 at 12:18:48PM +0100, Marton Balint wrote:
> This may improve precision for some compilers and architectures.
>
> Signed-off-by: Marton Balint
> ---
> libavcodec/aactab.h | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/libavc
On Sun, Mar 06, 2016 at 12:21:30PM +0100, Michael Niedermayer wrote:
> On Sun, Mar 06, 2016 at 11:46:23AM +0100, Reimar Döffinger wrote:
> > Makes it far easier to spot the issue if e.g.
> > caused by a typo in the code table.
> >
> > Signed-off-by: Reimar Döffing
On Sun, Mar 06, 2016 at 01:15:33PM +0100, Mats Peterson wrote:
> On 03/06/2016 12:55 PM, Mats Peterson wrote:
> >On 03/06/2016 12:51 PM, Mats Peterson wrote:
> >>On 03/06/2016 12:09 PM, Michael Niedermayer wrote:
> >>
> >>Once again, why are these tests unneeded?
> >>
> >>Mats
> >>
> >
> >avio_tell
On Sun, Mar 06, 2016 at 08:43:15AM -0500, Ronald S. Bultje wrote:
> We have a lot of infrastructure for it already available
> > though, like VLC code reading (though only in libavcodec,
> > not libavutil).
> > This is a hackish quick-and-dirty version.
> > It certainly is not optimized, and I woul
Approximately 11% faster transcoding from mp3 with
default settings.
Signed-off-by: Reimar Döffinger
---
libavcodec/aacenc.c | 9 -
libavcodec/aacenc.h | 5 +++--
libavcodec/aacenc_quantization_misc.h | 3 ++-
3 files changed, 9 insertions(+), 8
Approximately 10% faster transcode from mp3 to aac
with default settings.
Signed-off-by: Reimar Döffinger
---
libavcodec/aacenc_utils.h | 47 ++-
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/libavcodec/aacenc_utils.h b/libavcodec
On Sun, Mar 06, 2016 at 07:35:58PM +0100, Reimar Döffinger wrote:
> Approximately 10% faster transcode from mp3 to aac
> with default settings.
Note to anyone wanting to optimize it further:
There is almost 25% on the table if you can replace
the pow() and cos() function uses by somethin
On Sun, Mar 06, 2016 at 03:49:00PM -0300, James Almer wrote:
> On 3/6/2016 3:35 PM, Reimar Döffinger wrote:
> > Approximately 10% faster transcode from mp3 to aac
> > with default settings.
> >
> > Signed-off-by: Reimar Döffinger
> > ---
&g
On Sun, Mar 06, 2016 at 04:46:08PM -0300, James Almer wrote:
> On 3/6/2016 4:14 PM, Reimar Döffinger wrote:
> > On Sun, Mar 06, 2016 at 03:49:00PM -0300, James Almer wrote:
> >> On 3/6/2016 3:35 PM, Reimar Döffinger wrote:
> >> Are you sure this wasn't vectorized a
This ensures gcc does not create unnecessary
loads or stores and possibly even does not vectorize
the negation.
Speeds up mp3 to aac transcoding with default settings
by 10% when using "gcc (Debian 5.3.1-10) 5.3.1 20160224".
Signed-off-by: Reimar Döffinger
---
libavcodec/aacenc_u
On 07.03.2016, at 04:04, Ganesh Ajjanagadde wrote:
> On Sun, Mar 6, 2016 at 1:43 PM, Reimar Döffinger
> wrote:
>> On Sun, Mar 06, 2016 at 07:35:58PM +0100, Reimar Döffinger wrote:
>>> Approximately 10% faster transcode from mp3 to aac
>>> with default settings.
&g
On 08.03.2016, at 04:50, Ganesh Ajjanagadde wrote:
> On Mon, Mar 7, 2016 at 2:54 AM, Reimar Döffinger
> wrote:
>>
>>> Can you be more specific, and are you sure about this?
>>
>> Just run your favourite performance analysis tool and you'll see.
>&g
On Mon, Mar 07, 2016 at 10:50:53PM -0500, Ganesh Ajjanagadde wrote:
> On Mon, Mar 7, 2016 at 2:54 AM, Reimar Döffinger
> wrote:
> >> Can you be more specific, and are you sure about this?
> >
> > Just run your favourite performance analysis tool and you'll see.
&g
On Tue, Mar 08, 2016 at 10:40:18PM +, Rostislav Pehlivanov wrote:
> On 6 March 2016 at 16:29, Reimar Döffinger wrote:
>
> > Approximately 11% faster transcoding from mp3 with
> > default settings.
> >
> > Signed-off-by: Reimar Döffinger
> >
>
> Ver
On Tue, Mar 08, 2016 at 10:45:41PM +, Rostislav Pehlivanov wrote:
> On 6 March 2016 at 20:26, Reimar Döffinger wrote:
>
> > This ensures gcc does not create unnecessary
> > loads or stores and possibly even does not vectorize
> > the negation.
> > Speeds
On 08.03.2016, at 04:48, Ganesh Ajjanagadde wrote:
> +nzl += expf(logf(s / ethresh) * nzslope);
Shouldn't log2f/exp2f be faster?
log2f at least has CPU support on x86 AFAICT.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
On 09.03.2016, at 04:16, Ganesh Ajjanagadde wrote:
> Yields 2x improvement in function performance, and boosts aac encoding
> speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> after:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s system 105%
> cpu 4.
On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > Yields 2x improvement in function performance, and boosts aac encoding
> > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> > af
ons and details: see the licenses.
Regards,
Reimar Döffinger
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
101 - 200 of 794 matches
Mail list logo
