Hi Richard,
I finally got the y4m from Steven and I now know what's going. Actually, I
should have been able to tell you very soon just by looking at the command
line but ... that's life. Anyway I've Cc: Bernhard as 'honorary question
answerer and Doku whipper-in' in case something like this comes up for
others.
On Thursday 04 December 2003 04:57, Richard Ellis wrote:
> Has anyone noticed mpeg2enc rc92 creating odd "flashing" artifacts on
> what should be otherwise generally smooth color backgrounds? I've
> attached a small jpeg (29k) showing an example of the artifact.
> ...
> -f 5 -n n -a 2 -V 230 -B 224 -S 8000 -b 9576 -q 10 -I 1 -G 54 -H
-------------------------------------------------------------------------^
> -N 0.0 -X 200 -Q 4.0 -R 0 -d -4 4 -2 4
Beep.... error spotted.
The coloured splotches you are seeing are 'DCT mismatch' artefacts! What is
happening is that there are very slight rounding differences between the iDCT
and dequantisation routines in the encoder and the decoder. For P frames
these differences steadily accumulate in the decoder as each P frame encoding
assumes the results of the previous P frame *decoding*.
Normally, these:
- Simply don't occur (not such a 'heavy' -Q really putting extreme values in,
more textured less near-maximum brightness areas)
- Are invisible because in sensible-length GOPs a I frame comes along
where an image is encoded 'from scratch' with zero accumulated differences
- Are invisible because B frames mean far fewer P frames occur between I
frames reducing the accumulate difference.
However, with your setup you inadvertently created a worst-case scenario for
mismatch artefacts: loooooong GOPs, extreme quantisation matrices, and a very
bright slightly noisy (video capture) smooth image area!
The real solution is to simply avoid excessively long GOPs. The compression
gains beyond the 'normal' GOP lengths are pretty minimal and you can see the
potential disadvantages!
Andrew
PS
You may be wondering why MPEG-4 / DivX encoders can use mega-long GOPs. Easy:
MPEG-4 rigidly defines the numeric behaviour of DCT/quantisation algorithms.
They have to be bit-exact matches to the Spec so the mismatch problem doesn't
occur (or at least not to such an extent).
PPS
The DCT/iDCT routines in mpeg2enc are 'o.k' but not hugely accurate: some nice
high-precision SSE based ones are something I'd like to code up but other
jobs currently have higher priority.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
