View Full Version : New ffdshow build (?)
trodas
27th June 2006, 15:37
No, more likely to someone (M$?) stupidity. When I rename the files in question from *.mp4 to *.3gp then all is working now... :scared: ;)
A nice example that years after W98 crashed when one rename mp3 as wav is the problem still there... :(
videomixer9
27th June 2006, 17:11
to me this sound more like you got some fucked up filters installed. The blame MS for everything is out amongst non-clueless people :P Better check what's all handling mp4 for you and which things are added as handlers for it in registry etc. I bet you got Nero or whatever kick in there ...
foxyshadis
27th June 2006, 21:26
Hmm... Does ffdshow fail to detect that inloop is disabled in sauce or what? Seems a bit strange...
The h.264 PP requires you to manually state whether inloop is enabled or not. In the basic default setting, it's set as if inloop is off. And it has entirely misleading name and values, because it sounds as if it affects inloop deblocking, but that's only set on the main codec config page.
Normal mplayer pp is mostly annoying because it doesn't scale well. Low-to-mid quants will be a blurry mess when high quants are hardly touched at all, and default 100 w/dering is still too high for normal. If deblock were set to 80 and dering to 50 (by modifying the algorithm) it would probably work for the majority of what's watched.
mpioner
28th June 2006, 02:55
haruhiko_yamagata
thank you for work
may be you fix CPU load bug in OSD on dual CPU?
The h.264 PP requires you to manually state whether inloop is enabled or not. In the basic default setting, it's set as if inloop is off. And it has entirely misleading name and values, because it sounds as if it affects inloop deblocking, but that's only set on the main codec config page.
Yeah I noticed that H264 deblocking setting doesn't actually affect anything :) Only way to set it is to use those checkboxes at the Codecs page. I guess the combobox at PP page should be completely removed to eliminate confusion.
As for casual, non-inloop PP, that's big BS anyway. If your sauce is bad, it wont' do it really better, if it's good, one doesnt' need to use it anyway :P
What I really recommend as PP is THE deband filter. Banding is very common in anime-style material, and ffdshow filter is superb to remove it. So apart from Debanding and software resizing filters in ffdshow, i hardly use anything at all.
haruhiko_yamagata
29th June 2006, 10:50
haruhiko_yamagata
thank you for work
may be you fix CPU load bug in OSD on dual CPU?
Hello, mpioner. It's buggy before mt patch.
Is it nessesary? It may not easy to fix. As far as it exists, it should work properly. Deleting it is easier, but I hesitate to delete something that milan has written. Disable and forget may be better.
kurt
30th June 2006, 09:03
after installing videomixer's ffdshow-20060625-rev2546.exe, I got a msvcr80.dll error when using xvid_encraw and megui
http://img230.imageshack.us/img230/1966/image21bb.jpg (http://imageshack.us)
no problems with ffdshow-20060604-rev2546.exe (also from videomixer)
pdanpdan
30th June 2006, 13:21
after installing videomixer's ffdshow-20060625-rev2546.exe, I got a msvcr80.dll error when using xvid_encraw and megui
http://img230.imageshack.us/img230/1966/image21bb.jpg (http://imageshack.us)
no problems with ffdshow-20060604-rev2546.exe (also from videomixer)
Delete the ffdshow filter in avisynth plugin directory.
_xxl
30th June 2006, 20:48
libx264.dll to decode x264?
It is faster than ffmpeg/libavcodec.
libx264.dll can be used in ffdshow?
http://www.vid-labs.com/products/products.htm
The codec incorporates patent-pending complexity reduction algorithms that adapt to the video clip content and selectively bypass parts of the coding process.
http://www.vid-labs.com/products/products.htm
Fast MPEG4-10 H264 software CODEC!!!
But it's not free source :)
max-holz
2nd July 2006, 09:15
I want to tell to anybody that the file
ffdshow-20060604-rev2546.exe
was detected tonight by my antivirus as containing the virus
Trojan.Zlob
http://securityresponse.symantec.com/avcenter/venc/data/trojan.zlob.html
BE CAREFUL!
foxyshadis
2nd July 2006, 09:39
If you look back in the thread to when it was released, you'll see it was a false positive! It was submitted to sites that test against a couple dozen AV engines. Ensure your definitions are up to date, and if they are, dump that worthless symantec trash.
Liisachan
2nd July 2006, 12:05
There is even this note on every mirror site.
http://ffdshow.faireal.net/
ffdshow-rev2546-SSE2.exe
...
NOTE: Some antivirus software may "detect" a Trojan in this file, which is a false positive (there is no virus in it)...
Just stop and think about it... Most of the ppl around here are geeks, hackers, otaku, geniuses, nuts, aliens, haruhi, whatever. If there really was a virus or trojan in it, they would have found it soon and there wouldve been a huge fuss one hour after the release... don't you think so?
So the bottom line is:
:search:
foxyshadis
2nd July 2006, 13:03
btw, concerning the h.264 pp debacle, I decided to look a little harder and found that due to a code bug, what's actually happening is that the meanings of each option are reversed. No wonder it makes no sense!
"off": it's always on, "always": disables pp entirely, including for asp, "h264 video": it's always off, "h.264 video without deblocking": it's off when inloop is disabled and on otherwise. Makes sense, eh? The wrong setting obviously doubles up inloop.
I still support setting it to the safest (currently #3) on install, removing the UI, and relegating it to a registry-hack option only.
clsid
2nd July 2006, 17:46
When PP is off, all four options give me similar dfps.
When PP is on, option #1 and #4 produce higher dfps (almost twice as high) than #2 and #3.
What does "skip deblocking when safe" do? It gives me about 13% better performance. But does it affect visual quality?
Delete the ffdshow filter in avisynth plugin directory.
ok, I deleted ffavisynth.dll and the error message don't appear anymore. thx! :)
What does "skip deblocking when safe" do? It gives me about 13% better performance. But does it affect visual quality?
i think "safe" means you won't see blocks in the picture due to debloking filter being turned off. If completely disable it, then, depending on the sauce inloop filter settings and the bitrate (the lower is the bitrate of the sauce, the higher impact inloop filter actually has on the video quality), some blocks might appear.
On my XP 1800+ "safe deblocking" is actually a very important option, especially for 576p and 720p AVC videos.
soulstace
3rd July 2006, 09:17
K-lite codec pack always seems to keep up with the latest ffdshow builds.
http://www.torrentspy.com/torrent/785459/ffdshow_20060703
foxyshadis
3rd July 2006, 11:40
skip deblocking when safe = deblock only reference frames (i/p-frames mostly). If your source is of questionable quality you'll notice a distinct smooth/blocky pulsing from it, because b-frames won't get deblocked.
clsid, I get the same results and I'm not sure why. I'd like to build ffdshow so I can mess with the pp filter, but I don't want to deal with the hassles right now. ^^;
haruhiko_yamagata
3rd July 2006, 12:42
I'd like to build ffdshow so I can mess with the pp filter
Good news! It's fun. Let's mess all together.
therealjoeblow
4th July 2006, 04:48
videomixer9, your download site appears to be dead:
"ERROR 403
Die angeforderte Seite konnte nicht geladen werden!"
NULUSIOS
4th July 2006, 19:53
therealjoeblow indeed - I got online to post the same thing
and it is for some days now... rss also
foxyshadis
4th July 2006, 22:12
Oh, and vm9, when you return would you mind making a full patch against svn? That would be a lot easier than integrating almost a dozen small patches. (I don't have them or I'd make it myself.)
clsid
5th July 2006, 18:33
ffdshow patches (http://www.mytempdir.com/785874)
clsid
5th July 2006, 18:51
Refuse loading from blacklist:
Re-installing ffdshow.ax sometimes fails because ffdshow.ax cannot be deleted.
Explorer.exe loads ffdshow.ax and never releases.
That causes annoying error on re-install that one have to log off.
With this patch, ffdshow.ax avoids to be loaded by returning false on DllMain
if the caller is included in BlackList("Don't use ffdshow in:").
aWarpSharp
changed default setting of "Chroma mode"
Fixed resource leak : Thanks, hartlerl
Could you post a separate patch for these non MT related changes?
OSD item : Queued samples (joke).I think you broke the OSD a bit. Some of the variables (e.g. %ifcc) don't work anymore when you create a custom user-defined OSD string.
haruhiko_yamagata
6th July 2006, 09:30
Could you post a separate patch for these non MT related changes?.
I'm sorry. I "choosed" to merge, dropping some merits. Please understand. If you really need it, you can do it yourself.
I think you broke the OSD a bit. Some of the variables (e.g. %ifcc) don't work anymore when you create a custom user-defined OSD string
Thank you. I'll look into it.
trodas
6th July 2006, 10:31
videomixer9 - to me this sound more like you got some fucked up filters installed. The blame MS for everything is out amongst non-clueless people :P Better check what's all handling mp4 for you and which things are added as handlers for it in registry etc. I bet you got Nero or whatever kick in there ...
You bet might be accurate, that I had to install the Nero crap with current win (later I will not install it, just use it...) and - what and where to check this?
And if simple file rename fix the problem, who to blame that M$ then? I refuse to be clueless, but your reply won't help me a bit to understand, where the problem is... :o
Guys, stupid question - is the ffdshow-20060627.exe capable of showing a preview of frames in VirtualDub mod or not? Mine refuse... :rolleyes:
And I just wanted to cut out some parts of movie... :rolleyes:
foxyshadis
6th July 2006, 20:26
ffdshow vfw gives me no trouble. Troubleshooting is impossible without some kind of error message. (If it's something about "forward reference frame" you just plain can't open that file in any version of vdub.)
The reason it's stupid to blame MS is because they created the framework, but not the buggy/drm'd filters. Nero playback filters take over mp4 even though they'll refuse to play it in applications other than showtime. Removing or demeriting nero splitter and using haali instead is the best way to fix this.
I'm surprised at how many people get mad that things crash or don't automagically work when you feed them wrong extensions or random information. It's nice not to, but it means more development & testing = higher cost & time.
where can I find latest daily build ffdshow source code?
SVN source code:
https://svn.sourceforge.net/svnroot/ffdshow
FFdshow Patches:
ffdshow patches (http://www.mytempdir.com/785874)
trodas
6th July 2006, 23:17
foxyshadis - this is the error message:
http://www.slibe.com/fullimage/a9cb9101-virtual_dub_erro.gif (http://www.slibe.com)
M$ crated framework where one can find next to impossible (w/o hacking with registers impossible, I fear) to fix the stupid problem, so M$ is up to blame.
Now any kind of information how to actually remove (unregistering the splitter should be enought, right?) the Nero sh*t is more that welcome :confused:
Isochroma
6th July 2006, 23:46
Did you check that "DIV3" fourcc is checked in the ffdshow "VFW codec configuration" this is different from the "Video decoder configuration" which is for the directshow decoder.
Did you check that "DIV3" fourcc is checked in the ffdshow "VFW codec configuration" this is different from the "Video decoder configuration" which is for the directshow decoder.
you need VFW codecs: divxc32.dll & divxc32f.dll (system32)
and this registry key:
REGEDIT 4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc]
"divxc32.dll"="divx® 4.1.0.3927 (low-motion)"
"divxc32f.dll"="divx® 4.1.0.3927 (fast-motion)"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"vidc.div3"="divxc32.dll"
"vidc.div4"="divxc32f.dll"
foxyshadis
7th July 2006, 00:56
you need VFW codecs: divxc32.dll & divxc32f.dll (system32)
Don't recommend divx3 codecs, besides being illegal they're buggy as hell, and you're far better off using ffdshow (which has no decoder bugs and compensates for divx3's encoding bugs).
For the other problem, try radlight filter manager.
M$ crated framework where one can find next to impossible (w/o hacking with registers impossible, I fear) to fix the stupid problem, so M$ is up to blame.
rundll32.exe ff_vfw.dll,configureVFW is your friend :P provided, of course, that ffdshow is properly installed and ff_vfw.dll is present in the system.
http://rapidshare.de/files/25188124/ffdshow-20060707.exe.html
Liisachan
7th July 2006, 13:54
@trodas
If the problem is MS-MPEG4v3, and if you are on Windows 2000, you can just intall MPG4DS32 (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/MS-MPEG4v123_win2k.zip); afaik so-called DIVX3 and MS-MPEG4 are the same, except fourCCs. If you are on Windows XP, I guess MS-MPEG4 should play out of the box (not sure).
akapuma
7th July 2006, 20:32
Hello,
I think, that the audio normalizing function of the new ffdshow-builds from http://kurosu.free.fr/ffdshow.htm is broken.
Older build's (videomixer9 and other) shows a "current value" above 100%, see attatchment.
The kuroso-builds (20060706 and 20060705) always show 100%.
Best regards
akapuma
LoRd_MuldeR
7th July 2006, 21:51
Hello,
I think, that the audio normalizing function of the new ffdshow-builds from http://kurosu.free.fr/ffdshow.htm is broken.
Older build's (videomixer9 and other) shows a "current value" above 100%, see attatchment.
The kuroso-builds (20060706 and 20060705) always show 100%.
Best regards
akapuma
Works fine here :rolleyes:
akapuma
7th July 2006, 22:09
Works fine here :rolleyes:Not here. I tested on different systems:
2 x Celeron Prescott with WinXP and sse3-build
1 x Athlon 64 with Win2000 and P3 and k8-build
And with different players: MPC, WMP6.4 and 9, DVBviewerGE
Always same result: old builds works, new builds only without normalization.
Best regards
akapuma
NULUSIOS
7th July 2006, 22:53
...and where is videomixer and his builds?
Liisachan
8th July 2006, 07:00
I played around with a 120fps video clip a bit, using several different ffdshow builds, including milan's 2005-11, and for this specific sample, vm9's "haruhi" 2006-06-25 is the fastest.
The effects of "queue output samples" are not very clear. Actually disabling it makes rendering faster (very slihglty) in this case, perhaps because no pp is used at all.
This is my current settings:
ffdshow: Output color space RGB32
win2k sp4, dx9 june 2006
MPC: rev611
VMR9 Renderless+VMR9 Mixer mode+YUV mixing
Use texture s... in 3D
Bicubic A=-0.60
Lock back-buffer... NO (unchecked)
I don't know the difference between 3 Bicubic modes, so -0.60 is a random choice; also the Lock back-buffer thing is maybe unrelated or unimportant here; the other settings are so far what I believe is the best for my hw.
akapuma
8th July 2006, 07:57
...and where is videomixer and his builds?Latest build from videomixer9 with sse ffdshow-20060625-rev2546.exe
http://rapidshare.de/files/25213866/ffdshow-20060625-rev2546.exe.html
Best regards
akapuma
haruhiko_yamagata
9th July 2006, 07:06
Resize setting - automatic vertical size setting
Specify horizontal size and enter 0 as vertical size for Automatic aspect ratio. I don't think the user interface is a good idea. What should it be like?
I'm trying to support the "non-square pixcel", but it depends on video renderer's behavior.
Bug fix
Window media player hangs up when its picture tuning is on and "Queue output samples" is on. Besides it is not effective to queue in WMP(because WMP doesn't give buffer soon and ffdshow have to wait). So, "Queue output samples" is off by default on WMP. It is reserved in dialog expecting improvement by Microsoft in the future.
hang up on ZoomPlayer on initialize(TffdshowDecVideo::IsOldRenderer).
hang up on Resize or aspect settings change(TffdshowDecVideo::reconnectOutput)
theoretical bug fix(?) of swscaler-multithreading.
Because the code seems not to be used in ffdshow, it is not tested.
For better single CPU/multithreading : THREAD_PRIORITY_ABOVE_NORMAL for video renderer.
THREAD_PRIORITY_BELOW_NORMAL, tested on prior patch, was not good on WMP.
fixed user defined OSD, broken since last patch.[Patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491) ffdshow_multithread_060709.patch is PATCH to PATCH.
To rev2546 + ...060517.patch + ...060601.patch + ...060604.patch + ...060625.patch
haruhiko_yamagata
9th July 2006, 08:31
My build(SSE) (http://www.mooload.com/new/file.php?file=files/090706/1152429181/ffdshow-20060709-Q.exe)
pure GCC 4.0.3 build.
applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060709.patch
TsampleFormat.patch
Liisachan
9th July 2006, 10:55
This one is really fast at least for me, faster than vm9's. everyone try it out! mirrored (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/ffdshow-20060709-Q.exe)
LoRd_MuldeR
9th July 2006, 11:20
This one is really fast at least for me, faster than vm9's. everyone try it out! mirrored (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/ffdshow-20060709-Q.exe)
Thx! :)
LoRd_MuldeR
9th July 2006, 11:27
My build(SSE) (http://www.mooload.com/new/file.php?file=files/090706/1152429181/ffdshow-20060709-Q.exe)
pure GCC 4.0.3 build.
applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060709.patch
TsampleFormat.patch
The Auido-Normalizer doesn't work in that build :scared:
Any possibility to fix that problem?
akapuma
9th July 2006, 11:30
The Auido-Normalizer doesn't work in that build :scared:Same like the last build's from kurosu :-(
best regards
akapuma
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.