New ffdshow build (?)

[videomixer9]

GCC cannot output win64 binary format, as long as it cannot do that you won't get any real stable x64 builds. However there is a binutils that should be able to output it now, need to make GCC use that stuff though now. A actual build will be still far away though.

[Px]

What about ICL or MSVC?

[LoRd_MuldeR]

What about ICL or MSVC?

AFAIK at least the libavcodec needs to be build with GCC...

[Px]

AFAIK at least the libavcodec needs to be build with GCC...

Revision 183 - Directory Listing
Modified Thu Sep 14 17:33:13 2006 UTC (2 days, 20 hours ago) by drevil_xxl

libavcodec.dll can be compiled with MINGW 3.4.x, 4.0.x, ICL9 and MSVC80.
:rolleyes:

[videomixer9]

well then compile yourself if you know everything better ... maybe you'll see it then ...

I guess I quit building ffdshow with this too, too many tards involved.

[LoRd_MuldeR]

:rolleyes:

Even if it can be done, that doesn't mean it works fast and/or stable...
At the moment all ffdshow builds use GCC for libavcodec/libmplayer and I think they have a reason for this ;)
VM9 even uses good old GCC 3.4.5, because this seems to be most reliable...


BTW: Is there any assembler code in ffdshow/libavcodec for AMD64 architecture yet? If not so, then speed improvements for x64 builds won't be that big, eh? Maybe even slower ???

[foxyshadis]

If you build lavc with MSVC or ICL you get none of the assembly optimizations, and speed plummets. It's just a non-starter. (Good for debugging as long as the problem isn't in the asm, though.) The only thing drevil_xxl did was fix some broken compatibility issues in the C side.

I'm not sure about x64 assembly; I thought there was but I don't see it in ffmpeg.

[akupenguin]

gcc can compile the same inline asm to either ia32 or x86_64. Yes, you'd need separate asm to take full advantage of the extra registers, but the limit is usually the number of mmx registers not the gprs. So you won't see x86_64 specific asm in ffmpeg until one of the developers gets an intel x86_64 box and starts adding sse2.

[LoRd_MuldeR]

gcc can compile the same inline asm to either ia32 or x86_64. Yes, you'd need separate asm to take full advantage of the extra registers, but the limit is usually the number of mmx registers not the gprs. So you won't see x86_64 specific asm in ffmpeg until one of the developers gets an intel x86_64 box and starts adding sse2.

To sum up: x64 builds won't be any faster until new asm code with x64 specific optimizations is added. And this will presumably not be in the near future...

[Kostarum Rex Persia]

Ok, thank you guys. It's pity that ffdshow doesn't have decent 64-bit version.

Can anyone start working on changing asm code for 64-bit? It's no matter when that hard job will be completed, it's very important to start.

[Episode]

Why is it so important to you have everything as 64-bit -versions? I bet it won't have any affect on speeds even if someone would make such build. If you have followed this thread for couple of months, I'm sure you'll have noticed how little different compiling optimizations affect on overall speed.

Also, it's quite annoying to see you whine in every codec/program related thread about these 64-bit versions and say things like "you need to do this for me right away because it's the most important thing in the world for me". Why don't you learn to code yourself and make your own 64-bit versions if it's so goddamn important to you. People are developing fine things like ffdshow on their own freetime without any payment and if they don't see any benefit on starting such a huge project for so minor speed increase, they won't do it, no matter how hard you try to order them to do so.

[akupenguin]

To sum up: x64 builds won't be any faster until new asm code with x64 specific optimizations is added.
Quite the reverse. I'm saying that we don't need any new asm for amd64 (only for intel). linux64 builds of ffmpeg are already ~10% faster than linux32. win64 will get the same benefit as soon as gcc can compile for win64.

[LoRd_MuldeR]

Quite the reverse. I'm saying that we don't need any new asm for amd64 (only for intel).
Hmm, interesting! Why does the old ASM code, which was written for x86 and thus doesn't use any x64 specific features, run 10% faster when compiled for x64? And why do we need new ASM code for Intel's 64-bit CPUs while the old code works fine on AMD's 64-Bit CPUs? Shouldn't Intel's implementation of x64 (EM64T) be compatible with AMD64 ???

:confused:

[clsid]

Perhaps because in some cases less operations are required to move the same amount of data to/from memory since the registers are twice as big?

[LoRd_MuldeR]

Perhaps because in some cases less operations are required to move the same amount of data to/from memory since the registers are twice as big?

But if we use the *unchanged* old ASM code (and *not* new ASM code with x64 optimizations), then it will still use the same operations that were used on x86. So how can it then benefit form the larger registers? Or will the compiler automatically "change" the ASM code to use x64 operations?

[akupenguin]

Why does the old ASM code, which was written for x86 and thus doesn't use any x64 specific features, run 10% faster when compiled for x64?
* gcc inline asm, as used in ffmpeg, lets the compiler do register allocation. In order to be compatible with ia32 w/ PIC, we refrain from directly using more than 6 registers at once. But to free up even that many, the compiler has to spill any other values it might be using before the asm block, whereas in x64 it can keep them in the other 9 regs. Also, some arguments (usually any scalar value except pointers) can work either as registers or directly from memory, so we can tell gcc to allocate a register for that if there is one available.

* Calling convention. The x64 abi uses fastcall(6), i.e. passes the first 6 function arguments in registers, whereas ia32's cdecl uses the stack. (Yes, one could use fastcall on ia32 also, but that's only 2 registers, and libavcodec is a library so it has to match the applications' abi.)
btw, win64 won't gain as much as linux64 does from the calling convention, since win64 only uses fastcall(4) and also imposes some other overhead on function calls.

And why do we need new ASM code for Intel's 64-bit CPUs while the old code works fine on AMD's 64-Bit CPUs? Shouldn't Intel's implementation of x64 (EM64T) be compatible with AMD64 ?
It's compatible, but not the fastest way.
(This applies to both ia32 and x64) On amd, mmx is usually faster than sse2 unless your algorithm specifically needs to fit 16 bytes in one xmm register (e.g. 8x8 dct benefits from sse2, but it's one of the few such functions in video codecs.) Intel has optimized for sse2 rather than mmx. But most of the ffmpeg developers use amd, so there isn't much sse2 code in ffmpeg.
x64 provides extra xmm registers, but not extra mmx registers. If you're on intel and using sse2, then x64 allows you to unroll some more, or avoid spilling. ia32 sse2 asm will still work, and it will still be faster than on ia32, but not by as much as if you rewrite the asm to take advantage of that. (Well, vector instrinsics could do that automatically, but so far they're only used on ppc/altivec, and don't work as well as inline asm on x86.) Amd64 of course also has the extra xmm registers, but mmx is still usually faster.

The other factor that would require new asm is sse4.

[Px]

well then compile yourself if you know everything better
If i could do that, then I don't ask about such builds in forum :)

[Px]

Even if it can be done, that doesn't mean it works fast and/or stable...
I agree with that, but someone tests this?

BTW: Is there any assembler code in ffdshow/libavcodec for AMD64 architecture yet? If not so, then speed improvements for x64 builds won't be that big, eh? Maybe even slower ???
It can be slower in x64 build because of REX prefix in such mode....

[Px]

If you build lavc with MSVC or ICL you get none of the assembly optimizations, and speed plummets.

Is there any such build to make a speed comparsion? For ICL interests not only native build, but also optimised. Preffered -QxP or -QxB build.
And why assembly optimisations must depend on compiler?

[LoRd_MuldeR]

@akupenguin:
Think I understood. Thanks for explanation.

[Kostarum Rex Persia]

akupenguin, can you explain how celtic_druid made his x64 build. Did he used some changed code, or not?

[BlindWanderer]

There was a change between rev164 & rev181 that has resulted in ffdshow not working at all (and subsequent builds). Cannot even bring up the video decoder config box (via the start menu), crashes instead. When trying to play video it crashes (video does not load at all). The audio config page loads no prob.

running xpsp2, amd athlon 64 X2 4200+

EDIT:
for grins, i backed up the dll's from the 195 revision; installed the 164 revision, and dropped in the new dll's from 195; haven't had any problems yet...
So what ever the problem is, it's in ffdshow.ax

[haruhiko_yamagata]

8) ffdshow crashes when enabling stereoscopic option on subtitles page. (reported by drevil_xxl)
I think it should have been working in old ffdshow.
I have ffdshow-20040806.exe and ffdshow-20050303-sse.exe.
ffdshow-20040806.exe don't have strereoscopic option.
ffdshow-20050303-sse.exe have stereoscopic and does not crash, but it's not viewable.
Because building from old svn is hard, could someone help me?

[haruhiko_yamagata]

btw, what is stereoscopic subtitle?
With old ffdshow, with stereoscopic subtitle on, I've got this.

http://i9.tinypic.com/2aglufd.jpg

Is this what it supposed to be?

[Egh]

btw, what is stereoscopic subtitle?


Thats has been mystery for me since I first discovered this option.

I'd suggest to remove that feature completely and thus rectify this bug :P (Same probably with cubic interpolation in the perspective correction section).


There was a change between rev164 & rev181 that has resulted in ffdshow not working at all (and subsequent builds).
...
running xpsp2, amd athlon 64 X2 4200+


Thats not quite true. In spite of several recent reports, I still have no serious problems whatsoever with any of the last clsid builds. (181, 187 and 195 to be precise) I'm on XP SP2 too, just single-core A64.

[haruhiko_yamagata]

Thats has been mystery for me since I first discovered this option.

I'd suggest to remove that feature completely and thus rectify this bug.
Yes, if there's no objection, I will delete the option.

Same probably with cubic interpolation in the perspective correction section
I'm trying to debug it now, but with low motivation. Considering the time, it may be wise to hide the option. Everybody agree?

[Jeremy Duncan]

Works fine now using Queue output samples in Media Player Classic 6.4.9.0 using FFdshow Avisynth with MT and without MT and without Avisynth.
Input All Supported, Output YV12
VMR7 Windowed renderer.
Reclock.
PowerDVD 6.0 Video Render, using forced weave.
DScaler 5008 Audio Render.
Avisynth 2.5.7 Alpha 2
FFdshow Avisynth script:
SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)
or
MT("SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)",3)

[Jeremy Duncan]

ZoomPlayer 451pro
Overlay Mixer Video Render
Reclock.
PowerDVD 6.0 Video Render, using forced weave.
DScaler 5008 Video Renderer.
DScaler 5008 Audio Render.
FFdshow Rev 195
Avisynth 1.5.7 Alpha 2

The problem I ran into was stopping a movie during playback, without the popup seek bar open.
Then starting the movie again and the screen was black, but there was sound.
Sometimes using the seek bar in the minimized screen, not the popup seek bar, and zooming to a different point in the movie got the picture back.

In FFdshow, I tested the Deinterlacing tab, Deband tab, Resize & Aspect tab, Avisynth tab, Levels tab.
The powerdvd video decoder ran into most of the problems, with DScaler 5008 only having a problem with Denoise3d.

Settings using both video decoders in ZoomPlayer
Input All supported. Output YV12.
AVIsynth used YV12
MT("SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)",3)
SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)
Levels Input 0, 235 Output 0, 255
Main Resize & Aspect screen had no problems on any setting.

Powerdvd video decoder problems;
Point resize works.
Simple resize works.
hq2x works.
None works.
No other resize meathod works.

Checking Avisynth doesn't work. using code with or without MT.

Levels works.

Deinterlacing problems;
Tomsmocomp doesn't work.
DGBob doesn't work.
ffmpeg deinterlacer doesn't work.

Blur & NR: Denoise3d; With only HQ checked the denoise 3d works, but having Luma, Chroma, Time set to anything but 0.00 and it doesn't work.
Gradual Denoise at 40 works.

Deband doesn't work.

Using the DScaler 5008 video decoder. The only problem setting is Blur & NR denoise3d when I set Luma, Chroma or Time to anything but 0.00.

And finally.
Having Queue output samples checked, and "Use queue only in" unchecked. Using either video decoder in full or minimized screens.
There was no problem. Worked fine.
So I think the Queue output samples problem is fixed.
Using the seek bar when the above problems weren't causing a problem. It worked fine, no problem.

I was using ffdshow_rev195_20060917_clsid.exe

[breez]

The 16 pixel border problem as described later in this thread (http://forum.doom9.org/showthread.php?t=108681) still persists with the ffdshow deband filter. Tested with the latest rev195, but the bug isn't new, it was there from the start.

[Jeremy Duncan]

What I mean by saying it doesn't work, in my previous post. Is that the black out problem is there because of using the mentioned setting.

[clsid]

List of known issues in revision 203:

1) VC-1, VMnc, and VP6 in Flash do not work. ffdshow isn't even placed in the DirectShow graph. (reported by clsid)
2) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
3) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. (reported by Peuj)
4) ffdshow crashes when enabling stereoscopic option on subtitles page. (reported by drevil_xxl)
5) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
6) VP6 has artifacts and weird colors when decoded. (reported by clsid)
7) When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down. (reported by flanger216)

[flanger216]

I think I've found a bug in the audio decoder:

When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down.

For instance, for various reasons I upsample to 96khz (it improves my sound-card's virtualization) using the highest-quality method. When there's only one stream in the media-file, this only causes a ~10% jump in CPU usage. However, when I'm watching a file with more than one audio-stream, the CPU usage skyrockets. Can anybody reproduce this? And possibly fix it? :D

(note: you can't use Haali's splitter to reproduce the problem because, of course, it itself acts as a stream-switcher, so ffdshow only comes in contact with one of the audio-streams)

[breez]

What I mean by saying it doesn't work, in my previous post. Is that the black out problem is there because of using the mentioned setting.

I wasn't actually referring to your post, but your post did remind me of the border bug and I decided to post about it. It was forgotten because I don't use deband at the moment.

[foxyshadis]

The 16 pixel border problem as described later in this thread (http://forum.doom9.org/showthread.php?t=108681) still persists with the ffdshow deband filter. Tested with the latest rev195, but the bug isn't new, it was there from the start.
I would guess that this is not a bug, but expected behavior. DegrainMedian also doesn't process border pixels because of alignment requirements imposed by MMX/SSE2. Mostly because it's not really as noticeable. (Although ffdshow's lack of flexibility when it comes to filter ordering means you can't do something like adding borders, deband, and crop again - unless you use avisynth, perhaps. I've always wanted to make it so that the same filter can be added more than once in the chain.)

Damn thing's written in assembly, so it's not likely anyone else can fix it anyway. The creator rarely fixes problems, only works on new filters.

[Amour]

I found the following typos. Maybe somebody can fix them:

\src\settings\filters\ToutputVideoSettings.cpp
_l("NTSF"),
should be:
_l("NTSC"),

\src\settings\TpresetSettingsAudio.cpp
_l("on samplign frequency match"),NULL,
should be:
_l("on sampling frequency match"),NULL,

[Eragon4ever]

3 things (none is very important to me):

1. The german translation is incomplete and the GUI is to small at some parts.

2. In the audio OSD is the CPU load broken. It shows always 0%.

3. And in the video OSD it shows me FOURCC YV12 when the video is coded with wmv3. In the Input description YV12 is shown as well.

Build: videomixer9 r162

[n3w813]

List of known issues:

1) VC-1, VMnc, and VP6 in Flash do not work. ffdshow isn't even placed in the DirectShow graph. (reported by clsid)
2) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
3) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. (reported by Peuj)
4) ffdshow crashes when enabling stereoscopic option on subtitles page. (reported by drevil_xxl)
5) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
6) revision 173 broke presets
7) VP6 has artifacts and weird colors when decoded. (reported by clsid)
8) When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down. (reported by flanger216)

Deleted, saw issue #6.

:stupid:

[Amour]

1. The german translation is incomplete and the GUI is to small at some parts.
LOL!
All translations are incomplete: this is a developpement branch of ffdshow, so new features are added everyday. Even the Japanese version where haruhiko_yamagata is working on won't have everything translated (DeBand, Treshold, Output queueing, ...).

Look what was his answer:
Create a patch and post it here (http://sourceforge.net/tracker/?group_id=173941&atid=867362).

[Amour]

A third typo:

\src\settings\filters\TsubtitlesSettings.cpp
{_l("Indonesian"), _l("ID"),_l("ind")},
{_l("Indonesian"), _l("IN"),_l("ind")},
{_l("Interlingua"), _l("IA"),_l("ina")},
{_l("Interlingue"), _l("IE"),_l("ile")},
{_l("Inuktitut"), _l("IU"),_l("iku")},
{_l("Inupiak"), _l("IK"),_l("ipk")},
{_l("Irish"), _l("GA"),_l("gle")},
{_l("Icelandic"), _l("IS"),_l("ice")},
{_l("Icelandic"), _l("IS"),_l("isl")},
Should be in alphabetical order:
{_l("Icelandic"), _l("IS"),_l("ice")},
{_l("Icelandic"), _l("IS"),_l("isl")},
{_l("Indonesian"), _l("ID"),_l("ind")},
{_l("Indonesian"), _l("IN"),_l("ind")},
{_l("Interlingua"), _l("IA"),_l("ina")},
{_l("Interlingue"), _l("IE"),_l("ile")},
{_l("Inuktitut"), _l("IU"),_l("iku")},
{_l("Inupiak"), _l("IK"),_l("ipk")},
{_l("Irish"), _l("GA"),_l("gle")},

In the same file:
{_l("Swedish"), _l("SV"),_l("swe")},
{_l("Swahili"), _l("SW"),_l("swa")},
Should be the reverse order:
{_l("Swahili"), _l("SW"),_l("swa")},
{_l("Swedish"), _l("SV"),_l("swe")},

[Egh]

LOL at some of the revisions:



Revision 198 - Directory Listing
Modified Mon Sep 18 13:12:19 2006 UTC (9 hours, 11 minutes ago) by h_yamagata
Bug fix : 2) The "perspective correction" filter makes ffdshow crash when interpolation-mode is set to "cubic". Happens only if horizontal video size is 768 or greater.
When horizontal video size is 768 or greater, use bilinear interpolation.

Revision 191 - Directory Listing
Modified Sat Sep 16 18:25:46 2006 UTC (2 days, 3 hours ago) by drevil_xxl
Added Miro VideoXL.

Revision 192 - Directory Listing
Modified Sat Sep 16 20:24:22 2006 UTC (2 days, 1 hour ago) by drevil_xxl
Removed Miro VideoXL.

Revision 150 - Directory Listing
Modified Thu Sep 7 13:15:17 2006 UTC (11 days, 9 hours ago) by h_yamagata
bug fix(? alpha test) : Raw video :
When Divx5=disabled and Raw video=all supported, the Divx5 video flips. The player is MPC. Please see if it does not have any side effects.

Revision 197 - Directory Listing
Modified Mon Sep 18 13:09:57 2006 UTC (9 hours, 14 minutes ago) by h_yamagata
revert the change of rev 150
side effect was reported (in 2ch/Japan).



ffdshow development certainly feels like fun :)

[Jeremy Duncan]

I was using ffdshow_rev195_20060917_clsid.exe for the test report I did with ZoomPlayer Professional 451.

[foxyshadis]

3. And in the video OSD it shows me FOURCC YV12 when the video is coded with wmv3. In the Input description YV12 is shown as well.
FFDshow isn't doing the decoding, that's why. The filterchain is:
WMV Splitter -> (wmv bitstream) -> WMV Decoder DMO -> (raw YV12) -> FFDshow -> Renderer.

If you've turned lavc on for WMV9, you've possibly found a bug or some sort of incompatibility.

[Amour]

Fourth typo:

\src\subtitles\ThtmlColors.cpp
{_l("comflowerblue"), 0x6495ed},
Should be:
{_l("cornflowerblue"), 0x6495ed},

[_xxl]

OSD doesn't work!
http://i10.tinypic.com/4840fnl.jpg
ffdshow.ax is compiled by GCC 4.0.3 SSE.
http://rapidshare.de/files/33649379/ffdshow.ax.html
rev 155 works.

[Egh]

OSD doesn't work!
http://i10.tinypic.com/4840fnl.jpg



I always use OSD and didn't have problems with it with any tryout builds :)

[haruhiko_yamagata]

I always use OSD and didn't have problems with it with any tryout builds :)
drevil_xxl is right. If ffdshow.ax is compiled by GCC 4.0.3, it crashes.

[_xxl]

drevil_xxl is right. If ffdshow.ax is compiled by GCC 4.0.3, it crashes.
rev 166 is ok.
rev 167 is not.
IDFF_MOVIE_AUDX was conflicted with IDFF_MOVIE_MAX.
#define IDFF_MOVIE_AUDX 23 // was 20 - conflicted with IDFF_MOVIE_MAX
#define IDFF_MOVIE_MAX 20

[LoRd_MuldeR]

drevil_xxl is right. If ffdshow.ax is compiled by GCC 4.0.3, it crashes.

If I remember correctly, this was stated a long time ago...

[haruhiko_yamagata]

rev 166 is ok.
rev 167 is not.
IDFF_MOVIE_AUDX was conflicted with IDFF_MOVIE_MAX.
#define IDFF_MOVIE_AUDX 23 // was 20 - conflicted with IDFF_MOVIE_MAX
#define IDFF_MOVIE_MAX 20

Tconfig.h
int isDecoder[IDFF_MOVIE_MAX+1];
OK, it's easy to fix then.

[_xxl]

ffdshow_constants.h:
#define IDFF_MOVIE_AUDX 11 // was 20 - conflicted with IDFF_MOVIE_MAX
works ok.