New ffdshow build (?)

[Isochroma]

Your video card doesn't do hardware colorspace conversion properly. In this case, make sure to uncheck all the YUV output formats. Also while you're there, check "High Quality colorspace conversion". If you're using the registered version of CoreAVC for AVC decoding, then select the output colorspace as either RGB24 or RGB32 in the decoder window. And if you happen to be using the XviD decoder filter, set the output colorspace also to RGB24 or RGB32.

My FX5200 and GeForce MX400 don't do it right either. Others have reported this issue; it seems to effect mostly Nvidia cards.

[Romario]

What about IV50, and IV40/41 fourCC support in future FFDSHOW builds.

Can someone make stable patch, so I can watch IV50(Indeo Codec 5.11) video on my computer?

Or, how I can directly contact Milan Cutka via email. If someone knows his email, send it via Private Message to me. Thank you.

[Liisachan]

@LoRd_MuldeR
possibly nVidia's known problem--uh not a problem but it's by design.

to let nVidia+YUV+overlay work as 0-255:
...Example (NVidia ForceWare 78.01 WHQL)...
- Color Correction -> Apply color changes to: "Overlay" / Brightness "120%" / Contrast "101%"
- Video Overlay Settings -> Hue "0" / Saturation "102%"

Still, I'm one of RGB24/32 lovers too, actually.
RGB is slightly better than YUV, even if colorspace is ok, that's my experience; perhaps it's just that my hw is baka.

@Romario
http://sourceforge.net/tracker/?atid=471492&group_id=53761&func=browse

[thuan]

About new vm9's icl9.1 build, it's faster on my computer (AMD T-bred 1.5GHz). Here's the results with timecodec:new icl9.1 r2546
User: 52s, kernel: 0s, total: 52s, real: 53s, fps:70.2 dfps: 69.6
r2546 vm9's normal build
User: 64s, kernel: 0s, total: 65s, real: 65s, fps:56.8 dfps: 56.2 File tested: first 2 mins of Maison Ikkoku - 93 [TD].avi. Output colorspace YV12. The file is pretty old (use DIV3) so for acceptable quality when watching I use mplayer PP with Accurate deblocking and no automatic quality control, denoise3d hq and xsharpen. I also use those settings for the benchmark above.

Just normal decoding there's not much difference like vm9's comment.

[videomixer9]

hm ... the denoise3d and xsharpen must been the better working stuff there. Looks like it got some pros for filter users so I guess I do icl builds at least once in a while ...

[foxyshadis]

A quick test, comparing videomixer's icl and gcc builds, on my SSE3 core duo...

avc, no resize
ffdshow icl9 ~ User: 48s, kernel: 0s, total: 49s, real: 50s, fps: 156.5, dfps: 152.8
ffdshow gcc ~ User: 48s, kernel: 0s, total: 49s, real: 51s, fps: 157.6, dfps: 151.3
coreavc 1.0b ~ User: 6s, kernel: 0s, total: 6s, real: 21s, fps: 1118.6, dfps: 359.9

asp, resize, pp
ffdshow icl9 ~ User: 37s, kernel: 0s, total: 38s, real: 47s, fps: 198.2, dfps: 161.2
ffdshow gcc ~ User: 37s, kernel: 0s, total: 38s, real: 46s, fps: 196.5, dfps: 162.6

asp, resize, pp, deband, warpsharp
ffdshow icl9 ~ User: 132s, kernel: 1s, total: 133s, real: 143s, fps: 56.8, dfps: 52.6
ffdshow gcc ~ User: 136s, kernel: 1s, total: 137s, real: 149s, fps: 55.2, dfps: 50.7

I guess the filters I use just don't benefit, probably because they're already at least SSE. Of course, the lavc decoding doesn't at all. And coreavc is still waaay faster than lavc. (I still don't use it though, I like ffdshow's filters too much.) And the results were a bit variable between runs, so I tried to keep system use to a minimum.

OT, it'd be nice is sharpen and warpsharp dialogs were combined sometime.

[o2xygen]

with mplayer post and accurate deblock at automatic quality control. VMR9 RENDERER
My cpu is a Pentium III 1ghz SSE. all tests were carried out at the same environment.
sample
Video: DivX 5 512x384 23.98fps 1537Kbps [Video 0]
Audio: MPEG Audio Layer 3 48000Hz stereo 128Kbps [Audio 1]


bob0r build
ffdshow-20060423-gcc4.0.3-sse-mt-x264.nl.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.8, dfps: 76.6

Celtic Druid build
ffdshow-rev2529-SSE.exe
User: 9s, kernel: 0s, total: 9s, real: 14s, fps: 107.7, dfps: 73.6

issa builds
ffdshow-2539-gcc-sse-20060603.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.6, dfps: 73.4
ffdshow-2546-icc-sse-20060506.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.0, dfps: 72.5

dirk paehl build
ffdshow-20060423_gcc4.1_speed.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.0, dfps: 75.8
ffdshow-svn_2536_gcc.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.7, dfps: 77.4

videomixer9 builds
ffdshow-20060505-rev2546.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 104.7, dfps: 77.8
ffdshow-rev2533.exe
User: 9s, kernel: 0s, total: 9s, real: 13s, fps: 109.7, dfps: 77.9

[Reino]

videomixer9, at the moment I'm using your release posted here (http://forum.doom9.org/showthread.php?p=823871#post823871).
Could it be possible you (or someone else?) changed something on the libfaad2?
When I try to play this (http://www.megaupload.com/?d=8HUIR042) MPG[AVC1+AAC]-file, sound is really distorted with libfaad2 somehow (with realaac everything if fine...)
This wasn't an issue with previous FFDShow releases.

[videomixer9]

yeah that compile has a problem and I replaced it with something else iirc cause libfaad2 was borked by gcc and it's vectorizer that was applied to it. please replace it. These distortions happen if the floating point code is broken.

hm best dfps in o2xygen's test :p

[LoRd_MuldeR]

Your video card doesn't do hardware colorspace conversion properly. In this case, make sure to uncheck all the YUV output formats. Also while you're there, check "High Quality colorspace conversion".

Done!

possibly nVidia's known problem--uh not a problem but it's by design.

Can't be nVidia's Problem, because I have ATI graphics card (Redeon 9800 Pro) ^^
But as long as RGB gives much better quality, I'll just disable YUV and be happy :)

[_xxl]

http://www.intel.com/cd/ids/developer/asmo-na/eng/257129.htm

[Liisachan]

Software-side RGB *will* guarantee a good result, but not for free--it costs much CPU time. For a "heavy" codec like SNOW, Dirac, software-side RGB might be a bit difficult, especially when softsubbed. Other than CPU cost (in other words, you won't make most of the HW accelerators), there's nothing wrong in it. I use ffdshow-side RGB myself too. I even set Codec | Raw Video = All YUV so that any non-ffdshow-supported codec like RG40 VP7 will be RGB'ed too thru ffdshow.

But I thought that problem (YV16-235 in HQ Overlay) was only in nVidia drivers' default. It's news to me that the similar can happen more generally. Thanks for that report, LoRd_MuldeR :)

[MatMaul]

I have compiled pure GCC builds without the mt patch.
See here for more informations (http://matmaul.googlepages.com/)
Thanks to videomixer9, his google page is my model.
@ videomixer9 : If you don't want I use text of your page, just send me a PM or tell that here.

[bob0r]

Wow, Sourceforge SVN is already fucked again, after 400 retries i finally got 2546 source.

Ill be doing SSE and SSE2 builds for x264.nl

Both builds are done, but there is a huge problem.
ffdshow DTS decoding is horrible, sound get very loud and all messy, my reciever even decided to turn itself off.

So ffdshow-2546-gcc4.0.3-sse-x264.nl.exe and ffdshow-2546-gcc4.0.3-sse2-x264.nl.exe are now fully automated aswell (only manual compile as not every revision will be online)

I hope Milan can fix this horrible bug asap!
( http://sourceforge.net/tracker/index.php?func=detail&aid=1487390&group_id=53761&atid=471489 )

I advice anyone NOT to play DTS files using the
latest revision until this issue is resolved, it Can
blow up your audio system.

[videomixer9]

btw. is there any way to get icl to compile tomsmocomp and kerneldeint in sane timespans that is not hours or days? i gave up on libmplayer and libavcodec with icl, both perform horrible compiled with it. resizing gets awful slow with libmplayer compiled with icl.

btw. nothing blown up here with 2546 and DTS ... :p must be a compiler error.

I'll have a typical testing file and that one boosted up to some nice record values for me ...

todays icl build ...
User: 79s, kernel: 0s, total: 80s, real: 83s, fps: 422.9, dfps: 405.1
vs my mt-2539 build which had only:
User: 87s, kernel: 0s, total: 87s, real: 95s, fps: 387.2, dfps: 356.4

on the same file ... I'm amazed. gotta go back to tweak some more ...

Also, does any x64 processor have SSE3? Next build for x64 I'd like to just use SSE3 as default target.

[Egh]

I'll have a typical testing file and that one boosted up to some nice record values for me ...

todays icl build ...
User: 79s, kernel: 0s, total: 80s, real: 83s, fps: 422.9, dfps: 405.1
vs my mt-2539 build which had only:
User: 87s, kernel: 0s, total: 87s, real: 95s, fps: 387.2, dfps: 356.4

on the same file ... I'm amazed. gotta go back to tweak some more ...

Also, does any x64 processor have SSE3? Next build for x64 I'd like to just use SSE3 as default target.

Wow :approved: It seems we really have record holder now. Even on my athlon XP 1800+ I noticed faster seeking in video (that's 720p XVid and some filters enabled).

As for SSE3. You're not quite right.
Older A64 models do NOT support SSE3. Clawhammer&Newcastle&Winchester models dont' have it. SSE3 was introduced into A64 range only in Venice&SanDiego cores.

[videomixer9]

ah damn ... I only checked some pricelists and saw SSE3 listed everywhere, so I assumed every 64bit modell has it.

[Egh]

Software-side RGB *will* guarantee a good result, but not for free--it costs much CPU time. For a "heavy" codec like SNOW, Dirac, software-side RGB might be a bit difficult, especially when softsubbed. Other than CPU cost (in other words, you won't make most of the HW accelerators), there's nothing wrong in it. I use ffdshow-side RGB myself too. I even set Codec | Raw Video = All YUV so that any non-ffdshow-supported codec like RG40 VP7 will be RGB'ed too thru ffdshow.

But I thought that problem (YV16-235 in HQ Overlay) was only in nVidia drivers' default. It's news to me that the similar can happen more generally. Thanks for that report, LoRd_MuldeR :)

First, it's not only NVidia problem. Second that correction you told is only approximate iirc, not true conversion.

It's very easy though to convert if you have Avisynt installed. Add "ColorYUV(levels="TV->PC")" line into avs section in ffdshow and enjoy :)

Since RGB conversion actually takes into account that source signal is within TV range (and RGB is always full range) enabling only RGB output in ffdshow fixes the problem. If you don't do "high quality conversion" you don't actually loose much on CPU %.

And of course, simplest way to emulate conversion w/o changing colorspace would be to enable ffdshow filter Levels :P Use 16-235 as input and full range as output. Thus you can restore colors w/o RGB output :P

[Liisachan]

@Egh
Yeah, what I actually meant was: VMR9 Renderless RGB vs. Overlay YUV. The difference of CPU cost is significant, but like you said, YUV->RGB is not the slow part.

There is no 'only-one' formula to convert YUV to RGB, so the phrase "true conversion" doesn't make much sense. Avisynth uses one of the common algos--the Rec.601 matrix coeffs--by default, but that's not the only one, either. On the other hand, this conversion is float calc lossily cast to int, so like you said, everyhing is more or less just approximate, not losslessly reversible.

Personally, I do love ffdshow's RGB24/32 output (hq conv), I too feel that software-side rgb is higher-quality too, altho I've never tried double-blind tests :P

[Egh]

@Egh
There is no 'only-one' formula to convert YUV to RGB, so the phrase "true conversion" doesn't make much sense. Avisynth uses one of the common algos--the Rec.601 matrix coeffs--by default, but that's not the only one, either. On the other hand, this conversion is float calc lossily cast to int, so like you said, everyhing is more or less just approximate, not losslessly reversible.



I meant that altering brightness/constrast etc is not actually a true conversion. That wasnt' releated to YV12<->RGB. For the *true* conversion from TV to PC range in software you either have to use avisynth or ffdshow "Levels" filter (making input as 16-235 there).

P.S. Concerning coefficients -- Rec.601 and Rec.709 are both possible in AVS. I wonder which one ffshow actually uses :P

[dk75]

I advice anyone NOT to play DTS files using the
latest revision until this issue is resolved, it Can
blow up your audio system.[/B]
Rest assured. No one will use these new builds... cause it's nowhere to find.

[haruhiko_yamagata]

To 2546 bug fix. Seek problem.

http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[flanger216]

Videomixer9: when I try to install your latest x64 build, I get the error, "Error while registering ffdshow.ax" . 32-bit builds install fine.

[issa]

Rev 2546 build using ICC 9.1,

Compiler: ICC 9.1.22 (msvcrt 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/20323670/ffdshow-2546-icc-sse-20060513.exe.html) or MegaUpload (http://www.megaupload.com/?d=JFVWJJU2)

Please try it and see if there is a speed improvment.

[bob0r]

...

btw. nothing blown up here with 2546 and DTS ... :p must be a compiler error.

...


Ya probably, only my compiler did not change, ffdshow source did, so indeed something is broken.



Another issue: Am i the only one with ffdshow SVN checkout issues????

I get errors like there:
A ffdshow\src\ffmpeg\libavcodec\i386\dsputil_svn: REPORT request failed on '/svnroot/ffdshow/!svn/vcc/default'
svn: REPORT of '/svnroot/ffdshow/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
mmx_avg.h

A ffdshow\src\dialog\CmaskingSKAL.h
A svn: REPORT request failed on '/svnroot/ffdshow/!svn/vcc/default'
svn: REPORT of '/svnroot/ffdshow/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
ffdshow\src\dialog\Cin.h
A ffdshow\src\dialog\Cvolume.h

And then it does not complete the checkout, i have to run it a few times so it gets completed.
Only then i see "Checked out revision 2546.", but not the first time.
(i use svn co https://svn.sourceforge.net/svnroot/ffdshow/trunk ffdshow)

(could possibly be the cause of the DTS error aswell, though i don't think so)

[haruhiko_yamagata]

Multithreading of swscaler handles "Resize", "Sharpen/swscaler" and "Blur & NR/swscaler gaussian blur". As reported here, when two of them is checked and one try to uncheck one while playing, older mt versions crash. This patch includes bug fix for it.
http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[videomixer9]

Videomixer9: when I try to install your latest x64 build, I get the error, "Error while registering ffdshow.ax" . 32-bit builds install fine.

msvcrt for x64 is not included in the x64 build, get the special x64 runtime libs. As the installer would also install it on a 32bit system I didn't include it so that noone can break stuff. Also of course ffdshow64 only installs properly on Win64, it's not for 64bit processors running 32bit version of Windows.

http://www.microsoft.com/downloads/details.aspx?FamilyId=90548130-4468-4BBC-9673-D6ACABD5D13B (x64 VC Runtimes)

SVN checkout works like a charm here, sf.net never had less problems for me. DTS lib is version 0.0.2 or so since ages, I would be surprised to see any real changes there and the other audio handling stuff seems fine.

[o2xygen]

all with mplayer post and accurate deblock, auto Quality.control- VMR9 RENDERER
CPU= 1Ghz PIII SSE
Sample
Video: DivX 5 512x384 23.98fps 1537Kbps [Video 0]
Audio: MPEG Audio Layer 3 48000Hz stereo 128Kbps [Audio 1]


BOB0R BUILDS
ffdshow-20060423-gcc4.0.3-sse-mt-x264.nl.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.8, dfps: 76.6


CELTIC DRUID BUILDS
ffdshow-rev2529-SSE.exe
User: 9s, kernel: 0s, total: 9s, real: 14s, fps: 107.7, dfps: 73.6


ISSA BUILDS
ffdshow-2539-gcc-sse-20060603.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.6, dfps: 73.4

ffdshow-2546-icc-sse-20060506.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.0, dfps: 72.5

ffdshow-2546-icc-sse-20060513.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.7, dfps: 80.1


DIRK PAEHL BUILDS
ffdshow-20060423_gcc4.1_speed.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.0, dfps: 75.8

ffdshow-svn_2536_gcc.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.7, dfps: 77.4


VIDEOMIXER9 BUILDS
ffdshow-rev2533.exe
User: 9s, kernel: 0s, total: 9s, real: 12s, fps: 108.1, dfps: 83.6

ffdshow-20060509-rev2546.exe
User: 9s, kernel: 0s, total: 10s, real: 12s, fps: 106.8, dfps: 83.1

ffdshow-20060512-rev2546-icl91.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.9, dfps: 81.9


MATMAUL BUILDS
ffdshow-20060512-rev2546-SSE.exe
User: 9s, kernel: 0s, total: 9s, real: 13s, fps: 108.0, dfps: 81.2
Videomixer's builds are still the fastest
issa's latest ICL build gained much speed than the previous one
Matmaul's build seems fast as well

[MatMaul]

ffdshow rev. 2546

requires: SSE or SSE2
compilers: pure GCC (4.0.3+4.1.1)
specials: high accuracy tremor, high accuracy libmad, libavcodec 6ch vorbis fix, mt bugfix
download: SSE (http://matmaul.googlepages.com/ffdshow-20060513-rev2546-mt_bugfix-SSE.exe), SSE2 (http://matmaul.googlepages.com/ffdshow-20060513-rev2546-mt_bugfix-SSE2.exe)
more informations here (http://matmaul.googlepages.com/)

Thanks haruhiko_yamagata, your patch works great, I can now seek in my video.

[bob0r]

@videomixer9

Can you do a full compile with only gcc 4.0.3 then?
Also can you please pack up and put 2546 source online somewhere?

(or anyone else for that matter)

Edit:
@videomixer9
http://forum.doom9.org/showthread.php?p=827091#post827091
That build has fucked up DTS audio as well, meaning its most likely ffdshow SOURCE and CPU dependant.

So forget the above compile and put online requests, i already filed this as bug report, lets just wait what the answer is.

Also i will test 2543 first, it's possible this issue was introduced with revision 2544.

If only i could get the sources......:
cd Subversion\bin
svn co -r 2543 https://svn.sourceforge.net/svnroot/ffdshow/trunk ffdshow

svn: REPORT request failed on '/svnroot/ffdshow/!svn/vcc/default'
svn: REPORT of '/svnroot/ffdshow/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)

PFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Thank god the SVN system allows 100x checkout untill all files are completed :P (or svn up for that matter)

[videomixer9]

My build has fine DTS sound, your soundsystem is broken. Same with your SVN client :p The real broken thing is only LPCM.

sources ... http://bittekeinspam.googlepages.com/rev2546.7z

[flanger216]

msvcrt for x64 is not included in the x64 build, get the special x64 runtime libs. As the installer would also install it on a 32bit system I didn't include it so that noone can break stuff. Also of course ffdshow64 only installs properly on Win64, it's not for 64bit processors running 32bit version of Windows.

http://www.microsoft.com/downloads/details.aspx?FamilyId=90548130-4468-4BBC-9673-D6ACABD5D13B (x64 VC Runtimes)

Yeah, I tried that, but still no joy... here's my installation log, if it helps:

Output folder: D:\Program Files\ffdshow
Extract: ffdshow.ax... 100%
Extract: libavcodec.dll... 100%
Extract: TomsMoComp_ff.dll... 100%
Extract: libmplayer.dll... 100%
Extract: libmpeg2_ff.dll... 100%
Extract: ff_liba52.dll... 100%
Extract: ff_wmv9.dll... 100%
Extract: ff_tremor.dll... 100%
Extract: ff_theora.dll... 100%
Extract: ff_libmad.dll... 100%
Extract: ff_libdts.dll... 100%
Extract: ff_libfaad2.dll... 100%
Extract: ff_realaac.dll... 100%
Extract: ff_samplerate.dll... 100%
Extract: ff_unrar.dll... 100%
Extract: ff_x264.dll... 100%
Extract: ff_kernelDeint.dll... 100%
Extract: audxlib.dll... 100%
Extract: audxlib.def... 100%
Extract: msvcr80.dll... 100%
Extract: Microsoft.VC80.CRT.manifest... 100%
Could not load: D:\Program Files\ffdshow\ffdshow.ax

Again, don't worry about it too much; the 32-bit builds work great, and I doubt the x64 compiles really make much difference. I just wanted to finally test something legitimately 64-bit on my new XP64 install :)

[flanger216]

Here's a brainstorm...

Win64 has two 'program files' directories: 'C:\program files' for x64 applications and 'C:\program files (x86)' for x86 applications. When I try to install the x64 version of ffdshow, the installer defaults to 'C:\program files (x86),' so Windows erroneously thinks it's a 32-bit application instead of 64-bit. So, when the installer tries to register ffdshow.ax, perhaps it's trying to use the 32-bit version of regsvr32.exe instead of the 64-bit version? I checked, and there are in fact two versions in two seperate directories (c:\windows\system32 and \syswow64).

Sorry... probably talking out my ass here, but I know xp64 isn't all the widespread around here, so hopefully it'll help.

[videomixer9]

the crt is in it? uh ... maybe delete it then. I dunno, does Win64 also use regsvr32 to register? maybe try register it manually. If a binary is 64bit or 32bit shouldn't be detected on the directory but via the file header. If you register it manually it should complain about why it cannot be loaded or shows a crash e.g. so e.g. do regsvr32 c:\program files\ffdshow\ffdshow.ax (or is it regsvr64 on win64?) so maybe try regsvr64 c:\program files\ffdshow\ffdshow.ax

Also, you do have an SSE3 capable CPU? (e.g. Athlon 64 Clawhammer&Newcastle&Winchester don't have it as reported by Egh)

because not so many people have win64 this responses are my only clue if the builds work so your report is very welcome.

[bob0r]

My build has fine DTS sound, your soundsystem is broken. Same with your SVN client :p The real broken thing is only LPCM.

sources ... http://bittekeinspam.googlepages.com/rev2546.7z

Not when its CPU related!
Like i said ffdshow-20060420-gcc4.0.3-sse-x264.nl.exe does have fine DTS audio.
Ill try find out from which revision DTS audio goes wrong.

2543 is still broken too.

My SVN client is not broken, as it does the same on 3 other Computers aswell.

Most likely some SF SVN setting that is wrong, because AMS-IX usually knows best :)

[videomixer9]

Well I cannot reproduce that problem on any of my PCs with any of my DTS movies. That's a P4, P3 and Athlon XP. Perfect sound coming out of my 5.1 system hooked up via creatives propiertary multichannel pcm cable. You got any broken sample? preferably not dts in wave *hate*

Though thinking about it, did you test a file where dts is in wave and it just decodes it as regular 2ch PCM which usually sounds like plain distorted noise ...

[bob0r]

Well I cannot reproduce that problem on any of my PCs with any of my DTS movies. That's a P4, P3 and Athlon XP. Perfect sound coming out of my 5.1 system hooked up via creatives propiertary multichannel pcm cable. You got any broken sample? preferably not dts in wave *hate*

Though thinking about it, did you test a file where dts is in wave and it just decodes it as regular 2ch PCM which usually sounds like plain distorted noise ...

http://mirror05.x264.nl/public/x264.dts.sample.mkv

Please can you put an sample online too, then we should know enough.

[clsid]

Here's a brainstorm...

Win64 has two 'program files' directories: 'C:\program files' for x64 applications and 'C:\program files (x86)' for x86 applications. When I try to install the x64 version of ffdshow, the installer defaults to 'C:\program files (x86),' so Windows erroneously thinks it's a 32-bit application instead of 64-bit. So, when the installer tries to register ffdshow.ax, perhaps it's trying to use the 32-bit version of regsvr32.exe instead of the 64-bit version? I checked, and there are in fact two versions in two seperate directories (c:\windows\system32 and \syswow64).

Sorry... probably talking out my ass here, but I know xp64 isn't all the widespread around here, so hopefully it'll help.
Since the installer is 32-bit, Windows will indeed think the stuff in it is also 32-bit.

You could try moving the files to the 64-bit program files folder and manually registering ffdshow.ax with regsvr64.exe

[videomixer9]

afaik there isn't an nsis that produces special x64 installers so i'm kinda wondering how to get that stuff solved then ... hm.

That dts track in that sample is indeed broken and total overdrive. Hm need to cut part of some mkv, need to get tools first so may take a bit.

Okay some part of Howl with non-broken dts. fear superior japanese dvd. http://rapidshare.de/files/20377932/dts_sample.avc.mkv.html

[bob0r]

@videomixer9

r2524 | milan_cutka | 2006-04-22 17:02:19 +0200 (Sat, 22 Apr 2006) | 2 lines

merged changes from Dscaler5 libdts


Seems there lies the problem.

(ironicly 1 revision after the build i put on x264.nl :p)

[videomixer9]

great ... so milan broke dts and lpcm, wonder what's next :p I merged back parse.c from proper libdts and reuploaded my build with a libdts that actually works for that example too.

So this (http://bittekeinspam.googlepages.com/ffdshow-20060513-rev2546-icl91.exe) build now has the mt fixes and fresh from svn checked out libdca (libdts) plus the vorbis fix ... milan really needs to get back fixing lol.

[Skelsgard]

I´m having trouble downloading builds on googlepages. The download suddenly stop at bout 1.7 Mbs and reports "Download completed", but of course the .exe is broken. It´s happening with bobor´s and vm9´s builds. Yet vcredist_x86 and audxlib.dll download properly. Anybody having this problem?

[thuan]

Happen here too, but if you use a download manager then it went fine.

[Skelsgard]

I´ll try that, thnx, man :).

[flanger216]

the crt is in it? uh ... maybe delete it then. I dunno, does Win64 also use regsvr32 to register? maybe try register it manually. If a binary is 64bit or 32bit shouldn't be detected on the directory but via the file header. If you register it manually it should complain about why it cannot be loaded or shows a crash e.g. so e.g. do regsvr32 c:\program files\ffdshow\ffdshow.ax (or is it regsvr64 on win64?) so maybe try regsvr64 c:\program files\ffdshow\ffdshow.ax

Also, you do have an SSE3 capable CPU? (e.g. Athlon 64 Clawhammer&Newcastle&Winchester don't have it as reported by Egh)

because not so many people have win64 this responses are my only clue if the builds work so your report is very welcome.

There's a 32-bit version of regsvr32 in 'c:\windows\system32' and a 64-bit version in '\sysWOW64,' which, unfortunately, is also called regsvr32 . You think they could've at least changed the name of the executable, but I guess that's why I don't work at Microsoft.

Anyway, I'm away from my comp now, but tomorrow night I'll try cracking open the installer and registering ffdshow.ax myself. I do have a SSE3-capable Athlon64, so hopefully it should work, and then I'll report on whether it actually runs better.

[zambelli]

I'm experiencing a strange problem with ffdshow when transcoding videos to a Windows Mobile device using WMP10's sync feature.

I used to have the 12-21-05 x264.nl build installed and everything worked peachy. Then I upgraded to the 4-20-06 x264.nl build and suddenly all the transcoded videos (in: XviD, out: WMV9) started coming out upside down and mirrored. Whaaa? OK, I figured something was wrong with the new build, so I reverted back to 12-21-05 - and all my transcoded videos are still coming out flipped and mirrored.

Things I know:
1) Playback of the same XviD videos works fine in WMP10 and MPC. Even playback through VfW in VirtualDub works fine.
2) Encoding in standalone WME9 works fine - the videos transcode correct side up.
3) Ffdshow is definitely being used during WMP's transcoding process. I can see the ffdshow tray icon show up and the info shows the XviD video being decoded.

So my conclusion is that something is different in my Ffdshow configuration this time around. What could cause the video to be flipped and mirrored on decode just for this one graph? My ffdshow video config is pretty standard. No postprocessing features are checked - it's pretty much the default install config, really.

Any ideas or similar experiences?

[zambelli]

I'm experiencing a strange problem with ffdshow when transcoding videos to a Windows Mobile device using WMP10's sync feature.
OK, I've discovered the solution to my problem in the meantime. :) Rather than deleting the original post, I'll just post the solution here to help anyone else who runs into the same issue:

Apparently "Allow output format changes during playback" in the Output tab was the culprit. If checked, the image somehow gets flipped and mirrored during decode. I'm not sure why this is happening only in a transcoding graph (one where the output is not a renderer) though. If left in the default "indeterminate" state, the problem goes away and the image is decoded correctly. That sounds like a bug.

[Link00y]

Hi,

first of all: your ffdShow builds are great!

it was already mentioned once here.. I checked all your versions to find out that since ffdshow-20060504-rev2544 "decoding" uncompressed audio is impossible, making the ffdShow audio processor totally unusable. I downgraded to ffdshow-20060503-rev2541 and things work again - actually I'd like to have audio processing so that even for none supported codecs or codecs supported by the player itself (like MPC with its MPEG audio decoders) can still be upmixed (using the mixer feature) to 5.1 (Speaker configuration: 3/2+LFE) as ffdShow does that much better than my own sound card driver (Sound Blaster Audigy).

And if you accept: one minor request (but really: IT HAS TIME); the Mixer is a great feature in my eyes however I also often get Mono videos with 1/0 audio.. the 3/2 upsampling matrix does in fact nothing for these streams; I'd like to have a more advanced custom matrix system where I cannot simply type in settings for the input configuration I currently listen to but for all input types (in fact the best request name would be "Custom output speakers configuration")

Thank you,

Link00y

[haruhiko_yamagata]

Hi,

first of all: your ffdShow builds are great!

it was already mentioned once here.. I checked all your versions to find out that since ffdshow-20060504-rev2544 "decoding" uncompressed audio is impossible, making the ffdShow audio processor totally unusable. I downgraded to ffdshow-20060503-rev2541 and things work again - actually I'd like to have audio processing so that even for none supported codecs or codecs supported by the player itself (like MPC with its MPEG audio decoders) can still be upmixed (using the mixer feature) to 5.1 (Speaker configuration: 3/2+LFE) as ffdShow does that much better than my own sound card driver (Sound Blaster Audigy).

It happens on my machine too. It seems to be since rev2522.

[foxyshadis]

Good news haruhiko! The deadlocks when filtering with avisynth from before are also gone, thanks to your fix!

Bad news videomixer. aWarpSharp filter trashes the U chroma plane on the latest build. :( This happens if chroma is set to "downsampled" or "independent". Has anything changed since your last build? wait, nm, it happens in all recent builds, bizarre. It also seems to eat even more cpu than limitedsharpen, so I'll probably use that instead.