Re: [Mjpeg-users] 1.6.1.93: Bad quality
Hi all, It looks like there is, someplace, a mismatch problem lurking in the Arithmetic routines. Basically, different rounding between the (internal) decoding done in mpeg2enc for calculating the difference between the image to encode and the decoding of its predecessor and what is happening in the MPEG decoders. I really really need a short sequence the shows the Problem because otherwise it is almost impossible to track down precisely. Andrew --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] 1.6.1.93: Bad quality
HI! Richard Ellis wrote: What type of system (cpu) is being used? SSE, MMX, MMX-Extended, ??? P3-866. Don't know exactly, what type of extra instructions this one has. P3 class has MMX, maybe MMX-extended, and the initial implementation of SSE. If you watch the mpeg2enc startup messages, it should tell you what accelerations it's picking to use (of those that were compiled into it) I am using transcode -> fifo -> cat | y4mscaler | mjpegtools. mjpegtools does not say anything, but transcode says "sse (sse mmxext mmx asm)". Thomas --- 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
Re: [Mjpeg-users] 1.6.1.93: Bad quality
On Tue, Feb 10, 2004 at 08:03:23AM +0100, Thomas B?rkel wrote: > HI! > > Steven M. Schultz wrote: > > > What type of system (cpu) is being used? SSE, MMX, > > MMX-Extended, ??? > > P3-866. Don't know exactly, what type of extra instructions this > one has. P3 class has MMX, maybe MMX-extended, and the initial implementation of SSE. If you watch the mpeg2enc startup messages, it should tell you what accelerations it's picking to use (of those that were compiled into it) > This is what I see: At -q 4, everything is OK. With -q 3 or better, > I get pulsating (every second or so) blocking (very small blocks, > mosaic-like effect) in the background. If I don't use -R 2, some of > those small blocks get really big and hatched, like it can be seen > in the q3 example. Those examples were made without -R 2. That sounds very much like the integer roundoff problem that I saw on one encode a little while back that was an interaction between -R0 and -G54. You can look back in the archives for the messages. It was sometime around the Nov/Dec 2003 timeframe. The patches/splotches were hatched in my situation as well. Andrew indicated that it was accumulating integer roundoff errors from all P frames and a very long GOP size. It sounds like it's possible to push the encoder into the same roundoff problems with too high of a -q value as well. --- 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
Re: [Mjpeg-users] 1.6.1.93: Bad quality
HI! Steven M. Schultz wrote: As I wrote in another thread: I have a still example, I think, for that problem: http://www.boerkel.de/q.zip Initially, to me, that just looks like a variation on the grey blocks/splotches that always seem appear during dark scenes. I wonder if a bit of medianfiltering, perhaps on the chroma only, would reduce the visibility of the discoloration. I tried some filtering with no success. Problem is in the upper left corner. Most noticable in the q3 picture. What type of system (cpu) is being used? SSE, MMX, MMX-Extended, ??? P3-866. Don't know exactly, what type of extra instructions this one has. If the problem disappears at higher -q values (or does not happen with all source material) then my theory is that there is an overflow condition in the internal arithmetic caused by specifying too low of a -q value. This is what I see: At -q 4, everything is OK. With -q 3 or better, I get pulsating (every second or so) blocking (very small blocks, mosaic-like effect) in the background. If I don't use -R 2, some of those small blocks get really big and hatched, like it can be seen in the q3 example. Those examples were made without -R 2. Of course that is making the assumption it's the same problem. Then too it is possible it is similar but not the same thing. I can't tell. Thomas --- 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
Re: [Mjpeg-users] 1.6.1.93: Bad quality
On Mon, 9 Feb 2004, [ISO-8859-1] Thomas Börkel wrote: > As I wrote in another thread: I have a still example, I think, for that > problem: http://www.boerkel.de/q.zip Initially, to me, that just looks like a variation on the grey blocks/splotches that always seem appear during dark scenes. I wonder if a bit of medianfiltering, perhaps on the chroma only, would reduce the visibility of the discoloration. > Problem is in the upper left corner. Most noticable in the q3 picture. What type of system (cpu) is being used? SSE, MMX, MMX-Extended, ??? If the problem disappears at higher -q values (or does not happen with all source material) then my theory is that there is an overflow condition in the internal arithmetic caused by specifying too low of a -q value. Of course that is making the assumption it's the same problem. Then too it is possible it is similar but not the same thing. Steven Schult --- 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
Re: [Mjpeg-users] 1.6.1.93: Bad quality
HI! Ray Cole wrote: 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 darn difficult to get off/on...I hate the clip on it...) I don't think I'm going to be able to reproduce it. As I wrote in another thread: I have a still example, I think, for that problem: http://www.boerkel.de/q.zip Problem is in the upper left corner. Most noticable in the q3 picture. Thomas --- 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
Re: [Mjpeg-users] 1.6.1.93: Bad quality
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
Re: [Mjpeg-users] 1.6.1.93: Bad quality
> > mpeg2enc -f 8 -q 5 -a 2 -g 6 -G 18 -E -10 -N 1.0 -z t -4 2 -2 2 -r 16 -o file.m2v > > > > Is it possible to have less that 200+ character lines? ;) It used to be longer :-) > What are you using to do the playback? Ogle? Xine? MPlayer? > Standalone player? 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. 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. 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. One of the two standalone DVD players made it look a lot worse than my normal DVD player and mplayer. Actually it was the TV on it - the contrast was turned up way too high on it. But it was still noticeable on the other DVD player and on mplayer, and did go away using -R 2. 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 darn difficult to get off/on...I hate the clip on it...) I don't think I'm going to be able to reproduce it. -- Ray --- 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
Re: [Mjpeg-users] 1.6.1.93: Bad quality
On Fri, 23 Jan 2004, Ray Cole wrote: > With the same parameters as 1.6.1.92, I'm seeing terrible quality problems. > > Parameters used: > mpeg2enc -f 8 -q 5 -a 2 -g 6 -G 18 -E -10 -N 1.0 -z t -4 2 -2 2 -r 16 -o file.m2v > Is it possible to have less that 200+ character lines? ;) > I'm seeing very poor quality on still scenes. Faces are very blotchy. > Now I also use yuvdenoise - I haven't made any determination as to whether > it is the newer mpeg2enc or newer yuvdenoise killing me, but it feels more > like an mpeg2enc issue more than anything else. I also haven't tried using > -R 2 - that is certainly a major difference between 92 and 93. I'll try > that as well. Anyone else experienced a major decline in quality? Nope, in fact I encoded a 83 minute concert a little while ago and it looks fine. What are you using to do the playback? Ogle? Xine? MPlayer? Standalone player? With no B frames "-R 0", you will see problems with Ogle since it does not implement the DPME (Dual Prime Motion Estimation) - and errors will be logged in the window. Apple's DVD player also appears to have a problem playing discs encoded with "-R 0". MPlayer had no trouble and the movie looked ok - I didn't see any blotches/splotches. I took the same DVD and played it on a Philips 724 player and it looked very good I'll give it another try and see if somehow I overlooked the problems. 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
[Mjpeg-users] 1.6.1.93: Bad quality
With the same parameters as 1.6.1.92, I'm seeing terrible quality problems. Parameters used: mpeg2enc -f 8 -q 5 -a 2 -g 6 -G 18 -E -10 -N 1.0 -z t -4 2 -2 2 -r 16 -o file.m2v I'm seeing very poor quality on still scenes. Faces are very blotchy. Now I also use yuvdenoise - I haven't made any determination as to whether it is the newer mpeg2enc or newer yuvdenoise killing me, but it feels more like an mpeg2enc issue more than anything else. I also haven't tried using -R 2 - that is certainly a major difference between 92 and 93. I'll try that as well. Anyone else experienced a major decline in quality? I'll let you know the result of some additional experiments. -- Ray --- 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
