This exploits an approach based on the sieve of Eratosthenes, a popular
method for generating prime numbers.
Tables are identical to previous ones.
Tested with FATE. Does not work yet with --enable-hardcoded-tables due
to the union and lack of proper WRITE_ARRAY for it. Want to get feedback
on th
On 12/31/2015 10:11 PM, compn wrote:
> On Thu, 31 Dec 2015 22:07:56 +0100
> Michael Niedermayer wrote:
>
>> On Thu, Dec 31, 2015 at 10:35:47PM +0500, ha...@mayartech.com wrote:
>>> From: Bryan Christ
>>>--enable-libx264 enable H.264 encoding via x264 [no]
>>> + --enable-libi264
On 01/01/2016 03:27 AM, Kieran Kunhya wrote:
On 1 January 2016 at 02:22, Mats Peterson
wrote:
Even though the 1-bit mode in the QuickTime Animation decoder (qtrle) is
rather broken, it should use pal8 and not monow, since it's a palettized
mode. So I suggest that we apply the decoder patch (and
On 1 January 2016 at 02:22, Mats Peterson
wrote:
> Even though the 1-bit mode in the QuickTime Animation decoder (qtrle) is
> rather broken, it should use pal8 and not monow, since it's a palettized
> mode. So I suggest that we apply the decoder patch (and the accompanying
> "bug fix" patch of qtp
From: Michael Niedermayer
This causes a overall slowdown of 0.1 % (tested with mpeg4 single thread
encoding of matrixbench at QP=3)
Signed-off-by: Michael Niedermayer
---
libavcodec/put_bits.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/p
Even though the 1-bit mode in the QuickTime Animation decoder (qtrle) is
rather broken, it should use pal8 and not monow, since it's a palettized
mode. So I suggest that we apply the decoder patch (and the accompanying
"bug fix" patch of qtpalette.c that ignores the greyscale bit for 1-bit
vide
On Tue, 29 Dec 2015 10:45:25 -0900, Lou Logan wrote:
> Signed-off-by: Lou Logan
> ---
> doc/filters.texi | 8
> 1 file changed, 8 insertions(+)
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/f
On Thu, Dec 31, 2015 at 5:08 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 31, 2015 at 6:53 PM, Ganesh Ajjanagadde
> wrote:
>>
>> BTW, it would also help me if you or an AAC maintainer can come up
>> with a number below which dynamic initialization can always be done.
>
>
> I think the answer
On Thu, 31 Dec 2015 22:07:56 +0100
Michael Niedermayer wrote:
> On Thu, Dec 31, 2015 at 10:35:47PM +0500, ha...@mayartech.com wrote:
> > From: Bryan Christ
> >--enable-libx264 enable H.264 encoding via x264 [no]
> > + --enable-libi264 enable H.264 encoding via Intel's libva
Hi,
On Thu, Dec 31, 2015 at 6:53 PM, Ganesh Ajjanagadde
wrote:
> BTW, it would also help me if you or an AAC maintainer can come up
> with a number below which dynamic initialization can always be done.
I think the answer is "never", since 0 is always faster than any number.
But that's not an
On Thu, Dec 31, 2015 at 3:53 PM, Ganesh Ajjanagadde
wrote:
> On Thu, Dec 31, 2015 at 8:46 AM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, Dec 31, 2015 at 11:39 AM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> This patch does not seem to have measurable impact, at least on x86-64,
>>> though
>>> there c
On Thu, Dec 31, 2015 at 8:46 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 31, 2015 at 11:39 AM, Ganesh Ajjanagadde
> wrote:
>>
>> This patch does not seem to have measurable impact, at least on x86-64,
>> though
>> there could be benefits for less than stellar branch predictors.
>
> [..]
>>
On Thu, Dec 31, 2015 at 10:35:47PM +0500, ha...@mayartech.com wrote:
> From: Bryan Christ
>
> This commit adds a hardware accelerated H.264 encoder which utilizes
> libVA (open source implementation of VA-API). Information about libva
> is available at: https://en.wikipedia.org/wiki/Video_Acceler
From: Bryan Christ
This commit adds a hardware accelerated H.264 encoder which utilizes
libVA (open source implementation of VA-API). Information about libva
is available at: https://en.wikipedia.org/wiki/Video_Acceleration_API
This encoder is only availbale on linux and supported hardware which
On Thu, Dec 31, 2015 at 11:41:22AM -0500, Dave Rice wrote:
> Hi all,
>
> I’m reviewing the FFV1 Draft Specification [1] and commenting here
> specifically upon the General Description section and have some questions to
> clarify the meaning of this section. I’m cross-posting to ffmpeg-devel thou
if the patch is fixing incorrect code then it should be commited
if it doesnt then it should not
And to answer that, yes, it fixes incorrect code.
If it was OK to apply the previous lavf/qtpalette patch for 1-bit
palettized video, it should be OK to apply this bug fix without any
superfluo
On 12/31/2015 06:24 PM, Michael Niedermayer wrote:
if the patch is fixing incorrect code then it should be commited
if it doesnt then it should not
And to answer that, yes, it fixes incorrect code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
On 12/31/2015 06:53 PM, Mats Peterson wrote:
On 12/31/2015 06:24 PM, Michael Niedermayer wrote:
do you prefer that the decoder patch is pushed first?
or do i misunderstand?
but i can surely push that first if thats preferred
It's a small one-liner, as you can see, that ignores the greyscale
On 12/31/2015 06:24 PM, Michael Niedermayer wrote:
do you prefer that the decoder patch is pushed first?
or do i misunderstand?
but i can surely push that first if thats preferred
It's a small one-liner, as you can see, that ignores the greyscale bit
for 1-bit video. This should be done rega
On Thu, Dec 31, 2015 at 03:59:53PM +, Carl Eugen Hoyos wrote:
> Mats Peterson ffmpeg.org> writes:
>
> > And this patch doesn't affect the current state of
> > the qtrle decoder
>
> Then there is no need for this patch to be
> committed yet.
if the patch is fixing incorrect code then it sh
On Thu, Dec 31, 2015 at 8:46 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 31, 2015 at 11:39 AM, Ganesh Ajjanagadde
> wrote:
>>
>> This patch does not seem to have measurable impact, at least on x86-64,
>> though
>> there could be benefits for less than stellar branch predictors.
>
> [..]
>>
On 12/31/2015 05:04 PM, Mats Peterson wrote:
>
Alright, Michael, do whatever you want, but it's awkward to have this
patch lying around for no reason, when it's such a small change.
Mats
Let me repeat a snippet from the QuickTime File Format Specification:
"Depth: A 16-bit integer that indic
Dave Rice dericed.com> writes:
> Re: "Each frame is split in 1 to 4 planes". I'd like to be
> more specific. From this reading it seems like 2 planes is
> possible; however, are 2 plane encodings possible
> (grayscale with alpha or Y with only Cb)?
GRAY8A and GRAY16A are possible, both have t
Hi,
On Thu, Dec 31, 2015 at 11:39 AM, Ganesh Ajjanagadde wrote:
> This patch does not seem to have measurable impact, at least on x86-64,
> though
> there could be benefits for less than stellar branch predictors.
>
[..]
> -for (i = 0; i < 1<<13; i++) {
> -if (!(i & 7))
> -
Hi all,
I’m reviewing the FFV1 Draft Specification [1] and commenting here specifically
upon the General Description section and have some questions to clarify the
meaning of this section. I’m cross-posting to ffmpeg-devel though responses are
welcomed on either list though encouraged on the IE
This is used to prepare for optimizations of the table generation, which
is inherently done as floating point computation of i * cbrt[i].
Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/aacdec_fixed.c| 4 ++--
libavcodec/aacdec_template.c | 2 +-
libavcodec/cbrt_tablege
This exploits a very simple property of the cbrt function, obtaining a
non-negligible speed-up. Tables turn out to be identical on
GNU/Linux+gcc.
Sample benchmark (Haswell, GNU/Linux+gcc):
new:
6632898 decicycles in cbrt_tableinit, 256 runs, 0 skips
6623909 decicycles in cbrt_tableinit,
This patch does not seem to have measurable impact, at least on x86-64, though
there could be benefits for less than stellar branch predictors.
As such, the least useful of the series.
Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/cbrt_tablegen.h | 14 +-
1 fil
On 31.12.2015 17:24, Michael Niedermayer wrote:
> On Thu, Dec 31, 2015 at 05:02:14PM +0100, Andreas Cadhalpun wrote:
>> On 30.12.2015 21:12, Andreas Cadhalpun wrote:
>>> It is read up to length s->width * stride, which can be larger than the
>>> linesize. (stride = (s->nb_components > 1) ? 3 : 1)
>
On Thu, Dec 31, 2015 at 05:02:14PM +0100, Andreas Cadhalpun wrote:
> On 30.12.2015 21:12, Andreas Cadhalpun wrote:
> > It is read up to length s->width * stride, which can be larger than the
> > linesize. (stride = (s->nb_components > 1) ? 3 : 1)
> >
> > This fixes an out of bounds read.
> >
> >
On 12/31/2015 05:00 PM, Mats Peterson wrote:
I would gladly get rid of this one-liner in the meantime. It's "my" file
at that.
Mats
Alright, Michael, do whatever you want, but it's awkward to have this
patch lying around for no reason, when it's such a small change.
Mats
On 30.12.2015 21:12, Andreas Cadhalpun wrote:
> It is read up to length s->width * stride, which can be larger than the
> linesize. (stride = (s->nb_components > 1) ? 3 : 1)
>
> This fixes an out of bounds read.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/jpeglsdec.c | 2 +-
> 1 fil
On 12/31/2015 04:59 PM, Carl Eugen Hoyos wrote:
Mats Peterson ffmpeg.org> writes:
And this patch doesn't affect the current state of
the qtrle decoder
Then there is no need for this patch to be
committed yet.
Carl Eugen
___
ffmpeg-devel mailing l
Mats Peterson ffmpeg.org> writes:
> And this patch doesn't affect the current state of
> the qtrle decoder
Then there is no need for this patch to be
committed yet.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/
On 12/31/2015 04:54 PM, Michael Niedermayer wrote:
On Thu, Dec 31, 2015 at 04:47:20PM +0100, Mats Peterson wrote:
On 12/30/2015 07:56 PM, Mats Peterson wrote:
On 12/30/2015 07:52 PM, Mats Peterson wrote:
Michael, can you apply this one in the meantime, just to get rid of it,
and if it seems se
On Thu, Dec 31, 2015 at 04:47:20PM +0100, Mats Peterson wrote:
> On 12/30/2015 07:56 PM, Mats Peterson wrote:
> >On 12/30/2015 07:52 PM, Mats Peterson wrote:
> >>Michael, can you apply this one in the meantime, just to get rid of it,
> >>and if it seems sensible, until someone discovers how to solv
On 12/30/2015 07:56 PM, Mats Peterson wrote:
On 12/30/2015 07:52 PM, Mats Peterson wrote:
Michael, can you apply this one in the meantime, just to get rid of it,
and if it seems sensible, until someone discovers how to solve the 1-bit
palettized qtrle issue?
In the decoder, that is.
Mats
On Wed, Dec 30, 2015 at 09:53:35PM +, Eran Kornblau wrote:
> > > Please let me know if you think that is ok, and I will resubmit the patch
> > > with all fixes.
> >
> > should be ok
> >
> Updated patch attached, diff from previous patch is:
>
> --- a/libavformat/mov.c
> +++ b/libavformat/mo
Hi,
> this patchset fixes most if not all bugs reported to trac for me.
> [...]
sorry I forgot to mention that this patchset has already become obsolete
for the joint approach to push a common base for avfoundation into
FFmpeg & Libav.
I'm very short of time right now but I will update this & th
On 2015-12-31 07:02, Kieran Kunhya wrote:
>> Apart from that, again from a quick glance, there are a ton of
>> mallocs/frees. Can these somehow get consolidated?
>
> Yes, that's what I don't know how to solve easily. They should of
> course be a single allocated buffer that's reused.
Forgive me i
On 12/31/2015 12:28 PM, Nicolas George wrote:
Le primidi 11 nivôse, an CCXXIV, Mats Peterson a écrit :
Just to let you know, I can do what the I want with the code while
experimenting.
Not exactly, no. If you look at another project, even while experimenting,
then the final code can be sa
Le primidi 11 nivôse, an CCXXIV, Mats Peterson a écrit :
> Just to let you know, I can do what the I want with the code while
> experimenting.
Not exactly, no. If you look at another project, even while experimenting,
then the final code can be said to be inspired by it, and for some people
t
On 12/31/2015 11:19 AM, Carl Eugen Hoyos wrote:
I have tried to mess with it a bit, borrowing code from XAnim,
Please stop this now and please be more careful!
Just to let you know, I can do what the I want with the code while
experimenting. Thank you for your supportive input, and a Ha
On 12/31/2015 11:19 AM, Carl Eugen Hoyos wrote:
Mats Peterson ffmpeg.org> writes:
I have tried to mess with it a bit, borrowing code from XAnim,
Please stop this now and please be more careful!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-deve
Mats Peterson ffmpeg.org> writes:
> I have tried to mess with it a bit, borrowing code from XAnim,
Please stop this now and please be more careful!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ff
I've looked at the XAnim source regarding the decoding of QuickTime
Animation (qtrle in FFmpeg) (he calls the RLE codec "Graphics" but
that's wrong). Anyway, it uses a lot of opcodes and stuff that aren't
implemented whatsoever in libavcodec/qtrle.c. So far it has managed to
work in spite of th
46 matches
Mail list logo
