[mythtv] [Draft] Filter documentation.

D Banerjee davatar at comcast.net
Thu Jan 29 22:15:49 EST 2004


From: "Andrew Mahone" <andrewmahone at eml.cc>
>On Fri, 30 Jan 2004 03:00:51 +0100, "Kenneth Aafløy" <ke-
.aa at frisurf.no> said:
>> And it will (if i'm not mistaken) lighten the load on the filter (?).
>>
>> Anyways, I'm kinda lost in the avcodec anyways, so..
>>
>> Kenneth

>I'm not sure, libavcodec and mplayer are both pretty hard for me to
>follow, and it all depends on how the filter works.  If more smoothing is
>achieved by multiple passes through a filter, this would make things
>slower with worse input.  I would hope that it's done in a more sensible
>way, with stronger filters implemented by changing a value in the
>algorithm, rather than using an iterative method.

>I have no idea why copying the qscale data into the frame structure
>and reading it later would make a difference.  It should be a fairly
>minor CPU hit, and as long as each frame comes associated with correct
>qscale data, it shouldn't matter how "far" from the decoder the filter
>is applied.

Me three, I've given libavcodec a once over a few times over the past few
months, and always put it away for later ;)

I agree that the distance from the decoder should have nothing to do with
it's function. As long as we have a frame, with it's associated qscale data,
we're ready to process.

I was actually planning on porting the Xvid deblockers/deringers someday.
They seem to do a very good job, and to me at least, are a known quantity.



More information about the mythtv-dev mailing list