ffdshow tryouts project: Discussion & Development [Archive] - Page 33

haruhiko_yamagata

6th July 2007, 22:42

Worked fine here under XP x64, both in VDub and graphedit. No idea about Vista. Didn't include any MSVC runtime files though, which would I guess be a problem if your system doesn't have them.
Thanks, probably that's it.

thuan

7th July 2007, 00:56

Rev. 1329 and later has the new OSD/sub patch from Haruhiko-san included right? Just want to make sure.

celtic_druid

7th July 2007, 05:01

I used MSVC for everything since in the past I have had problems with x64 builds and ICL. Probably work my way back to ICL seeing what files can be compiled with it without issues. Previously I am not sure I ever got ffdshow.ax running stable even without opt flags set. Still that would have been ICL9, not 10.

_xxl

7th July 2007, 07:50

Is this build working?
http://rapidshare.com/files/41487492/ffdshow_rev1335_20070706_x64.exe.html

SBeaver

7th July 2007, 16:22

Is this build working?
http://rapidshare.com/files/41487492/ffdshow_rev1335_20070706_x64.exe.html

This one works. most things play in graphedit x64. (running vista x64)

deets

7th July 2007, 16:47

Is this build working?
http://rapidshare.com/files/41487492/ffdshow_rev1335_20070706_x64.exe.html

some good and bad news :) it works fine, loads up the config screens without any issues etc. so thats good.

the problem is that h.264 playback is very jerky, maybe 2-3fps and is totally out of sync with the audio.

If i go back to using the 32bit version in mpc rev1328 plays just fine without any noticeable jerky playback. of course no digital out though :P

thanks for your work though :) and its good to know ffdshow audio passes through the digital to spdif in 64 bit mode.

so the only issue is getting the h.264 playback upto standard of the 32 bit version

celtic_druid

7th July 2007, 16:55

I tested H.264 playback with a 720p source and it played ok here with my build. For better performance you would need a x86_64-pc-mingw32 compile of libavcodec though.

SBeaver

7th July 2007, 16:58

I had some h264 decoding issues too but I get blocking instead, framerate seems ok but there is a lot of blocking that I don't get when using 32bit versions. Blocking mostly at the edges and it seemed like color levels changed suddenly in the middle of playback making it brighter or darker.

_xxl

7th July 2007, 17:01

Where can I find x86_64-pc-mingw32?

celtic_druid

7th July 2007, 17:14

gcc 4.3 offers a x86_64-pc-mingw32 target as does binutils, however I don't know how usable it is currently.

TheShadowRunner

7th July 2007, 18:59

the download to ffdshow_rev1334_20070706_clsid.exe on sourceforge seem to be broken (on all mirrors too)

deets

7th July 2007, 19:13

ok some more testing :)

720p seems go out of syn very slowly and 1080p start off out of sync. cpu isnt being topped out or anything.

thanks for all your work on this, im sure as more people switch to vista64 for media playback, more would need this :)

also, i had a quick test and messing about with the colorspace seemed to speed things along a little bit more, although i havent had a chance to test this, i think the nv one was the least out of sync?

skystrife

7th July 2007, 21:45

These things are probably already known, but whatever:

High quality YV12 to RGB conversion is broken in x64 builds. It doesn't crash the player, but the video is really discolored.

DeBand is broken in x64 builds. It doesn't crash the player, but the video turns into static.

I'm sure there are other things, but those I use often.

foxyshadis

7th July 2007, 21:54

If you have a dual core, then 50% is "topped out" for a single thread. ffdshow's not entirely single-threaded, but the decoding part is (it's the most cpu intensive if you aren't filtering). Do you have skip deblocking and drop frames when behind on?

zambelli

8th July 2007, 04:21

Speaking of multithreading... How comes "Queue output samples" still isn't the default option for all apps? Allegedly it improves performance even on single procs.

SealTooGreat

8th July 2007, 06:48

ffdshow_rev1340 can't recognize specific subtitle letters, although the Charset is selected as Easteurope.
rev1280 works fine.

haruhiko_yamagata

8th July 2007, 13:58

Rev. 1329 and later has the new OSD/sub patch from Haruhiko-san included right? Just want to make sure.Yes, rev 1329(1330) or later have the patch.

haruhiko_yamagata

8th July 2007, 14:02

Speaking of multithreading... How comes "Queue output samples" still isn't the default option for all apps? Allegedly it improves performance even on single procs.
It still have compatibility issue on some (ATI's) GPU.

haruhiko_yamagata

8th July 2007, 14:12

ffdshow_rev1340 can't recognize specific subtitle letters, although the Charset is selected as Easteurope.
rev1280 works fine.
Thanks, I'll commit the fix tomorrow.

haruhiko_yamagata

8th July 2007, 14:52

deets

8th July 2007, 21:04

thanks for all your input :)

i can now watch 1280x720p without the audio going out of sync.

I have "skip deblocking always" ticked and have "queue output samples" ticked and drop frames on delay set to 1500.

would you guys mind if i hosted this 64 bit version on my site and linked to it in my blog.

also, im sure this has been asked about lots, but would it be too time consuming to make ffdshow and its h.264 support multi threaded? and any chance of a 64 bit version of mpc so we could quit using wmp11.

i ask a lot, but i hope it dont appear greedy and im genuinely very grateful for all you guys work on this :)

clsid

8th July 2007, 21:35

The 32-bit version of MPC works perfectly fine on 64-bit Windows. Also the 32-bit ffdshow is faster than the 64-bit ffdshow.

The only reason I see to use 64-bit ffdshow is for 64-bit Media Center.

deets

8th July 2007, 21:38

64 bit vista has the digital audio output locked to 64 bit applications, hence the request :) and 64 bit media players need a 64 bit codec to work.

i would gladly go back to using 32 bit mpc and ffdshow if i could get digital out put :(

SBeaver

8th July 2007, 21:39

The 32-bit version of MPC works perfectly fine on 64-bit Windows. Also the 32-bit ffdshow is faster than the 64-bit ffdshow.

The only reason I see to use 64-bit ffdshow is for 64-bit Media Center.

Yeah that, and for everyone running vista who wants SPDIF passthrough.

edit: never mind... ^^

foxyshadis

9th July 2007, 01:35

would you guys mind if i hosted this 64 bit version on my site and linked to it in my blog.
You can, but it'll probably be out of date very quickly. Which reminds me: clsid & drevil, how about adding a Nightly Builds for x64 files target? (Even though it won't get updated as often as the others.) Or do you prefer upping the files to the existing slots instead?

also, im sure this has been asked about lots, but would it be too time consuming to make ffdshow and its h.264 support multi threaded?
Not really something any of us can control. :( You can ask the ffmpeg guys, but I'm sure they've heard it many times by now, and need an expert or a sponsor to get the work done.

and any chance of a 64 bit version of mpc so we could quit using wmp11.
Better to ask Casimir - see the new MPC builds thread in the players forum.

Delerue

9th July 2007, 14:25

I noticed that 'kernel bob' deinterlacing makes the sound get out of sync after some time with some interlaced videos. I tested with a MPEG2 DVD disc. I set 'threshold' to '0', and leave all the other options disable. The CPU usage is far (less) from 10%. Any ideas?

P.S.: other deinterlacing methods, like '5-tap lowpass', work fine.

Please, can anyone confirm this?

deets

9th July 2007, 16:56

You can, but it'll probably be out of date very quickly. Which reminds me: clsid & drevil, how about adding a Nightly Builds for x64 files target? (Even though it won't get updated as often as the others.) Or do you prefer upping the files to the existing slots instead?

Not really something any of us can control. :( You can ask the ffmpeg guys, but I'm sure they've heard it many times by now, and need an expert or a sponsor to get the work done.

Better to ask Casimir - see the new MPC builds thread in the players forum.

ah ok, i think ill link to a version just for now as im sure there are plenty of vista 64 users who are having the same issues. once (if) you guys update a 64 bit version often, ill just link to that :)

ill go harass casimir (joke!) and see what he says :D

thanks for all your help :)

_xxl

9th July 2007, 18:01

64 bit vista has the digital audio output locked to 64 bit applications, hence the request and 64 bit media players need a 64 bit codec to work.
Just curious why are you using x64?
http://www.dslreports.com/forum/remark,17772982~start=0

celtic_druid

9th July 2007, 18:16

Maybe they have 2 8800GTX's and want to use more than 2.5GB's of RAM?

Imagine if everyone decided not to use 64bit OS's because of compatibility problems. The more people use 64bit OS's, the less compatibility problems there will be because the more resources will go into solving them.

deets

9th July 2007, 18:33

Just curious why are you using x64?
http://www.dslreports.com/forum/remark,17772982~start=0

in my case, i was building up a secondary PC and I had to get a new OS, my choices were either xp (again) or vista 32 or 64. As vista was not much more than XP I decided to go with that.

after looking into things, I found I had all the drivers I would need for vista 64 so decided to go for that as my cpu is 64 bit as well :p

i of course was not aware of the 64 bit lock down for spdif or even that my rpc1 patched DVD drive wouldnt work (although this is true of 32/64 vista)

but the true 64 bit apps i use, such as wmp11 and bon echo (firefox) appear a little faster than the 32 bit version on both vista and xp.

If i can get an ffdshow copy upto its 32bit speed or a 64 bit version of coreavc, then in my setup everything would be good :)

im sure more and more will go vista 64 so once these small issues are sorted, all will be cool!

Zach

10th July 2007, 00:45

I asked this yesterday in the Newbies forum (link (http://forum.doom9.org/showthread.php?t=127799)), but in hindsight, I should have asked this here. (But I didn't even know about this thread! :o) Well, this is actually a different question, so this isn't really a cross-post.

If I install the CCCP (http://www.cccp-project.net/), since that is rarely updated, will I break it if afterwards I install the latest ffdshow package from this thread?

In addition, in another thread, I read the Vista Codec pack is updated every couple of weeks. Until the CCCP, I've always shied away from codec packs, but should I reconsider and just abandon the CCCP just install (and subsequently update) the Vista Codec packs?

Cryptum

10th July 2007, 00:56

You can test CCCP beta version ;)
-> http://www.cccp-project.net/beta/

The latest has normaly ffdshow beta3 (or at least a recent tryouts version)

Da Cryptum

Ryokurin

10th July 2007, 01:57

In addition, in another thread, I read the Vista Codec pack is updated every couple of weeks. Until the CCCP, I've always shied away from codec packs, but should I reconsider and just abandon the CCCP just install (and subsequently update) the Vista Codec packs?

If you keep up with what they are changing, typically they are updating the FFDshow in the Vista Codec pack to a newer tryout version, or fixing some bug. Frankly using any codec pack can potentially be bad news and most people here will say to install what you want manually, but for the most part Vista Codec pack is ok.

check

10th July 2007, 10:25

CCCP is a 32bit codec pack that includes its own build of ffdshow, heavily based on tryouts patches (there are only a few differences now). There is no need ever to install multiple ffdshow versions, just pick one to install and don't install duplicates.

If you want to use official tryouts builds instead of the CCCP's, just do not install CCCP's ffdshow.

As for Vista Codec Pack, there should be no reason to need both this and CCCP installed.

haruhiko_yamagata

10th July 2007, 10:40

If CCCP (or anybody) is planing to release a build based on beta3, I would like to recommend to patch by rev 1340,1342 and if possible rev 1331.

Maybe that's what we should do as beta3a.

SBeaver

10th July 2007, 10:45

I had to install vista codec pack x64 to get splitters/demuxers for mkv and other containers to work in WMP.
I don't use their ffdshow x64 build becase it's so old.
haalis media splitter doesn't seem to work at all with x64 players.

One thing relevant to this thread that I'd like to mention:
When you have two ffdshow builds installed at the same time (one 32bit and one 64bit), they seem to share the settings so if I turn on a filter or change some setting in x64 this affects x86 too.
So you might want to keep that in mind in the future builds, maybe you could let them have separate settings.

Perhaps it would be feasible to make a hybrid build that works as x64 but can fall back to 32bit when used in 32bit players. (MS must have something like this since their codecs seem to work for both).
An easier way might be to stay 32bit but to implement some kind of workaround for the spdif output, sending it on to a x64 app so that you can still get passthrough on 32bit players.

Has anyone considered this or is that up to ffmpegs' team to worry about?

_xxl

10th July 2007, 11:18

When you have two ffdshow builds installed at the same time...
You shouldn't.
SVN is down.

celtic_druid

10th July 2007, 11:20

SBeaver

10th July 2007, 12:01

Last I checked all the splitters, etc. installed by the Vista x64 pack were just my guliverkli builds from some time back, which you can still download as separate *.ax files and register.

Personally I think that the settings should stay shared, although it wouldn't be hard to add a suffix like 64 to the registry key. I think the next ffdshow build I do will be an x64 installer that installs 64bit and 32bit builds. Better to install two matching builds at the same time I think.

What happens with S/PDIF output with say mplayer?

Sounds like a good idea. I don't really mind shared settings either, but when one thing works for 32bit but not for 64bit then you get into all sorts of trouble and have to change settings between every file you want to play.
But as you said, if you match the two builds there should be a lot less such issues, maybe it wont matter at all.

Zach

10th July 2007, 12:32

If you want to use official tryouts builds instead of the CCCP's, just do not install CCCP's ffdshow.
heh... it's usually the simplest and most obvious solutions that allude me sometimes. :)

As for Vista Codec Pack, there should be no reason to need both this and CCCP installed.
No, of course not.

I had to install vista codec pack x64 to get splitters/demuxers for mkv and other containers to work in WMP.
I don't use their ffdshow x64 build becase it's so old.
haalis media splitter doesn't seem to work at all with x64 players.
Are you talking about on the default 32-bit WMP11?

When I had Vista64 installed a few weeks ago (before I went back to XP briefly), I installed nVidia's mpeg codec, DivX, xvid, ac3filter, and then the current CCCP (all in that order), and I had no problems decoding anything: mpg, divx, xvid, mkv, and even ogm, though ogm was a surprise--I wasn't expecting that!

Now if you are talking about the 64-bit WMP11, well, I never bothered even running that except maybe once, so I don't know.

SBeaver

10th July 2007, 12:36

yes that was regarding wmp x64

_xxl

10th July 2007, 13:46

http://www.ffdshow.info/ domain name for sale?
http://i14.tinypic.com/6c7wh1t.jpg

Liisachan

10th July 2007, 14:14

maybe the domain was expired and has been "squatted" (or "camped") by a money-mad registerer. I'd say ignoring is the best strategy.

haruhiko_yamagata

10th July 2007, 14:35

I noticed that 'kernel bob' deinterlacing makes the sound get out of sync after some time with some interlaced videos. I tested with a MPEG2 DVD disc. I set 'threshold' to '0', and leave all the other options disable. The CPU usage is far from 10%. Any ideas?

P.S.: other deinterlacing methods, like '5-tap lowpass', work fine.
I can't reproduce. Do you have any sample that you can send to us?

clsid

10th July 2007, 17:11

@all

SVN has been relocated to "ffdshow-tryout.svn.sourceforge.net"

bob0r

11th July 2007, 08:14

Too lazy to read back, not sure if explained at all:
ffdshow_rev1348_20070710_clsid.exe size (Bytes): 4072905
ffdshow_rev1349_20070710_xxl.exe size (Bytes): 3764984
Why is there such difference in size again? (both are generic builds)

_xxl

11th July 2007, 08:52

My build is only ansi.Clsid build is ansi + unicode.

thuan

11th July 2007, 10:21

Look like maybe MS or Intel mess up. After I install this http://support.microsoft.com/?kbid=936357 I use a Core2Duo on XPSP2 up to date. Playing certain h264 file ([AniYoshi]_School_Days_-_01_(h264)_[02F5F33E].mkv) with ffdshow_rev1334_20070706_clsid_sse_icl9.exe result in a access violation.
ZoomPlayler pop up a message box: Access violation 035C1A12 in module 'ffdshow.ax'. Read of address 02687003.
Before I've played that file fine. I'll uninstall the hotfix and report later.

Report: Sorry not the hotfix problem. It's the bug where certain h264 file will make ffdshow crash if ffdshow.ax compiled with icl9 again. Previously, I have played other files before that file so it plays ok.