On Wed, 3 Dec 2003, Richard Ellis wrote:
> Has anyone noticed mpeg2enc rc92 creating odd "flashing" artifacts on
> what should be otherwise generally smooth color backgrounds? I've
No, can't say I've seen anything like what you describe.
> attached a small jpeg (29k) showing an example of the artifact. If
> you look to the right of the tall actor's shoulder, you can see very
> clearly what I'm talking about, it's a nice herringbone pattern of
> mpeg encoding subblocks (I'm not sure of the official name). When
Technical term - "Colored splotches"? ;)
I did see a number of yellow and light green squares scattered
about - were those in the original source?
> playing this video file, the herringbone pattern fades in slowly,
> then disappears. And this frame is not the only instance, it's just
do the blocks always appear in the same relative position in the
frame?
> The mpeg2enc encoding parameters I used (yes, I know some of these
> are defaults, but...) is my standard entry I've been using for
Not only that - it's a rather eclectic assembly of options ;)
> The only difference between this set of parameters and the set I have
> been using with rc91 is the addition of "-R 0" to obtain only P
Back in October (Oct 5) when dual prime motion estimation (also known
as "-R 0") was first available I encountered a corruption problem with
white splotches during scenes with horizontal motion. After an
exchange with Andrew the problem was pinpointed to gcc 2.95.x
"However, compile it under gcc-2.95 and bingo... yucky blotches galore!"
and later "Dual prime motion estimation mode is broken under gcc-2.95
but, apparently not, under gcc-3.3.1"
A short while later the problem was fixed and I've never seen the
problem since.
> I'll leave a run of rc92 without -R 0 running overnight to see what
> it does when encoding both P & B frames and report the results in the
The first 14 seconds or so should have been done fairly quickly so you
could see the same spot as the .jpg was from.
Or does the appearance of the colored splotches vary from encoding
run to encoding run and/or the options used?
I just finished encoding a 7m12s cartoon that I use for reference
with a couple of the options you gave - specifically I used
"-b 8500 -D 10 -M 2 -R 0 -E -10 -f 8 -H -q 10" (I can see the diff
from the -q 6 or 5 I normally use). Watching carefully I've seen
no blocks/splotches (there are good portions with solid backgrounds,
as well as fast motion scenes).
Next attempt is with "-Q 4.0" (which does seem a bit high - the range
is only up to 5) - that's an option that has the possibility of
artifacting (hmmm, can't recall if that's in the documentation or not).
Hmmm, that didn't seem to elicit any blocks/splotches that I could see.
Adding -X 200. Nope, that didn't do anything either. BUT I did notice
that -X (--quant-reduction-max-var) is not mentioned in mpeg2enc's
help/usage output. I'll be checking a fix for that in shortly.
I didn't think there were major changes between rc1 and rc2 - mostly
typo fixups, option parsing/usage, documentation, and so on.
Has anything (compiler, etc) changed recently on your system that might
enter into the equation?
You can set the number of B frames to just 1 ("-R 1") - that will
get out of the dual prime motion estimation mode just as well as
"-R 2" (the default of no -R is given) and still gain some of the
benefits.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
