ffdshow tryouts project: Discussion & Development - Page 39

Dr Pizza · 18th March 2007, 15:14

If someone could provide me with a buildable x64 source tree and suitable files to test it, I could certainly have a look.

ONjA · 18th March 2007, 16:12

Quote:

Originally Posted by haruhiko_yamagata

Thank you, but I can't reproduce. Any aditional information such as CPU, OS, extra filter... are wellcome. Which page to open?

Verified on 3 computers:
AXP and Duron (old, no sse, generic) - w2ksp4, no additional codecs\splitters\packs.
AXP under clean ws2003.

Just invoke ffdshow via player's control, i.e. mpc - filters -> ffdshow video decoder, then close, then invoke once more. Or the same via tray control.

Px · 18th March 2007, 17:30

Quote:

It'll happen as soon as a developer or willing volunteer gets x64.

I can test such builds in my second os, XP x64

Leak · 18th March 2007, 19:30

Okay, here's another updated version of my AviSynth filter:

The current installer based on revision 1048 (and previous versions) can be found here
Patch is here

Changes are that setting 0/1/0 and disabling "Apply Pulldown" should prevent any buffering ahead, just like the old filter. I've also added some code to send an onStop event to the filters when using the DirectShow encoder and encoding finishes, as I need to do some cleaning up if encoding should work more than once in a row.

Note: if you're using ffvfw (the Video for Windows wrapper around ffdshow) for encoding with the AviSynth filter turned on and it is set to buffer ahead you *will* get repeated frames at the beginning of your encode, as VfW *always* expects a compressed frame to come out when it hands an uncompressed frame to a codec - and there's nothing I can do about that.

Encoding using the DirectShow "ffdshow video encoder" works fine, though.

multiblitz · 18th March 2007, 19:49

I guess this is a bug:

If I use ffdshow (rev 1020) to playback VC-1 (HD-DVD) (using Haali's splitter, AnyDVD and ZP), I get a white picture (pure white screen) if I don't resize the picture. With resize (lanzos), I have a nice picture. But I don't want to resize (1920*1080 is already there...)

BIggest Bug so far: If ffdshow is used in the video-part (does not matter if it is only postprocessing-raw-filter after the original MS VC-1 Codec or directly the ffdshow-VC-1-decoder): Instead of correct speed of 23.976 fps, it recognizes 29.999 fps. So, the video is much faster than the audio which indeed is the case...without ffdshow in the video-chain, with pure MS VC-1, it works, eventhough SPDIF is still somewhat jaggy (core duo 6400 at 3.6 ghz).

cc979 · 19th March 2007, 00:43

with rev1050 and before
can't get ffdshow to be used with virtualdub (us sure it work before) it falls back to opening with xvid

is there something up with the vfw part?

cheers

clsid · 19th March 2007, 01:19

It works fine here. If you have both installed it is to be expected that Xvid is used instead of ffdshow. VFW doesn't have a merit system afaik.

skystrife · 19th March 2007, 02:00

Quote:

Originally Posted by Px

I can test such builds in my second os, XP x64

I know nothing about compiling and such, but I would certainly be interested in beta-testing such software. =)

cc979 · 19th March 2007, 03:14

Quote:

Originally Posted by clsid

VFW doesn't have a merit system afaik.

i did'nt know about that, cheers

akupenguin · 19th March 2007, 07:08

Quote:

Originally Posted by Episode

Is there really a need for x64 build of ffdshow? I mean, it won't be any faster than normal 32-bit build and x64 is compatible with normal builds.

It would be faster if you didn't have to disable asm. A 64bit build of ffh264 is 15% faster than a 32bit build on linux, entirely due to the extra registers.

Quote:

Originally Posted by Dr Pizza

Stuff like the H.264 decoder already has 64-bit asm with Windows-specific code paths, it just doesn't work properly.

There is a little 64bit asm (though mostly we just let gcc compile the same asm for 32 and 64bit). But there are no windows-specific codepaths in libavcodec.

bob0r · 19th March 2007, 09:17

ffdshow_rev1050_20070318_clsid.exe
ffdshow_rev1050_20070319_clsid_sse_icl9.exe

Which build should i put on x264.nl?
And why ICL9? (does it still only benefit on Intel and not AMD?)

fastplayer · 19th March 2007, 09:51

Quote:

Originally Posted by bob0r

And why ICL9? (does it still only benefit on Intel and not AMD?)

ffdshow tryouts FAQ

Leak · 19th March 2007, 10:14

Quote:

Originally Posted by fastplayer

ffdshow tryouts FAQ

That still doesn't say anything about whether the executable has Intels dain bramaged "if it isn't an Intel CPU perform much worse/don't run" check patched or not...

foxyshadis · 19th March 2007, 10:47

It's been patched. Current versions of icl just crash when you use AMD, they don't even bother to use the slow route anymore. (At one point VM9 was going to patch them to crash on Intel instead of AMD... ;p)

haruhiko_yamagata · 19th March 2007, 10:57

Quote:

Originally Posted by ONjA

Verified on 3 computers:
AXP and Duron (old, no sse, generic) - w2ksp4, no additional codecs\splitters\packs.
AXP under clean ws2003.

Just invoke ffdshow via player's control, i.e. mpc - filters -> ffdshow video decoder, then close, then invoke once more. Or the same via tray control.

Thank you, now I can reproduce the problem using another computer.

Dr Pizza · 19th March 2007, 15:46

Quote:

Originally Posted by akupenguin

It would be faster if you didn't have to disable asm. A 64bit build of ffh264 is 15% faster than a 32bit build on linux, entirely due to the extra registers.

There is a little 64bit asm (though mostly we just let gcc compile the same asm for 32 and 64bit). But there are no windows-specific codepaths in libavcodec.

tbh, if there were generic C paths that would do me for the moment. Making sure that the C parts are 64-bit LLP64 clean (god what a stupid model! I sorta understand why MS did it, but it's still annoying; they should have bitten the bullet and gone LP64) would be a good start.

clsid · 19th March 2007, 16:20

Quote:

Originally Posted by foxyshadis

It's been patched. Current versions of icl just crash when you use AMD, they don't even bother to use the slow route anymore. (At one point VM9 was going to patch them to crash on Intel instead of AMD... ;p)

I have patched the genuineintel check in the ICL libraries, so SIMD instructions should work on AMD processors too. Are you sure it crashes on AMD?

foxyshadis · 19th March 2007, 18:33

I mean, current unpatched icl. Sorry.

bob0r · 19th March 2007, 19:13

So my question is answered with Beta 2?

ExtraEye · 19th March 2007, 19:17

But of course. Beta 2 is the answer to all questions.

18th March 2007, 19:30	#764 \| Link
Leak ffdshow/AviSynth wrangler Join Date: Feb 2003 Location: Austria Posts: 2,441	Okay, here's another updated version of my AviSynth filter: The current installer based on revision 1048 (and previous versions) can be found here Patch is here Changes are that setting 0/1/0 and disabling "Apply Pulldown" should prevent any buffering ahead, just like the old filter. I've also added some code to send an onStop event to the filters when using the DirectShow encoder and encoding finishes, as I need to do some cleaning up if encoding should work more than once in a row. Note: if you're using ffvfw (the Video for Windows wrapper around ffdshow) for encoding with the AviSynth filter turned on and it is set to buffer ahead you will get repeated frames at the beginning of your encode, as VfW always expects a compressed frame to come out when it hands an uncompressed frame to a codec - and there's nothing I can do about that. Encoding using the DirectShow "ffdshow video encoder" works fine, though. __________________ now playing: [artist] - [track] ([album])

18th March 2007, 19:49	#765 \| Link
multiblitz Registered User Join Date: Dec 2004 Posts: 39	I guess this is a bug: If I use ffdshow (rev 1020) to playback VC-1 (HD-DVD) (using Haali's splitter, AnyDVD and ZP), I get a white picture (pure white screen) if I don't resize the picture. With resize (lanzos), I have a nice picture. But I don't want to resize (19201080 is already there...) BIggest Bug so far: If ffdshow is used in the video-part (does not matter if it is only postprocessing-raw-filter after the original MS VC-1 Codec or directly the ffdshow-VC-1-decoder): Instead of correct speed of 23.976 fps, it recognizes 29.999 fps. So, the video is much faster than the audio which indeed is the case...without ffdshow in the video-chain, with pure MS VC-1, it works, eventhough SPDIF is still somewhat jaggy (core duo 6400 at 3.6 ghz). Last edited by multiblitz; 19th March 2007 at 01:02.*

19th March 2007, 00:43	#766 \| Link
cc979 Curious BetaTester Join Date: Oct 2005 Posts: 430	with rev1050 and before can't get ffdshow to be used with virtualdub (us sure it work before) it falls back to opening with xvid is there something up with the vfw part? cheers __________________ Asrock N68-S AMD Athlon(tm) II X4 620 Processor (2.6GHz) - Crucial 2GB PC6400 800MHz DDR2 - Nvidia 9600GT Tools: ProcessExplorer & ProcessMonitor - BatchCompressor Guide: MinGW Compiling GCC

19th March 2007, 01:19	#767 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	It works fine here. If you have both installed it is to be expected that Xvid is used instead of ffdshow. VFW doesn't have a merit system afaik. __________________ MPC-HC 2.2.1

19th March 2007, 10:47	#774 \| Link
foxyshadis Angel of Night Join Date: Nov 2004 Location: Tangled in the silks Posts: 9,559	It's been patched. Current versions of icl just crash when you use AMD, they don't even bother to use the slow route anymore. (At one point VM9 was going to patch them to crash on Intel instead of AMD... ;p) Last edited by foxyshadis; 19th March 2007 at 10:50.

18th March 2007, 15:14	#761 \| Link
Dr Pizza Registered User Join Date: Feb 2007 Posts: 65	If someone could provide me with a buildable x64 source tree and suitable files to test it, I could certainly have a look.

19th March 2007, 09:17	#771 \| Link
bob0r Pain and suffering Join Date: Jul 2002 Posts: 1,337	ffdshow_rev1050_20070318_clsid.exe ffdshow_rev1050_20070319_clsid_sse_icl9.exe Which build should i put on x264.nl? And why ICL9? (does it still only benefit on Intel and not AMD?)

19th March 2007, 18:33	#778 \| Link
foxyshadis Angel of Night Join Date: Nov 2004 Location: Tangled in the silks Posts: 9,559	I mean, current unpatched icl. Sorry.

19th March 2007, 19:13	#779 \| Link
bob0r Pain and suffering Join Date: Jul 2002 Posts: 1,337	So my question is answered with Beta 2?

19th March 2007, 19:17	#780 \| Link
ExtraEye Registered User Join Date: Nov 2004 Posts: 166	But of course. Beta 2 is the answer to all questions. __________________ Hardware: Core 2 Duo E8400 3GHz, 2048 Ram, Geforce 9800GT.