New ffdshow build (?) [Archive] - Page 5

Liisachan

24th April 2006, 08:46

Yet another flavor :D

ffdshow-20060423_gcc4.1_speed.exe (http://www.paehl.com/open_source/?FFDSHOW)

Hm, I'm just not happy with these SSE and SSE2 builds

I kind of regret updating now. I remember having a build from Feb 6, 2006 ICL9 unicode. Is there somewhere I can get the latest ICL9 build?
That -mt- patch is not for stability. There are many builds recently, I know about 15 builds for rev.2523. What are you looking for. According to celtic_druid, "Infact MSVC8 seems to be the most stable (talking about ffdshow.ax). ICL I guess would be ok for most of the plugins. Then you have an MSVC8/ICL/gcc build though." If what you are looking for is ffdshow-20060203-icc-sse or ffdshow-20060202-icc-sse2 i put them here (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/).

JarrettH

24th April 2006, 09:12

The one CLSID posted works pretty good actually.

SVN: 2006-04-20 (rev. 2523)
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, mplayer.dll, kerneldeint.dll)
Minimum CPU requirement: MMX
Download: click here (http://rapidshare.de/files/18585145/ffdshow-svn2523-20060420.exe.html)

I noticed using Live TV the SSE and SSE2 builds were definitely not as fast as what I had been using and looked a bit more aliased in places. Does ICL9 mean it could have been SSE/SSE2? It didn't specifically say in About ffdshow.

Ah it must have been Feb 3rd then ;)
You are so kind for uploading that for me!!:D

haruhiko_yamagata

24th April 2006, 12:41

Thank you very much, bob0r. They works nicely on my computer.
Originally Posted by multiblitz
Same setting with the ffdshow-20060423-gcc4[1].0.3-sse2-mt-x264.nl.exe version:

One CPU at 90-95%, the other at 35-40%; total at 65-75%, so some MT haopens; Stuttering is much worse that in Milan's version of 20051129, every 5 secs.
Hello, multiblitz. I will investigate. This may take several days. Thank you.

haruhiko_yamagata

24th April 2006, 13:13

Hello, LoRd_MuldeR.
Originally Posted by LoRd_MuldeR
Question:

Does the MT patch effect multi CPU systems only?
Can I expect any improvements for my single CPU too?
Or could the MT patch even lower performance for a single CPU?
MT patch is not supposed to affect performance on single CPU. You can not expect any improvements for single CPU. MT patch check CPU count (just read from memory) and this is some overload. But this can be ignored.

In regard to bugs, there is room for them. The critical session, m_csReceive, is locked at different timing.

Video is running more fluid, but still not very well. Audio/Video is now in sync, but I get heavy "clicking" sounds all the time. So I'm not sure what is better...

CPU usage with *new* build (single CPU):

Thank you for detailed report.
I have no idea why.
Strange CPU usage curve with up and down. Does that occur on other builds without MT patch?

To investigate this, I would like to know

the application and its version ( and How to get)
how to get Superman trailer
the setting of ffdshow and application.

haruhiko_yamagata

24th April 2006, 14:00

I found a multithreading related bug.
It crashes Zoom Player!!

Confession : I have not tested with Zoom Player.

foxyshadis

24th April 2006, 14:14

I'm pretty sure the cpu curve is caused by avisynth. When I enable limitedsharpen on mine, cpu usage is ~70%, but occasionally dips to zero for a second or two and freezes, before resuming. Other ffdshow-specific maniplations (such as resize, subtitles, etc) don't show that behavior whether they use 20% or 80% total cpu.

Rawr, vsfilter crashes on here but ffdshow refuses to show the first line of softsubs, so I'm all out of luck for subs. ;_;

LoRd_MuldeR

24th April 2006, 15:03

Hello, LoRd_MuldeR.

To investigate this, I would like to know

the application and its version ( and How to get)
how to get Superman trailer
the setting of ffdshow and application.

Thanks for info. But does MT patch do any harm on single CPU or is it just without any effect and I can use the new builds with no risk?

The application is "Media Player Classic" with output set to "VMR7 (Windowed)". This setting seems to give best results on my machine. I use latest build from Celtic Druid. And I have *no* filters enabled in ffdshow at all. Excpet I did some testing with resize-filter: Downsizing to 640x384 (Fast Bi-Linear filter) seems to improve performance a little compared to full resolution of 1920x1088, but of course image quality suffers and it still does not play good...

You can download that trailer right here:
http://jfl1974.free.fr/upload/superman.mp4

haruhiko_yamagata

24th April 2006, 16:23

Originally Posted by LoRd_MuldeR
Thanks for info. But does MT patch do any harm on single CPU or is it just without any effect and I can use the new builds with no risk?

There is some risk even if you use single CPU. Just relatively safe.

Thanks for the detail. I'm downloading superman.

LoRd_MuldeR

24th April 2006, 16:32

There is some risk even if you use single CPU. Just relatively safe.

Thanks for the detail. I'm downloading superman.

So I hope there will be some new(!) builds *without* MT patch available...

multiblitz

24th April 2006, 19:12

It would be great if the most used filters in ffdshow would have separate threads, i my case this would be:

- (maybe de-interlace)
- Denoise 3d in HQ-Mode
- Lanszos Resizing at 4 tap+ and Lanszos Sharpening
- Sharpening with Unsharp-Mask

and this in combination with VMR9+zoomplayer. It would be simply wonderful if MT allows us to have this quality (ideally with limitesharpening / avisynth) in RGB32 at 1080p, which is today totally unfeasible (BTW, my x2 3800 runs at 2450 mhz)

Egh

24th April 2006, 19:30

So I hope there will be some new(!) builds *without* MT patch available...

Exactly. Especially taking into account that two new revisions were made to SVN already since 2524.

And kuroshu builds with patches are rather buggy, even casual sse1 build. In my case, for instance, b0b0rs build plays mpeg files ok, but kuroshu build with same settings doesn't do that properly. Both are same revision and both are sse1 only.

So for single CPU systems I would still like to get not patched builds :P

clsid

24th April 2006, 20:16

SVN: 2006-04-24 (rev. 2526)
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, mplayer.dll, kerneldeint.dll)
Minimum CPU requirement: MMX
Download: click here (http://rapidshare.de/files/18838575/ffdshow-svn2526-20060424.exe.html)

Liisachan

24th April 2006, 20:26

Thanks clsid!!!

@Egh
following the svn version is one thing, experimenting with mt is another. Each has its own value.

Liisachan

24th April 2006, 20:39

celtic_druid returns!

ffdshow-rev2526-SSE2.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2526-SSE2.exe)

asasadad_1

24th April 2006, 21:20

clsid's ffdshow build always works well on my machine(especially in libmpeg2).:thanks:

i cann't install celtic_druid's new ffdshow build (when register ffdshow.ax, there is error).

videomixer9

24th April 2006, 21:25

the main trick is not using gcc 4.x :O

celtic_druid

24th April 2006, 21:41

I used ICL9 for libmpeg2.

Build is unicode and requires SSE2. Other than that it should work.

LoRd_MuldeR

24th April 2006, 21:43

I used ICL9 for libmpeg2.

Build is unicode and requires SSE2. Other than that it should work.

Too sad I don't have no SEE2 support :mad:

celtic_druid

24th April 2006, 21:59

For about €100 you should be able to get a Sempron 3000+ and a cheap MB. So basically just sacrifice a night of drinking and you can have SSE2. No idea what Sempron's are like at video though esp. socket 754 ones. Probably not worth it.

asasadad_1

24th April 2006, 22:00

http://img246.imageshack.us/img246/9563/snap17ca.jpg
yes,my cpu support sse2,xp sp2

Liisachan

24th April 2006, 22:05

celtic's one installed on Win2k but doesn't install for me on winxp, with Runtime Error R6034 (http://ffdshow.faireal.net/tmp/r6034.png).

Normal (svn2526 clsid) vs. mt (20060423-sse-mt-x264.nl)

YES! mt does work, more or less. For a testing purpose, I used something I've never used:
- Postprocessing (Presets mplayer)
- Resize to 640x480 to 800x600 Lanczos
And this is what I almost always use:
- output colorspace RGB32, hq conv

Player is MPC celtic_druid Rev 604, VMR-9 Renderless, subpic buffer disabled. Tested on Prescott 3.4 GHz HT enabled, Windows XP SP2

http://ffdshow.faireal.net/tmp/ffdshowmt.png

EDIT: I captured Task Manager at a random time while playing the same file (I should have done that at the exactly same timing but I didn't...) So "Normal" and "mt" can't be compared side by side, but we can roughly conclude that mt is working, i.e. one of the two (shown as the left pane) is nearly equal to 0% with the normal version, but significantly non-zero with the mt version.

celtic_druid

24th April 2006, 22:40

Problem with manifest files again. Win2k doesn't care about them so it installs. XP I don't know. I tried with name='Microsoft.VC80.CRT' and it still won't load the runtime library.

videomixer9

24th April 2006, 22:47

I WANT TOO BUILD! all the newest freaky stuff, still generic build though... o_O

ffdshow-rv2526.exe: click here (http://rapidshare.de/files/18859754/ffdshow-rv2526.exe.html) or here (http://www.megaupload.com/de/?d=HZDO6OF7)

LotharZ

25th April 2006, 00:18

@videomixer9

libmpeg2 no works with your new build, even disabling SSE2.
Running now with your "ffdshow-20060408_msvc8_gcc41_sse" smoothly.

@celtic_druid

And yours cant be installed under Win2003, error with Visual C++ libraries.

videomixer9

25th April 2006, 00:35

bummer ... updated links to hopefully fixed version ...

http://www.megaupload.com/de/?d=HZDO6OF7
http://rapidshare.de/files/18859754/ffdshow-rv2526.exe.html

LotharZ

25th April 2006, 00:47

Problem solved, everything works perfectly.

thx

Rash

25th April 2006, 05:02

Dammit! The superman trailer pwned my computer! It is an Athlon 64 3200+ with a GeForce 6800GT. Where are you guys running this video?

Liisachan

25th April 2006, 12:23

Would that change the default vorbis decoder? If so, Yes, I think so. I assume almost everyone here agrees that lavc is safer than tremor at least for now.
This is going to be reality (http://sourceforge.net/tracker/index.php?func=detail&aid=1468239&group_id=53761&atid=471492). When asked to use the high-quality mode of Tremor, milan replied:

I'd like to leave tremor as it is as fast but not so high-quality
option for those with slower computers and make libavcodec
the default decoder for vorbis.
Do you or others have vorbis samples which aren't decoded
correctly with libavcodec vorbis decoder? I'd like to fix
them if there are any before making libavcodec vorbis
decoder the default.

Would lavc for vorbis decoding be 100% ok already? Afaik, yes, but does anyone know anything?

celtic_druid

25th April 2006, 13:28

I made lavc default for my installer. Just a pitty that it only works under win2k due to the manifest/dependancy problem. Now that I think about it I think I had the same problem with 64bit builds under X64.

clsid

25th April 2006, 17:23

Decoding audio doesn't use much cpu power in general. So I think high-quality is the best option, even for slow computers.

Btw, is high accuracy equivalent to the 32-bit mode of CoreVorbis?

Liisachan

25th April 2006, 17:34

That's what I suggested, but what milan says makes sense too (for really slow CPU). Tremor vs. libavcodec vs. CoreVorbis etc etc...that's a really difficult question, like "Which MP3 decoder is the best?" I have a vague impression that CoreVorbis is the best, but without proof. As for Tremor low vs high, I have a solid ABX proof.

I asked the same question in HA.org and it looks like no one got any problem with lavc.
http://www.hydrogenaudio.org/forums/index.php?showtopic=43983
Only, I was asked "why writing another independent Vorbis decoder in libavcodec, possibly buggy, when there is already proper one delivered by Xiph...?" which I cannot answer for sure. I thought maybe ffmpeg devs needed to make it GPL, not using a BSD-style license of libvorbis...but that's just a random guess. I could say "maybe because they hate xiph" but saying that in HA.org would be a bad idea, i guess.

Yong

25th April 2006, 17:40

ffdshow libavcodec-vorbis decoder have problem decoding 6-channels Ogg vorbis file.

videomixer9

25th April 2006, 18:08

ffdshow rev. 2527

requires: a CPU, with SSE preferably
compilers: GCC 4.1.1 + MSVC 8
specials: hopefully high accuracy tremor, maybe libavcodec default vorbis decoder
links: here (http://rapidshare.de/files/18909341/ffdshow-rv2527.exe.html) and here (http://www.megaupload.com/de/?d=B69NO8JR)

Egh

26th April 2006, 02:45

ffdshow rev. 2527

I downloaded the one from megaupload.

Error while registering ffdshow
Is shown during the installation.

I got Win XP SP2. b0b0r version (svn2523 iirc) is still nice.

I think is it actually installers code problem? :O

foxyshadis

26th April 2006, 04:39

Oh right, I need to report a bug in the mt builds. Seeking is screwy - it sometimes works, and sometimes just quits decoding video after the seeked-to frame. Maybe it has to do with landing on the wrong type of frame. It won't even restart at the next I-frame, I waited to make sure. Normal builds always seek just fine.

Liisachan

26th April 2006, 05:25

ffdshow libavcodec-vorbis decoder have problem decoding 6-channels Ogg vorbis file. I can't test it since my system is just stereo. Are you sure? and is Tremor OK with that? do you happen to know would libvorbis ok with 6-chan vorbis?

Liisachan

26th April 2006, 06:09

I think libavcodec does have problems with 6ch vorbis, and Tremor works better in this case.

Can anyone confirm?
Sample: xvid+6ch_vorbis.ogm (http://ffdshow.faireal.net/tmp/xvid+6ch_vorbis.ogm) 2.5MB

-Edit-
This is what I'm hearing. (channel 1 Front Left)
tremor_FL.wav (http://ffdshow.faireal.net/tmp/tremor_FL.wav) at least decent
lavc_FL.wav (http://ffdshow.faireal.net/tmp/lavc_FL.wav) "bubbly" artifacts

celtic_druid

26th April 2006, 06:40

Looks like a problem with the manifest again. Had the same problem with MPC. XP didn't like MSVC8's autogenerated manifest file. Remove it or replace it and it would run. MPC doesn't require Microsoft.VC80.CRT though. Haven't figured that one out yet.

Anyone got a MSVC8 built ffdshow.ax to register?

edit:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="ffdshow.ax" type="win32" />
<description>WindowsExecutable</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>

That works. If you have MSVC2005 you can just open the ax and replace the manifest. External manifests are ignored when registering, so they won't help.

I'll put a new build up later.

videomixer9

26th April 2006, 08:05

I downloaded the one from megaupload.

Is shown during the installation.

I got Win XP SP2. b0b0r version (svn2523 iirc) is still nice.

I think is it actually installers code problem? :O

Install VC8 runtime libs! get vcredist_x86.exe from MS site. Last time had the same with people that were all missing the runtime libs.
http://faux.warwickcompsoc.co.uk/vcredist/vcredist_x86.exe

videomixer9

26th April 2006, 08:31

LoRd_MuldeR

26th April 2006, 10:35

ffdshow rev. 2529

requires: a CPU, with SSE preferably
compilers: GCC 4.1.1 + MSVC 8 (ffdshow.ax)
specials: high accuracy tremor
tested: yes, working
links: here (http://rapidshare.de/files/18954480/ffdshow-rv2529.exe.html) or here (http://www.megaupload.com/de/?d=ZVPYYON9) (identical files just other hoster)

needs MSVC8 runtime libs, otherwise fails registering!!!

Here is one problem I found:
If I play WMV content, go to the ffdshow controls and switch to the "Info" page, then MPC just crahes and disappears without error message...

celtic_druid

26th April 2006, 11:44

WMV1 is working fine here, including the info page.
I did a SSE build this time to. Although I haven't tested it. Should install fine now though.

videomixer9

26th April 2006, 12:03

I don't use ffdshow for WMV usually, especially not WMV3. I have no real clue why it crashes except gcc messing it up. I wouldn't recommend ffdshow for WMV3 in any case though. I'll look into that for the next build, though I need to acquire an WMV video for that first as I usually avoid those. Guess I have to do my own somehow as WMV1/2 is not really used anymore since quite some time, if the crash is produced by WMV3 then I skip on this as WMV3 and ffdshow is stupid game, it works then it maybe doesn't and so on, even depends on the encoding settings and more :O

Another story about these runtime libs for MSVC 2005 (v8), the runtime libs should have external manifests so just getting dlls isn't enough usually.

Liisachan

26th April 2006, 12:11

lavc+vorbis6ch=buggy is confirmed by the 3rd party too.
vorbis 6ch = problematic on ffmepg too so probably it's not just ffdshow's pb but the pb is in lavc vorbis.c itself.
Thank you very much Yong, for this critical report :) Without you things might be foobared without knowing that problem.

Anyway celtic_druid's new builds:
- ffdshow-rev2529-SSE.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2529-SSE.exe)
- ffdshow-rev2529-SSE2.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2529-SSE2.exe)

Let's hope they will install on XP :)

changelog (http://ffdshow.faireal.net/bakaupdates.php)

LoRd_MuldeR

26th April 2006, 12:33

WMV1 is working fine here, including the info page.
I did a SSE build this time to. Although I haven't tested it. Should install fine now though.

Approved. Thanks for the SSE build :D

However it still crahes on the "Info" page during WMV playback.
That's not a big problem, because I avoid WMV too.
But sometimes I get WMV files and since ffdshow supports it, why not use it then?
The fewer M$ filters we need, the better :cool:

Liisachan

26th April 2006, 12:37

celtic's SSE & SSE2 now both install on XP for me.
that mt patch is not included, or if it is, it's not working for me this time.
no other obvious things so far.

celtic_druid

26th April 2006, 12:44

No mt patch in either build. WMV containing what? I only tested WMV1.

Who uses 5.1 vorbis anyway?

LoRd_MuldeR

26th April 2006, 12:48

Dammit! The superman trailer pwned my computer! It is an Athlon 64 3200+ with a GeForce 6800GT. Where are you guys running this video?

I just noticed that it helps a lot to change AAC decoder from "libfaad2" to "realaac". At least the heavy "clicking" sounds are gone and audio is okay now. A/V sync is also pretty much okay. Only video is still stuttering...

LoRd_MuldeR

26th April 2006, 12:52

No mt patch in either build. WMV containing what? I only tested WMV1.

WMV3 only I think. Problem is there with *all* WMV3 files I tested. With some WMV1 file I tested there's no problem.

But: The only problem is the "Info" page in ffdshow controls. Playback itself works fine for me...

thuan

26th April 2006, 12:54

LoRd_MuldeR you're probably playing a WMV3 file with ffdshow WMV3 codec enable by hand in the registry. I have the same problem when I do it, but then again WMV3 is not offically supported, and if I'm right ffdshow just load Microsoft decoder to do it anyway, so there's no point in enabling it.
BTW it doesn't crash with ffshow WMV3 decode with MPC here just Zoom crashes.

LoRd_MuldeR

26th April 2006, 13:02

if I'm right ffdshow just load Microsoft decoder to do it anyway, so there's no point in enabling it.

Oh really ???

videomixer9

26th April 2006, 13:04

prolly, the libav decoder for WMV3 is in vc9.c and this doesn't come with ffdshow's version of libav, however it's based on the vc-1 reference decoder afaik and not recommended to be used anyways, hence you're better of using ms filter directly, comes with windows anyways.

LoRd_MuldeR

26th April 2006, 13:17

haruhiko_yamagata

26th April 2006, 13:18

Originally Posted by foxyshadis
Oh right, I need to report a bug in the mt builds. Seeking is screwy - it sometimes works, and sometimes just quits decoding video after the seeked-to frame. Maybe it has to do with landing on the wrong type of frame. It won't even restart at the next I-frame, I waited to make sure. Normal builds always seek just fine.

:thanks: I tested seek bar of MPC and Windows Media Player 10. It worked.
Because Zoom Player crashes without showing any frame,
I think I must test more applications.
Please tell me what application do you use.

I'm trying to debug, though it is hard ^^;

Egh

26th April 2006, 16:19

Milan actually started responding to the entries on the ffdshow bugtracker, so I guess some old bugs are going to be corrected soon :approved:

Important info for gcc builders from Milan Cutka:

Date: 2006-04-25 08:54
Sender: milan_cutkaProject Admin
Logged In: YES
user_id=547197

I'm afraid the problems with GCC 4.1.0 aren't caused by ffdshow source code but by GCC 4.1 bug (or at least by build for MinGW). I'm almost certain there is nothing I could do to fix it. I compared assembly output of GCC 4.0 and 4.1 and those generated by GCC 4.1 are missing underscores in mangled symbol names (such as _ZN11CBaseFilter15QueryVendorInfoEPPw) in the parts of code where those symbols should be defined. So for now only GCC 4.0.3 is supported - if you'd find a problem compiling ffdshow using this compiler, report it to me. I promise I'll respond quickly.
I also hope GCC 4.1 gets fixed.

Liisachan

26th April 2006, 16:30

Who uses 5.1 vorbis anyway? Not me, but Yong. He/She uses it and that's why he/she could report that. But what's more important is, now its clear that vorbis decoder in LAVC is buggy, and it's possible that the decoding quality for normal 2ch vorbis is not perfect. which matches my vague impression that CoreVorbis is the safest/best DS Vorbis decoder too.

Egh

26th April 2006, 16:33

Not me, but Yong. He/She uses it and that's why he/she could report that. But what's more important is, now its clear that vorbis decoder in LAVC is buggy, and it's possible that the decoding quality for normal 2ch vorbis is not perfect. which matches my vague impression that CoreVorbis is the safest/best DS Vorbis decoder too.

AFAIK the 6ch vorbis per se is buggy. I mean that most people do not recommend to use it at all at this moment. Some even promised to correct that and do proper 6ch vorbis... A year ago already :P

Liisachan

26th April 2006, 16:37

oh, I see. you mean that fishy org?
um, but then again, BeLight has an option to directly convert AC3 5.1 to Vorbis 5.1, so I guess there are a few ppl who want to do that. I would use AC3 as it is if I needed 5.1 tho. Or maybe AAC? But I don't own 5.1 sound system, so...

foxyshadis

26th April 2006, 17:30

5.1 vorbis only isn't recommended because it has no channel coupling logic, so even vorbis backers point people to aac for that right now. There's no quality bugs (with the reference decoder), just that it's a lot larger than it has to be for any given quality.

haruhiko, I'll give wmp a try, but I've been using zoom player and mpc to test with. Also, haali's splitter. I've only done testing with mpeg4 (asp/avc) and mpeg1 so far. But, I can't get it to happen now, after shutting windows down for the night, so I guess it was something else! Weird.

Shirokuu

26th April 2006, 18:47

Risking going slightly off topic with the next question, but i have for months - maybe years already - an issue with using FFDSHOW combined with the Haali splitter and TMPEGenc. For some reason it happens with any FFDSHOW build since about a year ago so i guess it's not FFDSHOW related perse. Maybe somebody happens to know a workaround?

When feeding TMPEGEnc a matroska file with multiple audio tracks and one or more subtitles tracks, the subs don't get displayed. FFDSHOW feeds TMPEGenc with video and audio and Haali takes care of parsing the subtitles embedded in the MKV. With regular playback through the core player, BSP or MPC the subs DO appear.

A workaround would be to use MKVExtract to extract the embedded to a SRT file, and using FFDSHOW itself to parse the subtitles from the SRT. Of course TMPEG displays the subtitles this way, but TMPEG becomes instable when converting the MKV to for instance a DVD compliant MPEG2 stream. And on top of that two Haali splitters icons appear in the system tray. Strangely on normal playback using any player of your choice the regular amount of icons appears, namely one.

Both on my regular PC with the old 2004 stable FFDSHOW build, Haali 1.5 and TMPEG 2.0 and on my laptop with the latest FFDSHOW, Haali 1.6 and TMPEG Xpress 3.0 this behaviour occurs.

celtic_druid

26th April 2006, 19:04

TMPGEnc's dshow input is somewhat buggy and I believe mkv is officially not supported. So if it works at all, I guess you should be happy.

Shirokuu

26th April 2006, 19:21

MKV is indeed not officially supported so i have no real reason to complain of course. But I hoped to get MKV's working by using the VFAPI dshow input ability offered by TMPGEnc. I guess i have to take the long route: splitting a MKV into seperate streams with MKVExtract and feeding TMPGEnc the audio, video and subtitle streams manually through FFDSHOW.

issa

27th April 2006, 03:03

SVN Rev. 2531 icc 9 with gcc 4.1.1 build,

unicode build: ffdshow-20060426-icc-rev2531-unicode.exe (http://rapidshare.de/files/19025631/ffdshow-20060426-icc-rev2531-unicode.exe.html)

foxyshadis

27th April 2006, 05:11

Shirokuu, you can probably just extract the subtitles and use vsfilter to put them on the movie as hardsubs (at least, I'm pretty sure vfapi allows using vdub plugins on the source, if not, there's always avisynth). No need to separate it all and then try to line it back up again. If you want softsubs, you need them external to convert to vobsubs anyway. (Assuming dvd, not mpeg-1.)

videomixer9

27th April 2006, 08:16

SVN Rev. 2531 icc 9 with gcc 4.1.1 build,

unicode build: ffdshow-20060426-icc-rev2531-unicode.exe (http://rapidshare.de/files/19025631/ffdshow-20060426-icc-rev2531-unicode.exe.html)

i did any build in unicode so far, i think it's not even worth mentioning anymore as it is naturally to use unicode if available. Besides that it seems that ICL still does a better job on libmpeg2 e.g. but only marginal sadly. The .ax file seems to be no different with any compiler still hm.

Liisachan

27th April 2006, 12:55

5.1 vorbis only isn't recommended because it has no channel coupling logic, I can see your point very well. The audio part of the above sample is like 500Kbps, but the original AC3 is 384kbps, this is totally meaningless except for a testing purpose.
What you mean by "no channel coupling logic" is, it's not taking advantage of channel-correlations, such as in "mid-side coding"? (I'm not sure about those technical terms, but I mean, "does it compress each chan independently when chans are sharing a lot of similar data?")

@Shirokuu
If I have time I'll do more investigating, but I reckon... what you are trying to do is essentially like this?
If so, it's not TMpgEnc, but VSFilter doesn't like it. Maybe. Not 100% sure because this is my 1st time to try 2 connect graph this way.

http://ffdshow.faireal.net/tmp/vs2avimux.png

Shirokuu

27th April 2006, 14:20

Liisachan, that IS exactly what I was trying to do. Thanks for trying to reproduce the problem. You would reckon it would make no difference in a real player or in TMPGEnc, but it does. Is there a way around VSFilter that I could try?

Liisachan

27th April 2006, 14:56

This is not ffdshow-related, but here's what I would do.

First do this:
mkvinfo in.mkv

check fps, and the track number of sub you want.
...
| + Default duration: 41.708ms (23.976 fps for a video track)
...
| + Track number: 5
...
| + Codec ID: S_TEXT/UTF8
| + Language: eng

now, do this:
mkvextract tracks in.mkv -c WINDOWS-1252 5:WinLatin.srt

-c is for charset. if omitted, the result is UTF-8 (in that case you might need to re-save the .srt in UTF-16 or something)
5 is the track number

Make my.avs which looks like....

LoadPlugin("path\to\VSFilter.dll")
DirectShowSource( "in.mkv", fps=23.976 )
## Or, + AssumeFPS
# DirectShowSource( "in.mkv", fps=23.976 ).AssumeFPS( 24000, 1001, false )
## If upside down do
# FlipVertical()
TextSub( "WinLatin.srt" )

Open my.avs by MPC to check if it's ok. If it's ok, load my.avs to TmpgEnc.
The above won't take more than 1 minute or so.

EDIT: If it's dual-audio, maybe you need to demux the audio to handle it separately. AssumeFPS is technically needed because ((float)23.976) is not equal to = 23976/1000 nor = 24000/1001 in binary. If it's 25.000fps. not needed at all.

foxyshadis

27th April 2006, 14:58

I can see your point very well. The audio part of the above sample is like 500Kbps, but the original AC3 is 384kbps, this is totally meaningless except for a testing purpose.
What you mean by "no channel coupling logic" is, it's not taking advantage of channel-correlations, such as in "mid-side coding"? (I'm not sure about those technical terms, but I mean, "does it compress each chan independently when chans are sharing a lot of similar data?")
Yep, that's exactly the problem. 5.1 mixing is more complex than stereo coupling, I understand, but same idea. It's been on the todo list, but I guess no one's been available to do it in a while (most of the development outside aoyumi's tweaks seems to concentrate on speex and theora now).

videomixer9

27th April 2006, 17:05

ffdshow rev. 2532

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://rapidshare.de/files/19057679/ffdshow-rev2532.exe.html) or here (http://www.megaupload.com/de/?d=E6EGBBNQ) or here (http://www.filepoint.de/download/2841-dl-ffdshow-rev2532_exe) (no nagging)(2.93 MB)

namchik

27th April 2006, 20:05

Wow! It seems that latest SSE2 build by celtic_druid doesn't crash when libmpeg2 used :cool:

videomixer9

27th April 2006, 22:14

ffdshow rev. 2533

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://rapidshare.de/files/19084161/ffdshow-rev2533.exe.html) or here (http://www.megaupload.com/de/?d=IZD51S29)

changes: VMR9 color controls

issa

28th April 2006, 04:27

SVN 2533 icl 9 with gcc 4.1.1 unicode build,

URL: RapidShare (http://rapidshare.de/files/19102971/ffdshow-rev.2533-20060428-icc.exe.html) or MegaUpload (http://www.megaupload.com/?d=0VVWDA4C) [no sse & sse2 require]
URL: RapidShare (http://rapidshare.de/files/19105309/ffdshow-rev.2533-20060428-icc-intel.exe.html) or MegaUpload (http://www.megaupload.com/?d=QSPWCRAA) [sse2 intel cpu require]

namchik

28th April 2006, 06:28

issa
sse2 intel cpu require
is it for intel cpus only? I'm asking coz i have AMD 64...
and does it crash when libmpeg2 is used for decodeing mpeg2?

issa

28th April 2006, 06:55

issa

is it for intel cpus only? I'm asking coz i have AMD 64...
and does it crash when libmpeg2 is used for decodeing mpeg2?

Use the [no sse & sse2 require] version, it will use sse & sse2 when you have it.
The [no sse & sse2 require] compiled with CFLAGS "-QaxKW",
the [sse2 intel cpu reqire] compiled with CFLAGS "-QxN" & "-msse2 -mfpmath=sse".

JarrettH

28th April 2006, 07:46

SVN Rev. 2531 icc 9 with gcc 4.1.1 build,

unicode build: ffdshow-20060426-icc-rev2531-unicode.exe

thanks...just the stuff i'm looking for:cool:

where can i see the changes between these various builds?

Liisachan

28th April 2006, 08:08

Log (http://ffdshow.faireal.net/bakaupdates.php), more (http://svn.sourceforge.net/viewcvs.cgi/ffdshow?rev=2534&sortby=date&view=rev)

videomixer9

28th April 2006, 08:28

ffdshow rev. 2534

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, more experimental gcc switches
download: here (http://www.filepoint.de/download/2870-dl-ffdshow-rev2534_exe) or here (http://rapidshare.de/files/19110555/ffdshow-rev2534.exe.html) or here (http://www.megaupload.com/de/?d=MKML8A61)

Yama4050242

28th April 2006, 11:21

@issa
your build can not decode the x264 clip i made long time ago, sample here
http://rapidshare.de/files/19117988/sample.rar.html

videomixer9

28th April 2006, 13:41

ffdshow rev. 2535 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, more experimental gcc switches
download: here (http://www.filepoint.de/download/2883-dl-ffdshow-20060428-rev2535_exe) or here (http://rapidshare.de/files/19125295/ffdshow-20060428-rev2535.exe.html) or here (http://www.megaupload.com/de/?d=H9P10Z1M)

changes: vertical and horizontal image flipping

videomixer9

28th April 2006, 15:29

ffdshow rev. 2536 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, even more experimental gcc switches
download: here (http://www.filepoint.de/download/2895-dl-ffdshow-20060428-rev2536_exe) or here (http://rapidshare.de/files/19132438/ffdshow-20060428-rev2536.exe.html) or here (http://www.megaupload.com/de/?d=GH3BR3ES) or here (http://bittekeinspam.googlepages.com/ffdshow-20060428-rev2536.exe) (2.90 MB)

changes: DeBand filter

videomixer9

28th April 2006, 17:54

ffdshow rev. 2537 x64 tryout build
download here (http://www.filepoint.de/download/2938-dl-ffdshow64-20060428-rev2537_exe)

beware ... SLOWWWW! not milans fault, only mine :O

LoRd_MuldeR

28th April 2006, 18:25

ffdshow rev. 2536 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, even more experimental gcc switches
download: here (http://www.filepoint.de/download/2895-dl-ffdshow-20060428-rev2536_exe) or here (http://rapidshare.de/files/19132438/ffdshow-20060428-rev2536.exe.html) or here (http://www.megaupload.com/de/?d=GH3BR3ES) (2.90 MB)

changes: DeBand filter

Hey, why you don't make a small Homepage for your builds? Or at least a pure realese therad where the link is always in the first post (like Shartooth's x264 builds)? Would be much nicer, since this way I could permanently link to that thread...

BTW: What does "DeBand" do ???

videomixer9

28th April 2006, 18:41

i don't have a real example of banding on my hand, however you can add nice ghost shadows to people on fine videos with it :p It removes vertical bands that some video sources have, it seems to be an error that occurs mostly for analog input sources through interferences or broken cables afaik.

as for a homepage try this one, remembered I could "abuse" google for this:
http://bittekeinspam.googlepages.com/

Rash

28th April 2006, 21:05

Please no spam!:thanks: :D

bob0r

29th April 2006, 02:54

I could fully automated ffdshow builds, just like x264, as it also uses svn.
But, i think its better you update ffdshow every few days or revisions numbers, even when Milan farts, its added to the SVN.

Just a though, its a free world, but i am not hosting each revision of ffdshow :cool:

LoRd_MuldeR

29th April 2006, 14:59

as for a homepage try this one, remembered I could "abuse" google for this:
http://bittekeinspam.googlepages.com/

Looks good :) I'll link to that one!

Egh

29th April 2006, 17:48

foxyshadis

29th April 2006, 19:24

Personally, I'm only updating MT builds, so that alone is why I appreciate bob0r's contribution. ;)

videomixer9

29th April 2006, 20:57

videomixer9

30th April 2006, 00:18

ffdshow rev. 2538 MULTITHREADED VERSION

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060429-mt-rev2538.exe)

the patch is note exactly made for this revision so it's a unknown to me if it works.

LoRd_MuldeR

30th April 2006, 01:04

videomixer9

30th April 2006, 01:13

means you got no Dual-Core processor? well okay i don't have one either and the build works for me too, just wonder if it really does it's work on dualcores. Patching app threw some errors but seemed to have applied most things except for the outdated patching of .nsis2 file.

One reason I don't like external patches is that they tend to not fit anymore with even some trivial code changes here and there and need extra updates. I seriously hope milan does something about this soon.

foxyshadis

30th April 2006, 01:48

Well, I don't have time to in-depth test it now, but it works fine during normal viewing, no crashing and burning or anything.

haruhiko_yamagata

30th April 2006, 15:53

I seriously hope milan does something about this soon.

Thank you very much. But I think I have to fix at least the major bug with Zoom Player(maybe concern to other applications) before accepted.

MatMaul

30th April 2006, 15:59

ffdshow rev. 2538 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060429-rev2538.exe)

changes: minor msvc bugfixes by milan, I use this to try some more funny tweaks, this time some for caching.

Can you also activate high accuracy for libmad please ?
You can find the diff patch for activate accuracy mode for libmad here (http://kurosu.free.fr/ffdshow-update.tar.bz2) (made by kurosu (http://kurosu.free.fr/ffdshow)).

videomixer9

30th April 2006, 16:03

indeed, seems like this patch vanished after I had it applied and fiddled around a bit. Doing a new build now with 2539 revision and libmad patched too. The multithreading seems to give no harm in performance on single cpu so I'll keep it, if anyone thinks this isn't the case inform me please. As for a bug with ZoomPlayer ... dunno about that but it seems to work fine here as far as I can see, if anyone gets errors with this patch I'll also do an patchless version.

ffdshow rev. 2539

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad, multithreading by haruhiko_yamagata
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060430-mt-rev2539.exe)

Also I did a real test with a multithreaded and a non-multithreaded version on my Athlon XP 3000+ with a regular MPEG4 video.

ffdshow MT
User: 87s, kernel: 0s, total: 87s, real: 95s, fps: 387.2, dfps: 356.4
ffdshow non-MT
User: 90s, kernel: 0s, total: 90s, real: 96s, fps: 374.5, dfps: 350.0

it seems that it also gain a bit of performance with single CPU systems. Repeated this a few times and it always ended up similar.

MatMaul

30th April 2006, 16:46

coool thanks

MatMaul

30th April 2006, 19:51

I have a problem with your multithreaded buids : when I play a video (I don't know if it appears with all my videos, I have test with only 2 videos) and I navigate on the video in MPC, after 5-6 seeking I obtain an error :

http://www.mezimages.com/image/matmaul/miniature/mini_error.PNG (http://www.mezimages.com/agrandir_membre.php?na=matmaul&fi=/error.PNG)

I obtain this error with your 2 last mt buids (fdshow-20060430-mt-rev2539.exe and ffdshow-20060429-mt-rev2538.exe) but I don't have any problems with your last non-mt build (ffdshow-20060429-rev2538.exe)

videomixer9

30th April 2006, 20:25

your cpu type, os and mpc version and evtl. haali version would be interesting. So far I didn't hear from anyone else of problems with the mt patch with single core, so I'm kinda curious and maybe it also has something in common with those ZP crashes haruhiko reported before. I'll build another version without the mt patch. Also interesting would be if the problem also occures with bobors mt builds.

ffdshow rev. 2539

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060430-rev2539.exe)

MatMaul

30th April 2006, 20:31

Pentium M Dothan
Windows XP SP2
MPC 6.4.9.0 FR
I use internal MPC Splitter for the problematics videos (avi files).

I test mt bobor build and I report.

clsid

30th April 2006, 20:32

For those who might want to do some benchmarking on the different builds, Haali's TimeCodec (http://haali.cs.msu.ru/mkv/timeCodec.exe) tool is quite useful. (you also need to install Haali Media Splitter)

MatMaul

30th April 2006, 20:43

same problem with ffdshow-20060423-gcc4.0.3-sse-mt-x264.nl.exe and ffdshow-20060423-gcc4.0.3-sse2-mt-x264.nl.exe
no problem with ffdshow-20060420-gcc4.0.3-sse2-x264.nl.exe

videomixer9

30th April 2006, 20:56

Hm tested with skipping around a bit with gabest avi splitter with the rev604 mpc by celtic_druid and couldn't reproduce the problem. Maybe I try the older "stable" release of MPC. Otherwise this is a myth to me, might be a fault that only occurs on Pentium M or only your specific config, odd how multithreading does this as it's a quite common technique in any software so it must be a specific error with this one ...

MatMaul

30th April 2006, 21:43

My problem isn't reproducible for me too...
It does not appear all the time, I must restart the video 3-4 times and a lot of seek to reproduce the problem.
The problem appears often after a change in the ffdshow configuration when a movie is launched, ever when I seek.

I can't reproduce the problem in ZP and WMP.

videomixer9

30th April 2006, 22:10

Ah ... hm ... I had such problems in the past with anything in MPC, I dunno why it appears but in randomly appears sometimes in MPC and then doesn't. Also I happen to have random crashes with MPC while watching DVDs when I select something in the menu. So it looks like it's actually something with MPC if it's not reproducable with ZP and WMP ... :/

MatMaul

30th April 2006, 22:32

I think the problem is MPC+mt build, because I have no problem with your build ffdshow-20060430-rev2539.exe

videomixer9

30th April 2006, 22:37

well I guess the way the filters are loaded they'll belong to the MPC process and there might be an interference with the threads of MPC itself, or maybe only with the french trans of MPC *hehehe* however as I cannot reproduce the problem I cannot do any further debugging of it so it'll be upto haruhiko, milan or gabest.

MatMaul

30th April 2006, 23:20

same problem with MPC 6.4.9.0 EN and MPC rev604

videomixer9

30th April 2006, 23:53

okay I reproduced an error when I turn on one of the filters in ffdshow I never use usually :p MPC crashed then with the MT build, the other one didn't. Playback or search didn't crash except the usual thing if you manage to search a file to a dozen places within a second it always got overworked, at sane search speed never a problem, so seeking in a file I dunno about.

The problem with the filter occurs on any player though. Seems to be a problem with the mt code though.

To reproduce it e.g. enable Resize & Aspect Filter in ffdshow controls while the video plays, then dechecked it right after you enabled it and it will crash. This is something haruhiko_yamagata has to check up on. Doesn't seem to happen with any video neccessarily so you might have to try several. Also notice some of the settings for this filter section are still applied without the filter being enabled.

Seems like the MT doesn't like size changes of video that much. Nothing wrong with seeking still.

Nothing wrong with seeking still. Besides I wonder why someone would seek around like mad and change ffdshow config all the time. o_O Also does it happen only with special filters enabled or e.g. postprocessor or swscaler on or with anything? I usually don't use any filters as postprocessor is crappy, the rest of the filters for sucky video that i have none of and my graphic card upscale perfectly fine. So I wouldn't have notice any errors with them without any report.

So my current guess is you fiddle around with resize & aspect filters ...

foxyshadis

1st May 2006, 00:52

Ah, this could explain why I experienced seeking problems of my own (audio would play but not video), but no crashes or permanent hangs, while using resize filter. Thanks for testing, I know I'm not insane now!

videomixer9

1st May 2006, 00:57

haruhiko changed the resizing part of libmplayer that ffdshow uses. The other part that was changed is in the .ax file itself. It may be possible that the .ax file still sends a picture to the video renderer in the resolution before it was changed, but propagates another resolution already which gets the player confused and either hang up the video renderer or crash the player. Just a wild guess. However the resizing was one major point for haruhiko (should I use -san or -kun to be not that rude? :p) to do this so this is bit annoying.

However, it doesn't neccessarily happen all the time, plenty of times nothing wrong happens here.

Egh

1st May 2006, 02:36

I havent' been using MT version on a single AthlonXP cpu for much time so far, but I pretty much *always* use ffdshow lanczos resizing and I didn't experience any seeking or crashing problems. I have last CD's build of MPC.

Suggestion: try to play with output options. E.G. I always use forced RGB32 output. Maybe problems are with other settings?

Liisachan

1st May 2006, 06:43

@videomixer9
lol, -kun is a no-no. That'd make you sound his/her boss. If you'd like to add a honorific, -san would be always gender-neutral and safer. OR: haru or haru-chan, like Alex for Alexandra

Seeking like a mad is not practical but could be a good way to find a hidden bug. Enabling/disabling the resizing filter while playing the video is a bit too much, but basically the same thing.

Liisachan

1st May 2006, 06:57

@videomixer9
You changed the filename rev2539-2.exe to rev2539.exe? Could you please try not to change the URL unless really needed? As I sometimes re-post the link to another place...

PS what I said about -kun might be wrong. but I can tell for sure that generally -san is much safer.

multiblitz

1st May 2006, 10:48

Has anyone an explanation why the NON-Milan-builds (comparing for example Milan's 20051129-version with the latest MT-version) need in sum more CPU-Power for the same thing ? As I use a X2 3800 at 2450 mhz, could it be that the AMD-optimization is missing (read somewhere that most people use the Intel-compilers which make INtel-CPUs look better)?

videomixer9

1st May 2006, 12:09

Did you do a real test or just watch taskmanager for a bit, try to test it with timeCodec e.g. Since the last milan build there were I think two changes with libavcodec and both should've improved mpeg4 performance really. Most people btw. don't use Intel compiler, bobor doesn't use it, kurosu doesn't use, clsid didn't use it on his last build, I don't either, only issa did.

Intel Compiler can automatically adjust optimizations and if you don't patch it ICL8/9 have a GenuineIntel check, if that one fails, does on AMD CPUs e.g., then it uses a generic tree that runs on any CPU.

-kun is more a friendly you, while -san is a more distanced you (german I'd make it Du vs. Sie), If he'd be my master I could call him -sama or -dono while -dono sounds more like he's a samurai even though it's still okay to use nowadays, or I could call him -sensei but I'm not his pupil in anything and he's not a doctor either :p (ah the joy of watching anime and japanese drama for too long)

Btw. the resizing problem didn't occur now while testing that much, seems to apply only to certain videos. I didn't find any pattern in those yet though.

Sorry for the re-renaming, but I did that cause I had it linked elsewhere already too where I couldn't edit the link afterwards.

Liisachan

1st May 2006, 12:41

Well, in anime, the background is often young people's school life, in that case what you said is roughly true, altho it depends on many other things--both your age/gender and the age/gender of the person you speak to matter. Believe me, at least in forums or mailing lists in Japanese language, you'd use -san (or sometimes -shi) in a situation like this.

haruhiko_yamagata

1st May 2006, 14:14

So far I didn't hear from anyone else of problems with the mt patch with single core, so I'm kinda curious and maybe it also has something in common with those ZP crashes haruhiko reported before.
Yes, my wishful thinking is that some of the symptoms reported have same cause as you pointed. I can't reproduce seeking problem till now. And I hope that is fixed when I have fixed the bug with Zoom Player. I'm working on Zoom Player though it has not been progressing over the past few days.

However the resizing was one major point for haruhiko
This is just an aside.
Three months ago, when I started to work around ffdshow, I just wanted to see upscaled DVD without frame drops. First I thought multithreading of swscaler would make this come true. I implemented it to see a result just bit better.
Next I checked what was most time consuming and found video renderer was. Though video renderer was out of ffdshow, I guessed calling it on other thread would do multithreading. So I changed ffdshow.ax.
The result was satisfactory, but I needed more than three CPU. Against my will, I had to keep the lid on mt of swscaler. On dual-core system mt of swscaler is not used frequently.
I don't think mt of swscaler is not much buggy. I guess most bugs are related to mt of ffdshow.ax

should I use -san or -kun to be not that rude?
I read good talk of you and Liisachan with :D . Anyway I don't need any honorific. Just call me haruhiko. That sounds nice.

haruhiko_yamagata

1st May 2006, 15:22

I have a problem with your multithreaded buids : when I play a video (I don't know if it appears with all my videos, I have test with only 2 videos) and I navigate on the video in MPC, after 5-6 seeking I obtain an error :

Now I confirmed seek problem with MPC and mt, though it doesn't crash. Video is not updating for seconds after seek. I'll try to debug. Thank you.

foxyshadis

1st May 2006, 19:15

Just curious, but is there any benefit to multithreading other areas of ffdshow, such as decoding or avisynth? I'm sure avisynth could benefit when enabled, it usually makes things slooooow. ;) I guess making every filter a thread would lead to lots of unnecessary memory copies, though.

Glad to have it now, though, it works great 99% of the time. Good luck, debugging threads is pretty tricky.

videomixer9

1st May 2006, 21:25

libavcodec already does multithreaded encoding, also with ffdshow. I think that patching libavcodec for multithreaded decoding would be the easiest. libavcodec has the capabilities as it e.g. can already multithread mpeg1/2 decoding.

Via ffdshow you can also already make libavcodec spawn several threads but it doesn't use them yet for decoding work and I think it's still a bit tricky to do this properly considering you have to interact with all the different frame types to decode. I guess milan will wait for ffmpeg people to implement this, all he has to do then is to set the amount of threads via a libav call like it already does for mpeg1/2, that's a one line patch :O.

dk75

2nd May 2006, 00:00

I've had ZoomPlayer crashed with ffdshow MT bobors mod when used resizing filter. It's always when doing settings in ffdshow while playing or when closing ZP down while playing.
Thought i've never used resizing filter before so i can't compare it to nonMT version of ffdshow.

dk75

2nd May 2006, 00:06

ups! forget to mention that i have AthlonXP only so not a HT or MT capable machine.
But, this MT ffdshow was only newest bobor compilation avilable, so no choice.

zilexa

2nd May 2006, 19:27

zilexa, it doesn't define what hand-optimizations are used; those still go through a cpu-checking process and use whatever you have no matter what build you run. (..)

ok so if I understand correctly, just to be sure, I could even use the Athlon64 build from http://kurosu.free.fr/ffdshow for all Athlon processors (XP and 64) and even Pentium processors (but for Prescott it would lack support for SSE3)?
I made an unattended Windows OEM cd with ffdshow ofcourse, I install it on several PC's with Pentium and AMD cpu's. Thats why I ask..

videomixer9

2nd May 2006, 19:44

SSE3 optimizations were just recently added to ffmpeg and aren't in ffdshow yet, the rest of the code should be also free of any SSE3 optimizations. Only problem that might appear with builds for SSE3 is that by some miracles gcc did some working autovectorizations for SSE3 or replaced calls to SSE units with ones specific to SSE3. I don't remember if SSE3 even had some register call changes compared to SSE2 but iirc SSE3 is merely a plain slight performance upgrade to SSE2.

SSE2 builds would probably crash on regular Athlon/Athlon XP and non-SSE2 Pentium as there are actual changes in SSE2 to SSE and there is actually some code that will automatically assume presence of SSE2 if set at compile time. That's mostly what the specific optimized versions do, they override checks and automatically assume the presence of a certain instruction set. This saves you some comparisions at runtime, but those are really minor though e.g. mplayer team recommends setting optimizations while compiling already either. A problem in the past with this often occured with ffdshow or VLC e.g. in the past, often with liba52 and libdts that had SSE2 switches enabled at compiletime and assumed it's presence.

The only proper autovectorization that makes stuff really require a certain instruction set are the builds done with ICL, however ICL can also do those with a runtime detection enabled if you specify all supported instructions sets at compile time, e.g. /QaxNWPKB. The binaries will be larger but run on any CPU, you can of course favor smaller size and recompile for each processor type.

GCC devs are working on autovectorization, but it is buggy, and I think that kurosu also dropped using it. Checking the notes GCC outputs with -ftree-vectorizer-verbose enabled you can also see that GCC still doesn't even nearly optimize as much as ICL does. For the decoding part all this doesn't matter much anyways, only matters for the performance of some filters (not the colorspace conversions either cause those are in libmplayer and handoptimized too and with runtime cpu detection).

dk75

2nd May 2006, 22:02

whoa... i've had this infamous "can't register ffdshow.ax" error during instalation.
On both videomixer9 GCC 4.1.1 and Paehl GCC 4.1.0 versions.
So, it's time to comeback to bob0r's GCC 4.0.3 - but it's only SVN2524... :(

kurt

2nd May 2006, 22:24

@dk75: did you try it again after a restart? sometimes I get the same error...

videomixer9

2nd May 2006, 22:25

seems people don't want to read, it needs MSVC8 runtime libs!

http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en

If it's not that then I have no idea except for lack of user rights which isn't usually the case as most bakas work as admins all the time. If ffdshow.ax is already used it cannot overwrite it and fails at that stage already. Just try and register it by hand and it'll prolly throw a more useful error message at you.

Egh

3rd May 2006, 05:44

If it's not that then I have no idea except for lack of user rights which isn't usually the case as most bakas work as admins all the time. If ffdshow.ax is already used it cannot overwrite it and fails at that stage already. Just try and register it by hand and it'll prolly throw a more useful error message at you.

If it says "Fail to register" then it's lack of dlls. If the ffdshow.ax is still used (b0rked videoplayer copy in memory e.t.c.) then the message is different (with classical "Abort, Retry, Ignore"). In the latter case kill all remaining videoplayer copies in memory if there're any, and then if still not working, kill explorer.exe :P That usually helps.

haruhiko_yamagata

3rd May 2006, 06:14

I'm almost dead lock in my debug^^; I'm doing this for diversion.

Okay, did some testing with that "super high resolution" Superman trailer (x264). With the previous ffdshow build the video was stutterting extremely. Sometimes no new frame for several seconds. And audio/video was completely out of sync.
I can't explain why, but milan's ffdshow-20051115.exe is best to play Superman trailer on my PC. AFAIK any newer version is not as good as 1115 to see Superman.

Dammit! The superman trailer pwned my computer! It is an Athlon 64 3200+ with a GeForce 6800GT. Where are you guys running this video?

Do you mean you can't see Superman? Some version(s) of MPC fails. I update MPC to see Superman.

videomixer9

3rd May 2006, 08:11

If it says "Fail to register" then it's lack of dlls. If the ffdshow.ax is still used (b0rked videoplayer copy in memory e.t.c.) then the message is different (with classical "Abort, Retry, Ignore"). In the latter case kill all remaining videoplayer copies in memory if there're any, and then if still not working, kill explorer.exe :P That usually helps.

I explained exactly that and then you explain it to me ... very clever. You call it lack of dlls and I specified which dlls aren't present ... duh. I also explained that if the ffdshow.ax is already in use that it will fail overwriting but not registering. Am I that hard to understand? bleh.

issa

3rd May 2006, 08:35

Rev 2539 Build,

Compiler: GCC 4.1.1 only
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/19499233/ffdshow-2539-gcc-sse2-20060603.exe.html) or MegaUpload (http://www.megaupload.com/?d=8YYJAQ42)

Compiler: GCC 4.1.1 only
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/19499670/ffdshow-2539-gcc-sse-20060603.exe.html) or MegaUpload (http://www.megaupload.com/?d=XNT4YYYH)

Compiler: ICC 9.0.30 (msvcr 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19504995/ffdshow-2539-icc-sse-20060503.exe.html) or MegaUpload (http://www.megaupload.com/?d=VMDHTWKL)

Compiler: ICC 9.0.30 (msvcr 8 included) + GCC 4.1.1
CPU Extension: SSE2 (Intel CPU only)
Download: RapidShare (http://rapidshare.de/files/19504656/ffdshow-2539-icc-intel-20060503.exe.html) or MegaUpload (http://www.megaupload.com/?d=JZT2D77K)

videomixer9

3rd May 2006, 14:02

I wonder when Intel will finally release ICL 9.1 (which was announced for end of april) as the current one doesn't integrate into MSVC 2005 and milan changed all the makefiles to 64bit compilation for ICL already and you have to clean that out. And newest Platform SDK doesn't work too well with it either.

Btw. that Superman trailer runs better on current ffdshow here, the h264 part was a bit improved since then ... however still to slow so I stick to CoreAVC for h264.

breez

3rd May 2006, 15:47

Rev 2539 Build,
Compiler: ICC 9.0.30 (msvcr 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19504995/ffdshow-2539-icc-sse-20060503.exe.html) or MegaUpload (http://www.megaupload.com/?d=VMDHTWKL)

Any ideas how to get this build working? I get 'exception occured while trying to run "ffdshow.ax,configure"' message when trying to open config dialog (it installed fine).

This http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en is installed. Windows XP SP2. Athlon XP.

dillee1

3rd May 2006, 22:12

Tested videomixer9's mt-rev2539 with some hdtv mpeg2 and mpeg4 clip on a dual p3 1G.
Graphedit never reports more than 54% CPU usage. No difference in compare with single threaded builds. Btw vlc use ~95% CPU when playing those clips.

videomixer9

3rd May 2006, 22:21

set the number of threads to two in the ffdshow configuration, actually mpeg2 decoding is multithreaded since ages.

dk75

3rd May 2006, 23:03

@dk75: did you try it again after a restart? sometimes I get the same error...
Yes, feew times. It's always refused to install. After one of this i've instantly installed bob0r 2523 GCC4.0.3 version without problems.

haruhiko_yamagata

4th May 2006, 03:01

Btw. that Superman trailer runs better on current ffdshow here, the h264 part was a bit improved since then ... however still to slow so I stick to CoreAVC for h264.

Ok, current ffdshow runs better on faster machines. On my P4HT/G450, 1115 is better. I've tested current version on Athlon 64 x2 4400+, it's OK.
I know milan is working very hard on h264, I didn't like to say that. and in practice P4HT/G450 is too slow to enjoy HD movie whatever the version is. But I'm just curious about the strange CPU usage curve. It appears after 1115.

haruhiko_yamagata

4th May 2006, 03:57

bug fix: Crash on default setting of Zoom Player, old
renderer of MPC, etc.

Certain video renderer cannot run on child thread. It
includes the default renderer of Windows 2000 or older,
the default of Zoom Player(Overlay Mixer, Standard
Renderer), "Old Renderer" of MPC, etc. In this case,
multithreading around video renderer is avoided and Resize
is processed on multithread.

knouwn bug: Seek problem is not fixed yet. Mainly on DX50?
It sometimes crashes after seek.

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

videomixer9

4th May 2006, 08:32

Ok, current ffdshow runs better on faster machines. On my P4HT/G450, 1115 is better. I've tested current version on Athlon 64 x2 4400+, it's OK.
I know milan is working very hard on h264, I didn't like to say that. and in practice P4HT/G450 is too slow to enjoy HD movie whatever the version is. But I'm just curious about the strange CPU usage curve. It appears after 1115.

milan doesn't work at all on h264 as milan isn't affiliated with ffmpeg project afaik. decoders are just taken from the ffmpeg project, that's why multithreading in ffdshow itself may even be the wrong attempt, as I said before libavcodec is already prepared for multithreading as e.g. it can do so for mpeg1/2 already since quite some time, MPEG4 and others are missing but libavcodec has interfaces to set amount of threads. On the encoding part MPEG4/h264 should also have multithreading support already though. The strange behaviours are prolly cause of changes to framedropping so the audio/video sync isn't lost.

The video renderer is just something ffdshow connects to and which must be multithreaded by MS, to take off load for HD playback it's needed to multithread the decoding process itself, which is a bit more complicated, but is doable as CoreAVC/Ateme and other decoders show.

Also consider the video memory needed and acceleration features, a G450 might have problems keeping up to the rest of your PC and HD video renderers, and if you're trying with VMR9 it's hopeless anyways on that card I'd say.

haruhiko_yamagata

4th May 2006, 10:38

decoders are just taken from the ffmpeg project, that's why multithreading in ffdshow itself may even be the wrong attempt, as I said before libavcodec is already prepared for multithreading as e.g. it can do so for mpeg1/2 already since quite some time, MPEG4 and others are missing but libavcodec has interfaces to set amount of threads.
Yes, my way of multithreading conflicts multithreading of decoders on dual core CPU. So let's hope we'll have multi-core CPU. I should add dialog for setting. Then user can select which way of multithreading.

The video renderer is just something ffdshow connects to and which must be multithreaded by MS, to take off load for HD playback it's needed to multithread the decoding process itself, which is a bit more complicated, but is doable as CoreAVC/Ateme and other decoders show.

I mentioned the Superman trailer, but my main purpose is to see upscaled DVD. In this setting decoding DVD doesn't take CPU time long.
The video renderer depends much on video card, so I doubt if multithreading of video renderer would be effective.
There are many scenarios. Heavy decoder+light renderer, the opposite, etc. Best way of multithreading differ case by case.

Also consider the video memory needed and acceleration features, a G450 might have problems keeping up to the rest of your PC and HD video renderers, and if you're trying with VMR9 it's hopeless anyways on that card I'd say.

G450 is for developing environment. I see movie with Athlon 64 x2 4400+/Radeon 9600XT. 9600XT is a bit out of date, so it needs help of multithreading. No frame drop with Superman trailer.

videomixer9

4th May 2006, 12:57

And I'll keep wondering why people are so hot for software resizers when their video hardware has inbuilt resizing that works pretty well most of the time while preserving most details.

The problem with multithreading just a specific filter is that the filter has to wait for the decoder to do it's work, and then kick in when decoding is already done. Problem with this is that your workload is spread unequally if you just throw random work at some threads and reuse them immediatly after they are done with their work, there is a real high chance then that only one thread is doing most of the work, as the video decoder is decoding for realtime playback and doesn't deliver content as fast as the filter could do it's work. Without specific CPU selection it can now happen that the free other core we have doesn't get much of the work as the threads are more probable to land on the processing list for the first core again, as the decoder won't start with the next frame before the filter is done. Of course this also has to do with the OS handling it.

From my peeks at your code it seems that just a random thread is generated and executed on a CPU the OS decides it should use. It should be like that you create a worker thread per CPU that you assign to a specific core and then spread the work that should be done to those worker threads equally, or even better by checking the status of those threads and assign the one on the lesser used core to more work.

This doesn't solve the issue that you still only get video data from an upstream that gives you only frame per frame as it's supposed to be outputted to a video renderer, to be more effective you'd need to get the decoder to do work ahead of time and still keep audio sync. You could then resize a few frames ahead and spread the workload more effective.

As ffdshow is currently, I think that it waits with decoding the next frame till the one before actually wandered all the way to the videorenderer. The frame gets decoded, after that the CPU is all free for filtering, then the next frame is decoder and filtered and so on. As you see there is a timegap the decoder could already decode a new frame while resizing is done and another thread could resize the this frame already just to throw it at the videorenderer right after the one before.

Problem is, decoder and filters need to properly sync on this work.

As for dillee1, VLC should have multithreaded decoding hacked around the codecs, so this should explain why MT is effective while these multithread patches by haruhiko are just really interesting for resize filter users.

btw. added 2541 compile that has Aud-X support, dunno if anybody really uses that, forgot to add the dll to the installer, maybe next time ...

milan official added the patch by haruhiko, new build coming soon.

haruhiko_yamagata

4th May 2006, 16:43

Well, it's ideal, but too difficult for me. To make things compact so that I can be responsible for it is important, I think.

videomixer9

4th May 2006, 16:43

ffdshow rev. 2544

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad, runtime cpu detection
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060504-rev2544.exe)

Multithreading patch by Haruhiko Yamagata is now officially part of ffdshow. Also new is Aud-X support, audxlib.dll comes with installer, get sure to read the license here (http://bittekeinspam.googlepages.com/AudX_licence.pdf).

issa

4th May 2006, 16:48

Any ideas how to get this build working? I get 'exception occured while trying to run "ffdshow.ax,configure"' message when trying to open config dialog (it installed fine).

This http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en is installed. Windows XP SP2. Athlon XP.

I try it on my notebook, it didn't crash... I will recheck the build and upload the build again.

clsid

4th May 2006, 17:57

I get a crash whenever I try to change the resizing settings during playback :(
If I pause first, then the crash will occur immediately after playback is resumed.
It happens 9/10 times.

(rev 2544)

videomixer9

4th May 2006, 18:05

oddly that's what happened for me earlier too, however it suddenly just disappeared as a problem. All I remember doing inbetween was uninstalling ffdshow and reset settings to default ... not that it sounds like that's related.

LoRd_MuldeR

4th May 2006, 20:42

Here it *sometimes* crashes when I switch from "Specify aspect ratio" to "Specify size" during playback. MPC just closes without error message. Keeping at "Specify size" and typing in different sizes, it will work okay and no problem at all. (Latest Videomixer build).

dillee1

4th May 2006, 22:19

Tried 2 thread setting with mpeg2 clip. CPU usage goes to ~60% (1 thread = 54%). More threads don't further increase CPU usage. mpeg4 doesn't seems to be affected by MT at all.

"VLC should have multithreaded decoding hacked around the codecs, so this should explain why MT is effective"

vlc doesn't use directshow at all, so it is not restricted by frame-per-frame architecture in directshow. It might schedule a whole gop to each worker thread if it wish. It's can communicate internally to sync A/V as well.

"while these multithread patches by haruhiko are just really interesting for resize filter users."
10% speedup is better than nothing:-)

clsid

4th May 2006, 23:54

resize crashes are been fixed in latest revision

haruhiko_yamagata

5th May 2006, 02:59

resize crashes are been fixed in latest revision
Not only comminting the patch, he added dialog for setting and fixed my bug. Thank you, milan!

foxyshadis

5th May 2006, 04:31

issa

5th May 2006, 04:57

Rev. 2545 build,

Compiler ICC 9.0.30 (msvcrt 8 included) + GCC 4.1.1
CPU extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19652727/ffdshow-2545-icc-sse-20060505.exe.html) or MegaUpload (http://www.megaupload.com/?d=5537E1BA)

How many people still want to try pure GCC 4.1.1 build?

videomixer9

5th May 2006, 08:31

So basically ffdshow needs to be re-engineered to do multithreading all the way through, presumably by pre-buffering several frames of audio or video data (which can decide how to best parallelize that part), decoupling the filtering engine from the decoding engine and feeding into a worker thread per core like vm9 says, then having a pool at the renderer that ensures frame order and timing are correct. Shouldn't be too hard... for server engineers. ;) I wish I knew more about implementing threading, I'd love to work on it. I'm curious how much of that structure is already done.

Until then, having portions of it multithreaded is still better than nothing, though.

ffmpeg will add MPEG4 and other multithreaded for sure. Then ffdshow can just set an amount of threads to be used for decoding and libavcodec will do effective video decoding multithreading. ffdshow's filtering is another case, but most filters aren't that cpu heavy anyways, and for some the original devs will prolly also do something about it.

foxyshadis

5th May 2006, 09:03

I'm beginning to think people are intentionally agitating videomixer.... You could just read the last page.

http://forum.doom9.org/showthread.php?p=822612#post822612

MatMaul

5th May 2006, 13:14

Same problem (crash of MPC after seeking) with rev 2544.
I stay on rev 2539.

videomixer9

5th May 2006, 13:52

there is this nifty insurgent thing on the CCCP website, maybe try that and post the results of the log somewhere. If that problem is persistent than it may have to do with something else on your system that conflicts with MPC and ffdshow ...

http://www.cccp-project.net/downloadi.php

you can post result on nopaste.info or similar for better overview.

ffdshow rev. 2546

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad, runtime cpu detection
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060509-rev2546.exe)

changes: edge emulation for deBand - works only when processing full frame

MatMaul

5th May 2006, 14:21

I don't think it's a filter problem because when I render the file with mpc the filter chain seems to be normal :
AVI MPC source -> ffdshow MPEG4 decoder -> video renderer

log file of CCCP (http://www.nopaste.info/index.php)

MatMaul

5th May 2006, 14:28

The uninstaller doesn't remove audxlib.def and audxlib.dll.

asasadad_1

5th May 2006, 14:31

lpcm decoding crashes in ffdshow rev. 2546(by videomixer9)

videomixer9

5th May 2006, 14:34

hehe is there any directshow filter available you didn't install? :O Well if the filters used are really only those. There are some evil things in that list but they usually don't interfere with avi playback. Btw. are those crashes really produced by video rendering? Try to disable sound output and seek around, dunno which audio filters you use but they may also be the culprit.

did lpcm still work in 2545, if yes then I wonder how it got broken ... need to check that but don't have any lpcm ... guess I try search the forum for some sample.

Ah dammit forget to add the delete command in the uninstall section, thx MatMaul. reuploaded the version with hopefully fixed uninstalling.

MatMaul

5th May 2006, 14:39

if it's an audio problem, ffdshow is also the problem because it decode the audio of those files with ffdshow :p
I have removed the audio of a file and same problem......
I think it's a problem of the couple ffdshow mt patch-MPC...

EDIT : same crash with last rev of mpc (rev609 compiled by CelticDruid)

asasadad_1

5th May 2006, 14:44

hehe is there any directshow filter available you didn't install? :O Well if the filters used are really only those. There are some evil things in that list but they usually don't interfere with avi playback. Btw. are those crashes really produced by video rendering? Try to disable sound output and seek around, dunno which audio filters you use but they may also be the culprit.

did lpcm still work in 2545, if yes then I wonder how it got broken ... need to check that but don't have any lpcm ... guess I try search the forum for some sample.

Ah dammit forget to add the delete command in the uninstall section, thx MatMaul
here is a sample:http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/lpcm.vob

LoRd_MuldeR

5th May 2006, 14:46

here is a sample:http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/lpcm.vob

I can reproduce the problem with that sample. If I enaable LPCM support in ffdshow I get only noise. Otherwise it's fine...

videomixer9

5th May 2006, 14:48

hm I tried an example from here:
http://forum.doom9.org/showthread.php?p=603581#post603581

and it works fine. o_O that mplayer sample I only get noise too.

MatMaul

5th May 2006, 14:49

anyone have a pentium M dothan and can try to reproduce my bug ?

asasadad_1

5th May 2006, 14:58

hm I tried an example from here:
http://forum.doom9.org/showthread.php?p=603581#post603581

and it works fine. o_O that mplayer sample I only get noise too.
that mplayer sample is ok via ffdshow-rv2526 by you:)

videomixer9

5th May 2006, 15:14

lpcm doesn't work with issa build either here, though it either constantly peeps or you hear nothing, there were several changes since that revision on the file decoding lpcm. milan might have broke it unintentionally. From looking a bit around ... could it be 64bit CPU users don't have this problem? are you guys using 64bit CPUs, I'm not. Just an idea I got from the code changes ...

Other than that, it first appears as a problem in rev2544 for me ... I didn't do 42 and 43 builds. Inbetween there was some quicktime audio stuff added that changed some audio decoding stuff, I guess I'll try and revert those files affect in that patch and try if the error still occurs.

May also be related to floating point code generation ...

edit: the sample is 24bit lpcm? older builds says so, newest one only detects standard lpcm and may thus decode it as 16bit resulting in the noise. I hardcoded the 24bit part and then it works ... but that's not a real solution hehe.

sleepking

6th May 2006, 01:29

Same problem (crash of MPC after seeking) with rev 2544.
I stay on rev 2539.

The same problem,and ffdshow audio decoder-->codercs-->uncomperessed "all supported" don't work on my computer.

issa

6th May 2006, 09:08

Rev. 2546 build,

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

Temporary fix LPCM problem by assume 16bit PCM when fail to detect the stream type.

max-holz

6th May 2006, 15:55

videomixer9

6th May 2006, 16:19

the binaries automatically select the available SIMDs and use the one according to your CPUs capabilities. Code is generated for both SSE and SSE2 with ICL and embedded into the same binary. So the link to SSE and SSE2 version is the same ...

MatMaul

6th May 2006, 19:41

@ videomixer9 :I see on your website :
applied patches : runtime cpu detection, advanced gcc optimizations makefile patch
what are these patch ?
Can you publish them please ?
I actually try to make my own build and I'm interested by these patchs.
thanks !

Adub

6th May 2006, 21:23

Videomixer, are you going to make some builds with sse2 optimizations? That would be great man!

videomixer9

6th May 2006, 21:52

just use the build from issa, I won't do SSE2 builds.

issa

7th May 2006, 06:04

Rev 2546 Build version 2,

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

Temporary try to fix LPCM problem by using the old detecting code when new code fail to detect the stream. I think milan still working on the new detecting code.

haruhiko_yamagata

7th May 2006, 07:30

I apologize for lacking consideration for ffmpeg project/libavcodec.
Please forget the prior version of document and words about Superman trailer.
I am really sorry for it.

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

MatMaul

7th May 2006, 23:43

_xxl

8th May 2006, 15:18

ffdshow-20060508-2546.exe Intel 9.0.30
http://rapidshare.de/files/19931630/ffdshow-20060508-2546.exe.html

Liisachan

8th May 2006, 16:11

ffdshow-rev2546-SSE2.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2546-SSE2.exe)

3826010 Bytes
2006-05-08 13:14:20 UTC

celtic_druid

8th May 2006, 16:14

Not 100% rev2546. I added the multichannel vorbis patch from ffmpeg so 5.1 vorbis should sound fine now when decoded by libavcodec. Tested ok here.

Liisachan

8th May 2006, 16:22

Wow, I'll test it now.

EDIT
YES! That problem has been fixed in this new build.
In case someone needs a sample to test: xvid+6ch_vorbis.ogm (http://ffdshow.faireal.net/tmp/xvid+6ch_vorbis.ogm)

I was wondering why you made yet another one when there are already many builds lately, but now I know the reason. You're aggressively creative, which i'm really appreciating.

videomixer9

8th May 2006, 19:36

Hm, I also applied the patch and updated my latest build to use it. I usually don't check ffmpeg mailing lists so I missed it ...

asasadad_1

8th May 2006, 20:12

issa

9th May 2006, 03:38

some lpcm decoding seems didn't work in ffdshow-rev2546-SSE2(by celtic_druid ).
here (http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/Fever.vob) is a sample.
ffdshow-svn2523-20060420(by clsid) is ok.

I think the lpcm detect code in svn had not finished yet, if you need lpcm decoding, try my build on http://forum.doom9.org/showthread.php?p=824440#post824440.

_xxl

9th May 2006, 13:00

http://rapidshare.de/files/20008336/ffdshow-20060509-2546.exe.html
http://rapidshare.de/files/20034853/gcc.jpg.html
http://rapidshare.de/files/20034897/icl.jpg.html

Lemonzest

9th May 2006, 23:24

using videomixer9's builds, latest one and wma2 has stopped working, it is recognised but just muted/no sound have to disable libavcodec in the options and let windows decode it. i made a new test file and its the same.

videomixer9

10th May 2006, 00:08

works fine for me with a sample I got off mplayer ftp as I don't have such trash on my hd anymore :p there are some aggresive gcc optimizations enabled that may break stuff randomly, I usually test them only for aac/ac3/dts sound though as those are the usual things that break with them.

Lemonzest

10th May 2006, 01:39

i just did a quick encode with wma2 audio, and have to disable "WMA 8/9" Audio in the codec part of the audio decoder, for it to play, windows explorer says the audio is "Windows Media Audio 2" and in the info panel of the audio decoder it says "libavcodec wmav2" just no sound :(

http://lemonzest.tastyspleen.net/Temp.avi

Kostarum Rex Persia

10th May 2006, 02:36

Can someone tell me why build 2546 doesn't support fourCC IV50( Indeo 5.11 codec).

I can't play Indeo 5.11 files at all, can someone make a patch for decoding this stuff?

foxyshadis

10th May 2006, 03:56

I've never seen IV50 or IV40/41 in ffdshow, you've always had to go to ligos's website to get the codecs. As the decoders aren't present in lavc at all, it would take a lot more than a quick patch to get it in.

http://www.free-codecs.com/download/Intel_Codec_Installer.htm

Lemonzest

10th May 2006, 19:07

videomixer9, just got your new build and no idea what you did but wma v2 now plays fine :D Thanks.

3dsnar

11th May 2006, 18:26

I have posted this request through sourceforge,
but I would like to know what other users think about such approach
(I think this is the least confusing and possibly the most stable apprach)

-------------------------------------------------------------
Currently Aud-X MP3 5.1 is available as one of the mp3 decoding libraries.

My request is:

1) Please, add new format: Aud-X MP3 5.1 to the format list.
The user will be able to chose audxlib or disable the format.

---- If Aud-X MP3 5.1 is selected:
audxlib.dll would be used ONLY for Aud-X streams.
For regular MP3 streams other mp3 decoder would be used (selected with the MP3 format drop list)

---- if not selected, audxlib.dll would not be used.

2) Please add description to "info & debug"
about the mp3 5.1 stream (if it is such).

-------------------------------------------------------------

Please share your thoughts within this forum,
but also here:
http://sourceforge.net/tracker/index...61&atid=471492

videomixer9

11th May 2006, 19:21

ffdshow rev. 2546 ICL9.1

minimum requirement: SSE
compilers: GCC 4.1.1 + ICL 9.1.022
specials: high accuracy tremor, high accuracy libmad, runtime cpu detection, libavcodec 6ch vorbis fix
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060511-rev2546-icl91.exe)

I thought it was time to try and get things on ICL maybe, test it and find out if it works better for you. It uses autovectorization and auto-parallelization (automatic optimization for dualcore). Raw decoding performance shouldn't be very much better as libavcodec is still gcc compiled, but some filters built into ffdshow.ax should work better. Compile time for this is very long so I don't know if I do any built with ICL 9.1 from now on. I prolly release another built with some other settings later.

celtic_druid

11th May 2006, 20:03

Parts of libavcodec can be built with ICL9 to. Yeah, compiling ffdshow with ICL does take ages.

videomixer9

11th May 2006, 20:23

libavcodec ICL 9.1 fails on missing links for some things that I'm trying to figure out to get it compiled with it, interesting is the auto-parallelization part. Seems to have something to do with dsputil ...

LoRd_MuldeR

11th May 2006, 20:35

Are ICL builds okay for AMD CPU's too or is it recommended to use GCC builds on my AthlonXP ???
Will do some testing myself too...

videomixer9

11th May 2006, 20:51

From my expierence upto now ICL isn't really usefull for main ffdshow part. I had better results making up performance by using more optimization for libavcodec on gcc. Also mostly totally stupid stuff is autovectorized or parallelized, e.g. dolby decoder or mixer.

Would be nice to have timecodec results, for me the icl build is not a bit better for just decoding, must be cause all needed operations are optimized anyways, and the rest of the code not being that bad. Considering ICL needs almost a half hour and MSVC 2005 only like 2-3 mins ... not even talking about stuff like kerneldeint which throws out of memory after a while here ...

And yes better not use it on AMD the libs aren't patched and I think it still is nazi against AMD, but rather than applying a patch I think I'd stick to MSVC compiler as it performs well enough that way. If it'd patch any libs I'd also only patch them now to check for AuthenticAMD so Intel people may cry, got sick of that company.

LoRd_MuldeR

12th May 2006, 01:09

I've just noticed that there's a big difference between RGB and YUV output. With YUV output (ffdshow default setting) it looks "mealy". If I uncheck YUV modes and force RGB output, the colors look *much* better. So it's a great improvement for image quality. Any explanation why it's that way?

Sample: YUV (http://mulder.dummwiedeutsch.de/etc/mpc_yuv.png) <-> RGB (http://mulder.dummwiedeutsch.de/etc/mpc_rgb.png)

Isochroma

12th May 2006, 02:32

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

12th May 2006, 02:50

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

12th May 2006, 03:05

@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

12th May 2006, 03:26

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

12th May 2006, 08:14

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

12th May 2006, 11:25

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

12th May 2006, 11:43

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

CoRoNe

12th May 2006, 11:58

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

12th May 2006, 13:14

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

12th May 2006, 14:30

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

12th May 2006, 14:43

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

Liisachan

12th May 2006, 14:43

MatMaul

12th May 2006, 15:14

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

12th May 2006, 15:16

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

12th May 2006, 15:17

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

12th May 2006, 18:40

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

12th May 2006, 18:50

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

Egh

12th May 2006, 18:58

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

12th May 2006, 19:47

@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

12th May 2006, 20:11

@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

12th May 2006, 23:21

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

13th May 2006, 03:44

To 2546 bug fix. Seek problem.

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

flanger216

13th May 2006, 05:40

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

13th May 2006, 07:24

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

13th May 2006, 08:25

...

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

13th May 2006, 11:31

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

13th May 2006, 12:03

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

13th May 2006, 12:08

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

13th May 2006, 13:19

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

13th May 2006, 18:30

@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

13th May 2006, 18:58

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

13th May 2006, 19:19

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

13th May 2006, 19:34

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

13th May 2006, 19:44

bob0r

13th May 2006, 19:57

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

13th May 2006, 20:12

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

13th May 2006, 20:33

clsid

13th May 2006, 20:34

videomixer9

13th May 2006, 20:38

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

13th May 2006, 21:31

@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

13th May 2006, 21:44

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

14th May 2006, 04:08

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

14th May 2006, 04:26

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

Skelsgard

14th May 2006, 04:28

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

flanger216

14th May 2006, 06:11

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

14th May 2006, 06:42

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

14th May 2006, 08:33

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

14th May 2006, 09:35

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

14th May 2006, 10:27