On Sun, 8 Feb 2004, Ray Cole wrote:
> mplayer and 2 standalone players. I haven't been able to reproduce it with other
> material. The part of the scene giving the problem was a wall. The wall was
> textured, had a lot of yellowish color to it (gee, I'm sure I'm being real
> descriptive here :-) There were random rectangular blocks popping out as a much
> brighter yellow than the other colors in the wall. The scene itself has virtually
> no movement. The blocks would build to be extremely noticeable then 'disappear',
> then build back about...the cycle was about 1/2 a second, which given a GOP of 18
> probably means it was disappearing on the I frames then progessively getting worse
> with the stack of P frames.
Line breaks? ;)
> I wasn't near maximum bitrate during the scene. It really is like there
> was some sort of rounding or floating point error getting progressively
> worse with each P frame that went away with the B frames.
Sounds like inaccuracies creeping in during the DCT. That's similar
to what I see on SSE vs non-SSE systems. The non-SSE (which uses a
pure MMX implementation) encodings always had a lower bitrate than
the SSE (or Altivec) encodings and the difference became larger as
-q was decreased.
> Now...and this may make a big difference...since that recording I upgraded
> processors from an Athlon 1600 to an Ahtlon 2600 and rebuilt mpeg2enc.
> The Athlon 2600 has mmxext, whereas the Athlon 1600 does not and I noticed
> mpeg2enc reports it is using mmx extended on my 2600 whereas it couldn't
> use it on my 1600... That may well be the reason I can't reproduce it now.
Ah, your new cpu has the "Barton" core (in addition to larger L2 cache
there were new instructions as well). That could VERY well be
the difference.
Andrew Stevens has mentioned one of the things on his TODO list is a
new (and more accurate) set of routines using floating point and/or
the vectorizing capabilities of the newer GCC compilers. Going to
floating point would improve the accuracy and prevent some (all?) of
the problems that have plagued the MMX routines.
> I realize a sample would be worth 1GB words...but unless I pop the old
> processor back in place (which I hate doing because the CPU fan is so
And slower too :)
> I don't think I'm going to be able to reproduce it.
At this point I wouldn't worry about it - I think the problem's been
identified and rewriting the MMX code isn't something that would be
easy (or fun ;)).
Cheers,
Steven Schultz
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
