ffdshow development

[Blight]

Probably not really high priority, but both versions of WarpSharp are completely broken. The standard one seems to be warping the wrong parts of the image while aWarpSharp makes the entire image green.

[arno]

Originally posted by gitoshi
@Andy2222:

I'm not talking about the overlay controls in FFDShow.
I talk about the render mode of the player. If the player use Overlay Mixer you get jerky playback.(look like the decoder is droping frames to keep a/v sync)
This problem was solved in Xvid RC3 but remain in FFDShow, I don't think that is a Libavcodec problem, if I select the XVid4 library as decoder in FFDshow codec page I still had jerky playback.
Just check playback with Core Media Player, or with MPC using Overlay Mixer (Options/PlayBack/Output/Video).

G

Isn't the jerky playback also not (partially) related to the bad performance of the Athos-builds? It seems that the Athos builds don't seem to work properly (smoothly) on both my P2-500 systeem as well as my AMD Duron 1.2GHz systeem. I'm guessing the VC7++ only compiles proper (speedy) code for Pentium-4 users. Maybe Athos can enlight me (us)...

P.s. : One piece of evidence is the fact that the Kuros build, which was built with VC6 DID work properly on both my systems...

[Andy2222]

Originally posted by gitoshi
@Andy2222:

I'm not talking about the overlay controls in FFDShow.
I talk about the render mode of the player. If the player use Overlay Mixer you get jerky playback.(look like the decoder is droping frames to keep a/v sync)
This problem was solved in Xvid RC3 but remain in FFDShow, I don't think that is a Libavcodec problem, if I select the XVid4 library as decoder in FFDshow codec page I still had jerky playback.
Just check playback with Core Media Player, or with MPC using Overlay Mixer (Options/PlayBack/Output/Video).

G

I know that u mean the so called overlay mixer render, wich isnt actually the real render. I play all my stuff using the overlaymixer in zoomplayer or Crystal player and i never had problem's with ffdshow and dropping frames or jumping frames u discribe. My framerate is always constant 23.9... or 25.. in zoomplayer and i watch lotsa diff. types of movies (xvid3/4, divx3-5)? So it seems its a hardware/driver dependent problem.

PS: can u post your system stats and ffdshow version + zoomplayer settings? We cant fix bugs if we cant reproduce them...
Did those bug also happend in pure graphedit mode?

[Andy2222]

Originally posted by arno
Isn't the jerky playback also not (partially) related to the bad performance of the Athos-builds? It seems that the Athos builds don't seem to work properly (smoothly) on both my P2-500 systeem as well as my AMD Duron 1.2GHz systeem. I'm guessing the VC7++ only compiles proper (speedy) code for Pentium-4 users. Maybe Athos can enlight me (us)...

P.s. : One piece of evidence is the fact that the Kuros build, which was built with VC6 DID work properly on both my systems...

As far as i know Athos also use VC6 and CPU Blend options, wich dont optimize that hard for a special cpu. The ICL compiler use several P4/Intel optimizations wich cause problem's on athlon cpu's but are code dependend, so far for my test's it was realy bad using icl for ffdshow + athlon.
For my last speed test's the Athos builds performed oki and i had no big problem's on my athlonxp.

[athos]

Originally posted by Andy2222
As far as i know Athos also use VC6 and CPU Blend options, wich dont optimize that hard for a special cpu. The ICL compiler use several P4/Intel optimizations wich cause problem's on athlon cpu's but are code dependend, so far for my test's it was realy bad using icl for ffdshow + athlon.
For my last speed test's the Athos builds performed oki and i had no big problem's on my athlonxp.
I use VC6 and Pentium CPU option actually. The flags for gcc (libavcodec, mplayer etc) uses -march=i586 -mcpu=i686 which means it requires at least i586-class cpu (pentium) but if available uses i686 (pentium pro) features. so i thought there would be no meaning in including i486. Should I set to Pentium Pro or back to Blend? I am also thinking of maybe releasing specific processoroptimized builds for Pentium4 and maybe AthlonXP, but maybe I should wait for the code to be a bit more stable, especially Xvid 1.0 compability. At the same time I imagine that the low cpu usage of ffdshow is appealing to those with older cpus, who maybe are using an old computer as a media player.

[Andy2222]

Originally posted by athos
I use VC6 and Pentium CPU option actually. The flags for gcc (libavcodec, mplayer etc) uses -march=i586 -mcpu=i686 which means it requires at least i586-class cpu (pentium) but if available uses i686 (pentium pro) features. so i thought there would be no meaning in including i486. Should I set to Pentium Pro or back to Blend? I am also thinking of maybe releasing specific processoroptimized builds for Pentium4 and maybe AthlonXP, but maybe I should wait for the code to be a bit more stable, especially Xvid 1.0 compability. At the same time I imagine that the low cpu usage of ffdshow is appealing to those with older cpus, who maybe are using an old computer as a media player.

That all looks oki for me i realy cant see what cause this (jerky) playback for u gitoshi? Since u also have this problem using the org. xvid.dll and not libav, only the mplayer lib and ffdshow is left. U also have this problem if resize is disabled? Can u try use the org. xvid decoder and set the output to yv12 or rgb32 and also using yv12 or rgb32 in ffdshow output?

[arno]

Originally posted by Andy2222
That all looks oki for me i realy cant see what cause this (jerky) playback for u gitoshi? Since u also have this problem using the org. xvid.dll and not libav, only the mplayer lib and ffdshow is left. U also have this problem if resize is disabled? Can u try use the org. xvid decoder and set the output to yv12 or rgb32 and also using yv12 or rgb32 in ffdshow output?

Some other info (I said it here before but I think it got overlooked):
- The Kuros build fixed the slow-performance problem on both my Duron & Pentium2-500 machine.
- But another problem with the Athos builds: crashing Nic's postprocessing (when enabled ffdshow crashes) was also resolved so I think there's still a problem with the cpu-dependent code generated by your (Athos) compiles. Athos, could you maybe figure out what the difference is between the options you use and the other guy (Kuros) used?

Thanks for listening, guys.

[Andy2222]

Originally posted by arno
Some other info (I said it here before but I think it got overlooked):
- The Kuros build fixed the slow-performance problem on both my Duron & Pentium2-500 machine.
- But another problem with the Athos builds: crashing Nic's postprocessing (when enabled ffdshow crashes) was also resolved so I think there's still a problem with the cpu-dependent code generated by your (Athos) compiles. Athos, could you maybe figure out what the difference is between the options you use and the other guy (Kuros) used?

Thanks for listening, guys.

mhh the so called "Kuros" releases perform realy bad since the libav/mplayer libs was compiled using VC not gcc, so all asm code is ignored. The normal ffdshow code was using blend/normal options as far as i remember. I also remember just that 1 version from Kuros?
So seems its in the asm code of the mplayer lib or libav lib, it could be the asm color conversion code in the mplayer lib?

Can u test this for me, install Kuros release and save/copy the libmplayer.dll and libavcodec.dll somewhere, than install the Athos 09/2003 build and test if it have jerky playback. Now copy the libmplayer.dll from the Kuros release in the ffdshow dir and test it again.

[LigH]

Currently, the "orange-blue bug" seems to be fixed in the latest ffdshow build provided by athos (2003-03-12). At least I got new material from the same source without showing that effect. But I still have to check the same old material I used to discover the bug - later...

[arno]

Originally posted by Andy2222
mhh the so called "Kuros" releases perform realy bad since the libav/mplayer libs was compiled using VC not gcc, so all asm code is ignored. The normal ffdshow code was using blend/normal options as far as i remember. I also remember just that 1 version from Kuros?
So seems its in the asm code of the mplayer lib or libav lib, it could be the asm color conversion code in the mplayer lib?

Can u test this for me, install Kuros release and save/copy the libmplayer.dll and libavcodec.dll somewhere, than install the Athos 09/2003 build and test if it have jerky playback. Now copy the libmplayer.dll from the Kuros release in the ffdshow dir and test it again.

If I do this the jerkiness is 100% certainly fixed. But note that the "Nic's postprocessing" crash still occurs (immidiately), when enabled.

p.s. : Just tried with only replacing either "libmplayer.dll" or "libavcodec.dll", and it seems that the jerkiness is fixed when I only replace "libmplayer.dll". I hope it helps you on what to look for, Andy....

p.s2: I can fix the Nic's postprocessing crash (obviously, I guess) by replacing the ffdshow.ax file with the Kuros one.

[Andy2222]

Originally posted by arno
If I do this the jerkiness is 100% certainly fixed. But note that the "Nic's postprocessing" crash still occurs (immidiately), when enabled.

p.s. : Just tried with only replacing either "libmplayer.dll" or "libavcodec.dll", and it seems that the jerkiness is fixed when I only replace "libmplayer.dll". I hope it helps you on what to look for, Andy....

p.s2: I can fix the Nic's postprocessing crash (obviously, I guess) by replacing the ffdshow.ax file with the Kuros one.

oki can u now do some more for me :)

What CPU flags are displayed (wich cpu options ffdshow thinks u have) in the ffdshow "Info" page for both of your CPU's (MMX, MMXEXT, SSE...)
I think i have a clue what crashes nic's and produce that jerky playback for your cpu's.

[arno]

Originally posted by Andy2222
oki can u now do some more for me :)

What CPU flags are displayed (wich cpu options ffdshow thinks u have) in the ffdshow "Info" page for both of your CPU's (MMX, MMXEXT, SSE...)
I think i have a clue what crashes nic's and produce that jerky playback for your cpu's.

Glad to do so ;-).... CPU options enabled:

All (MMX, MMXEXT, SSE, 3DNOW, 3DNOWEXT) except "SSE2". This is on my Duron machine, the other machine the P3-500 is at work so I can't test this right now...

[Andy2222]

Originally posted by arno
Glad to do so ;-).... CPU options enabled:

All (MMX, MMXEXT, SSE, 3DNOW, 3DNOWEXT) except "SSE2". This is on my Duron machine, the other machine the P3-500 is at work so I can't test this right now...

There are 2 revs. model 7 and 3.

Can u check what Model u have 3 or 7 and what wcpuid tool shows for support?
wcpuid http://cgi2.tky.3web.ne.jp/~nrklv/cgi-bin/softdl.cgi?wcpu31a.exe

[Arska]

Originally posted by dimzon
Bug found at resize feature!

Seems like FFDShow does'nt keep original aspect ratio!
When I use 20030523 bild it work's fine!
I have 720*304 video
I set resize to 800*600 (my VideoCard does'nt work properly when width not mod 32)
Under 20030523 i got nice LETTERBOXED (black zones ot top and bottom) image with width scaled to 800 and video height is scaled proportionaly original aspect ratio (no aspect ratio changed)

Under last athos bild i got scaled to 800*600 image with aspect ratio changed to 4:3 (no letterboxing)


I just tried ffdshow-20040312.exe, and this resize bug still exists (i.e. 'keep original aspect ratio' doesn't work, instead it seems to do exactly the same as 'no aspect ratio correction').

[gitoshi]

ok here my specs
main system
Athlon Xp 2400 (T-Bred core)
Geforce 4 TI 4200 128mb
Win2K DirectX 9.0b
MMX, MMXEXT, SSE, 3DNOW, 3DNOWEXT
CPU 20-30% during play back no PP.

secondary system
Celeron 1Ghz (Tualatin core)
Intel 815
Win2K DirectX 9.0b
MMX, MMXEXT, SSE
CPU 60-70% during play back no PP.

FFdshow 20040312
ZoomPlayer 3.31 fresh install everything default
same problem. If I use VRM9 in ZP the jerky disappear.

Both system are non-SSE2.

G

pd: Where I get Kuros ffdshow build??

[arno]

Originally posted by Andy2222
There are 2 revs. model 7 and 3.

Can u check what Model u have 3 or 7 and what wcpuid tool shows for support?
wcpuid http://cgi2.tky.3web.ne.jp/~nrklv/cgi-bin/softdl.cgi?wcpu31a.exe

I can't check it for my home computer right now (the Duron one) as I'm at work. But for the P3-500 Machine (machine@work) this is the info:
CPU options enabled (ffdshow): MMX, MMXEXT & SSE
WCPUID info: Intel Pentium III, Family=6, Model=7, Stepping ID=3, MMX & SSE supported.

[MarkCoolio]

Has some had this problem too?:

Since 2 or 3 versions of ffdshow if I install it and NOT choose to let it decode mpeg video and audio at all, I get no sound anymore when trying to play such files...

I have installed the Cyberlink DVD decoder filters and all works well when not having installed ffdshow. But if it is installed, I get no sound.

Any ideas?

[bond]

does ffdshow read out the "decoderConfigDescriptor"?

[kilg0r3]

Is there any possibility to include ffdshow as preprocessor in the vfw encoding chain, e.g. with xvid?

[Neo Neko]

only in combination with Avisynth.

[MarkCoolio]

Originally posted by MarkCoolio
Has some had this problem too?:

Since 2 or 3 versions of ffdshow if I install it and NOT choose to let it decode mpeg video and audio at all, I get no sound anymore when trying to play such files...

I have installed the Cyberlink DVD decoder filters and all works well when not having installed ffdshow. But if it is installed, I get no sound.

Any ideas?

Edit: this only seems to appear with Windows Media Player 9 (maybe lower versions too...). In Zoom Player, MPC, etc. it works.

[kilg0r3]

Originally posted by Neo Neko
only in combination with Avisynth.
What I tried so far is to use Directshowsource. I expected ffdshow to then load automaticaly, which it didn't. I does not have anything to do with the avisynth setting in ffdshow, does it?

[bill_baroud]

you have to enable "raw video" in ffdshow i think. Then it's loaded everytime a video is rendered throught Directshow.

[Honza]

I have problem with new versions of ffdshow. The last version which work good was ffdshow-20040113. Newer versions crashes, when i activate dering with Nic´s method of postprocessing.

I use media player classic 6.4.7.6

[arno]

Originally posted by Honza
I have problem with new versions of ffdshow. The last version which work good was ffdshow-20040113. Newer versions crashes, when i activate dering with Nic´s method of postprocessing.

I use media player classic 6.4.7.6

This is a known problem -> I suffer from the same problem. Furthermore you probably also experience stuttering (bad performance). Currently (as far as I know) Andy is looking into this issue and I hope he can fix it.

[arno]

Originally posted by arno
I can't check it for my home computer right now (the Duron one) as I'm at work. But for the P3-500 Machine (machine@work) this is the info:
CPU options enabled (ffdshow): MMX, MMXEXT & SSE
WCPUID info: Intel Pentium III, Family=6, Model=7, Stepping ID=3, MMX & SSE supported.

Ok Andy, just got the info from my home machine (Duron 1.2 GHz) aswell:
CPU options enabled (ffdshow): MMX, MMXEXT, SSE, 3DNow, 3DNowExt
WCPUID info:
AMD Duron (model 7).
Standard: Family=6, Model=7, Stepping ID=1.
Extended: Family=7, Model=7, Stepping ID=1.
MMX & SSE supported.

I hope it helphs (Andy).

[Andy2222]

Originally posted by arno
Ok Andy, just got the info from my home machine (Duron 1.2 GHz) aswell:
CPU options enabled (ffdshow): MMX, MMXEXT, SSE, 3DNow, 3DNowExt
WCPUID info:
AMD Duron (model 7).
Standard: Family=6, Model=7, Stepping ID=1.
Extended: Family=7, Model=7, Stepping ID=1.
MMX & SSE supported.

I hope it helphs (Andy).

just to be sure does WCPUID show that both of your machines are "MMX+" supported? Since u just wrote "MMX & SSE".

[arno]

Originally posted by Andy2222
just to be sure does WCPUID show that both of your machines are "MMX+" supported? Since u just wrote "MMX & SSE".

Pentium 3 machine:
Supported: MMX & SSE (meaning eg. MMX+ is NOT supported).

For my AMD Duron machine I have to get back to you tonight (when I'm home).

[Andy2222]

Originally posted by arno
Pentium 3 machine:
Supported: MMX & SSE (meaning eg. MMX+ is NOT supported).

For my AMD Duron machine I have to get back to you tonight (when I'm home).

Oki thats the problem than, seems ffdshow thinks u have MMX+ but u dont have and that crash Nic's dering since it needs MMX+. If that is also the case for your Duron than its a bug in the Runtime CPU detection code of the mplayer lib or ffdshow function return.

[hellfred]

Originally posted by arno
Pentium 3 machine:
Supported: MMX & SSE (meaning eg. MMX+ is NOT supported).

That is strange. I, too, have a Pentium 3@550mHz. It is a Katmai type, so the first incarnation of the PIII, as far as i know.
And i think it does support MMXext, though wcpuid does tell me it does not, too. I will examine the intel homepage.

Hellfred

[hellfred]

Now i am completely confused.
On the intel homepage it looks like there is no distinction
between MMX and MMXext / MMX2.
Google did not really help, too.

Under linux mplayer detects this feature set for my CPU:
MPlayer dev-CVS-040129-17:38-3.2.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner 549.0 MHz (Family: 6, Step
ping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Under windows, the win32 port of mplayer however does not find the MMX2.

/proc/cpuinfo says
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 548.545
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 1094.45


Hellfred

[Andy2222]

A realy strange problem, since i was also thinking that a P3 has MMX2/Ext, but if nic's dering realy crash ffdshow than it dont have mmx2... its prolly cause of the "pshufw" command wich is indeed a mmx2 command.

I also tryed get some info from the Intel side but all it say's is p3 has SSE and MMX (but not if its mmx + the 15 new mmx2 commands...)

All kinda strange but i think normal the WCPUID tool is 100% correct since that programm is out for a while.

PS: As far as i know the new mmx ext commands (or mmx2) was first introduced with the SSE1 commands or im wrong? Im confused now too...

found this site: http://www.tommesani.com/MMXLatency.html#Latency

here the pshufw command is listed for a P3 so the duron and p3 "should" have mmx2 and they should not crash using nic's dering...

[hellfred]

Originally posted by Andy2222
A realy strange problem, since i was also thinking that a P3 has MMX2/Ext, but if nic's dering realy crash ffdshow than it dont have mmx2... its prolly cause of the "pshufw" command wich is indeed a mmx2 command.

I also tryed get some info from the Intel side but all it say's is p3 has SSE and MMX (but not if its mmx + the 15 new mmx2 commands...)

All kinda strange but i think normal the WCPUID tool is 100% correct since that programm is out for a while.

PS: As far as i know the new mmx ext commands (or mmx2) was first introduced with the SSE1 commands or im wrong? Im confused now too...

found this site: http://www.tommesani.com/MMXLatency.html#Latency

here the pshufw command is listed for a P3 so the duron and p3 "should" have mmx2 and they should not crash using nic's dering...

Here is another one:
http://www.gamasutra.com/features/wyatts_world/19990528/pentium3_01.htm

What is all the fuss about with the Pentium III?

This new processor contains 70 new multimedia instructions, or "Streaming SIMD Instructions" as Intel would like them to be called. Some of these new SIMD (Single Instruction Multiple Data) instructions provide an extension to MMX, and like the existing MMX instructions, they are integer-based
Can you provide me with a small program just checking the relevant pshufw command? Then i will run it on my PIII. Just something like pushing some data in one Registry and afterwards checking the content of it. Maybe you can write something like this in an instant?

Hellfred

[arno]

Originally posted by Andy2222
A realy strange problem, since i was also thinking that a P3 has MMX2/Ext, but if nic's dering realy crash ffdshow than it dont have mmx2... its prolly cause of the "pshufw" command wich is indeed a mmx2 command.

I also tryed get some info from the Intel side but all it say's is p3 has SSE and MMX (but not if its mmx + the 15 new mmx2 commands...)

All kinda strange but i think normal the WCPUID tool is 100% correct since that programm is out for a while.

PS: As far as i know the new mmx ext commands (or mmx2) was first introduced with the SSE1 commands or im wrong? Im confused now too...

found this site: http://www.tommesani.com/MMXLatency.html#Latency

here the pshufw command is listed for a P3 so the duron and p3 "should" have mmx2 and they should not crash using nic's dering...


Just checked my home computer (the AMD Duron one) and this is the additional information you requested about it (WCPUID):
Supported: MMX, SSE, MMX+, 3DNOW & 3DNOW+

Seems that only SSE2 is NOT supported in that machine. It's also odd because that would mean that the problem is not MMX+ related..

IMPORTANT NOTE (Andy): Note that the Nic's postprocessing bug (like the slow-performance problem) were introduced at the exact point where Athos started making the unofficial ffdshow-builds. It still think it's a compile(r) issue....

NOTE2: It seems that the current Athos build does run partially on my P3-500 (although it still crashes sometimes. On my Duron it always crashes...

[jk888]

Ok maybe I'll shout it out to get some response, "FFDSHOW DOES NOT SUPPORT PLAYBACK OF XVID CUSTOM MATRICES SIXOFNINE-HVS". We did multiple rounds of testing in the Xvid forum with screenshots and video clips, check here:
http://forum.doom9.org/showthread.php?s=&threadid=72199

The Xvid decoder plays movies encoded with the SixOfNine-HVS matrices without problems, but when we used the ffdshow decoder it plays with artifacts in the video. Both the older stable version of ffdshow and the latest build does not support it.

PLEASE FIX!!!

[Andy2222]

Originally posted by jk888
Ok maybe I'll shout it out to get some response, "FFDSHOW DOES NOT SUPPORT PLAYBACK OF XVID CUSTOM MATRICES SIXOFNINE-HVS". We did multiple rounds of testing in the Xvid forum with screenshots and video clips, check here:
http://forum.doom9.org/showthread.php?s=&threadid=72199

The Xvid decoder plays movies encoded with the SixOfNine-HVS matrices without problems, but when we used the ffdshow decoder it plays with artifacts in the video. Both the older stable version of ffdshow and the latest build does not support it.

PLEASE FIX!!!

There is no real "ffdshow decoder" ffdshow use the libavcodec or can use the xvid3/4 decoder's if installed.
So those playback bugs appeer with playback set to libavcodec or xvid in ffdshow? If they appeer with libavcodec can u check if the mplayer also produce those errors?

thx


"NOTE2: It seems that the current Athos build does run partially on my P3-500 (although it still crashes sometimes. On my Duron it always crashes..."

i dont think its Athos fault, ffdshow still has many little bug's. I will compile soem test files for you to get an idea why those nic's and jerky playback appeer for u 2 since it never happend for me. Just check your pm's later.

[nadlabak]

jk888:
What exactly have you not understood in Didée's response to your first post?
http://forum.doom9.org/showthread.php?postid=455119

[Kurosu]

Originally posted by Didée
- it's not the fault of ffdshow. It's the fault of the underlying libavcodec routines, hence the ffmpeg-guys will have to look into it, not those who code ffdshow!

- it's not the fault of that specific matrix you mention. The problem occurs with every matrix that contains values <16 for the (inter) DC component in it.
Noticing this recurrent problem, I'm taking some time to discuss it. Looking at a document which I can't identify clearly (MPEG-4 Video Verification VM17.0), I see that Annex J, "encoder complexity reduction based on intelligent pre-quantization", we have this formula for MPEG-4 quantization of non-intra blocks:
coeff(u,v) = sign(F(u,v) * ( (16*|F(u,v)|)//w[u][v] ) / (2*QP)
with: - F(u,v) non-quantized and coeff(u,v) quantized DCT coeff
- w non-intra quantizer matrix
- QP quantizer step
This document states that "to guarantee that all coeff(u,v)=0, we have |F(u,v)|<2*QP"
To me, this means 16/W[u][v]=<1, hence W[u][v]>=16. I couldn't find a clear proof of that, but it would mean that ffmpeg isn't buggy. It would only follow (was: only follows) the standard, and the said matrix would be (was: is) "beyond specs".

The implication on the validity of 6of9 matrix (for instance) isn't immediate, but still, it was worth mentionning that point.

[jk888]

Nope I don't understand what Didée said before, but now I kinda do. So it has nothing to do with ffdshow? How do I let the libavcodec team and the ffmpeg team know about this?

I tested it and found that artifacts only appear when I select libavcodec. I don't use Mplayer, it's for linux isn't it? I only have a windows platform right now.

[Sharktooth]

Originally posted by Kurosu
Noticing this recurrent problem, I'm taking some time to discuss it. Looking at a document which I can't identify clearly (MPEG-4 Video Verification VM17.0), I see that Annex J, "encoder complexity reduction based on intelligent pre-quantization", we have this formula for MPEG-4 quantization of non-intra blocks:
coeff(u,v) = sign(F(u,v) * ( (16*|F(u,v)|)//w[u][v] ) / (2*QP)
with: - F(u,v) non-quantized and coeff(u,v) quantized DCT coeff
- w non-intra quantizer matrix
- QP quantizer step
This document states that "to guarantee that all coeff(u,v)=0, we have |F(u,v)|<2*QP"
To me, this means 16/W[u][v]=<1, hence W[u][v]>=16. I couldn't find a clear proof of that, but it would mean that ffmpeg isn't buggy. It only follows the standard, and the said matrix is "beyond specs".

The implication on the validity of 6of9 matrix (for instance) isn't immediate, but still, it was worth mentionning that point.
Really interesting. You may be right. I'll search for more on the web/newsgroups.

[MfA]

Kurosu, that section is NOT a normative part of the standard. Nothing in the normative part of the standard prohibits values lower than 16.

[Kurosu]

Originally posted by MfA
Kurosu, that section is NOT a normative part of the standard. Nothing in the normative part of the standard prohibits values lower than 16.
This is an annex, yes indeed.

But that wasn't my point: please note the use of the conditionnal. I was just pointing out a strange coincidence.

[MfA]

Okay let me then just point out that you were conditionally wrong :) Nothing in the normative part of the standard prohibits weights smaller than 16.

[Kurosu]

Shall I put conditionnal tense everywhere to get my point straight?
Edit2: This sentence was written with MfA's post in mind, prior to his editing. So it shouldn't have been so flaming. My apologies.

I still agree nothing (was: clearly) forbids the use of values below 16.

Now, that discussion won't solve any bugs, so I'll leave it to that point: the 'bug' occurs when an hypothesis of the optimization in that annex isn't true anymore. Such coincidence was worth mentionning IMHO.

[MfA]

Clear doesnt come into it, the standard doesnt forbid values below 16 period.

[Coroner]

Please could you stop this argument, it isn't helping anyone. It's annoying to get an email notification only to find out it's people still bickering.

Play nice.

:D

[Didée]

Trying to look at the problem from a different angle:

Everytime I stumble over a clip that ffdshow doesn't play correctly, due to "suspicious" quant matrices, I try to decode the clip

- by XviD itself
- by DivX's DS filter
- by 3ivx's DS filter

And it seems that all of these three are able to decode those streams correctly, and only ffdshow fails. This leads me to a certain assumption ...

BTW, what else decoders one could try? (Capable of B-frames, qpel & GMC)

- Didée

[athos]

Originally posted by MfA
Clear doesnt come into it, the standard doesnt forbid values below 16 period.
Ok, you have said that many times now, we get it. Nobody disputes it. You are the winner.

But, Kurosu was trying to point out something that he was hoping might explain this bug. If this explains the bug, we might be able to fix it.

How does your repeating of the same, undisputed claim, help with this?

[Sirber]

Originally posted by Didée
BTW, what else decoders one could try? (Capable of B-frames, qpel & GMC)

- Didée mplayer or VLC :) www.videolan.org

[MfA]

It means you need file a bug report with only one Michael instead of both ... if ffmpeg indeed "only followed the standard" and the matrices xvid allowed were "beyond specs" then xvid would have wanted to correct it. As much as ffmpeg does not mind fixing bugs in other encoders, xvid likes being standard compliant.

Has anyone verified the same problem occurs with mplayer/vlc yet? If so can anyone put up a small sample for the bug report?