On Wed, Dec 03, 2003 at 09:39:18PM -0800, Steven M. Schultz wrote:
>
> On Wed, 3 Dec 2003, Richard Ellis wrote:
>
> > 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?
Those are the artifacts, and no, they are not in the original source
as far as I can see by playing the .avi with glav. The original
source from the DC10+ card looks just as I would expect it to look,
nice and clean.
> > 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?
If I play the file multiple times, yes, the blocks always appear in
the exact same locations.
> > 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.
Ok, that may pinpoint a source then. Mpeg2enc was compiled under
2.95.3. Except that the encoder is rerunning the test, and without
any -R parameter the splotches are still in the new encoded output
file, and look to be located in the same places as on the test jpeg.
They are, however, less intense (not as dark/noticeable) than on the
encoding with -R 0.
> > 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.
Other jobs queued ahead of it, and I wanted to get to bed anyway. :)
> Or does the appearance of the colored splotches vary from encoding
> run to encoding run and/or the options used?
Same location in the image, but less intense (less dark) in the run
without "-R 0".
> I didn't think there were major changes between rc1 and rc2 -
> mostly typo fixups, option parsing/usage, documentation, and so on.
There was at least one pretty major change, rc1 had no option for P
frame only, rc2 added 0/1/2 B frames between P frames.
> Has anything (compiler, etc) changed recently on your system that might
> enter into the equation?
It was compiled with gcc 2.95.3, which might be the trouble after you
said above that you had found some weirdness with 2.95.3 after the
change to adjustable B frames.
> 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.
Dropping -R, and letting it use 2 B's per P like rc91 only made the
splotches less intense, but they are still there. If you want, I can
lavtrans out the first 30 or 60 seconds of the capture and set it up
so you could download (dsl here) it to try yourself and see if it's
some weird pattern in the input causing the effect.
-------------------------------------------------------
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
