ffdshow tryouts project: Discussion & Development

[iron2000]

Is the 16-235->0-255 shader in MPC similar to the Full range RGB conversion in ffdshow?

I like the colours by the MPC shader better.

[mike7]

Feature Request:
Could you, please, if have time of course, add ability to display current preset on OSD?
Thanks for you great work.

[haruhiko_yamagata]

When there will be a new binary file?
I want to test the vob/ssa fixes.

thxWell, the vob problem is difficult. It requires more understanding of vobsub.

@clsid
Please move it (short term todo-1) to mid term.

[haruhiko_yamagata]

Feature Request:
Could you, please, if have time of course, add ability to display current preset on OSD?
Thanks for you great work.done as rev 1551.

[haruhiko_yamagata]

I'm not very knowledgeable about this stuff, but when I did that, the black seems to be "proper" black instead of dark grey.

I have a Nvidia 7900gs and it had been bothering me for a while.

Is this the intended outcome?
Anyways, whoohoo! :thanks:Yes, I use Nvidia 7900GS. Its YUV->RGB conversion is not reliable. VMR7 is totally broken. VMR9 is bit better but it always use full range. That's why I always use YUV->RGB conversion in ffdshow.Sorry for OT, I updated the driver and managed to get proper output from VMR9-YUV by tweaking the nVidia control panel. From video & Television->Adjust video color settings, increase contrast and decrease brightness. I also had to increase RGB gamma for all channels. The bug can be fixed through the control panel, though the configuration is not easy for beginers...

[LoRd_MuldeR]

Does the rev1548 build by CLSID already include the "VfW configuration" shortcut fix?
If so, it doesn't work :(

The shortcut uses the following settings now:Target = C:\WINDOWS\system32\rundll32.exe ff_vfw.dll,configureVFW
Start in = C:\WINDOWS\system32

Change "Start in" to "SysWOW64" and it does work ...

[clsid]

Well, it should be working. The install script was fixed in 1545.

The value of "Start in" written by the installer should be SysWOW64.

This means that either there is a bug in the installer software or there is something wrong with your Windows installation.

Here is a sample script that you can compile with InnoSetup:
[Setup]
AppName=Test
AppVerName=Test
AppId=innotest
DefaultDirName={tmp}
Uninstallable=no
OutputDir=.

[Code]
function InitializeSetup(): Boolean;
begin
Result := false;
// this should display SysWOW64 path on a 64-bit version of Windows
msgbox(ExpandConstant('{sys}'), mbInformation, mb_ok);
end;

[squid_80]

The shortcut uses the following settings now:Target = C:\WINDOWS\system32\rundll32.exe ff_vfw.dll,configureVFW
Start in = C:\WINDOWS\system32

Change "Start in" to "SysWOW64" and it does work ...
To be proper the target should be c:\windows\syswow64\rundll32.exe as well.

[clsid]

I know. But that is not the issue. That rundll32.exe version is able to handle both 32/64-bit stuff afaik. The issue is that the {sys} constant in the install script resolves to the wrong folder.

[LoRd_MuldeR]

I know. But that is not the issue. That rundll32.exe version is able to handle both 32/64-bit stuff afaik. The issue is that the {sys} constant in the install script resolves to the wrong folder.

Well the GetSystemDirectory() function definitely returns "C:\Windows\system32" here...

http://img212.imageshack.us/img212/4138/fileinnosetuprb9.th.png (http://img212.imageshack.us/my.php?image=fileinnosetuprb9.png)


// EDIT

Could other "Windows XP Pro - x64 Edition" (aka Windows Server 2003 - Client Mod) users please test it:
http://mulder.dummwiedeutsch.de/temp/setup.exe

[squid_80]

I know. But that is not the issue. That rundll32.exe version is able to handle both 32/64-bit stuff afaik. The issue is that the {sys} constant in the install script resolves to the wrong folder.
It's the wrong solution to the problem. You should be calling the correct rundll32.exe rather than setting the Start In directory. For example if you've got both x64 and x32 installed, running c:\windows\system32\rundll32.exe ff_vfw.dll,configureVFW from c:\windows\syswow64 will launch configuration of the x64 build, not x32.

GetSystemDirectory() will always return c:\windows\system32 in x64. GetSystemWow64Directory() is used to get the 32-bit system directory. I think the right way to do it is not put ff_vfw.dll in system32 at all, keep it in program files\ffdshow and point the shortcut there.

[haruhiko_yamagata]

Well the GetSystemDirectory() function definitely returns "C:\Windows\system32" here...

http://img212.imageshack.us/img212/4138/fileinnosetuprb9.th.png (http://img212.imageshack.us/my.php?image=fileinnosetuprb9.png)


// EDIT

Could other "Windows XP Pro - x64 Edition" (aka Windows Server 2003 - Client Mod) users please test it:
http://mulder.dummwiedeutsch.de/temp/setup.exesystem32 here, too. Regardless of ArchitecturesInstallIn64BitMode=x64 or blank.

[LoRd_MuldeR]

I think the right way to do it is not put ff_vfw.dll in system32 at all, keep it in program files\ffdshow and point the shortcut there.

AFAIK, VfW Codecs are simply installed by putting the DLL into the "System32" directory. So if it will be placed in ffdshow's install folder, it won't won't be recognized by the Video Compression Manager - unless there is a second method to register "out of place" VfW Codecs via the Windows Registry somehow...

[squid_80]

AFAIK, VfW Codecs are simply installed by putting the DLL into the "System32" directory.
No they're not. A string key is made in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32 called vidc.XXXX where XXXX is the codec handler's FourCC. The string itself is the dll to use, optionally including the full path.

[LoRd_MuldeR]

No they're not. A string key is made in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32 called vidc.XXXX where XXXX is the codec handler's FourCC. The string itself is the dll to use, optionally including the full path.
If that behavior is the same on all Win32 versions, I think the ff_vfw.dll should definitely be put into the ffdshow install folder!

Then the shortcut could be done like:
Target = rundll32.exe C:\<Path to ffdshow>\ff_vfw.dll,configureVFW
Start in = <blank>

I think Rundll doesn't need a full path, as long as the path to ff_vfw.dll is explicit.
Windows will automatically find Rundll32.exe from %Path% ...

[clsid]

Guys, please ignore the rundll32.exe stuff. That is just cosmetics, not what goes wrong. Have a look at my test script. If {sys} doesn't give the correct directory, then it would still point to the wrong (but working) rundll32.exe even with a 'fixed' script.

The codec can indeed be placed everywhere. The drivers32 key should contain the full path, with the added note that the path should be in shortname form. But since placing codecs in the system folder is pretty much the standard in practice, some buggy apps may fail to properly recognize codecs that are placed elsewhere.

[LoRd_MuldeR]

Guys, please ignore the rundll32.exe stuff. That is just cosmetics, not what goes wrong. Have a look at my test script. If {sys} doesn't give the correct directory, then it would still point to the wrong (but working) rundll32.exe even with a 'fixed' script.
Well, it seems {sys} does return the correct system directory! I guess it simply calls GetSystemDirectory(), which return "C:\WINDOWS\System32", even on x64 Windows. If you want to get "C:\WINDOWS\SysWOW64", then I think would you need a different placeholder (e.g. "{syswow64}") which calls GetSystemWow64Directory() instead. But if you would simply place the ff_vfw.dll in the ffdshow install folder, you can work with the full path to ff_vfw.dll easily. So that should solve the problem...

Target = rundll32.exe "C:\Program Files\ffdshow\ff_vfw.dll",configureVFW

I think most applications simply use Windows' Video Compression Manager. So as long as Windows is able to find the Codecs with full path, there should be no problem. If some buggy applications fail, then that's their problem. The most important application for 99,9% of your users is VirtualDub anyway...

[clsid]

Relocating ff_vfw.dll shouldn't be needed. Putting it in the ffdshow app folder can also be a problem for people who have shortname functionality disabled on their NTFS partition. That is rare, but possible.

[LoRd_MuldeR]

Putting it in the ffdshow app folder can also be a problem for people who have shortname functionality disabled on their NTFS partition. That is rare, but possible.

Wouldn't that cause identical problems with ffdshow.ax located in the ffdshow install folder?

[clsid]

No, because shortname is only needed for ff_vfw.dll


Edit: I think I may have found the cause.
Writing files to {sys} will cause them to end up in SysWOW64, because of the WOW64 file redirection done by Windows.
When no files are concerned {sys} just resolves to the system32 dir. Although the Inno docs are ambiguous about this.

I will commit a fixed script later. Going to watch F1 first now.

[LoRd_MuldeR]

Well, if you want to keep ff_vfw.dll in "SysWOW64" folder on Win x64, then you will need to find a way to detect the location of "SysWOW64" from InnoSetup. I have not looked into the docs yet, but they should have a placeholder for the "SysWOW64" directory. If not, maybe you can manually call GetSystemWow64Directory() from InnoSetup, like System::Call in NSIS...

Another quick idea: Make a small EXE file (e.g. vfwconfig.exe), which calls "configureVFW" from ff_vfw.dll, and put that EXE into ffdshow install folder. Then you can make a shortcut to vfwconfig.exe in ffdshow install folder, instead of calling Rundll32.exe ...

[squid_80]

When all else fails: RTFM.
Prototype:
function GetSysWow64Dir: String;

Description:
64-bit Windows only: returns fully qualified path of the
SysWOW64 directory. This is the actual directory in which 32-bit
system files reside. An empty string is returned if this
function is called on 32-bit Windows, or if for some reason it
fails to retrieve the path on 64-bit Windows (unlikely).

Example:
var
S: String;
begin
S := GetSysWow64Dir;
// Must check the result -- an empty string is returned
// if there is no SysWOW64 directory.
if S <> '' then
MsgBox('SysWOW64 directory: ' + S, mbInformation, MB_OK)
else
MsgBox('There is no SysWOW64 directory.', mbInformation, MB_OK);
end;

[clsid]

I know how to fix it, don't worry. Simply using GetSysWow64Dir is NOT the solution, since that returns an empty string on 32-bit Windows as you can see above. So a small wrapper function is needed.

Edit: using {syswow64} should do the trick. That should be equal to {sys} on 32-bit Windows.

[squid_80]

Edit: using {syswow64} should do the trick. That should be equal to {sys} on 32-bit Windows.
Unless you want to use the same install script for 64-bit builds...
var S: String;
begin
if Is64BitInstallMode then
S := GetSystemDir()
else
S := ExpandConstant('{syswow64}');
MsgBox('System directory: ' + S, mbInformation, MB_OK)
end;

[clsid]

A fixed build is already online.

The differences needed for 32/64-bit builds are taken care of by pre-processing of the install script. So there is no need for such code.

[LoRd_MuldeR]

A fixed build is already online.
The "VfW configuration" short now works on WinXP Pro x64 Edition!
Good job :thanks:

The differences needed for 32/64-bit builds are taken care of by pre-processing of the install script. So there is no need for such code.
So if the differences are handled by pre-processing the script, hence at compile-time, we have different installers for 32/64-Bit Windows now?

[clsid]

The script is different for 32/64-bit builds of ffdshow. It has been since the beginning. But the 32-bit script is the same regardless of the Windows version, otherwise we couldn't have a single installer that works on all versions of Windows.

[LoRd_MuldeR]

The script is different for 32/64-bit builds of ffdshow. It has been since the beginning. But the 32-bit script is the same regardless of the Windows version, otherwise we couldn't have a single installer that works on all versions of Windows.

I see :)

So the recent fix makes the 32-Bit installer create proper shortcuts under x64 Windows ;)

[Kado]

@haruhiko_yamagata

I think you forgot to put the back center speaker controls and meter in the volume filter (for something like 6.1 speakers), unless you did that on purpose with the intention of adding it later because like the description for rev.1549 says:
"Volume filter : add control for side channels".

[haruhiko_yamagata]

@haruhiko_yamagata

I think you forgot to put the back center speaker controls and meter in the volume filter (for something like 6.1 speakers), unless you did that on purpose with the intention of adding it later because like the description for rev.1549 says:
"Volume filter : add control for side channels".Back center speaker is hidden there beforehand. Back left speaker can be used to configure back center speaker. They are rarely used together. Because there was no space to add one more control, I left it untouched. Though I cant test it.

[fastplayer]

Is SF's shell service down? I can't connect to shell.sourceforge.net anymore... :confused:

Edit: Thx for confirmation, Haruhiko!
Edit2: It's working as of now! :)

[haruhiko_yamagata]

Is SF's shell service down? I can't connect to shell.sourceforge.net anymore... :confused:Yes. I can't connect too.

[kurt]

Is there a way to decode *.jpg files with ffdshow? Cause I would like to watch my vacation pics on TV with some sharpenfilter (or something similar).

At present it looks like that on my system:

http://i24.tinypic.com/2qu7vxx.png

[LoRd_MuldeR]

Is there a way to decode *.jpg files with ffdshow? Cause I would like to watch my vacation pics on TV with some sharpenfilter (or something similar).

At present it looks like that on my system:

http://i24.tinypic.com/2qu7vxx.png

If you enable "Raw video" in the Codecs list, you should be able to put ffdshow between "Color Space Converter" and "Video Renderer".
Maybe the "Color Space Converter" won't even be needed then ...

[clsid]

You could use Irfanview. That has a sharpen filter.

[kurt]

If you enable "Raw video" in the Codecs list, you should be able to put ffdshow between "Color Space Converter" and "Video Renderer".
Maybe the "Color Space Converter" won't even be needed then ...
I can put ffdshow video decoder after color space converter (before it isn't possible) but then I can't connect to any video renderer.... any ideas?
http://img520.imageshack.us/img520/7258/image2id4.th.png (http://img520.imageshack.us/my.php?image=image2id4.png)

You could use Irfanview. That has a sharpen filter.
thx for the tip, but I don't see an option for sharpening on the fly (e.g. slideshow) with Irfanview.

@ mods: if this is way too OT, feel free to place it somewhere else :)

[Leak]

I can put ffdshow video decoder after color space converter (before it isn't possible) but then I can't connect to any video renderer.... any ideas?
What does the properties dialog for the "Out" pin of the ffdshow raw decoder show? That could give a hint as to why nothing wants to connect...

(Or you could run DbgView from Sysinternals and look if any messages turn up in it...)

[kurt]

What does the properties dialog for the "Out" pin of the ffdshow raw decoder show? That could give a hint as to why nothing wants to connect...

(Or you could run DbgView from Sysinternals and look if any messages turn up in it...)
I don't know why, but now it works :D
(I can't remember what I changed exactly) - thank you all.
http://img143.imageshack.us/img143/511/image1pd8.th.png (http://img143.imageshack.us/my.php?image=image1pd8.png)http://img132.imageshack.us/img132/1877/image2gm4.th.png (http://img132.imageshack.us/my.php?image=image2gm4.png)

unfortunately seesaw scipt in avisynth dialog doesn't seem to work... but sharpen should be enough for the moment :)

[Leak]

unfortunately seesaw scipt in avisynth dialog doesn't seem to work... but sharpen should be enough for the moment :)
I haven't ever used SeeSaw, but given that all kinds of other filters and scripts work I can't think of a reason why SeeSaw wouldn't...

[kurt]

I haven't ever used SeeSaw, but given that all kinds of other filters and scripts work I can't think of a reason why SeeSaw wouldn't...
Maybe I wasn't clear enough:
SeeSaw does work in avisynth dialog for videos. But not for jpgs (at least here) :)

[clsid]

Since a jpg can be considered as a movie with a length of just 1 frame, any filter that need multiple frames to work on, won't work. I dunno if that applies to SeeSaw.

[Didée]

SeeSaw requires YV12 as input, because of MaskTools. The decoder probably delivers the JPGs as YUY2 or RGB, so you've to use ConvertToYV12() before SeeSaw. While you're at it, set 'sootheT=0', because temporal soothing makes no sense for single image sequences.

[kurt]

SeeSaw requires YV12 as input, because of MaskTools. The decoder probably delivers the JPGs as YUY2 or RGB, so you've to use ConvertToYV12() before SeeSaw. While you're at it, set 'sootheT=0', because temporal soothing makes no sense for single image sequences.
It's damn slow for Hi-Res files but it works with SeeSaw now :)

A ConvertToYV12() is not needed, if one is limiting colorspaces to yv12 in avisynth dialog :)
http://img521.imageshack.us/img521/9273/unbenanntzq8.th.png (http://img521.imageshack.us/my.php?image=unbenanntzq8.png)

:thanks: for the hint, Didée!

[LoRd_MuldeR]

thx for the tip, but I don't see an option for sharpening on the fly (e.g. slideshow) with Irfanview.
1. In IrfanView v4.10 goto "File" -> "Batch Convert/Rename"
2. Add all the files you want to view
3. Choose "Work as: Batch conversion"
4. Choose the output directory as you like it
5. Check "Use Advanced Options" and click "Advanced" button
6. Under "Other Options" (right side) check "Sharpen"
7. Click "Okay" and "Start Batch"
8. Use "File" -> "Slideshow" as usual (from output directory)

[kurt]

@ Lord_Mulder: yup, I'm aware of batch-processing. I have Paintshop Pro installed and could do this also with it. But I don't want to convert my pics (they are sharpen enough) - the TV is the problem. For my taste the pics on TV could be a bit sharper, this is why I asked for ffdshow.

Regarding Irfanview: I thought maybe it has an option to enable some sharpen filters during slideshows, but this seems not the case. Now I will try, wich filter in ffdshow (sharpen, seesaw..) is satisfying - if I find some time :p

(reminder: this is all about JPGs - with videos I don't have any sharpening problems on my TV because of SeeSaw)

Edit: hmmm, maybe batch processing is really easier (and faster in the end) to handle since mpc/ffdshow/seesaw is not specially made for playing back images (and it takes a lot of cpu time switching between the pics). Convert the pics you want to use for a slideshow and just delete them later .... I have to reconsider :D

[foxyshadis]

Well, you should really use SeeSaw after resizing, so high-res shouldn't be a problem done properly. But yeah, it's best to batch convert everything into a folder, sized directly to the screen's dimensions, to get the best quality at a good speed.

[kurt]

Well, you should really use SeeSaw after resizing, so high-res shouldn't be a problem done properly. But yeah, it's best to batch convert everything into a folder, sized directly to the screen's dimensions, to get the best quality at a good speed.
jup, I tried lanczosresize(1024,768) yesterday and it suited well on my CRT TV - but it is still very slow (P4, 2 ghz, 512 MB RAM)...

[haruhiko_yamagata]

Instead of adding yet another option, wouldn't it be better to just make it work the logical way. For me also that would mean using AND instead of OR on all the enabled conditions in a preset.Well, sure. I just was erring on the cautious side because someone might already be making use of the "OR" behaviour, which would of course break with a change to "AND"...

The code change itself should be rather minimal, but the implications might not be. What does the rest here think?

np: Luke Vibert - Comphex (Chicago, Detroit, Redruth)Sorry to be too late, but I guess this change is confusing the user. We are not announcing this very loudly. People who don't read here have no way to know...
'on movie file name match with preset name' is checked by default and unless users uncheck it, the preset doesn't load.
Too late but isn't it better to add an option to select OR/AND and make OR the default?

The dialog would require a radio button
*On all conditions match (AND)
*On one of the conditoins match (OR)

[clsid]

Or maybe uncheck 'on movie file name match with preset name' by default. I don't think many people are actually using that condition.

[haruhiko_yamagata]

Or maybe uncheck 'on movie file name match with preset name' by default. I don't think many people are actually using that condition.Yes, I will.
But it doesn't rescue user's old preset.