New ffdshow build (?)

[LoRd_MuldeR]

Same like the last build's from kurosu :-(

best regards

akapuma

Well, I can use MPC's internal audio normalizer. But I hope the problem can be found & fixed anyway...

[haruhiko_yamagata]

Hello, Liisachan. Thank you very much for the mirror.

The Auido-Normalizer doesn't work in that build
Thank you for report. I'll investigate.

[Jorgosch]

I think, that the audio normalizing function of the new ffdshow-builds from http://kurosu.free.fr/ffdshow.htm is broken.


I can partially confirm that. Normalisation doesn't work for AC3 sound but DOES work for mp3 source.

[akapuma]

I can partially confirm that. Normalisation doesn't work for AC3 sound but DOES work for mp3 source.I have movies with x264 and vorbis in a mkv-container. Normalization don't works with this files.

Best regards

akapuma

[Liisachan]

it's kinda finicky... the new one is fast on Win2k but not that impressive on winxp, exactly the same settings, the same physical machine, different os...
vmr9mixer mode+YUV mixing that works best for me on Win2k doesn't work well on WinXP either (the color space is werid)...

[Egh]

I can partially confirm that. Normalisation doesn't work for AC3 sound but DOES work for mp3 source.


You can output result to AC3Filter and do normalisation there.

[Egh]

Resize setting - automatic vertical size setting
Specify horizontal size and enter 0 as vertical size for Automatic aspect ratio. I don't think the user interface is a good idea. What should it be like?
I'm trying to support the "non-square pixcel", but it depends on video renderer's behavior.



so have you added that patch in your build? Atm entering 0 vertical value in the vertical resolution editbox causes MPC to crash :)

[haruhiko_yamagata]

it's kinda finicky... the new one is fast on Win2k but not that impressive on winxp, exactly the same settings, the same physical machine, different os...
As for build, I'm a beginer. Videomixer9 and people around here are very familiar with compiler and it's options. I build for distribution because they all seem to be holiday.
vmr9mixer mode+YUV mixing that works best for me on Win2k doesn't work well on WinXP either (the color space is werid)...
Is it the build specific problem? I modified swscaler this time, it may be related...

[haruhiko_yamagata]

so have you added that patch in your build? Atm entering 0 vertical value in the vertical resolution editbox causes MPC to crash :)
Yes.
It is not reproducible here. What the settings(video renderer(includeing mode), color space, video card etc) are?
Is usual resize working? Can you change(not to 0) setting while playing?

[Egh]

Yes.
It is not reproducible here. What the settings(video renderer(includeing mode), color space, video card etc) are?
Is usual resize working? Can you change(not to 0) setting while playing?

LOL :P just checked -- it's fully b0rked :) I.E. resize itself crashes. It doesnt' crash only if target resolution is same as video (i.e. then no actual resizing occur).

It crashes always after checking resizing check box and playing the video afterwards. (e.g. when i pause the video, tick the box and start the video again)

For instance:

sauce: 640*480, SAR 1/1, DAR 4/3
In ffdshow resize section settings as follows:
No aspect ratio correction, Specify Size 1024 768; Resize Always.

Those setting work with last VM's build but fail if your build is installed. If I reinstall VM's build all is working as usual again.

My CPU is SSE1 only, if that matters, btw.

MPC settings: do not matter whatsoever. Crashes on VMR9 (no mixer mode) with any of three modes (plain, 2D & 3D). Crashes on Overlay Mixer as well. Crashes with YV12 colorspace and with forced RGB32.

EDIT: thru Remote Desktop I just tried new ffdshow on a PC which has even SSE3. Still same stuff. Besides, that PC has D.E.P. enabled for all programs, and D.E.P. exception was raised first before general message about MPC crash :P

[haruhiko_yamagata]

Hello, Egh.

Well, I think I build for SSE1 only, but I'm not familiar with build settings. Or is it the source?

Please try "replase libmplayer.dll with the last videomixer9's".

[Egh]

Hello, Egh.

Well, I think I build for SSE1 only, but I'm not familiar with build settings. Or is it the source?

Please try "replase libmplayer.dll with the last videomixer9's".

Nah, still same stuff. Even with both libmplayer & libavcodec taken from last VM9's build.

As for SSEx it doesn't seem to be a problem, as I already said in the edit text in my last message :) D.E.P. seems to be an answer :) So you might not have a crash due to different build of MPC or something else. But the problem is here...

[videomixer9]

wow damn homepage was deleted, uploaded it elsewhere again, use the link in the sig. was just away for some days and it's like that, typical.

[LoRd_MuldeR]

wow damn homepage was deleted, uploaded it elsewhere again, use the link in the sig. was just away for some days and it's like that, typical.

Now that you are back, can you make a build with latest patch by haruhiko_yamagata, so we can see what's the matter with the audio-normalizer ???

[videomixer9]

I'm on it currently, had to redo from scratch my sourcetree didn't like that latest patch so it takes a while :P

And to all the japanese paranoids out there that trust their fucked up antivirus programs more than me, there is no virus anywhere in my builds and ICL9 just generates larger code, that's all. I wonder where all these noob theories come from. I take the recent wave of antivirus programs detecting open source installers and programs as trojans as an attack vs. open source software and recommend you to get evtl. money you paid for those programs back.

Btw. new build is up ... here (http://ffdshow.pyrokar.lima-city.de/current.php).

[LoRd_MuldeR]

Btw. new build is up ... here (http://ffdshow.pyrokar.lima-city.de/current.php).

That build seems to work fine :) What about an SSE version ???

[videomixer9]

maybe later, only interesting for filter uses of filters that are embedded into the ax file or other libs than libmplayer.

[Egh]

That build seems to work fine :) What about an SSE version ???

What is more, it doesn't crash on rezise :P

Though i think the CPU usage for resizer somewhat increased.

Another thing for the patch is that it works ok in VMR9 mode, but in Overlay Mixer it doesn't actually resize :) Not that I care since I don't use OM...

[videomixer9]

With Overlay Mixer you need to reopen the video to make resizing take effect, it only works on the fly with VMR modes.

[akapuma]

No problems with normalizing. Thank you, videomixer9.

Best regards

akapuma

[Yama4050242]

@videomixer9
your build ffdshow-20060709-rev2546
can not play my old x264 encodes
sample here
http://www.megaupload.com/?d=AZRHIBZV

[videomixer9]

that shit file again ... it only doesn't work with the gcc 4.1.1 sse build though and works with the other, dunno which craptastic art it is that makes your shit borked on sse all the time. Prolly SSE doesn't like chinese. Might be libfaad though too. Other than that it produces overflows on memory reservation, wonder if this video isn't just made to make things crash ... at least when ICL9 comes into play, I remember this video crashing before with the same settings.

Stick to the nosse version for now, it uses optimizations too but it doesn't have important things like the checkboxes use SSE :O Yes, these are the thing that get SSE optimized by the compiler ... that so doesn't help with anything. Even with GCC things, if you define -msse it will get undefined in the code anyways again.

[haruhiko_yamagata]

Hello, videomixer9. Your build is great. I should have waited.

[videomixer9]

I think the problem is still the pure GCC try, it just doesn't work correctly, especially on the parts of MS headers etc. being involved. As for me, special SSE builds are no more, next versions will be ICL+GCC 3.4.5 without any of the SSE things in ICL enabled. Too many problems with ICLs extra switches, and /arch:SSE is a pure useless switch. GCC 4.1.1 seems broken and seems to be the culprit for broken old files by Yama ...

[thuan]

The file from yama above and shon3i still crash with your newest build with nosse. I don't think it because gcc4.1.1 sse because it works with haru build, clsid build, vm9's older builds with msvc ffdshow.ax and the crash reported it is a crash in ffdshow.ax module. I think icl ffdshow.ax is the problem whether sse or not. My CPU is SSE only.

[videomixer9]

Oh well dunno where it overflows but I did a mix build now with ICL91 for anything but the .ax, the ax as msvc 2005 and gcc 3.4.5 for the rest.

[thuan]

Works perfectly now, thanks vm9. This problem seems to cause by a revision of x264, actually watch a lot of anime but haven't stumb upon any file like this beside here.

PS. Haruhi ends so fast before I know it damn.

[LoRd_MuldeR]

ffdshow-20060710-rev2546.exe breaks KernelDeinterlacer :(

[videomixer9]

just replace it with an old one, nothing changed and in which way it is broken, I tested it and it worked. There's nothing different in that compile than in every other one.

edit: okay i got something that is actually broken with it, I'll just replace this version quietly with a new one. ICL culprit again.

So ...

ffdshow.ax: doesn't like any optimizations of ICL for certain files (/O2 /O3 /Ox all breaking certain x264 files)
kernelDeint: doesn't like high level optimizations and compiles ages when not using link time code generation (/O3 breaks code, /Ox is fine, use /LTCG)
libfaad: floating point improvement breaks the sound (don't use /Op, /O3 and /LTCG okay though)
TomsMoComp: works fine but get stuck in optimization loop when not using link time code generation (/O3, use /LTCG o.k.)
FLT_ffdshow, ffvdub, makeAVIS, ffavisynth, ffwmv9, ffunrar, ffvfw, ff_acm: currently all using /O1 or with /LTCG, so far no reports of broken code
liba52, libdts, realaac, libmad, tremor, libmpeg2, theora: all doing fine with /O3 and /LTCG so far
auto parallelisation generally breaks things on intel cpus sadly (don't use /Qparallel)

btw. the build is updated with a fixed kerneldeint.

[LoRd_MuldeR]

Thank you once again!

[videomixer9]

btw. I tried kurosu's latest ffdshow for athlon xp with the posted x264 sample and it crashes too here O_o Also recommended for everyone trying to avoid being detected as virus try updating to nsis 2.18. nsis 2.16 gets your download detected as virus immediatly while downloading.

Also hey, I broke it so I have to repair it :P Now I should really keep those settings saved somewhere properly and stop fiddling.

[Egh]

@ haruhiko_yamagata:

lol, it seems that your patch sometimes is broken.

I have one sauce which is 1280*1080 (yes, HD anamorphic:P) and if I enter 1024,0 in the resizer it actually resizes too much in the vertical resolution, making less than 576 (DAR is 16:9).

It works with dvd anamorphic, like 720*480.

[Liisachan]

As for build, I'm a beginer. Videomixer9 and people around here are very familiar with compiler and it's options. I build for distribution because they all seem to be holiday. Oh, don't be so modest :)

Is it the build specific problem? I modified swscaler this time, it may be related... Nah, I didn't notice that until recently, as I didn't ususally use xp. It's not your build's pb, just general... perhaps my hw-specific.

for me things are like these.
RGB32 Output on VMR9Renderless + VMR9Mixer + YUV mode =
- Cool and very fast on Win2K
- Color Space is wrong and not very fast win xp
RGB32 Output on Overlay
- Not really fast on Win2k
- Very fast on Winxp

And what I meant by 'finicky' is, it's working amazingly depending on a minor detail configuration. NOT that it's all bad but I figured it would still need some tinkering... Keep up your great job!

[videomixer9]

isn't RGB32 output a bit stupid in VMR9 YUV Mixing mode, I mean it's meant for YUV input so it converts back to YUV or rather just ask upstream filters to output YUV or fails.

Overlay doesn't accept RGB32 input for me, MPC will also automatically fall back to VMR7 then. I guess on 2k it falls back to GDI or something which is slowass compared to VMR7.

[LoRd_MuldeR]

isn't RGB32 output a bit stupid in VMR9 YUV Mixing mode, I mean it's meant for YUV input so it converts back to YUV or rather just ask upstream filters to output YUV or fails.

Overlay doesn't accept RGB32 input for me, MPC will also automatically fall back to VMR7 then. I guess on 2k it falls back to GDI or something which is slowass compared to VMR7.

Colors look incorrect unless I froce RGB32 output in ffdshow.
Even in VMR9 YUV Mixing mode! Don't know why, but that's the way it is...

[clsid]

I have made an InnoSetup install script for ffdshow. With CPU detection :)

download (http://rapidshare.de/files/25481987/ffdshow_innosetup_script.rar.html)

[videomixer9]

Try using YUY2 and not YV12. Must be a reason Xvid and DivX decoders use it as default colorspace too :O

[LoRd_MuldeR]

YUV output:
http://img63.imageshack.us/img63/1222/yuv3ls.png

RGB32 output:
http://img63.imageshack.us/img63/3100/rgb323ih.png


YUY2 or YV12 makes no difference. I'll keep on force RGB32 output...

[videomixer9]

Well that is a VMR shoot, of course YV12 will look like YV12 only using the limited colorrange. I don't see anything wrong there, and if RGB32 looks like that with YUV mixing mode on VMR9 it's like wrong, should looks more like the first shot. I still don't get the VMR9mania, I stick to Overlays even though using them on VMR7 which is the fastest thing you can get on XP with hardware level conversion.

[LoRd_MuldeR]

Well that is a VMR shoot, of course YV12 will look like YV12 only using the limited colorrange. I don't see anything wrong there, and if RGB32 looks like that with YUV mixing mode on VMR9 it's like wrong, should looks more like the first shot.

Still the second one looks better, at least for my eyes :D
Haali Renderer always looks like the second one, but it has the delay problem...

[videomixer9]

Haali renderer just does level or RGB32 conversion itself. Of course YV12 will look funny on RGB32 screens, on TV out e.g. you prolly won't notice it though and that's what YV12 VMR9 is good for, you can output unchanged video to your TV. The colors are not wrong it's just that they are stored like this, but well what to tell all these VMR9 loving kids, only good thing on this modes is that you can view multiple videos at once, in reality nobody does that thus MPC auto switching of Overlay to the active player instance is fine enough for me when trying to do that. I don't see improved quality on those renderers either, but well people got rich imagination or never found the overlay color settings of their video cards, and why waste CPU time on things like Haali Renderer, as much as some may like it but e.g. OpenGL renderer in mplayer or VLC works way faster giving you basically the same benefits like using software resizers and colorspace converters. So much wasted energy for rendering video fancy when it works way easier with way less load. Remember that CoreAVC vs. Avivo checks, while Avivo may have been a bit faster than CoreAVC, the system used dozens of less watts for the almost same result :P

[Egh]

Hmm. I really don't understand what the fuss about levels. You can simply readjust levels in ffdshow or avisynth. So if you want YV12 output with corrected colors you can do that.

@ Liisachan: "RGB32 Output on Overlay" you sure you actually have "overlay mixer" in filters' list, not old GDI "Video Renderer".

@ VM9 : overlay doesn't allow screenshots iirc.

[videomixer9]

Well I don't do screenshots that often, and VMR7 windowed which uses Overlays additionally you can actually do screenshots, though of course the shot will come out without corrected levels if you don't correct them per software. This mode is also default on XP and working very fine, also using ffdshow for making shots isn't that bad.

[Liisachan]

@ Liisachan: "RGB32 Output on Overlay" you sure you actually have "overlay mixer" in filters' list, not old GDI "Video Renderer".
What I meant was MPC's Overlay + ffdshow's RGB32, on XP. That's only for testing but it was fast. I don't actually use it, because MPC's softsub is my life.

[SeeMoreDigital]

@ VM9 : overlay doesn't allow screenshots iirc.Unless I'm misunderstanding something... It seems to work okay for me: -

http://img269.imageshack.us/img269/4607/vmr9snap2uu.jpg

Cheers

[videomixer9]

What he meant was basically the same as me, you wrote it isn't really fast on 2k and that being due to it not being really Overlay. Also I wonder if on XP it really used Overlays as said, at least for me RGB32 ffdshow output makes Overlay not working and it will fall back to VMR7 without using overlays. Also softsubs might be a bit less resolution with vsfilter instead of using MPC internal renderer but it's fine enough for me and if you really need the quality just resize the video to a higher res via software so vsfilter renderers onto a better res, on TV it's no quality difference anyways, and most effects you can do with this filters are hardcoded mostly by encoders anyways as rendering eats massive CPU.

SeeMoreDigital: trying to run for the clowns award? he talks about overlays, not VMR9 (or as I'd call it kids toy, I think the original intention of that renderer is to give game designers the possibility to display videos on objects ingame). But VMR9 is cool and new so all the kids must use it for video playback duh.

[Egh]

What I meant was MPC's Overlay + ffdshow's RGB32, on XP. That's only for testing but it was fast. I don't actually use it, because MPC's softsub is my life.

and yet as I pointed out already, it's no wai an overlay :P


AFAIK, with ffdshow forcing RGB32 colorspace output, it does NOT use overlay on XP. And, it does not fallback to VMR7 as well (@ videomixer9).

It shows here (and always shown for me on any XP PC I tried) only "Video renderer", which is same as "Old Renderer" option in MPC. Though it might be due to videocards used on those PCs (all were NVidia).

Thus, Liisachan, you can pretty much have same result by selecting "Old renderer" instead of overlay mixer.

[Liisachan]

Egh: Yeah, I guess. What matters is not whether it is really Overlay or not, but it was fast when I ticked the box that says Overlay, on Win XP. I don't usually use XP to begin with. So that was just a random test so to speak.

...softsubs might be a bit less resolution with vsfilter instead of using MPC internal renderer but it's fine enough for me... Yeah, that's fine if it's fine for you.
most effects you can do with this filters are hardcoded mostly by encoders anyways as rendering eats massive CPU. It is understandable that leechers think that way, because their purpose is to read subs to enjoy the anime/movie. If it's readable and in a decent quality, it should be ok for them, and that's normal and nothing's wrong with that. Although, encoders (whom you talked about) themselves may have different perceptions. Anyway to sum up,
(1) there is a checkbox called Overlay Mixer in MPC's Output config, and selecting it may effect the performance
(2) Ticking the above "Ovelay" box doesn't necessarily mean that what is called Overlay is really used.
(3) If Overlay is really used, it's directly from HW, so you can't screencap. Otherwise you can.

Now back to the subject... What I was trying to say was:
- Ppl say "this ffdshow build is fast, and that is not fast" etc. but the speed is quite different according to your settings (this part is obvious). And there can be great difference even if the settings are the same, between Win2k and XP, and I found it kidna interesting.

[haruhiko_yamagata]

I have one sauce which is 1280*1080 (yes, HD anamorphic:P) and if I enter 1024,0 in the resizer it actually resizes too much in the vertical resolution, making less than 576 (DAR is 16:9).

What are the SAR (You can get the value in OSD)?
Does restarting of the video application improve anything?

[_xxl]

I have made an InnoSetup install script for ffdshow. With CPU detection :)
download (http://rapidshare.de/files/25481987/ffdshow_innosetup_script.rar.html)
InnoSetup install for ffdshow with CPU detection:
http://rapidshare.de/files/25562637/FFdshow_rev2546_20060711.zip.html
CPU detection:MMX,SSE&SSE2.