> -sample_rate = ldexp(val, exp - 16383 - 63);
> +if (exp >= 0)
> +sample_rate = val << exp;
> +else
> +sample_rate = (val + (1<<(-exp/2))) >> -exp;
To round the value it should probably be something like:
sample_rate = (val + ((uint64_t)1<<(-exp-1))) >> -exp;
To a
> -Original Message-
> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> boun...@ffmpeg.org] On Behalf Of James Almer
> Sent: Thursday, May 28, 2015 10:06 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL heade
On Fri, May 22, 2015 at 10:07:17PM -0600, ill wrote:
> So can the ffserver patch be committed?
>
>
>
>
> ffserver.c |4
> ffserver_config.c|6 --
> ffserver_config.h|1 +
> libavformat/allformats.c |1 +
> libavformat/rawenc.c | 12
>
>
> > I've recently got a couple of appropriate samples from the PPSSPP
> emulator
> > project so I coud test this feature extensively.
>
> where can i find these samples ?
> are they online somewhere? can you upload them ?
>
I've just uploaded a folder named "atrac3p GHA phase inversion" to
upl
On Mon, Jun 08, 2015 at 02:17:16AM +0200, Max Pole wrote:
> Hello crews,
>
> I attached two simple patches reenabling a decoder feature been initially
> disabled due to lack of real-world samples.
>
> I've recently got a couple of appropriate samples from the PPSSPP emulator
> project so I coud
Hello crews,
I attached two simple patches reenabling a decoder feature been initially
disabled due to lack of real-world samples.
I've recently got a couple of appropriate samples from the PPSSPP emulator
project so I coud test this feature extensively.
The 2nd patch is a cosmetical one that re
There is no support for non integer sample rates, using doubles/floats
currently could
only lead to rounding differences between platforms
Signed-off-by: Michael Niedermayer
---
libavformat/aiffdec.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavformat/aif
Hi,
On Sun, Jun 7, 2015 at 4:39 PM, Michael Niedermayer
wrote:
> On Sun, Jun 07, 2015 at 04:27:42PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Jun 7, 2015 at 2:35 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> > > Hi Ronald,
> > >
> > > On 07.06.2015 19:37
On Sun, Jun 07, 2015 at 04:27:42PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jun 7, 2015 at 2:35 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
> > Hi Ronald,
> >
> > On 07.06.2015 19:37, Ronald S. Bultje wrote:
> > > On Sun, Jun 7, 2015 at 12:44 PM, Andreas Cadhalpun
Hi,
On Sun, Jun 7, 2015 at 1:02 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Otherwise the check 'tile_size < size' treats a negative size as
> unsigned, causing the check to pass. This subsequently leads to
> segmentation faults.
>
> This was originally fixed as part of Lib
Hi,
On Sun, Jun 7, 2015 at 2:35 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Hi Ronald,
>
> On 07.06.2015 19:37, Ronald S. Bultje wrote:
> > On Sun, Jun 7, 2015 at 12:44 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >> On 07.06.2015 17:52, Ronald S.
On 07/06/15 19:02, Andreas Cadhalpun wrote:
> Otherwise the check 'tile_size < size' treats a negative size as
> unsigned, causing the check to pass. This subsequently leads to
> segmentation faults.
>
> This was originally fixed as part of Libav commit 72ca83, so the
> original author is one of t
Hi Ronald,
On 07.06.2015 19:37, Ronald S. Bultje wrote:
> On Sun, Jun 7, 2015 at 12:44 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>> On 07.06.2015 17:52, Ronald S. Bultje wrote:
>>> We can't simply claim that 8k is not a valid dimension, that would make us
>>> a vp8-incompa
Fixed so threading isn't removed completely.
Sorry this took so long. Took too long to figure out that decode_ihdr_chunk()
was being called in each thread and thus overwriting the cur_w/h value set by
update_thread_context().
("Remove threading support" patch can be ignored now)
_
The spec specifies the dispose operation as how the current (i.e., currently
being rendered) frame should be disposed when the next frame is blended onto it
This is contrary to ffmpeg's current behaviour of interpreting the dispose
operation as how the previous (i.e., already rendered) frame shoul
Hi,
On Sun, Jun 7, 2015 at 12:44 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Hi Ronald,
>
> On 07.06.2015 17:52, Ronald S. Bultje wrote:
> > On Sun, Jun 7, 2015 at 10:05 AM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >> +#define MARGIN (16 << 2)
Otherwise the check 'tile_size < size' treats a negative size as
unsigned, causing the check to pass. This subsequently leads to
segmentation faults.
This was originally fixed as part of Libav commit 72ca83, so the
original author is one of the following developers:
Anton Khirnov
On 07.06.2015 17:38, Michael Niedermayer wrote:
> On Sun, Jun 07, 2015 at 04:05:37PM +0200, Andreas Cadhalpun wrote:
>> If the dimensions are too large, s->mb_width or s->mb_height can become
>> too large, leading to an int16_t overflow of s->mv_max.{x,y}.
>>
>> Signed-off-by: Andreas Cadhalpun
>>
Hi Ronald,
On 07.06.2015 17:52, Ronald S. Bultje wrote:
> On Sun, Jun 7, 2015 at 10:05 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> +#define MARGIN (16 << 2)
>> +#define MAX_MB_SIZE (((INT16_MAX - MARGIN) >> 6) + 1)
>>
>
> So this is roughly 9 bits.
>
>
>> +if (s
Helmut K. C. Tessarek evermeet.cx> writes:
> To honor the beautiful mind who made game theory a
> whole different area, what about:
>
> John F. Nash
+1
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listi
Hi,
On Sun, Jun 7, 2015 at 10:05 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> +#define MARGIN (16 << 2)
> +#define MAX_MB_SIZE (((INT16_MAX - MARGIN) >> 6) + 1)
>
So this is roughly 9 bits.
> +if (s->avctx->coded_width > MAX_MB_SIZE * 16 ||
> +s->avctx->coded
On Sun, Jun 07, 2015 at 04:05:37PM +0200, Andreas Cadhalpun wrote:
> If the dimensions are too large, s->mb_width or s->mb_height can become
> too large, leading to an int16_t overflow of s->mv_max.{x,y}.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/vp8.c | 10 +-
> 1 file cha
If the dimensions are too large, s->mb_width or s->mb_height can become
too large, leading to an int16_t overflow of s->mv_max.{x,y}.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/vp8.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp8.c b/libavcodec/
On Sat, Jun 06, 2015 at 10:59:30PM -0300, Reynaldo H. Verdejo Pinochet wrote:
> Hi
>
> On 06/06/2015 10:43 AM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > ffserver.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > [..]
>
> Looks good.
24 matches
Mail list logo
