ffdshow tryouts project: Discussion & Development

[Episode]

@squid_80, notice that it says word may, not must.

[haruhiko_yamagata]

I guess you mean this part (I can't read your quote):
Yes, Japanese version does not have as an entire set. Of course, Japanese version is as official as English one.

[Dr Pizza]

Is "VISTA_SPDIF" needed in x64 build?I don't have win64 and can't test this.

Dunno. I don't have anything attached to the SPDIF headers on my motherboard, so I have no real way of knowing what's going on with that.

[clsid]

ffdshow tryouts is a nominee for the SourceForge.net Community Choice Awards in the category "Best Project for Multimedia".

Vote here:
http://sourceforge.net/community/index.php/landing-pages/cca07/

In the unlikely event that ffdshow wins, we may choose a charity that will receive a donation.

Are there any suggestions for a good charity? I was thinking about something like the World Wildlife Foundation or an aids or cancer foundation.

[magnusr]

Is "VISTA_SPDIF" needed in x64 build?I don't have win64 and can't test this.

Sorry cant answer that since i stopped using spdif (spdif cant handle 6 channel pcm audio, only 2). Need 6 channel pcm audio for HD-DVD so I can enjoy DD+, dts-hd etc.

And can you belive this my ati 2600xt cant handle dd+ or dts-hd throuh its hdmi ouput (only 2 channel pcm, ac3 and dts here also). Its like a nerfed hdmi with spdif built in.

Atleast my PS3 gets 6 channel pcm over the hdmi cable :)

Getting off topic here. sorry.

[Dr Pizza]

Wouldn't it ultimately be easier/more robust if the installer, instead of bundling the .dll and the manifest, just bundled the redist .exe? That way the .ax and other .dlls wouldn't need any special manifest file or anything (just the embedded manifest the linker puts in automatically). I suppose it would make the installer a little larger.

[Dr Pizza]

@squid_80, notice that it says word may, not must.

"may" confers permission, not ability; you have permission to (i.e. you "may") distribute the files as a complete set. It says nothing about distributing partial sets. And because it doesn't say you can, it means you can't.

[haruhiko_yamagata]

Wouldn't it ultimately be easier/more robust if the installer, instead of bundling the .dll and the manifest, just bundled the redist .exe? That way the .ax and other .dlls wouldn't need any special manifest file or anything (just the embedded manifest the linker puts in automatically). I suppose it would make the installer a little larger.ffdshow.ax.manifext and ff_vfw.dll.manifest is required to enable Xp visual style for Windows Xp x64, even with the redist installed. I think it's a bug of Windows Xp. Windows Vista has different behavior.

[Dr Pizza]

XP x64 is frankly pretty unloved by MS; that sure sounds like a bug, as I don't think visual styles should need a separate manifest.

[Leak]

Is there a reason EVR isn't in the list of compatible filters for output format changes? I'd have a patch that adds it ready to go unless there's some showstopper problem with it that I'm unaware of - seems to work fine for me in XP with .Net 3.0 installed and MPC Homecinema 1.0.9.0 when I uncheck the "compatible only" option.

[magnusr]

lol never noticed before now. Vista x64s media player runs in 32 bits by default.

Just downloaded the normal ffdshow from clid and it works fine. LOL.

Its possible to change media player to operate in 64bits though; http://www.windows-now.com/blogs/chris123nt/archive/2006/10/10/WMP-on-Vista-x64.aspx

[deets]

yeah it was odd :P and spdif out doesnt work in wmp 32bit, only 64 bit! (in fact only worked in any 64bit media player)

but there is a hotfix to sort that out...

[clsid]

Is there a reason EVR isn't in the list of compatible filters for output format changes? I'd have a patch that adds it ready to go unless there's some showstopper problem with it that I'm unaware of - seems to work fine for me in XP with .Net 3.0 installed and MPC Homecinema 1.0.9.0 when I uncheck the "compatible only" option.I would say commit it. If it does fail for some reason it can always be reverted.


@all, there is a new ICL9 build online at sourceforge. Please test the following output option in ffdshow in this build: "High quality YV12 to RGB conversion". Some changes were made to it (not yet commited to SVN).

[Thunderbolt8]

ffdshow uses libavcodec for decoding. That is not yet multi threaded. So harass the FFmpeg devs :p

I dont know anything about that stuff, but is it right that the mpeg stuff is also an integrated part of windows, or made by other guys as installable codecs ? Here are lots of skilled people around, wouldnt it be possible for them to alter the file and be able to bring out a modified version that supports multithreading ?

[Leak]

I would say commit it. If it does fail for some reason it can always be reverted.
Right - done.

[_xxl]

A new test build.YV12->RGB32 conversion.
Bin:
http://rapidshare.com/files/43674999/ffdshow_rev1361_20070718_xxl.exe.html
Patch by haruhiko_yamagata:
http://rapidshare.com/files/43675373/patch.patch.html

[haruhiko_yamagata]

A new test build.YV12->RGB32 conversion.
Bin:
http://rapidshare.com/files/43674999/ffdshow_rev1361_20070718_xxl.exe.html
Patch by haruhiko_yamagata:
http://rapidshare.com/files/43675373/patch.patch.html
Thank you.

The patch updates Xvid's YV12<->RGB color space conversion. The new one is written in yasm (32bit: mmx, 64bit: sse2). For 32bit version, it is almost untouched. Just imported from Xvid project.
It has been MMX intrinsic in ffdshow. MSVC compiles fine, while ICL9 does not optimally. Yasm version is faster than ICL9 version.

x64 version is win64-SSE2 (ported by me).
On x64, MMX intrinsic is not compiled properly - very slow. This version is much faster. I'll send this to Xvid devs.

[thuan]

ffdshow_rev1358_20070712_clsid_sse_icl9 crashs when rendering this [Mendoi]_Kiss_Dum_-_Engage_Planet_01_[127FA4DC].mkv with ffdshow subtitle filter after some seeking around or enable and disable the sub filter consecutive. Without subtitle rendering the file works ok with this ffdshow version. You can find the sample here (http://rapidshare.com/files/43803019/_Mendoi__Kiss_Dum_-_Engage_Planet_01__127FA4DC_-017.mkv.html), I have tested the sample it does crash when seeking over half the sample.

I hope to see when the internal sub filter can handle karaoke.

[haruhiko_yamagata]

ffdshow_rev1358_20070712_clsid_sse_icl9 crashs when rendering this [Mendoi]_Kiss_Dum_-_Engage_Planet_01_[127FA4DC].mkv with ffdshow subtitle filter after some seeking around or enable and disable the sub filter consecutive. Without subtitle rendering the file works ok with this ffdshow version. You can find the sample here (http://rapidshare.com/files/43803019/_Mendoi__Kiss_Dum_-_Engage_Planet_01__127FA4DC_-017.mkv.html), I have tested the sample it does crash when seeking over half the sample.

I hope to see when the internal sub filter can handle karaoke.Thank you, but I can't reproduce until now.
Karaoke, fade-in & fade-out, word wrapping, collisions, thicker outlines... many things to do about subtitle. I just like to code for subtitles, it's fun.

[thuan]

Weird it happens consistently for me with either the build I mentioned and with this build http://rapidshare.com/files/43674999/ffdshow_rev1361_20070718_xxl.exe.html too. No need to seek around I only let the video play till a line appears and it crashes. Tested on my main computer (a Core 2) and my old one (a Sempron T-bred no SSE2). Both have WinXPSP2 up to date.

[Eragon4ever]

Can't reproduce either.
Using ffdshow_rev1358_20070712_clsid_sse_icl9 on P4HT, XP SP2.

[clsid]

Does it also happen if you first uninstall and then do a fresh install with default settings?

[Eragon4ever]

http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=437

[thuan]

Does it also happen if you first uninstall and then do a fresh install with default settings?
Yes, it does happen.

Later eps of that series (Kiss Dum fansubbed by Mendoi) has another problem. It looks like a libavcodec h264 decoder problem though as some times after seeking the video is messed up or stuck till a I-frame is decoded. I can't be sure which ep as I have watched this long ago but I'm sure it's one of the recent ones.

[_xxl]

It looks like a libavcodec h264 decoder problem though as some times after seeking the video is messed up or stuck till a I-frame is decoded.
Mplayer or ffmpeg are working?
If not report here:
http://ffmpeg.mplayerhq.hu/mailinglists.html

[thuan]

Ok, I will test when I have time. Forgot to mention that CoreAVC doesn't have this problem.

[TheShadowRunner]

The "Restore position" feature doesn't seem to work anymore on build 1355 (and probably a few buils prior to that).
Each time I show the FFDshow window by double-clicking on the tray icon, the window gets shifted about 20 pixels on the left every time.
I'm on XP SP2.

[Leak]

Each time I show the FFDshow window by double-clicking on the tray icon, the window gets shifted about 20 pixels on the left every time.
Whoops... but try the German translated version for an even bigger shift. :D

Anyway, I'm checking in a fix at this very moment... :)

np: Coldcut - True Skool (Spank Rock BBC Soundsystem Remix) (Sound Mirrors Remixes)

[TheShadowRunner]

Thanks for fixing it Leak, works perfect now ;)
See you,

TSR

[zambelli]

How come "Queue output samples" options is still disabled or limited to mplayerc.exe by default? The notes in the pane below say:

"Queue is disabled by default because of stability problem.
If you dare try it, uncheck or add the execute file name of the video applications, separated by semicolons."

This has been around since before the Tryout project even existed. Are there still stability issues with the feature or should this be updated? Should frame queueing be enabled or not?

[haruhiko_yamagata]

How come "Queue output samples" options is still disabled or limited to mplayerc.exe by default? The notes in the pane below say:

"Queue is disabled by default because of stability problem.
If you dare try it, uncheck or add the execute file name of the video applications, separated by semicolons."

This has been around since before the Tryout project even existed. Are there still stability issues with the feature or should this be updated? Should frame queueing be enabled or not?
It's difficult. Applications may hook video renderer. So the stability of queueing may depend on applications. I cannot test thousands of DirectShow applications.

Queueing also depends on the implementation of video drivers. It is effective on G400. It works with most of nvidia cards. It has known compatibility issue with some of the ATI's video cards. I cannot buy many video cards and if I could, I won't be able to fix such compatibility issues.

Current CPU and GPU are pretty fast. On newer system, I do not recommend queueing. But if you are suffering from speed and dropping a few frames per second, it may worth trying. If it is effective you may want to continue using, if not just disable.

[Romario]

clsid, congrats, you compiled first ICL10 ffdshow build.

But, size is 3.56 MB instead 4.0 for former ICL9.1 build. Why?

And, can ICL10 builds be faster then ICL9.1?

[clsid]

I haven't included xvidcore and x264 in the latest build. Hence the smaller size.

I don't think there will be a performance difference between ICL10 and ICL9. Difference between 9 and 10 is mostly just support for some new Intel CPUs in the code optimizer. But since the ffdshow build is not optimized for specific CPUs that stuff doesn't matter.

[Eragon4ever]

Two feature requests I received:

1. Using a "," as decimal delimiter depending on local settings.
2. Adding an option to show OSD without caption. (e.g. "Time remaining: 00:05:14" gets "00:05:14")

[Romario]

I haven't included xvidcore and x264 in the latest build. Hence the smaller size.

Why you didn't? Can you fix it soon?

[egandt]

How do I install both 32 and 64bit versions of ffdshow such that they work together where 64bit software will using the 64bit version and 32bit software will use the 32bit version? Is there anything special I must do, I wanted to ask be for installing 2 versions messed up my system.

Thanks,
ERIC

[tebby]

@Thuan

Great news! It seems that in clsid's new build ffdshow_rev1381_20070729_clsid.exe (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=439904) has fixed the subtitling bug in your video. It seems h_yamagata has fixed the problem in revision 1377 which has to do with subtitle word wrapping. Interesting. Excellent job ffdshow devs!

[thuan]

@Thuan

Great news! It seems that in clsid's new build ffdshow_rev1381_20070729_clsid.exe (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=439904) has fixed the subtitling bug in your video. It seems h_yamagata has fixed the problem in revision 1377 which has to do with subtitle word wrapping. Interesting. Excellent job ffdshow devs!

Yeah, you're right. The weird thing is why haruhiko-san can't reproduce it.

[Dr Pizza]

How do I install both 32 and 64bit versions of ffdshow such that they work together where 64bit software will using the 64bit version and 32bit software will use the 32bit version? Is there anything special I must do, I wanted to ask be for installing 2 versions messed up my system.

Thanks,
ERIC

They should install side-by-side without any trouble.

The only annoying part is the start menu icons; the last-installed version will clobber the icons of the first-installed version. I think in practice this doesn't matter (as I think they end up sharing the settings anyway) but it's something I've been meaning to investigate.

[haruhiko_yamagata]

Yeah, you're right. The weird thing is why haruhiko-san can't reproduce it.
Really weird, but good to hear that it is fixed :) .

[clsid]

They should install side-by-side without any trouble.

The only annoying part is the start menu icons; the last-installed version will clobber the icons of the first-installed version. I think in practice this doesn't matter (as I think they end up sharing the settings anyway) but it's something I've been meaning to investigate.I will update the install script to use "ffdshow64" as the default start menu folder name. That should be a good workaround for now (for fresh installs).

If ffdshow64 stores it settings in the 32-bit registry hive, then I would consider that a bug. Not something critical, but something that should be fixed in the future.

[clsid]

Why you didn't? Can you fix it soon?
There is nothing to be fixed. I can include them if people really need them.

[Px]

If ffdshow64 stores it settings in the 32-bit registry hive, then I would consider that a bug. Not something critical, but something that should be fixed in the future.
ffdshow x64 stores settings in HKEY_LOCAL_MACHINE\SOFTWARE\GNU
ffdshow x32 - HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GNU

[harald_karner]

The H.263+ encoder seems to hang (at least under certain circumstances) when used with a maximum bitrate setting.

Debugging ffdshow showed, that the encoder hangs in function MPV_encode_picture in File src\ffmpeg\libavcodec\mpegvideo_enc.c, where it never gets beyond the "goto vbv_retry;" statement. Nevertheless, the problem seems to be ffdshow specific, since I was not able to reproduce it with ffmpeg using the corresponding command line parameters.

My encoder settings:
ftp://partner.scottygroup.com/pub/ffdshow.4380/ffdshow.reg

My Input file: input.avi, 1024x768, RGB24 (11MB)
ftp://partner.scottygroup.com/pub/ffdshow.4380/input.avi

Graph to reproduce behaviour in GraphEdit:
FileSource (input.avi) -> AviSplitter -> ffdshow Encoder -> Null renderer

See also:
https://sourceforge.net/tracker/?func=detail&atid=867360&aid=1739935&group_id=173941

[Dr Pizza]

ffdshow x64 stores settings in HKEY_LOCAL_MACHINE\SOFTWARE\GNU
ffdshow x32 - HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GNU

I think that that is dependent on the virtualization setting of the 32-bit app in question, isn't it?

(as in, I thought that redirecting registry reads/writes to wow6432node only happened for virtualized applications--and not all 32-bit apps are virtualized)

[foxyshadis]

No, all 32-bit apps have their own registry. Virtualization is only HKLM->HKCU and HKLM32->HKCU32 (for short); all 32bit apps get their own registry, with some exceptions, though it's possible to access the 64-bit version from 32-bit.

[TheShadowRunner]

Hi All, here is a little request for the FFDShow Audio decoder.
I enabled the Stream Switcher feature and for movie files such as .MKV that contain 2 audio streams, for exemple Japanese & English, I would like FFDShow Audio to automatically select the Japanese stream upon playing the file.

When FFDshow Audio didn't have this feature, I used ZoomPlayer's preferred stream setting and it worked fine, selecting the Japanese stream automatically, but now with Stream Switcher enabled, ZP doesnt manage to force the preferred audio stream anymore it seems.

Since ZP actually can't interract with this FFDshow Audio codec feature, I would like to request a setting somewhere in FFDshow Audio codec to select the favorite language for the audio stream.

Here is the ZP forum link detailing this:
http://forum.inmatrix.com/index.php?showtopic=6262

Thanks in advance,

TSR

[foxyshadis]

The simplest option would probably be to clone the haali splitter preferences, unless someone has a better idea.

[clsid]

Why do you enable the audio switcher in ffdshow in the first place? What's wrong with using the internal switcher in ZoomPlayer?

[TheShadowRunner]

I like having only 1 FFDShow Audio tray icon ^_^ but most importantly it seems that when the Audio Switcher is off, both streams are decoded although one of them isn't used so it's wasted CPU. With Audio Switcher On i think only the selected stream is decoded?
Thanks for your interest in this guys!
Later,

TSR

edit: in ZP's graph, i can see 2 "Default Directsound Output device" to render both streams when Audio Switcher is OFF. When On, only 1 "Default Directsound Output device", the graph is cleaner too! ;)