Log in

View Full Version : New ffdshow build (?)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72

clsid
30th August 2006, 01:32
rev103 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2546-103_20060830.exe?download)

haruhiko_yamagata
30th August 2006, 10:08
Rev 107

Minor fix : _mm_empty() instead of emms
Minor fix : Use of #if __STDC_VERSION >= 199901L
Bug fix : slow decoder(MPEG4-ASP,etc) : idct_algo
Bug fix : libavcodec : Ignored "Info & debug" CPU setting

Now known bugs of libavcodec decoder have been cleaned.

clsid
30th August 2006, 12:29
Nice work Haruhiko!

rev107 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2546-107_20060830.exe?download)

Egh
30th August 2006, 13:49
Nice work Haruhiko!

rev107 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2546-107_20060830.exe?download)

Your builds are now the best imo.

But is it bug or feature? :P Your installer always puts "Use overlay mixer" and "Allow format ..." into intermediate state, regardless of the previous setting (one is off and one is checked in my case).

Also, just noticed: your installer at least last build now specifically sets libmpeg2 as IDCT (regardless of any previous setting as well). Is it better than auto or Xvid MMX? iirc some time ago XVid idct and Skal's one were considered the best.

devaster
30th August 2006, 13:50
at weekend (maybe) I release a ffdshow with hw idct on gpu
please check : http://sourceforge.net/projects/x264gpu/

Egh
30th August 2006, 13:57
at weekend (maybe) I release a ffdshow with hw idct on gpu
please check : http://sourceforge.net/projects/x264gpu/

I long to try this :) But I'm quite sure it will be slower on older cards compared to pure software? Or does it give better speed difference compared to bicubic resizing?

devaster
30th August 2006, 14:10
i use a autodetect because im using a native cg not a dxva...
100% running on nvidia 6600 ...
for now change only and add some dlls...

videomixer9
30th August 2006, 15:24
Hm, sounds interesting but I wondered a bit about what I read on the CoreAVC thread with the nvidia api needed SSE2, is that true?

Other than that I did my own build again after returning, with old nsis installer:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-sse-rev110.exe?download

devaster
30th August 2006, 15:41
no the CG compiler is not in nvidia api you must downolad full redistributable (http://developer.nvidia.com/object/cg-redistributable-binaries.html)
and a copy a dir for your system from this package . Iwould pack it with ...
and i thing it is for all cpus (in manual isnt restrictions )

clsid
30th August 2006, 15:42
But is it bug or feature? :P Your installer always puts "Use overlay mixer" and "Allow format ..." into intermediate state, regardless of the previous setting (one is off and one is checked in my case).

Also, just noticed: your installer at least last build now specifically sets libmpeg2 as IDCT (regardless of any previous setting as well). Is it better than auto or Xvid MMX? iirc some time ago XVid idct and Skal's one were considered the best.I will update the script to respect the previous settings for those options. Afaik these settings give the highest compatibility with the various players. I once read somewhere that the libmpeg2 IDCT is most compatible. Does anyone have some more info on the difference and pro/cons of the IDCTs?

Egh
30th August 2006, 16:11
I will update the script to respect the previous settings for those options. Afaik these settings give the highest compatibility with the various players. I once read somewhere that the libmpeg2 IDCT is most compatible. Does anyone have some more info on the difference and pro/cons of the IDCTs?

Hmmm... Wonder how can idct be compatible with anything :)
Usually they differ in speed/quality.

As for quality, i dont' see difference between xvid and reference one. For descriptions of various types of IDCT (including couple not present in ffdshow) refer to dgdecode manual.

I think main question here is speed, not quality. If someone is able to run some tests and see if there's any difference, that would be handy.

clsid
30th August 2006, 18:58
DGDecoe Manual APPENDIX B: iDCT Algorithm Notes "The video information inside MPEG files is stored in the frequency domain rather than in the spatial domain (the images we see). That way, the information gets compacted and that compaction can be used to compress (reduce) the amount of information you have to send over the transmission channel. MPEG uses the DCT (Discrete Cosine Transform) to translate spatial information into frequency information. To bring back the spatial information from the MPEG stream you have to apply the iDCT, that is, the Inverse Discrete Cosine Transform, that undoes the DCT that was used during encoding."

"Although MPEG is almost deterministic (given a MPEG stream the output should be identical in all decoders), the standard has a degree of freedom when choosing the iDCT to use. That way, the decoder can be more easily implemented depending on the hardware below it. What the standard requires from the decoder is that the iDCT meets IEEE-1180 specs, or in plain words, that the error from the iDCT doesn't go beyond that the ones pointed out in the IEEE-1180."

Which iDCT you should use depends primarily on what CPU you have and to a lesser degree, on how accurate an iDCT you desire. Most people will not be able to tell the difference in quality between these algorithms but they can be easily observed by combining the AviSynth filters Subtract() and Levels(). All of the available options are IEEE-1180 compliant, except for SSE/MMX (Skal).

Qualitywise: IEEE-1180 Reference > 64-bit Floating Point > Simple MMX (XviD) > Remaining iDCTs.

Speedwise: SSE2/MMX and SSE/MMX (Skal) are usually the fastest. The IEEE-1180 Reference is easily the slowest.
The question becomes how big are the quality/speed differences? If quality difference is insignificant, then the fastest should be used. I guess that is Skal or XviD MMX?

KoD
30th August 2006, 21:01
When the DCT coeffs used by the encoder do not match those used during iDCT by the decoder The MPEG1/2/4 and H.261/2/3 IDCT (http://guru.multimedia.cx/category/dct/).

One more plea for people to use h264 since the coefficients are standardized so all h264 decoders will give bit identical output.

clsid
30th August 2006, 22:16
rev117 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2546-117_20060830.exe?download)

_xxl
30th August 2006, 23:28
sse:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev111-sse.exe?download
sse2:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev111-sse2.exe?download

Egh
31st August 2006, 00:19
DGDecoe Manual APPENDIX B: iDCT Algorithm Notes
The question becomes how big are the quality/speed differences? If quality difference is insignificant, then the fastest should be used. I guess that is Skal or XviD MMX?

Yeah, exactly my thought :)

The question which is still open, though, is what kind of idct is the one from libmpeg2?

As for the fastest one, I'll take a stab and say the one with most advanced CPU optimisation is the fastest :) Does any of those idcts in ffdshow have SSE/SSE2 implementation?

KoD
31st August 2006, 10:08
If it was encoded with xvid, then simply use the idct meant for xvid encodes.

If it was encoded with h264, then don't worry, those idct options are simply ignored and the standardized way of doing idct is used by the decoder.

If it's something else, god knows ! Consider that even the encoder might have not used a proper way of doing DCT, so even if you use the reference iDCT you may get strange artifacts. (which makes me wonder how does the "auto" iDCT option in ffdshow really works - it should choose an iDCT based on the detected encoder info used to make the video stream, but my guess is it simply chooses one of the available implementations based on what mmx/sse instructons sets the cpu has even if they're not appropriate for the video stream they're used on)

Edit later: I found out that milan wrote what those options mean, actually: Libavcodec options (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Miscellaneus+settings). It seems like this option selects a certain implementation to be used by libavcodec. The safest option (and best) should be "auto" (letting libavcodec select a certain idct to be used). It looks like for xvid this auto selection works quite well since xvid code is freely available. For other closed fomats (like divx), the above "god knows what they used" is true so auto selection might work well or not.

Some of the changes made in libavcodec regarding idct can be found here (http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/h263dec.c?view=log).

Any changes in xvid regarding idct are here (http://cvs.xvid.org/cvs/chora/cvs.php/xvidcore/src/dct/idct.h) as well as in the specific extended instructions set folders in that directory.

Egh
31st August 2006, 13:24
If it was encoded with xvid, then simply use the idct meant for xvid encodes.



Actually as I can see XVid idct was done by Skal himself :) And that one also has SSE2 optimisation. But that code was commented out when it was added in 2005 :)

libmpeg2 could be slower, i guess. So XVid or Skal are top candidates right now. Can someone measure the speed difference, if any, in practice with ffdshow?

igor1st
31st August 2006, 17:52
libmpeg2 could be slower, i guess. So XVid or Skal are top candidates right now. Can someone measure the speed difference, if any, in practice with ffdshow?
I have video file (fourcc=divx, bitsream reports divx 4.0) which plays without color artifacts only with libmpeg2 or xvid mmx.

my speed test with ASP:
Athlon XP, libmpeg2 = 199.4 fps
Athlon XP, XviD MMX = 198.3 fps
Pentium-M, libmpeg = 176.7 fps
Pentium-M, XviD MMX = 178.5 fps

KoD
31st August 2006, 18:52
The difference in speed is so small that it doesn't really matter. And current xvid default idct method is the one used by libmpeg2 actually. As I've said, either auto or libmpeg2 should be used. It's not worth gaining 1fps when there are already more than 100 fps but in exchange get color artifacts, is it ?

igor1st
31st August 2006, 19:40
It's not worth gaining 1fps when there are already more than 100 fps but in exchange get color artifacts, is it ?
Exactly. That's why I choose libmpeg2 as default idct for my builds.

videomixer9
31st August 2006, 20:11
rev 119
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev119.exe?download

imo quality on divx6 videos is slightly worse in ffdshow than with the divx decoder (and yes postprocessing is disabled in divx decoder)

Bathrone
1st September 2006, 04:17
Can advise that Vista builds 5536 and 5552 are working happily with build 107 of ffdshow. Will try 119 tonight.

_xxl
1st September 2006, 10:21
Take a look!
http://sourceforge.net/project/stats/detail.php?type=prdownload&group_id=53761&ugn=ffdshow&package_id=48261&release_id=95213&file_id=180315
http://sourceforge.net/project/stats/detail.php?type=prdownload&group_id=53761&ugn=ffdshow&package_id=59355&release_id=274595&file_id=600104
Many people download old versions.

Peuj
1st September 2006, 10:57
Take a look!
http://sourceforge.net/project/stats/detail.php?type=prdownload&group_id=53761&ugn=ffdshow&package_id=48261&release_id=95213&file_id=180315
http://sourceforge.net/project/stats/detail.php?type=prdownload&group_id=53761&ugn=ffdshow&package_id=59355&release_id=274595&file_id=600104
Many people download old versions.

I'm not surprised, it's still the official versions. ;)

LoRd_MuldeR
1st September 2006, 11:42
Take a look!
http://sourceforge.net/project/stats/detail.php?type=prdownload&group_id=53761&ugn=ffdshow&package_id=48261&release_id=95213&file_id=180315
http://sourceforge.net/project/stats/detail.php?type=prdownload&group_id=53761&ugn=ffdshow&package_id=59355&release_id=274595&file_id=600104
Many people download old versions.

Seems to me like the "official" SF site is dead:
http://sourceforge.net/project/showfiles.php?group_id=53761

Last release is October 12, 2004.
Latest "daily build" dates back to 2005 ;)

If they don't want to update their site (at the moment) they should at least support the people that still work on this project!
Why not mark the old builds as "historical" and link to the ffdshow-tryout site ?!

Egh
1st September 2006, 11:56
Seems to me like the "official" SF site is dead:

If they don't want to update their site (at the moment) they should at least support the people that still work on this project!
Why not mark the old builds as "historical" and link to the ffdshow-tryout site ?!

IIRC Milan long time ago offered to take control of the ffdshow homepage. I guess you can still get it if you ask him (though first you'd need to find him:P)

LoRd_MuldeR
1st September 2006, 12:14
though first you'd need to find him :P

hehe :D

Egh
1st September 2006, 14:17
rev121 is already out from VM9 :0 Very high speed indeed :)

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev121.exe?download

Bathrone
1st September 2006, 14:24
Where is the changelog for all these releases?

Eragon4ever
1st September 2006, 14:26
http://svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log

Egh
1st September 2006, 14:38
BTW, from the point of GUI design at least, options for h264 deblocking need to be moved out of Codecs page.

Since we have decoder's option tab, I think it would be better to move those checkboxes here (or better redone them).

toby77jo
1st September 2006, 15:16
http://svn.sourceforge.net/viewvc/ff...yout/?view=log

Revision 122 - Directory Listing
Modified Fri Sep 1 14:02:31 2006 UTC (11 minutes, 8 seconds ago) by h_yamagata

Bug fix of rev 121.

It's nice with a changelog, but where to find the download link to revision 122?

clsid
1st September 2006, 15:22
rev122 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2546-122_20060901.exe?download)

foxyshadis
1st September 2006, 15:26
Changelogs are just internal code, until someone builds them and posts here about them there won't be a download link. :p But most of the time it only means a few hours of waiting until someone does so.

videomixer9
1st September 2006, 17:12
It'd be great if we could also nominate something as a stable release, I put up a new frontpage for the ffdshow tryouts page and don't redirect to the tryouts forums directly anymore, and I'd like to link there at least directly to a stable build people can use.

so the tryouts forums is reachable via http://forum.ffdshow.info/ and the new frontpage that's not the hottest of the hottest stuff but at least something easy at http://ffdshow-tryout.sourceforge.net/ ...

better contributions are always welcome.

Eragon4ever
1st September 2006, 17:21
Nice,
but could you place the revision number in the file name in the future?
And the link to the forum is not woking for me. I get a 404.

videomixer9
1st September 2006, 17:35
sometimes you may hate that the names are case sensitives. fixed the link. and the filename lacks the build number on purpose.

LoRd_MuldeR
1st September 2006, 18:48
and the filename lacks the build number on purpose.

This way you don't now what build you are downloading and it's bad to keep various ffdshow installers on your HDD. So please add build number to download. Thx.

_xxl
1st September 2006, 19:30
Autodetecting best optimizations:
http://prdownloads.sourceforge.net/ffdshow-tryout/FFdshow-Tryouts-20060901-rev122.exe?download
MMX:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev122-mmx.exe?download
SSE:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev122-sse.exe?download
SSE2:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev122-sse2.exe?download

KoD
1st September 2006, 20:25
Wasn't there a consensus a few weeks ago that the best thing is to let ffdshow decide at runtime what optimizations to use and not to force compiling for a specific set of extended instructions ?

Egh
1st September 2006, 21:40
Lol but it seems in the last build from clsid decoding options page is disabled :)

_xxl
1st September 2006, 22:15
Wasn't there a consensus a few weeks ago that the best thing is to let ffdshow decide at runtime what optimizations to use and not to force compiling for a specific set of extended instructions ?
Why not?
SSE & SSE2 versions are compiled by GCC 4.0.3.

Kostarum Rex Persia
1st September 2006, 22:24
What's going on with Video Mixer?

He doesn't make ffdshow builds anymore, or what?

jffulcrum
1st September 2006, 23:26
It`s tricky: VM9 build`s show usage of MMXEXT CPU instructions, but clsid build`s does not. Double tricky: Pentium 3 CPU not support MMXEXT, this is AMD feature, right ? :)

in the last build from clsid decoding options page is disabled
VM9 build too.

foxyshadis
1st September 2006, 23:29
What's going on with Video Mixer?

He doesn't make ffdshow builds anymore, or what?
What, yesterday's build isn't good enough?

LoRd_MuldeR
2nd September 2006, 00:20
@drevil_xxl build:
Thanks for SSE build. Works fine here :D

Zep
2nd September 2006, 05:44
Lol but it seems in the last build from clsid decoding options page is disabled :)


works for me

_xxl
2nd September 2006, 06:08
Waiting for h264 GPU support!
http://www.bit-tech.net/news/2006/01/07/nvidia_decode_h264/
http://www.nvidia.com/page/purevideo_support.html

Reino
2nd September 2006, 10:53
Does anyone know when DVD-support for MPEG-2 in FFDShow will be ready?