Re: [libav-devel] [PATCH 13/25] intrax8: Use a local buffer instead of a ScratchpadContext
Quoting Vittorio Giovara (2016-02-23 16:25:55)
> On Tue, Feb 23, 2016 at 8:22 AM, Diego Biurrun wrote:
> > On Mon, Feb 22, 2016 at 08:17:37PM -0500, Vittorio Giovara wrote:
> >> Sustain possible size changes via av_fast_malloc().
> >
> > Sustain? That's not the right word, but I'm a tad unsure what you are
> > trying to say here.
>
> If there is a parameter change we might need a bigger buffer, so I
> opted for this function that frees the old pointer and allocates a new
> one.
>
> >> --- a/libavcodec/intrax8.c
> >> +++ b/libavcodec/intrax8.c
> >> @@ -773,6 +773,7 @@ int ff_intrax8_decode_picture(IntraX8Context *const w,
> >> Picture *pict,
> >> {
> >> MpegEncContext *const s = w->s;
> >> int mb_xy;
> >> +int alloc_size = FFALIGN(FFABS(pict->f->linesize[0]) + 32, 32) * 2 *
> >> 24;
> >
> > That's a lot of magic numbers.
>
> indeed, they are the ones used in mpegvideo
That's for the edge emu buffer though, I don't think you need as much
here. It's probably also constant size -- you might only need it to be
block-sized (i.e. 8x8), but you should pester a certain Костя to be
sure.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 13/25] intrax8: Use a local buffer instead of a ScratchpadContext
On Tue, Feb 23, 2016 at 10:25:55AM -0500, Vittorio Giovara wrote:
> On Tue, Feb 23, 2016 at 8:22 AM, Diego Biurrun wrote:
> > On Mon, Feb 22, 2016 at 08:17:37PM -0500, Vittorio Giovara wrote:
> >> Sustain possible size changes via av_fast_malloc().
> >
> > Sustain? That's not the right word, but I'm a tad unsure what you are
> > trying to say here.
>
> If there is a parameter change we might need a bigger buffer, so I
> opted for this function that frees the old pointer and allocates a new
> one.
That's an implementation detail. Better explain the reason for this change.
> >> --- a/libavcodec/intrax8.c
> >> +++ b/libavcodec/intrax8.c
> >> @@ -773,6 +773,7 @@ int ff_intrax8_decode_picture(IntraX8Context *const w,
> >> Picture *pict,
> >> {
> >> MpegEncContext *const s = w->s;
> >> int mb_xy;
> >> +int alloc_size = FFALIGN(FFABS(pict->f->linesize[0]) + 32, 32) * 2 *
> >> 24;
> >
> > That's a lot of magic numbers.
>
> indeed, they are the ones used in mpegvideo
Indeed, it's frigging everywhere, horrid...
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 13/25] intrax8: Use a local buffer instead of a ScratchpadContext
On Tue, Feb 23, 2016 at 8:22 AM, Diego Biurrun wrote:
> On Mon, Feb 22, 2016 at 08:17:37PM -0500, Vittorio Giovara wrote:
>> Sustain possible size changes via av_fast_malloc().
>
> Sustain? That's not the right word, but I'm a tad unsure what you are
> trying to say here.
If there is a parameter change we might need a bigger buffer, so I
opted for this function that frees the old pointer and allocates a new
one.
>> --- a/libavcodec/intrax8.c
>> +++ b/libavcodec/intrax8.c
>> @@ -773,6 +773,7 @@ int ff_intrax8_decode_picture(IntraX8Context *const w,
>> Picture *pict,
>> {
>> MpegEncContext *const s = w->s;
>> int mb_xy;
>> +int alloc_size = FFALIGN(FFABS(pict->f->linesize[0]) + 32, 32) * 2 * 24;
>
> That's a lot of magic numbers.
indeed, they are the ones used in mpegvideo
--
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 13/25] intrax8: Use a local buffer instead of a ScratchpadContext
On Mon, Feb 22, 2016 at 08:17:37PM -0500, Vittorio Giovara wrote:
> Sustain possible size changes via av_fast_malloc().
Sustain? That's not the right word, but I'm a tad unsure what you are
trying to say here.
> --- a/libavcodec/intrax8.c
> +++ b/libavcodec/intrax8.c
> @@ -773,6 +773,7 @@ int ff_intrax8_decode_picture(IntraX8Context *const w,
> Picture *pict,
> {
> MpegEncContext *const s = w->s;
> int mb_xy;
> +int alloc_size = FFALIGN(FFABS(pict->f->linesize[0]) + 32, 32) * 2 * 24;
That's a lot of magic numbers.
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
