Based on the past couple days of encoding the one knob I really
really want to tweak is the selecting blurring one - high motion
scenes could do with a bit of selective blurring but only the
encoder knows when that's needed...
Is that something any of the current tools does in any sense
(selective or not)?
> mpeg2enc.cc to allow the amount by which the quantization for
> high-frequency components is increased to be specified on the command
> line. I couldn't seem to get optional arguments to work with getopt,
> so I resorted to adding --hf-boost|-k, which takes integers from
> 0-512, with 384 the default (as in the current code). 0 is the same
Hmmm, the option name is confusing - it sounds as if the HF content
is being boosted (which would increase the bitrate rather quickly
I'd think) rather than the quantization of the HF.
I told you it was a quick hack. Yes, it does imply just the opposite
of what I meant. (You should see some of the code I've been paid to
write!)
Might I suggest "--increase-hf-q" instead? Or something that
has "q" in it at least?
If it makes it into the CVS, then you/Andrew/whoever have my
permission to give it any name you want. :)
I really just wanted to make it an optional argument to --reduce-hf,
but I'll be damned if I could get getopt to see the optional argument.
Either I can't read the getopt documentation properly (most likely) or
there's something funny going on...
If 384 was the default before then perhaps 512 is a bit limiting -
you're already most of the way to the limit. What do your tests
show - any difference between 384 (the default) and 512 ( the new
max)? I wonder what 768 would look like ;)
I'm not sure now why I put a limit on at all. That's not like me.
The only way I can see any difference along the continuum from 0 to
512 is to use a clean source with lots of detail, take screenshots,
and then flip between them on my computer. Very fine detail does
slowly disappear, and the noise jumps about a little. I probably
couldn't see any of it on a tv.
This whole exercise has got me wondering what the "right" way is to
design the quantizer matrix - here we are just multiplying some
default by a ramp with the given slope, but is a linear ramp the right
thing? Should it be quadratic? Logarithmic? With the effect already
so subtle I wouldn't even know how to go about evaluating. So I'll
probably stick to linear.
> This might be useful for those that want some extra bitrate reduction
> but find that the current level results in unacceptable artifacts. I
I gotta get me a new TV then - I haven't seen artifacts, or rather
the ones I do see are the "shades of grey" problem which my feeble
attempt made worse in most cases (as it turns out using the
yuvmedianfilter on the chroma only is almost as good as y4mblackfix
was).
Someone earlier said that they got heavy edge ringing. They might try
using a value of 128 or 256 and see if the ringing is reduced.
Dan
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
