ffdshow tryouts project: Discussion & Development

[Dark Shikari]

Maybe because it's not assembler code, but intrinsic functions...x264 doesn't currently use any assembly intrinsics. I've considered it, but the main problem is just that GCC sucks, and it generally doesn't compile intrinsics very well.

[LoRd_MuldeR]

Because every operating system except Windows uses a certain 64-bit calling convention... while Windows uses a totally different one. And Akupenguin doesn't want to maintain the Windows 64-bit version of the calling code.

I see. But calling conventions should only make a problem if the called function expects a different convention than the caller, right? So as long as all functions in x264 (including the assembly) agree on the same calling conventions, it should work fine. So why do we need to care about the OS' calling convention, as long as we don't want to call any system functions?

[Dark Shikari]

I see. But calling conventions should only make a problem if the called function expects a different convention than the caller, right? So as long as all functions in x264 (including the assembly) agree on the same calling conventions, it should work fine. So why do we need to care about the OS' calling convention, as long as we don't want to call any system functions?The Windows 64-bit calling convention is extremely weird and does some pretty bizarre things, so I'm not sure how possible that is.

The other reason is because you'd probably have to reprogram the compiler to use a certain calling convention for all externally called functions, and the *nix calling convention for all internal-only functions. I'm not sure if there's an easy way to do this with __fastcall or not.

[LoRd_MuldeR]

The other reason is because you'd probably have to reprogram the compiler to use a certain calling convention for all externally called functions, and the *nix calling convention for all internal-only functions. I'm not sure if there's an easy way to do this with __fastcall or not.

hmmm, I see. Thanks for info.

[squid_80]

x264 hasn't worked on 64-bit since sometime in 2005 (if ever), and even then it was probably just incidental.
It was working up until at least August last year. It was not at all incidental, I put a fair bit of effort into it and if you look back through the revisions you'll probably faintly recognize the start of the assembly abstraction (Even though your blog says "Written from scratch by Loren Merritt...").

LoRd_MuldeR: You can tell the C compilier what convention to use (fastcall, stdcall etc.) but you can't tell it how the ABI works; that is the problem here.
P.S. Windows will occassionally butt in between function calls and have it's way with the stack. I haven't figured out how or why, I just know the "red zone" is another luxury Linux has that Windows doesn't.

[Dark Shikari]

It was working up until at least August last year. It was not at all incidental, I put a fair bit of effort into it and if you look back through the revisions you'll probably faintly recognize the start of the assembly abstraction (Even though your blog says "Written from scratch by Loren Merritt...").Hmm, I got my info from Loren, so either he wasn't very clear or I missed it.

Though his commit message where he removed all Windows 64-bit-related code would disagree with you.

I suspect for more detailed info you're going to have to ping him to this thread...

[squid_80]

November 2007: http://mirror05.x264.nl/Cef/force.php?file=./x264_x64_r682.7z
I don't mind having the code removed; I was never willing to consistently maintain it, and now I can tell people who PM me about updating it to buzz off because my name's not on there.

[LoRd_MuldeR]

LoRd_MuldeR: You can tell the C compilier what convention to use (fastcall, stdcall etc.) but you can't tell it how the ABI works; that is the problem here.

Yes, I understand. But when calling your own (internal) functions you don't need to care about the OS' ABI. So my though was: Use whatever calling convention satisfies the OS for calling system functions and use your preferred calling convention for calling the internal functions. This way the calling convention used to call your (internal) assembly functions could always be the same, no matter which OS you are running on. So you wouldn't have to adjust the assembly for every OS (*nix vs. Win64). But from what I understand now, the compiler doesn't support that method...

[Dark Shikari]

Yes, I understand. But when calling your own (internal) functions you don't need to care about the OS' ABI.But what if your internal calling convention relies on certain registers being conserved during context switches--registers that the OS doesn't conserve?

[squid_80]

Yes, the C compiler uses the ABI for the target OS. If you're calling assembly functions from assembly functions, you can pretty much use whatever convention you want (as long as stack alignment is observed).

(Quick 'n' Dirty way to fix the "xmm6-xmm15 are non-volatile" problem on win64: write 2 assembly functions to save/restore them, wrap them around the asm function calls (like emms) and don't use floating point in between. It won't unwind properly but who gives a crap.)

The only registers win64 doesn't preserve over context switches are MMX registers in kernel mode.

[akupenguin]

But what if your internal calling convention relies on certain registers being conserved during context switches--registers that the OS doesn't conserve?
The OS has to preserve all registers, because context switches can occur anywhere in the code, not just at function boundaries. A register that isn't preserved on switches can't ever be used.

It was working up until at least August last year.
Sure there were patches floating around, but they weren't submitted to svn, and I don't care enough about win64 to pull patches from someone elses repository without input from the authors.

Win64 support was added in r336 (2005-10-25). The first subsequent revision to break it was r353 (2005-11-02) which used 10 xmmregs without saving any. Win64 was never committed again.

[leeperry]

I know there's little chance I'll get a reply but anyway :D

I understand the "deband" filter of ffdshow is actually the "gradfun2db" AVS script, which I prefer to use to run it multithreaded with MT.

anyone knows what AVS script the "unsharp masking" filter of ffdshow comes from ?

Thanks,

[Inventive Software]

You could :search: in the AviSynth forums. ;)

[leeperry]

well I know I can get unsharp masking with LSF....that's not the point..

I would like to get the exact same algorithm as ffdshow, but in AVS.

set to 6 it creates some very slight EE, that I find very appealing.

[Mercury_22]

Great improvements in x64 version now with ffdshow_rev2009_20080616_clsid_x64 I can see ffdshow in VirtualDub-1.8.1-AMD64's video compression menu and I can encode using "Libavcodec" (mpeg4, DivX3...) ! :thanks: (and it's so fast... :) ! .... only if x264 would been available in x64 :p :))

But when I'm using xvid for encoding VirtualDub-1.8.1-AMD64 it's crashing with this error message :
roblem Event Name: APPCRASH
Application Name: Veedub64.exe
Application Version: 1.8.1.0
Application Timestamp: 48556ca0
Fault Module Name: xvidcore.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 48555728
Exception Code: c0000005
Exception Offset: 0000000000088199
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 6687
Additional Information 2: 7aa12ef2e1d3af19ae1243cad32742e1
Additional Information 3: 595c
Additional Information 4: 5a3571e18b531ebc7ebe8615900c8fc0

[clsid]

Does xvidcore work properly for decoding?

[Mercury_22]

Does xvidcore work properly for decoding?

(Yes decoding it's OK !) = wrong :confused:

EDIT : I was wrong sorry NOT working I forget to change to xvid instead of Libavcodec when I tested

[_xxl]

I would like to know if any MinGW GCC x64 compiled:
libmpeg2
theora
liba52
libtds
libmad
faad
tremor
realaac
libavcodec
libmplayer
xvidcore
x264
are working or not?
Please test with VirtualDub64 and 64bit media player.
Thanks!

[Mercury_22]

I would like to know if any MinGW GCC x64 compiled:
libmpeg2
theora
liba52
libtds
libmad
faad
tremor
realaac
libavcodec
libmplayer
xvidcore
x264
are working or not?
Please test with VirtualDub64 and 64bit media player.
Thanks!

Encoding Using VirtualDub-1.8.1-AMD64 :

- libavcodec (mpeg4, divx 3...), theora are working
- xvidcore NOT working
- the others how should I test them since they are NOT in the ffdshow64 video encoder configuration (VFW configuration) ??? :mad: :helpful:

Decoding using MPC-HC x64 & WMP x64 :
- libavcodec ( all ), theora, liba52, libmad, mp3lib, libfaad2, realaac, tremor, are working
- libmpeg2, xvidcore NOT working

[_xxl]

libmpeg2, xvidcore NOT working
Are those crashing?
Did you tried theora decoder/encoder?
x64 libmpeg2, x264, xvidcore, libmplayer, liba52, libdts, faad, realaac, tremor will be compiled from plain C only.
Only libavcodec seems to work, but not 100% sure.
Please test all libavcodec codecs encoding and decoding.
So Win64 is not supported?

[Mercury_22]

Are those crashing?
Did you tried theora decoder/encoder?
x64 libmpeg2, x264, xvidcore, libmplayer, liba52, libdts, faad, realaac, tremor will be compiled from plain C only.
Only libavcodec seems to work, but not 100% sure.
Please test all libavcodec codecs encoding and decoding.
So Win64 is not supported?

NONE IS CRASHING (except xvid when encoding but it's mre probable to be VirtualDub-1.8.1-AMD64's fault look here (http://forums.virtualdub.org/index.php?act=ST&f=4&t=15774&)) just not decoding or encoding
Yes I've tried theora decoder/encoder and it's working !
Tested all ( AFAIK ) libavcodec codecs decoding, for all encoding later today

Also libdts later today because i don't have a sample ! Can anyone give me a link to a DTS sample ? Please

Update : libdts not working in X64 AND APPARENTLY NOT WORKING IN X86 TOO ! Can anyone confirm this (x86) !
I'm using ffdshow_rev2008_20080615_xxl for x86 and ffdshow_rev2009_20080616_clsid_x64 for x64

Update 2 tested "all libavcodec codecs encoding " and no problems !

[fastplayer]

When enabling "LFE Crossover", all audio that is already present in the discreet LFE channel of a DD5.1 ac3 signal is muted. Hence the ".1 channel" is completely lost!
Correct would be to maintain the LFE signal and simply add the bass from the other 5 channels to it.
Can somebody confirm this?

[_xxl]

Please check that all libs are compiled by MinGW GCC x64, not MSVC.

[Mercury_22]

Please check that all libs are compiled by MinGW GCC x64, not MSVC.

I'm using ffdshow_rev2009_20080616_clsid_x64 So.. :confused: ask clsid because ther's nothing in the Release Notes (http://sourceforge.net/project/shownotes.php?group_id=173941&release_id=569930) :logfile:

Maybe someone can compile a new version and tell us what he used to compile all libs ! :script: :helpful:

Update : libdts not working in X64 AND APPARENTLY NOT WORKING IN X86 TOO ! Can anyone confirm this (x86) !

I'm using ffdshow_rev2008_20080615_xxl for x86 and ffdshow_rev2009_20080616_clsid_x64 for x64

[clsid]

I've used GCC for: libavcodec, libmplayer, libmpeg2, libtheora, xvidcore, tomsmocomp

[_xxl]

I will make new x86 and x64 builds today. Please test them.

[Mercury_22]

I will make new x86 and x64 builds today. Please test them.

Ok but can anyone confirm the DTS problem on x86 ? :logfile:

[_xxl]

No, it works with my samples, x86.

[Mercury_22]

No, it works with my samples, x86.

Can you upload a sample please!

[fastplayer]

DTS workin fine with rev2000.
Sample: http://www.mediafire.com/?39cbbpnb0gz

[Mercury_22]

DTS workin fine with rev2000.
Sample: http://www.mediafire.com/?39cbbpnb0gz

Your sample it's working for me too on both x86 and x64 :thanks:
Can you test my sample audio only DTS 5.1 wav (http://www.diatonis.com/downloads_dts_ac3.html) for me it's working only with AC3Filter or PowerDVD ( audio cd )

[_xxl]

Wav in dts was not working before, this is a know issue, doesn't work with mpc, only with latest ac3filter.

[fastplayer]

Can you test my sample audio only DTS 5.1 wav (http://rapidshare.com/files/123095978/testdts.wav.html) for me it's working only with AC3Filter or PowerDVD ( audio cd )
All I get is noise. VLC plays it back though.
I'm not sure if the wave parser correctly detects DTS... Did this sample work with previous ffdshow versions?

Edit: XXL cleared it up! :)

[Mercury_22]

All I get is noise. VLC plays it back though.
I'm not sure if the wave parser correctly detects DTS... Did this sample work with previous ffdshow versions?

I don't know i don't have previous ffdshow version and i'm not going to install old versions

Also i've update my link with new samples Also wavs

Wav in dts was not working before, this is a know issue, doesn't work with mpc, only with latest ac3filter.

Tested with WMP and PowerDVD (with powerdvd it's working as audio cd/dvd) also and not working so ffdshow it's not working not mpc :eek:

[Mercury_22]

ffdshow_rev2014_20080617_clsid_x64 tested and :
- xvid CAN decode and encode without any problem s! :) :thanks:
- libmpeg2 still NOT working :mad:

[clsid]

Xvid will probably be a bit slow, since the assembly optimizations have been disabled for x64 builds of xvidcore.

[Dark Shikari]

Xvid will probably be a bit slow, since the assembly optimizations have been disabled for x64 builds of xvidcore."A bit" is probably a severe understatement.

I'm not sure why one would want to include such an encoder without assembly; if anything you're just going to mislead people into thinking its slower than it actually is rather than advise them to download the standalone 32-bit version. Unless maybe you put a gigantic notice that says "THESE ENCODERS ARE REALLY SLOW AND HAVE NO ASM SO DON'T USE THEM"--but if so, what's the point of even including them?

[_xxl]

Only theora and libavcodec has been compiled for x64 with assembly, the rest is just C.
So there isn't no Win64 support for x264, xvidcore and libmpeg2.
Is there a plan to support Win64?

[Dark Shikari]

Only theora and libavcodec has been compiled for x64 with assembly, the rest is plain C.
So there isn't no Win64 support from x264, xvidcore and libmpeg2.
Is there a plan to support Win64?I would strongly object to including x264 without asm support, given that the speed would be absolutely abominable and it would reflect badly on the x264 project.

There is no plan to support Win64 unless someone steps up to maintain it.

[clsid]

I will remove it from my future installers. If I decide to make any that is, because I am getting really fed up with all the x64 crap that I don't even use myself.

[georgevalkov]

I will remove it from my future installers. If I decide to make any that is, because I am getting really fed up with all the x64 crap that I don't even use myself.

I agree with that. After all of the changes that You and _xxl made recently, I'd recommend you to have a rest and eventually make plans for the feature. :cool:

[Mercury_22]

With XXl's ffdshow_rev2014_20080617_x64 version libmpeg2 it's working now :thanks: and I even have H.264 in the encoding menu ..... to bad that it's not working do to lack of win x64 support in x264 :mad:
Anyway Thanks XXL and all other ffdshow's developers for your hard work ! :thanks:

[video_magic]

.....
Anyway Thanks XXL and all other ffdshow's developers for your hard work ! :thanks:

Amen! Thanks so much from Me also :)

[Anima123]

Big thanks for all who devoted in this great project.

[tiresias]

A couple of questions about the ffdshow mpeg2 decoder ...

When you use the Microsoft DV decoder, you can set its properties to "half resolution" which produces a half-size decoded image and reduces the load on the CPU. Is there a similar property that can be changed in the ffdshow mpeg2 decoder, so that high definition mpeg clips could be displayed in half resolution and with a reduced load on the CPU which would hopefully help stutter-free playback on lower powered PCs? If there is not such a setting, would this be a good addition?

High definition at full resolution is larger than most PC screen resolutions, so in most cases it would have to be displayed at less than it's full res on screen. In that case it seems a good idea to get hopefully stutter-free playback by decoding at half of full resolution.

The second question is do the ffdshow decoders provide access to properties via a DirectShow programming interface to the filter (instead of the properties dialog box).

[Mercury_22]

After more testing I found that liba52 it's not working in XXL 's ffdshow_rev2014_20080617_x64 and libmpeg2 it's not working in clsid's ffdshow_rev2014_20080617_x64 ! :confused:
Help please ! :helpful:

[georgevalkov]

A couple of questions about the ffdshow mpeg2 decoder ...

When you use the Microsoft DV decoder, you can set its properties to "half resolution" which produces a half-size decoded image and reduces the load on the CPU. Is there a similar property that can be changed in the ffdshow mpeg2 decoder, so that high definition mpeg clips could be displayed in half resolution and with a reduced load on the CPU which would hopefully help stutter-free playback on lower powered PCs? If there is not such a setting, would this be a good addition?

My compurer's CPU is Athlon XP1700+ overclocked to 1.89 GHz.

CPU usage with ffdshow for interlaced 20 Mbit/s MPEG-2 720x576 PAL 25 fps playback is 33% for both libavcodec and libmpeg2.

If you are lucky enough, a decoder that supports DXVA_ModeMPEG2 will be able to utilize the video hardware and reduce the CPU load. ATi All in Wonder 9600XT come with a DVD decoder called: CyberLink Video/SP decoder. CPU usage for the same media is less than 15%. Or if I force BOB deinterlacing and connect to VMR9, it will play at 50 fps and consume about 30% of CPU.

MPlayer consumes about 30% of CPU.
^ Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough

full-HDTV [DivXTestCDv2.0.b/H_VIDEO_CODECS/VID-1E.mpg] 1920x1088p consumes less than 19% with the CyberLink decoder and DXVA enabled. Currently this is the only format, for which I don't use ffdshow.


High definition at full resolution is larger than most PC screen resolutions, so in most cases it would have to be displayed at less than it's full res on screen. In that case it seems a good idea to get hopefully stutter-free playback by decoding at half of full resolution.

When I want to play an HDTV move, I change the screen resolution to match the movie's and enjoy it.

The second question is do the ffdshow decoders provide access to properties via a DirectShow programming interface to the filter (instead of the properties dialog box).
I think that the answer is Yes, but I don't know anything else.
Good luck!

[clsid]

When you use the Microsoft DV decoder, you can set its properties to "half resolution" which produces a half-size decoded image and reduces the load on the CPU. Is there a similar property that can be changed in the ffdshow mpeg2 decoder, so that high definition mpeg clips could be displayed in half resolution and with a reduced load on the CPU which would hopefully help stutter-free playback on lower powered PCs? If there is not such a setting, would this be a good addition?That is not possible and this functionality will not be added.

The second question is do the ffdshow decoders provide access to properties via a DirectShow programming interface to the filter (instead of the properties dialog box).There is a very basic API for controlling some parts of ffdshow. Look at the source code or ask Albain (he implemented it). But for the most part of ffdshow, there is no way to control it programmatically. And there are no plans to add such functionality.

[Reimar]

[Concerning playing MPEG-2 at half resolution]

That is not possible and this functionality will not be added.


It is not in any way important to me, but I am curious why it is impossible? libavcodec itself does offer the functionality, at least for some codecs.

[clsid]

For libavcodec's mpeg-2 decoder there already is a "use speedup tricks" option in ffdshow. I don't know what that does precisely.


Generally speaking, at this moment, it is very unlikely that new functionality will be implemented in ffdshow, unless someone steps up and offers to do it. The current devs simply don't have the time, skills, or motivation to add new stuff. The only new functionality that is planned (afaik) is adding the AC3/E-AC3/AAC decoders from libavcodec. xxl is going to do another attempt to get them working with ffdshow.