Log in

View Full Version : ffdshow development


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

Defiler
24th June 2004, 01:29
I lied. Here's another post. :D

Installing ffdshow does not address:
Audio playback (AAC, AC3, Vorbis, etc.)
Matroska support
Ogg Media (OGM) support
Working subtitle support

Furthermore, roughly half of the released ffdshow versions have major incompatibilities with certain popular codecs. Even if ffdshow were the only thing worth installing, there would be a 'market' for pre-tested ffdshow builds.

Furthermore, various of the other components required have semi-complex requirements themselves: VSFilter and Matroska Splitter have different builds for Win9x and WinNT systems, several of these things require the Visual C++ runtimes which most users lack, etc. Also, many users are on dialup, and the DefilerPak (chose the name as a joke, but it caught on. Heh.) is about half the size of all the component installers taken separately.

I'm not claiming that codec packs are amazing works of art.. but deciding on your own that users should know all sorts of technical details before being allowed to watch video just shows that you don't understand the whole market. The tens of thousands of DefilerPak users aren't stupid. They just have better things to do with their time.

Finally, this whole side-conversation started precisely because there ISN'T currently a non-SSE2 build of ffdshow that includes the latest fixes. Currently, this statement is not true: "There will always be general compiles available for those who wish to make codec packs."
However, I'm glad to hear that this will continue to happen. That's all I care about.

I normally try not to talk about codec packs on Doom9. Sorry for doing so accidentally.

Neo Neko
24th June 2004, 04:37
Originally posted by Defiler
I lied. Here's another post. :D

Installing ffdshow does not address:
Audio playback (AAC, AC3, Vorbis, etc.)

Don't be so sure. Some of Athos's recent compiles have offered AC3 and even AAC decoding. And it works.

Originally posted by Defiler
Matroska support
Ogg Media (OGM) support

Granted. But that is not much. And alot of people don't yet use those unfortunatly.

Originally posted by Defiler
Working subtitle support

When did it stop working? Sure VSfilter is better. But it works. ;)

Originally posted by Defiler
Furthermore, roughly half of the released ffdshow versions have major incompatibilities with certain popular codecs.

Really? Which ones. There is a VP3 decoding issue and a huffyuv encoding issue. Anything else? Last I tried it worked fine with all my Xvid and Divx encodes. It decodes Mjpeg and Huffyuv fine as well. And users don't absolutely need the latest greatest ffdshow cvs and test binaries. Honestly the last stable build over at source forge is highly adequate for most people. I can't wait till Milan releases another stable build.

Originally posted by Defiler
Furthermore, various of the other components required have semi-complex requirements themselves: VSFilter and Matroska Splitter have different builds for Win9x and WinNT systems, several of these things require the Visual C++ runtimes which most users lack, etc. Also, many users are on dialup, and the DefilerPak (chose the name as a joke, but it caught on. Heh.) is about half the size of all the component installers taken separately.

That's life. And that is the history of computer software back into time immemorial. And it is NEVER going to change. Personally a user should be able to tell if they are running 9X or NT. I mean the 9X versions say 9X at every boot up. And last I saw all NT versions including NT5.1(XP for the lay people) say NT on boot up. If a user does not know or can not find out that is pretty sad. :P But then again so is thinking IE6 is their OS. And they do that.

Originally posted by Defiler
I'm not claiming that codec packs are amazing works of art.. but deciding on your own that users should know all sorts of technical details before being allowed to watch video just shows that you don't understand the whole market.

I understand the world, and the Microsoft market as you describe it. Where the user should not have to know anything. Look where that has gotten us. :D The average computer user is giving their system over to organised crime for it's own nefarious purposes from mass unsolicited direct mailing to distributed attacts against key internet infrastructure as seen recently. There is not that much in ffdshow that beginners would have to configure. But it is there when they are ready.

Originally posted by Defiler
The tens of thousands of DefilerPak users aren't stupid.

No one said they were. Ignorant is something else. But not always a bad thing. I admit there are times when an all in one pack could be nice. But you just have to live with the fact that many people are jaded and rightly so against codec packs. Having said that nothing I have said here has been about you or yours specifically. Just codec packs in general. They are just an outmoded paradigm.

Originally posted by Defiler
Finally, this whole side-conversation started precisely because there ISN'T currently a non-SSE2 build of ffdshow that includes the latest fixes. Currently, this statement is not true: "There will always be general compiles available for those who wish to make codec packs."

Not true. Compile it yourself. Or ask athos nicely if he will. No one has to do anything special to make vanilla compiles. So rasing a ruckus when someone does do special work is counter productive.

Originally posted by Defiler
I normally try not to talk about codec packs on Doom9. Sorry for doing so accidentally.

No problem. ;)

TripleA
24th June 2004, 07:36
I understand what you're saying, Neo. And in another age I would even have agreed with it. But I now think things should not be so complex. Sure, it would be better if every computer user knew everything about their computer, but they don't. And the way things are headed now, tomorrow's users will know less than today's. But I would still like them to have a pleasant computing experience.

Sure, some CODEC packs cause problems. But that only means, IMHO, that one of the better ones (i.e. Defiler's) should be upgraded to semi-official status. Because, why do you think so few people use Matroska? Certainly it's technically superior to AVI. But to open MKV files, the user needs to install an extra filter just one time on the very first run and it will run for the rest of Windows' life. This very simple act, further complicated by need to install a different filter for each of WinNT & Win9x, is the single biggest hurdle, IMHO, in the way of Matroska's widespread adaptation. If the user only had to double click a single icon to get support for everything, this problem would disappear. Or at least get smaller.

Sure, it would be better if the user knew things and acted on that knowledge. But the choice isn't between the user using CODEC packs and the user acting knowledgeably, it's more like between the user using CODEC packs and the user walking away from you.

I would like to eventually see the light of open source spread to the darkest corner of every last HDD on the planet (i.e. Bill's personal PC ;)). And yet I see users lured away by the glamour of simplicity and ease-of-use. At first, I technically didn't understand the decision: "But it takes away your control of the machine!", I screamed. Then slowly I saw that they never had control of their machines. I had control, and I'm still free to retain it. But to normal users the choice is between being able to use their machines to produce something and spending the day on the phone with tech-support.

This has gotten quite far from ffdshow and I believe it's time to pull the reins a bit: like it or not, ffdshow is one of the highlights of open source. It's expected to be perfect and it's expected to "just work", not only as commercial software does, but even better. I understand Koepi saying "But it's free! And the developer isn't required to cater to the users' every whim", for truly the developer isn't required to do anything. Indeed, free software developers retain the right to walk away at any moment. At the very least, they leave behind a heap of source files so a later developer can take up the banner without having to re-invent too many wheels; and that, IMHO, is much better than what the best closed source software can provide (where's QEMM? Helix's DiscMinder? PCTools? All buried somewhere in Symantec). So, while indeed the developer(s) of ffdshow aren't required to provide perfect software, their software is close enough to perfect that it's expected to be. This is an accolade to be treasured: it's no longer "geeks'" software, it's software for the unwashed masses.

I sincerely hope the distinction I'm trying to make and my message are clear enough, or I'm in for a rough ride ahead ;).

In any case, back to the context of this particular SSE2 build of ffdshow, it indeed is an early development build. Most probably not fit for public consumption, actually. And I'm sure that the code would later have been merged with the one-size-fits-all ffdshow we all love once it got close to final and it was shown that it does indeed work. So perhaps this whole line of conversation is a bit pre-mature. But really, this thread looks from where I'm sitting to be 30 40-post pages long. That's a heck of a lot of posts, and I'm sure a few more wouldn't hurt anyone... ;)

P.S. I know Centrino is the platform, but people see ads for Centrino laptops and Pentium 4 laptops, at least in my part of the world. Can you guess what they assume Centrino to be...? In any case, I was quoting an actual recent question. And I did, indeed, have to pause and think before answering. But, perhaps significantly, I did not bother to correct the mis-conception regarding Centrino...

Edit: Grammar, grammar, fancy grammar.

m0rbidini
24th June 2004, 19:33
Anyone who has done some kind of end-user support on a daily basis about these issues knows that codec packs are evil for end-users. A big percentage of complaints come from users that installed them. ffdshow doesn't usually conflict with nothing. It's the codec packs that do those things, at least most of them.

When I have end-users (when I say end-users I'm referring to those who have little knowlegde about this stuff) asking me how to solve their DivX/XviD playing problems (and most of them don't wanna know about Matroska or OGM, cause most of them don't have these kind of files) I just say:

- remove all codec packs from your system;
- remove all DivX/XviD codecs from your system;
- reboot and make sure they were uninstalled;
- install ffdshow (link to one site that usually has the latest builds);
- install Media Player Classic (even if it's just for testing; some players - not all - complicate this for the end-user);
- (Optional) explain that ffdshow has subtitles support and how to use it;

Normally this solves all their problems.

End-users that need Matroska and/or OGM support can also use MPC (it has splitters for both). If they don't like MPC then I just link them to the latest Matroska Splitter and/or OggDS 0.995, respectively. Etc, etc.

I'm not saying that this is the more correct way of treating this, from a "pedagogic" point of view. This may not be the only solution (I can also recommend installing the XviD and/or DivX's decoders instead of just ffdshow, but I usually prefer this way) 'cause some may prefer DivX/XviD standalone decoders and/or other players. But it's better than just give them a codec pack, 'cause if something doesn't work it's much harder to find the culprit.

Cya

crlorentzen
25th June 2004, 02:44
Originally posted by Andy2222
What cpu u have? Are u sure u have a SSE2 capable cpu? Since for me all works fine in Media Player Classic 6.4.8.2.

Just wanted to make sure you saw it, all pertinant infomation on my computer alwasy been displayed in my SIG, but since you couldn't see it here it is...Intel Pentium 4 Northwood-B 2.66Ghz 533Mhz FSB (133x4, quad pumping you know).(someone please tell me I am not crazy, this chip supports SSE2 right? SiSoft has always said soo)

anyways I just reinstalled the lates SSE2 Compile (ffdshow-20040616_SSE2.exe) and am testing, it seems SPP Deblocking crashed MPC 6.4.2.8 always.
1. All other sections unchecked
2. Set slider to zero
3. Selected SPP Deblocking
4. move slider up one.
5. release
6. MPC Crash

SPP looks terrible too in this build...
ffdshow-20040607a.exe, no problem just very slow on SPP.
ffdshow-20040520-p3.exe, no problem just very slow on SPP.

tested in DivX 5, XviD , MP43, DivX3.11a...all crashed MPC. (ffdshow-20040616_SSE2.exe)

any ideas? Nvidia Driver version 60.85 WHQL certified every other driver completely up to date.

Andy2222
25th June 2004, 03:20
So only SPP deblocking crash your mpc?

Its useless atm anyways, maybe i take a look if i have time. Im about to finish the resizer work and will release a new test version "soon". I made many alignment changes and hopefull i solved all memory crashes this way. I need some more time to finetune the new code for max. performance but in general im happy with the improvements.

The main advantage (except for the better speed) will be the fixed parameter setting wich allows to choose what tap deep in lanczos/bicubic mode u want. U can choose from Lanczos1 over Lanczos4 to Lanczos10 if u want :)

I also changed some default parameters and u can choose a very fast 4 tap bicubic mode wich will look good for most ppl.

crlorentzen
25th June 2004, 22:15
Thanks Andy, just note SPP Deblockling only crashes MPC with the 20040616_SSE2 release.

and I would still like someone to conferm I am not crazy that my CPU has SSE2 Support.

smokeslikeapoet
26th June 2004, 01:35
A P4 has SSE2 support. If you have any question about the capabilites of your CPU any benchmarking or system diag utility should. I use Sisoft's Sandra (http://www.download.com/3000-2086-10264518.html). A nice little freeware app called CPU-Z (http://www.cpuid.com/cpuz.php) will show you your supported instruction sets, too. I have an Athlon 1800+ so I'm going to try the P3 SSE compile.

esby
26th June 2004, 02:11
you could use avs2avi, now DGIndex (dgmpgdec),
and check the help>SIMD menu...

it will show you the list of instruction available for your cpu...

esby

crlorentzen
26th June 2004, 03:13
Originally posted by smokeslikeapoet
A P4 has SSE2 support. If you have any question about the capabilites of your CPU any benchmarking or system diag utility should. I use Sisoft's Sandra (http://www.download.com/3000-2086-10264518.html). A nice little freeware app called CPU-Z (http://www.cpuid.com/cpuz.php) will show you your supported instruction sets, too. I have an Athlon 1800+ so I'm going to try the P3 SSE compile.

tank you...I had used SiSoft and had seen it marked...but I wanted someone else to confirm. I was kindof annoyed about the post asking me what CPU I have when it was in my Sig, just wanted to drive the point home...sorry all for wasting time and being a little mean.

HeadlessCow
26th June 2004, 23:19
Showing signatures is an option. Given the profusion of retarded signatures that people use...it's also a nice option to have turned off :-p

P0l1m0rph1c
27th June 2004, 01:46
Originally posted by esby
you could use avs2avi, now DGIndex (dgmpgdec),
and check the help>SIMD menu...

it will show you the list of instruction available for your cpu...

esby

er... avs2avi != DGIndex. Maybe what you meant was DVD2AVI.

esby
27th June 2004, 06:02
yeah, you are right, i meant dvd2avi :)

esby

Andy2222
27th June 2004, 19:20
Originally posted by smokeslikeapoet
I have an Athlon 1800+ so I'm going to try the P3 SSE compile.

There is no SSE version, ffdshow dont use SSE code only mmx and mmx2 :) but try whatever runs fine for u.

crlorentzen
27th June 2004, 20:42
Originally posted by Andy2222
There is no SSE version, ffdshow dont use SSE code only mmx and mmx2 :) but try whatever runs fine for u.

Andy, I think someone else has done p3 compiles. Maybe it is not SSE...but they are marked as p3,and since p3 supports MMX, MMX2, and SSE...maybe he made some changes to make use of SSE.

EDIT: http://athos.leffe.dnsalias.com/ (Athos apparently compiles what he brands as p3) http://athos.leffe.dnsalias.com/ffdshow-20040520-p3.exe for instance

Andy2222
27th June 2004, 23:38
ah u refer to Athos P3 versions, yes he did release a "/G6" or so calles "P3" compiled version. There are no special changes for sse or P3 the compiler just "try" to shedule some instructions better for P3 compatible cpu's. If it runs faster for u use it :)

athos
28th June 2004, 18:07
I also used /QxK, which supposedly uses P3-specific instructions. Dont expect any real world differences though.

SeeMoreDigital
28th June 2004, 18:49
Nice to see you back athos :D


Cheers

jerry07
29th June 2004, 05:22
there are the latest no sse and sse1 version at this japan website
http://www.h7.dion.ne.jp/~moroheiy/

Tommy Carrot
29th June 2004, 11:50
Originally posted by jerry07
there are the latest no sse and sse1 version at this japan website
http://www.h7.dion.ne.jp/~moroheiy/

Damn, finally a new build, and i cannot use it cuz it doesn't appear in the virtualdub (apparently the "installer doesn't like win98" issue). :mad:

Andy2222
29th June 2004, 12:28
Originally posted by Tommy Carrot
Damn, finally a new build, and i cannot use it cuz it doesn't appear in the virtualdub (apparently the "installer doesn't like win98" issue). :mad:

Its nice to see some1 else is also compiling fresh versions, but i dont know why they label it SSE and SSE2 since there are no code changes compared to the normal MMX/MMX2 compile. Those are prolly G6 (P3) and /G7 (P4) compiles, wich wont make any diff. at all.

The problem is that those versions are also fully Visual Studio compiles wich disable all the gcc inline asm, in fact if u use the resizer the code is 1000% slower wich also apply to the postprocessor and other mplayer routines.

The best would be that Athos release a new build? I still have some tests to run before i can release a new version.

Lobuz
29th June 2004, 13:51
@athos
Just remember that ffdshow-20040520-p3.exe was corrupting some of video while decoding. I think that was qpel+Bframes or qpel+GMC(I can't test now cause my AthlonXP is fried). So it's advisable to use some optimisations with caution.

Regards
Lobuz

athos
29th June 2004, 13:54
New build. i686 target, install path patch, OM patch, skals mpeg4.
Download and changelog, see my sig.

Defiler
29th June 2004, 15:40
Originally posted by athos
New build. i686 target, install path patch, OM patch, skals mpeg4.Excellent. Thank you.

ViCroié
30th June 2004, 18:26
WHOAAAA, great new accurate deblocking :D

it's GREAT!

Thx allot :thanks:

Andy2222
1st July 2004, 05:09
also new SSE2 build

here are some additional hits to the new version

Hint:
The Parameter setting in the resizer tab direct influence the filter/tap deep and wich internal routines are used.
For Lanczos the parameter choose the mode/tap deep
(3 = lancsoz3, 4 = lancsoz4, 5 = lancsoz5 ...)

Speed tips:
1: use a filter (level/denoise...) before u resize to force max. performance
2: The new default Bicubic setting is a special tuned setting, for best performance dont change the parameter.

3: Dont go higher than 4 aka Lanczos4, or slower internal routines are used.
4: in Bicubic mode dont set Luma sharpen higher than 1.60 or slower routines are used.
in lanczos3 mode dont set Luma sharpen higher than 0.62/0.82 or slower routines are used.
in lanczos4 mode dont set Luma sharpen higher than 1.20 or slower routines are used.

5: avoid using Chroma sharpen, if u do dont go over 1.20 or slower routines are used.
6: always try to output YV12 colorspace at the output pane
7: Spline & Sinc use slower, lesser optimized routines so avoid those modes.

So mainly use bicubic with the new "default" setting and only Luma sharpen (0-1.6).
Lanczos3 and Lanczos4 are also well optimized, but anything higher is not, like Lanczos with parameter higher than 4 or Spline/Sinc, avoid those modes.

PS: bugs/crashes ... per private message pls. Also gimme some feedback on the resizer speed on P4 since i could not test the code on a P4.

masken
1st July 2004, 13:22
Is there any chance of improving the installer so that it supports silent installs? (/Silent switch for example).

...and perhaps also return an errorcode upon failure.

Perhaps also some additinal switches, like:
/DisplayProgress
/PostProcessing:[0-6]
/AutomaticQualityControl
...etc.

Or alternatively, the HKLM keys explained so one could just import values silently after an install to set the preferences.

Blight
1st July 2004, 21:06
Nice work andy.

Any chance that the Frame Rate Doublers could be detached from the deinterlacers? There are a few cases you would want both at the same time.

And something completely inventive... How about removing all the categories and making the whole thing object oriented, so you can simply add a "resize" object, then another effect and another resize, etc... So you can create a customized effect queue with multiple effects of the same category.

Andy2222
1st July 2004, 21:22
Originally posted by Blight
Nice work andy.

Any chance that the Frame Rate Doublers could be detached from the deinterlacers? There are a few cases you would want both at the same time.

And something completely inventive... How about removing all the categories and making the whole thing object oriented, so you can simply add a "resize" object, then another effect and another resize, etc... So you can create a customized effect queue with multiple effects of the same category.

um, i understand what u mean, but thats work milan need do. I feel more comfortable in the inner core :) aka asm code. I realy like to shake my head around how i can fit datas in registers or what instruction to use and to reoder stuff.
I dont have this much expierence with big object oriented projects, so i will stick with little optimisations and bugfixes and let Milan do the big math :)
My next big goal is a working 64bit version. I like the challenge and i bet this will a funny thing to do and i can learn lotsa stuff :)

athos
2nd July 2004, 01:29
Blight, I think that's is a really cool and useful idea! Perhaps the best way to implement it would be a new project which takes ideas and code from ffdshow/ffmpeg/mplayer etc? Because I think it would be too much of a rewrite of ffdshow, it might just be easier to start over. But it is an exciting idea.

LoopDeMack
2nd July 2004, 07:33
Bug in new ffdshow or ????
In some xvid movies I got only gray picture, in my collection I found 7 xvids not compatible with latest ffdshow-20040616_SSE2, I tried with ffdshow-20040701_SSE2 and its same ,if I try to use xvid trough ffdshow instead of libvacodec its fine or if I use some older version of ffdshow.
P4,2.8c/win200pro/Nvidia5600/Starstorm detonators 56.72/

pankov
2nd July 2004, 09:46
@Athos & Andy
Guys, can you make a non SSE2 build that will include this very needed bugfix and a usefull feature?
2004-07-01 Andy2222 (ffdshow-20040701_SSE2.exe)
...
* fixed "green" shift resize bug
* new default Bicubic Parameter, wich force a faster internal routine (only with the new default parameter)
...

I don't know why but this "green" problem is veeeery visible on my TV and it kills the pleasure of watching movies

Andy2222
2nd July 2004, 14:11
Originally posted by LoopDeMack
Bug in new ffdshow or ????
In some xvid movies I got only gray picture, in my collection I found 7 xvids not compatible with latest ffdshow-20040616_SSE2, I tried with ffdshow-20040701_SSE2 and its same ,if I try to use xvid trough ffdshow instead of libvacodec its fine or if I use some older version of ffdshow.
P4,2.8c/win200pro/Nvidia5600/Starstorm detonators 56.72/

small fix pls test if this fix your problem

changelog:

2004-07-02 Andy2222 (ffdshow-20040701a_SSE2.exe)

* more robust/compatible compiling options for libavcodec.dll & mplayer.dll

2004-07-01 milan_cutka

* logoaway processes chroma planes
* MSS2 support in VFW

bond
2nd July 2004, 18:46
the problems with cabac have been fixed in the ffmpeg h.264 decoder and it should be stable to use now. time for updating libav used in ffdshow :)

LoopDeMack
2nd July 2004, 19:34
Originally posted by Andy2222
small fix pls test if this fix your problem

changelog:

2004-07-02 Andy2222 (ffdshow-20040701a_SSE2.exe)

* more robust/compatible compiling options for libavcodec.dll & mplayer.dll

2004-07-01 milan_cutka

* logoaway processes chroma planes
* MSS2 support in VFW

Now, its ok.

See you, m8y.

Andy2222
3rd July 2004, 02:41
Originally posted by bond
the problems with cabac have been fixed in the ffmpeg h.264 decoder and it should be stable to use now. time for updating libav used in ffdshow :)

Milan is a fast devil :)

here is your fixed version

2004-07-03 milan_cutka (ffdshow-20040701b_SSE2.exe)

* updated libavcodec - h.264 decoding fix,
* support for AVC1 FOURCC - official FOURCC for mpeg4 avc video

Tyrael911
3rd July 2004, 08:26
have u guys stopped releasing p3 optimized versions?
the last one is from 05-20 and it crashes on some xvid movies, as Lobuz said before...

dahlgren
4th July 2004, 10:38
maybe stupid question or it doesn'r belong here, but:

how can i use pan & scan with zoomplayer+ffdshow?

bond
4th July 2004, 11:23
Originally posted by Andy2222
2004-07-03 milan_cutka (ffdshow-20040701b_SSE2.exe)

* updated libavcodec - h.264 decoding fix,
* support for AVC1 FOURCC - official FOURCC for mpeg4 avc video hm it crashes here in ffdshow.ax, no matter what content i try to decode with it :(

Andy2222
4th July 2004, 15:34
mhh what CPU u have and does it also crash on simple divx5 or xvid if u try use libavcodec? Can u test if u can use the normal xvid decoder and ffdshow as raw filter without crash?

...this is realy bs, why i never get those crashes while others do. Its frustrating to hunt bugs/compiler errors if u dont get them :(

bond
4th July 2004, 15:35
i have a pentium3 with 866mhz

it already crashes if i only try to place it in the graph by selecting it via the filter list in graphedit :(

Andy2222
4th July 2004, 15:45
oki my fault i still havnt added code to detect the CPU features in the installer, to prevent the install on wrong systems. The problem is your pentium3 has no SS2 and so it crashes. The versions with ".._SSE2.exe" only run on AMD64, Pentium4 and PentiumM CPU's.

sorry

hellfred
4th July 2004, 23:52
So much to the discussion whether a DAU / normal computer user should know what extensions are supported by his CPU. :D

Sorry Bond, did not want to hurt you. But it fitted so splendit to the discussion that was going on here some pages ahead of this message.

iradic
5th July 2004, 00:06
MMX -> Pentium MMX, Pentium II, K6, K6II, K6III and later
iSSE -> Pentium III, all Duron (called 3DNow extension), all Athlon (called 3DNow extension)
SSE -> Pentium III, Duron (core Morgan), Athlon XP and later
SSE2 -> PIV

taken from: Dust- a noise remover (http://forum.doom9.org/showthread.php?s=&threadid=42749&perpage=20&highlight=loadpluginex.dll&pagenumber=5) thread...

dragongodz
5th July 2004, 12:00
i still havnt added code to detect the CPU features in the installer
So much to the discussion whether a DAU / normal computer user should know what extensions are supported by his CPU.
a user should know what cpu they have atleast so just have that selectable from the installer.

Nikse555
5th July 2004, 12:11
A MMX version would be nice... plz

I have an VIA C3 933 Mhz processor (equal to p2 ~550mhz) with MMX/3DNow!

thop
7th July 2004, 20:03
Originally posted by pankov
@Athos & Andy
Guys, can you make a non SSE2 build that will include this very needed bugfix and a usefull feature?
2004-07-01 Andy2222 (ffdshow-20040701_SSE2.exe)
...
* fixed "green" shift resize bug
...

I don't know why but this "green" problem is veeeery visible on my TV and it kills the pleasure of watching movies
I second that request.

Andy2222
7th July 2004, 21:33
It isnt this easy since i use a little diff. code compared to the mmx2 version. I did not realy "fix" the bug, its more like i noticed that my version seems to not have those bugs. I can try if i find whats wrong, but i did not planed to rework the org. mmx2 code.

pankov
7th July 2004, 21:40
Andy,
pleaaaaase do it - the green fix is really important for me.
I'm gona puke of all this green stuff - since I've noticed it I can't watch a single movie with pleasure
:(

SMF007
8th July 2004, 22:57
I just noticed something about the audio filter. The resampler only downsamples (as it's clearly named). I know upsampling doesn't increase the audio quality, but I was trying to use ffdshow to resample PCM streams for AC3filter to re-encode. I was just thinking that if it's doing resampling already, why could it not upsample too?

Any thoughts on upsampling of audio?