Hi Dan,
> I think extent of the ringing artifacts depend on the source images
> being encoded. If the spatial bandwidth of the signal hitting
> mpeg2enc has already been limited (by camera optics, preprocessing,
> etc) then at higher spatial frequencies the spectrum will already roll
> off, and will probably be less effected by --reduce-hf. I should
> probably grab some "busy" screenshots and pull them into matlab to
> estimate what the spatial bandwidth of my camera really is.
--reduce-hf doesn't actually throw away the higher frequency DCT bins.
What it does is simply increase their quantisation (which of course means
more low-amplitude ones get 0-ed).
> Now in general, ringing tends to occur when bandlimiting is done with
> a sharp-transition lowpass filter, as the impulse (time) response of a
> sharp filter rings out for a while. The same thing happens when you
> throw out high-frequency DFT/DCT bins, which I'm assuming is happening
> here (I not familiar enough with mpeg2 encoding in general and
> mpeg2enc in specific to be sure). If so, it might make sense to add
> some control both to which bins are kept, and to how the encoder
> transitions between keeping and not keeping them.
The Problem is you can't be so selective - the decoder assumes a fixed
quantisation matrix for each DCT that you can specify in each picture
coding sequence. However, a well-known trick is to selectively 0
isolated bins (they have a high coding overhead) you think won't reduced SNR
too much.
> Or, perhaps we just need a linear spatial-filtering routine to
> complement yuvdenoise (adaptive temporal filtering) and
> yuvmedianfilter (nonlinear spatial filtering) that allows for a
> programmable spatial frequency reduction (basically, like
> yuvscaler/y4mscaler but without the decimation step). This could be
> done so that edges are a little softened rather than ring. I'm
> assuming that if the input has little content in a bin, then the
> encoder will save bits.
You hit the nail on the head on this one. I build scalers (and hence
pre and reconstruction filters) for my job. Quite apart from my normal
struggle just to halfways find time to properly develop mpeg2enc
this means that I can't easily do this for the project without risking nasty
IP issues.
It should be possible to write a nice generic pair of forward and transposed
FIR (ideally: pixel difference based to eliminate DC ripple) routines for MMX
without too much hassle.
Andrew
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
