Log in

View Full Version : New ffdshow build (?)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72

LoRd_MuldeR
12th December 2006, 00:20
Yes, both beta 1 and 684 work for me. VMR9 renderless + queue, YUY2 or RGB32.

Sorry, for me it does not :(

With "VMR9 (renderless)" and "VRM9 mixer mode" enabled, it says queue not supported by renderer.
With "VMR9 (renderless)" and "VRM9 mixer mode" disabled, it does queue, but I get about 1 frame each 5 seconds.
Doesn't happen when queue is off in ffdshow.

MatMaul
12th December 2006, 00:29
With "VMR9 (renderless)" and "VRM9 mixer mode" disabled, it does queue, but I get about 1 frame each 5 seconds.
I haven't this problem, all is ok (aboot 10 frames in queue) when "VRM9 mixer mode" is disabled.

With "VMR9 (renderless)" and "VRM9 mixer mode" enabled, it says queue not supported by renderer.
Same behaviour with me

sillKotscha
12th December 2006, 08:41
Vorbis? The sample looks like dts.

there are 11 sound tracks in this matroska file... try track 6

http://img151.imageshack.us/img151/5494/6iz6.png (http://imageshack.us)

haruhiko_yamagata
12th December 2006, 10:09
With "VMR9 (renderless)" and "VRM9 mixer mode" enabled, it says queue not supported by renderer.
OK, I can reproduce this. It's not a bug. ffdshow detects error from GetBuffer and prints like that.

With "VMR9 (renderless)" and "VRM9 mixer mode" disabled, it does queue, but I get about 1 frame each 5 seconds.
Doesn't happen when queue is off in ffdshow.
I understood that the queue still had compatibility issue.

It is too hard to fix for beta 1, because the trial to fix the problem will break the code too much.

clsid
12th December 2006, 13:47
Just fix it in trunk. Then it can be in beta2.


Here is an interesting topic about ffdshow:
http://forum.doom9.org/showthread.php?t=119319

KoD
12th December 2006, 15:53
As mentioned by sillKotscha, the sample does have a 6ch Vorbis track just that it's not the default track but the DTS one is.

Regarding Unicode and Windows. It's not a matter of how many languages are being used on the computer, but a matter of Windows function calls and how they are implemented in the dlls that come with Windows. (gdi32.dll, user32.dll, etc)

All Win32 API functions that have a string argument exist, in fact, in two flavours : WindowsFunctionA and WindowsFunctionW , in which A stands for the function that gets an ansi string argument and W stands for the function that gets a unicode string parameter.

For instance, TextOut is implemented in gdi32.dll both as TextOutA and TextOutW.

So, a call in my program to TextOut is in fact a call to either TextOutA or TextOutW from that gdi32.dll. If I defined UNICODE at compile time, then the preprocessor actually replaced all my TextOut function calls with TextOutW function calls and when the linker later on exported the symbols, it exported the TextOutW function call. If UNICODE was not defined, then the preprocessor replaced all my TextOut function calls with calls to TextOutA.

Now, the thing is on Win2000, XP, 2003, Vista and probably all future Windows versions, only TextOutW is actually implemented in gdi32.dll. TextOutA does nothing more than allocate memory from the program heap, converts the ANSI string argument to a Unicode string and then calls TextOutW with that Unicode string as an argument. When the function returns, the heap memory is freed. Since memory allocation is one of the expensive operations, it will incur a performance hit on the application. All Windows functions that have a string argument behave this way, with the A (ANSI) version having to allocate heap memory for string conversion to unicode and then call the W (unicode) function to actually do the job.

On Win98/Me, the situation is different: the A version of functions are implemented and most of the W versions are not, they simply return an ERROR_CALL_NOT_IMPLEMENTED.

So, in the end, on Windows 2000 and newer Windowses, it's best to build with UNICODE defined so that the compiler will generate code that uses the W Windows functions directly.

Eragon4ever
12th December 2006, 16:48
Please take a look here: http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=207

aduwind
12th December 2006, 21:24
http://forum.doom9.org/showthread.php?t=89941

FFT3dGPU is a GPU version of Fizick's FFT3DFilter.
It's, among other things, a denoiser and sharpner filter,that uses the GPU.
FFT3dGPU is an avisynth plugin and it works in ffdshow!!!!...unfortunately at 5/10 FPS in real time ffdshow postprocessing:( :( - On my opteron 165 @ 2.900 and ATI X1600 pro AGP -Catalist 6.10 and Avisynt 2.6
In this version the next frame is processed while waiting for the GPU to end it's work. Meaning the filters before fft3dGPU are working concurrently with it.

The following card should work:

Nvidia:
Geforce FX 5xxx
Geforce 6xxx
Geforce 7xxx

Ati:
Radeon 9500
Radeon 9550
Radeon 9600
Radeon 9700
Radeon 9800
Radeon Xxxx
Radeon X1xxx

Where x, means any digit.

Dear developers, why not explore the way to improve this filter in ffdshow as postprocessing filter ?
We could save CPU usage...:cool: :cool: :cool:

Many thanks

Romario
12th December 2006, 21:50
Your idea is, certainly, refreshing! But, I don't think that fft3dGPU 0.8.2 can integrate and work with ffdshow easily.

Other opinions about this?

devaster
12th December 2006, 22:37
jj i have still big problem to include a (i)dct on gpu implemented with brook but with pure cg is very good
when i get a whole frame builded from dct coeficients then i may run a idct on one call to cg shader and i get back from shader a transformed frame with accurancy comparable to xvid mmx idct but
it is as a twice faster... (my home results ...nvidia6600)

Booji Boy
13th December 2006, 04:40
Uhm, is VP6 advanced profile (VP61) not supported? I use the beta1 from the tryouts.

Jeremy Duncan
13th December 2006, 07:08
jj i have still big problem to include a (i)dct on gpu implemented with brook but with pure cg is very good
when i get a whole frame builded from dct coeficients then i may run a idct on one call to cg shader and i get back from shader a transformed frame with accurancy comparable to xvid mmx idct but
it is as a twice faster... (my home results ...nvidia6600)

How about you post your work or a link to your work so far and the developers here can look and it and maybe help you ? :)

Liisachan
13th December 2006, 10:28
VP61 is too old. What is supported is VP62 aka FLV4.

KoD
13th December 2006, 13:01
On2 has a free download (http://www.on2.com/downloads/) for a directshow vp6 decoder.

DeepBeepMeep
13th December 2006, 13:10
Just fix it in trunk. Then it can be in beta2.


Here is an interesting topic about ffdshow:
http://forum.doom9.org/showthread.php?t=119319

This is maybe slightly off topic. I am quite a big fan of ffdshow, I use it for almost everything including deinterlacing HD.

I have found out that the Kernel deinterlacer and Kernel bob give some very nice results. However the bob version seems to be too CPU intensive with HD even for top notch PCs.

It seems that the kernel deinternlacer / bob have been superseded by LeakKernal deinterlacer / Bob which are much faster. I have tried Leakkernal deinterlacer in avisynth running inside ffdshow and it consumes much less CPU than the previous versions. Unfortunately one can not use the Leakkernal bob since it doubles the output frame rate, which obviously is not supported by ffdshow

Any plan to allow avisynth scripts running inside ffdshow to change frame rates? If not it would be a very good idea to update the kernel deinterlacer / bob with their latest versions. They can be obtained here: http://neuron2.net/kerneldeint/leakkerneldeint154.zip

Thanks

Inventive Software
13th December 2006, 14:46
VP62 is essentially 6.1 and 6.0 with a sharpening postprocessing option. VP61 IIRC implemented "ordinary" postprocessing (i.e deblocking), and VP60 is just the video. I have the encoder if you would like to encode some samples. :)

clsid
13th December 2006, 16:41
Media Player Classic has an internal decoder for VP6 that supports all three subtypes. ffdshow only supports VP62.

Inventive Software
13th December 2006, 18:38
Since when has MPC had decoder support for all VP6 types? It doesn't specify it, so I assume it's cleverly disguised in the FLV support... :D

Liisachan
13th December 2006, 22:15
More or less Gabest planned to support VP60 and VP61 too in the beginning, and even defined MEDIASUBTYPE_vp*60 and 61 once, which were deleted @ rev 596. If there's anything special in MPC, it supports FLV5 partially, not only FLV4.

In case anyone needs VP4/5/60/61 to test them and try to support them, some files are here (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/.on2/). But I think there are more important things to worry about than VP61 etc.

clsid
13th December 2006, 22:53
A while ago I created some sample files with the VP6 VFW codec and I could play all of them with MPC (svn build by Celtic_Druid).

fastplayer
13th December 2006, 23:48
Wow! 24 hours have passed without an update or a new build. ffdshow must be ready for prime time! :D

Liisachan
14th December 2006, 04:41
MPC uses libvp62, a different lib than ffmpeg's, which can only decode On2 VP6.2. Both (VP62).avi and (FLV4).flv play. They are the same codec, and you could even transmux FLV4.flv to VP62.avi using FLV_Extract. Last time I checked, ffdshow and vlc can play VP62.avi too. For ffdshow, both VfW and DS work.

(VP6.1).avi doesn't play.

asasadad_1
18th December 2006, 09:13
ffdshow.ax(ffdshow_rev696_20061215_clsid.exe) conflicted with Elecard MPEG Demultiplexer 1, 0, 74, 60725+ DScaler Mpeg2 Video Decoder 0, 0, 6, 0, after uninstalled ffdshow or just renamed ffdshow.ax to ffdshow1.ax, Elecard MPEG Demultiplexer+ DScaler Mpeg2 Video Decoder worked well.
here (http://www.yourfilelink.com/get.php?fid=239516) is a small mpeg sample + Elecard MPEG Demultiplexer+DScaler Mpeg2 Video Decoder.
os xp sp2.

haruhiko_yamagata
18th December 2006, 09:58
ffdshow.ax(ffdshow_rev696_20061215_clsid.exe) conflicted with Elecard MPEG Demultiplexer 1, 0, 74, 60725+ DScaler Mpeg2 Video Decoder 0, 0, 6, 0, after uninstalled ffdshow or just renamed ffdshow.ax to ffdshow1.ax, Elecard MPEG Demultiplexer+ DScaler Mpeg2 Video Decoder worked well.
here (http://www.yourfilelink.com/get.php?fid=239516) is a small mpeg sample + Elecard MPEG Demultiplexer+DScaler Mpeg2 Video Decoder.
os xp sp2.
Confirmed. Either ffdshow or Elecard MPEG Demultiplexer is broken.

Yong
18th December 2006, 19:24
Could someone help me with this?
im trying to compile ffdshow with gcc 4.1.1/4.2.0, but this is what i get,
http://img174.imageshack.us/img174/3637/grrrrccoo7.jpg

I have set the dxsdk environment accoring to b0bor guide, do i need the platform sdk?
gcc3.4.5 compile baseclasses flawlessly, except the convert dir.
here is where i download gcc4xx :
http://oss.netfarm.it/mplayer-win32.php

ffdshow compilers, please tell me where to download other versions of gcc, i wanna try other versions :)

_xxl
18th December 2006, 20:15
Could someone help me with this?
im trying to compile ffdshow with gcc 4.1.1/4.2.0, but this is what i get,
I have set the dxsdk environment accoring to deaththesheep guide, do i need the platform sdk?
gcc3.4.5 compile baseclasses flawlessly, except the convert dir.
here is where i download gcc4xx :
http://oss.netfarm.it/mplayer-win32.php
ffdshow compilers, please tell me where to download other versions of gcc, i wanna try other versions :)
You can compile ffdshow only with MinGW GCC 4.0.3.

Yong
18th December 2006, 22:10
Thx drevil_xxl :D :D :D
compiling ffdshow is easier than i thought:)
compiled, installed and its worked flawlessly.

Romario
19th December 2006, 00:10
ffmpeg rev 7332 introduce SSSE3 detection. Wow!!!

Revision 7332 - Directory Listing
Modified Mon Dec 18 22:43:09 2006 UTC (23 minutes, 34 seconds ago) by gpoirier

Add SSSE3 (Core2 aka Conroe/Merom/Woodcrester new instructions) detection

midiboy
19th December 2006, 08:54
Hi everyone!

Is it possible that the raw processing filter has problems in ffdshow_beta1_20061211_clsid.exe ?

As you can see in the pics I cannot use it in ZP anymore as a postprocessing filter for DVD playback.

The ZP settings have not changed and it worked well with all previous ffdshow versions (last one I tried before beta 1 was
ffdshow_rev404_20061017_clsid.exe )

Changing the settings in ZP (color space etc.) does not help and raw video in the ffdshow codec section is set to "all supported".

By the way, why is the raw processing filter settings link not included anymore ? I got to it by copying it from an old ffdshow build:

C:\WINDOWS\system32\rundll32.exe ffdshow.ax,configureRaw

Thanks for your help,
Alex

cc979
19th December 2006, 12:00
theres problem with gcc about the thunks, theres a patch out

thunk error (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067)
my build of gcc 4.1.2 has the patch in, check my sig. about it

_xxl
19th December 2006, 14:17
Still,ffdshow.ax compiled by MInGW GCC 4.1.2 crashes.

haruhiko_yamagata
19th December 2006, 15:52
Hi everyone!

Is it possible that the raw processing filter has problems in ffdshow_beta1_20061211_clsid.exe ?

As you can see in the pics I cannot use it in ZP anymore as a postprocessing filter for DVD playback.

The ZP settings have not changed and it worked well with all previous ffdshow versions (last one I tried before beta 1 was
ffdshow_rev404_20061017_clsid.exe )

Changing the settings in ZP (color space etc.) does not help and raw video in the ffdshow codec section is set to "all supported".

By the way, why is the raw processing filter settings link not included anymore ? I got to it by copying it from an old ffdshow build:

C:\WINDOWS\system32\rundll32.exe ffdshow.ax,configureRaw

Thanks for your help,
Alex
If you want to use ffdshow raw video processing in Zoom Player, you have to configure ffdshow using Video decoder configuration (not raw processing filter settings).

Jeremy Duncan
20th December 2006, 03:35
The new libavcodec supports SSE3.
Will this speed up real time Lanczos Resizing, or is libavcodec used only for Encoding ?

foxyshadis
20th December 2006, 05:35
Search for "MM_SSE3" in "*.c;*.h;*.cpp" in "D:\video\work\dev\ffmpeg":

---------- Find in Files ----------
"D:\video\work\dev\ffmpeg\libavcodec\i386\cputest.c"(89,21): rval |= MM_SSE3;
"D:\video\work\dev\ffmpeg\libavcodec\i386\cputest.c"(114,15): (rval&MM_SSE3) ? "SSE3 ":"",
"D:\video\work\dev\ffmpeg\libavcodec\dsputil.h"(486,9):#define MM_SSE3 0x0040 /* Prescott SSE3 functions */
3 occurrences have been found.
Output completed (23 sec consumed)


The new libavcodec supports SSE3.????

That's two people who've confused "detecting processor support" with "supporting". Compare to SSE2, which actually has a few functions written for it. Anyway, libswscale is part of mplayer, although it's also copied into ffmpeg.

LigH
20th December 2006, 08:58
SNOW support has been disabled some time ago, since it was extremely buggy.

Did that change in the meantime? Or is it still recommendable for a "stable" release to avoid its implementation?

Jeremy Duncan
20th December 2006, 09:29
????

That's two people who've confused "detecting processor support" with "supporting". Compare to SSE2, which actually has a few functions written for it. Anyway, libswscale is part of mplayer, although it's also copied into ffmpeg.

So this new feature of ffmpeg won't speed up fps of realtime playback ?
Is this feature only for encoding ?

_xxl
20th December 2006, 09:50
Multithreaded/SMP decoding for MPEG4/H263/H.264 will be very useful.

thuan
20th December 2006, 09:51
It means it only detects whether your CPU has SSE3 or not. No gain in speed.

Inventive Software
20th December 2006, 11:13
Assuming the installers are (sorta) consistent between builders, can I suggest this? Decoders that are selected in the installer are applied for the DShow decoder. Why not have them applied for the VFW decoder too?

sillKotscha
20th December 2006, 11:22
Decoders that are selected in the installer are applied for the DShow decoder. Why not have them applied for the VFW decoder too?

nice idea... but that would mean overwriting already existing vfw decoders you may prefer over ffdshow :rolleyes:

e.g. divx/xvid... I use ffdshow for directshow decoding but I still like to use divx/xvid for vfw...

clsid
20th December 2006, 12:32
Did that change in the meantime? Or is it still recommendable for a "stable" release to avoid its implementation?
There have been no changes to SNOW.

clsid
20th December 2006, 12:38
Assuming the installers are (sorta) consistent between builders, can I suggest this? Decoders that are selected in the installer are applied for the DShow decoder. Why not have them applied for the VFW decoder too?
The current installers already do that. It does so for all MPEG-4 variants and H.264. More can be added at request.

Afaik VFW does not have a merit system. So I don't know whether ffdshow or for example Xvid will take precedence. Probably Xvid, since its FourCC will be a direct match. Please test, if there is a problem, I can build in a detection function.

Mario Bros
20th December 2006, 15:52
Hi! I think i found a possible bug. I often use frame by frame skip in mpc (with the arrow keys), when i hold down the forward key, the player hangs at 100% cpu usage, and i need to kill the process in task man.. The last build that works is CLSID's rev386. I suspect it has something to do with queued output. (it was introduced in rev389). Environment spec: CPU: Athlon 64 3000+ (MMX,SSE1-3), OS: XP SP2, FFdshow -> queued output -> off, media player classic + queue output patch.

haruhiko_yamagata
20th December 2006, 16:28
Hi! I think i found a possible bug. I often use frame by frame skip in mpc (with the arrow keys), when i hold down the forward key, the player hangs at 100% cpu usage, and i need to kill the process in task man.. The last build that works is CLSID's rev386. I suspect it has something to do with queued output. (it was introduced in rev389). Environment spec: CPU: Athlon 64 3000+ (MMX,SSE1-3), OS: XP SP2, FFdshow -> queued output -> off, media player classic + queue output patch.
Yes, it is a bug. I have been debuging this problem since last Sunday.

// EDIT
100% cpu usage? It freezes with 0% cpu usage for me.
It freezes only with VMR9 renderless + RGB out.

Mario Bros
20th December 2006, 19:32
You are right.
Sorry!, I didn't remember correctly.

Jeremy Duncan
21st December 2006, 17:09
"I've been trying to play H.264 files with CoreAVC , but unless I turn raw video to disabled in the ffdshow video settings, the ffdshow mpeg4 filter always seems to be used as well.

I think the CoreAVC decoder is used first, but ffdshow is then used. I get significantly lower frames when this happens, as opposed to when ffdshow is set to disabled. I've run Gspot and it shows CoreAVC only when ffdshow is disabled, but it shows ffdshow being used after CoreAVC when it isn't.

If I block the ffdshow mpeg4 filter in media player this stops it from using the filter even if the raw video is set to all supported in the ffdshow video settings. However, if I do this, I am no longer able to use ffdshow when I watch DVD's, which I would like to do.

I tried setting H.264 to disabled in the ffdshow video codec settings, but this didn't seem to do anything.

Does anyone know how I can prevent ffdshow from being used when playing H.264 files, but still use it when watching DVD's WITHOUT having to change settings everytime I want to watch a different type of media?

Thanks a lot for the help."

Inventive Software
21st December 2006, 17:48
I tested the VFW encoder side of ffdshow. rev 696, the following encoders worked, assume those not listed didn't work.

libavcodec

MPEG-4
MPEG-1
MPEG-2
Lossless JPEG
HuffYUV
FFV1
DV

libtheora
Theora

wmv9 (Note: these encoders used the default WMP10 codecs after installation of WMP10)

Windows Media Video 9
Windows Media Video 9 Advanced Profile (WMVA, not WVC1)
Windows Media Video 9 Screen
Windows Media Video V7
Windows Media Video V8

All other codecs chucked out a "Cannot start encoder (-100)" error in VirtualDub 1.7.0. The source used was an AviSynth input size 720x576@25 FPS, YV12 colourspace. The settings used were the defaults for each codec, 1 pass quality 80.

I will try an old tryouts revision, as well as an old ffdshow revision to determine when the encoder support was broken.

Isochroma
21st December 2006, 19:37
@Jeremy Duncan: The issue is with the CoreAVC filter, which has a strange output colorspace implementation. If you set ffdshow to accept YUV in the Codecs page, then even if you set CoreAVC to output an RGB format, you'll find on playback that it outputs some YUV format and ffdshow ends up in the graph.

There is one solution, you can remove the registry keys for CoreAVC that allow it to output YUV formats, thus forcing RGB always.

Strangely, CoreAVC runs with 2-4% LESS CPU outputting RGB32 than YV12, at least with VMR9 Levels fix checkbox checked.

clsid
22nd December 2006, 00:03
If you enable RAW video support then ffdshow will get inserted into the DirectShow graph. That is not a bug, but exactly what it is supposed to do. It will process the video that was decoded by another filter.

midiboy
22nd December 2006, 00:21
Hi haruhiko_yamagata,

If you want to use ffdshow raw video processing in Zoom Player, you have to configure ffdshow using Video decoder configuration (not raw processing filter settings).

As you can see in the pic, I enabled "all supported" in the "raw video decoder configuration". This used to work fine for years now but not with the beta1 build.

If I enable raw video in the normal video decoder configuration then ffdshow will load in all kinds of graphs where I do not want it. Thats the reason for the extra raw video decoder, no? To be able to insert ffdshow for instance for DVD post processing.

Otherwise the "raw video filter" ({0B390488-D80F-4A68-8408-48DC199F0E97}) is useless, no ?

Thanks for your help,
Alex