View Full Version : New ffdshow build (?)
_ck_
18th November 2006, 11:05
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
19th November 2006, 00:47
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
19th November 2006, 04:51
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
20th November 2006, 19:29
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
21st November 2006, 13:31
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
21st November 2006, 22:24
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
22nd November 2006, 00:08
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
22nd November 2006, 10:16
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
22nd November 2006, 10:50
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
22nd November 2006, 16:00
I have compiled ffdshow with mingw gcc-core-4.0-20061116.
http://www.mytempdir.com/1076752
LoRd_MuldeR
22nd November 2006, 17:21
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
22nd November 2006, 17:55
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
22nd November 2006, 18:43
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
22nd November 2006, 19:55
My mistake. It was not a h.264 clip.
haruhiko_yamagata
23rd November 2006, 09:31
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
23rd November 2006, 10:20
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
23rd November 2006, 10:48
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
23rd November 2006, 11:17
Fixed.
OK, I'm relieved.
fastplayer
23rd November 2006, 13:01
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
23rd November 2006, 14:12
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
23rd November 2006, 14:25
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
24th November 2006, 05:40
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
24th November 2006, 06:50
This levels bug that was corrected...should I see any difference after I update my ffdshow?
popper
24th November 2006, 15:05
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
24th November 2006, 15:16
Actually, the PS3 can run AVC and MPEG-4 ASP directly, no need for ffdshow there.
Lys
24th November 2006, 22:06
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
24th November 2006, 22:11
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
24th November 2006, 22:14
TimeCodec (http://haali.cs.msu.ru/mkv/timeCodec.exe). You'll need Haali Media Splitter installed too.
Lys
24th November 2006, 22:47
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
24th November 2006, 23:28
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
24th November 2006, 23:36
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
24th November 2006, 23:59
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
25th November 2006, 00:06
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
25th November 2006, 03:57
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
25th November 2006, 16:22
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
25th November 2006, 17:12
@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
25th November 2006, 18:32
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
25th November 2006, 22:38
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
25th November 2006, 23:59
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
26th November 2006, 01:00
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
26th November 2006, 01:56
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
26th November 2006, 18:42
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
26th November 2006, 19:05
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
26th November 2006, 21:07
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
26th November 2006, 22:03
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
27th November 2006, 10:59
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
27th November 2006, 11:37
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
27th November 2006, 12:19
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
27th November 2006, 14:19
@Romario, please upload a small sample file.
Blight
27th November 2006, 15:47
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?
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.