New ffdshow build (?)

[Peuj]

The fact that the following MOV[SVQ3+AAC] crashes...is this FFDShow to blame or the MP4 Splitter?

link: http://www.a-film.nl/film/trailer/00000397_quicktime_HOOG.mov

Same issue for me with the latest ffdshow version.

[clsid]

You can drag the slider with your mouse.

[_xxl]

ffdshow(SSE2) compiled by MinGW GCC 4.0.3 is crashing.

[leeperry]

You can drag the slider with your mouse.

I know but you cannot reach every 0.1 increment......which is freakin' annoying

I cannot reach 1.67/1.78/1.85 and 2.35

[cc979]

ffdshow(SSE2) compiled by MinGW GCC 4.0.3 is crashing.

i'll check on it on mine, and try and find whats wrong - maybe related to crash with gcc 4.1.2 - as i had to alter the makefile.inc's remove the -march and -mtune to get it to work

[cc979]

just compiled it with gcc-4.0.3 with 'make SSE2=yes' works fine so far

[Yong]

sse and sse2 works here, with -march=pentium4 -mtune=pentium4, compiled with gcc 4.0.3, only libmpeg2 have problem with sse2(broken output or crash).

[cc979]

sse and sse2 works here, with -march=pentium4 -mtune=pentium4, compiled with gcc 4.0.3, only libmpeg2 have problem with sse2(broken output or crash).

just found libmpeg2 not sse2, just read a webpage about cpuid not in libmpeg2 - maybe its optimized for plain i686

edit. i maybe wrong https://trac.videolan.org/libmpeg2/browser/trunk?rev=1107

[Yong]

just found libmpeg2 not sse2, just read a webpage about cpuid not in libmpeg2 - maybe its optimized for plain i686

edit. i maybe wrong https://trac.videolan.org/libmpeg2/browser/trunk?rev=1107

libmpeg2 works if u define it with -U__SSE2__, which will disable the sse2 assembly code(?), or dont select the sse2 in here (http://img412.imageshack.us/img412/8176/sse2xd3.png).

[popper]

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.

it looks nice and simple , the way a book cover/first page should be, however im not so sure about this, perhaps its just me but 'if it's MPEG4 or H264, MPEG2 or MPEG1 or even WMV3' seems wrong and favours mpeg4-ASP and educates or at least implys to the average user that mpeg4 is the best (everyone says mpeg4 is the best as its [singular]the newest thing according to X-salesman)and so it most be divx as you state H.264 seperately (if they even know H.264 is AVC/mpeg4 p10, probably not).

perhaps its time for everyone to stress the point that mpeg4 is a generic salesmans trick (to sell non AVC kit)and people should be using 'the new AVC' and 'the old ASP' as the key words to at least make an effort to get people to ask these salesmen the right questions and perhaps get AVC/ASP written on the packages .....

[boom9]

sorry for offtopic, but do you know what does the "snap to desktop edges" option in MPC do?

Options->Player->"snap to desktop edges"

i have do some servial tests but did not see any difference

[thuan]

It does exactly what it says, when you move the thing close to your Desktop (screen) edges.

[boom9]

It does exactly what it says, when you move the thing close to your Desktop (screen) edges.

Looks like my MPC does not move closer, did I get it wrong?
thank you

[KoD]

How is this ffdshow related ? Is this the MPC thread ?

[LoRd_MuldeR]

@boom9
1. Plase remove over-sized images form your posting. They derstroy the layout!
2. "snap to desktop edges" means that MPC will dock to the edges of the screen when you move the window near to the edges. It's just the same behavior as Winamp, for example. Make the MPC window small enough and move it arround. You will notice the effect!
3. This post obviously is off-topic...

[leeperry]

Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

better talk to god than to his saints I guess, thank you so much :D

so I can use the keyboard arrows to finetune ?
any chance of implementing buttons with just 1.33/1.66666/1.77777/1.85 and 2.35 ?
or making the incremental change a lot slower when the right button is pushed ?
coz sometimes I just got my wireless mouse handy, no keyboard :D

where could I get a SSE2(GCC?) compiled version ?

thanks again and merry xmas :D

[fastplayer]

better talk to god than to his saints I guess, thank you so much :D
<snipped>

Why do you post the same (http://forum.doom9.org/showthread.php?p=921111#post921111) message again?

[leeperry]

coz it seems that I'd love to get a reply :)
sorry for that,

[_xxl]

I ran some tests on my computer and here are the results.
I used for testing a h264 sample and ffdshow rev 716.
I have enabled Queue in timecodec.exe.

The output colorspace is yv12.
NUll:
User: 22s, kernel: 0s, total: 22s, real: 23s, fps: 99.2, dfps: 97.0
http://i12.tinypic.com/47imfev.jpg
old:
User: 23s, kernel: 11s, total: 34s, real: 36s, fps: 64.1, dfps: 61.0
http://i14.tinypic.com/4igfskm.jpg
om:
User: 22s, kernel: 11s, total: 34s, real: 36s, fps: 64.8, dfps: 61.0
http://i12.tinypic.com/448sepd.jpg
vmr7:
queue on
User: 22s, kernel: 0s, total: 22s, real: 29s, fps: 98.0, dfps: 75.1
http://i16.tinypic.com/2evspj7.jpg
vmr9:
queue off
User: 22s, kernel: 0s, total: 23s, real: 24s, fps: 97.1, dfps: 92.9
http://i13.tinypic.com/400w3gh.jpg

[fastplayer]

Has a maxed-out core any adverse effects when using queued output?

[fastplayer]

Haruhiko has implemented a new version of queued output in rev719 with quite some fundamental changes - at least it looks like it to me :). So those who had issues with queued output in the past - *cough*CCCP*cough* - should give the 719+ builds a try.

Changelog:
New version of queue.
As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
Only queue in VMR7 and overlay mixer.
In VMR9, try VMR9's internal queue.
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.
registry option "queueCount".

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

Download:
ffdshow_rev719_20061227_xxl.exe (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=214245&release_id=470135)

[haruhiko_yamagata]

Haruhiko has implemented a new version of queued output in rev719 with quite some fundamental changes - at least it looks like it to me :). So those who had issues with queued output in the past - *cough*CCCP*cough* - should give the 719+ builds a try.

Well, let's fotet CCCP.
rev719 may not be as stable as beta1, though no new bugs are reported regarding queue (issue with Haali's renderer has been fixed).
I found VMR9 has internal queueing mechanism. It is not worse than ffdshow's but no better. When I try to play 720p 24fps movie in 48fps, it drops more frams with queue in a certain hardware(my intel on bord one). It's very usefull in G450, but it's not usefull at all in some hardware.
Queue is effective in VMR9 renderless/MPC in most video cards though.

[clsid]

I have tested the new queue.

ffdshow rev720
MPC rev611-3
Windows 2000 Sp4

Renderers:

System default:
Picture freezes after a few frames. Time slider progresses normally. If I move the slider to another spot in the movie, then again only a few frames are played before the picture freezes. CPU usage during freeze ~10%.

Old renderer:
queue off

Overlay Mixer:
off: old renderer does not support queue ???

VMR-7 (windowed):
ok

VMR-7 (renderless):
ok

VMR-9 (windowed):
off: video driver can't work with YV12 + VMR-9 + queue

VMR-9 (renderless):
ok

[LoRd_MuldeR]

jap:
* Overlay Mixer: "old renderer does not support queue"
* Haali Renderer: "Queued Frames: 0"
* VMR7/9 okay

(rev719, MPC 611-3)

[MacAddict]

jap:
* Haali Renderer: "Queued Frames: 0"
* VMR7/9 okay

(rev719, MPC 611-3)

I can verify this on my system as well.

[cc979]

rev 721

trunk/src/dialog/CcurveNormal.h

#ifndef _CCURVENORMALPAGE_H_1
#define _CCURVENORMALPAGE_H_

should it be

#ifndef _CCURVENORMALPAGE_H_1
#define _CCURVENORMALPAGE_H_1

[Eragon4ever]

I think this is my bad from removing spaces.
If so it should be
#ifndef _CCURVENORMALPAGE_H_
#define _CCURVENORMALPAGE_H_

I'll change it.

[haruhiko_yamagata]

Thank you for testing.
@clsid : I'll test Windows2000 and its default renderer.
@LoRd_MuldeR : I can't connect to Overlay Mixer recently in MPC. It connects to old renderer. Seems same for everyone. I remember I could. What's wrong? MPC, Direct X, OS, ffdshow?

[_xxl]

I used for testing a h264 sample and ffdshow rev 719 + queue on, MPC rev611-3 and Windows XP SP2.
Output colorspace YV12.
Renderers:
1).System default:
http://i14.tinypic.com/2duxmx4.jpg
2).Old renderer:
queue off
http://i13.tinypic.com/34z0vw3.jpg
3).Overlay Mixer:
queue off
http://i10.tinypic.com/313iv0j.jpg
4).VMR-7 (windowed):
http://i10.tinypic.com/2vd0ccm.jpg
5).VMR-7 (renderless):
http://i11.tinypic.com/4g4zndt.jpg
6).VMR-9 (windowed):
queue off
http://i17.tinypic.com/4ck6xxh.jpg
7).VMR-9 (windowed):YUY2
http://i10.tinypic.com/2i0sl5w.jpg
8).VMR-9 (renderless):
http://i10.tinypic.com/448twsk.jpg
9).Haali:
queue off
Queued Frames: 0
http://i14.tinypic.com/4h7j3py.jpg
MPC + ffdshow + Queue.
Queue off:
http://i12.tinypic.com/2cxw87s.jpg
Queue on:
http://i18.tinypic.com/2hs4vih.jpg
Media Player2 + ffdshow + Queue.
Queue off:
http://i10.tinypic.com/4gow6kw.jpg
Queue on:
http://i17.tinypic.com/2lih6wz.jpg
I have enabled Queue in timecodec.exe.
TimeCodec VMR7 + ffdshow + queue:
http://i11.tinypic.com/2gtueyf.jpg
User: 22s, kernel: 0s, total: 22s, real: 29s, fps: 101.4, dfps: 75.2
TimeCodec VMR7 + coreavc 0.0.0.4:
http://i18.tinypic.com/2lwxfed.jpg
User: 14s, kernel: 13s, total: 27s, real: 30s, fps: 81.2, dfps: 74.0
TimeCodec VMR7 + coreavc decoder 0.0.0.4 + ffdshow queue:
http://i18.tinypic.com/2a9165g.jpg
User: 15s, kernel: 0s, total: 15s, real: 29s, fps: 141.5, dfps: 75.1

[LigH]

Just as side note -- if you want to test Theora decoding, or output space clamping:

Some community modelling project of the PlaneShift MMORPG made a preview video in Theora which looked distorted at first in ffdshow, like: [\]

The reason was: It uses some odd dimensions (1202x911), and YV12 output was enabled in ffdshow. Limiting the output to RGB and YUV 4:2:2 only "fixed" the messed output. But here I wonder: May it be recommendable to expand the dimensions to the next matching sizes (e.g. height of 912 lines) to avoid that?

http://vaalnor.mine.nu/Downloads/Video/waterfall.avi (312 KB)

[_xxl]

http://img139.imagevenue.com/loc369/th_09263_theo_122_369lo.jpg (http://img139.imagevenue.com/img.php?image=09263_theo_122_369lo.jpg)
Input size:1202x911
Output size 1216x912
ffdshow + Haali Media Splitter (AR)

[fastplayer]

@drevil_xxl:
Any chance you include Unicode-version of ffdshow.ax in your builds (like clsid)?

[vlada]

On my system the output resolution is 1208x902 and it looks O.K. I'm using ffdshow beta1.

Btw. recently I read quite a lot about queued output. What is it good for? How does it works?

[LigH]

Hmm...

ffdshow_beta1_20061211_clsid.exe
YV12 output enabled
MPC 6.4.9.0 deutsch
Output: Overlay
ELSA Gladiac GeForce2 GTS, 32 MB, Detonator 4345

Video size:1202x911
Slanted picture

[LoRd_MuldeR]

@LoRd_MuldeR : I can't connect to Overlay Mixer recently in MPC. It connects to old renderer. Seems same for everyone. I remember I could. What's wrong? MPC, Direct X, OS, ffdshow?

Sorry, I don't know.

MPC is rev611-3
DirectX is 9.0c (2006 Dec)
OS is WinXP Pro (SP-2)
ffdshow is rev719

So everything should be up-to-date, eh?

// EDIT

With "Overlay Mixer" selected in MPC I get this:
http://img136.imageshack.us/img136/8554/overlaymf9.gif
So there is Overly Mixer on the graph...

But ffdshow still says "Queued samples: off: old video renderer does not support queue"

[clsid]

MPC also shows Overlay Mixer in "Play -> Filters" for me. Perhaps a bug in ffdshow that detects it wrong?

[haruhiko_yamagata]

Sorry, I don't know.

MPC is rev611-3
DirectX is 9.0c (2006 Dec)
OS is WinXP Pro (SP-2)
ffdshow is rev719

So everything should be up-to-date, eh?

// EDIT

With "Overlay Mixer" selected in MPC I get this:
http://img136.imageshack.us/img136/8554/overlaymf9.gif
So there is Overly Mixer on the graph...

But ffdshow still says "Queued samples: off: old video renderer does not support queue"
Thank you for the graph. I understood. When ffdshow detects "Video Renderer" in the graph, it says like that.
I'll fix the bug.

[haruhiko_yamagata]

Btw. recently I read quite a lot about queued output. What is it good for? How does it works?
Queue may save the CPU time and increase the frame rate when CPU load is high and droping a few frams/sec.

When ffdshow finished decoding, ffdshow delivers the sample to video renderer. Video renderer process the sample in its back buffer and waits untill it is time to present the image(the samples have timestamps). This waiting is waste of time. Queue utilize the time video renderer is waiting for the presentation time.

Assume the frame rate is 25. Each samples have to be processed in 40ms. Assume consecutive frames are decoded in 30ms, 45ms, 20ms, 50ms. With queue frame 2 and 4 can be delivered before presentation time. Without queue it failes to be in time and some video renderers drop such frames(depend on drivers).

Queue is especially effective when GPU is slow and frames are being dropped in video renderer. Queue was initially developped in G450.

Queue is not effective when it is too heavy and video is delayed, because the sample sent to video renderer is presented as soon as possible.

Queue is not effective in Timecodec.exe because Timecodec present the sample as soon as it is delivered.

Video renderer is executed in other thread, so it may help accelalation in some cases(usually not that much).

If you have fast CPU and GPU, you should disable queue.

[haruhiko_yamagata]

Just as side note -- if you want to test Theora decoding, or output space clamping:

Some community modelling project of the PlaneShift MMORPG made a preview video in Theora which looked distorted at first in ffdshow, like: [\]

The reason was: It uses some odd dimensions (1202x911), and YV12 output was enabled in ffdshow. Limiting the output to RGB and YUV 4:2:2 only "fixed" the messed output. But here I wonder: May it be recommendable to expand the dimensions to the next matching sizes (e.g. height of 912 lines) to avoid that?

http://vaalnor.mine.nu/Downloads/Video/waterfall.avi (312 KB)
Only VMR7 worked for me. All other renderers did not(I can't test Haali's). Obviously it is downstream's responsibility to reject such connection. But in practice they connects, means ffdshow has to do some work around. It is good to skip YV12 for such sized media.

Btw, is YV12 supported in VMR9?
If you have direct X SDK, see d3d9types.h
D3DFMT_UYVY = MAKEFOURCC('U', 'Y', 'V', 'Y'),
D3DFMT_R8G8_B8G8 = MAKEFOURCC('R', 'G', 'B', 'G'),
D3DFMT_YUY2 = MAKEFOURCC('Y', 'U', 'Y', '2'),
D3DFMT_G8R8_G8B8 = MAKEFOURCC('G', 'R', 'G', 'B'),
D3DFMT_DXT1 = MAKEFOURCC('D', 'X', 'T', '1'),
D3DFMT_DXT2 = MAKEFOURCC('D', 'X', 'T', '2'),
D3DFMT_DXT3 = MAKEFOURCC('D', 'X', 'T', '3'),
D3DFMT_DXT4 = MAKEFOURCC('D', 'X', 'T', '4'),
D3DFMT_DXT5 = MAKEFOURCC('D', 'X', 'T', '5'),

YV12 is not listed. Is YV12 + VMR9 with normal file working for evryone?

YV12 and VMR9 renderless/MPC does not work for me. ffdshow try YV12 first of all, This behavior may be changed for VMR9 renderless.

drevil_xxl said that it is black and white in WMP11/YV12/WinXp.

YV12 first may need reconsidering.

[wyrd]

Hi,in my case:

XPpro sp2
DirectX 9.0c(4.09.00.0904)
ATI Radeon(Omega3.8.252)
MPC611-3
WMP10 10.00.00.4036
ffdshow drevil_xxl's rev722
haali's media splitter 20061228

capture:
http://tirnanog.fate.jp/tmp/waterfall/
mpc_systemdefault.JPG
mpc_overlaymixer.JPG
mpc_vmr9_MixerModeOff.JPG
mpc_vmr9_MixerModeOn_YUVOff.JPG
mpc_vmr9_MixerModeOn_YUVOn.JPG
wmp_dontusevmr.JPG
wmp_overlaymixer.JPG
wmp_HQmode+ffdshow_forced_RGB32.JPG
wmp_HQmode.JPG

Regards

[foxyshadis]

I believe all YUV planar is converted inside the driver to UYVY before being passed on to the card, if the driver supports it. In my case it does, I have no problems using YV12+VMR9 with or without queue.

I have an odd bug that I've been unable to track down: Enabling avisynth drops frames for no apparent reason. It's totally repeatable on this sample (http://foxyshadis.slightlydark.com/random/[960x540%5D.mkv), and repeatable on certain panning scenes in other movies, but rare on others both larger and smaller. I can't figure it out. All the avisynth script has to contain is "last", if it's empty but enabled it'll be smooth. Queue has nothing to do with it, I'm sure of that. CPU usage is practically nothing, queue is at 9, and avisynth is the only filter enabled.

Better script: "ShowSMPTE()", which gives a counter that should change every frame. It doesn't, showing that it's sticking somewhere. Hrm. I'm not as lost as I was originally, but still don't see where the problem might be, assuming it's in the avisynth code.

[clsid]

In my experience YV12 output gives the best performance.

But in some (rare) cases it gives color shifts in Overlay, like in wyrd's mpc_overlaymixer.jpg screenshot.

A file that has color shift for me is "beyonce.at.the.bbc.1080mbaff.sample.ts (http://mirror05.x264.nl/public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts)" (1440x1088). Funny thing is that coreavc has no such problem on this file when outputting YV12 to Overlay Mixer.

Two others files with the problem are "STORMAHEAD_PodsTrailer.mov" (SVQ3 640x259) and "dv-300708.mov" (SVQ3 300x225). So both with non-mod2/4/8/16 resolutions.

[haruhiko_yamagata]

Of course YV12 is the fastest. That's why it is still default despite many problems.

For the odd number line files, the decision making for the spec is easy. Just add one line at the bottom, though the implementation may be hard.

Thorny issue is what to do in VMR9 renderless. VMR9 renderless supports YV12 but it does not work for me(i82865G, both MPC and Zoom player pro).

[foxyshadis]

Oh, an idea I wanted to mention. What do you guys think about having grain filter retrigger every 45 ms? This avoids one of the big problems with using it with vfr video (wmv and mkv particularly) with long stretches of a single frame. Sometimes a full second of staring at the same motionless grain pattern on a black screen. At least if it's moving at 22fps the eye is fooled into seeing haze, instead of grain. 45 ms is long enough to not interfere with film or video, and while it'd trigger twice a frame for 20fps and lower, I don't think it would look too bad. (But I still intend to run experiments to find out.)

[clsid]

I have tested the new queue.

ffdshow rev723
MPC rev611-3
Windows 2000 Sp4

Renderers:

System default:
works ok now

Old renderer:
off: The video renderer in use is not supported.

Overlay Mixer:
off: The video renderer in use is not supported.

VMR-7 (windowed):
ok

VMR-7 (renderless):
ok

VMR-9 (windowed):
off: video driver can't work with YV12 + VMR-9 + queue

VMR-9 (renderless):
Weird behavior: queue shows "1" once in a while, the rest of the time it shows "off: The video renderer in use is not supported".

Edit: Here is the OSD log file (http://www.mytempdir.com/1139999).

[wyrd]

@clsid
confirm here too. beyonce_colshift (http://tirnanog.fate.jp/tmp/waterfall/beyonce_colshift.JPG)
also, STORMAHEAD_PodsTrailer.mov is similar, too.(even defaultrenderer mode)
I'm wondering, but a snapshot comes out normally.(???) I've using "Fraps" for overlay capture.

Test report for "new queue":
I've a one problem too. It seems like the clsid's report.
("Picture freezes after a few frames. Time slider progresses normally.")
http://tirnanog.fate.jp/tmp/for_new_queue/sakura_hangup.jpg
samplemovie (http://tirnanog.fate.jp/tmp/for_new_queue/sakuratan.avi) (1.7M)

Test with:
ffdshow rev706p2,rev721,rev722
MPC rev611-3 WinXP sp2
splitter:mp4=haali's mkv=MPC avi=system
non HT P4(queue output sample: on - daring^^)

Because this problem occurs intermittently, I still can't clarify a reproduction procedure.

The operation that i did and a sample which is easy to occur with my pc.
1.restart pc
2.play movie with vmr9(renderless)+mixer mode off
3.change vmr9 -> null and play
4.change null -> vmr9(windowed) and play
5.change vmr9(windowed) -> vmr9(renderless)+mixer mode on and play
6.change vmr9(rederless) mixer on -> vmr9(renderless) mixer mode off and play
repeat 1-6.(may or may not be reproduce)

or other way,(This was easy to reproduce for me.(in rev721))
1.restart pc
2.play movie with vmr9(renderless)+mixer mode off
3.other applicaiton exec(open) and close.(e.g word,excel,msvc,photoshop...as heavy as one can)
4.play movie with system default renderer.
5.other applicaiton exec(open) and close.(e.g same as above)
repeat 2-5. or 1-5.
(Plz put sample movie to a network drive if possible.)

This problem reproduce with or with out renderer mode(vmr9/overlay).
other freeze snapshot & sample movie:
sanyo (http://tirnanog.fate.jp/tmp/for_new_queue/sanyo_hangup.jpg),starwars (http://tirnanog.fate.jp/tmp/for_new_queue/starwars_hangup.jpg),unreal (http://tirnanog.fate.jp/tmp/for_new_queue/unreal_hangup.jpg),mezon (http://tirnanog.fate.jp/tmp/for_new_queue/mezon_hangup.jpg)
http://tirnanog.fate.jp/tmp/for_new_queue/

Best Regards.
oh, I do not yet test rev723...

[clsid]

That freeze issue was fixed in rev723.

[wyrd]

I tested drevil's rev724 until a while ago.:o
It works fine for me.
Thanks a lot.

[haruhiko_yamagata]

In my video card(i82865G), YV12 is not supported for any 1025 or larger holizontal size. I see some green artifact or black screen.

//EDIT
YV12 is not supported for any 320 or smaller holizontal size. Many files from YouTube are smaller than 320.

[haruhiko_yamagata]

Now YV12 plays better than before in odd line numbers.
STORMAHEAD_PodsTrailer.mov as well as many files from YouTube plays better.

I still have issue in VMR9, but I'm sure it's VMR9's responsibility unless using YV12 in VMR9 of itself is wrong.

Do you agree to adding an option like "Disable YV12 in VMR9" and set it to default?
Because YV12 is the fastest, I think we need a poll.

I guess it should work in DVD resolution. Please test using resize to small(dx<320) and large size(dx>1024).