ffdshow tryouts project: Discussion & Development

[madshi]

@dukey, here are benchmarks from an ATI 5700 GPU on win7 x64:

DXVA Surface speed test:
NV12: upload 254 fps, download 4 fps
YV12: upload 255 fps, download 4 fps
A8R8G8B8: upload 272 fps, download 2 fps

A8R8G8B8 Texture speed test:
default: upload 109 fps, download 217 fps
dynamic: upload 304 fps, download 2 fps

All the "downloads" are 1:1 without any format change. As you can see, the results differ a lot, depending on resource type (Surface / Texture) and on allocation type (DXVA / D3D9, default/dynamic pool). The general result is, though, that NV12 downloads are painfully slow with ATI cards, and that's exactly what you need if you want to download untouched DXVA decoding results to CPU RAM. The download in my benchmark was *not* done via SSE4, though, so probably that would speed things up.

For comparison here are results from a GTX 295 in win7 x64:

DXVA Surface speed test:
NV12: upload 458 fps, download 593 fps
YV12: upload 729 fps, download 205 fps
A8R8G8B8: upload 345 fps, download 201 fps

A8R8G8B8 Texture speed test:
default: upload 191 fps, download 314 fps
dynamic: upload 211 fps, download 30 fps

[dukey]

That's really unusually slow. From what I recall with nvidia, if you ask for a RGBA texture, it's actually laid out ABRG in memory. So if you read out ABRG it's fast, where as if you read out RGBA it's painfully slow. ABRG matches the windows pixel format. I guess that explains

A8R8G8B8: upload 272 fps, download 2 fps

and

A8R8G8B8 Texture speed test:
default: upload 109 fps, download 217 fps

My guess is the graphics card is converting NV12 to a different format internally, then doing software conversion when you read it back.
With my own opengl renderer, I split NV12 into a luminance texture for (Y), and a luminance alpha texture for (UV).

[hoborg]

@madshi:
Just for info, did you have any results from AMD FUSION APUs?

[madshi]

That's really unusually slow.
FWIW, I've about 40 benchmark results for ATI and also 40 for NVidia from different users. They all pretty much say the same thing.

From what I recall with nvidia, if you ask for a RGBA texture, it's actually laid out ABRG in memory. So if you read out ABRG it's fast, where as if you read out RGBA it's painfully slow. ABRG matches the windows pixel format. I guess that explains [...]
I don't think so in this case. I've allocated all RGB resources in exactly the same format, just with different pool flags. The difference is probably caused by whether the resource is allocated in GPU RAM or in PCIe RAM or something like that.

My guess is the graphics card is converting NV12 to a different format internally, then doing software conversion when you read it back.
Software conversion would be much faster than 4fps, unless they use interpreted Visual Basic code... :p

With my own opengl renderer, I split NV12 into a luminance texture for (Y), and a luminance alpha texture for (UV).
I do that, too, in madVR. But you cannot tell DXVA to do that. The DXVA output is an NV12 surface and there's no way to properly split it into separate Y/UV textures on the GPU (except by using CUDA). Unfortunately ATI offers no OpenCL / Direct3D9 interop, so for ATI cards we're simply out of luck.

Just for info, did you have any results from AMD FUSION APUs?
I'm not sure, maybe. If I have, they're pretty old. But it doesn't really matter, anymore. Not to me, at least.

[haruhiko_yamagata]

@ikarad and who are interested in subtitles,

[FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv
"Complex karaoke", one of the two embedded ASS subtitles, uses \t. Current ffdshow does not have \t implementation. Please wait until it is implemented.

[Rising_Sun]_Chihayafuru_-_01_[HDTV_-_720p_-_H264_-_AAC][9130C84A].mkv
The script has \pos and \move in the same line. Bug fixed.
The script has {\1aH&99&}, which is a typo of {\1a&H99&}. Fixed anyway.

1.m2ts
PGS crashes: The bug was hidden temporally. It no longer crashes.

_utw_ fate stay night - unlimited blade works _bd__h264-720p ac3__70764ba9_.ass
Positioning bug fixed.

A test build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4018_20111104_branch.exe)

[ikarad]

@ikarad and who are interested in subtitles,

[FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv
"Complex karaoke", one of the two embedded ASS subtitles, uses \t. Current ffdshow does not have \t implementation. Please wait until it is implemented.

[Rising_Sun]_Chihayafuru_-_01_[HDTV_-_720p_-_H264_-_AAC][9130C84A].mkv
The script has \pos and \move in the same line. Bug fixed.
The script has {\1aH&99&}, which is a typo of {\1a&H99&}. Fixed anyway.

1.m2ts
PGS crashes: The bug was hidden temporally. It no longer crashes.

_utw_ fate stay night - unlimited blade works _bd__h264-720p ac3__70764ba9_.ass
Positioning bug fixed.

A test build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4018_20111104_branch.exe)
Thanks, I am going to try.

I expect that your correct pgs crash definitively if you can and the problem with complex karaoke.

But one problem: deband filter doesn't work with your version.
Clsid had correct this bug before because it was compiler that make a problem with deband filter
Those changes are required to compile with 4.5.3.
4.6.1 gives broken deband.

[alexins]

Thanks, I am going to try.

I expect that your correct pgs crash definitively if you can and the problem with complex karaoke.

But one problem: deband filter doesn't work with your version.
Clsid had correct this bug before because it was compiler that make a problem with deband filter.

Originally Posted by clsid
Those changes are required to compile with 4.5.3.
4.6.1 gives broken deband.


gcc 4.6.2 gives working deband :D

[Midzuki]

gcc 4.6.2 gives working deband :D

Great :) :) :)

@ betaking - have you read this? ;) :rolleyes:

[ikarad]

@ikarad and who are interested in subtitles,


I think I find another bug with sub renderer.
I try your test build and with mpc sub renderer I have this at 18"25
http://img11.hostingpics.net/thumbs/mini_150933mpc.jpg (http://www.hostingpics.net/viewer.php?id=150933mpc.jpg)

With ffdshow I have this
http://img11.hostingpics.net/thumbs/mini_793494ffdshow.jpg (http://www.hostingpics.net/viewer.php?id=793494ffdshow.jpg)

file here:http://www.nyaa.eu/?page=torrentinfo&tid=256116

[haruhiko_yamagata]

@alexins
Thanks, I'll get 4.6.2.

@ikarad
Thank you for testing.
[Hiryuu] Maken-Ki! 04 [Hi10P 1280x720 H264] [D6466060].mkv uses \t as well.
The implementation is hard, but planed in the near future.

[Infernodash]

Is it possible to enable the deinterlacing and debanding options in ffdshow raw filter while using lav video decoder? When I play 8 bit files the filters applies, however, it dithers my 10bit files to 8bit. I want the filter to only apply to 8bit files. Is there a way to do that and maintain 10bit playback?

Edit: I am using MPC-HC, MadVR, Haali Splitter, LAV Audio and Video decoders, as well as ffdshow raw filter.

[betaking]

Great :) :) :)

@ betaking - have you read this? ;) :rolleyes:

OK.so i wait 4.6.2 Stable Release now!:D

[Keiyakusha]

Infernodash
no, ffdshow doesn't supports 10bit output so you can't maintain it.
Also ffdshow's deband filter is very crappy and broken, unlikely it will ever support 10bit. Instead someone needs to port new good and shiny solutions from avisynth :P

[ikarad]

@alexins
Thanks, I'll get 4.6.2.

@ikarad
Thank you for testing.
[Hiryuu] Maken-Ki! 04 [Hi10P 1280x720 H264] [D6466060].mkv uses \t as well.
The implementation is hard, but planed in the near future.

Thanks
I find a bug with your version (bug is not present with ffdshow3984)

At 2"20, video crash all the time if subs are selected on in ffdshow
video here: http://www.zshare.net/download/95645287c2805c9b/

[mini-moose]

the current builds of ffdhshow have ffmg-mt migrated into libavcodec. When I use ffdshow as directshowsource for x264 transcoding, the encode speeds are the same, however I noticed
that during first pass if I run other processes (for example eac3to) this slows down the encode speeds considerably which didn't happen with ffmpg-mt. Not sure why it would do that considering 1st pass only uses about 50% of cpu.

[haruhiko_yamagata]

Thanks
I find a bug with your version (bug is not present with ffdshow3984)

At 2"20, video crash all the time if subs are selected on in ffdshow
video here: http://www.zshare.net/download/95645287c2805c9b/
The crash was confirmed. Thank you.

[Infernodash]

Infernodash
no, ffdshow doesn't supports 10bit output so you can't maintain it.
Also ffdshow's deband filter is very crappy and broken, unlikely it will ever support 10bit. Instead someone needs to port new good and shiny solutions from avisynth :P

Thank you for your reply. I'm hoping there will be some new solutions ported over as well.

I will be reading this forum more often so I can stay abreast with all the developments happening. I felt absolutely lost when trying to figure out this problem last night.

[egur]

The standard hardware decoders that copy frames back to system RAM are probably too slow on Intel hardware, too, I think, at least if they use standard Direct3D surface reading. You can get things fast with Intel GPUs only by using specific Intel APIs, at least that was the case last time I checked. So there's a good chance that egur's implementation is (currently) the only one which is really able to do GPU decoding + copying back to system RAM in real time for Intel GPUs. @egur, please correct me if I'm wrong.

The fast GPU->CPU copy is done by using the MOVNTDQA instruction (SSE4.1). Also availble by using the intrinsic _mm_stream_load_si128.
Originally found in VLC's code.
There are two speedup tricks:
1) Source and target page offsets (12 lsb of addresses) should be 2K apart.
2) MSVC compiler uses a maximum of two xmm registers when using the intrinsic function. Some speed is gained by using all 8/16 registers by manually coding in ASM.

Performance is about 2x slower than using memcpy on system memory in SandyBridge.
Vtune showed that more time is spent locking the d3d surface than the actual copy...
Using this copy on older HW or to copy from a discrete GPU will give a significantly worse results as PCIe traffic is involved.
In SNB, memory and L3 cache is shared between the CPU and GPU, making this vopy operation a viable option.

Haven't tested this on Liano, should work well I guess.

It's very easy for me to export DXVA samples instead of simple memory buffers. I'll do it at a later stage.

Also need to submit my ffdshow fixes, hope to get to this done by end of the week.

[madshi]

Sounds quite good, thanks for the useful information!

[CruNcher]

This is current state of SB (GT1) on Aero with newest Driver 2509

Windows 7 x64 Service Pack 1
Intel(R) HD Graphics Family

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: lossy (0-0)

DXVA Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: StretchRect failed

DXVA Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: lossy (0-0)

D3D9 Surface speed test:
NV12: upload 275 fps, download 15 fps, trick download failed
YV12: upload 156 fps, download 20 fps, trick download failed
A8R8G8B8: upload 145 fps, download 7 fps, trick download failed

DXVA Surface speed test:
NV12: upload 302 fps, download 15 fps, trick download failed
YV12: CreateSurface failed
A8R8G8B8: CreateSurface failed

A8R8G8B8 Texture speed test:
default: upload 262 fps, download 143 fps
dynamic: upload 265 fps, download 10 fps, trick download 146 fps

Btw Mirillis Render implementation looks rocking it's damn performant (it's currently one of the lowest resource ones (8 Bit) i saw from the top 4 ISVs (Cyberlink,Corel,Nero,Arcsoft) on Windows only Potplayers Direct3D renderer comes close (still missing Shader PP though), Custom EVR is as heavy as MadVR on minimum) and needs very low resources on both GPU/CPU and also allows its shader PP to be used @ 1080p the same time (very amazing performance optimization using 70-80% of the GPU (Picture2,Detail Boost) compared to others who would overflow it with above 100% utilization (Sharpen Complex 2 @ Fullscreen) :) with Shader PP (Quality is comparable to Sharpen Complex 2 if not even better) it needs as much CPU as MadVR with anything turned down to a minimum (nearest neighbour ect) and GPU usage is still very good even on the highest PP Level (round about 70-80% @ Fullscreen :) (and they even render a very Graphical partly animated UI on top of this without any Performance slowdowns just amazing and Deinterlacing works without any Performance problems as the cream on top)
Though Recording the Players Output via Quick Sync is the most efficient currently with MadVR (from a Custom renderer stand, not EVR) :)

I wonder how much it will impact their Performance once they include 10 Bit Output Rendering though, but so far it looks excellent you don't see such a optimized piece of Software every day (Remembers about the early days of CoreCodec, only that CorePlayer never became reality in the form like Mirillis seems to did it) :) and that this is High optimized Multimedia Software from Poland, not bad (compared to all the Asian ISVs and even OSS like MPC-HC or non OSS private dev MadVR (which still has the stability advantage) ;)

Will be very interesting to see how they will crush Fraps and others with their Low Level knowledge :)

For those who are interested http://www.mediafire.com/download.php?lr93jn6pnut54bg a Quick Sync (Aero,DWM) Recording the Performance Counter update @ 500ms (adds additional stress)

@ Madshi
though this result blows in its own category (stability with the low latency timer running) http://www.mediafire.com/download.php?7uhdibw4i3r2jce :)

[ryrynz]

Infernodash
ffdshow's deband filter is very crappy and broken, unlikely it will ever support 10bit. Instead someone needs to port new good and shiny solutions from avisynth :P

I vote Flash3kyuu_deband.

[Keiyakusha]

I vote Flash3kyuu_deband.

I was thinking about it when I wrote that ^__^

[dimitrik]

Well, what I need are video codecs, that cab work with avi, mkv, etc.

Right now I have a problem with Subtitle Workshop which I can't make to show a video image. That was usually related with video codecs, but I installed ffdshow (32bit) and nothing. I couldn't find a 64 bit version.

To solve your subtitle workshop problem set Directvobsub in the "general->loading" settings from "always load" or "load when needed" to "do not load". The downside is that if you really want to use Directvobsub you need to switch it back on and off.

To find the 64bit ffdshow, try xvidvideo.ru
You can also go to codecguide.com to get the 64 bit k-lite codec pack which includes ffdshow and a couple of other essential tools to control the codecs on your system.

If you need more help, open a new thread though as this diverts from the current topic.

[LigH]

Do you remember in which revision you fixed MPEG-1 aspect ratio signalling?

After possibly years of annoyance with rare but extreme samples, I finally found enough time last weekend to make a bunch of test cases to report an issue (http://forum.gleitz.info/showthread.php?45184-MPEG1-Video-mit-verr%FCckten-Seitenverh%E4ltnissen-im-MPC-HC-via-ffdshow) with really crazy sample aspect ratios in different renderers for rather "exotic" MPEG-1 aspect ratio flags (from about 1:5 to 5:1); then I was told that xvidvideo.ru is active again, updated ffdshow after months ... and it appears to be fine now.

:thanks:

[egur]

As per my discussion with clsid, I've committed my integration work. The DLL's itself is in another SF project (svn:externals).
I merge to to head revision, in advance so the merge was trivial.

Here's the changelog:
Added support for Intel QuickSync Decoder:
* Add 2 files that load and manage the decoder.
* Added external reference to the IntelQuickSyncDecoder project on SF (qsdecoder).
* Changed installer files.
* Added fallback in some cases where the decoder would not init well.

Bug fixes & other changes:
* Fixed H264 SPS header crash.
* Fixed NV12->NV12 crash by not using swscale to perform the copy. Added SSE2 copy function to perform the task.
* Fixed crash when a NULL string was translated.
* Cleanup - removed missing files from projects files - caused unnecessary rebuilds.
* Changed FPS measurement so VFR clips show a more correct frame rate.

BTW, I did compile this build and tested it quite extensively but you should check it anyway.
The code changes to ffdshow's code base are very small.

[Atak_Snajpera]

clsid can you update your build at sourceforge?

[betaking]

@ Midzuki,I have uploaded last ffdshow svn built by msvc2010 and gcc 4.6.2 stable on my site! you can get it!
ps: big thanks for alexins!

[clsid]

Eric, the minimum requirement for ffdshow is MMX. Could you please add fallbacks were appropriate where SSE2/SSE4 is currently used?

[egur]

Eric, the minimum requirement for ffdshow is MMX. Could you please add fallbacks were appropriate where SSE2/SSE4 is currently used?

OK, no problem. Added just SSE2 copy within ffdshow. Can revert to memcpy.
SSE4 is only used within the QuickSync Deocder DLL and it can't be disabled internally (make no sense as this should only be used for SNB and newer CPUs).
What I can do is disable Quicksync altogether if SSE4 is not supported (disable from within ffdshow's code).

Update:
Done. Committed at revision 4032.

[Midzuki]

@ Midzuki,I have uploaded last ffdshow svn built by msvc2010 and gcc 4.6.2 stable on my site! you can get it!
ps: big thanks for alexins!

Many :thanks: for that :)

However don't forget, I am no one important :o ,

it's ikarad who always has the last word on the subject :D

[ikarad]

Many :thanks: for that :)

However don't forget, I am no one important :o ,

it's ikarad who always has the last word on the subject :D

What?

[Midzuki]

What?

http://forum.doom9.org/showthread.php?p=1536401#post1536401

I guess you need more cups of coffee per day ;) :p

[ikarad]

http://forum.doom9.org/showthread.php?p=1536401#post1536401

I guess you need more cups of coffee per day ;) :p

I don't know where is the problem.
I just say haruhiko_yamagata that with this test build, deband doesn't work and that clisd had a similar problem with the compiler.

It's all, no need coffee.

[egur]

OK, no problem. Added just SSE2 copy within ffdshow. Can revert to memcpy.
SSE4 is only used within the QuickSync Deocder DLL and it can't be disabled internally (make no sense as this should only be used for SNB and newer CPUs).
What I can do is disable Quicksync altogether if SSE4 is not supported (disable from within ffdshow's code).

Update:
Done. Committed at revision 4032.

Fix wasn't 100% (disabled QuickSync Decoder). please build revision 4033. Sorry for the mess.

[Midzuki]

I don't know where is the problem.

The problem is, you are seeing problems where they do not exist -.-

If your attention is not big enough to perceive the (very-obvious) reasons why I write what I write, well... -.-

[ikarad]

The problem is, you are seeing problems where they do not exist -.-

If your attention is not big enough to perceive the (very-obvious) reasons why I write what I write, well... -.-

Problem existed.

I don't understand where is your joke. Maybe a custom of your country :confused:

Sorry for my misunderstanding.

[haruhiko_yamagata]

A new build from the branch. (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4037_20111110_branch.exe)

Thanks to alexins, GCC 4.6.2 is used for the build. Deband should work now.

@ikard,
The crash has been fixed. The offending line triggered two other bugs. Three bugs has been fixed.

The build also contains Eric's QuickSync Decoder and ffdshow converters new feature, support for 10bit 420 YCbCr color space input.
Please give some trials on ffdshow converters vs swscale (quality and/or speed). In RGB conversion page, check/uncheck "High quality YV12 to RGB conversion".
Checked: ffdshow converter
Unchecked: swscale
Which do you like?

@Eric,
Great work! My only frustration is that I do not have sandy bridge. I'm not sure my build is working for your part.

[egur]

@Eric,
Great work! My only frustration is that I do not have sandy bridge. I'm not sure my build is working for your part.

Thanks :)
My build is pretty straight forward. No ICL12 option yet (I have a different version of the Intel compiler/composer and this produces a different project setting). Will Add ICL12 project in the near future.

BTW, please keep my decoder out ofthe defaults as it doesn't work in WMC fullscreen (can't create d3d device for surface allocation under fullscreen). This will probably mean a significant design change - postpone initialization till time of actual decode and have FFDShow pass the D3D9 device manager to my decoder... :(

[mandarinka]

This is not about comparing the converter to swscale, but I did some comparing of the HQ software RGB conversion (just with a plain 8-bit source) against the reportedly similar software converter in LAV video. It seems that comparing the outputs, there is some spatial shift of chroma. I took some pictures to illustrate the difference (taken with ffdshow's grab, for LAV video, I had it output rgb32 and set ffdshow to decode raw formats, allowing me to use grab with LAV video too).
Tested versions: ffdshow 4026, LAV video 0.38. (pc used: windows xp sp3 32bit, Athlon 64 cpu.)

http://screenshotcomparison.com/comparison/93625

I think the author of LAV video's converter mentioned some chroma position treatment difference in this post (http://forum.doom9.org/showthread.php?p=1521532#post1521532), there is more discussion of the converter there. In post 5056, Madshi responds on that too...

[haruhiko_yamagata]

Yes, there is some shift of chroma. ffdshow uses bilinear interpolation and chroma is positioned in the center of four luma pixels. 75:25 for both horizontally and vertically.
I know this is not the default of MPEG2, H.264, etc.
H.264 has the flag that defines the position of chroma. If many people want it to be used, I may consider implementing it.
In my opinion, it is hard to see the difference in motion. It may not be very important.

[mandarinka]

I see, thanks for the info.

[ikarad]

A new build from the branch. (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4037_20111110_branch.exe)

Thanks to alexins, GCC 4.6.2 is used for the build. Deband should work now.

@ikard,
The crash has been fixed. The offending line triggered two other bugs. Three bugs has been fixed.

Thanks.
Have you succeed to implement \t ?

[haruhiko_yamagata]

Thanks.
Have you succeed to implement \t ?
Not yet. It will take a month or longer.
I'm implementing scroll/banner. It requires spatial fading, which is taking longer time than expected.

[haruhiko_yamagata]

Eric, the minimum requirement for ffdshow is MMX. Could you please add fallbacks were appropriate where SSE2/SSE4 is currently used?
clsid,
The wiki (http://ffdshow-tryout.sourceforge.net/wiki/faq:builds)says ffdshow supports Pentium Pro. Is MMX required? I agree that it is pointless to support non-MMX CPUs. Should I update the wiki?

Eric,
Any troubles fixing CPU detection? Can I help you?

[clsid]

Yes, MMX is required.

I was thinking of making two builds for next release, one MMX and one SSE, and then continue with just SSE from there.
A good time for a release would be after Eric's work is finished and tested, and maybe (some of) your subtitle improvements have been merged.

Are you using VS2010? If so, the VS2008 projects could be removed as nobody here uses them anymore.

[_xxl]

Please remove old VS2008. How faster is SSE version?

[haruhiko_yamagata]

Then, for generic builds, Pentium II / Athlon are minimum requirement, aren't they?
I have updated the wiki.
And yes, "Pentium III or newer" is a good candidate for the near future release.

I'm using VS2010 trial version. OK, I'll buy one.

[haruhiko_yamagata]

Is anyone using GCC 4.5.x? Can we migrate to GCC 4.6.2?
Is this patch OK?
Index: src/ffmpeg/config.h
===================================================================
--- src/ffmpeg/config.h (revision 4043)
+++ src/ffmpeg/config.h (working copy)
@@ -43,8 +43,8 @@
#define ASMALIGN(ZEROBITS) ".p2align " #ZEROBITS "\n\t"

#if ARCH_X86_64
- #define EXTERN_PREFIX "_"
- #define EXTERN_ASM _
+ #define EXTERN_PREFIX ""
+ #define EXTERN_ASM
#else
#define EXTERN_PREFIX "_"
#define EXTERN_ASM _
Index: src/makefile_c.inc
===================================================================
--- src/makefile_c.inc (revision 4043)
+++ src/makefile_c.inc (working copy)
@@ -12,8 +12,8 @@
TARGET_OS=x86_64-w64-mingw32
CFLAGS+=-DWIN64 -D_WIN64 -D__MINGW64__
OPTFLAGS+=-O2 -m64
- YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64 -DPREFIX
- LDFLAGS+=--entry=_DllMainCRTStartup@12
+ YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64
+ LDFLAGS+=--entry=DllMainCRTStartup@12
else
TARGET_OS=i686-w32-mingw32
CFLAGS+=-DWIN32 -D_WIN32 -D__MINGW32__
@@ -22,7 +22,7 @@
endif

CFLAGS+=-mdll -mthreads -pipe
-OPTFLAGS+=-fno-common -fno-tree-vectorize
+OPTFLAGS+=-fno-common
CPPFLAGS+=-fno-rtti
OUTPUTFLAG=-MMD -o\

@@ -31,8 +31,6 @@
YASMFLAGS+=-g cv8
else
CFLAGS+=-DNDEBUG -UDEBUG
- OPTFLAGS+=-fomit-frame-pointer
- LDFLAGS+=-s
endif

ifeq ($(EXCEPTIONS),1)

[egur]

Yes, MMX is required.

I was thinking of making two builds for next release, one MMX and one SSE, and then continue with just SSE from there.
A good time for a release would be after Eric's work is finished and tested, and maybe (some of) your subtitle improvements have been merged.

Are you using VS2010? If so, the VS2008 projects could be removed as nobody here uses them anymore.

Maybe it's time to drop MMX altogether... It's inferior to SSE2 and I would be very surprised if there are functional platforms that don't have SSE2 - anyway they couldn't play any 720p+ content. I had a P4 system that could barely play 720p (w/o any processing).

My initial integration work is finished and it was tested quite a lot.
I'm aware of some issues:
Will not work under WMC fullscreen because I need to get the D3D device manager from the renderer otherwise I can't allocate surfaces. WMC users will not be able to use the HW acceleration. This will be fixed in a week or two and require some modifications on both my decoder (late initialization) and small ffdshow changes (pass the d3d device manager to the internal decoder so the only usable D3D device in fullscreen exclusive can be used to allocate surfaces). Other players that use full screen playback seem to work fine.

Another thing that needs to be done is the ability (config option) to fail the pin connection if HW acceleration isn't supported and allow another filter to become the decoder. Alternatively, ffdshow will select the default internal decoder. This feature's reasoning is to allow LAV decoder handle 10 bit formats as it outputs 10/16 bits.

Both these changes are not show stoppers for a release.

Oh, I also need to provide an ICL12 project build although it's not critical - can build my DLL with VC2010 like in the VS2010 solution. The ICL build will probably improve nothing so it's a low priority issue.
I would also like to spend a little time on cleaning up the hundreds of warning during ffdshow's build so new issues are quickly caught.

[dann23]

Is it possible to make ffdshow compatible with media foundation? I'm thinking especially at the subtitle part.