This uses ff_exp2fi to get a speedup (~ 6x).
sample benchmark (Haswell, GNU/Linux):
old:
19102 decicycles in sbr_dequant,1023 runs, 1 skips
19002 decicycles in sbr_dequant,2045 runs, 3 skips
17638 decicycles in sbr_dequant,4093 runs, 3 skips
15825 decicycles in s
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/internal.h | 19 +++
libavcodec/jpeg2000.c | 18 ++
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 445b45a..afcf00d 100644
--- a/libavcodec/intern
These postfixes can be computed statically, and there is no need to
waste runtime resources.
Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/eval.c | 52
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavu
On 12/10/2015 8:02 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/x86/hevc_sao_10bit.asm | 142
> +++---
> 1 file changed, 57 insertions(+), 85 deletions(-)
Ping for patchset.
___
ffmpeg-devel
Adds HLS flags to emit the X-PLAYLIST-TYPE tag to the top of generated
M3U8 files.
See the spec:
https://tools.ietf.org/html/draft-pantos-http-live-streaming-18#section-4.3.3.5
There was also an FFMPEG trac ticket #4571 that had this as a wishlist item:
https://trac.ffmpeg.org/ticket/4571
---
d
On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde wrote:
> On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote:
>> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
[...]
>>>
>>> diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>>> index d998dba..e60
On Tue, Dec 15, 2015 at 11:50:21PM +0100, Andreas Cadhalpun wrote:
> If that is the case, the loop setting predictor_state in
> sonic_decode_frame causes out of bounds reads of int_samples, which has
> only frame_size number of elements.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/so
On Tue, Dec 15, 2015 at 10:41:15PM +0100, Andreas Cadhalpun wrote:
> On 15.12.2015 08:17, Anton Khirnov wrote:
> > Can you share the sample that shows the problem?
>
> I could, but it's of no use for comparing with libopus, because their
> decoder errors out in an unrelated check.
>
> > From what
If that is the case, the loop setting predictor_state in
sonic_decode_frame causes out of bounds reads of int_samples, which has
only frame_size number of elements.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/sonic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/sonic
Hi Derek,
On Tue, 15 Dec 2015 17:39:23 +, Derek Buitenhuis wrote:
> On 12/15/2015 5:23 PM, Jean Delvare wrote:
> > Looks like something different from what we were discussing here.
>
> In which way?
>
> That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
I see two com
On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote:
> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
>> exp2 suffices here. Some trivial (~ 4x) speedup is done in addition here by
>> reusing results.
>>
>
>> This is bit-identical to the old values.
>
> That may be true
On 15.12.2015 14:42, Timo Rothenpieler wrote:
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?
That would be OK for me.
> Or is putting that exception-text in nvenc.c enough to make enabling it
> by
On 15.12.2015 03:15, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 01:19:01AM +0100, Andreas Cadhalpun wrote:
>> On 15.12.2015 00:43, Michael Niedermayer wrote:
>> ffmdec.c | 28
>> 1 file changed, 28 insertions(+)
>> 5a300bbcfb78b1f24b8b7c572d420577b2a1b1f3
On 15.12.2015 08:17, Anton Khirnov wrote:
> Can you share the sample that shows the problem?
I could, but it's of no use for comparing with libopus, because their
decoder errors out in an unrelated check.
> From what I can see, libopus does not do any clipping at that point, so
> something else m
On Tue, Dec 15, 2015 at 05:46:08PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> libswscale/arm/yuv2rgb_neon.S | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
should be ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposi
On 12/15/2015 06:51 PM, Mats Peterson wrote:
Here is a *suggestion* for how to end the QuickTime palette in Matroska
saga. I have created a new file 'qtpalette.c' with a function
get_qtpalette(), that will be called from both matroskadec.c and mov.c.
So, no more calling into another demuxer to ge
Fixes ticket 279.
---
libavformat/mpegtsenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 19032f3..a0dca4a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1519,8 +1519,6 @@ static int mpegts_write_packet_intern
Here is a *suggestion* for how to end the QuickTime palette in Matroska
saga. I have created a new file 'qtpalette.c' with a function
get_qtpalette(), that will be called from both matroskadec.c and mov.c.
So, no more calling into another demuxer to get the palette, and no
duplicated code, sinc
On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
>
> Hi,
>
> This commit is likely to break fate on arm since the current C code path
> seems to use less precision.
>
> How should I proceed to fix it ?
hmm
can the precission of the C code path a
On 12/15/2015 5:23 PM, Jean Delvare wrote:
> Looks like something different from what we were discussing here.
In which way?
That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@f
---
ffserver.c | 77 --
1 file changed, 50 insertions(+), 27 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index 029771c..b7f9616 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -138,7 +138,7 @@ typedef struct HTTPContext {
int http
On Tue, 15 Dec 2015 16:56:02 +, Derek Buitenhuis wrote:
> On 12/15/2015 10:44 AM, Jean Delvare wrote:
> > Originally I proposed this patch for performance reasons and also
> > because I think it makes the code more readable. But seeing how the
> > same cast is already present everywhere in the
On 12/15/2015 05:49 PM, Moritz Barsnick wrote:
Hi Mats,
On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote:
Sorry if this may sound idiotic, but if I provide a unified patch for a
file that is newer/different from the one I have here, it won't work, right?
"It depends." ;-)
By the w
On 12/15/2015 10:44 AM, Jean Delvare wrote:
> Originally I proposed this patch for performance reasons and also
> because I think it makes the code more readable. But seeing how the
> same cast is already present everywhere in the ffmpeg code, I would now
> also invoke consistency. There's no ratio
Hi Mats,
On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote:
> Sorry if this may sound idiotic, but if I provide a unified patch for a
> file that is newer/different from the one I have here, it won't work, right?
"It depends." ;-)
By the way, git handles this kind of stuff nicely.
It
From: Matthieu Bouron
---
Hi,
This commit is likely to break fate on arm since the current C code path
seems to use less precision.
How should I proceed to fix it ?
Matthieu
---
libswscale/arm/swscale_unscaled.c | 53 ---
libswscale/arm/yuv2rgb_neon.S | 77 ++
From: Matthieu Bouron
---
libswscale/arm/yuv2rgb_neon.S | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 01d8536..9f9dd2a 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@
Sorry if this may sound idiotic, but if I provide a unified patch for a
file that is newer/different from the one I have here, it won't work, right?
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
doc/ffmpeg.texi |4 ++--
ffmpeg_opt.c| 22 +-
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6307470..a38a32e 100644
--- a/doc/ffmpeg.texi
+++
On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote:
> >
> > using a random IV value would break any regression tests
> > see AVFMT_FLAG_BITEXACT
> >
> Fixed, only generating a random IV when bitexact is not enabled.
> Updated patch files attached.
>
> >
> > is this filling in a rando
Hello All,
There is updated patch version initially introduced by Sven Dueking
This patch expose 3 QSV functions as public.
This is needed because the VPP needs access to these functions too.
Please review.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
0001-a
On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote:
[...]
> @@ -4007,6 +4008,147 @@ static int mov_read_free(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return 0;
> }
>
> +static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +uint32_t format =
On 10 Dec, Philip Langdale wrote :
> >Are we really talking about including a huge 3rd party header because
> >distros are so lazy? What's next, do we add Windows headers to the
> >FFmpeg tree, because MinGW lags severely behind the newest definitions
> >like HEVC DXVA support?
>
> Admittedly, we
On 15 Dec, Timo Rothenpieler wrote :
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?
I still don't understand why you want to fork this header into the
FFmpeg tree.
--
Jean-Baptiste Kempf
http://
So, to get somewhere with this, would everybody be ok if I change this
to remove the non-free marking, but keep it disabled by default for now?
Or is putting that exception-text in nvenc.c enough to make enabling it
by default viable?
signature.asc
Description: OpenPGP digital signature
___
I don't really know which is worse, calling a function in mov.c, or
"duplicating" (because I'll have to admit that it's a form of
duplication in a technical sense) code in it. Because *if*, against all
odds, there would have to be a change in the QuickTime color table
handling, it's easy to for
On Fri, Dec 11, 2015 at 3:02 PM, Andrey Utkin
wrote:
> On Wed, Dec 9, 2015 at 2:07 AM, Andrey Utkin
> wrote:
>> Hi! Could please anybody look at MJPEG RTP encoder issue with yuvj422p
>> https://trac.ffmpeg.org/ticket/3823#comment:17 ? This pixel format
>> becomes popular for IP cameras having no
> >
> > +struct AVAESCTR;
>
> Is this needed?
>
Indeed compiles for me without it, I matched the existing code in aes.h, and in
general I prefer to define the structs in advance.
If you prefer that I will remove it, please let me know
> > +subsample_count = AV_RB16(sc->cenc.auxiliary_info_
Hi Hendrik,
On Tue, 15 Dec 2015 11:31:57 +0100, Hendrik Leppkes wrote:
> On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer
> wrote:
> > On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> >> Also I can see 12 occurrences of the same cast for this parameter of
> >> function av_ima
On Tue, 15 Dec 2015 11:20:40 +0100, Michael Niedermayer wrote:
> yes, I have no real oppinion on this except that C is insane or I am
C is insane, who would dare to argue otherwise? ;-)
More than the language itself, the fact that the compilers think they
can reorder instructions the way they lik
On Tuesday 15 December 2015 11:29:58 am Moritz Barsnick wrote:
> On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote:
> > I found that the ffmpeg H.265 decoder can't run on the iOS platform
> > when I enable the neon assembly code, it crashed when playing the
> > H.265 clip. When disable the
On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
>> Hallo Michael,
>>
>> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
>> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
>> > > As I underst
On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote:
> I found that the ffmpeg H.265 decoder can't run on the iOS platform
> when I enable the neon assembly code, it crashed when playing the
> H.265 clip. When disable the neon assembly code it works fine. What's
> the problem with the H.265 n
On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> Hallo Michael,
>
> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
> > > As I understand it, the temporary stack buffer "src_data" was
> > > introduced s
I found that the ffmpeg H.265 decoder can't run on the iOS platform when I
enable the neon assembly code, it crashed when playing the H.265 clip. When
disable the neon assembly code it works fine. What's the problem with the H.265
neon assembly code?
Best regards,
Zhuhb
_
On Mon, Dec 14, 2015 at 6:18 PM, Michael Niedermayer
wrote:
> On Mon, Dec 14, 2015 at 05:49:48PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
> > Also use the input frame format instead of the AVCodecContext one
> according
> > to the documentation of AVCodecContext.get_buffer2().
On Tue, Dec 15, 2015 at 10:00 AM, Michael Niedermayer
wrote:
> On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> > On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > From: Matthieu Bouron
> > >
> > > ---
> > > libavfilter/avfilt
> are these encrypted mp4 files some kind of standard encryption?
>
Yes, these files conform to the common encryption specification ISO/IEC 23001-7
> rephrased... will encrypted files created by ffmpeg be able to be
> decrypted/decoded and played by quicktime? or any other player?
> (assuming oth
>
> using a random IV value would break any regression tests
> see AVFMT_FLAG_BITEXACT
>
Fixed, only generating a random IV when bitexact is not enabled.
Updated patch files attached.
>
> is this filling in a random IV that later is overridden ?
> random_seed() can be slow so it would be better
On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron
> wrote:
>
> > From: Matthieu Bouron
> >
> > ---
> > libavfilter/avfilter.c | 1 +
> > libavfilter/avfilter.h | 5 +
> > libavfilter/video.c| 38
50 matches
Mail list logo
