New ffdshow build (?)

[haruhiko_yamagata]

Enabling that setting means MPC will decode, not ffdshow. That's why I questioned your report of proper playback.

That file is a satellite DVR stream with mux to accomodate dropouts, most often those happen in audio. It might also use the field duplication flag. It's MPEG2 valid but not DVD spec valid. It's a nice small real-world test sample. Is it choking ffdshow's demux or one of the video decoders or a combination of both? I don't know. My hunch is this is a demux issue because both MPEG2 decoders choke in the same manner.

It's not an odd profile, btw. Burn it to a disc and it will play in almost any hardware DVD player although some of the Sony units are touchy. It will also play in "proper" DVD players like PowerDVD.
As foxyshadis said, ffdshow never demux anything. ffdshow just decode.

[cc979]

I already send a sample to Rapidshare. Link in my first post in this Thread.




In Media Player Classic, adding WMVideo Decoder DMO in external filters, ffdshow decode the file. Is recognized as YV12 - uncompressed.

the file plays in VLC fine, gspot recognise it as wmv3 - but ffdshow does play it

[Rgeek]

the file plays in VLC fine, gspot recognise it as wmv3 - but ffdshow does play it

Mean You ffdshow does not play it?


Thanks to people help me. I'm newbie and I was Thinking the problem is my inexperience.

I partly solve this issue using AviSynth script: DirectShowSource("file.avi")


PS. My English is broken(so far), sorry for some thing non-intelligible.

[FredThompson]

As foxyshadis said, ffdshow never demux anything. ffdshow just decode.Hmmm...the playback problems must be all inside ffdshow, don't you think? The file plays properly with MPC decoding.

[dk75]

No, it don't. (FruitBeer.vob)
Whenever i use internal MPEG2 or ffdshow decode in MPC it's this same - it's stops.
When i change splitter from Haali to internal MPC then it crashes.
But it's play very well in mplayer.
So... this must be demuxer problem not libmad2/libavcodec problem.

[chros]

x264.nl added clsid ffdshow revision 497.
I must say i am amazed...
If ffmpeg would use multi core/cpu code i am sure it could match, or even surpass all the other H.264 decoders.
It's very fast indeed ... :) Almost like CoreAVC ...

Is there any plan to adding multicore support? It's needed ! :)

[Eragon4ever]

Added three patches to Sourceforge:

1. A bugfix of German part of custom_messages.iss.
@haruhiko: One of your last commits of this file (I think r437) broke the German letter 'ü' and replaced the following letter with 'E'. Maybe you svn client cannot handle it. (here (http://sourceforge.net/tracker/index.php?func=detail&aid=1582239&group_id=173941&atid=867362))

2. A fixed version of the German copying.txt. (here (http://sourceforge.net/tracker/index.php?func=detail&aid=1595242&group_id=173941&atid=867362))

3. An up to date (r522) version of the changelog, including the missing ffmpeg comments. (here (http://sourceforge.net/tracker/index.php?func=detail&aid=1595243&group_id=173941&atid=867362))

[breez]

Nice indeed.

A little benchmark using timecodec.exe and 640x480 H.264 file:

clsid ffdshow rev 514: 190.9fps
CoreAVC Standard: 213.8fps

(Athlon XP 10.5x180MHz)

[fastplayer]

@Haruhiko & Co.:
I noticed a small GUI bug in ffdshow's audio decoder properties. Take a look at size of the "Mixer" group box:
http://img477.imageshack.us/img477/963/guibugjm1.png
I think it happened right after the ffdshow dialog resize.

[Inventive Software]

3000+ posts in a thread started more than a year ago. Well done everybody. :)

[haruhiko_yamagata]

Hmmm...the playback problems must be all inside ffdshow, don't you think? The file plays properly with MPC decoding.
No, I don't think so.
MPC decoder with "MPEG PS/TS/PVA" off, the video stops as well as it does with ffdshow.
Creating a decent filter graph is applications responsibilty. As for MPC, that source filter is enabled by default. If you want to disable it, you have to do so at your own risk.

[foxyshadis]

I forgot something, with the wmv9 issue brought up recently - WM9 decoder passthrough is missing from current builds. I think it has been since VC-1 was removed and WMV9 was added back. Was it a licensing reason? Or is it essentially equivalent to disabling it anyway?

[_xxl]

http://img22.imagevenue.com/loc598/th_25151_Capture_122_598lo.jpg (http://img22.imagevenue.com/img.php?image=25151_Capture_122_598lo.jpg)
"wmv9" decoder works in vfw mode.

[Episode]

@clsid, could you please make another icl9 build?

[Eragon4ever]

I noticed an other GUI bug (even smaller than the last):
http://img87.imageshack.us/img87/2393/screenshot1311200614502af7.png

When I resize of the first column the dropdown box stays where it is until I'm finished. (I hope you know what I want to say.)

[haruhiko_yamagata]

Added three patches to Sourceforge:

1. A bugfix of German part of custom_messages.iss.
@haruhiko: One of your last commits of this file (I think r437) broke the German letter 'ü' and replaced the following letter with 'E'. Maybe you svn client cannot handle it. (here (http://sourceforge.net/tracker/index.php?func=detail&aid=1582239&group_id=173941&atid=867362))

2. A fixed version of the German copying.txt. (here (http://sourceforge.net/tracker/index.php?func=detail&aid=1595242&group_id=173941&atid=867362))

3. An up to date (r522) version of the changelog, including the missing ffmpeg comments. (here (http://sourceforge.net/tracker/index.php?func=detail&aid=1595243&group_id=173941&atid=867362))
Thank you. Please wait a few days.

[cc979]

Mean You ffdshow does not play it?


Thanks to people help me. I'm newbie and I was Thinking the problem is my inexperience.

I partly solve this issue using AviSynth script: DirectShowSource("file.avi")


PS. My English is broken(so far), sorry for some thing non-intelligible.

oops. i did mean ffdshow does not play it

[fastplayer]

Thanks a lot for the quick fix and the new build! :thanks:

One other minor GUI 'thingie': When clicking on skip deblocking always in H.264 codec settings, shouldn't then skip deblocking when safe automagically be greyed-out?

[G_M_C]

I've got some questions about the current state of ffdshow, and a specific way to set it up.

1)
Approx one week ago I set up ffdshow, and since then i've got serious problems with AviSynth's DirectShow () command.
When i use DSS() the video-window flashes grey in a irregular pattern. The pattern changes when restarting the video, but will never show the same pattern.

It happened with a X264 video in a mkv-container, but hapens with other types of video too. It's quite annoying, because transcoding H264 to anything else goes thru AviSynth's DSS() with most applications, so i hope there's a fix for this.

Also see my post at: http://forum.doom9.org/showthread.php?t=118101

2)
Also since i installed ffdshow, the general quality of video-playback seems to have dropped. I now get visable pixellation when i resize the view-plane to full screen. When i force decoding thru XviD and than switch to full screen edges look smooth, and there is far less pixelation to be seen.

How can tah be fixed.

3) This one is related to both questions above;
I only installed ffdshow for the abillity to decode H264 streams. I use that abillity with H264-streams / X264-streams that are contained in .TS in .MKV and/or are extracted to MP4 or even raw streams. But in general i only need the H264 abillity.

To get that i paintstakingly switched of all optios in ffdshow that arent related to H264 (some of wich helped to improve the state of question 1 and 2). But the question is now: Can someone give me directions to set up ffdshow for H264 only, with the highest video-quality possible ? And offcourse the streams should be able to be opened in AviSynth for transcoding, because thats the reason whay i need this setup.

4)
When you come to the conclusion that i'm better of with another codec (like CoreAVC or so), can i safey deinstall ffdshow, without problems ? Because the ffdshow-wiki mentions a serious problem with the uninstaller (it deletes all windows audio,- and video codecs :( )

[_xxl]

Because the ffdshow-wiki mentions a serious problem with the uninstaller (it deletes all windows audio,- and video codecs :( )
Bug was fixed.

[FredThompson]

No, I don't think so.
MPC decoder with "MPEG PS/TS/PVA" off, the video stops as well as it does with ffdshow.
Creating a decent filter graph is applications responsibilty. As for MPC, that source filter is enabled by default. If you want to disable it, you have to do so at your own risk.One of us is confused. "MPEG PS/TS/PVA" is MPC's internal decoder. When it is on, MPC decodes the video. When it is off, ffdshow will decode the MPEG stream if ffdshow is set for MPEG2 decoding, correct?

The video plays properly with that setting enabled. However, MPC does not support 4:2:2 MPEG2. The libavcodec inside ffdshow does not support 4:2:2 MPEG2. The libmpeg2 inside ffdshow supports 4:2:2 MPEG2 but it chokes when trying to play FruitBeer.vob.

FWIW, mplayer also puked on FruitBeer.vob

[KoD]

"MPEG PS/TS/PVA" is MPC's internal decoder.
Incorrect. MPEG PS/TS/PVA is MPC's internal mpeg splitter, not decoder. Microsoft Windows os-es (or maybe it's the WMP install) come with an mpeg2 splitter, the mpeg2splt.ax file which you can find in your Windows\system32 folder. It's this splitter that seems to choke on that file.

When you enable MPEG PS/TS/PVA in MPC, MPC will use its built-in mpeg splitter instead of the Windows mpg2splt.ax. Once you enable it, the file does not freeze in MPC no matter that you use ffdshow's mpeg2 decoder, nvidia's mpeg 2 decoder, cyberlink's mpeg 2 decoder, windvd's mpeg2 decoder or MPC's built-in mpeg2 decoder. If you are going to use another player than MPC (like WMP or mplayer2), the Windows provided mpg2splt.ax splitter will be used and the playback will freeze.

Now, if you want to use MPC's internal mpeg splitter for other programs to see, you can find it as an external filter here: celtic druid's stash (http://esby.free.fr/CelticDruid/mirror/Media%20Player%20Classic/external%20filters/unicode/). Just register it and it should take over mpg2splt.ax. It used to sometime break filter graphs for other formats, don't know what is its status now so registering it like this is not without risk.

The flow is like this: media container -> splitter -> decoders that work on the streams received from the splitter -> decoder output goes to presentation or other processing filters.

Ffdshow is only a bunch of decoders and processing filters bundled together, it doesn't work as a splitter.

[clsid]

To get that i paintstakingly switched of all optios in ffdshow that arent related to H264 (some of wich helped to improve the state of question 1 and 2). But the question is now: Can someone give me directions to set up ffdshow for H264 only, with the highest video-quality possible ? And offcourse the streams should be able to be opened in AviSynth for transcoding, because thats the reason whay i need this setup.
You can select which formats are decoded by ffdshow during installation. Deselecting everything is pretty easy, since it uses a tree. Uncheck the parent node to uncheck all of its children. Then check H.264.

[ilpippo80]

First of all, thanks for your hard work on ffdshow, guys!
now, let's talk about "business":
with both ffdshow_rev529_20061113_clsid.exe and ffdshow_rev529_20061113_clsid_icl9.exe I have a slowdown of about 25 seconds (!!!) during any file opening in media player classic (haven't tried other players). I tried changing a few settings (like disabling the queue) and I tried several kind of files but the problem persisted. Reinstalling ffdshow_rev514_20061109_clsid_icl9.exe solved the problem... Anyone else has this issue?
Do you need any more details?

[lasuocera]

Hi all, same problem for me. Also on osd cpu time i have a message regarding windows vista.

My computer:
cpu: Pentium 4 1700 512mb ram
video: hercules 3d prophet 4500 tvout
system: xp sp2

Tested with mpc (latest build by celtic_druid) vmr9 renderless.
Thank you for your great work.

[haruhiko_yamagata]

Hello, ilpippo80 and lasuocera. Where is pdh.dll in your hdd?
Typically it should be C:\WINDOWS\system32.

ilpippo80, is "CPU Load" working for you?

[lasuocera]

Can't answer now. I'm not on my machine. See you later!

[FredThompson]

Incorrect. MPEG PS/TS/PVA is MPC's internal mpeg splitter, not decoder. ...
Ah, OK, thanks for clearing that up. As I said, "one of us is confused." In this case, it was me. :eek:

[Px]

2)
Also since i installed ffdshow, the general quality of video-playback seems to have dropped. I now get visable pixellation when i resize the view-plane to full screen. When i force decoding thru XviD and than switch to full screen edges look smooth, and there is far less pixelation to be seen.

How can tah be fixed.
Turn on postprocessing......

[ilpippo80]

for me pdh.dll is in d:\windows\system32
cpu load gives me: "does not work in vista ..."
btw, I'm on win xp sp2, on a p4 3GHz with HT enabled and I have an administrator account.

[yesgrey]

Hi,

Could anyone post the actual ffdshow source in a compressed single file for download? I would like to see if I would be able to add the resize for screen resolution, and I don't want to deal with svn before knowing if I could write the code...

Thanks.

[MatMaul]

with both ffdshow_rev529_20061113_clsid.exe and ffdshow_rev529_20061113_clsid_icl9.exe I have a slowdown of about 25 seconds (!!!) during any file opening in media player classic (haven't tried other players). I tried changing a few settings (like disabling the queue) and I tried several kind of files but the problem persisted. Reinstalling ffdshow_rev514_20061109_clsid_icl9.exe solved the problem... Anyone else has this issue?
Do you need any more details?
Same problem with xp sp2, MPC and v5.1.2600.2180 of pdh.dll.

[clsid]

No problems on my Windows 2000 (pdh.dll version 5.0.2195.6660).

[netwolf]

I have the same problem (long delay after starting playback) here on my laptop, using XP Pro SP2, latest Omega drivers (ATI mobility 9700) and ZoomPlayer Pro and ffdshow_rev529_20061113_clsid.exe

[Peuj]

no problem too on my Windows XP SP2 (pdh.dll version 5.1.2600.2180)

[Inventive Software]

Codec(s) used would give a good indication people. I have no problems with MPEG-4 ASP or DivX or XviD playback for the record. Must also add that mplayer automatic post-processing is now working! :) (clsid's 529 build)

[lasuocera]

Hello, ilpippo80 and lasuocera. Where is pdh.dll in your hdd?
Typically it should be C:\WINDOWS\system32

pdh.dll version 5.1.2600.2180 is in C:\WINDOWS\system32.
Sorry! I made a mistake confusing my notebook configuration with the PC i use at work. I'm using an ASUS A2800S notebook P4 3.06 with Radeon Mobility 9600

P.s. I had no problems with previous build by clsid.
P.p.s. Tested decoding xvid

[_xxl]

Please test my build!
http://www.sendspace.com/file/n8wuo5

[Eragon4ever]

Could anyone post the actual ffdshow source in a compressed single file for download? I would like to see if I would be able to add the resize for screen resolution, and I don't want to deal with svn before knowing if I could write the code...

Here you go: ffdshow rev 535 src (http://rapidshare.com/files/3341642/ffdshow_r535.7z.html)

[yesgrey]

Thanks!

[akapuma]

Hello,

I've a problem to play this file: http://akapuma.info/test/Sac-001.mkv (266kB)
This file contains x264 and vorbis in a mkv-container. Player: MPC, WMP6.4. Splitter: haali. WIN2000SP4

Problems with newer ffdshow (player hangs, abort via taskmanager required):
533 by Dirk Paehl
529 by CLSID

No problems with older ffdshow:
514 by Dirk Paehl
494 by CLSID

Best regards

akapuma

[_xxl]

Hello,
I've a problem to play this file: http://akapuma.info/test/Sac-001.mkv (266kB)
This file contains x264 and vorbis in a mkv-container. Player: MPC, WMP6.4. Splitter: haali. WIN2000SP4
Best regards
akapuma
My build is working for me with this file.
MPC+ffdshow.
http://www.sendspace.com/file/n8wuo5

[Eragon4ever]

I've a problem to play this file: http://akapuma.info/test/Sac-001.mkv (266kB)
This file contains x264 and vorbis in a mkv-container. Player: MPC, WMP6.4. Splitter: haali. WIN2000SP4

Problems with newer ffdshow (player hangs, abort via taskmanager required):
533 by Dirk Paehl
529 by CLSID

No problems with older ffdshow:
514 by Dirk Paehl
494 by CLSID

No problems here.
ffdshow r529 by clsid
MPC
WMP 11
Haali's splitter
WinXP

[netwolf]

It seems that ffdshow doesn't even have to decode anything for the delay to show up here.

I tested with a MPEG4 file which ffdshow was set to decode, and had the dealy.
Then I tried a DivX5 file (which is decoded by the original DivX codec) with ffdshow used for postprocessing only, and the delay appeared again.

And I noticed something else: it only appear on the first file I open!
If one file is running and I start another one without closing the player (ZoomPlayer), there is no delay and everything works fine, no matter what files I play.

[clsid]

That fine plays fine here too.
- Windows 2000 SP4
- ffdshow (rev335)
- MPC (rev611-2) / WMP6.4 / BSplayer 2.12
- Haali (20061029)

[fastplayer]

MKV file posted by akapuma plays fine here using:
- MPC (rev611-2) with its internal Matroska splitter
- ffdshow build 529 (generic) by clsid
- WinXP SP2

[ilpippo80]

Please test my build!
http://www.sendspace.com/file/n8wuo5

I tried it and it still has the same problem!
btw, my pdh.dll is version 5.1.2600.2180

[LoRd_MuldeR]

First of all, thanks for your hard work on ffdshow, guys!
now, let's talk about "business":
with both ffdshow_rev529_20061113_clsid.exe and ffdshow_rev529_20061113_clsid_icl9.exe I have a slowdown of about 25 seconds (!!!) during any file opening in media player classic (haven't tried other players). I tried changing a few settings (like disabling the queue) and I tried several kind of files but the problem persisted. Reinstalling ffdshow_rev514_20061109_clsid_icl9.exe solved the problem... Anyone else has this issue?
Do you need any more details?

Yeah, same problem here :scared:
Tested with latest CLSID builds (ICL and none-ICL) and with build posted by drevil_xxl ...

ffdshow_rev514_20061109_clsid.exe does run fine!

[TheShadowRunner]

To CLSID:
Using ffdshow_rev529_20061113_clsid.exe, files take about 10 seconds to load. Using the previous version with the exact same settings, the same files load instantly.
Please let me know if you need further details about my config/hardware.
Later,

TSR

[clsid]

List of known issues in revision 547:

1) Long delay when opening files. Seems to be caused by the CPU load monitoring code added in rev524.
2) CPU Load OSD item shows "Vista not supported" error on (some) XP SP2 systems.
3) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
4) Levels (ylevels, ylevelsG, ylevelsS, ylevelsC) are not implemented correctly. Details about the correct way can be found here (http://forum.doom9.org/showthread.php?p=897854).
5) WM9 decoder passthrough is missing

Reported but unconfirmed bugs:

6) image settings -> preset autoload conditions -> "on FOURCC match" doesn't work. (reported by juskixxx) (confirmed by clsid) (haruhiko could not reproduce it)
7) Automatic preset loading doesn't seems to be working with on "number of channel match" and AC3 audio on DVD (don't know if it happens with AC3 audio in MKV, AVI or not or any other audio format). I use "3;4;5;6" in "number of channel match" so this should load with audio track with more than 2 channels but with an AC3 2 channels track this is also loaded. (reported by thuan)
8) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". I know that at least some of these encoders do work for others. My system specs: Windows 2000, AMD Athlon Thunderbird. (reported by clsid)
9) Resize filter alters colors. Details (http://forum.doom9.org/showthread.php?p=884778#post884778). (reported by Kador)

Other issues:

10) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). Funny thing however is that the files play without crash if you first play a good file and then play a 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)
11) ffdshow is not compatible with CrystalPlayer.

[Reino]

ffdshow_rev514_20061109_clsid.exe:

-Does one know when ffdshow will be able to play embedded WavPack Audio together with the WavPack Splitter?
-Also does anyone know if ffdshow will ever support quicktime audio such as TWOS,ARAW,etc?
-There seems to be something wrong when trying to play files with embedded SNOW Video (such as the "SoC_[SNOW+Vorbis].mkv" files from Liisachan). There's no video at all (and with this I mean also no ffdshow video decoder in the dsgraph).
-When trying to enhance the video images with warpsharp an ugly green line always shows up (see image below). Is this supposed to happen?
http://img139.imagevenue.com/loc361/th_34576_ffdshow_warpsharp_123_361lo.JPG (http://img139.imagevenue.com/img.php?image=34576_ffdshow_warpsharp_123_361lo.JPG)

[akapuma]

Hello,

I've a problem to play this file: http://akapuma.info/test/Sac-001.mkv (266kB)
This file contains x264 and vorbis in a mkv-container. Player: MPC, WMP6.4. Splitter: haali. WIN2000SP4I asked in the german forum (http://forum.gleitz.info/showthread.php?p=308047). Kurt reported, that's he need 10 seconds, before the movie starts (with 529 CLSID, no problems with 482). So, I repeated my test. MPC starts after 53 seconds.

Best regards

akapuma

[bob0r]

Compiling ffdshow rev 2546: gcc 4.0.3: worked

Compiling ffdshow-tryout rev 538: gcc 4.0.3:

gcc -c -mno-cygwin -mdll -fno-rtti -mthreads -pipe -D_WINGDI_ -DUCLIBCPP -D_GLIBCPP_HAVE_MBSTATE_T -D_WIN32_IE=0x0500 -mmmx -msse -mfpmath=sse -msse2 -w -DNDEBUG -UDEBUG -DFFDEBUG=0 -I. -I.. -Iuclibc++ -Ibaseclasses -I../baseclasses -IimgFilters -I../imgFilters -Implayer -I../mplayer -Isettings -I../settings -Isettings/filters -I../settings/filters -Icodecs -I../codecs -Isubtitles -I../subtitles -Iconvert -I../convert -Idialog -I../dialog -IaudioFilters -I../audioFilters -Icygwin -I../cygwin -Iffmpeg -I../ffmpeg -Iacm -I../acm -Ixiph -I../xiph -Ifilters -I../filters -Imuxers -I../muxers -I"/dx/Include" -L"/dx/MingLib" -ldx9 -I/dx/Include -L/dx/MingLib -ldx9 -O2 -march=pentium-mmx -mtune=i686 -fomit-frame-pointer -finline-functions -finline -frename-registers -fweb -funit-at-a-time -MMD -o ffdshow_all.o ffdshow_all.cpp
In file included from TcpuUsage.cpp:66,
from ffdshow_all.cpp:7:
TcpuUsage.h:3:17: error: pdh.h: No such file or directory


Instead of getting pdh.h from installing Microsoft stuff i dont want to install yet, does anyone mind putting pdh.h online, and possible more files needed?

[clsid]

-There seems to be something wrong when trying to play files with embedded SNOW Video (such as the "SoC_[SNOW+Vorbis].mkv" files from Liisachan). There's no video at all (and with this I mean also no ffdshow video decoder in the dsgraph).SNOW support has been disabled some time ago, since it was extremely buggy.

[clsid]

Instead of getting pdh.h from installing Microsoft stuff i dont want to install yet, does anyone mind putting pdh.h online, and possible more files needed?It is part of the platform SDK. I have uploaded it here (http://www.mytempdir.com/1060418) for you.

[dk75]

Hello,

I've a problem to play this file: http://akapuma.info/test/Sac-001.mkv (266kB)
This file contains x264 and vorbis in a mkv-container. Player: MPC, WMP6.4. Splitter: haali. WIN2000SP4

Problems with newer ffdshow (player hangs, abort via taskmanager required):
533 by Dirk Paehl
529 by CLSID

No problems with older ffdshow:
514 by Dirk Paehl
494 by CLSID

Best regards

akapuma

WinXP SP1
Haali 20061029 aka 1.6.336.23
ffdshow rev 529 clsid generic
ZoomPlayer Standard 5.00 b8
Plays fine except ~10s laaaag at the start

[Eragon4ever]

I think someone should take a look at this (http://forum.doom9.org/showthread.php?t=118111).

[bob0r]

@clsid: thanks
So what is the deal with SSE and SSE2?
Which version should i use (put online)

I have compiled:
ffdshow-538-gcc4.0.3-sse2-x264.nl.exe
http://mirror05.x264.nl/ffdshow/force.php?file=./ffdshow-538-gcc4.0.3-sse2-x264.nl.exe

ffdshow-538-gcc4.0.3-sse-x264.nl.exe
http://mirror05.x264.nl/ffdshow/force.php?file=./ffdshow-538-gcc4.0.3-sse-x264.nl.exe

[bob0r]

538 bug report:
BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts (http://mirror05.x264.nl/public/force.php?file=./BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts) is not being displayed 16:9, splitters use: MPC internal and Haali's

bug does not exist with:
ffdshow_rev497_20061104_clsid.exe

[kurt]

So what is the deal with SSE and SSE2?
Which version should i use (put online)
I would wait 'till the delay bug is fixed ...

[LoRd_MuldeR]

I would wait 'till the delay bug is fixed ...

Yeah, that makes it nearly unuseable. Better build rev514 for the moment...

[Inventive Software]

What codecs does the massive delay occur with clsid's 529 build? I have that build, and so far, no problems with DivX......

[LoRd_MuldeR]

What codecs does the massive delay occur with clsid's 529 build? I have that build, and so far, no problems with DivX......

I replaced it with last working build. But the delay occured with my h.264 videos (MPC + internal AVI-Splitter + ffdshow + VMR9)

[kurt]

here I get problems with xvid and x264, in avi, mkv, mp4 whatever :)

List of known issues in revision 538:
1) Long delay when opening files. Seems to be caused by the CPU load monitoring code added in rev524.



rev524: Alternative implementation of "CPU Load".
Now it can work on multiprocessor system.
It uses pdh.dll in your HDD in NT, registry hack in Win9x.
Automatic quality control of postprocessing works again.
If "CPU Load" for the heaviest processor >90% and "Queued samples"<8 ...

so it is only multiprocessor related? (I'm sitting behind a coreduo ATM)

[LoRd_MuldeR]

here I get problems with xvid and x264, in avi, mkv, mp4 whatever :)




rev524: Alternative implementation of "CPU Load".
Now it can work on multiprocessor system.
It uses pdh.dll in your HDD in NT, registry hack in Win9x.
Automatic quality control of postprocessing works again.
If "CPU Load" for the heaviest processor >90% and "Queued samples"<8 ...

so it is only multiprocessor related? (I'm sitting behind a coreduo ATM)

Nope. Got the problem on my good ol' AthlonXP (WinXP SP-2)

[Inventive Software]

But the delay occured with my h.264 videos (MPC + internal AVI-Splitter + ffdshow + VMR9)

You should know by now H.264 and AVI don't mix.

I have tested said build on MP4 files with AVC content, and no delay's occured.

[LoRd_MuldeR]

You should know by now H.264 and AVI don't mix.

I have tested said build on MP4 files with AVC content, and no delay's occured.

It always worked before since ages and it works 100% fine with rev514
And please don't start that useless AVI flamewar again now ;)

[Inventive Software]

I'm not starting the AVI flamewar, just using what works. ;)

I still think CPU detection code in the installer would prevent this issue, cause it seems to be related to certain versions of pdh.dll. Is that what you've generally found?

[ilpippo80]

I have the same delay with all the files I've tried it with: avi files, mpeg files, flv files and also using ffdshow for postprocessing only.
I doubt that it is something related to some specific format.

[bob0r]

@kurt

Yup thanks, it was more a general question.
I won't put any build online until i know its working properly.

I just need to know if SSE or SSE2 makes any difference at all.

[fastplayer]

I just need to know if SSE or SSE2 makes any difference at all.
IMHO the SSE2 build is not worth the effort.

[bob0r]

I have noticed ffdshow_rev497_20061104_clsid.exe has SSE2 .dll files (thats what you get when you just run "make")

So i guess those will do, but i am not sure if SSE2 ffdshow.ax still crashes on non SSE2 machines...

[fastplayer]

Oops, I was talking about the ffmpeg/libavcodec part which is hand-optimized for SSE1/2/3DNow etc. Compiling it with SSE1/2 switches won't have any effects on performance. In some cases it even caused instability....

[clsid]

I have noticed ffdshow_rev497_20061104_clsid.exe has SSE2 .dll files (thats what you get when you just run "make")

So i guess those will do, but i am not sure if SSE2 ffdshow.ax still crashes on non SSE2 machines...
Building libavcodec and libmplayer can be done by just running make. The binary will run fin on CPUs without SSE/SSE2. It will contain both generic and optimized code paths.

Building ffdshow.ax with GCC will generate a binary that is SSE or SSE2 dependent.

[clsid]

I still think CPU detection code in the installer would prevent this issue, cause it seems to be related to certain versions of pdh.dll. Is that what you've generally found?So far all the XP users have the same version. So I don't think this is the cause.

[Episode]

I can reproduce this bug with finnish version of xp, but not with english version.

[fastplayer]

So far all the XP users have the same version. So I don't think this is the cause.
Maybe Haruhiko - who implemented revision 524 - has a newer pdh.dll:
http://support.microsoft.com/kb/917022/en-us

[Px]

Delay also occurs with ffdshow_rev494_20061103_clsid.exe on my XP x64, but not on the first player launch, only when I opening files with already launched player. No dependence with type of launched file, no cpu usage, some weird file operations (bsplayer trying to find xvidcore.dll, avisynth.dll, skl_drv_mpg.dll (???), audxlib.dll), no strange registry keys usage. Later I try to compare registry and file logs in cases of first and second launch.....

[F_L_C]

Just installed ffdshow_rev529_20061113_clsid and have no delay opening xvid/divx avis.

Athlon XP 2400
NV 7800GS (FW 92.91)
WinXP SP2 x86 (fully patched, DX9c Oct. build)
ZP 4.51 (vmr9 renderless)
default ffdshow xvid/divx filters w/ postprocessing, denoise3D, and resize/aspect enabled

[_xxl]

Compiling ffdshow rev 2546: gcc 4.0.3: worked

Compiling ffdshow-tryout rev 538: gcc 4.0.3:

gcc -c -mno-cygwin -mdll -fno-rtti -mthreads -pipe -D_WINGDI_ -DUCLIBCPP -D_GLIBCPP_HAVE_MBSTATE_T -D_WIN32_IE=0x0500 -mmmx -msse -mfpmath=sse -msse2 -w -DNDEBUG -UDEBUG -DFFDEBUG=0 -I. -I.. -Iuclibc++ -Ibaseclasses -I../baseclasses -IimgFilters -I../imgFilters -Implayer -I../mplayer -Isettings -I../settings -Isettings/filters -I../settings/filters -Icodecs -I../codecs -Isubtitles -I../subtitles -Iconvert -I../convert -Idialog -I../dialog -IaudioFilters -I../audioFilters -Icygwin -I../cygwin -Iffmpeg -I../ffmpeg -Iacm -I../acm -Ixiph -I../xiph -Ifilters -I../filters -Imuxers -I../muxers -I"/dx/Include" -L"/dx/MingLib" -ldx9 -I/dx/Include -L/dx/MingLib -ldx9 -O2 -march=pentium-mmx -mtune=i686 -fomit-frame-pointer -finline-functions -finline -frename-registers -fweb -funit-at-a-time -MMD -o ffdshow_all.o ffdshow_all.cpp
In file included from TcpuUsage.cpp:66,
from ffdshow_all.cpp:7:
TcpuUsage.h:3:17: error: pdh.h: No such file or directory


Instead of getting pdh.h from installing Microsoft stuff i dont want to install yet, does anyone mind putting pdh.h online, and possible more files needed?

You need pdh.h and libpdh.a.

[_xxl]

List of known issues in revision 538:

6) ffdshow doesn't work with CrystalPlayer 1.97

[_xxl]

IMHO the SSE2 build is not worth the effort.
Why?Just search "__SSE2__" in ffdshow.

[haruhiko_yamagata]

I still cannot reproduce the delay problem.

To summarize,

The version of pdh.dll does not matter.
When it is delayed, "CPU Load" always shows the error "does not work in vista..." (Is this correct?)

I think the problem is caused by the failure of loading pdh.dll.
If ffdshow try to load windows\system32\pdh.dll and fail, then it serches the environmental variable "PATH". It takes the time.
I'll try explicit full path. But why does loading pdh.dll fail?

[haruhiko_yamagata]

You need pdh.h and libpdh.a.
libpdh.a is not necessary. I think I can remove dependency to pdh.h.

[baka]

6) ffdshow doesn't work with CrystalPlayer 1.97

i second that :devil:

[Peuj]

I think the problem is caused by the failure of loading pdh.dll.
If ffdshow try to load windows\system32\pdh.dll and fail, then it serches the environmental variable "PATH". It takes the time.
I'll try explicit full path. But why does loading pdh.dll fail?

Maybe people who have the problem could use ProcessExplorer (http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx)
(freeware tool, nothing to install simply execute the exe)
Menu "Find" -> "Find Handle or DLL..."

To confirm the dll is loaded or not during playback.

[Peuj]

List of known issues in revision 538:

Maybe you could had this to the list http://forum.doom9.org/showthread.php?t=118111

Thanks

[_xxl]

6)CrystalPlayer 1.97 doesn't work with ffdshow!
CrystalPlayer is protected by Aspack 2.12b, so I CAN'T enable debug.I'll blacklist Crystal.exe.

[_xxl]

Maybe you could had this to the list http://forum.doom9.org/showthread.php?t=118111
Thanks
Yes, libdts seems to be broken for 44100 Hz and 1024 samples.
EDIT:
Same problem with Gabest's MpaDecFilter Filter.

[baka]

6)CrystalPlayer 1.97 doesn't work with ffdshow!
CrystalPlayer is protected by Aspack 2.12b, so I CAN'T enable debug.I'll blacklist Crystal.exe.

ye, always the best solution :(

why not to contact crystal player team? :P

[G_M_C]

Turn on postprocessing......

Yeah, but it is still pixellated on the edges, XviD shows well-defined edges. When the decoding of H264 by ffdshow produces ruff edges, i cant use it for my transcodes ...

[KoD]

CrystalPlayer also doesn't load VSfilter so it can't display subtitles. It has its own way of building filter graphs and forcing things that is not compatible with some filters. Really something that needs to be corrected by the CrystalPlayer devs and not anyone else.

G_M_C : on the ffdshow video decoder config -> Decoder options -> switch IDCT to auto and see if you still have that problem. You could also play around with Error concealment option and Error resilience.

[_xxl]

Maybe people who have the problem could use ProcessExplorer (http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx)
(freeware tool, nothing to install simply execute the exe)
Menu "Find" -> "Find Handle or DLL..."
To confirm the dll is loaded or not during playback.
http://i9.tinypic.com/43cqalh.jpg

[baka]

CrystalPlayer also doesn't load VSfilter so it can't display subtitles. It has its own way of building filter graphs and forcing things that is not compatible with some filters. Really something that needs to be corrected by the CrystalPlayer devs and not anyone else.

so can we do something in crystal player to use ffdshow normally? some option or whatever?

[KoD]

Baka, short answer: no. Long answer: CrystalPlayer's code restricts the way a rendering graph is built so nothing can be done. Take it with its developers.

[_xxl]

so can we do something in crystal player to use ffdshow normally? some option or whatever?
No.It doesn't work with ffdshow since rev8.Other media players are working so the problem is in CrystalPlayer.

[netwolf]

Delay also occurs with ffdshow_rev494_20061103_clsid.exe on my XP x64, but not on the first player launch, only when I opening files with already launched player. No dependence with type of launched file, no cpu usage, some weird file operations (bsplayer trying to find xvidcore.dll, avisynth.dll, skl_drv_mpg.dll (???), audxlib.dll), no strange registry keys usage. Later I try to compare registry and file logs in cases of first and second launch.....
I *sometimes* have the same problem, or at least a very similar one: when playing a file and opening another one, the second file does not play properly, but I only see the picture for a second (or less) and the player stops.
Restarting the file gives the same result.

When I close the player (ZoomPlayer) and open the same file again, it plays without problems.

WRT the delay problem: here it doesn't seem to be busy finding a system file. There is no HDD activity during the delay, it seems to be just sitting and waiting...

[fastplayer]

Why?Just search "__SSE2__" in ffdshow.
I was referring to the ffmpeg/libavcodec part. Benchmarks showed no improvements when using various compiler switches. In fact videomixer's generic MMX build turned out to be faster than any of those "optimized" builds.
As for ffdshow itself, I think you can answer the question better than me :)

[Inventive Software]

In 543 it looks like a GCC bug. Take it up with GCC developers, cause the fatal error in that was an "internal compiler error".

542: Coding issues. Something for the team to look at I think.

@bob0r: Have you tried compiling with GCC 3.4.6?

[_xxl]

It works for me.Tested with mingw GCC 4.0.3.
http://img149.imagevenue.com/loc502/th_89905_Capture_122_502lo.jpg (http://img149.imagevenue.com/img.php?image=89905_Capture_122_502lo.jpg)

[bob0r]

*red face* for not going to gcc 4.0.3

[ilpippo80]

ProcessExplorer shows that MediaPlayerClassic loaded pdh.dll.
Watching MediaPlayerClassic activity in ProcessMonitor (also available from sysinternals) shows that pdh.dll is successfully found and opened.
Haruiko and others, if you need my ProcessMonitor log just ask!
Btw, I have Italian version of XP.

[Reino]

ffdshow_rev514_20061109_clsid.exe:

-Does one know when ffdshow will be able to play embedded WavPack Audio together with the WavPack Splitter?
-Also does anyone know if ffdshow will ever support quicktime audio such as TWOS,ARAW,etc?
-When trying to enhance the video images with warpsharp an ugly green line always shows up (see image below). Is this supposed to happen?
http://img139.imagevenue.com/loc361/th_34576_ffdshow_warpsharp_123_361lo.JPG (http://img139.imagevenue.com/img.php?image=34576_ffdshow_warpsharp_123_361lo.JPG)

*bump*

[foxyshadis]

Yes, marcfd's awarpsharp is hideously buggy - using luma only mostly works, but chroma modes bug up all the time. Normal warpsharp shouldn't though.

By WavPack w/ WavPack splitter, you mean ffdshow decoding from .wv files, as opposed to inside a video file? Does it currently not work? I don't have anything to test against. Hybrid files definitely won't work though.

As for quicktime audio, we're pretty dependant on 3rd party libraries for that type of thing. If ffmpeg implemented it, we'll add it, or if an easily integratable open source library was found for them.

[G_M_C]

[...]
G_M_C : on the ffdshow video decoder config -> Decoder options -> switch IDCT to auto and see if you still have that problem. You could also play around with Error concealment option and Error resilience.

Thx, i'll give it "a whirl" as they say, on my next project :)

[Reino]

Yes, marcfd's awarpsharp is hideously buggy - using luma only mostly works, but chroma modes bug up all the time. Normal warpsharp shouldn't though.

By WavPack w/ WavPack splitter, you mean ffdshow decoding from .wv files, as opposed to inside a video file? Does it currently not work? I don't have anything to test against. Hybrid files definitely won't work though.

As for quicktime audio, we're pretty dependant on 3rd party libraries for that type of thing. If ffmpeg implemented it, we'll add it, or if an easily integratable open source library was found for them.

Thanks for your answer foxyshadis.
I'm talking about awarpsharp indeed, but it doesn't make any difference how you setup the options that go with it. I have set Chroma Mode to none, Blur Mode to fast 1-pass, Depth to 16, Threshold to 0.5 and Blur to 2, but the green line always apears no matter what.
Let's hope this will be fixed soon.

As for WavPack: I'm talking about hybrid files (like the one mentioned in this thread: SoC_[XviD+WavPack+MP3]-007.mkv). WV-files play perfectly.

I would be great to be able to play quicktime-files without the need of QuickTime Alternative or VLC Media Player.

[LoRd_MuldeR]

Hey, now I can combine ffdshow with Haali Renderer an get an even longer delay :D
(BTW: rev548 didn't change anything on the problem)

[Px]

I still cannot reproduce the delay problem.

To summarize,

The version of pdh.dll does not matter.
When it is delayed, "CPU Load" always shows the error "does not work in vista..." (Is this correct?)

I think the problem is caused by the failure of loading pdh.dll.
If ffdshow try to load windows\system32\pdh.dll and fail, then it serches the environmental variable "PATH". It takes the time.
I'll try explicit full path. But why does loading pdh.dll fail?
It's not connected with pdh.dll, on rev_494 I have delays in bsp on reopen, and both ffdshow and player don't search for this file. Moreover, I installed ffdshow_rev548_20061115_clsid.exe, there is no delay on first launch, on second launch bsp searching for pdh.dll after delay....

[Px]

Yeah, but it is still pixellated on the edges, XviD shows well-defined edges. When the decoding of H264 by ffdshow produces ruff edges, i cant use it for my transcodes ...
Turn on Fast SPP Deblock

[Px]

There is no HDD activity during the delay, it seems to be just sitting and waiting...
Confirms, no other activity during the delay, watched by filemon....

[LoRd_MuldeR]

FFdshow-Tryouts-20061115-rev551.exe doesn't show the delay problem :)

// EDIT

But know MPC disappears without error message when I double-click (some) files in Explorer.
Doesn't happen when I open the problematic files via Drag-and-Drop.

Anybody else with that problem ???

[Blight]

Argh... ignore my previous post, it's not an ffdshow issue.

Keep up the good work.

[LoRd_MuldeR]

When I turn on OSD (and only then), I still get a huge delay plus this:
http://img292.imageshack.us/img292/1936/cpuloadgl2.jpg
(running on WinXP SP-2 as Admin)

[akapuma]

FFdshow-Tryouts-20061115-rev551.exe doesn't show the delay problem Confirmed.

Thank you for fixing the problem.

Best regards

akapuma

Edit:
But same problem with CPU-load is on OSD...

[foxyshadis]

As for WavPack: I'm talking about hybrid files (like the one mentioned in this thread: SoC_[XviD+WavPack+MP3]-007.mkv). WV-files play perfectly.
That's ffmpeg's domain; I believe liisachan reported it, but no work's been done on it in the last 4 weeks.

aWarpSharp has no source code, never has. It's a precompiled binary that Milan included. Short of disassembling and rewriting from scratch, like the existing "original ffdshow warpsharp", there's no way to ever fix anything.

[Px]

Hmmmm, uninstalled ffdshow_rev548_20061115_clsid.exe, installed back ffdshow_rev494_20061115_clsid.exe, and delay disappeared.......

[ilpippo80]

FFdshow-Tryouts-20061115-rev551.exe doesn't show the delay problem :)

Confirmed for me too.
no more delay on startup. still delay when turning on osd with cpu load and same message "does not work on vista"...

[clsid]

So it seems that loading phd.dll only from system32 doesn't make a difference. That workaround can then be removed.

Perhaps the following updated version of phd.dll fixes the problem?
http://support.microsoft.com/kb/917022/en-us

[Episode]

There doesn't seem to be any way to download that hotfix :(

[Liisachan]

That's ffmpeg's domain; I believe liisachan reported it, but no work's been done on it in the last 4 weeks.

clsid is the one who reported the problem (http://forum.doom9.org/showthread.php?p=880207#post880207) on September 26, 2006, also saying "Wavpack crashes". Currently, lossy/hybrid Wavpack does not crash, though you get no sound, so I guess it's better than it was. "Normal" lossless Wavpack does play too. The problem is, so-called Wavpack Lossy (lossy wv without wvc) and Wavpack Hybrid (lossy wv with wvc) do not play.

Wavpack is currently v4.3x and v4.4 is on its way, which will be slightly incompatible with 4.3x, so I'd think devs can wait until 4.4 is officially out.

[Egh]

aWarpSharp has no source code, never has. It's a precompiled binary that Milan included. Short of disassembling and rewriting from scratch, like the existing "original ffdshow warpsharp", there's no way to ever fix anything.

Suggestion: then maybe it should be removed completely?

BTW, what are other precompiled binaries used in ffdshow for which source is not available?

Anyhow, anyone who needs specifically awarpsharp, can use avisynth filter, which doesn't produce greenline, at least here.

Also, theoretically one can ask the developer for the source code, so reverse engineering is not the only remaining option ^^

[haruhiko_yamagata]

I gave up using pdh.dll and restored previous version of TcpuUsage.
I thought it was not working, but I was wrong. It was basically OK, some device was necessary for the caller's side. Now it works for multiprocessor system too.

Thank you for many reports and backup.
My binary (http://sourceforge.net/project/showfiles.php?group_id=173941) is available for rev555.

[fastplayer]

Hehe, I'd really like to know why it worked for some and for others not. But as long as it works... :D
Thanks for your persistence on this matter! :)

[LoRd_MuldeR]

I gave up using pdh.dll and restored previous version of TcpuUsage.
I thought it was not working, but I was wrong. It was basically OK, some device was necessary for the caller's side. Now it works for multiprocessor system too.

Thank you for many reports and backup.
My binary (http://sourceforge.net/project/showfiles.php?group_id=173941) is available for rev555.

Thank you! New build works fine, even with OSD and "CPU Load" enabled :)

[G_M_C]

Turn on Fast SPP Deblock

Nothing seems to help as yet. Will keep trying though, by downloading & installing the newest version this weekend and starting again.

But i'm considerating going over to CoreAVC if it works better with my system and AviSynth's DirectShowSource().

But before i do that, i wanted to try out the Open Source possibillities first.

[lasuocera]

Thank you! New build works fine, even with OSD and "CPU Load" enabled :)

It's ok for me too!

[clsid]

@ G_M_C: did you perhaps enable any of the "skip deblocking ..." options in ffdshow? Those lower the visual quality (and increase performance).

[Jeremy Duncan]

The download links at sourceforge are down.

http://superbwest.dl.sf.net/sourceforge/ffdshow-tryout/ffdshow_rev555_20061116_Q.exe

[_xxl]

Try this:
http://switch.dl.sourceforge.net/sourceforge/ffdshow-tryout/ffdshow_rev555_20061116_Q.exe
http://switch.dl.sourceforge.net/sourceforge/ffdshow-tryout/FFdshow-Tryouts-20061116-rev555.exe

[Jeremy Duncan]

Those links work. Thanks. :)

Edit.
http://prdownloads.sourceforge.net/sourceforge/ffdshow-tryout/ffdshow_rev551_20061115_clsid.exe

"Could not read file.

Go back. /home/ftp/pub/sourceforge//s/so/sourceforge/ffdshow-tryout/ffdshow_rev551_20061115_clsid.exe
Nov 16, 2006 10:33"

[LoRd_MuldeR]

you should use rev555, not rev551

[Jeremy Duncan]

you should use rev555, not rev551

I am. drevil_xxl linked to clsid_551 and the link didn't work.

[clsid]

Fresh builds (regular and icl9) are now on sourceforge. Rev557.

[F_L_C]

clsid has rev557 at sf now. I have an Athlon XP 2400 mobile and have always used the generic build because clsid seems to usually update that build first. Should I stick w/ them or use the generic build ICL 9.1 below those?

[LoRd_MuldeR]

Fresh builds (regular and icl9) are now on sourceforge. Rev557.

:thanks:

[Inventive Software]

Any chance of a mammoth SVN changelog? :D

[Egh]

Any chance of a mammoth SVN changelog? :D

what's wrong with http://svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log ? :)

Though actually most of the revisions have very vague description and it's hard to understand w/o looking in the code itself what actually was corrected :)

[Inventive Software]

what's wrong with http://svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log ? :)

Though actually most of the revisions have very vague description and it's hard to understand w/o looking in the code itself what actually was corrected :)

Because I know zilch about SVN, so it's easier for me to ask. ;) I'll bookmark that and keep a sharp eye, so I'll know what's going on.

[Egh]

clsid has rev557 at sf now. I have an Athlon XP 2400 mobile and have always used the generic build because clsid seems to usually update that build first. Should I stick w/ them or use the generic build ICL 9.1 below those?

As a rule you need to test on your particular system what's faster.
Generally speaking the difference is minimal.

Comparison:
(system is 3800+ A64 overclocked to 2.7Ghz, NVidia 7600GS overclocked). Output samples are disabled for the test, colorspace output -- YV12.

Input file -- 1280*720 h264 high-profile, encoded with nearly maximum possible quality settings.

Null renderer performance:

FFDShow from 4th Oct Generic
User: 18s, kernel: 0s, total: 18s, real: 19s, fps: 63.9, dfps: 62.6
ffdshow 557 generic
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 69.3, dfps: 68.3
ffdshow 557 ICL9
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 68.6, dfps: 67.3


VMR9 performance:

FFDShow from 4th Oct Generic
User: 19s, kernel: 1s, total: 20s, real: 23s, fps: 58.4, dfps: 50.0
ffdshow 557 generic
User: 18s, kernel: 1s, total: 19s, real: 22s, fps: 61.7, dfps: 52.8
ffdshow 557 ICL9
User: 17s, kernel: 1s, total: 18s, real: 22s, fps: 63.8, dfps: 52.4


So ffdshow does decode h264 faster now than even a month ago, though actual speed increase is about 5%. Unfortunately still seriously below CoreAVC performance ...

ICL9 here (i.e. on this system, as I told above the results might actually vary on different boxes) not really much faster than generic, in fact ICL9 is somewhat slower.

@ Inventive Software:
Because I know zilch about SVN, so it's easier for me to ask. I'll bookmark that and keep a sharp eye, so I'll know what's going on. Not that I much follow source code itself, but that svn revisions log I bookmarked ages ago :)

[clsid]

The ICL9 build can be useful if you make use of the processing filters in ffdshow. For pure decoding speed it makes no difference as Egh showed.

[SeeMoreDigital]

Wow guys....

I've just installed "ffdshow_rev551_20061115_clsid.exe" and have to say playback of MPEG-4 AVC (even MBAFF and PAFF) is much improved...

Very well done (and nice set-up GUI install clsid) :)


Cheers all

[haruhiko_yamagata]

4) Levels (ylevels, ylevelsG, ylevelsS, ylevelsC) are not implemented correctly. Details about the correct way can be found here (http://forum.doom9.org/showthread.php?p=897854).

I think it's implemented properly.
Please set "Gamma correction" 1.50 and see.

[G_M_C]

@ G_M_C: did you perhaps enable any of the "skip deblocking ..." options in ffdshow? Those lower the visual quality (and increase performance).

Nope, my goal is quality and disabling the "inline-beblocking" stuff in H264 would not be wise ;)

But as i said; I'll be starting again this weekend. It might even be something alse on my system that's bugging.

For instance: i've got a DivX 6.x codec dat want to butt in every time I start a XviD. It then gets disabled, and XviD takes over. This is kinda weard, because i'm shure ive uninstalled DivX 6.x a while ago, so there defenately is something wrong. I might even reformat my whole system, and setup all video-stuff again (but i dread that option, because its so much work; Installing everything from DVD-RB to CCE, authoring stuff AC3-tools Soundforge ... just too much to think about :/ )

[haruhiko_yamagata]

7) Automatic preset loading doesn't seems to be working with on "number of channel match" and AC3 audio on DVD (don't know if it happens with AC3 audio in MKV, AVI or not or any other audio format). I use "3;4;5;6" in "number of channel match" so this should load with audio track with more than 2 channels but with an AC3 2 channels track this is also loaded. (reported by thuan)
I can't reproduce this.
Please see if it is the same with other DVDs.
If the first track is 2ch and main track is 6ch, 2ch preset setting is loaded.

[foxyshadis]

Suggestion: then maybe it should be removed completely?

BTW, what are other precompiled binaries used in ffdshow for which source is not available?

Anyhow, anyone who needs specifically awarpsharp, can use avisynth filter, which doesn't produce greenline, at least here.

Also, theoretically one can ask the developer for the source code, so reverse engineering is not the only remaining option ^^

MarcFD's long gone, unfortunately, and was never inclined to release his sources at all. That's his choice, but you might be right about removing it. aWarpSharp is the only one, I believe.

That does give me an idea though, to take a few filters out of the main compiling and have a separate project for them, including just .obj if necessary, because dang, they take forever to build. =p The ones that aren't affected by internal ffdshow changes.

G_M_C, do you have any dregs of codec packs on the system? It might be worth getting radlight filter manager (or zoomplayer's or whatever) and check out where that's coming from.

[clsid]

List of known issues in revision 562:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Levels (ylevels, ylevelsG, ylevelsS, ylevelsC) are not implemented correctly? Details about the correct way can be found here (http://forum.doom9.org/showthread.php?p=897854).
3) WM9 decoder passthrough is missing

Reported but unconfirmed bugs:

4) Automatic preset loading doesn't seems to be working with on "number of channel match" and AC3 audio on DVD (don't know if it happens with AC3 audio in MKV, AVI or not or any other audio format). I use "3;4;5;6" in "number of channel match" so this should load with audio track with more than 2 channels but with an AC3 2 channels track this is also loaded. (reported by thuan)
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". I know that at least some of these encoders do work for others. My system specs: Windows 2000, AMD Athlon Thunderbird. (reported by clsid)
6) Resize filter alters colors. Details (http://forum.doom9.org/showthread.php?p=884778#post884778). (reported by Kador)

Other issues:

7) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). Funny thing however is that the files play without crash if you first play a good file and then play a 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)
8) ffdshow is not compatible with CrystalPlayer.

[G_M_C]

[...]

G_M_C, do you have any dregs of codec packs on the system? It might be worth getting radlight filter manager (or zoomplayer's or whatever) and check out where that's coming from.

Dont really remember, but afaik i've allways tried to avoid any form of Codec-Pack, and have installed codecs sererately (as needed). But its very possible I messed up sometime ;)

But thx for the advice; Ill see if Radlight filtermanager produces usefull results. The most recent version is a couple of years old, but it worth a try :)

[F_L_C]

The ICL9 build can be useful if you make use of the processing filters in ffdshow. For pure decoding speed it makes no difference as Egh showed.

I do use the postprocessing, blur&noise reduction (denoise3D), and resize/aspect filters for xvid/divx AVIs. All right, I'll use the ICL9 builds from now on. And thanks for the numbers Egh.

[_ck_]

For some reason both these new builds totally hose my use of ffvdub within virtualdub. I can load the filter but then virtualdub crashes immediate if I try to move through the video at all.

[haruhiko_yamagata]

For some reason both these new builds totally hose my use of ffvdub within virtualdub. I can load the filter but then virtualdub crashes immediate if I try to move through the video at all.
It works for me. I use VirtualDub 1.6.15.

[_ck_]

It works for me. I use VirtualDub 1.6.15.

weird - maybe I have some other conflict - as soon as I roll back the error goes away...

[Jeremy Duncan]

I think it's implemented properly.
Please set "Gamma correction" 1.50 and see.

YLevels is fine.
It's YlevelsG, YlevelsS, YlevelsC that is made wrong and is corrected here. (http://forum.doom9.org/showthread.php?p=897854)
Didée pointed this out.

A different request now.
Mr Yamagata rgb2rgb.c has been updated from version 19211
Could you update to the latest version.
Link (http://svn.mplayerhq.hu/mplayer/trunk/libswscale/rgb2rgb.c?view=log)
And may I also ask that Lanczos resizing be multithreaded.

:thanks:

[haruhiko_yamagata]

YLevels is fine.
It's YlevelsG, YlevelsS, YlevelsC that is made wrong and is corrected here. (http://forum.doom9.org/showthread.php?p=897854)
Didée pointed this out.
Oh yes, I understood.

A different request now.
Mr Yamagata rgb2rgb.c has been updated from version 19211
Could you update to the latest version.
Link (http://svn.mplayerhq.hu/mplayer/trunk/libswscale/rgb2rgb.c?view=log)
And may I also ask that Lanczos resizing be multithreaded.

:thanks:
rgb2rgb.c : I'll keep it in mind (though I can't do soon).

Lanczos resizing is multithreaded. Without any configuraton, it is always processed by multithread if you have multiple CPU cores(except for Pentium4HT).

[pandy]

Seems that on ffdshow "Levels" is partialy broken - when i set Posterize less than 255 there is no Y (luma) - video looks like Y disabled, only chroma channels are on.
Few latest builds have this issue, at this moment i use ffdshow_rev568_20061119_clsid.exe - i believe that in the past this feature was fully functionall...

[haruhiko_yamagata]

Seems that on ffdshow "Levels" is partialy broken - when i set Posterize less than 255 there is no Y (luma) - video looks like Y disabled, only chroma channels are on.
Few latest builds have this issue, at this moment i use ffdshow_rev568_20061119_clsid.exe - i believe that in the past this feature was fully functionall...
It works for me.

[Jeremy Duncan]

Is there some special meathod needed to use Didée's Ylevels ?
I've set it to affect only the right half, and using both a movie and a calibration disk I saw no change using any of Didée's Ylevels.

Am I supposed to change the input and output or something ?

I dunno ? :D

[haruhiko_yamagata]

Is there some special meathod needed to use Didée's Ylevels ?
I've set it to affect only the right half, and using both a movie and a calibration disk I saw no change using any of Didée's Ylevels.

Am I supposed to change the input and output or something ?

I dunno ? :D
Set "Gamma correction".

[pandy]

It works for me.

For me not...

I setting level on 16 ie 4 bit quantization, before posterization i add noise and... i receive only chroma channels, tested on various materials - but sometimes if other filters are turned on then turned off, some options are switched there is ok - so very weird behaviour of the ffdshow.

btw there is the same as earlier problem with MPEG 1 and 2 decoding, libmpeg works ok, libavcodec not - problem looks usual (miscoloroed macroblocks)

[haruhiko_yamagata]

For me not...

I setting level on 16 ie 4 bit quantization, before posterization i add noise and... i receive only chroma channels, tested on various materials - but sometimes if other filters are turned on then turned off, some options are switched there is ok - so very weird behaviour of the ffdshow.

btw there is the same as earlier problem with MPEG 1 and 2 decoding, libmpeg works ok, libavcodec not - problem looks usual (miscoloroed macroblocks)
I can't reproduce yet.
I'm sorry but I can't understand what you mean. Please explain in a way easy to understand.

[_xxl]

I have compiled ffdshow with mingw gcc-core-4.0-20061116.
http://www.mytempdir.com/1076752

[LoRd_MuldeR]

I have compiled ffdshow with mingw gcc-core-4.0-20061116.
http://www.mytempdir.com/1076752

Seems to work for me, but what is the difference?

[Video Dude]

Is anyone else having trouble getting the post processing to work for DV (dvsd) and ffavisynth?

Even with the settings at the max, I am not seeing any effect. All the same for mplayer, Nic, and SPP. To compare, I select to process only right side and there is no difference from the left. Automatic quality control is turned off.

All the other filters work great.
In fact, the post processing works for the h.264 and flv1 clips I tested.

I have tried the builds clsid 551-568 and drevil 555.
I had upgraded from the Oct 2004 build on the sourceforge page. Post processing works for me using this build on DV and ffavisynth.

[foxyshadis]

You're right, it's not enabled for DV. I'll fix the codec list.

PP shouldn't work for h.264, are you sure it's not raw video getting decoded elsewhere, or the built-in inloop?

I wonder if I should remove all of the h26*, since they can all use inloop. SVQ3 as well. hrm. Are current SVQ videos blocky, or does inloop work properly on them?

[Video Dude]

My mistake. It was not a h.264 clip.

[haruhiko_yamagata]

It reads the setting from control panel and overwrites current setting only once for the first time.

This may be inconvinient for people around here.
For beginers, it is better to overwrite IMO. If the user have only stereo speakers and the stream has center speaker part, the most important part is lost. Beginers don't know why.

Inno setup script load ffSpkCfg.dll and gets the setting of the control panel for the first time.
From the next time, setup reads from ffdshow registry and do not overwrite the setting.

ffSpkCfg.dll depends on dsound.dll, which is a part of directX 8. Loading ffSpkCfg.dll may fail and in that case, fail over 2ch stereo.

[haruhiko_yamagata]

ffdshow and ffmpeg is replaced by "censored" in our PHP forum (http://ffdshow-tryout.sourceforge.net/phpBB2/viewforum.php?f=3). Not only bugs forum, it is seen in all the forums of PHPBB2.
Are we being attacked? or is it a simple bug?
What can we do?

[_xxl]

ffdshow and ffmpeg is replaced by "censored" in our PHP forum (http://ffdshow-tryout.sourceforge.net/phpBB2/viewforum.php?f=3). Not only bugs forum, it is seen in all the forums of PHPBB2.
Are we being attacked? or is it a simple bug?
What can we do?
Fixed.

[haruhiko_yamagata]

Fixed.
OK, I'm relieved.

[fastplayer]

If the user have only stereo speakers and the stream has center speaker part, the most important part is lost. Beginers don't know why.
I don't understand. How has speaker setup been handled until now? I thought multichannel sound was properly downmixed by ffdshow. Or not?

[haruhiko_yamagata]

I don't understand. How has speaker setup been handled until now? I thought multichannel sound was properly downmixed by ffdshow. Or not?
No, it was not. By default, "Mixer" was disabled. If "Mixer" is disabled and one does not have center speaker, voice and sound that should come from center speaker is lost, as well as that of surrund speaker. At least it is so for DVD 5.1ch AC3.

[fastplayer]

OK, so you implemented it that way that it automatically sets the right speaker count in the "Mixer" settings.
I didn't notice this was a problem because the ffdshow installer had "Mixer" enabled and set to 2.0 stereo by default (in the clsid builds).

Edit: Just installed clsid's latest build and ffdshow correctly recognized my speaker setup. Only thing left to do is enabling LFE (2.1 speakers).
:thanks: for another user-friendly feature!

[cc979]

i've compiled mingw gcc 4.2, 4.3 if any one wants to try ffdshow with them

http://forum.doom9.org/showthread.php?p=903850#post903850

[JarrettH]

This levels bug that was corrected...should I see any difference after I update my ffdshow?

[popper]

As a rule you need to test on your particular system what's faster.
Generally speaking the difference is minimal.

Comparison:
(system is 3800+ A64 overclocked to 2.7Ghz, NVidia 7600GS overclocked). Output samples are disabled for the test, colorspace output -- YV12.

Input file -- 1280*720 h264 high-profile, encoded with nearly maximum possible quality settings.

Null renderer performance:


VMR9 performance:


So ffdshow does decode h264 faster now than even a month ago, though actual speed increase is about 5%. Unfortunately still seriously below CoreAVC performance ...

ICL9 here (i.e. on this system, as I told above the results might actually vary on different boxes) not really much faster than generic, in fact ICL9 is somewhat slower.

@ Inventive Software:
Not that I much follow source code itself, but that svn revisions log I bookmarked ages ago :)

im wondering, has someone reading, got a PS3 and installed this on linux there to benchmark?, it would be interesting to see how a basic install would compare for encoding/decoding the same HD avc samples....
----------------------------------------------------------------------
Playstation 3 Linux kernel patches and documentation mirror
http://www.powerdeveloper.org/playstation.php

[Dark Eiri]

Actually, the PS3 can run AVC and MPEG-4 ASP directly, no need for ffdshow there.

[Lys]

What do you use to benchmark? The one like Egh's.

On an unrelated note, I can't notice the difference between postprocessing, even with everything on max. What is processing strength meant to do?

[fastplayer]

On an unrelated note, I can't notice the difference between postprocessing, even with everything on max. What is processing strength meant to do?
Post-processing does not work with all codecs like H.264 for example.
AFAIK this is the current list of PP-supported codecs (right side):
http://svn.sourceforge.net/viewvc/ffdshow-tryout/src/imgFilters/TimgFilterPostproc.cpp?r1=581&r2=580&pathrev=581

[clsid]

TimeCodec (http://haali.cs.msu.ru/mkv/timeCodec.exe). You'll need Haali Media Splitter installed too.

[Lys]

Thanks for timecodec. What is the difference between dfps and fps? (null renderer)

I use ordinary xvid files. Can someone highlight what I should be looking for? Or is it only effective for poor quality videos?

[clsid]

Timecodec benchmarks decoding speed. It has nothing to do with quality.

I think dfps is the framerate when taking into account the overhead not directly related to the decoder itself, for example colorspace conversion.

[Lys]

The quality wasn't about the benchmark, I was just wondering what postprocessing is meant to do, versus having it disabled. I truly cannot notice any difference.

[clsid]

If you don't see any difference, then leave it disabled. On sources with low quality it should give a more visual difference.

[LoRd_MuldeR]

The quality wasn't about the benchmark, I was just wondering what postprocessing is meant to do, versus having it disabled. I truly cannot notice any difference.

Post-Processing is intended to smooth-out "block" artifact in heavy-compressed videos. Instead of a "blocky" video, you will get a "washed" video. You have to choose what you prefer. For high-quality videos (videos that don't look blocky), post-prcessing has to be disabled anyway!

[Px]

Timecodec benchmarks decoding speed. It has nothing to do with quality.

I think dfps is the framerate when taking into account the overhead not directly related to the decoder itself, for example colorspace conversion.
fps - calculated by codec fps
dfps - displayed fps....

[Blight]

Hi,
I'm writing a tool to help locate and automate installation of new ffdshow versions.

I'm detecting which version the user currently has installed by looking at the version info of "ffdshow.ax".

The problem I'm facing, is that the version in "ffdshow.ax" seems to be inconsistant.

ffdshow_rev551_20061115_clsid.exe = v1.0.2.2017
FFdshow-Tryouts-20061116-rev555-sse2.exe = v1.0.2.1999

There does seem to be some consistancy if you don't mix and match optimized versions. But wouldn't putting the revision number as the version number make more sense?

Example:
ffdshow_rev551_20061115_clsid.exe = v1.0.2.551
FFdshow-Tryouts-20061116-rev555-sse2.exe = v1.0.2.555

I know it's a small issue, but it will help with automation.

[LoRd_MuldeR]

@Blight
I think you should check for the build date.
No idea how to 'read' it from ffdshow.ax, but you can see it on the 'about' page. At least this seems to be consistant since ages.
Even if they change the version number for future builds, it wouldn't help you on detecting old ones...
Maybe you just read the "last changed" date from File System ???

[GmorG McRoth]

I'm not sure if this already known issue but, with subtitles "fast rendering" roman letters become Japanese (maybe Chinese) like so: http://img139.imagevenue.com/loc301/th_75817_snapshot20061125182916_122_301lo.jpg (http://img139.imagevenue.com/img.php?image=75817_snapshot20061125182916_122_301lo.jpg)
without that option checked everything is normal..
ps. tested with build ffdshow_rev584_20061123_clsid.exe

[foxyshadis]

Yeah, it does. Bizarre, that. Couldn't find an immediate cause after some digging through the subtitle code, so I'll come back to it later if no one else does.

[Liisachan]

In Unicode, basically Chinese, Korean, and Japanese are the same one thing (so called CJK). I checked that pic, and assume that this is when UTF-8 strings are rendered as MBCS. For each CJK code point, UTF-8 uses 3 bytes. If it is mistakenly treated as double-byte, you'd typically see a weird <2-byte Char>+<1-byte ASCII>...sequence. In that pic, a Chinese char is a 2-byte one and '?' in the square is one-byte ASCII (probably a control char which is not printable). That's what I guess.

The question is, why is Win Latin converted to a weird CJK string in UTF-8 here? I'd think that the problem is not the renderer, but something like MultiByteToWideChar. For instance, when converting from UTF-8 to 16, if the 2nd param of MultiByteToWideChar is MB_ERR_INVALID_CHARS, the result could be a mess. But even so, if the input is US-ASCII, nothing bad shouldn't happen...

[foxyshadis]

My guess is that it's just rendering random garbage, but I although I have a few leads (there's a slightly different code path with fast than without), nothing seemed wrong. Once I run it with a debugger it might jump right out. (Since I'm working on integrating gcc 4.3, getting stuff compiled is a bit difficult atm.) Thanks for the heads up, I'll see if I find anything like that in the code.

[pandy]

I can't reproduce yet.
I'm sorry but I can't understand what you mean. Please explain in a way easy to understand.

Ok, seems that problem is in other place - when i use preset of ffdshow in avisynth then posterization works ok, used directly ie when i play movie in mpc not work. Other problem are that sometimes played video are flipped...

This weird behaviour is probably done by conflict between elecard and mainconcept filters... :devil: :angry: :mad:

seems that my windows need to be fully reinstaled...

Thank You haruhiko_yamagata San.

[Blight]

mulder:
Since my application is new, older versions are not as important, I'm just asking for a standard when doing versions as right now it's a bit of a mess. Yes, I'm aware that opening the property page allows you to access the version there, but it's not a windows-standard way of storing version information. Since ffdshow.ax is actually a DLL file and there is a standard way of storing version information for DLL files, I would appriciate if it was used.

[clsid]

The version will increment each time you build ffdshow. However, the value differs for each builder.

It is possible to store the revision/build date in the registry via the InnoSetup script. But that won't help for builds that use NSIS or a custom script.

[LoRd_MuldeR]

The version will increment each time you build ffdshow. However, the value differs for each builder.

It is possible to store the revision/build date in the registry via the InnoSetup script. But that won't help for builds that use NSIS or a custom script.

1. NSIS can do that easily too.
2. Can't the builders set their build# to the rev# they build?

[clsid]

I know NSIS can do that too, if someone updates the script.

I'm not going to manually adjust the version number (in version.ver) each time I build.

[Inventive Software]

Blimey, I'm itching to attack the NSIS script, but I reckon that's way too in over my head for my understanding, at the moment.

[Romario]

Can you guys resolve H264 decoding bug with x264 interlace video.

FFDSHOW rev 557 which I currently use can't decode x264 interlace well.

I encode from MPEG2 and uncompressed AVI sources in x264vfw rev600 from DeathTheSheep site, http://gabextreme.googlepages.com/x264vfwunited

[Px]

Small feature request - in OSD menu field "Input bitrate" shows average input bitrate. Could you add ability to see current input bitrate, not average?

[clsid]

@Romario, please upload a small sample file.

[Blight]

clsid:
That's a shame, standardization is a good thing, and version numbering is a part of that, it helps automate upgrades.

btw, which build would you recommend as "most stable", or is the latest build that?

[clsid]

The InnoSetup install script now puts the revision and builddate in the registry.

All recent builds are pretty stable.

[foxyshadis]

Small feature request - in OSD menu field "Input bitrate" shows average input bitrate. Could you add ability to see current input bitrate, not average?

How about frame size, then? You can't get any more current than that. If you want something a little closer to most bitrate analysis tools, which smooth bitrate over a half second to one second window, it's possible to come up with something.

[LoRd_MuldeR]

I've just installed ffdshow_rev598_20061127_clsid.exe, but the About page says:

http://img281.imageshack.us/img281/5998/clipboard01ph3.png

However when I go to file properties of ffdshow.ax, it says:
"Build Date" = "27/11/2006 - 15:19:24UTC"

[Px]

How about frame size, then?
It won't help...
You can't get any more current than that.
Media Player Classic shows both average and current bitrate, but doesn't log to file :(, I asked for such functionality in this topic - http://forum.doom9.org/showthread.php?t=101835&page=59, but got no answer at this moment....

[devaster]

can someone give some info where is a point where is applied settings when is ffdshow started ? i have written GPU (i)dct and i cannot find a location where is this selected (for libavcodec). GUI settings i have modified but code ...

[zambelli]

How do the new (*rev*clsid) ffdshow builds hosted on x264.nl compare to the old ones (*gcc*sse)? Same/better functionality? Same/better performance?

[foxyshadis]

can someone give some info where is a point where is applied settings when is ffdshow started ? i have written GPU (i)dct and i cannot find a location where is this selected (for libavcodec). GUI settings i have modified but code ...

ffdshow:
CdecoderOptions.cpp <-- backend of the GUI
Tlibavcodec.cpp <-- set the name/order here, in idctNames
TvideoCodecLibavcodec.cpp <-- avctx->idct_algo gets set to the IDCT here. Don't forget to bump the 6 to a 7.

ffmpeg:
avcodec.h <-- Add a define for yours here. Starts with FF_IDCT_AUTO
dsputil.c <-- where the grunt work happens, in dsputil_init(). Everything's done with function pointers, so include your header and add your newidct.c to the project. See simple_idct.c/h for an example.

[devaster]

ffdshow:
CdecoderOptions.cpp <-- backend of the GUI
Tlibavcodec.cpp <-- set the name/order here, in idctNames
TvideoCodecLibavcodec.cpp <-- avctx->idct_algo gets set to the IDCT here. Don't forget to bump the 6 to a 7.

ffmpeg:
avcodec.h <-- Add a define for yours here. Starts with FF_IDCT_AUTO
dsputil.c <-- where the grunt work happens, in dsputil_init(). Everything's done with function pointers, so include your header and add your newidct.c to the project. See simple_idct.c/h for an example.

:thanks: :thanks: :thanks: foxyshadis

some things i have found another I change

another little question : is somewhere some comments/docs to the code ?

[seewen]

List of known issues in revision 562:

Reported but unconfirmed bugs:

5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". I know that at least some of these encoders do work for others. My system specs: Windows 2000, AMD Athlon Thunderbird. (reported by clsid)



Same here.
My spec system: Windows Vista, Core 2 duo e6600.
But I've got the same problem with old build (ffdshow-tryouts-rev127 for example). And it works with ffvfw-20031028 (MPEG-4)


Sorry I don't know if it's the right place to post...

[Romario]

@Romario, please upload a small sample file.

OK, here it is. Small 50 second sample is on http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html

[clsid]

How do the new (*rev*clsid) ffdshow builds hosted on x264.nl compare to the old ones (*gcc*sse)? Same/better functionality? Same/better performance?
ffdshow tryouts vs. ffdshow:
- several bugfixes
- some new functionality: e.g. VP5 and VP62 decoders
- improved functionality: WMV3 decoder, output queue
- performance improvements: mainly just for decoding H.264, up to 30%

[clsid]

OK, here it is. Small 50 second sample is on http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html
Ok, I can reproduce it. VideoLAN has the same problem. So it is a bug in the ffmpeg code.

Can someone submit this to the ffmpeg mailing list?

[cc979]

just compiled ffdshow-rev601

all but libavcodec.dll was compiled with gcc-4.0.3

libavcodec.dll was compiled with a patched gcc-4_1-branch revision 118702 as ffdshow.ax crashed on opening filter with video was playing played, apart from it seems ok

its here if you want to test it
http://www.mytempdir.com/1088885

see my gcc page for new gcc build

[Romario]

Thank you, clsid.

Are you sure that ffmpeg is responsible for that annoying bug?

[Inventive Software]

Videolan and ffmpeg (and mencoder and ffdshow) use the same underlying code for the codecs and whatnot, so yes, ffmpeg is responsible since that's where the primary development goes on.

[devaster]

i cannot compile libavcodec project from svn due 500< syntax errors (especially in structures )...
i have compile it as c code in vs2005 with latest platform and directx sdk (march and october)
where is problem ? any ideas ?

[haruhiko_yamagata]

i cannot compile libavcodec project from svn due 500< syntax errors (especially in structures )...
i have compile it as c code in vs2005 with latest platform and directx sdk (march and october)
where is problem ? any ideas ?
libavcodec should be compiled by GCC.
VS2005 may be used to debug, but it often requires fixing source code.

[devaster]

libavcodec should be compiled by GCC.
VS2005 may be used to debug, but it often requires fixing source code.
AHA thanx ill try it ...

[LoRd_MuldeR]

just compiled ffdshow-rev601

all but libavcodec.dll was compiled with gcc-4.0.3

libavcodec.dll was compiled with a patched gcc-4_1-branch revision 118702 as ffdshow.ax crashed on opening filter with video was playing played, apart from it seems ok

its here if you want to test it
http://www.mytempdir.com/1088885

see my gcc page for new gcc build

Your libavcodec.dll seems to work fine for me. Some results:

ffdshow.ax by clsid (ICL9), libavcodec.dll by cc979 (GCC 4.1.2)
User: 58s, kernel: 0s, total: 58s, real: 59s, fps: 126.6, dfps: 124.4
User: 58s, kernel: 0s, total: 58s, real: 59s, fps: 126.7, dfps: 124.3

ffdshow.ax by clsid (ICL9), libavcodec.dll by clsid (GCC 4.0.3)
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 145.7, dfps: 143.4
User: 50s, kernel: 0s, total: 50s, real: 51s, fps: 146.6, dfps: 143.4

[fastplayer]

Why is there such a difference between 4.0.3 and 4.1.2? Shouldn't performance improve with newer compilers?

[Inventive Software]

Unfortunately, that doesn't appear to be the case with GCC. :(

[LoRd_MuldeR]

Unfortunately, that doesn't appear to be the case with GCC. :(

Well, it's just one test on one specific system.
And cc979 said that he used some "patched" version to get it working. Maybe that's why it's slower...
Last but not least "newer" doesn't mean "more optimized" nor "more reliable"

[cc979]

@LoRd_MuldeR: cheers for checking, think i need to look into it further - 20fps difference, i should check with clsid what optimizations were used on his build

[fastplayer]

Last but not least "newer" doesn't mean "more optimized" nor "more reliable"
In case of software - and compilers in particular - it should. But that's just my opinion ;)

[LoRd_MuldeR]

In case of software - and compilers in particular - it should. But that's just my opinion ;)

Of course it should, but reality often looks different ;)
For example they add a new feature, but it will take some time to optimize...

[fastplayer]

@LoRd_MuldeR:
I know what you mean. It's just odd for a compiler to go "backwards" in terms of performance. IIRC videomixer used 3.4.5 and achieved better performance than builds built with 4.x.x.

What compiler (version) are the ffmpeg guys actually recommending?

[LoRd_MuldeR]

I don't know...
But since all critical code in libavcodec is written in Assembler, the compiler version should not effect the performance very much anyway.
Makes my results even more confusing...

[clsid]

@cc979, no special optimizations have been used, just the supplied makefile

I did some tests with GCC 4.1.1 a while back and that was also slower. GCC 3.4.5 used to be the fastest then, closely followed by GCC 4.0.3. For the current code it is the other way around, 4.0.3 being the fastest.

GCC does need to perform some actions on the assembly code I think. Like register allocation and such. But it is still weird that newer versions have worse performance.

[foxyshadis]

I can't seem to get the environment for 4.2 and 4.3 working correctly, but if anyone can I think it's very important to test those out. 4.3 in particular will enable much simpler and faster multithreading (with OpenMP).

[iron2000]

Something I found at the ffdshow Wikipedia entry (http://en.wikipedia.org/wiki/Ffdshow):
"Important note: The ffdshow uninstaller has a bug and deletes Windows' codec and audio registry."

Is this true still for recent builds?

[foxyshadis]

It was brought up and fixed in August.

I don't understand why it was added to wiki weeks after it was fixed. Oh well, a lot of information on wiki goes unverified for ages.

[edit] There, rewrote the wiki entry, hopefully the important stuff doesn't get clobbered with misinformation again.

[Anima123]

Is there anyone that have successfully compiled ffdshow with gcc 4.3 (OpenMP)?

[haruhiko_yamagata]

Yeah, it does. Bizarre, that. Couldn't find an immediate cause after some digging through the subtitle code, so I'll come back to it later if no one else does.
It's my bug at rev 237. I'm trying to fix it. Thank you.

[LoRd_MuldeR]

Something I found at the ffdshow Wikipedia entry (http://en.wikipedia.org/wiki/Ffdshow):
"Important note: The ffdshow uninstaller has a bug and deletes Windows' codec and audio registry."

Is this true still for recent builds?

Writing stuff to Wikipedia is pain!
Once you update the Weblinks for example, it only takes seconds until your changes are reverted :mad:
Let it be outdated, if they like it that way....

[fastplayer]

@Developers:
I was wondering why only some of the changes that are being made by the ffmpeg guys end up in ffdshow. Why not all of them?
Looking at ffdshow's changelog, it seems like you handpick some of the updated ffmpeg code and integrate it into ffdshow. Why? Or am I completely wrong?

[LoRd_MuldeR]

@Developers:
I was wondering why only some of the changes that are being made by the ffmpeg guys end up in ffdshow. Why not all of them?
Looking at ffdshow's changelog, it seems like you handpick some of the updated ffmpeg code and integrate it into ffdshow. Why? Or am I completely wrong?

Maybe because the devs work in their free time and they cannot do everything at the same time ???

We should be thankful for every update we get!

[clsid]

Not all of the ffmpeg code is used by ffdshow.

[fastplayer]

That would have been my guess.
Do you just copy over the source or do you have to make adjustments? Is there no way to automate this?
By the way, thanks for the new build, clsid! :)

[vlada]

I have a question regarding DVD support. It doesn't work in my favorite player (ViPlay 2.xx) but it works in WMP. But there are 2 small flaws:

1) MPEG-2 decoding only works with libmpeg2. With libavcodec the video is very choppy although CPU usage is low. This bug in ffdshow (or libavcodec?) is there already for a long time.

2) It would be nice if letterboxing (in Subtitles dialog) worked for DVDs too. I mentioned my problems in this thread (http://forum.doom9.org/showthread.php?p=823874).

[Romario]

clsid, what's going on with your bug report about FFMPEG x264 interlace decoding? Do you got any answer form FFMPEG devs?

[clsid]

I haven't submitted a bug report. Feel free to do it yourself:
http://ffmpeg.mplayerhq.hu/bugreports.html

[clsid]

List of known issues in revision 613:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Some files with interlaced H.264 video don't decode properly. FFmpeg bug. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). (Reported by Romario)

Reported but unconfirmed bugs:

3) Writing an OGM file via VFW interface creates a corrupt file. (reported by clsid)
4) FLV muxer seems to be buggy as well.
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". At least some of these encoders do work for others? (reported by: clsid, seewen)

ToDo:

6) Add WM9 decoder passthrough

Other issues:

7) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). These files should be very rare. Funny thing however is that the files play fine and without crash if you first play another file and then play the 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)

[Inventive Software]

With regard to the encoders problem you have... have you tried it with different frame-rate material? I had that problem with NTSC framerate stuff (both 29.97 and 23.976), and 25 FPS wasn't a problem.

[haruhiko_yamagata]

I reprodeced the freeze on seek problem with Crystal player.
When I unchecked Crystal player's "Direct Show" -> "Allow YV12 (fastest)", it is OK.
When I unchecked ffdshow's "Ouput"->"Supported output colorspaces"->"YV12", it is OK as well.

OK, I found more radical fix. After a little more testing, I'll comit.

[clsid]

With regard to the encoders problem you have... have you tried it with different frame-rate material? I had that problem with NTSC framerate stuff (both 29.97 and 23.976), and 25 FPS wasn't a problem.
Just tested a 25fps input file and the problems remain.

[JarrettH]

what does stuff like this mean in the changelog?

(ffmpeg 7189,7191,7192,7193)

:D

[LoRd_MuldeR]

what does stuff like this mean in the changelog?

(ffmpeg 7189,7191,7192,7193)

:D

Changes on code from ffmpeg. Look at ffmpeg's SVN for details:
http://svn.mplayerhq.hu/ffmpeg/?view=log

[oddball]

Some SVQ3 clips still run like crap. The 'Deck the Halls' trailer for instance.

[Mangix]

a lot of them run very nicely :)

[Anima123]

I reprodeced the freeze on seek problem with Crystal player.
When I unchecked Crystal player's "Direct Show" -> "Allow YV12 (fastest)", it is OK.
When I unchecked ffdshow's "Ouput"->"Supported output colorspaces"->"YV12", it is OK as well.

OK, I found more radical fix. After a little more testing, I'll comit.

I can also reproduce it with ffdshow before rev601. Without "Allow YV12 (fastest)" enabled, Crystal Player cannot play video with YV12 color space like rmvb, which quite puzzled me. I have no idea what's the problem?

Furthermore, with "Allow YV12 (fastest)" enabled in Crystal Player and only allow YV12 output in ffdshow settings, it becomes not only freezing but also take over 90% cpu power.

[haruhiko_yamagata]

I can also reproduce it with ffdshow before rev601. Without "Allow YV12 (fastest)" enabled, Crystal Player cannot play video with YV12 color space like rmvb, which quite puzzled me. I have no idea what's the problem?

Furthermore, with "Allow YV12 (fastest)" enabled in Crystal Player and only allow YV12 output in ffdshow settings, it becomes not only freezing but also take over 90% cpu power.
The problem is fixed at rev 613. My binary is available for testing.

[Anima123]

Thanks Mr.Q

I've tried your latest build, it works without enable "queue output samples" option within ffdshow. Since that was not needed with Crystal Player which has its own buffer mechanism, so it's the solution.

[fastplayer]

What is the audxlib.dll good for? Which one of the audio codecs is using it?

[Episode]

It's for the Aud-X (http://www.aud-x.com/) 5.1 channel Mp3 decoding

[fastplayer]

I don't see any references to Aud-X in the audio codecs properties. Is it used at all?

[Inventive Software]

It's only used if you have an Aud-X encoded MP3 stream. http://www.aud-x.com will tell you more about Aud-X.

[foxyshadis]

Hm, I don't have audx.dll or whatever it is, I don't think clsid packages it. But it's supposed to be one of the options for mp3 decoding, iirc, since it piggybacks off a normal mp3. (It's somewhat similar to dolby 5.1 in that the backward-compatible downmix is listenable as well.)

[F_L_C]

Revision 602 - Directory Listing
Modified Thu Nov 30 13:28:23 2006 UTC (3 days, 21 hours ago) by h_yamagata
Bug fix : subtitle : fast rendering on UNICODE build was garbling.

This fix is causing Zoomplayer 4.51 to crash when subtitles are enabled w/ default settings. The popup says graphedit is the cause and the WinXP event viewer says ntdll.dll is the source. These crashes occur with Q rev619 and clsid rev610. Crashes do not occur w/ clsid rev598 because the fix was not implemented yet.

[haruhiko_yamagata]

Revision 602 - Directory Listing
Modified Thu Nov 30 13:28:23 2006 UTC (3 days, 21 hours ago) by h_yamagata
Bug fix : subtitle : fast rendering on UNICODE build was garbling.

This fix is causing Zoomplayer 4.51 to crash when subtitles are enabled w/ default settings. The popup says graphedit is the cause and the WinXP event viewer says ntdll.dll is the source. These crashes occur with Q rev619 and clsid rev610. Crashes do not occur w/ clsid rev598 because the fix was not implemented yet.
It works for me. What kind of subtitle do you use?
Could you upload the sample?

[F_L_C]

I spoke too soon about clsid rev598 not being affected...it just crashed. The subtitles are English and is for an xvid video. They are of the form .idx and .sub. The event viewer says:

Faulting application zplayer.exe, version 4.5.1.0, faulting module ntdll.dll, version 5.1.2600.2180, fault address 0x00011c48.

Sorry, I can't upload the file because it exceeds the forum limit (it's 1.5MB RAR).

[F_L_C]

I have uploaded it to rapidshare:

http://rapidshare.com/files/6006335/subsample4Q.rar.html

[haruhiko_yamagata]

I have uploaded it to rapidshare:

http://rapidshare.com/files/6006335/subsample4Q.rar.html
Thank you, but I still can't reproduce the problem. Where does it crash? at the first subtitle? Does the host sample movie matter?
I reset all ffdshow settings except for the subtitle file. Is it reproducible by the default settings?

[F_L_C]

I just tried drevil's latest sse build and same crash as yours and clsid. It crashes a few minutes into the video at almost the same exact scene (frame). The subtitle filter is at default settings; I just ticked the enabled box that's all. If I disable it, there is no crash at the scene or anywhere else.

The timeline in ZP shows 11:04 at the scene when it crashes and the words being displayed says "The move affects 37,000 workers in 160 countries..." It either crashes at this exact scene or immediately after.

[haruhiko_yamagata]

I just tried drevil's latest sse build and same crash as yours and clsid. It crashes a few minutes into the video at almost the same exact scene (frame). The subtitle filter is at default settings; I just ticked the enabled box that's all. If I disable it, there is no crash at the scene or anywhere else.

The timeline in ZP shows 11:04 at the scene when it crashes and the words being displayed says "The move affects 37,000 workers in 160 countries..." It either crashes at this exact scene or immediately after.
Thank you. Now I can reproduce the problem.
The error comes from the destructer of TrenderedSubtitleLines in ffdshow.ax/Tfont.h.

[F_L_C]

I have no idea what that means, lol. Bless the holy mother that people like you, clsid, and drevil exist. Thank-you.

[Mangix]

it means there's an error in the code. now we just have to wait for a fix(if it isn't fixed yet :))

[Isochroma]

An item of interest to ffshow developers has this morning been posted on the CoreAVC thread here (http://forum.doom9.org/showthread.php?p=911912#post911912).

The post details how an unusual feature of CoreAVC tweaks the VMR9 renderer - which normally clamps the luma of any YUV inputs to TV range - to output full range with YUV input.

ffdshow's Levels filter can be used to convert videos encoded in TV range to PC range. However, if the output is set to any YUV format, it will continue to show TV range using the VMR renderers, due to the clamping behavior. Some might be fooled into thinking that the Levels filter is working because some parts of the image get brighter, but the brightest whites will still be at level 235, and the blackest blacks at 16.

The article continues in greater depth; it is proposed that the CoreAVC developers reveal the specific code used to tweak the VMR renderers, so that ffdshow and others may incorporate the code to allow full range passthrough for significant performance improvement without significant coding complexity increase.

[MatMaul]

ffdshow's Levels filter can be used to convert videos encoded in TV range to PC range. However, if the output is set to any YUV format, it will continue to show TV range using the VMR renderers, due to the clamping behavior. Some might be fooled into thinking that the Levels filter is working because some parts of the image get brighter, but the brightest whites will still be at level 235, and the blackest blacks at 16.

Sorry but I don't understand the problem.
If I do a 16-235=>0-255 conversion like that :

http://img396.imageshack.us/img396/3785/ffdshowlevelsss1.png

where is the problem ?
anyone can explain that more clearly (I don't understand very well "clamping") or in french by MP if a french who understood read me :) .

Thanks

EDIT :

I think I understand !! :)

if I remap like that, cool I have the good luminance but I lose all datas in 0-16 and 235-255 in the remaped levels

So if I take the original YUV levels, I see only around 30-218 range instead of 16-235 range. :(

[Isochroma]

If your source is PC range or you expand a TV source to full range using the Levels filter, ffdshow sends full range data to the downstream renderer (assuming it is VMR9). Also assuming you are using a YUV output format in ffdshow (RGB always passes PC range all the way thru the pipeline - so we won't bother with that case here), everything's ok at this point.

Next, the VMR9 renderer receives YUV frame data from ffdshow's output pin on its input pin. However, because it is YUV, a little piece of code in the VMR9 renderer clamps any values outside of the 16-235 range. Then the frame is sent to your video card. So expanding the range in ffdshow is an exercise in futility because VMR9 will lop of the top and bottom anyway like a chainsaw.

The VMR9 renderer assumes that because it is receiving YUV data on its input pin, that the luma ought to be clamped to TV range. That is the problem. Range and color space representation are two entirely separate matters, not to be confused. Both RGB and YUV representations can contain the full range 0-255 for luma.

Any YUV frames passed to the input pin of VMR9 will be clamped to TV range, EXCEPT the magic CoreAVC when the "Fix VMR9 levels" checkbox is checked and a YUV format is selected for output (remember RGB is never clamped by VMR so the checkbox doesn't apply there). The CoreAVC filter must be directly connected to VMR for this to work - no filters in between - because it does some very special tweak that noboby but the Core team understand.

CoreAVC does not itself modify the frame luma range. That would be useless, because VMR9 renderer would clamp it anyway when it is delivered to the input pin. Rather, CoreAVC tweaks the renderer itself using either an undocumented switch or hack to force the renderer to pass full PC range even though its input pin is connected to a YUV source.

If ffdshow used this trick, you could expand your levels and output in any YUV format (such as MPEG-4's native YV12) and know that the VMR won't clamp it back to TV. This means much lower CPU usage, because the only way to get PC levels with VMR from ffdshow right now is RGB output (software YUV -> RGB conversion).

[foxyshadis]

Doesn't happen on ATI cards, so :bigshrug: here. At least, not on my 9200 and x1300pro. (Haven't tested the TNT2. Hope I never have to.) When dealing with display yuv levels, you should never claim that it happens some way and no other, because the combinations of gpu, drivers, and who knows what else lead to an almost random nature to it. You can certainly list the cards and driver versions you've tested on that your observations apply to. In this case, I'd really like to know how your system is set up so that it might be possible to duplicate by someone who can debug it.

The problem is that the video driver is what implements VMR9, not directx and not the OS.

Anyway, thanks for bringing that interesting behavior to our attention. I'll see if I can find anything about this signaling in the MS documentation, or online if it isn't here.

I'm just waiting for Haali's renderer to get a PC/TV levels switch, then I can finally quit screwing with levels.

[Isochroma]

As CPUs become more powerful, it becomes less important anyway. Using RGB formats as output guarantees that nothing will be altered and full PC levels passed to the display.

As far as I know, the Video Mixing Renderer is a feature of the operating system, not the graphics driver. I'm probably wrong... here's some fascinating documentation on the VMR: Using the Video Mixing Renderer (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directshow/htm/usingvmrmixingmode.asp).

[foxyshadis]

VMR7/9 are the interface to the graphics driver's actual renderer implementation. The interface is provided by DirectX, specifying how they communicate. Actually, most of DirectX is just interfaces and methods to enumerate supported interfaces, along with housekeeping stuf, it acts as a glue code between driver code and application code. I'm sure you know that, but anyway, that's all VMR9 is, which is why it works so differently with different drivers; the only complicated things VMR (renderless) does is timing and delay messages. I'd appreciate it more if there was one single reference implementation of yuv->rgb because at least then there's none of this confusion and bugginess.

May I ask whether you're using Windowed or Renderless modes (or Windowless)? Or both/all three? I'm home now so I'm scrounging all the docs looking for such a tweak. Still like to know what card/driver family you have.

[Isochroma]

Tested using MPC's windowed and renderless modes in VMR9. MPC doesn't support windowless mode, so far as I can tell. Not sure how VMR7 works in this regard, stopped using it some time ago because VMR9 renderless provided superior performance (lower CPU) using my FX5200 AGP8X. And I'm using Forceware 84.21; the 9x.xx series drivers are a disaster, IMHO.

I've emailed Avery Lee with the link to the CoreAVC thread post. I'm very sure he uses a 6-series GeForce for his debugging sessions. He was the first to post about the strange behavior of VMR9 and levels: YCbCr levels and the Video Mixing Renderer 9 (http://www.virtualdub.org/blog/pivot/entry.php?id=92)

Here's a comment posted after the article by Blight:

"I actually asked NVIDIA about this (a long time ago, this problem is as old as DirectX 9) and they said that it’s a microsoft directive or something of that nature that the output luma range should be 16-235 (no conversion to RGB luma range), very confusing and inconsistant."

[foxyshadis]

Yeah, ATI dropped support for below 9600 around 5.8, and more recently all 9000-series, so I feel your pain there. I believe nvidia only fixed their drivers in the 91.x time. =\ So at least that gives us a target: Older cards on the older drivers. Hmm. I wonder if it's possible to find out what options coreavc sets by querying directshow as it runs.

[MatMaul]

Yeah, ATI dropped support for below 9600 around 5.8, and more recently all 9000-series, so I feel your pain there. I believe nvidia only fixed their drivers in the 91.x time. =\ So at least that gives us a target: Older cards on the older drivers. Hmm. I wonder if it's possible to find out what options coreavc sets by querying directshow as it runs.

So with a x700 with last drivers, if I do a 16-235=>0-255 conversion, there are no clamping ?
how can I verifie that ?

[SeeMoreDigital]

I've emailed Avery Lee with the link to the CoreAVC thread post. I'm very sure he uses a 6-series GeForce for his debugging sessions. He was the first to post about the strange behavior of VMR9 and levels: YCbCr levels and the Video Mixing Renderer 9 (http://www.virtualdub.org/blog/pivot/entry.php?id=92)Hmmmm....

This was one of the reasons why I developed my own RGB (0-255) test cards..... I could not understand why there was so much colour and contrast difference between each one of MPC's video display output modes.... If say, I play a test card with 255:255:255 (white) in it and take a screen grab... What I'm seeing is grey. But with MPC's internal capture facility (set to .bmp), it's white!

Hope that makes sense?!

[foxyshadis]

So with a x700 with last drivers, if I do a 16-235=>0-255 conversion, there are no clamping ?
how can I verifie that ?

With VMR modes you should be able to make a screencap and test that. You can also play two instances at once, one in rgb out and one in yuv out, and they should match in brightness. The method I usually use is less strict - since I get black borders on most stuff, I just ensure that black edges match the black borders when watching. Any fade-to-grey will jump right out. Obviously if you try to correct it in ffdshow levels and it doesn't go away, just gets distorted, it's clamping - you will need to use the full luma range option though, or it'll be the levels filter itself doing the clamping.

You should ensure your monitor is something near a reference brightness, where you can discern both near-blacks and near-whites in some graphics software.

I already know that VMR9 will do PC-mode passthrough (no clamping) on mine, in all yuv modes, and Haali's will do TV-mode these days (it used to be PC-mode as well, maybe it sets some bits somewhere now, or one of my many recent &#!$ driver updates farged it up).

[F_L_C]

haruhiko_yamagata: I don't know if this will help you, but if I disable the ffdshow sub filter and use the one that ZP recommends: http://www.inmatrix.com/zplayer/formats/vsfilter.shtml

then there are no crashes. But the one ZP recommends screws up the derived aspect ratio of the xvid and I cannot figure out how to make it work/look like ffdshow's sub filter. Hope you or your clever ffdshow friends can straighten this out soon.

[Egh]

Good :) At least someone finally grabbed attention of the developers for that issue! Since I've been working with the fullrange encoded videos for a while, i've noticed strange behaviour on VMR9+YV12 already.

But it was fixed thanks to DW help a while ago: http://forum.doom9.org/showthread.php?p=912584#post912584

Taking this as an opportunity, and since many devs will hopefully test this issue, would like to remind that videos can be fullrange encoded already. Does ffdshow work correctly with them if you convert them to RGB32?

I didn't bovver to hack into the relevant code, but, in my n00bish opinion, RGB32 correction is wrong in that case. The function which does the conversion actually has a parameter for a fullrange video, but i wonder if that parameter is ever set if the fullrange video is indeed produced by the decoder.

[haruhiko_yamagata]

haruhiko_yamagata: I don't know if this will help you, but if I disable the ffdshow sub filter and use the one that ZP recommends: http://www.inmatrix.com/zplayer/formats/vsfilter.shtml

then there are no crashes. But the one ZP recommends screws up the derived aspect ratio of the xvid and I cannot figure out how to make it work/look like ffdshow's sub filter. Hope you or your clever ffdshow friends can straighten this out soon.
fixed at rev625. ffdshow's subtitle is not bad. I prefer Subtitles - Vobsub - Smoothing method - full (Slowest).
It looks better than the default one(swscaler gaussian).

[SeeMoreDigital]

Can some of you guys play the following Test Card Samples (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPC_Test_Card_Samples.zip) with MediaPlayer Classic (and FFdshows MPEG-4 decoder filter) and confirm whether the "white" in the 1280x720 sample is more or less white than in the 1024x576 sample?


Cheers

[fastplayer]

What exactly is delvcr80.exe removing when being executed? Only VC8 runtime DLLs in the ffdshow directory, right? I noticed it in the {tmp} directory. As far as I understand it is only effective when using NSIS builds but the comment in the Inno script suggests that it'll be ported to Inno, too.

[haruhiko_yamagata]

What exactly is delvcr80.exe removing when being executed? Only VC8 runtime DLLs in the ffdshow directory, right? I noticed it in the {tmp} directory. As far as I understand it is only effective when using NSIS builds but the comment in the Inno script suggests that it'll be ported to Inno, too.
Yes, it just remove old NSIS's msvcr80. It is executed only when the user is current ly using NSIS build and only effective if the user have ever used my build. Briefly ,it is executed only once.
Porting it to Inno script is easy, but I can't deny a posibility of serious bug. I prefer used code, at least untill our first beta.

[fastplayer]

Thanks for explaining this!
I noticed the file in drevil's build even though he's using Inno and 7.1 runtime.

Porting it to Inno script is easy, but I can't deny a posibility of serious bug. I prefer used code, at least untill our first beta.
You mean deleting the global assembly in the WinSxS directory? :D

[n3w813]

...
Next, the VMR9 renderer receives YUV frame data from ffdshow's output pin on its input pin. However, because it is YUV, a little piece of code in the VMR9 renderer clamps any values outside of the 16-235 range. Then the frame is sent to your video card. So expanding the range in ffdshow is an exercise in futility because VMR9 will lop of the top and bottom anyway like a chainsaw...


First of all, is YV12 a subgroup of YUV colorspace? Or are they 2 totally different colorspace (ie rgb vs yv12)?

I'm a newb when it comes to video related stuff, but I'm offering my experience here.

I'm using a Nvidia 7800GT with 97.31 drivers in WinXP SP2.
This is how I use ffdshow/vmr9.

DVD mpeg2 -> Nvidia mpeg2 decoder -(yv12)> ffdshow denoise/resize/sharpen -(yv12)> vmr9 renderless.

In my testing, using GetGray DVD calibration disc, 0-16 BTB and 236-255 WTW are being passed to vmr9 then to my tv through DVI. To verify, I turn up the brightness on my tv, and I can see BTB bars.

With CoreAVC 1.1, if I CHECK the 'Fix VMR9 Range' checkbox, 0-16 and 236-255 actually gets chopped off!! Weird huh, it's actually the exact opposite of what you are describing. :confused:

I never thought twice about trying to understand why. :p I know that my video is outputting the correct levels. But I guess this is a good time to find out the bottom of this.

My MCE box with 6800GT is experiencing the exact same thing.

P.S. I did use the vmrcccstatus=0x1 registry setting as suggested in Nvidia's driver pdf to supposedly fix video level issue. But I don't know if it is required, I think it may be defaulted to 0x1. Also, the description in the pdf is wrong, I think. It says to set to 0x1 for 16-235, and 0x3 for 0-255. I've tested this; if you set to 0x3, you DO NOT get BTB or WTW info. It is the opposite here also.

I'm already confused as it is with all this video level/pc level/colorspace stuff, and then manufactures come in and confuse me some more. :mad:

[Egh]

With CoreAVC 1.1, if I CHECK the 'Fix VMR9 Range' checkbox, 0-16 and 236-255 actually gets chopped off!! Weird huh, it's actually the exact opposite of what you are describing. :confused:


I guess that's CoreAVC bug. Since I've noticed some time ago that if the video is already fullrange, with --fullrange VUI parameter (in h264 stream itself) coreavc changes already present PC levels into TV ones, i.e. does exactly the opposite of what is needed :)

btw, what is that calibration disc?

[Jeremy Duncan]

http://calibrate.tv/

[haruhiko_yamagata]

You mean deleting the global assembly in the WinSxS directory? :D
No, it just delete msvcr80.dll and some related things from plugin directories and registry.

[clsid]

Thanks for explaining this!
I noticed the file in drevil's build even though he's using Inno and 7.1 runtime.It is supposed to be in the Inno packs ;) The Inno packs are silently removing the files installed/created by the old NSIS ffdshow installers.

I'll port the code sometime soon. Most people don't like hidden processes.

[SeeMoreDigital]

Isochroma posed the following in the CoreAVC thread yesterday: -
84.21 may clips VMR9 outside 16-235 over DVI, Latest Nvidia driver clips (http://forum.inmatrix.com/index.php?showtopic=4387)

Quote from the 84.21 driver release notes:

"Video color-space range for DVI-only1 outputs is erroneously set to standard mode (16-235) instead of extended mode (0-255).

A new detection feature to apply Standard CSC mode to TV outputs (including NTSC, PAL, 480i, and 576i), included DVI-only outputs by mistake.

Note: The driver correctly applies extended mode to analog outputs, and standard mode to TV outputs (including NTSC, PAL, 480i, and 576i).

A future driver release will correct this and apply the extended-mode color space to DVI-only outputs."

1. “DVI-only” means only one display is connected, and it is to the DVI output.So it would seem the differences we see in the colour output are most likely caused by discrepancies in Nvidia handling of certain sized input resolutions.... Bummer!

[cc979]

Can some of you guys play the following Test Card Samples (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPC_Test_Card_Samples.zip) with MediaPlayer Classic (and FFdshows MPEG-4 decoder filter) and confirm whether the "white" in the 1280x720 sample is more or less white than in the 1024x576 sample?


Cheers

i tested, all whites are the same in vmr9/overlay with colourspace yv12/rgb32/nv21

nvidia driver 93.71, 'Do not use colour temperature correction', on the adjust video colour settings - otherwise i got colour problems in overlay mode

[SeeMoreDigital]

i tested, all whites are the same in vmr9/overlay with colourspace yv12/rgb32/nv21How did you test. Was it "visually" or did you make a "screen-grab" and perform a spot test?

invidia driver 93.71, 'Do not use colour temperature correction', on the adjust video colour settings - otherwise i got colour problems in overlay mode I don't seem to be able to find this setting....


Cheers

[dk75]

First of all, is YV12 a subgroup of YUV colorspace? Or are they 2 totally different colorspace (ie rgb vs yv12)?
It's subgroup of YUV, 4:2:0 YUV to be exact, while YUY2 is 4:2:2 YUV.

[haruhiko_yamagata]

clsid uploaded a candidate (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=213872) for our first beta.

clsid, drevil_xxl, foxyshadis and I talked each other and decided to launch our first beta. Please test ffdshow_rev641_20061206_clsid.exe. When the build is confirmed to be stable, the package will be renamed "ffdshow official release beta1 revision 641 20061206" or something. Packages for each builders will be renamed like "Nightly builds by ...".

[F_L_C]

I have installed clsid's rev641 and can confirm the subtitle crash bug that Q and I were discussing has been fixed. I had no other issues with ffdshow. Thanks once again and congrats to you all for the stable release.

[MatMaul]

@clsid : can we have some information about the compilation of the beta, like which component is compiled with which compiler ?

[clsid]

Same compilers as previous builds. Details of compilers used can be found on sourceforge. Click on the clipboard icon.

[fastplayer]

I have installed clsid's rev641 and can confirm the subtitle crash bug that Q and I were discussing has been fixed. I had no other issues with ffdshow. Thanks once again and congrats to you all for the stable release.
This bug apparently affected me too. I just checked 2 AVI files that are vobsub'ed and would crash in 8 out of 10 cases at one specific scene and now they don't. I didn't report this bug because I couldn't reproduce it 100% and the crash dump never mentioned anything ffdshow-related. Guess I was wrong... :/
Anyway, thanks a lot for the fix! And build 641 behaves great so far! :thanks:

[MatMaul]

Same compilers as previous builds. Details of compilers used can be found on sourceforge. Click on the clipboard icon.
thanks !

[Anima123]

There's a new build rev646 out (marked as "proposed stable"). Thanks for developers.

[cc979]

How did you test. Was it "visually" or did you make a "screen-grab" and perform a spot test?

I don't seem to be able to find this setting....


Cheers

i took screen grabs for all the modes apart from overlay

the colour correction is in video/television panel using advanced settings

http://img392.imageshack.us/img392/8835/clipboard1de5.th.png (http://img392.imageshack.us/my.php?image=clipboard1de5.png)

[fastplayer]

@clsid:
I noticed in your install_script.iss that you ship 2 versions of ffdshow.ax and ff_wmv9.dll. I suppose both are compiled for different CPUs but where in your script is the CPU detection part? Or is this done automagically by the Inno installer?

Edit: Never mind. One file is built with ANSI, the other with Unicode support.

[clsid]

edit: nevermind

[fastplayer]

In case someone missed it:
Build 654 aka proposed stable is out!
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=213872&release_id=469134

[Romario]

I downloading it now!!!

clsid, I don't know how to report bug to ffmpeg devs. So, can you, please, instead of me, report x264 interlaced bug to them.

Thanks.

I think that when this bug get fix, ffdshow devs can declare stable build.

[LoRd_MuldeR]

I just noticed that the German installer says: "Unverarbeitete Videodaten" (unprocessed videodata)
shouldn't it be: "Unkomprimierte Videodaten" (uncompressed videodata)
instead?

[fastplayer]

Since eragon4ever translated "RAW Audio" with "Unkomprimierte Audiodaten", he should change it for consistency's sake. PM him.

[Eragon4ever]

No need for PM. I'll change it.

[fastplayer]

That was fast! :eek:
Thanks!

[clsid]

I think I have found a bug in the ffdshow subtitle filter.

If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position.

[fastplayer]

For me the subtitles play faster than in normal mode.

[Px]

Downloaded Build 654 aka proposed stable, only remaining problem - with vfw encoder

[foxyshadis]

Er, what error would that be, exactly? It doesn't crash or corrupt anything for me.

[Px]

Er, what error would that be, exactly? It doesn't crash or corrupt anything for me.
http://forum.doom9.org/showthread.php?p=900177#post900177
8) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)".

[ilpippo80]

I've tested ffvfw+virtualdub 1.6.16 reencoding an avi file and a mpeg1 file. I used "full processing mode" for video and "no audio" settings. The ffvfw were the default ones, with one step and constant bitrate.
Here's my results:

- The following encoders gave me the error "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100):"
MPEG-4 MPEG-1 MPEG-2 (with the avi but no problems with the mpeg1)
H261
H263
DV
ISO MPEG-4 Video V1
Windows Media MPEG-4 Video V3
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2

- the mjpeg files created crashed with ffdshow decoder (in mpc) but not vlc.

- the wmv8 files created gave me corrupted video with both ffdshow decoder and vlc

[_xxl]

Sample file please.
the mjpeg files created crashed with ffdshow decoder (in mpc) but not vlc.
What version are you using?This bug was fixed in rev 400.
- The following encoders gave me the error "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100):"
MPEG-4 MPEG-1 MPEG-2 (with the avi but no problems with the mpeg1)
H261
H263
DV
ISO MPEG-4 Video V1
Windows Media MPEG-4 Video V3
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2

EDIT:
H263+ is working?
I don't think that it is possible to reencode to any video codec? :confused:

[clsid]

sample input file (http://www.mytempdir.com/1105695)

[ilpippo80]

I'll upload the files later this evening, anyway I'm using rev641_20061206_clsid_icl9

[egandt]

Using the rev654 20061207 I can not resize as the aspect ratios is always 9x16 and not source derived, I've tried 3 builds from the 7th all with the same MO. The input resolution is 640x480 resize is set to "no aspect ratio correction", the output video is always 16x9 no matter what setting is used in Zoomplayer (which has had no changes since I upgraded from an 11/17 build). Note: turning off resize in ffdshow resolves the issue.

Also flawed in the rev601_20061130-sse2.

ERIC

[ilpippo80]

Sorry for the lack of news, I've been a bit busy yesterday...
Anyway, here's the files:
http://www.sendspace.com/file/yk37wq

I just made some other tests, and I've seen that the mpeg1,2,4 compression problem is with some avi files and not with others, while I had no problems with mpg files so far...

H263+ is working?

Yes, H263+ is working...

I don't think that it is possible to reencode to any video codec? :confused:

What do you mean?

[haruhiko_yamagata]

Using the rev654 20061207 I can not resize as the aspect ratios is always 9x16 and not source derived, I've tried 3 builds from the 7th all with the same MO. The input resolution is 640x480 resize is set to "no aspect ratio correction", the output video is always 16x9 no matter what setting is used in Zoomplayer (which has had no changes since I upgraded from an 11/17 build). Note: turning off resize in ffdshow resolves the issue.

Also flawed in the rev601_20061130-sse2.

ERIC
No aspect ratio correction means ffdshow respects the setting of "Specify size".
If you want to respect source aspect ration, you have to choose "Keep original aspect ratio".

[vlada]

I have some questions regarding default setting of ffdshow. I'm writing a beginners guide on how to set up video playback on computers with MS Windows. Of course ffdshow is here the base. I don't want to confuse the readers so I'd like to ask you a couple of questions:

1) Why are MPEG-1 and MPEG-2 not checked by default. I had some troubles with some MPEG-1 videos and ffdshow. But I never had a problem with MPEG-2 videos using libmpeg2. On the other side libavcodec always causes very choppy playback with MPEG-2. What are the reasons that MPEG-2/libmpeg2 is not enabled by default?

2) Why isn't FLAC enabled? Are there any problems?

3) Why is tremor the default decoder for Vorbis? I heard libavcodec should have higher quality. But there used to be a bug in 5.1 decoding. Is it already fixed?

4) Why is postprocessing off by default? I even can't select it in installer.

Thank you.

[fastplayer]

1) Why are MPEG-1 and MPEG-2 not checked by default. I had some troubles with some MPEG-1 videos and ffdshow. But I never had a problem with MPEG-2 videos using libmpeg2. On the other side libavcodec always causes very choppy playback with MPEG-2. What are the reasons that MPEG-2/libmpeg2 is not enabled by default?
I can only guess so... Since most people have some 3rd party MPEG2 decoder installed on their system, enabling libmpeg2 in ffdshow would override the default MPEG2 decoder which some people don't like. As for MPEG1, Windows already ships with a basic MPEG1 decoder which handles most MPEG1 videos. At least for me... :D
And most people use MPC as their default player anyway which already has libmpeg2 integrated and enabled by default. So I don't see any problems with ffdshow regarding libmpeg2...

[clsid]

Playing .flac files requires a source filter. ffdshow is only a decoder. If you install the source filter, then it also comes with a decoder.

Post-processing should never be on by default. PP is only useful for bad quality videos, and even then the best settings depend on the specific video and the users eyes and taste.

[fastplayer]

3) Why is tremor the default decoder for Vorbis? I heard libavcodec should have higher quality. But there used to be a bug in 5.1 decoding. Is it already fixed?
AFAIK, celtic_druid released once a version which had this bug fixed. I don't know if it has been incorporated into the tryouts... :confused:

[Eragon4ever]

It has been fixed it rev 4.

[Jeremy Duncan]

Since Lanczos Resizing is Multithreaded on Dual Core cpu's and not Hyperthreading ones.
What else is hyperthreaded on Dual core only and not hyperthreading cpu's, Is Queue output samples useful on Hyperthreading cpu's ?

[MatMaul]

I have tried to make a trunk folder in the repository, and I totally break the repository, sorry.

:stupid: (it's me...)

anyone who have a svn access can make a trunk folder with the development version in it please (the last non-broken version is the 674) ? like that :

/branches/ => beta1, beta 2 etc
/trunk/ => the development version

like that if anyone want only the development version he can have it without download all the branches

thanks a lot and sorry again.

EDIT : I actually try to resolv that, I think it was good in about 5 minutes. sorry...

[clsid]

uploading now

[MatMaul]

ok, I stop my own upload.

[fastplayer]

Why does ffdshow need a branch? It's not like some sort of backwards-compatibility has to be maintained like the Mozilla guys having Firefox branches for version 1.0.x, 1.5.x.x, and 2.0.0.x, or am I wrong?
Why not stay with one branch and release monthly/quarterly etc. a stable version? The decision could be based on a democratic poll here on the forums or the main developers decide among themselves which build to release.

[Eragon4ever]

This way new features can be added to trunk while fixes are in both. And maybe it will be deleted after a release and the source code will be packed?

[Mangix]

got a question here. why is the ALAC decoder not included with ffdshow? the current libavcodec has the code needed to decode ALAC but ffdshow isn't using it...

[_xxl]

got a question here. why is the ALAC decoder not included with ffdshow? the current libavcodec has the code needed to decode ALAC but ffdshow isn't using it...
http://sourceforge.net/tracker/index.php?func=detail&aid=1359547&group_id=53761&atid=471492

[fastplayer]

This way new features can be added to trunk while fixes are in both. And maybe it will be deleted after a release and the source code will be packed?
You got a point. Although most of the development work is updating ffmpeg and fixing bugs. So I'm not entirely sure if adding branches is of any advantage. Maybe I'm just too short-sighted... :D

[clsid]

I got a timeout twice during commit. MatMaul, can you upload it?

Here is the latest source code:
http://www.mytempdir.com/1109364

[MatMaul]

ok i upload now.

[haruhiko_yamagata]

Since Lanczos Resizing is Multithreaded on Dual Core cpu's and not Hyperthreading ones.
What else is hyperthreaded on Dual core only and not hyperthreading cpu's, Is Queue output samples useful on Hyperthreading cpu's ?
Yes. Resize is the only one that P4HT is excluded from multithreading.
Because P4HT does not have extra core for MMX, resizing and decoders would get little effect from multithreading.
Queue output samples does not depend on MMX and so it is best match with P4HT.

[clsid]

List of known issues in revision 684:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Some files with interlaced H.264 video don't decode properly. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). FFmpeg bug or perhaps a x264 VFW bug? (Reported by Romario)

Other bug reports:

3) Writing an OGM file via VFW interface creates a corrupt file. (reported by clsid)
4) FLV muxer seems to be buggy as well.
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". At least some of these encoders do work for others? Seems to depend on the input? Sample input file (http://www.mytempdir.com/1105695). (reported by: a few people)
6) I think I have found a bug in the ffdshow subtitle filter. If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position. (reported by clsid)

ToDo:

7) Add WM9 decoder passthrough
8) Update and fix SNOW support
9) Fix VMnc decoding
10) Fix VC-1 decoding
11) Update libavcodec vorbis

Other issues:

12) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). These files should be very rare. Funny thing however is that the files play fine and without crash if you first play another file and then play the 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)

[MatMaul]

7) Add WM9 decoder passthrough
I don't understand this feature :o

EDIT : when I tick "VMR9 mixer mode" in MPC, queue is not actived (rev684 by clsid) : it is normal ?

[mpioner]

developers pls add suport for this http://cia.navi.cx/
How
https://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1#scripts
like http://cia.navi.cx/stats/project/ffdshow

[Liisachan]

you mean this? [ 1577522 ] ffdshow "Queue output samples" support (http://sourceforge.net/tracker/index.php?func=detail&aid=1577522&group_id=82303&atid=565651)
patch is included in celtic_druid's 611-2, tho it is reported that 611-2 has a problem about Dts

[MatMaul]

you mean this? [ 1577522 ] ffdshow "Queue output samples" support (http://sourceforge.net/tracker/index.php?func=detail&aid=1577522&group_id=82303&atid=565651)
patch is included in celtic_druid's 611-2, tho it is reported that 611-2 has a problem about Dts
I have the last celtic druid mpc.
I'm not talking of this bug.

If I haven't "vmr9 mixer mode" ticked, no problem queue is active.
if I tick "vmr9 mixer mode", I have a "not effective : the video renderer in use does not support queue."
I use vmr9 renderless as renderer.

[KoD]

Libavcodec vorbis in current ffdshow does work with 6 channel vorbis. You can look at a test file here http://www.cccp-project.net/beta/test_files/[CCCP]_Manhole_Test_Your_5.1_[revamped].mkv

There is an issue with drevil's installer (at least in build 685). It installs the ansi version of files (at least considering what the about box says) instead of the unicode ones on my Windows XP. Clsid's 684 build installs the unicode version as expected.

[LoRd_MuldeR]

I have the last celtic druid mpc.
I'm not talking of this bug.

If I haven't "vmr9 mixer mode" ticked, no problem queue is active.
if I tick "vmr9 mixer mode", I have a "not effective : the video renderer in use does not support queue."
I use vmr9 renderless as renderer.

yeah, same here!

[haruhiko_yamagata]

EDIT : when I tick "VMR9 mixer mode" in MPC, queue is not actived (rev684 by clsid) : it is normal ?
fixed at rev 682. Though it was a simple bug, I decided to enable queue in VMR9 renderless and disable in VMR9(except for renderless) for beta 1. After beta1, I'll try to enable queue in VMR9 only when it is safe.

[MatMaul]

fixed at rev 682. Though it was a simple bug, I decided to enable queue in VMR9 renderless and disable in VMR9(except for renderless) for beta 1. After beta1, I'll try to enable queue in VMR9 only when it is safe.
Are you sure ?
I have test with beta 1 and rev 684, same behaviour.

[haruhiko_yamagata]

There is an issue with drevil's installer (at least in build 685). It installs the ansi version of files (at least considering what the about box says) instead of the unicode ones on my Windows XP. Clsid's 684 build installs the unicode version as expected.
ANSI build work fine in Windows XP. It's the spec of my and drevil_xxl's builds.
If you use more than 3 languages(English, Windows version of language, another language), UNICODE build have the advantage. It may be two, if you use English version of Windows.

[haruhiko_yamagata]

Libavcodec vorbis in current ffdshow does work with 6 channel vorbis. You can look at a test file here http://www.cccp-project.net/beta/test_files/[CCCP]_Manhole_Test_Your_5.1_[revamped].mkv

Vorbis? The sample looks like dts.

[haruhiko_yamagata]

Are you sure ?
I have test with beta 1 and rev 684, same behaviour.
Yes, both beta 1 and 684 work for me. VMR9 renderless + queue, YUY2 or RGB32.

[LoRd_MuldeR]

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]

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]

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]

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]

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]

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]

Please take a look here: http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=207

[aduwind]

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]

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]

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]

Uhm, is VP6 advanced profile (VP61) not supported? I use the beta1 from the tryouts.

[Jeremy Duncan]

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]

VP61 is too old. What is supported is VP62 aka FLV4.

[KoD]

On2 has a free download (http://www.on2.com/downloads/) for a directshow vp6 decoder.

[DeepBeepMeep]

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]

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]

Media Player Classic has an internal decoder for VP6 that supports all three subtypes. ffdshow only supports VP62.

[Inventive Software]

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]

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]

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]

Wow! 24 hours have passed without an update or a new build. ffdshow must be ready for prime time! :D

[Liisachan]

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]

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]

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]

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]

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]

Thx drevil_xxl :D :D :D
compiling ffdshow is easier than i thought:)
compiled, installed and its worked flawlessly.

[Romario]

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]

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]

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]

Still,ffdshow.ax compiled by MInGW GCC 4.1.2 crashes.

[haruhiko_yamagata]

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]

The new libavcodec supports SSE3.
Will this speed up real time Lanczos Resizing, or is libavcodec used only for Encoding ?

[foxyshadis]

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]

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]

????

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]

Multithreaded/SMP decoding for MPEG4/H263/H.264 will be very useful.

[thuan]

It means it only detects whether your CPU has SSE3 or not. No gain in speed.

[Inventive Software]

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]

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]

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]

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]

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]

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]

You are right.
Sorry!, I didn't remember correctly.

[Jeremy Duncan]

"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]

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]

@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]

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]

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

[Isochroma]

@CLSID: Yes, there is a bug in CoreAVC or ffdshow or both.

There are many RAW formats that can be selected; selecting YUV only means ffdshow should ONLY put itself in the graph if the upstream filter is outputting YUV.

However, even if CoreAVC is set to some RGB output, ffdshow still puts itself ahead and then CoreAVC outputs YUV.

[clsid]

@midiboy, try using {04FE9017-F873-410E-871E-AB91661A4EF7} and enable RAW support in the normal ffdshow decoder.


@Isochroma, do you mean that if you set ffdshow to accept only YUV in RAW mode, then CoreAVC suddenly starts outputting YUV instead of RGB?

[Isochroma]

YES, EXACTLY, you have hit the nail on the head.

[foxyshadis]

I bet CoreAVC uses YUV as a fallback mode, then, even if RGB is selected. Probably queries for all supported colorspaces, and if it does YUV but not RGB it'll switch. I wonder if it will use RGB fallback if you have YUV selected, too.

You'll have to ask Core about that behavior though.

[midiboy]

midiboy, try using {04FE9017-F873-410E-871E-AB91661A4EF7} and enable RAW support in the normal ffdshow decoder.

Hi Clsid,

yeah I know I can do that but then ffdshow will insert itself in all kinds of graphs where I don´t want it (tv recording software etc.).

Why did you stop using the raw video processor filter ? That was a very good idea, having a seperate filter for raw video processing that can be used for special things like DVD postprocessing WITHOUT disturing other playback graphs.

Would it be too much work supporting it again ??

Thanks,
Alex

[KoD]

midiboy, what's wrong with enabling what raw formats you want ffdshow to act as a postprocessing filter in ffdshow video decoder configuration -> Codecs page -> Raw option ?

If you want graph building control (which filters go where and in what order), you should know that's not meant for a filter in the graph to decide, but for the player that builds the graph. Use something like ZoomPlayer that offers the user an interface to alter the graph as he wants or contact the makers of the playback software you are using to implement such a functionality. Having filters force what goes where is wrong ! I leave it up to you as an exercise to find out why. ffdshow already forces its choices in some situations, and that's what's causing some issues (as well as solving some issues like explorer thumbnails).

And as amazing as it may seem, falling back to a format that all filters in the graph agree upon is what's meant to happen. Is what makes automatic graph building work.

[clsid]

Afaik, no changes have been made to the raw filter. Try some old versions to see when it stopped working for you.

[haruhiko_yamagata]

Though I'm messed up with the bug (http://forum.doom9.org/showthread.php?p=919534#post919534) of the patch for MPC and don't have much time, it may be interesting to try adding a option "DVD only" for Raw video.
TffdshowDecVideo::dvdproc shows if the source is DVD in most cases.
{04FE9017-F873-410E-871E-AB91661A4EF7} is suposed to be added into filter graph manually and used in graphedit.exe. That's why it has that low merit setting.

[foxyshadis]

And as amazing as it may seem, falling back to a format that all filters in the graph agree upon is what's meant to happen. Is what makes automatic graph building work.

I realize that, but Isochroma implied that it was exclusive. Similar to how ffdshow has total control over preferred/fallback/disabled formats. Now that I found a screenshot of 1.1 prefs (http://www.coreavc.com/index.php?option=com_joom12pic&Itemid=1), which I assume is the same in 1.2, it really is a full list of formats in order of preference, and there's no way to easily remove RGB or YUV modes, so a fallback to YUV is totally understandable. (I'm surprised it's possible to disable them completely via the registry, honestly.)

[Reino]

The fact that the following MOV[SVQ3+AAC] crashes...is this FFDShow to blame or the MP4 Splitter?

link: http://www.a-film.nl/film/trailer/00000397_quicktime_HOOG.mov

[Episode]

@clsid, would it be possible to have another icl9 build sometime soon? Thanks in advance!

[Jeremy Duncan]

Though I'm messed up with the bug (http://forum.doom9.org/showthread.php?p=919534#post919534) of the patch for MPC and don't have much time, it may be interesting to try adding a option "DVD only" for Raw video.
TffdshowDecVideo::dvdproc shows if the source is DVD in most cases.
{04FE9017-F873-410E-871E-AB91661A4EF7} is suposed to be added into filter graph manually and used in graphedit.exe. That's why it has that low merit setting.

That's a nice idea.

[Px]

I tested the VFW encoder side of ffdshow. rev 696, the following encoders worked, assume those not listed didn't work.
I tested
ffdshow_rev705_20061222_clsid.exe
ffdshow_rev705_20061222_clsid_icl9.exe
Still "Cannot start encoder (-100)" on MPEG4 codec. Which build, you are used for test?


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.
Did you tried to recompress files? I try both Vdub/Vdubmod, 5 or 6 files with different codecs, divx, xvid, mpeg2, on all of them "Cannot start encoder (-100)" error appeared :(

[_xxl]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
http://www.mytempdir.com/1129848

[Episode]

I really don't understand why CCCP -project considers ffdshow-tryouts as very unstable and unusable. They released a new version few days ago with a version of ffdshow that's dated way back in the september and they won't use tryouts versions because they have "very badly written multithreading code and almost none real improvements". Is the original code really that much more stable than what we have now or is CCCP just ignoring this project since the changes are not made by milan?-)

[foxyshadis]

Presumably one of their members used a build with queuing in the summer sometime, it didn't noticeably improve performance (or he stumbled onto one of the hanging bugs), and instead of filing a bug they wrote off the whole project indefinitely. But I'll see if I can convince them; I was sort of hoping Check would, since he's somehow involved with the group.

The original code is most definitely not more stable than what we have now. If CCCP wants to disable multithreading in their installer that's easy enough, but that's no excuse for ignoring the numerous bugfixes and performance improvements even in the original ffdshow code. Obvs none of them have compared current AVC performance to the last official build's.

[fastplayer]

Quote from the CCCP changelog (http://www.cccp-project.net/wiki/index.php?title=Main_Page):
Updated ffdshow to 2006-09-23, no multithreading since it isn't currently stable enough. Yes, this build might seem old. The reason for this is that ffdshow-tryouts isn't (and hasn't been) very stable. We prioritize stability over bleeding-edge features.
I'd really like to know what sh|t they're on... :rolleyes:

[_xxl]

Updated ffdshow to 2006-09-23, no multithreading since it isn't currently stable enough. Yes, this build might seem old. The reason for this is that ffdshow-tryouts isn't (and hasn't been) very stable. We prioritize stability over bleeding-edge features.
Yes,they seem to know everything better than we do.:confused:

[sillKotscha]

wtf is cccp? and more important... who cares about them?

[foxyshadis]

Combined Community Codec Pack (http://www.cccp-project.net/). The most popular codec pack on the net currently; k-lite has lost a lot of popular support over the past year or two, since CCCP showed up, because the alternative is much simpler and less dangerous on the system, and does a great job of cleaning up other codec packs' leftover garbage. They basically center the pack around ffdshow & haali's splitter, with a few extras to take up the slack. Fansub groups in particular nearly unanimously recommend CCCP now. It's important, because more people install such things than ever install ffdshow separately.

(In case you know the real meaning of CCCP, they do hint at that as well.)

[haruhiko_yamagata]

QueueUp20061223.patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1621133&group_id=173941&atid=867362)

New version of queue. This patch was writen to improve the stability and compatibility issue. Ironically this patch is too large and needs more testing.

As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.

VMR9 rengerless + RGB out + patched MPC : continue pressing right cursor key freezes. This issue is improved if queue is off. If queue is on, we have to wait for new builds.

My binary (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev706p_20061223_Q.exe) is available for testing.

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

[sillKotscha]

(In case you know the real meaning of CCCP, they do hint at that as well.)

Союз Советских Социалистических Республик :D

installing codec packs... that's the point - if a widely accepted codec pack offers ffdshow respectively build the pack around ffdshow than someone should convince them to include the last marked stable beta release... as it is rock solid for 99% of the users...

on the other hand it is a move in the right direction that no rip-offs of (il-) legal codecs are floating around but ffdshow is used instead in their pack... but to be honest - I don't care about codec packs :)

it's just kind of a sad feeling that your (devs around ffdshow) work doesn't get that respected as you've worked hard to release a stable beta release of ffdshow...

[Liisachan]

Personally, I don't use codec packs either, but codec packs are not all bad if you use it right. ffdshow is a codec pack too, in a way. The good point of CCCP would be, with it you can play video on relatively slow computers. So it could be recommended for general users who may or may not have fast CPU.

However, if you have fast CPU and prefer quality over speed that's a whole different story.

For instance, ffdshow's high-quality RGB32 output or MPC's internal sub-renderer with no sub-pic buffering.

Originally, haruhiko's mt patch was for that very purpose--VMR9 Renderless RGB32; so... that codec pack is in a way inconsistent with ffdshow's philosophy. ffdshow is quality-oriented (as in vorbis decoder, changed into high-quality mode). Actually, tho, many users didn't know old ffdshow's default Vorbis decoder was problematic; even today, many users don't know their video is out of sync, audio being about 50ms (typically 1 video frame) too late because of encoder delay + lame tag, as the encoders use lame default without knowing what they are doing. Obviously I wouldn't listen to "recommendations" of such people.

CCCP is "people's pack" (or "poor men's" pack in a good sense); Fast VSFilter softsubs instead of MPC's too beautiful but too slow desktop resolution (reasonable for normal users). Fast YUV color space instead of software-side RGB (the quality is especially degraded for many of nVidia users who don't configure the driver correctly; not CCCP's fault, tho). As another note, last time I checked, the official Matroska pack from matroska.org was CCCP-based too. (They didn't include ffdshow's mp4 encoders as legal precautions)
So, altho I'm not sure if cccp is good or not (as I'm not a user), it's used relatively widely, and I believe it must be much better than Nimo (?) or something, I don't remember the exact name, but I mean old notorious codec packs.
From what I gathered many people recommend cccp too, tho just because many ppl recommend it doesn't mean I automatically agree with that.

[LoRd_MuldeR]

QueueUp20061223.patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1621133&group_id=173941&atid=867362)

New version of queue. This patch was writen to improve the stability and compatibility issue. Ironically this patch is too large and needs more testing.

As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.

VMR9 rengerless + RGB out + patched MPC : continue pressing right cursor key freezes. This issue is improved if queue is off. If queue is on, we have to wait for new builds.

My binary (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev706p_20061223_Q.exe) is available for testing.

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

Tested with MPC:
VMR7 works fine
VMR9 works fine
Haali Renderer completely freezes with Queue enabled, otherwise is does not
Overlay says "not supported"

[cc979]

i've recompiled gcc-4.1.2 with the strip option, @clsid files are smaller - check my sig for the file

i try to compile ffdshow - and every thing compiles ok - ffdshow.ax will crash when looking the filters
but i've found a solution it has to do with '-march=pentium-mmx -mtune=i686' in makefile.inc's

if i remove them, it does compile and function correctly on my athlon_x64, but shows on version page x86, sse

and in the .bat files it should be "%SystemRoot%\..\Program Files\NSIS\makensisw.exe" for people who have windows on a drive

cheers

[haruhiko_yamagata]

Tested with MPC:
VMR7 works fine
VMR9 works fine
Haali Renderer completely freezes with Queue enabled, otherwise is does not
Overlay says "not supported"
Thank you very much for testing. Haali's renderer does not work on my developing environment. I find a PC that Haali's renderer works and reproduced the problem.

//EDIT
Overlay often fail over old renderer. That's why the OSD says "not supported".

[foxyshadis]

Still have issues with video output freezing when I make on-the-fly adjustments to avisynth. (Did I ever report that? Only noticed recently.) While the video's either playing or paused. Seeking fixes it.

Queue works well in YV12 and not in YUY2 here, in VMR9 renderless YUV mixing mode, just to let you know. I got it to work once in Zoomplayer, too, but it wouldn't after that. ;_;

And pretty much all MPEG-4 and WMV based codecs are crashing, the last few revisions, but only in MPC. Grr, and I have yet to successfully compile MPC to debug (when attempting to debug the binary, it exits process before it can be attached properly).

[haruhiko_yamagata]

I got it to work once in Zoomplayer, too, but it wouldn't after that. ;_;
Thank you for report. Is it about ffdshow_rev706p*_20061223_Q.exe? Please let me know the detail.

[Px]

I tested
ffdshow_rev705_20061222_clsid.exe
ffdshow_rev705_20061222_clsid_icl9.exe
Still "Cannot start encoder (-100)" on MPEG4 codec. I try both Vdub/Vdubmod, 5 or 6 files with different codecs, divx, xvid, mpeg2, on all of them "Cannot start encoder (-100)" error appeared :(
Today I made some additional test on huffyuv compressed 720x576 video, MPEG4 encoder works normally. Could it be, that ffdshow can't start encoding because another instance of vfw codec must be used for decoding?

[Px]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
Where I can download vc1 samples for testing?

[Px]

And one another thing (or maybe I missed something?):
I recently upgraded my cpu to dualcore, and found that when I play 24 Mbps H.264 sample in MPC, ffdshow works as if it multithreaded, first core load near 60%, and second - 40%. When I play same file in bsplayer, cores load 80-100/20...

[clsid]

Today I made some additional test on huffyuv compressed 720x576 video, MPEG4 encoder works normally. Could it be, that ffdshow can't start encoding because another instance of vfw codec must be used for decoding?
I tried disabling everything in ffdshow VFW decoder and it still has the same problems. Even with uncompressed input.

[foxyshadis]

Thank you for report. Is it about ffdshow_rev706p*_20061223_Q.exe? Please let me know the detail.

Yes, my apologies, it's your test build. Queue seems to be working normally in Zoom Player again now (in YUY2 VMR9), I think it might have stopped working because I installed clsid's build, oops. :o Btw, if it's important: ATI X1400 Mobility, Catalyst 6.10. XP SP2.

Btw, can the queue limit be raised, if there's enough free memory? Once in a while it'll hit a scene or the system will get busy and it shrinks to zero.

I still have to test certain scenes that had jerky panning before even with 9 frames in queue.

Where I can download vc1 samples for testing?

http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/

Lots of video game sites are using it for trailers now, too.

And one another thing (or maybe I missed something?):
I recently upgraded my cpu to dualcore, and found that when I play 24 Mbps H.264 sample in MPC, ffdshow works as if it multithreaded, first core load near 60%, and second - 40%. When I play same file in bsplayer, cores load 80-100/20...

Decoding is not yet multithreaded. (Except mpeg 1/2.) The queue only works if you have enough spare cpu to decode ahead a few frames. (Turn on ffdshow's OSD and select Queued Samples to find out if that's the case.) Once the pictures leave the decoder they can be multithread through the rest of the pipeline, to some degree, as well as fully threaded software resize.

Instead of watching task manager's graphs, it's often better to watch the cpu% in the process list, where you don't have to eyeball total utilization. If you really need graphs, process explorer has a single per-process graph that I think you'd like. It's hard to push mine above 50%, but I did it by resizing to 1280x1024. :p

[Px]

http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/

Lots of video game sites are using it for trailers now, too.
Thanks :)

Decoding is not yet multithreaded. (Except mpeg 1/2.) The queue only works if you have enough spare cpu to decode ahead a few frames. (Turn on ffdshow's OSD and select Queued Samples to find out if that's the case.) Once the pictures leave the decoder they can be multithread through the rest of the pipeline, to some degree, as well as fully threaded software resize.
Ok, I see, the Queued Samples most time is 9-10, in worth cases - 3-4

Instead of watching task manager's graphs, it's often better to watch the cpu% in the process list, where you don't have to eyeball total utilization.
I don't watch task manager, I use RMClock for watching and Rivatuner for logging core usage separately :)

[haruhiko_yamagata]

celtic_druid has compiled a new build for MPC.
Both the cursor key problem (http://forum.doom9.org/showthread.php?p=919534#post919534) and DTS problem are fixed.

mplayerc.rev611-3.2kxp.7z (http://tirnanog.fate.jp/mirror/Media%20Player%20Classic/mplayerc.rev611-3.2kxp.7z)

Thank you very much, celtic_druid.

[foxyshadis]

A couple interesting results, with r706p and the new MPC 611-3. The video hang when editing avisynth (or output) during playback is still there, but now it only lasts a second before resetting and playing normally. Also YUY2 works for queue now. Oh wow, that's awesome. (RGB also works, naturally.)

[fastplayer]

Not a biggie but... XP visual styles are not working with the latest MPC build.

[foxyshadis]

They work here. You might want to try searching your system for mplayerc.* and delete whatever comes up; a stray manifest might be breaking something. Or it might be something entirely different, not sure.

[celtic_druid]

The manifest file is embedded, so yeah it should work.

[haruhiko_yamagata]

Yes, my apologies, it's your test build. Queue seems to be working normally in Zoom Player again now (in YUY2 VMR9), I think it might have stopped working because I installed clsid's build, oops. :o Btw, if it's important: ATI X1400 Mobility, Catalyst 6.10. XP SP2.

Btw, can the queue limit be raised, if there's enough free memory? Once in a while it'll hit a scene or the system will get busy and it shrinks to zero.

I still have to test certain scenes that had jerky panning before even with 9 frames in queue.

I need a hard ware compatiblity list:(.
The limit of queue count can be raised, though I doubt the efficacy. Registry option for testing may help.

[fastplayer]

They work here. You might want to try searching your system for mplayerc.* and delete whatever comes up; a stray manifest might be breaking something. Or it might be something entirely different, not sure.

The manifest file is embedded, so yeah it should work.

@foxyshadis:
There's no hidden manifest file in my MPC directory or anywhere else. Just the EXE and INI.
@celtic_druid:
I remember that this happened with one of your previous MPC builds. I think the manifest file wasn't properly embedded as a resource or something...
Update: manifest is not embedded. Couldn't find it with ResHacker but I added it from your previous MPC build. See link below.

Edit: Fixed it by adding a manifest file.
Edit2: MPC build rev611-3.2 by celtic_druid + embedded manifest for XP visual styles support:
http://d.turboupload.com/d/1361725/mplayerc.rar.html

[leeperry]

call me stupid but I got a pretty annoying problem with the latest versions of ffdshow :(

in the older "official" releases, it was possible to fine-tune the aspect ratio with the keyboard arrows in order to reach 1.67/1.78/1.85 and 2.35

with the newer versions it doesn't work anymore, so you have to move the mouse like crazy to more or less reach the ratio you want........and you can only reach 1.66/1.77/1.84-1.86 and 2.36

is there a recent release that lets you change it with the keyboard arrows ?!!?!?

thanks ;)

[celtic_druid]

Yeah, MSVC sometimes leaves out embedding it. You can add it with MSVC (copy paste from previous exe).

[fastplayer]

Yeah, MSVC sometimes leaves out embedding it. You can add it with MSVC (copy paste from previous exe).
I actually copied the %windir%\system32\cdplayer.exe.manifest file into the MPC folder, renamed it to mplayerc.exe.manifest and voilà it works again :)

[leeperry]

any chance getting a reply pls ?
noone cares to get perfect aspect ratio but me ? :(

[haruhiko_yamagata]

any chance getting a reply pls ?
noone cares to get perfect aspect ratio but me ? :(
Please wait. I'm looking into it.

[leeperry]

awesome, thanks a lot :)

actually I'd be really great to be able to choose between :
1.0
1.22
1.33
1.47
1.666666
1.777777
1.85
2.35

and then being able to input it manually

[haruhiko_yamagata]

awesome, thanks a lot :)

actually I'd be really great to be able to choose between :
1.0
1.22
1.33
1.47
1.666666
1.777777
1.85
2.35

and then being able to input it manually
Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

[mpioner]

celtic_druid
time to do MPC-tryout :D

[leeperry]

Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

better talk to god than to his saints I guess, thank you so much :D

so I can use the keyboard arrows to finetune ?
any chance of implementing buttons with just 1.33/1.66666/1.77777/1.85 and 2.35 ?
or making the incremental change a lot slower when the right button is pushed ?
coz sometimes I just got my wireless mouse handy, no keyboard :D

where could I get a SSE2(GCC?) compiled version ?

thanks again and merry xmas :D

[Peuj]

The fact that the following MOV[SVQ3+AAC] crashes...is this FFDShow to blame or the MP4 Splitter?

link: http://www.a-film.nl/film/trailer/00000397_quicktime_HOOG.mov

Same issue for me with the latest ffdshow version.

[clsid]

You can drag the slider with your mouse.

[_xxl]

ffdshow(SSE2) compiled by MinGW GCC 4.0.3 is crashing.

[leeperry]

You can drag the slider with your mouse.

I know but you cannot reach every 0.1 increment......which is freakin' annoying

I cannot reach 1.67/1.78/1.85 and 2.35

[cc979]

ffdshow(SSE2) compiled by MinGW GCC 4.0.3 is crashing.

i'll check on it on mine, and try and find whats wrong - maybe related to crash with gcc 4.1.2 - as i had to alter the makefile.inc's remove the -march and -mtune to get it to work

[cc979]

just compiled it with gcc-4.0.3 with 'make SSE2=yes' works fine so far

[Yong]

sse and sse2 works here, with -march=pentium4 -mtune=pentium4, compiled with gcc 4.0.3, only libmpeg2 have problem with sse2(broken output or crash).

[cc979]

sse and sse2 works here, with -march=pentium4 -mtune=pentium4, compiled with gcc 4.0.3, only libmpeg2 have problem with sse2(broken output or crash).

just found libmpeg2 not sse2, just read a webpage about cpuid not in libmpeg2 - maybe its optimized for plain i686

edit. i maybe wrong https://trac.videolan.org/libmpeg2/browser/trunk?rev=1107

[Yong]

just found libmpeg2 not sse2, just read a webpage about cpuid not in libmpeg2 - maybe its optimized for plain i686

edit. i maybe wrong https://trac.videolan.org/libmpeg2/browser/trunk?rev=1107

libmpeg2 works if u define it with -U__SSE2__, which will disable the sse2 assembly code(?), or dont select the sse2 in here (http://img412.imageshack.us/img412/8176/sse2xd3.png).

[popper]

It'd be great if we could also nominate something as a stable release, I put up a new frontpage for the ffdshow tryouts page and don't redirect to the tryouts forums directly anymore, and I'd like to link there at least directly to a stable build people can use.

so the tryouts forums is reachable via http://forum.ffdshow.info/ and the new frontpage that's not the hottest of the hottest stuff but at least something easy at http://ffdshow-tryout.sourceforge.net/ ...

better contributions are always welcome.

it looks nice and simple , the way a book cover/first page should be, however im not so sure about this, perhaps its just me but 'if it's MPEG4 or H264, MPEG2 or MPEG1 or even WMV3' seems wrong and favours mpeg4-ASP and educates or at least implys to the average user that mpeg4 is the best (everyone says mpeg4 is the best as its [singular]the newest thing according to X-salesman)and so it most be divx as you state H.264 seperately (if they even know H.264 is AVC/mpeg4 p10, probably not).

perhaps its time for everyone to stress the point that mpeg4 is a generic salesmans trick (to sell non AVC kit)and people should be using 'the new AVC' and 'the old ASP' as the key words to at least make an effort to get people to ask these salesmen the right questions and perhaps get AVC/ASP written on the packages .....

[boom9]

sorry for offtopic, but do you know what does the "snap to desktop edges" option in MPC do?

Options->Player->"snap to desktop edges"

i have do some servial tests but did not see any difference

[thuan]

It does exactly what it says, when you move the thing close to your Desktop (screen) edges.

[boom9]

It does exactly what it says, when you move the thing close to your Desktop (screen) edges.

Looks like my MPC does not move closer, did I get it wrong?
thank you

[KoD]

How is this ffdshow related ? Is this the MPC thread ?

[LoRd_MuldeR]

@boom9
1. Plase remove over-sized images form your posting. They derstroy the layout!
2. "snap to desktop edges" means that MPC will dock to the edges of the screen when you move the window near to the edges. It's just the same behavior as Winamp, for example. Make the MPC window small enough and move it arround. You will notice the effect!
3. This post obviously is off-topic...

[leeperry]

Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

better talk to god than to his saints I guess, thank you so much :D

so I can use the keyboard arrows to finetune ?
any chance of implementing buttons with just 1.33/1.66666/1.77777/1.85 and 2.35 ?
or making the incremental change a lot slower when the right button is pushed ?
coz sometimes I just got my wireless mouse handy, no keyboard :D

where could I get a SSE2(GCC?) compiled version ?

thanks again and merry xmas :D

[fastplayer]

better talk to god than to his saints I guess, thank you so much :D
<snipped>

Why do you post the same (http://forum.doom9.org/showthread.php?p=921111#post921111) message again?

[leeperry]

coz it seems that I'd love to get a reply :)
sorry for that,

[_xxl]

I ran some tests on my computer and here are the results.
I used for testing a h264 sample and ffdshow rev 716.
I have enabled Queue in timecodec.exe.

The output colorspace is yv12.
NUll:
User: 22s, kernel: 0s, total: 22s, real: 23s, fps: 99.2, dfps: 97.0
http://i12.tinypic.com/47imfev.jpg
old:
User: 23s, kernel: 11s, total: 34s, real: 36s, fps: 64.1, dfps: 61.0
http://i14.tinypic.com/4igfskm.jpg
om:
User: 22s, kernel: 11s, total: 34s, real: 36s, fps: 64.8, dfps: 61.0
http://i12.tinypic.com/448sepd.jpg
vmr7:
queue on
User: 22s, kernel: 0s, total: 22s, real: 29s, fps: 98.0, dfps: 75.1
http://i16.tinypic.com/2evspj7.jpg
vmr9:
queue off
User: 22s, kernel: 0s, total: 23s, real: 24s, fps: 97.1, dfps: 92.9
http://i13.tinypic.com/400w3gh.jpg

[fastplayer]

Has a maxed-out core any adverse effects when using queued output?

[fastplayer]

Haruhiko has implemented a new version of queued output in rev719 with quite some fundamental changes - at least it looks like it to me :). So those who had issues with queued output in the past - *cough*CCCP*cough* - should give the 719+ builds a try.

Changelog:
New version of queue.
As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
Only queue in VMR7 and overlay mixer.
In VMR9, try VMR9's internal queue.
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.
registry option "queueCount".

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

Download:
ffdshow_rev719_20061227_xxl.exe (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=214245&release_id=470135)

[haruhiko_yamagata]

Haruhiko has implemented a new version of queued output in rev719 with quite some fundamental changes - at least it looks like it to me :). So those who had issues with queued output in the past - *cough*CCCP*cough* - should give the 719+ builds a try.

Well, let's fotet CCCP.
rev719 may not be as stable as beta1, though no new bugs are reported regarding queue (issue with Haali's renderer has been fixed).
I found VMR9 has internal queueing mechanism. It is not worse than ffdshow's but no better. When I try to play 720p 24fps movie in 48fps, it drops more frams with queue in a certain hardware(my intel on bord one). It's very usefull in G450, but it's not usefull at all in some hardware.
Queue is effective in VMR9 renderless/MPC in most video cards though.

[clsid]

I have tested the new queue.

ffdshow rev720
MPC rev611-3
Windows 2000 Sp4

Renderers:

System default:
Picture freezes after a few frames. Time slider progresses normally. If I move the slider to another spot in the movie, then again only a few frames are played before the picture freezes. CPU usage during freeze ~10%.

Old renderer:
queue off

Overlay Mixer:
off: old renderer does not support queue ???

VMR-7 (windowed):
ok

VMR-7 (renderless):
ok

VMR-9 (windowed):
off: video driver can't work with YV12 + VMR-9 + queue

VMR-9 (renderless):
ok

[LoRd_MuldeR]

jap:
* Overlay Mixer: "old renderer does not support queue"
* Haali Renderer: "Queued Frames: 0"
* VMR7/9 okay

(rev719, MPC 611-3)

[MacAddict]

jap:
* Haali Renderer: "Queued Frames: 0"
* VMR7/9 okay

(rev719, MPC 611-3)

I can verify this on my system as well.

[cc979]

rev 721

trunk/src/dialog/CcurveNormal.h

#ifndef _CCURVENORMALPAGE_H_1
#define _CCURVENORMALPAGE_H_

should it be

#ifndef _CCURVENORMALPAGE_H_1
#define _CCURVENORMALPAGE_H_1

[Eragon4ever]

I think this is my bad from removing spaces.
If so it should be
#ifndef _CCURVENORMALPAGE_H_
#define _CCURVENORMALPAGE_H_

I'll change it.

[haruhiko_yamagata]

Thank you for testing.
@clsid : I'll test Windows2000 and its default renderer.
@LoRd_MuldeR : I can't connect to Overlay Mixer recently in MPC. It connects to old renderer. Seems same for everyone. I remember I could. What's wrong? MPC, Direct X, OS, ffdshow?

[_xxl]

I used for testing a h264 sample and ffdshow rev 719 + queue on, MPC rev611-3 and Windows XP SP2.
Output colorspace YV12.
Renderers:
1).System default:
http://i14.tinypic.com/2duxmx4.jpg
2).Old renderer:
queue off
http://i13.tinypic.com/34z0vw3.jpg
3).Overlay Mixer:
queue off
http://i10.tinypic.com/313iv0j.jpg
4).VMR-7 (windowed):
http://i10.tinypic.com/2vd0ccm.jpg
5).VMR-7 (renderless):
http://i11.tinypic.com/4g4zndt.jpg
6).VMR-9 (windowed):
queue off
http://i17.tinypic.com/4ck6xxh.jpg
7).VMR-9 (windowed):YUY2
http://i10.tinypic.com/2i0sl5w.jpg
8).VMR-9 (renderless):
http://i10.tinypic.com/448twsk.jpg
9).Haali:
queue off
Queued Frames: 0
http://i14.tinypic.com/4h7j3py.jpg
MPC + ffdshow + Queue.
Queue off:
http://i12.tinypic.com/2cxw87s.jpg
Queue on:
http://i18.tinypic.com/2hs4vih.jpg
Media Player2 + ffdshow + Queue.
Queue off:
http://i10.tinypic.com/4gow6kw.jpg
Queue on:
http://i17.tinypic.com/2lih6wz.jpg
I have enabled Queue in timecodec.exe.
TimeCodec VMR7 + ffdshow + queue:
http://i11.tinypic.com/2gtueyf.jpg
User: 22s, kernel: 0s, total: 22s, real: 29s, fps: 101.4, dfps: 75.2
TimeCodec VMR7 + coreavc 0.0.0.4:
http://i18.tinypic.com/2lwxfed.jpg
User: 14s, kernel: 13s, total: 27s, real: 30s, fps: 81.2, dfps: 74.0
TimeCodec VMR7 + coreavc decoder 0.0.0.4 + ffdshow queue:
http://i18.tinypic.com/2a9165g.jpg
User: 15s, kernel: 0s, total: 15s, real: 29s, fps: 141.5, dfps: 75.1

[LigH]

Just as side note -- if you want to test Theora decoding, or output space clamping:

Some community modelling project of the PlaneShift MMORPG made a preview video in Theora which looked distorted at first in ffdshow, like: [\]

The reason was: It uses some odd dimensions (1202x911), and YV12 output was enabled in ffdshow. Limiting the output to RGB and YUV 4:2:2 only "fixed" the messed output. But here I wonder: May it be recommendable to expand the dimensions to the next matching sizes (e.g. height of 912 lines) to avoid that?

http://vaalnor.mine.nu/Downloads/Video/waterfall.avi (312 KB)

[_xxl]

http://img139.imagevenue.com/loc369/th_09263_theo_122_369lo.jpg (http://img139.imagevenue.com/img.php?image=09263_theo_122_369lo.jpg)
Input size:1202x911
Output size 1216x912
ffdshow + Haali Media Splitter (AR)

[fastplayer]

@drevil_xxl:
Any chance you include Unicode-version of ffdshow.ax in your builds (like clsid)?

[vlada]

On my system the output resolution is 1208x902 and it looks O.K. I'm using ffdshow beta1.

Btw. recently I read quite a lot about queued output. What is it good for? How does it works?

[LigH]

Hmm...

ffdshow_beta1_20061211_clsid.exe
YV12 output enabled
MPC 6.4.9.0 deutsch
Output: Overlay
ELSA Gladiac GeForce2 GTS, 32 MB, Detonator 4345

Video size:1202x911
Slanted picture

[LoRd_MuldeR]

@LoRd_MuldeR : I can't connect to Overlay Mixer recently in MPC. It connects to old renderer. Seems same for everyone. I remember I could. What's wrong? MPC, Direct X, OS, ffdshow?

Sorry, I don't know.

MPC is rev611-3
DirectX is 9.0c (2006 Dec)
OS is WinXP Pro (SP-2)
ffdshow is rev719

So everything should be up-to-date, eh?

// EDIT

With "Overlay Mixer" selected in MPC I get this:
http://img136.imageshack.us/img136/8554/overlaymf9.gif
So there is Overly Mixer on the graph...

But ffdshow still says "Queued samples: off: old video renderer does not support queue"

[clsid]

MPC also shows Overlay Mixer in "Play -> Filters" for me. Perhaps a bug in ffdshow that detects it wrong?

[haruhiko_yamagata]

Sorry, I don't know.

MPC is rev611-3
DirectX is 9.0c (2006 Dec)
OS is WinXP Pro (SP-2)
ffdshow is rev719

So everything should be up-to-date, eh?

// EDIT

With "Overlay Mixer" selected in MPC I get this:
http://img136.imageshack.us/img136/8554/overlaymf9.gif
So there is Overly Mixer on the graph...

But ffdshow still says "Queued samples: off: old video renderer does not support queue"
Thank you for the graph. I understood. When ffdshow detects "Video Renderer" in the graph, it says like that.
I'll fix the bug.

[haruhiko_yamagata]

Btw. recently I read quite a lot about queued output. What is it good for? How does it works?
Queue may save the CPU time and increase the frame rate when CPU load is high and droping a few frams/sec.

When ffdshow finished decoding, ffdshow delivers the sample to video renderer. Video renderer process the sample in its back buffer and waits untill it is time to present the image(the samples have timestamps). This waiting is waste of time. Queue utilize the time video renderer is waiting for the presentation time.

Assume the frame rate is 25. Each samples have to be processed in 40ms. Assume consecutive frames are decoded in 30ms, 45ms, 20ms, 50ms. With queue frame 2 and 4 can be delivered before presentation time. Without queue it failes to be in time and some video renderers drop such frames(depend on drivers).

Queue is especially effective when GPU is slow and frames are being dropped in video renderer. Queue was initially developped in G450.

Queue is not effective when it is too heavy and video is delayed, because the sample sent to video renderer is presented as soon as possible.

Queue is not effective in Timecodec.exe because Timecodec present the sample as soon as it is delivered.

Video renderer is executed in other thread, so it may help accelalation in some cases(usually not that much).

If you have fast CPU and GPU, you should disable queue.

[haruhiko_yamagata]

Just as side note -- if you want to test Theora decoding, or output space clamping:

Some community modelling project of the PlaneShift MMORPG made a preview video in Theora which looked distorted at first in ffdshow, like: [\]

The reason was: It uses some odd dimensions (1202x911), and YV12 output was enabled in ffdshow. Limiting the output to RGB and YUV 4:2:2 only "fixed" the messed output. But here I wonder: May it be recommendable to expand the dimensions to the next matching sizes (e.g. height of 912 lines) to avoid that?

http://vaalnor.mine.nu/Downloads/Video/waterfall.avi (312 KB)
Only VMR7 worked for me. All other renderers did not(I can't test Haali's). Obviously it is downstream's responsibility to reject such connection. But in practice they connects, means ffdshow has to do some work around. It is good to skip YV12 for such sized media.

Btw, is YV12 supported in VMR9?
If you have direct X SDK, see d3d9types.h
D3DFMT_UYVY = MAKEFOURCC('U', 'Y', 'V', 'Y'),
D3DFMT_R8G8_B8G8 = MAKEFOURCC('R', 'G', 'B', 'G'),
D3DFMT_YUY2 = MAKEFOURCC('Y', 'U', 'Y', '2'),
D3DFMT_G8R8_G8B8 = MAKEFOURCC('G', 'R', 'G', 'B'),
D3DFMT_DXT1 = MAKEFOURCC('D', 'X', 'T', '1'),
D3DFMT_DXT2 = MAKEFOURCC('D', 'X', 'T', '2'),
D3DFMT_DXT3 = MAKEFOURCC('D', 'X', 'T', '3'),
D3DFMT_DXT4 = MAKEFOURCC('D', 'X', 'T', '4'),
D3DFMT_DXT5 = MAKEFOURCC('D', 'X', 'T', '5'),

YV12 is not listed. Is YV12 + VMR9 with normal file working for evryone?

YV12 and VMR9 renderless/MPC does not work for me. ffdshow try YV12 first of all, This behavior may be changed for VMR9 renderless.

drevil_xxl said that it is black and white in WMP11/YV12/WinXp.

YV12 first may need reconsidering.

[wyrd]

Hi,in my case:

XPpro sp2
DirectX 9.0c(4.09.00.0904)
ATI Radeon(Omega3.8.252)
MPC611-3
WMP10 10.00.00.4036
ffdshow drevil_xxl's rev722
haali's media splitter 20061228

capture:
http://tirnanog.fate.jp/tmp/waterfall/
mpc_systemdefault.JPG
mpc_overlaymixer.JPG
mpc_vmr9_MixerModeOff.JPG
mpc_vmr9_MixerModeOn_YUVOff.JPG
mpc_vmr9_MixerModeOn_YUVOn.JPG
wmp_dontusevmr.JPG
wmp_overlaymixer.JPG
wmp_HQmode+ffdshow_forced_RGB32.JPG
wmp_HQmode.JPG

Regards

[foxyshadis]

I believe all YUV planar is converted inside the driver to UYVY before being passed on to the card, if the driver supports it. In my case it does, I have no problems using YV12+VMR9 with or without queue.

I have an odd bug that I've been unable to track down: Enabling avisynth drops frames for no apparent reason. It's totally repeatable on this sample (http://foxyshadis.slightlydark.com/random/[960x540%5D.mkv), and repeatable on certain panning scenes in other movies, but rare on others both larger and smaller. I can't figure it out. All the avisynth script has to contain is "last", if it's empty but enabled it'll be smooth. Queue has nothing to do with it, I'm sure of that. CPU usage is practically nothing, queue is at 9, and avisynth is the only filter enabled.

Better script: "ShowSMPTE()", which gives a counter that should change every frame. It doesn't, showing that it's sticking somewhere. Hrm. I'm not as lost as I was originally, but still don't see where the problem might be, assuming it's in the avisynth code.

[clsid]

In my experience YV12 output gives the best performance.

But in some (rare) cases it gives color shifts in Overlay, like in wyrd's mpc_overlaymixer.jpg screenshot.

A file that has color shift for me is "beyonce.at.the.bbc.1080mbaff.sample.ts (http://mirror05.x264.nl/public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts)" (1440x1088). Funny thing is that coreavc has no such problem on this file when outputting YV12 to Overlay Mixer.

Two others files with the problem are "STORMAHEAD_PodsTrailer.mov" (SVQ3 640x259) and "dv-300708.mov" (SVQ3 300x225). So both with non-mod2/4/8/16 resolutions.

[haruhiko_yamagata]

Of course YV12 is the fastest. That's why it is still default despite many problems.

For the odd number line files, the decision making for the spec is easy. Just add one line at the bottom, though the implementation may be hard.

Thorny issue is what to do in VMR9 renderless. VMR9 renderless supports YV12 but it does not work for me(i82865G, both MPC and Zoom player pro).

[foxyshadis]

Oh, an idea I wanted to mention. What do you guys think about having grain filter retrigger every 45 ms? This avoids one of the big problems with using it with vfr video (wmv and mkv particularly) with long stretches of a single frame. Sometimes a full second of staring at the same motionless grain pattern on a black screen. At least if it's moving at 22fps the eye is fooled into seeing haze, instead of grain. 45 ms is long enough to not interfere with film or video, and while it'd trigger twice a frame for 20fps and lower, I don't think it would look too bad. (But I still intend to run experiments to find out.)

[clsid]

I have tested the new queue.

ffdshow rev723
MPC rev611-3
Windows 2000 Sp4

Renderers:

System default:
works ok now

Old renderer:
off: The video renderer in use is not supported.

Overlay Mixer:
off: The video renderer in use is not supported.

VMR-7 (windowed):
ok

VMR-7 (renderless):
ok

VMR-9 (windowed):
off: video driver can't work with YV12 + VMR-9 + queue

VMR-9 (renderless):
Weird behavior: queue shows "1" once in a while, the rest of the time it shows "off: The video renderer in use is not supported".

Edit: Here is the OSD log file (http://www.mytempdir.com/1139999).

[wyrd]

@clsid
confirm here too. beyonce_colshift (http://tirnanog.fate.jp/tmp/waterfall/beyonce_colshift.JPG)
also, STORMAHEAD_PodsTrailer.mov is similar, too.(even defaultrenderer mode)
I'm wondering, but a snapshot comes out normally.(???) I've using "Fraps" for overlay capture.

Test report for "new queue":
I've a one problem too. It seems like the clsid's report.
("Picture freezes after a few frames. Time slider progresses normally.")
http://tirnanog.fate.jp/tmp/for_new_queue/sakura_hangup.jpg
samplemovie (http://tirnanog.fate.jp/tmp/for_new_queue/sakuratan.avi) (1.7M)

Test with:
ffdshow rev706p2,rev721,rev722
MPC rev611-3 WinXP sp2
splitter:mp4=haali's mkv=MPC avi=system
non HT P4(queue output sample: on - daring^^)

Because this problem occurs intermittently, I still can't clarify a reproduction procedure.

The operation that i did and a sample which is easy to occur with my pc.
1.restart pc
2.play movie with vmr9(renderless)+mixer mode off
3.change vmr9 -> null and play
4.change null -> vmr9(windowed) and play
5.change vmr9(windowed) -> vmr9(renderless)+mixer mode on and play
6.change vmr9(rederless) mixer on -> vmr9(renderless) mixer mode off and play
repeat 1-6.(may or may not be reproduce)

or other way,(This was easy to reproduce for me.(in rev721))
1.restart pc
2.play movie with vmr9(renderless)+mixer mode off
3.other applicaiton exec(open) and close.(e.g word,excel,msvc,photoshop...as heavy as one can)
4.play movie with system default renderer.
5.other applicaiton exec(open) and close.(e.g same as above)
repeat 2-5. or 1-5.
(Plz put sample movie to a network drive if possible.)

This problem reproduce with or with out renderer mode(vmr9/overlay).
other freeze snapshot & sample movie:
sanyo (http://tirnanog.fate.jp/tmp/for_new_queue/sanyo_hangup.jpg),starwars (http://tirnanog.fate.jp/tmp/for_new_queue/starwars_hangup.jpg),unreal (http://tirnanog.fate.jp/tmp/for_new_queue/unreal_hangup.jpg),mezon (http://tirnanog.fate.jp/tmp/for_new_queue/mezon_hangup.jpg)
http://tirnanog.fate.jp/tmp/for_new_queue/

Best Regards.
oh, I do not yet test rev723...

[clsid]

That freeze issue was fixed in rev723.

[wyrd]

I tested drevil's rev724 until a while ago.:o
It works fine for me.
Thanks a lot.

[haruhiko_yamagata]

In my video card(i82865G), YV12 is not supported for any 1025 or larger holizontal size. I see some green artifact or black screen.

//EDIT
YV12 is not supported for any 320 or smaller holizontal size. Many files from YouTube are smaller than 320.

[haruhiko_yamagata]

Now YV12 plays better than before in odd line numbers.
STORMAHEAD_PodsTrailer.mov as well as many files from YouTube plays better.

I still have issue in VMR9, but I'm sure it's VMR9's responsibility unless using YV12 in VMR9 of itself is wrong.

Do you agree to adding an option like "Disable YV12 in VMR9" and set it to default?
Because YV12 is the fastest, I think we need a poll.

I guess it should work in DVD resolution. Please test using resize to small(dx<320) and large size(dx>1024).

[fastplayer]

How did you fix the odd line bug? AFAIK, YV12 output has to be a multiple of 2 for height and width. Did you "secretly" add one line to output?

[haruhiko_yamagata]

How did you fix the odd line bug? AFAIK, YV12 output has to be a multiple of 2 for height and width. Did you "secretly" add one line to output?
Yes, I did. Just added one line at the bottom.

[fastplayer]

As for VMR9, maybe the latest DirectX SDK is needed. MS fixes quite a few bugs from time to time...

Edit: Forget about that. Just went through the changelogs of the previous releases and not one word about VMR... :/

[clsid]

Now YV12 plays better than before in odd line numbers.
STORMAHEAD_PodsTrailer.mov as well as many files from YouTube plays better.

I still have issue in VMR9, but I'm sure it's VMR9's responsibility unless using YV12 in VMR9 of itself is wrong.

Do you agree to adding an option like "Disable YV12 in VMR9" and set it to default?
Because YV12 is the fastest, I think we need a poll.

I guess it should work in DVD resolution. Please test using resize to small(dx<320) and large size(dx>1024).
I tried several small and large horizontal video sizes with YV12 in VMR-9 (renderless) and all played ok. So I guess this depends on the graphics card or drivers.

The YV12 odd resolution fix works great. Thanks!

The color shift problem with "beyonce.at.the.bbc.1080mbaff.sample.ts" only happens in Overlay for me. In VMR-9 it plays ok. If I use the resizer in ffdshow then it also works ok in Overlay, but only if the horizontal size is smaller than 344.

[fastplayer]

The color shift problem with "beyonce.at.the.bbc.1080mbaff.sample.ts" only happens in Overlay for me. In VMR-9 it plays ok. If I use the resizer in ffdshow then it also works ok in Overlay, but only if the horizontal size is smaller than 344.
Confirmed. All output modes in MPC work except Overlay Mixer.

[foxyshadis]

Drevil, is there any reason for icl project files to include "libirc.lib libm.lib svml_disp.lib" or were those accidentally added?

Edit: Ugh, I'm such a space case, I finally noticed while debugging that it came down to ffdshow (or ffmpeg? still investigating) returning bad frame numbers for IDFF_currentFrame, sometimes duplicates and sometimes skipping. That's "useful", since avisynth relies on those. >.> I'll write back if I find a workaround or a fix.

[clsid]

Drevil, is there any reason for icl project files to include "libirc.lib libm.lib svml_disp.lib" or were those accidentally added?
Yes, those are required. Without them there will be linker errors.

[foxyshadis]

Oh, I see why now. I was loading it from the vcproj and not the icproj when I compiled it today, sorry.

[Inventive Software]

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.

What I should have mentioned is that encoders were tested with 2 threads. 1 thread, and the following codecs FAILED (assume those not listed worked)

libavcodec
H.263
H.261

Multithreading's broken in a lot of codecs it seems. ;)

[_xxl]

Multithreading's broken in a lot of codecs it seems. ;)
multithreaded/SMP encoding for MPEG1/MPEG2/MPEG4/H263
was added in ffmpeg(libavcodec) in rev 2772 & 2778.
Here are some results:
libavcodec h263+:
http://i16.tinypic.com/2rxbm80.jpg
libavcodec mpeg4 xvid:
http://i13.tinypic.com/3zluejo.jpg

[Mangix]

got a question about SSE and SSE2 builds. are they supposed to decrease the decoding time so that videos load faster? i just tried one of celtic_druid's mplayer builds and i noticed that H.264 was faster than drevil_xxl's rev 730 build of ffdshow. actually, it was really unbearable.

[clsid]

You can't compare mplayer with ffdshow. Mplayer has always been a bit faster because it doesn't use DirectShow.

[Mangix]

i don't mean a bit faster. i mean WAY faster. i know that ffdshow uses DirectShow, but i never imagined that there's a huge difference between it and mplayer. i mean with mplayer, i can get clear and smooth playback on a 1280x720 file(quite large i know). on ffdshow, it does 15-20 fps.

[_xxl]

Mplayer is faster.If compiled with "FAST" is more faster but less quality.Some ffdshow filters can use SSE(2).Decoding parts are written in hand-optimized assembler for maximum speed.

[Mangix]

so i take it that there is SOME optimization in libavcodec's H.264 decoding code?

[fastplayer]

This has been discussed over and over again --> :search:
Quote from http://en.wikipedia.org/wiki/Ffdshow
A common misconception is that ICL SSE/SSE2 builds will decode video better than "generic" builds. In fact, the video decoders are always compiled in gcc and are usually hand-optimized; it's the ffdshow filters that benefit from ICL.

[Mangix]

doesn't that only apply to ICL builds :p

anyways, if that quote is true for all the builds, then i guess the actual decoding speed is not affected.

[clsid]

You could try enabling "skip H.264 deblocking" in ffdshow. That will increase performance considerably. At the cost of a little lower output quality.

[Yong]

Compiling error with lastest svn (gcc4.0.3)...
$ make -s
In file included from ../imgFilters/avisynth/Tavisynth.h:5,
from Tacm.h:5,
from Tacm.cpp:21:
../imgFilters/avisynth/avisynth.h:349: error: integer constant is too large for 'long' type
../imgFilters/avisynth/avisynth.h: In member function 'BYTE* VideoFrame::GetWritePtr() const':
../imgFilters/avisynth/avisynth.h:500: error: '_ASSERT' was not declared in this scope
../imgFilters/avisynth/avisynth.h: In member function 'BYTE* VideoFrame::GetWritePtr(int) const':
../imgFilters/avisynth/avisynth.h:509: error: '_ASSERT' was not declared in this scope
make[1]: *** [Tacm.o] Error 1
make: *** [lib] Error 2

[foxyshadis]

ffdshow and mplayer should have raw decoding speeds within a couple fps of each other if everything else is the same - no ffdshow filters, obviously, yuv output, and using overlay renderer, as well as no upstream, downstream, or audio filters hogging cpu time. Those latter parts ffdshow has no control over, and are just perils of directshow.

Graphedit is a quick way to check what filters show up, or mpc's filters menu, though it's hard to tell what should and shouldn't be there without doing this stuff a lot. Basically it should be something like:

file -> ffdshow video -> video renderer
\-> ffdshow audio -> directsound

Edit: GCC doesn't like the avisynth.h update? Okay, I'll check that.

Edit 2: That should do it.

[fastplayer]

I noticed the ffdshow audio mixer takes a lot of cpu time, at least in the recent past, even when it's just doing 2.0->2.0, so you might check whether that's enabled.
How did you measure this and compared to what (MPC's internal audio filters?)?

[foxyshadis]

How did you measure this and compared to what (MPC's internal audio filters?)?

Not ffdshow's audio decoder, the mixer filter (mpc doesn't have anything comprable). CPU usage spiked considerably, so it's always off.

But thanks for making me test again, because I found I was wrong - it's having the audio panel open that does it, not whether mixer is on or off. :o Must be a case of refreshing the gui too much; I guess I don't have to leave it off after all.

SVN should be fixed.

[fastplayer]

But thanks for making me test again, because I found I was wrong - it's having the audio panel open that does it, not whether mixer is on or off.
Yes, I can confirm this behavior too.

[_xxl]

AAC audio decoding bug:
http://forum.doom9.org/showthread.php?t=119932

[_xxl]

I have some test results.
Rev 730 sse2 + h.264 sample + MPC latest.
first play:
http://i16.tinypic.com/3z0sqoz.jpg
second play:(don't exit MPC)
http://i13.tinypic.com/2ed6xle.jpg
third play:(don't exit MPC)
http://i11.tinypic.com/30mqxp4.jpg
Just what am I looking at?I don't understand.
http://i12.tinypic.com/2u8w5zm.jpg
If I exit MPC and play this sample again I'll get first case.
If I stop and play again in MPC I get case 2 or 3.

[foxyshadis]

Try process explorer's single aggregate graph, in process properties. Or just set MPC's affinity to one CPU. You'll find the graphs are mostly stable, and all you're seeing is the kernel's habit of tossing threads around in strange fashions. It doesn't really affect performance to execute half-and-half on two cpus instead of one.

[Yong]

rev 734 fixed the gcc compiling error, Thx. but i have to use EXCEPTIONS=1 when compiling, is that normal?

Btw what happend to the snow? its several revs behind. i patched ffdshow with latest snow code form ffmpeg, playback seem to work fine here(encoded with latest mencoder).

[_xxl]

Snow is buggy.
Latest snow is not compatible with old version from ffdshow.

[foxyshadis]

Should we just update it, mention its instability like we used to for FFV1, and point to a specific version (like beta 1) for decoding old versions of snow? Perpetuating an outdated version might only lead to more problems.

[Liisachan]

Using vstrict=-2 means that you know what you are doing.
That's a bit different than being 'buggy' as you were already warned.


Snow is an experimental wavelet-based codec made by the FFmpeg developers,
and while it is still in heavy development, it is already giving very good
results.
Be very careful though, as the format of the bitstream produced might
change, do not rely on it to store videos that you value.
For this reason, MEncoder will not encode without 'vstrict=-2' on the
command line.

http://www.mplayerhq.hu/DOCS/tech/snow.txt

[Jeremy Duncan]

clsid,

May I ask you to post another generic FFDshow with the latest revision.

:thanks:

[haruhiko_yamagata]

I found a bug in YV12 and odd number lines.
With old video renderer, it sometimes crashes. When aplication finishes or changed to full screen.

[fastplayer]

I can't reproduce it with the STORMAHEAD_PodsTrailer.mov video.
Using latest MPC (old renderer), ffdshow rev731, XP SP2, and Radeon X800 GTO with 6.11 CAT driver.

Edit: One odd thing happened though: MPC doesn't rewind even though "Rewind when done playing" is checked. I don't know if this has anything to do with it...
Edit2: Checked with all 3 samples (http://tirnanog.fate.jp/tmp/odd_line/) provided by user wyrd and no crashes here...

[Inventive Software]

I want to clear up the VFW encoders tests I did. Here goes.

I tested ffdshow_tryout rev 696 (clsid) and ffdshow rev 2546 20060603 (videomixer9). Both produced identical results. Sample used was AviSynth 720x576@25FPS. H.263 and H.261 tested with 352x288@25FPS.

The following encoders worked with 1 thread:

libavcodec
MPEG-4
DivX 3
MS MPEG-4 V2
MPEG-1
MPEG-2
H.263
H.263+
H.261
WMV7
WMV8
MJPEG
Lossless JPEG
HuffYUV
FFV1
DV
FLV1

libtheora
Theora

wmv9
Windows Media Video 9
Windows Media Video 9 Advanced Profile (WMVA)
Windows Media Video 9 Screen
Windows Media Video V7
Windows Media Video V8

The following codecs failed to work and produced a -100 error in VirtualDub:

wmv9
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2
(This is because they're for single images only, is my guess)

The following codecs worked with 2 threads:

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

libtheora
Theora

wmv9
Windows Media Video 9
Windows Media Video 9 Advanced Profile (WMVA)
Windows Media Video 9 Screen
Windows Media Video V7
Windows Media Video V8

The following encoders failed to work and produced a -100 error in VirtualDub:

DivX 3
MS MPEG-4 V2
H.263
H.263+
WMV7
WMV8
MJPEG
DV
FLV1

wmv9
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2
(Again, these are single frame codecs I think)
(Note: the lossless codecs and H.261 don't have a threads box in the config pages)

Multithreading (i.e threads > 1) is therefore broken in the following codecs:

libavcodec
DivX 3
MS MPEG-4 V2
H.263
H.263+
WMV7
WMV8
MJPEG
DV
FLV1

Hope that makes everything more clearer.

EDIT: Updated with correct resolutions for H.263 and H.261, H.263's broken with multithreading.

[Yong]

IIRC h261 and h263 encoder only works with specific resolution,
for h261 are 176x144 and 352x288.
for h263 are 128x96, 176x144, 352x288, 704x576 and 1408x1152.

[Inventive Software]

That might explain why I couldn't get them to work then.

[_xxl]

libavcodec decode:
int numthreads=deci->getParam2(IDFF_numLAVCdecThreads);
if (numthreads>1 && mpeg12_codec(codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=numthreads);
else
threadcount=0;
libavcodec encode:
if (coCfg->numthreads>1 && sup_threads(coCfg->codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=coCfg->numthreads);
else
threadcount=0;

Multithreading encoding was added in 2004.

[Inventive Software]

So proper multithreaded decode is only with MPEG-1 and MPEG-2... right?

[wyrd]

I found a bug in YV12 and odd number lines.
With old video renderer, it sometimes crashes. When aplication finishes or changed to full screen.
I confirmed it in rev731,732 (in my case, open view -> option)
samples (http://tirnanog.fate.jp/tmp/odd_line/)
Regards

[clsid]

List of known issues in revision 736:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Some files with interlaced H.264 video don't decode properly. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). FFmpeg bug or perhaps a x264 VFW bug? (Reported by Romario)
3) Encoding fails if threads > 1 for the following formats: DivX 3, MS MPEG-4 V2, H.263(+), WMV7, WMV8, MJPEG, DV and FLV1.

Other bug reports:

4) Writing an OGM file via VFW interface creates a corrupt file. (reported by clsid)
5) FLV muxer seems to be buggy as well.
6) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2 and DV. VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". At least some of these encoders do work for others? Seems to depend on the input? Sample input file (http://www.mytempdir.com/1105695). (reported by: a few people)
7) I think I have found a bug in the ffdshow subtitle filter. If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position. (reported by clsid)
8) There is an abnormal increase in CPU usage when the ffdshow audio panel is open during playback. (reported by foxyshadis)
9) Queue is off in Overlay Mixer. (reported by clsid)
10) ffdshow raw filter doesn't work in ZoomPlayer. (reported by midiboy)

ToDo:

11) Update SNOW
12) Fix VMnc decoding
13) Fix libavcodec VC-1 decoding
14) H.261 and H.263 encoders only support specific resolutions. An error message should be added and shown when an unsupported input resolution is used. H.261 supports 176x144 and 352x288. H.263 supports 128x96, 176x144, 352x288, 704x576 and 1408x1152.

Other issues:

15) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). These files should be very rare. Funny thing however is that the files play fine and without crash if you first play another file and then play the 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)

[Jeremy Duncan]

libavcodec decode:
int numthreads=deci->getParam2(IDFF_numLAVCdecThreads);
if (numthreads>1 && mpeg12_codec(codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=numthreads);
else
threadcount=0;
libavcodec encode:
if (coCfg->numthreads>1 && sup_threads(coCfg->codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=coCfg->numthreads);
else
threadcount=0;

Test my new build:
http://www.mytempdir.com/1145846

It works fine on my Pentium M 725.

Did you tweak how FFDshow multithreads ?

[Blight]

A couple of requests:

1. Can you expose the subtitle streams as an IAMStreamSelect interface with an option to select each subtitle stream and a last option to hide/show the subtitles?

2. Can you create a separate instance of ffdshow for the
subtitle filter (similar to how you have the RAW filter). This would make subtitling much more flexible (design-wise).

[MacAddict]

Hmm, wonder if it's possible to display 'queue samples' in the info window as well? As it is the only way to see it is to have OSD turned on right?

Looks like plenty of space exists just below the line that shows 'current frame' :-)

[Kurtnoise]

I've got some errors (http://kurtnoise.free.fr/BuildLog.htm) during lavc compilation...Any ideas ?

[_xxl]

Libavcodec can be compiled by MinGW GCC 3.4.x or 4.0.x.

[Inventive Software]

@clsid: You can update your "threads > 1 broken" list with H.263 as well.

[Romario]

Libavcodec can be compiled by MinGW GCC 3.4.x or 4.0.x.

Why not with 4.1.x or 4.2.x ?

[Px]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
http://www.mytempdir.com/1129848
I've finally got some time to do this, with FlightSimX_720p60_51_15Mbps.wmv and Test_1440x576_WVC1_6Mbps.wmv all works fine, cpu usage similar to ms codecs

[_xxl]

I've finally got some time to do this, with FlightSimX_720p60_51_15Mbps.wmv and Test_1440x576_WVC1_6Mbps.wmv all works fine, cpu usage similar to ms codecs
wmv9lib uses ms codecs to decode WVC1.You need to have WMP11 or ms vc1 codec.

[Kurtnoise]

Libavcodec can be compiled by MinGW GCC 3.4.x or 4.0.x.
...and can't be compiled with MSVC ?

[foxyshadis]

Not right now, some ffmpeg updates broke compatibility. It's only worthwhile for debugging, anyway, since it can't compile any of the assembly code. (Can ICL compile ffmpeg natively? I haven't tried, ICL doesn't work right for me since I upgraded to VS2005SP1, always internal linker errors about bad debug information.)

[Peuj]

Hi,

I use the lastest MPC rev611-3.2 and ffdshow_rev731_20061230_clsid.exe

When I try to play the mov from this link:
http://www.jeuxvideo.fr/telecharger-video-1-cinematique-d-introduction-39197.html

MPC freezes and I have to kill it. Something wrong with H.264 ?

Thanks

[fastplayer]

Plays fine here except I hear no sound. Don't know which decoder is needed...

Edit: It's IMA4 Audio. Trailer plays fine.

[Peuj]

Plays fine here except I hear no sound. Don't know which decoder is needed...

Edit: It's IMA4 Audio. Trailer plays fine.

Video #0
Codec : H.264
Codec/Info : H.264 (3GPP)
PlayTime : 1mn 42s
Bit rate : 2055 Kbps
Width : 720 pixels
Height : 486 pixels
Aspect ratio : 4/3
Frame rate : 29.970 fps
StreamSize : 25.1 MiB

Audio #0
Codec : ADPCM
PlayTime : 1mn 42s
Bit rate : 384 Kbps
Channel(s) : 2 channels
Resolution : 16 bits
StreamSize : 4.68 MiB


OK thanks. Something wrong on my computer so. :(

[SeeMoreDigital]

Yep... it plays fine for me too!

[fastplayer]

OK thanks. Something wrong on my computer so. :(
I'm using exactly the same version of MPC (system default renderer) and ffdshow as you. Maybe the file is broken... :?

[clsid]

Btw what happend to the snow? its several revs behind. i patched ffdshow with latest snow code from ffmpeg, playback seem to work fine here(encoded with latest mencoder).You can commit the patch to SVN if you want.
Could you also upload a sample SNOW file encoded with mencoder for all of us to put in our collections?

[_xxl]

http://forum.doom9.org/showthread.php?p=923987#post923987
Snow should be removed.

[clsid]

SNOW isn't backward compatible. But supporting playback of the latest version is better than no support at all.

[Taurus]

Hi,

I use the lastest MPC rev611-3.2 and ffdshow_rev731_20061230_clsid.exe

When I try to play the mov from this link:
http://www.jeuxvideo.fr/telecharger-video-1-cinematique-d-introduction-39197.html

MPC freezes and I have to kill it. Something wrong with H.264 ?

Thanks
With newest Haali's Media Splitter enabled I've got no sound too.
Haali's disabled - everythings just fine.
Apps same as mentioned in the quote.

[F_L_C]

Why don't you guys delete "Nightly builds by videomixer9" from the download page because it's apparent this developer is no longer active. The last updates were 5 months ago.

Also, one of clsid's old generic builds (rev696) somehow got placed into Q's old generic builds.

[Episode]

I'm pretty sure videomixer9 will eventually come back and start updating his builds again. Also, since he was one of the founding members of this project (ffdshow-tryouts), it wouldn't be nice to remove he's builds ;-)

[foxyshadis]

They're just builds, they can be remade or reuploaded. They should probably go in an 'archived builds' section otherwise. Once in a while it helps to test really old builds when checking out when a bug appeared.

[edit] Too late, they've already been set hidden. :p

[Inventive Software]

Feature request: incorporate libavformat and have it similar to ffdshow's configuration currently. Not sure how practical this is, but it'd be nice for ffdshow to have the source "splitters" or container formats support as well as the codecs, thus making ffdshow the premier DShow filter. :)

[Peuj]

With newest Haali's Media Splitter enabled I've got no sound too.
Haali's disabled - everything just fine.
Apps same as mentioned in the quote.

Ok the problem was that the nero splitter was used instead of ffdshow. I have changed the merit filter with GSpot to use ffdshow.

About the sound I have enabled IMA ADPCM in ffdshow audio and I have no problem with Haali.

Just to know: is there another way to change the merit filter instead GSpot ?

Thanks

[HeadBangeR77]

(...)

Just to know: is there another way to change the merit filter instead GSpot ?

Thanks

This is obviously an OT, but here you are:

http://www.softella.com/dsfm/index.en.htm

the best tool for setting merits I've ever used - freeware and a single executable only ;)

In order to remain in the main topic:
I installed a new nightly build yesterday, namely 'ffdshow_rev735_20070102_xxl', and the 'about section' says it is in fact tryout revision 621. The rest (e.g. dates of compilation of different libraries) seems to be up-to-date, so I hope it's just a simple typo, isn't it?

Btw. I've been reading through Doom9's Forums for years before registering and posting - believe me or not, but it's a strange feeling, this 'first time', like experiencing deja-vu :D ;)

cheers /HeadB.

[wyrd]

It seems good for me.
ffdshow_rev735_20070102_xxl.exe MD5:BE9C97EB299EAA9B68F0E66ADC64CEB4
http://tirnanog.fate.jp/tmp/snap/xxl_735_t.jpg (http://tirnanog.fate.jp/tmp/snap/xxl_735.jpg)

@Peuj,as you please
http://tirnanog.fate.jp/tmp/snap/dftools_t.jpg (http://tirnanog.fate.jp/tmp/snap/dftools.jpg)
Thanks

[HeadBangeR77]

@ wyrd

I already know what I did: I uninstalled the previous version (621) and installed the newer one (735), then messed up with some settings, and returned to the old ones by adding them to the registry from my back-up files. Those back-ups contain all decoder settings, including version and compilation date. Weird, the compilation date (2nd of Jan) is all right, the revision number was taken from the old build :D

Are those registry values (build number and compilation date) there for a certain reason (I mean the exported back-ups, of course), or just to make a humble user crazy in the middle of the night? ;) ;) ;)

[Dark_Angel_PT]

drevil_xxl:
Do you own the domain in your sig?
Why doesn't it directs to the new webpage (that i personally like BTW)at ffdshow-tryout.sourceforge.net ?


I posted two suggestions to the OSD in the ffdshow forum, would like to know what you think...

http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=226

[foxyshadis]

http://www.zend.com/forums/index.php?t=msg&goto=2272&S=747c3b529f3fe9d65756e24d1d443699

Do you guys think this will be useful? It could be used to automatically update the version resource (mainly for zoomplayer and the curious) as well as the rev numbers in the build scripts.

[Yong]

My lastest build, for testing only
http://y0ngc6.googlepages.com/ffdshow_rev738_20070105.exe
compiled with lastest snow code from ffmpeg,
and the ffmpeg binary
http://y0ngc6.googlepages.com/ffmpeg-r7407.7z

NOTE: the snow bitstream has changed, do not use older snow created by old revision of mencoder/ffmpeg to play with this build.

[haruhiko_yamagata]

http://www.zend.com/forums/index.php?t=msg&goto=2272&S=747c3b529f3fe9d65756e24d1d443699

Do you guys think this will be useful? It could be used to automatically update the version resource (mainly for zoomplayer and the curious) as well as the rev numbers in the build scripts.
SubWCRev.exe depends on TortoiseSVN. Considering most of us are using TortoiseSVN, it may be usefull. But the code should be written carefully not to depend too much on TortoiseSVN. At least have to work around if TortoiseSVN is not used for the working copy. Too hard :scared: .

The registry where to store revision need reconsidering.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ffdshow_is1 may be better.

[clsid]

If TortoiseSVN is installed, then verinc.exe should use the the revision as micro version. Else increment existing version (current behaviour).

Another possibility would be to remove verinc.exe completely and manually adjust the version. I think that manually adjusting the version once every X revisions (25,50,100?) will be enough.

Edit: Changing the registry key location has some major downsides. First, InnoSetup overwrites the uninstall key at the end of the installation. So keys also need to be written at the end from [code] section to prevent them from being deleted. Second, using the uninstall key binds the info explicitly to our installer. So the info can't be used by NSIS installer, codec packs, etc.

[chros]

I'm using Winamp's DFX plugin for a long time, to increase the audio quality.
There's a new version of it (8.0) which can deal with multichannel source ! But ffdshow doesn't allow to connect them ...
There's a source which shows the splitter that it has only 2ch audio but it has true 5.1: it works well with DFX.

Can you do anything about this?

Thanks

[dk75]

maybe you should post the sample of this file with 5.1ch/2ch problem?

[haruhiko_yamagata]

libmpeg2 : bug fix : MPEG 1/2 seek issue.
Crash and artifact on seek(or startup) is fixed.
Now we can seek better in FruitBeer.vob.
No more green artifact at the startup of hbo_trailer_6ksd.ts.
No more crash on seek in this sample (http://www.stronger.jp/figure/dl/pv/figurehead_pv.lzh). To reproduce:With Zoom player + gabest's MpegSplitter, it crashes on first few seeks. If you secceeded several times, you have to restart the application.

[fastplayer]

:thanks: a bunch for the fix!
This should get ffdshow's MPEG2 decoder closer to MPC's which has no problems playing these files back by the way.

[cc979]

just tried to compile rev.752 usinggcc-4.0.3 i get this

make[1]: *** [FLT_ffdshow.o] Error 1
make[1]: Leaving directory `/home/user/svn/ffdshow-tryout/trunk/dscaler'
make: *** [DSCALER] Error 2

[_xxl]

The same error:
FLT_ffdshow.cpp:174:2: warning: no newline at end of file
../src/imgFilters/avisynth/avisynth.h: In member function 'int VideoInfo::GetPlaneWidthSubsampling(int) const':
../src/imgFilters/avisynth/avisynth.h:228: error: exception handling disabled, use -fexceptions to enable

-fno-exceptions is used.

[Yong]

try "make EXCEPTIONS=1"

[foxyshadis]

I fixed avisynth.h so it doesn't rely on exceptions again (unnecessary for what it does).

[MatMaul]

Hello !
I proposed some adds for the audio part of ffdshow :

- Add a volume control on the left click of the audio ffdshow icon in the system tray, like with the Windows mixer icon :

http://www.etud.insa-toulouse.fr/~mvelten/volume.png

- Add an option to reset the volume control when the filter is loaded, to not have a +15dB if the volume of the audio is high :p

http://www.etud.insa-toulouse.fr/~mvelten/reset.png

[clsid]

List of known issues in revision 755:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Some files with interlaced H.264 video don't decode properly. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). FFmpeg bug or perhaps a x264 VFW bug? (Reported by Romario)

Other bug reports:

3) The following encoders do not work for me: MPEG 1, MPEG 2 and DV (does DV have input limitations like H263?). VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". (reported by: clsid)
4) I think I have found a bug in the ffdshow subtitle filter. If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position. (reported by clsid)
5) There is an abnormal increase in CPU usage when the ffdshow audio panel is open during playback. (reported by foxyshadis)
6) Queue is off in Overlay Mixer. (reported by clsid)
7) ffdshow raw filter doesn't work in ZoomPlayer. (reported by midiboy)

ToDo:

8) Update SNOW
9) Fix VMnc decoding
10) Fix libavcodec VC-1 decoding
11) H.261 and H.263 encoders only support specific resolutions. An error message should be added and shown when an unsupported input resolution is used. H.261 supports 176x144 and 352x288. H.263 supports 128x96, 176x144, 352x288, 704x576 and 1408x1152.

Other issues:

12) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). These files should be very rare. Funny thing however is that the files play fine and without crash if you first play another file and then play the 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)

[Episode]

@clsid, for some reason my computer decided to reboot itself automaticly after installing your latest build (752). I didn't see any question whether I want to reboot my computer, so I assume that it's a bug since it happened again when I tried to install it again.

[clsid]

Are you sure that there wasn't a restart option on the last page of the installation wizard?



@all, since this topic is getting very long, I have created a fresh topic. So please continue the discussions there:
http://forum.doom9.org/showthread.php?t=120465

If a mod reads this, please lock this topic.

[Episode]

Yes, I'm sure. I can reproduce this bug every time I try to install build 752. However, it doesn't happen with any other builds. There isn't any restart option on the last page. And if there is a need for restart, the installer should ask again if you really want to do that :)

[clsid]

It uses the same install script as previous builds. Also if a restart is needed, InnoSetup will always give an option. Perhaps ffdshow is causing a BSOD which makes your computer restart.

I'll put a new build online.

[Episode]

It wasn't a BSOD, but that doesn't matter anymore since the new build seems to install correctly without restart. Thanks a lot.