ffdshow 2003-01-22

[kilg0r3]

It is out now! Just wanted to make that public AND start a new correctly named ffdshow thread. Let's see wether luck the power be with me :D

[The Link]

I hate to be that stupid, but where did you get that release? I searched the "dffshow thread" for download locations but couldn´t find any working. The latest alpha built on sourceforge is 2003-01-03. :(

Regards,

The Link

[athos]

Sorry, this was my bad. It compiled OK and I had uploaded it to SF and was putting in the changelog and stuff when I decided I should test it. It crashed both WMP6.4 and BSPlayer (which locked the whole system) several times, so I decided to remove the release. Unfortunately I had allready sent out the notifications from SF.

I think milan is in the middle of some work on the colorspace conversions or something, I will try to make a new build in a couple of days. The good news is I was able to compile with VS6 and ICL7, so hopefully the next release wont need any VS7 dlls.

Edit: I will put it on private webspace if you still want to try it: http://athos.web1000.com/ffvfw.html
Direct link: http://athos.web1000.com/ffdshow-20030122.exe

[Suikun]

"We are sorry, but the file you are trying to download is larger than the maximum length permitted under current network conditions. Please try again later when network conditions change. The file you were trying to download was 693661 bytes."

:-/

[SiXXGuNNZ]

I just installed it and it just locks up and I have to end task in task manager, reverted back to the 20021213 build and everything works good again

[CruNcher]

jeah same here 100% Cpu Utilization

edit: it's taken of sf.net i think they fix it :)

[Shayne]

Locks up zoom here too!

[cweb]

I installed this alpha version on a friend's Win95 machine and it did not work at all. I then switched back to the december alpha version, in fact.

[kilg0r3]

locks up mplayers in winxp pro.

[Edit] you can also get it herehere (http://unc.dl.sourceforge.net/sourceforge/ffdshow/) [Edit]

[Bluedan]

I decided to post here though the new version is yet to "come".
It's more related to all the latest versions:
I tried to force YV12 overlay output through ffdshow playing an XVid encoded movie. For this I unchecked YUY2 which at the time being is default colorspace output for both DivX and XVid (though internally computing in YV12 according to MPEG4 specs), right?
Well, nevertheless either using XVid decoder or libavcodec(Xvid decoder unchecked) it still showed YUY2 under info tab!
Sisoft Sandra 2002 reports my NVIDIA TNT2pro to support 9 color space overlays including the above mentionned.
Strange.
The overlay info is correct I think though I don't know of any other programme to crosscheck.
Because sometimes -I have no clue on what it depends- all players fail to initiate fast YUY2 (YV12- I don't know) overlay, instead ffdshow shows slow RGB32 overlay, which I can confirm because of choppy playback (PIII@667MHz).
I wonder why I'm not able to initiate YV12 overlay. I thought it to be a tad faster than YUY2 though less bandwidth.
I'm also aware of NVIDIA being buggy in those things.
Any ideas?

ffdshow 03-01-2003, XVid 15-01-2003, DX8.1, WinXPSP1, Zoom- + bsplayer tested

[kilg0r3]

please ignore this post. when testing ffdshowplayback. i forgot to disable dvdMax of my matrox g400 (which is an extremely cpu hungry function. also YV12 overlay is not supported for this function. (hail to chibi jasmin for thefight in the matrox forum ;))

@Bluedan and others

your post made me look at cpu usage try YV12 output too.

ffdshow 20020103, on my system (win xp pro, athlon xp 1533mhz), uses about 2 times the amount of cpu (ca 50-70%) than the vanilla xvid decoder (20 - 30%) that is linked to the xvid.dll. a divx5 clip with 1024+4xx resolution even took 100% (with the divx decoder its only 65%max). is that normal? No post processing or other options were selected. no difference between 'use xvid' selected or not.

players: zoomplayer, wmp 6.4

put your ideas here ......................

[athos]

Like I said, this latest version _does not work_. That's why I removed it from sourceforge. I posted it here just for those extra-curious who want to play with fire so-to-speak. Perhaps it works on some systems, but it doesnt look that way. milan's changelog states that ffdshow doesnt compile (a few days ago), and later that it is somehow working (at least it compiles). several changelog entries states that he is working on the colorspace conversions, so hopefully this will work soon.

When I am able to compile a build that actually works, I will post it on sourceforge.

[Bluedan]

@Athos

Yeah, I was talking about ffdshow 20030103, too.
Not that unofficial version you put your link to in this thread (20030122)!

@kilgOr3

Did not notice that in 20030103 version use XVid option had no effect. Will check and also with previous ffdshow version from december.

your post made look at cpu usage try YV12 output too.

This is cryptic to me. Say in complete sentence, please.

[kilg0r3]

@ Bluedan

please ignore my post above. for the reason why, see the old now edited post. Sorry for the confusion.

yet, i'd like to raise the adaptive-postprocessing idea again. realvideo PP also works adaptively and adjusts the level of PP according to the quantizer used by the encoder. this seems, for a non-coder(!), relatively easy to implement; at least it'd be easier to implement than my previous poposal , which included a calculation of resolution, bitrate and amount of motion :P

cheers to you and all other fine artisans.

----
just my 666 iraqi dinar

[Bluedan]

Already noticed.
But there's still me questioning about how to force YV12!
I didn't find a way to force it, the last programme I tried was DVobsub with dynamic change option, to no avail.
It simply stays YUY2. :angry:

[Chibi Jasmin]

Originally posted by kilg0r3
please ignore this post. when testing ffdshowplayback. i forgot to disable dvdMax of my matrox g400 (which is an extremely cpu hungry function. also YV12 overlay is not supported for this function. (hail to chibi jasmin for thefight in the matrox forum ;))


I would never disable DVDMax for its great image quality and usability...simply select YUY2 output (only!) in ffdshow (codecs/suppurted output colorspace) and all will be fine!

[kilg0r3]

@chibi

nice to see that you are still here :). in my post, i just wanted to point out that it is not useful to keep dvdmax enabled when benchmarking.

cheers

[drebel]

@ Bluedan
if you have a movie already YV12 encoded (via avisynth 2.5a-vdubmod)you shouldnt have any problems with YV12 output and directx8.x (video rendener)using xvid.ax or ffdshow...But you cant use dx9 (and new vmr9) in yv12 movies without any color conversions yet

regards,
george

[Bluedan]

@drebel
Yeah, but since all MPEG4 videos seem to default to YUY2 (and MPEG2 as well) and being bound to it, though decoding is done in YV12?
I thought there's no big difference in (overlay-)speed between YV12 and YUY2 compared to RGB.
I don't use DX9.

[Boardlord]

Hey all!

Same here, can't force it to yv12. :(
Plus, the 20030122 locks my players too. Does anyone have a compile which has the simple idct and works, so that I could test the new koepi binary(2003-01-24) for smearing with qpel?
If you have could you mail it to steinad@mailbox.hu ?
Thanks!!!

[eagle7]

Hello,

I have some problems with ffdshow. First I install it and when I play a video with any player (windows media player, core media player, bsplayer) the player crash and a there is a message named accompat.txt


I have WindowsXP, the video is a OGM.
I give the message in attach file.
What's the problem, please help me:( :(

[eagle7]

Nothing :( :(

[athos]

which build are you using?

[eagle7]

All since 01.12.02

[athos]

I know the latest one does not work (read above in the thread).. have you tried updating your graphic drivers?

[eagle7]

Now it's ok. I have format the drive and actually it works:confused: :confused:

[kilg0r3]

@athos, milan

normally i am not the nagging kind, currently however i am not able to test xvid quality when qpel is enabled because there is no decoder which can handle it 100%. about when can we expect the next ffdshow release with the working simple idct? even an intermediary compile with many features broken would be nice.

[kastro68]

Are you sure that the problem you are experiencing with qpel is a decoding issue rather than and encoding one? I believe I have the same problem as you and I haven't enable q-pel for quite some time now.

However, I see some people posting their encoding settings and some of them have q-pel enabled.

[athos]

Originally posted by kilg0r3
@athos, milan

normally i am not the nagging kind, currently however i am not able to test xvid quality when qpel is enabled because there is no decoder which can handle it 100%. about when can we expect the next ffdshow release with the working simple idct? even an intermediary compile with many features broken would be nice.

I havent heard from milan for several weeks, except for checking out his entries in the CVS. I try to compile now and then, but since the last alpha the builds have been broken, ie crashes media players. I noticed some interesting entries the last couple of days, something about V2.. Trying to compile right now.

Edit: Todays build wont play either. Maybe I should try without ICL. Maybe I'll try that tomorrow. It seems milan is working on V2:
2003-02-18 17:00 milan_cutka

new macro in nsis 2 script

2003-02-18 16:37 milan_cutka

V1

2003-02-18 15:48 milan_cutka

removed read only checkbox from open file dialogs

2003-02-18 09:51 milan_cutka

V2 cleanup

2003-02-18 09:50 milan_cutka

V1 cleanup

2003-02-18 09:02 milan_cutka

optimized uncompressed YV12 input

2003-02-17 19:19 milan_cutka

xvid stride fix

2003-02-17 19:08 milan_cutka

V2

2003-02-17 18:32 milan_cutka

no message

2003-02-17 18:21 milan_cutka

no message

2003-02-17 18:18 milan_cutka

no message

2003-02-17 17:05 milan_cutka

faster YV12,I420 uncompressed input

2003-02-17 16:30 milan_cutka

moved bswap

2003-02-17 16:24 milan_cutka

updated libavcodec (more encoding code removed)

2003-02-17 15:28 milan_cutka

updated postproc and swscale

2003-02-17 13:59 milan_cutka

updated legal headers, removed 3 from classes names

2003-02-17 13:55 milan_cutka

V1 - stable branch

2003-02-17 13:45 milan_cutka

V1 - stable branch

2003-02-17 13:42 milan_cutka

V1 - stable branch

2003-02-17 13:39 milan_cutka

V1 - stable branch

2003-02-17 06:49 milan_cutka

no message

2003-02-13 14:35 milan_cutka

I'm not sure...

2003-02-12 14:20 milan_cutka

trying to get colorspaces work

2003-02-11 06:40 milan_cutka

no message

2003-02-05 15:02 milan_cutka

no message

2003-02-05 13:39 milan_cutka

better showMV, working on ...

2003-02-05 07:17 milan_cutka

can connect to mpeg2 decoder filters (cyberlink, intervideo),
working on colorspaces

2003-01-29 15:45 milan_cutka

no message

2003-01-28 15:58 milan_cutka

no message

2003-01-27 06:47 milan_cutka

no message

2003-01-24 15:46 milan_cutka

no message

2003-01-23 07:06 milan_cutka

no message

Edit: Still locks players when compiled with Microsoft Compiler.

[kyousuke]

i tried this build ffdshow-20030122 and i don't know why, but like somebody, bsplayer/wmp crashs :/

then, i have a request for ffdshow team !

could you add in ffdshow a selector for switching between overlay mode1/mode2 ? let's me explain :)

is bsplayer, there are a mode1 and a mode2 :
- when i read div4/5/xvid in mode1/2, bsplayer run automatically ffdshow (with high resolution, the decode is sometime slow with my cpu) :/
- when i read very big mpeg/div3 (like 720x480), i prefer to use mode1 without ffdshow cause the decode is really faster than when i use mode2+ffdshow! i don't know why ... when i use overlay mode2+ffshow the decode is too slow and some frames are dropped.

all of this came from hazard. in fact i didn't know my cpu should decode one day an avi in 720x480 fastely (i've an amd k7-550) but i found a way with div3/mpeg !!! perhaps soon i'll be able to do this with ffdshow, i hope !

thanks you to ffdshow team ! you rox ! :)

regards,
kyo

[Bluedan]

@kyousuke

Obviously, you're uncertain about the meaning of mode 1 or 2 in bsplayer.
BTW, I think there's no way to have direct influence on bsplayer from within ffdshow.
In bsplayer mode 1 represents YV12 color space, which means, that bsplayer tries to force YV12 overlay for playback, which is -if your graphic card/ driver do support this correctly !- suitable for older computers with a remarkable lack of "computing powers".
In fact your K7@550MHz isn't a shiny model amongst todays machines anymore, but in conjunction with YV12 there might be a re-gain in decoding performance.
Remember that internally in MPEG4 and thus XVid and DivX video streams color space data is stored in YV12 format. No color space conversion required unless there are some DirectShow Filters in the chain which automatically switch to YUY2 or have been set to do so.
For example VobSub in its default.
Ogg DSF always results in YUY2 overlay, AFAIK, no matter how I set bsplayer overlay mode.
So, I wonder for a long time which instance has the priority in a direct show filter chain to set the overlay mode. Unfortunately, this hasn't been answered to me.

YUY2 can be switched on in bsplayer via mode 2.

The problem with YV12 is that there are issues with proper support via certain graphic card manufactors for some of there products.
Playback is degraded for some, so the preferred output is YUY2.

The higher the resolution of your movies (you don't encode them yourself, do you?) the more you should consider to lower screen resolution and/ or color depth to 16bit. Or deactivate consuming filters in ffdshow like sharpen or the postprocessing itself.
Also b-frame decoding demands extra time.

Hope this clarifies a bit.

[kyousuke]

okidoki !!!! good explanation ;)
i didn't realize that mode1 was in fact yv12, i should have think about this!(i always use avs2.5 yv12 ^^; for my encodes) and yes the mode1 works perfectly on my k7+rivaTNT ! yes yes old machine but very good in yv12 :)

so for the rest, i understand why the preferred output is YUY2, and how to works ffdshow. tks!
it's just too bad that some filters in the chain don't offers the possibily to be switched ... nvidia's drivers and ati's are very good today, ppl should more support the yv12 now in theirs DSF ... perhaps it will come :)

thanks you !

[Aktan]

@Bluedan

/OFFTOPIC

How do you know that Mode 1 is YU12 and Mode 2 is YUY2? I am just wondering where you found this information out.

[Bluedan]

Originally posted by Aktan
@Bluedan
How do you know that Mode 1 is YU12 and Mode 2 is YUY2? I am just wondering where you found this information out.

Well, there are chances that the information is slightly incorrect.
Drebbel pointed out to me (have a look at this thread (http://forum.doom9.org/showthread.php?s=&threadid=44218)) that I should better use a certain graphedit version to determine actual color space overlay instead of ffdshow info which I rely on: during playback open its properties, under info tab you'll find it.

The link for that special graphedit is here (http://www.progdigy.com/).
I admit I didn't give it a try so far.
:rolleyes:

[Blight]

Question for Milan (if he's still here):

When FFDShow is seeking to a new position, do you disable all filtering/postprocessing? I think it may be a nice speed-boost to seeking if all non-essential decoding is disabled during a seek.

[Nic]

To my knowledge mine and milan's filters will only add post-processing after the XviD API returns a valid frame. Once a valid frame is returned then seeking should be over. AFAIK.

Have you noticed a difference then between seeking with post-processing on and off?

Cheers,
-Nic

[Blight]

Nic:
It's near-impossible to benchmark these things, especially on a fast computer. I just wanted to make sure non cycles were spent where it wasn't required.

And... is the XviD API even used when the "use xvid" checkbox is disabled? Frankly, what is more reliable, the checkbox on or off, cause it seems to go either way according to the setting the encoder used.