Problem with the latest CVS build?

Jeffster · 20th September 2005, 14:42

Hi,

I've just installed the latest CVS build from celtic_druid and there appears to be a problem with it, at least on my system anyway. (actually builds from both the 15/09 and 16/09)

Maybe it is already known, but I haven't seen any reports here so I thought I'd mention it. The video produced it is barely watchable, and I've never seen that happen before.

I've temporarily uploaded two samples to my homepage server for anyone who wishes to see what I mean.

The first sample from 08/02 build is normal, as expected. By contrast, the second sample from 09/16 build clearly demonstrates the problem. Both were encoded at Q3 and the rest of the settings were the defaults. Interestingly the filesize is different too.

FWIW - my cpu is Intel (celeron)

Jeff

celtic_druid · 20th September 2005, 15:06

Downloaded both, compressed the good one myself with Q3 + defaults and it looks fine.
My other limited tests also came out fine.

On the 15th I released gcc, ICL7 and ICL9 builds. Are they all effected? The one on the 16th was patched ICL9. Only the genuine intel check was removed though so it shouldn't make any difference.

Some one else want to test since I don't appear to be able to replicate the problem.

Jeffster · 20th September 2005, 15:57

After seeing the result with 16th I went back and grabbed one from the 15th packed in 7z "xvid.cvs.head.2005.09.15.7z"...

I'm not sure which compile it is sorry, except it wouldn't be the ICL9 one since that is named as such.

I just checked another mirror and it has 3 files dated the 15th and I guess they are different compiles?
XviD.cvs.head-20050915.exe
XviD.cvs.head-20050915_2.exe
XviD.cvs.head-ICL9-20050915.exe

I've tried all 3 now and get the exact same (weird) result.

celtic_druid · 20th September 2005, 16:17

XviD.cvs.head-20050915.exe & XviD.cvs.head-20050915_2.exe I think are basically the same. I added a userdata field with the build date and updated the installer.

I can't reproduce the problem at all though and I don't have any Intel CPU's to test with, let alone a celeron.

boombastic · 20th September 2005, 20:17

just to know because i am a newbie of compiling stuff:

which is better between the ICL9,ICL8 and GCC compiles for an Athlon XP 3000+?
Besides this, i tried the compile of the 15th and got a fine result.

Episode · 20th September 2005, 21:42

ICL9 should still be faster than the others, even on AMD processors.

celtic_druid · 21st September 2005, 01:51

Since I removed the genuine intel checks from the ICL9 compile it should definatly be faster on AMD's. With the checks in place ICL7 I would think would be faster.

How gcc fares I don't know. People always wanted gcc compiles though, so I still do them occasionally.

Jeffster · 22nd September 2005, 10:59

Quote:

Originally Posted by celtic_druid

Some one else want to test since I don't appear to be able to replicate the problem.
[...]
I can't reproduce the problem at all though and I don't have any Intel CPU's to test with, let alone a celeron.

I hope someone else is able to test this and reproduce the problem too. I'm beginning to wonder if it may somehow be cpu related.

I'm gonna try attaching a screenshot showing what I mean for those unable to check out the sample clip. This time I also enabled 'Print debug info', not that it is very helpful since it's unreadable.
(bare in mind this was encoded at Q2 this time!)

celtic_druid · 22nd September 2005, 13:25

Surely there must be someone else here able to test? I tested on one AMD 64 and a thunderbird. Both were fine.

I'll put up a plain MSVC build for you to test.
http://mirror05.x264.nl/celtic_druid..../xvid_msvc.7z

Jeffster · 22nd September 2005, 13:59

Thanks celtic_druid.
I tried with the plain build but unfortunately the results were still the same for me.

celtic_druid · 22nd September 2005, 14:26

Ok, so it probably isn't a compiler issue.

Koti · 22nd September 2005, 17:11

I can confirm and reproduce this 100% ( intel celeron mobile 1333mhz )
with that build posted above - Vob > VDubMod > Xvid (Q2 defaults) = Disaster just as Jeffster has show in post above

edit - no problems on P4 3.2 Prescott or AMD2100+

edit 2 - performance optimizations - xvid on celeron detects and uses MMX , Integer SSE , SSE
When MMX is disabled the output is fine.
(I hope that can narrow down where to look for the bug )

kesako · 22nd September 2005, 20:29

i've got a problem too.
i've downloaded XviD.cvs.head.MTK__20050921.exe.i've tested the MTK PAL profile with these settings :
2 pass
quantizer type : MPEG
adaptive quantization
1000 kbps
motion search precision: ultra high
VHQ mode : wide search
use VHQ for b-frames too.
use chroma motion
max i frame interval : 250

other settings by default
result is very bad.

suxen_drol · 22nd September 2005, 23:54

confirmed. to reproduce the problem, force the use of MMX optimised functions only in advanced->debug window.

this suggests a bug within one or more of the mmx-only optimised functions. the equivalent sse2/3dnow function(s) are working correctly, and as most users have p4/athlon/modern-celeron cpus, this explains why few people have detected the fault.

-- pete

celtic_druid · 23rd September 2005, 02:05

So it looks like one of the new ASM functions added recently is responsible.

Someone really should post this on the mailing list.

Jeffster · 23rd September 2005, 06:01

Thanks everyone.

I'm glad the bug has been confirmed and narrowed down at least.

ChronoCross · 23rd September 2005, 06:03

it happened to me using megui. Pentium 3 so it's most definitely one of the MMX functions. Happened it 2 pass mode for every single frame no matter the quant.

squid_80 · 23rd September 2005, 09:20

Looks like the AC coefficients are missing. Could the new cbp_mmx function be responsible? (I'm only looking at the cvs log, haven't checked the code...)

EDIT: Yep, looks like calc_cbp_mmx is doing something it shouldn't.

EDIT2: The packssdw/pcmpgtw instructions are buggy. I can explain in greater detail if required.

sysKin · 23rd September 2005, 16:26

Quote:

Originally Posted by squid_80

Could the new cbp_mmx function be responsible?

It's funny how cbp calculations, were optimized over and over again, while they have no impact on the speed at all

Sharktooth · 23rd September 2005, 18:30

Well, but now it's optimized...

20th September 2005, 14:42	#1 \| Link
Jeffster Registered User Join Date: Jan 2003 Location: Land of the Long White Cloud Posts: 183	Problem with the latest CVS build? Hi, I've just installed the latest CVS build from celtic_druid and there appears to be a problem with it, at least on my system anyway. (actually builds from both the 15/09 and 16/09) Maybe it is already known, but I haven't seen any reports here so I thought I'd mention it. The video produced it is barely watchable, and I've never seen that happen before. I've temporarily uploaded two samples to my homepage server for anyone who wishes to see what I mean. The first sample from 08/02 build is normal, as expected. By contrast, the second sample from 09/16 build clearly demonstrates the problem. Both were encoded at Q3 and the rest of the settings were the defaults. Interestingly the filesize is different too. FWIW - my cpu is Intel (celeron) Jeff Last edited by Jeffster; 23rd September 2005 at 14:17. Reason: removed samples - screenshot in later post instead

20th September 2005, 15:57	#3 \| Link
Jeffster Registered User Join Date: Jan 2003 Location: Land of the Long White Cloud Posts: 183	After seeing the result with 16th I went back and grabbed one from the 15th packed in 7z "xvid.cvs.head.2005.09.15.7z"... I'm not sure which compile it is sorry, except it wouldn't be the ICL9 one since that is named as such. I just checked another mirror and it has 3 files dated the 15th and I guess they are different compiles? XviD.cvs.head-20050915.exe XviD.cvs.head-20050915_2.exe XviD.cvs.head-ICL9-20050915.exe I've tried all 3 now and get the exact same (weird) result. Last edited by Jeffster; 20th September 2005 at 15:59. Reason: edit

22nd September 2005, 13:25	#9 \| Link
celtic_druid Registered User Join Date: Oct 2001 Location: Melbourne, Australia Posts: 2,171	Surely there must be someone else here able to test? I tested on one AMD 64 and a thunderbird. Both were fine. I'll put up a plain MSVC build for you to test. http://mirror05.x264.nl/celtic_druid..../xvid_msvc.7z Last edited by celtic_druid; 22nd September 2005 at 13:45.

22nd September 2005, 17:11	#12 \| Link
Koti Always trying Join Date: Jan 2005 Location: The O.C. ;) Posts: 221	I can confirm and reproduce this 100% ( intel celeron mobile 1333mhz ) with that build posted above - Vob > VDubMod > Xvid (Q2 defaults) = Disaster just as Jeffster has show in post above edit - no problems on P4 3.2 Prescott or AMD2100+ edit 2 - performance optimizations - xvid on celeron detects and uses MMX , Integer SSE , SSE When MMX is disabled the output is fine. (I hope that can narrow down where to look for the bug ) Last edited by Koti; 22nd September 2005 at 23:12.

22nd September 2005, 20:29	#13 \| Link
kesako Registered User Join Date: Feb 2005 Posts: 3	i've got a problem too. i've downloaded XviD.cvs.head.MTK__20050921.exe.i've tested the MTK PAL profile with these settings : 2 pass quantizer type : MPEG adaptive quantization 1000 kbps motion search precision: ultra high VHQ mode : wide search use VHQ for b-frames too. use chroma motion max i frame interval : 250 other settings by default result is very bad. Attached Images

20th September 2005, 15:06	#2 \| Link
celtic_druid Registered User Join Date: Oct 2001 Location: Melbourne, Australia Posts: 2,171	Downloaded both, compressed the good one myself with Q3 + defaults and it looks fine. My other limited tests also came out fine. On the 15th I released gcc, ICL7 and ICL9 builds. Are they all effected? The one on the 16th was patched ICL9. Only the genuine intel check was removed though so it shouldn't make any difference. Some one else want to test since I don't appear to be able to replicate the problem.

20th September 2005, 16:17	#4 \| Link
celtic_druid Registered User Join Date: Oct 2001 Location: Melbourne, Australia Posts: 2,171	XviD.cvs.head-20050915.exe & XviD.cvs.head-20050915_2.exe I think are basically the same. I added a userdata field with the build date and updated the installer. I can't reproduce the problem at all though and I don't have any Intel CPU's to test with, let alone a celeron.

20th September 2005, 20:17	#5 \| Link
boombastic Registered User Join Date: Oct 2003 Location: Ascoli Piceno-Italy Posts: 279	just to know because i am a newbie of compiling stuff: which is better between the ICL9,ICL8 and GCC compiles for an Athlon XP 3000+? Besides this, i tried the compile of the 15th and got a fine result.

20th September 2005, 21:42	#6 \| Link
Episode n00b Join Date: Jan 2003 Location: Tokyo, Japan Posts: 122	ICL9 should still be faster than the others, even on AMD processors.

21st September 2005, 01:51	#7 \| Link
celtic_druid Registered User Join Date: Oct 2001 Location: Melbourne, Australia Posts: 2,171	Since I removed the genuine intel checks from the ICL9 compile it should definatly be faster on AMD's. With the checks in place ICL7 I would think would be faster. How gcc fares I don't know. People always wanted gcc compiles though, so I still do them occasionally.

22nd September 2005, 13:59	#10 \| Link
Jeffster Registered User Join Date: Jan 2003 Location: Land of the Long White Cloud Posts: 183	Thanks celtic_druid. I tried with the plain build but unfortunately the results were still the same for me.

22nd September 2005, 14:26	#11 \| Link
celtic_druid Registered User Join Date: Oct 2001 Location: Melbourne, Australia Posts: 2,171	Ok, so it probably isn't a compiler issue.

22nd September 2005, 23:54	#14 \| Link
suxen_drol Registered User Join Date: Nov 2001 Posts: 24	confirmed. to reproduce the problem, force the use of MMX optimised functions only in advanced->debug window. this suggests a bug within one or more of the mmx-only optimised functions. the equivalent sse2/3dnow function(s) are working correctly, and as most users have p4/athlon/modern-celeron cpus, this explains why few people have detected the fault. -- pete

23rd September 2005, 02:05	#15 \| Link
celtic_druid Registered User Join Date: Oct 2001 Location: Melbourne, Australia Posts: 2,171	So it looks like one of the new ASM functions added recently is responsible. Someone really should post this on the mailing list.

23rd September 2005, 06:01	#16 \| Link
Jeffster Registered User Join Date: Jan 2003 Location: Land of the Long White Cloud Posts: 183	Thanks everyone. I'm glad the bug has been confirmed and narrowed down at least.

23rd September 2005, 06:03	#17 \| Link
ChronoCross Does it really matter? Join Date: Jun 2004 Location: Chicago, IL Posts: 1,542	it happened to me using megui. Pentium 3 so it's most definitely one of the MMX functions. Happened it 2 pass mode for every single frame no matter the quant.

23rd September 2005, 09:20	#18 \| Link
squid_80 Registered User Join Date: Dec 2004 Location: Melbourne, AU Posts: 1,963	Looks like the AC coefficients are missing. Could the new cbp_mmx function be responsible? (I'm only looking at the cvs log, haven't checked the code...) EDIT: Yep, looks like calc_cbp_mmx is doing something it shouldn't. EDIT2: The packssdw/pcmpgtw instructions are buggy. I can explain in greater detail if required. Last edited by squid_80; 23rd September 2005 at 12:03.

23rd September 2005, 18:30	#20 \| Link
Sharktooth Mr. Sandman Join Date: Sep 2003 Location: Haddonfield, IL Posts: 11,768	Well, but now it's optimized... __________________ MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!!

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode