ffdshow tryouts project: Discussion & Development

[LoRd_MuldeR]

I give up. Those rules are insane. Hack the address then do this , don't that ...

Well, you must understand that ffmpeg is a huge project and the devs don't want to be bombed with tons of noob questions...

[KoD]

The performance when going from VS2003 to VS2005 and VS2008 should be naturally worse, since each new version of the C compiler generates more additional code to improve security: more exception code handling, some functions are replaced with calls to slower functions that do buffer size checking, memory guards to detect buffer overflows and other techniques used to hijack code. These pieces of code decorate each function call, some decorate memory handling functions, so obviously performance will drop as each call will have to waste more time doing something else than just what was intended from it. A few of these improvements in security but which ultimately hurt performance are described in the MSDN magazine here (http://msdn.microsoft.com/en-us/magazine/cc337897.aspx).

While I can see why these would be necessary on an application that deals with accounting, data security and such, they seem out of place from multimedia applications which primarily need to be fast.

Edit: forgot to say that the new versions of the C runtimes are compiled as such as well, so the slowdown comes mostly from using them.

[_xxl]

The performance when going from VS2003 to VS2005 and VS2008 should be naturally worseI have remembered that some time ago ffdshow compiled by VC6 + ICL8 was the fastest.

[yesgrey]

While I can see why these would be necessary on an application that deals with accounting, data security and such, they seem out of place from multimedia applications which primarily need to be fast.

Well, if the software is not slowed down, why will we need new and faster cpus?... ;)

[STaRGaZeR]

Well, if the software is not slowed down, why will we need new and faster cpus?... ;)

Because you will be able to do the same in a fraction of time. When you're dealing with huge amounts of time required for a specific task even a 10% is a huge improvement. Time is money ;)

[CruNcher]

Does somebody know if x264-hd benchmark test clip (test-720p.mpg) is broken i get strange artifacts per frame rendering with libavcodec (Mpeg-2) also with ffplay, libmpeg2 rendering is fine very strange, also some decoder signal SD for that clip i wonder what's going on with the bitstream.

http://s11b.directupload.net/images/081127/rln5orow.png (libavcodec)
http://s10b.directupload.net/images/081127/td5c4z54.png (libmpeg2)

i don't have time currently (testing a new commercial GPU video product,and preparing my own stuff) to fight around looking @ whats happening here just found it by accident testing my encoding framework, maybe someone else has :)

[haruhiko_yamagata]

While I can see why these would be necessary on an application that deals with accounting, data security and such, they seem out of place from multimedia applications which primarily need to be fast.Do you think security is not important for multimedia applications? I don't think so. The security issue that has been fixed recently was so serious that I had to admit sacrificing MSVC7/MinGW 4.0.x and even adding a few bugs. ffdshow can be used from web browsers. Just clicking a link can trigger its security hole and infect a virus.

By the way, it's not getting slower for me.
Test file: premiere-paff.ts (H.264)
2373 MCVC9
User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 542.0, dfps: 99.4

2373 ICL
User: 2s, kernel: 0s, total: 2s, real: 11s, fps: 460.3, dfps: 103.4

2301 MSVC7
User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 583.3, dfps: 96.1

2301 ICL
User: 2s, kernel: 0s, total: 2s, real: 11s, fps: 549.8, dfps: 103.1

[LoRd_MuldeR]

Do you think security is not important for multimedia applications? I don't think so.

Security is very important in multimedia applications. If you follow the Newstickers, you read about "new" exploits in VLC Player and friends every few days...

@KoD
If there is a buffer overflow in your multimedia application, an attacker can easily execute his own (destructive) code on your local machine, just by providing a manipulated audio/video file :scared:
You really can't want that unresolved and you should be thankful to the developers for taking care of it...

[LoRd_MuldeR]

Here is another benchmark, this time I used another (longer) file:

E:\HD\x264.736.aq.0.48.8mbit.mkv

[ffdshow r2373 ICL, 4 threads]
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 177.1, dfps: 33.8
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 174.1, dfps: 33.8
User: 4s, kernel: 1s, total: 6s, real: 33s, fps: 180.7, dfps: 33.8

[ffdshow r2373 MSVC, 4 threads]
User: 5s, kernel: 0s, total: 6s, real: 33s, fps: 185.8, dfps: 33.7
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 170.0, dfps: 33.5
User: 5s, kernel: 0s, total: 6s, real: 33s, fps: 177.5, dfps: 33.1

[ffdshow r2335 ICL, 4 threads]
User: 5s, kernel: 1s, total: 6s, real: 32s, fps: 173.7, dfps: 34.0
User: 4s, kernel: 1s, total: 6s, real: 33s, fps: 179.3, dfps: 33.9
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 166.4, dfps: 33.2

[ffdshow-MT r2368 MSVC, 4 threads]
User: 4s, kernel: 0s, total: 4s, real: 12s, fps: 226.4, dfps: 88.0
User: 4s, kernel: 0s, total: 4s, real: 12s, fps: 227.1, dfps: 87.6
User: 4s, kernel: 0s, total: 4s, real: 12s, fps: 239.3, dfps: 87.2

Conclusions: Difference between MSVC and ICL is negligible. Difference between r2373 and 2335 is negligible too. The MT branch still rules (no surprise).

[clsid]

Those are better results :)

[CruNcher]

Forceware 180.70 (Nvidia G92)

Null

CoreAVC = User: 5s, kernel: 0s, total: 5s, real: 31s, fps: 702.2, dfps: 110.9, Memory: 50
DivX = User: 6s, kernel: 0s, total: 6s, real: 37s, fps: 505.4, dfps: 93.3, Memory: 50
ffdshow-mt = User: 7s, kernel: 0s, total: 7s, real: 55s, fps: 454.5, dfps: 63.0, Memory: 52
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 58s, fps: 9800.3, dfps: 60.0, Memory: 161
Cyberlink = User: 13s, kernel: 0s, total: 13s, real: 58s, fps: 268.3, dfps: 60.2, Memory: 115
MPC VideoDecoder = No measuring possible (doesn't start rendering) also not if DXVA is disabled

VMR7 (low to none kernel activity)

CoreAVC = User: 7s, kernel: 0s, total: 8s, real: 58s, fps: 436.8, dfps: 59.9, Memory: 56
Arcsoft = User: 1s, kernel: 0s, total: 1s, real: 58s, fps: 2398.0, dfps: 60.0, Memory: 157
Cyberlink = User: 11s, kernel: 1s, total: 12s, real: 58s, fps: 281.8, dfps: 60.7, Memory: 250
DivX = User: 8s, kernel: 1s, total: 9s, real: 59s, fps: 366.5, dfps: 58.8, Memory: 56
ffdshow-mt = User: 8s, kernel: 0s, total: 9s, real: 64s, fps: 378.2, dfps: 54.8, Memory: 56
MPC VideoDecoder = User: 8s, kernel: 1s, total: 9s, real: 79s, fps: 359.5, dfps: 44.2, Memory: 40

Overlay (GPU) (0-1.4x% CPU,low to none kernel activity)

MPC VideoDecoder = User: 0s, kernel: 0s, total: 1s, real: 61s, fps: 3087.8, dfps: 57.4, Memory: 31
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 72s, fps: 22540.8, dfps: 48.5, Memory: 60
Cyberlink = No measuring possible falls back to CPU

VMR7 (GPU) (0-1.4x% CPU,low to none kernel activity)

MPC VideoDecoder = User: 0s, kernel: 1s, total: 2s, real: 61s, fps: 1720.7, dfps: 57.3, Memory: 82
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 72s, fps: 17339.1, dfps: 48.3, Memory: 109
Cyberlink = No measuring possible falls back to CPU

VMR9 (GPU) (0-2.x% CPU, kernel activity peaking)

MPC VideoDecoder = User: 0s, kernel: 1s, total: 2s, real: 61s, fps: 1720.7, dfps: 57.3, Memory: 85 (heavy kernel peaking)
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 78s, fps: 8348.4, dfps: 45.0, Memory: 94
Cyberlink = No measuring possible falls back to CPU


GPU = 100W (CPU idle 1.1 GHz, 1.1v)
CPU = 175W (GPU Idle + CPU Load 2.5 GHz, 1.35v)

Hmm Arcsoft and Cyberlink behave different (GPU) benchmarking with timecodec (Cyberlink uses 100% CPU) it seems Cyberlink falls back to CPU rendering running within timecodec

PS: Arcsofts Decoder renders definitely more files successful in GPU Mode (outside timecodec) then Cyberlink does using VMR 7 (stays black a lot of times with Cyberlinks Decoder)
MPC - Video Decoder (DXVA) has especially problems with Broadcast Related Bitstreams (for Progressive it seems the most efficient) except under VMR9 here MPC Video Decoder shows up some really bad performance in Kernel times (Win XP)

CoreAVC vs GPU is a easy answer (for playback) especially for people with older CPUs and already installed next Gen GPU it makes no sense to use CoreAVC as the Power Saving can be very big in this situation up to 75W

[Snowknight26]

Half the time I enable visualizations in ffdshow they either don't show (quants/MVs) or they do show but they show zeroed results (graph is a flat line).

[LoRd_MuldeR]

I never really understood what "Graph" is supposed to do. It looks like a solid block moving from the right to the left, not really what a graph is supposed to look like :confused:

However "Motion vectors" and "Quantizers" seem to work as expected for me. That is with MPEG-2 and H.264 sources.

[Thunderbolt8]

Reported!
ID 734 https://roundup.mplayerhq.hu/roundup/ffmpeg/issue?status=-1,1,2&@sort=-activity&@search_text=&@dispname=Show%20Unresolved&@filter=status&@group=priority&@columns=id,activity,title,creator,assignedto,status&@pagesize=50&@startwith=0&assignedto=429
libav already made problems some time ago when I had that sample of the galapagos hd dvd, which was 1080i 29.97fps. back then haruhiko_yamagata disabled vc-1 support for libavcodec, since it was buggy I guess.

[LoRd_MuldeR]

With recent ffdshow builds I get a strange problem with the "Greedy 2 Frame" deinterlacer (available as DScaler plugin).
During playback I get see strange flickering and in the config menu the sliders behave in a strange way. When I move one slider, the other one will be reset to "0".

Any ideas? Maybe related to the move to VS2008 ??? :confused:

[Snowknight26]

I never really understood what "Graph" is supposed to do. It looks like a solid block moving from the right to the left, not really what a graph is supposed to look like :confused:

Should look like this: http://www.stfcc.org/misc/visualizations.working.jpg
And not working obviously: http://www.stfcc.org/misc/visualizations.notworking.jpg

However "Motion vectors" and "Quantizers" seem to work as expected for me. That is with MPEG-2 and H.264 sources.

I wish that was the case for me. 50% of the time isn't good enough. :\

[haruhiko_yamagata]

I never really understood what "Graph" is supposed to do. It looks like a solid block moving from the right to the left, not really what a graph is supposed to look like :confused:The graph renders the input bit rate. One column represents one frame. So there should be peaks and dips if a good encoder is used.

[haruhiko_yamagata]

With recent ffdshow builds I get a strange problem with the "Greedy 2 Frame" deinterlacer (available as DScaler plugin).
During playback I get see strange flickering and in the config menu the sliders behave in a strange way. When I move one slider, the other one will be reset to "0".

Any ideas? Maybe related to the move to VS2008 ??? :confused:I can reproduce if the clip has mixed flags of interlaced and progressive. "Process frames flagged as progressive" is related.

[haruhiko_yamagata]

I wish that was the case for me. 50% of the time isn't good enough. :\It works only if libavcodec is used as decoder.

[Yong]

Hi, im here to report the ffdshow latest svn compiling problem,

1. compiling ffdshow.ax with msvc2008 sp1, comment out this 2 line compiling will work without any error.
IIRC older compiler, e.g. msvc 2005 and gcc also have problem with this 2 lines.
1>.\src\audioFilters\TaudioFilter.cpp(252) : error C2664: '_mm_castps_si128' : cannot convert parameter 1 from 'const __m128' to '__m128 &'
1> Conversion loses qualifiers
1>.\src\audioFilters\TaudioFilter.cpp(253) : error C2664: '_mm_castps_si128' : cannot convert parameter 1 from 'const __m128' to '__m128 &'
1> Conversion loses qualifiers

2. when compiling the ff_wmv9.dll with mingw-gcc4.2.1sjlj
dllwrap -mno-cygwin --target=i686-pc-mingw32 \
-Wl,--enable-stdcall-fixup --strip-all \
--def ff_wmv9.def -o ../../../bin/ff_wmv9.dll ff_wmv9.o GenProfile_lib.o nssBuffer.o videoenc.o writerSink.o include/wmguids.o ../../imgFilters/ffImgfmt.o combase.o -lstdc++ -lsupc++ -luuid -lole32 -loleaut32 -lwinmm -lgdi32 -ldxguid
../../imgFilters/ffImgfmt.o:ffImgfmt.cpp:(.text+0x3e1): undefined reference to `int _snwprintf_s<wchar_t>(wchar_t*, unsigned int, unsigned int, wchar_t const*, ...)'
../../imgFilters/ffImgfmt.o:ffImgfmt.cpp:(.text+0xc43): undefined reference to `int _snwprintf_s<wchar_t>(wchar_t*, unsigned int, unsigned int, wchar_t const*, ...)'
collect2: ld returned 1 exit status
E:\msys\mingw\bin\dllwrap.exe: E:\msys\mingw\bin\gcc exited with status 1
make: *** [../../../bin/ff_wmv9.dll] Error 1
make: Leaving directory `/sources/ffdshow/src/codecs/wmv9'

but msvc2008 sp1 compile just fine.

Im sorry if the infomations i provided are not enough.. :p

[haruhiko_yamagata]

Hi, im here to report the ffdshow latest svn compiling problem,

1. compiling ffdshow.ax with msvc2008 sp1, comment out this 2 line compiling will work without any error.
IIRC older compiler, e.g. msvc 2005 and gcc also have problem with this 2 lines.
It depends on Platform SDK version. Which macro should we use to check SDK version?

2. when compiling the ff_wmv9.dll with mingw-gcc4.2.1sjlj

but msvc2008 sp1 compile just fine.

Im sorry if the infomations i provided are not enough.. :pGCC compilation of ffdshow.ax and ff_wmv9.dll was dropped at rev 2349. Please use MSVC9.

[Snowknight26]

It works only if libavcodec is used as decoder.

The only settings that were changed in my 2 screenshots was the order in which I checked the Visualization options. Both times the video was being decoded with libavcodec.

[haruhiko_yamagata]

The only settings that were changed in my 2 screenshots was the order in which I checked the Visualization options.How is it different?

[Snowknight26]

Not entirely sure what you're asking.

[haruhiko_yamagata]

Can anybody help us to understand each other?

By the way, I'm going into bug fix/finalizing phase.
What is left for next stable release?

[fastplayer]

Revision 2390
Modified Sat Nov 29 13:23:50 2008 UTC (4 minutes, 39 seconds ago) by h_yamagata

libavcodec MPEG-2: fix timestamps issue (DVD)
Is this the issue MatMaul (http://forum.doom9.org/showthread.php?p=1214645#post1214645), me (http://forum.doom9.org/showthread.php?p=1107246#post1107246) and a couple of others reported about?

[LoRd_MuldeR]

The graph renders the input bit rate. One column represents one frame. So there should be peaks and dips if a good encoder is used.

Doesn't look like that for me :confused:

http://img58.imageshack.us/img58/1982/grapheu7.th.png (http://img58.imageshack.us/my.php?image=grapheu7.png)

Maybe the stream is CBR, but I don't think so. Even streaming isn't perfect CBR, but allows some local ratecontrol optimizations...


I can reproduce if the clip has mixed flags of interlaced and progressive. "Process frames flagged as progressive" is related.

The funny thing is: When I configure ffdshow "offline" the sliders work just fine.

But as soon as a media is playing, they go crazy. Move one slider, get the other one reset to zero.

Any chance for a fix? :o

[fastplayer]

What is left for next stable release?
I can tell you exactly what's left: A proper changelog! :D
I really hope that all devs have kept track of what they've added/changed/fixed since the beta5 release.
If you have something that's "readable", PM me! :)

[haruhiko_yamagata]

Is this the issue MatMaul (http://forum.doom9.org/showthread.php?p=1214645#post1214645), me (http://forum.doom9.org/showthread.php?p=1107246#post1107246) and a couple of others reported about?Yes, it will be OK.

[haruhiko_yamagata]

Doesn't look like that for me :confused:

http://img58.imageshack.us/img58/1982/grapheu7.th.png (http://img58.imageshack.us/my.php?image=grapheu7.png)

Maybe the stream is CBR, but I don't think so. Even streaming isn't perfect CBR, but allows some local ratecontrol optimizations...
It works better for me. What is the video format and which decoder is used?

The funny thing is: When I configure ffdshow "offline" the sliders work just fine.

But as soon as a media is playing, they go crazy. Move one slider, get the other one reset to zero.

Any chance for a fix? :oSimply wait for the next build, please :D .

[haruhiko_yamagata]

I can tell you exactly what's left: A proper changelog! :D
I really hope that all devs have kept track of what they've added/changed/fixed since the beta5 release.
If you have something that's "readable", PM me! :)OK, I will update.
@developers, please add your work to the change log.

[fastplayer]

OK, I will update.
@developers, please add your work to the change log.
What changelog do you mean? Is there one I don't know about?

Once I have all the bits and pieces, I'll integrate it into the wiki-changelog, right here:
http://ffdshow-tryout.wiki.sourceforge.net/Changelog

FYI, the web documentation is dead. The wiki is the future:
http://ffdshow-tryout.wiki.sourceforge.net/
It's a bit easier to maintain and hopefully will encourage people to participate and add content. I said "hopefully" because nobody has added one single line since I set up the wiki a few months ago...
Multiple language support has been dropped because it's a pain-in-the-butt to keep it synchronized and I'd rather see all our efforts focused on one good documentation than on 3 mediocre ones... By the way, this was clsid's idea. So if you have a problem with that, argue with him. Yeah, good luck with that... :p

[LoRd_MuldeR]

It works better for me. What is the video format and which decoder is used?

Source: DVB Source, MPEG-2
Decoder: libavcodec mpeg2video

Simply wait for the next build, please :D .

:thanks:

[clsid]

The idea is to eventually have documentation in the Wiki for the many options that ffdshow has. Any volunteers that are willing to write some pieces of documentation? Even small pieces are welcome.

Perhaps we could let the installer create a link to the Wiki in the start menu (once the wiki has more content of course)? That would make it known to the general public. But before we allow the general public to edit the wiki it would be useful if there were some moderators that could monitor changes and undo vandalism.

[clsid]

Fresh builds will be online shortly :cool:

@Albain,
FFmpeg now appears to support decoding of DTS-HD:
http://svn.mplayerhq.hu/ffmpeg?view=rev&revision=15951

[fastplayer]

But before we allow the general public to edit the wiki it would be useful if there were some moderators that could monitor changes and undo vandalism.
Permissions are already set to "public" and it has been like that for 3 months. So far nobody has done anything legally or illegally...
I'm keeping an eye on the "recent changes" list almost daily and I make backups regularly. So I wouldn't be too much concerned about abuse and such. I am more concerned about the lack of content... :(

[clsid]

The wiki is not easy to find. The default webpage view on SourceForge hides several menu items, including the wiki. So I suspect that is one of the reasons for the lack of activity.

[STaRGaZeR]

By the way, I'm going into bug fix/finalizing phase.
What is left for next stable release?

I would like to remember a very useful proposition Leak did back in October:

http://forum.doom9.org/showthread.php?p=1208512#post1208512

http://forum.doom9.org/showthread.php?p=1208726#post1208726

I'm asking mainly because forcing ATi's deinterlacer in soft telecined frames (for the reasons discussed before in this thread) produces bad effects if you send it the field information instead of just plain progressive frames. Maybe a simple checkbox could do the trick, that way the "Apply pulldown" option will remain effective (like it is now) or not (like it was in rev2236), users could decide.

[fastplayer]

The wiki is not easy to find. The default webpage view on SourceForge hides several menu items, including the wiki. So I suspect that is one of the reasons for the lack of activity.
I agree and the wiki visual editor does not work with Opera and Safari browsers. Not exactly a show stopper but far from the user-friendliness and ease of use that wikis suggest...

[clsid]

Here are some bugs that have been reported in the past. Can anyone confirm if they are still present in revision 2391? If not, I will remove them from the bugtracker:

# Cubic blending deinterlacer doesn't work.
# Anamorphic MPEG-1 video displays with incorrect aspect ratio when using libavcodec as decoder.
# ttxt subtitles are always rendered in italic with small size and with times (new) roman font
# amr audio decoding doesn't work in 64-bit builds?

And here are a few more:
http://sourceforge.net/tracker/index.php?func=detail&aid=2333334&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1924063&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2215967&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1673817&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1952999&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2028210&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2056124&group_id=173941&atid=867360

[LoRd_MuldeR]

I think I mentioned it before, but the following deinterlacing filters don't deinterlace:
"Framerate doubler" and "Cubic blending"

If these can't be fixed easily, I think the code should be disabled/removed. There are enough alternatives.

BTW: What is "Bypass" good for? If the user doesn't want to deinterlace, (s)he can simply uncheck deinterlacing. Unless it's required for some special purpose, it could be removed too.

[fastplayer]

By the way, what's the name of the next release? Beta6? RC1? 1.0? :eek:
How about a preliminary changelog? So all you devs can log your changes in one central place, then we can clean out and streamline it into something presentable later.
Here you go:
http://ffdshow-tryout.wiki.sourceforge.net/IWantToBeAChangelogWhenIGrowUp

[STaRGaZeR]

Cubic blending does not work.

[ 2333334 ] no interlaced flag since rev23xx --> I've been using it with EVR Custom since forever, never had a problem like no flags whatsoever. Only bugs that have been corrected over time.

[ 2028210 ] Problemm with cropping --> Wasn't it fixed in rev2292? It's working for me, "Process whole image" should be checked.

[ 2056124 ] mpeg2 decoding/colorspace conversion bug --> The HQ vs noHQ is not a bug, but a feature. But I can't explain the difference between libmpeg2 and libav with HQ enabled.

[clsid]

It will be: Beta 6.

Most info can be found in the SVN log:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log

I am not really in the mood to convert that into a changelog. If you want to do it, go ahead. Don't forget to exclude the commits to the ffmpeg-mt branch. Many groups of commits can be summarized, e.g.: Added support for E-AC3 and Dolby TrueHD/MLP audio.

Beta 4 = revision 1685
Beta 4a = revision 1723
Beta 5 = revision 2033

[clsid]

Most of the page links in the wiki point to non-existing pages. Could you perhaps create empty stub pages? I think that will lower the threshold for people to add content. Also, page names are then created in an organized way. Stub pages could look like this:
Page Title

This page has no content yet. Please contribute!

[fastplayer]

Most of the page links in the wiki point to non-existing pages. Could you perhaps create empty stub pages? I think that will lower the threshold for people to add content. Stub pages could look like this:
Page Title

This page has no content yet. Please contribute!
Yes, I'm going through the SVN changelog. The question is: Should multiple fixes for one feature/option be summarized (like "Fixes for RemoteAPI") or should each fix be listed explicitly?

Edit: I'll make the stubs later. :)

[yesgrey]

Can anybody help us to understand each other?

When opening a video file with Visualizations unchecked and all options disabled nothing shows, as supposed.
If while watching the file you open the ffdshow dialog and then check the Visualizations, whitout any options being enabled, if then you start enabling the options nothing shows.

Summarizing: You only could see the Visualizations if any option is checked prior to checking the Visualizations check box.

[Leak]

Summarizing: You only could see the Visualizations if any option is checked prior to checking the Visualizations check box.
So, in other words, changing the types of visualization to display while they're already being displayed does nothing?

You're right, if you uncheck all four checkboxes on the "Visualizations" page, open a file and check the "Vizualizations" check box first followed by any of the others they won't have any effect.

Toggling the "Vizualizations" checkbox off and back on makes them appear, though.

EDIT: silly me thought I had a problem with quantizers, but of course resizing the image via AviSynth is bound to make them (and the motion vectors in case you also crop the image) go totally bonkers...

np: Gas - Track 5 (Gas)

[KoD]

Regarding the pass to VS2008: I've done a few tests so far with clisd's icl builds and there are indeed no speed differences between the pre and post ffdshow revisions. I've checked both simple video decoding scenarios, as well as other scenarios that could be common like when deinterlacers, resizing or color conversions are used. The end result was: there was no (absolutely none, actually) difference in speed for the ICL compiled builds. I wasn't keen on testing the builds that use only the VS2008 C compiler, as I don't use them.

Finally, a few bugs that have been reported before but I don't know if they're accounted officially:
1. mpeg1 layer 3 in avi files causes "clicks" when libavcodec is used as a decoder (Microsoft's avi splitter is used); same files don't show this behavior when mp3lib for instance is used
2. mpeg1 layer 2 in mpg files also causes clicks when libacodec is used as a decoder (Microsoft's mpeg splitter is used); same files don't show this behavior when mp3lib for instance is used

When extracting the mp3 or mpeg1 layer 2 audio from the video file and playing it as is, libavcodec doesn't generate those clicks anymore.

There has to be something wrong in how the libavcodec decoder expects the audio frames it receives to be formatted or such, as other decoders don't have this issue.

[clsid]

Yes, I'm going through the SVN changelog. The question is: Should multiple fixes for one feature/option be summarized (like "Fixes for RemoteAPI") or should each fix be listed explicitly?
If the SVN log mentions some specific details about a fix, then it might be useful to mention those details in the changelog as well. Fixes that don't include much details can be grouped together. Multiple fixes for the same issue can also be summarized. Just do whatever you think is best.