[Ffmpeg-devel] snow MC simplification

Guillaume Poirier docmaintainerwannabe
Tue Jan 17 14:17:14 CET 2006

Michael Niedermayer wrote:
> Hi
> On Mon, Jan 16, 2006 at 03:32:08PM -0800, Loren Merritt wrote:
>>On Mon, 16 Jan 2006, Guillaume POIRIER wrote:
>>>On 1/8/06, Michael Niedermayer <michaelni at gmx.at> wrote:
>>>>Snow currently uses the h.264 luma MC functions if possible and if not
>>>>(1/8 pel) then its own MC functions (mc_block())
>>>>the result is that mc_block() is only used for some chroma blocks if qpel 
>>>>enabled, so it would be nice if we could et rid of it, the attached patch
>>>>does that, but it needs testing (encode stuff with and without and view 
>>>>the respective player with and without the patch)
>>>>if anyone has other ideas on how this can be simplified then dont hesitate
>>>>to reply ...
>>>I don't know if that was intended, but that patch fixed a chroma bug,
>>>as you may notice it on those 2 screenshots:
>>>vanilla version:
>>>snow_MC_simplification patched version:
>>>So either a recent commit broke snow, or just just fixed a
>>>longstanding bug... Anyway, that's good stuff!
>>I see such artifacts when mixing an encode with the patch and mplayer 
>>without it, or vice versa.
>>My results:
>>patch adds an average of +.7% bitrate, -.08 dB chroma
>>decoding speed +24% (athlon-xp)
>>no visible difference
> if noone can see a difference then iam in favor of the simpler chroma MC code
> after all humans watch videos not PSNR evaluating computers ...

Well said :)

A bit more precision about the drift to pink problem I experienced: each
new picture drifts more and more towards pink, until probably a keyframe
makes the color look normal once again.

Would it help if I were uploading the 300 frames sample I encoded?
I don't remember how big it was though...


More information about the ffmpeg-devel mailing list