[mythtv] [PATCH] libpostprocess

[Kenneth Aafløy]

On Tue, 2003-10-28 at 22:36, Isaac Richards wrote:
> 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?

Doing a little more work to make the program do a little less work,
but I'll stop naging about this topic now.

Kenneth