[mythtv] [PATCH] libpostprocess

[Isaac Richards]

On Tuesday 28 October 2003 04:18 pm, Kenneth Aafløy wrote:
> On Tue, 2003-10-28 at 20:47, Isaac Richards wrote:
> > On Tuesday 28 October 2003 04:20 am, Kenneth Aafløy wrote:
> > > On Tue, 2003-10-28 at 06:51, Isaac Richards wrote:
> > > > Or, just make that data available from the VideoFrame struct.  Think
> > > > minimal change, not changing everything around unnecessarily for a
> > > > minor feature.
> > >
> > > I was thinking of this too, but as far as I can see this would then
> > > imply per-frame copy of that table, because frames are filtered to long
> > > after they are decoded. I'm unsure of the exact size of the table, but
> > > (width+15)/16 seems to be a common allocation for it. So the question
> > > really is wheter it's justifiable to to keep track of those tables on a
> > > per frame basis or just move the filter closer to where it's generated.
> >
> > I don't think copying 120 extra bytes of data per frame at maximal HDTV
> > resolutions is going to affect anything at all.  The filtering isn't
> > going to move anywhere.
>
> I didn't look hard enough the first time (from libavcodec/mpegvideo.c):
>
> s->mb_width  = (s->width  + 15) / 16;
> s->mb_height = (s->height + 15) / 16;
> s->mb_stride = s->mb_width + 1;
> mb_array_size= s->mb_height * s->mb_stride;
> CHECKED_ALLOCZ(pic->qscale_table , mb_array_size * sizeof(uint8_t))
>
> Still to small?

Of course.  8kb of data at full hdtv resolutions is completely insignificant 
compared to the size of the video frame (ie, over 3 MB).  Why is this even an 
issue?

Isaac