[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