ffdshow tryouts project: Discussion & Development

[Dark_Angel_PT]

Aside from the CCCP and ffdshow tryouts discussion, i personally think this is a great project, and i give my respect to the developers of the new fork.
However, i believe the new fork suffers some of the problems the old one had.

- Release a stable, regularly updated build.
People like to have something they feel is safe and stable. Something to act as a reference, something to compare everything else against, like "this version is faster/slower than the stable one"
It is a reality that people still keep downloading and using milan's old builds, because they are considered the stable one.

Also, it gives the project a goal, a milestone, something to plan and work for.
Currently, i feel ffdshow just keeps constantly getting new features, and the occasional bugs..., over and over.
There is a need for milestones!! Something to wait for.

When the beta1 for a stable build came up, i was excited.
This project desperately needs a bigger audience, and only a stable, well spread and announced build can provide that.
How long hasn't the ffdshow beta1 been discussed here??
When someone reaches the sourceforge page, finding the usual "CLICK TO DOWNLOAD" button is impossible. The average user expects this, and it is essential for the wide spread of this project, for testing and feedback.

There is a need for an "official build" or recommended one. Of course a stable version could provide this, but further than that...for the testing versions too.
I think it would be a good idea to reach a decision on which combination of settings and compliers provides the best results. Even if not the fastest, a good allaround compatible build for all systems.
Then, other builds for specific instructions or different compliers could be mentioned for experienced users looking for extra speed or something else.

Taking over the old project is also a good thing, although i think in respect to milan, only a warning should be made in the homepage, everything else left as is, and development should continue in ffdshow-tryouts.


-Get the website organized, and USE IT!
I still think it is a waste to use Doom9 so much to discuss ffdshow, with a perfectly good forum and frontpage (the www.ffdshow.info ).
The discussion should be redirected from here to the forum, and the URL for the new fork much more divulged and announced.I don't expect a "SpreadFfdshow" campaign like Firefox....but at least concentrate things in a single place, and spread the word!!

Gathering people in a single place to report and discuss bugs, features and stuff is more more resource-efficient than have them spread over several places.

Having the forum active and with a developer stopping by sometimes, is good too.
I for example made a feature request, and didn't get a reply. A simple "too hard to implement ATM" or "don't expect to see it soon, not a priority" would have made me happy, as i would at least known what to expect.

The resources are there, just use them.

- Start Documentation
Make ffdshow more "for everyone".
Getting a stable version out, or a reference build would be a great step.
Concentrating efforts in one place, and make it know to the public....even better!
But, ffdshow has so many options it is impossible to just know what they all do by playing with them.
To start a wiki of some sorts, to slowly start to explain the workings of ffdshow would be a HUGE step.
An offline help file is good too, and i have heard something about that around here.



These are just suggestions and thoughts of a longtime ffdshow user, very grateful for everyones effort in making this software what it is

[haruhiko_yamagata]

When will we see the next stable tryouts? I see daily development but as a noob I feel very hesistant to upgrade. Right now most stuff works great. The only thing I would appreciate is better documentation what everything does.

Ps. And perhaps a little faster x264 decoding.. :)
It's fair statement. We have a lot to do before beta2. Please wait one or two months at least.

[ExtraEye]

Is X264 encoding speed up to you? I thought that actually depended on the FFMPEG guys...

[haruhiko_yamagata]

Aside from the CCCP and ffdshow tryouts discussion, i personally think this is a great project, and i give my respect to the developers of the new fork.
However, i believe the new fork suffers some of the problems the old one had.

- Release a stable, regularly updated build.
-Get the website organized, and USE IT!
- Start Documentation

As for stable release, we can't do so often. Because ffdshow is a huge project, testing it is very hard. We needed long time to test beta1. I think 4 times a year is the max.
As for take over, in respect to milan, I would like to continue on the tryouts.

As for the website, I agree with you. There should be more active, I hope. Especially for feature requests, it will be buried in, if they are posted here. And sorry for not replying yet.

Documentation is a big target. I completely agree with you. I've just begun but have no time to update. It is greatly appreciated if anyone write a single page for it. If one don't have skill in html, please post a simple text.

[fastplayer]

I see daily development but as a noob I feel very hesistant to upgrade.
There's no need to be "hesitant" using the latest build. Just try it! :)
The devs make - mostly - small incremental changes in each build and if they screw things up, they fix em in a matter of minutes.
When will we see the next stable tryouts?
Good question! Maybe the devs could shed some light on this one.

[_xxl]

I thought that actually depended on the FFMPEG guys.
True.Please ask ffmpeg developers to add multithreaded h264 decoding support.ffmpeg,mplayer and ffdshow can't handle h264 evobs.Tested with AMD X2.

[check]

Just looking at your first post:
ffdshow raw filter doesn't work in ZoomPlayer. (reported by midiboy)
This is a ZP 'feature', called smartplay. It seems to remove any raw processing filters, and also includes a blacklist where you can add evil filters (morgan, antifreeze, et al). Disabling it lets everything work as normal.

re: CCCP doing bug reports and helping code. No can do. We test our own version, which means bug reports would simply become more work for us, and we are mostly a bunch of patch monkeys, not Real Coders, so we can't help with dev :).

re: documentation. I'd be happy to write some of the ffdshow documentation, where does it belong? I've written a fair amount of the megui documentation, so I know what I'm getting in to.

[Hans Ohlo]

True.Please ask ffmpeg developers to add multithreaded h264 decoding support.ffmpeg,mplayer and ffdshow can't handle h264 evobs.Tested with AMD X2.
add paff decoding to the list. i 'dared' to report a bug/crash to the ffmpeg list and ask later if it has been confirmed and if it will be fixed... do not ask me what i got into doing so ;)

[ExtraEye]

"It is greatly appreciated if anyone write a single page for it. If one don't have skill in html, please post a simple text."
Post a simple text where?

[Yong]

can anyone comfirm this?
ffdshow.ax crash if noise filter+SSE2 is enabled.
im using P4 2.4Ghz.

tested with clsdi build, no crash.
i was compiled ffdshow with SSE=1 SSE2=1 flags...

[haruhiko_yamagata]

"It is greatly appreciated if anyone write a single page for it. If one don't have skill in html, please post a simple text."
Post a simple text where?
https://sourceforge.net/tracker/?group_id=173941&atid=867362

[haruhiko_yamagata]

Just looking at your first post:
ffdshow raw filter doesn't work in ZoomPlayer. (reported by midiboy)
This is a ZP 'feature', called smartplay. It seems to remove any raw processing filters, and also includes a blacklist where you can add evil filters (morgan, antifreeze, et al). Disabling it lets everything work as normal.

re: CCCP doing bug reports and helping code. No can do. We test our own version, which means bug reports would simply become more work for us, and we are mostly a bunch of patch monkeys, not Real Coders, so we can't help with dev :).

re: documentation. I'd be happy to write some of the ffdshow documentation, where does it belong? I've written a fair amount of the megui documentation, so I know what I'm getting in to.
You may report bugs as long as it is reproducible in the builds from tryouts. We'll fix them if we can.

Writing a documentation for ffdshow is wellcome, but you know I'm not feeling comfortable with CCCP. Before I can act cozy with you,

Open the source code immediately (Am I the copyright holder for the patches?).
Remove the insulting words in your WEB/forum (I know it's not you who wrote that).

[_xxl]

can anyone comfirm this?
ffdshow.ax crash if noise filter+SSE2 is enabled.
im using P4 2.4Ghz.
tested with clsdi build, no crash.
i was compiled ffdshow with SSE=1 SSE2=1 flags...
MinGW GCC 4.x.x can't compile SSE2 builds.
That's why you couldn't find them anymore.

[ExtraEye]

Mentar, your "example" with the resizing is kind of silly. I mean, the fact that the user can change the way the video is processed in accordance to his tastes/pc's abilities is definitly not a bad thing. "trying to use software in ways they are not INTENDED to be used" - what?
It's fine to argue here and there and it's fine you want to support cccp for not using ffdshow tryouts but is it possible for you to stop talking so rudely? It's totally unnecessary and doesn't help this discussion. Actually this hole debate *flame* doesn't suit this thread at all - may as well continue them in cccp forums instead of wasting the development thread's pages on it.

[check]

Writing a documentation for ffdshow is wellcome, but you know I'm not feeling comfortable with CCCP. Before I can act cozy with you,
You don't need to act cozy with me to tell me a good place to write up documentation :confused: edit: and in any case, I'm not doing this work on behalf of the CCCP. In any case, I've started the thing over on the mewiki (which is turning into a more general AV wiki by the day) here: http://mewiki.project357.com/wiki/Ffdshow_reference
I won't have more time to work on it until sunday, so feel free to add/copy/etc as you see fit. GPL fun: all work posted there is licenced under the GFDL, but I dual licence my first two revisions and release them into the public domain. If you want to start the reference somewhere else, that should be all you need.

[ilpippo80]

@haruhiko
I've tested hw deint in clsid's ffdshow_rev926_20070215_clsid_sse_icl9.exe.
Here's my results using graphedit:

MPV decoder only: ok with VMR7 and VMR9
DScaler only: ok with VMR7 and VMR9
ffdshow(libmpeg2) only:
- with VMR7 hw deint is always off and the image is horizontally stretched (I've never seen this bug before)
- with VMR9 hw deint is always on
MPV+ffdshow(raw): ok with VMR7 and VMR9 (hw deint depends only on MPV setting)
DScaler+ffdshow(raw):
- with VMR7 hw deint depends only on DScaler settings
- with VMR9 hw deint is always off
ffdshow(libmpeg2)+ffdshow(raw): hw deint is always off

[Yong]

MinGW GCC 4.x.x can't compile SSE2 builds.
That's why you couldn't find them anymore.

ok thx for the info;)
btw discovered 2 new bugs:
1. resize filter, eg, if i wana resize my video from 320x240 to 640x480, picture is resized, but it only show 1/4 on the screen.
same as 640x480 resize to 320x240.
2. resize filter crash if using rgb32 out.

just a quick report.:p

[HeadBangeR77]

@ clsid:
Your last 926 icl9 sse build works like charm, thanks. :)

@ haruhiko_yamagata
I cannot reproduce the old bug with auto iDCT & XviD decoding with the above build. Auto works fine for me now.

Btw. Is XviD MMX DCT really always used while encoding?

PS. * Using words of French origin seems to be complicated. ;)

[haruhiko_yamagata]

@haruhiko
I've tested hw deint in clsid's ffdshow_rev926_20070215_clsid_sse_icl9.exe.
Here's my results using graphedit:

MPV decoder only: ok with VMR7 and VMR9
DScaler only: ok with VMR7 and VMR9
ffdshow(libmpeg2) only:
- with VMR7 hw deint is always off and the image is horizontally stretched (I've never seen this bug before)
- with VMR9 hw deint is always on
MPV+ffdshow(raw): ok with VMR7 and VMR9 (hw deint depends only on MPV setting)
DScaler+ffdshow(raw):
- with VMR7 hw deint depends only on DScaler settings
- with VMR9 hw deint is always off
ffdshow(libmpeg2)+ffdshow(raw): hw deint is always off
Oops! True. Please wait.

[ExtraEye]

drevil_xxl: Exactly the point. Nothing is coming out of this - he even made a negative post in which he asks to be ignored and that's probably the best idea too. Let's just move on.

[foxyshadis]

All CCCP discussion moved to http://forum.doom9.org/showthread.php?t=122341

Please keep it there, this thread is discussion for the development of tryouts only.

[cc979]

just be using the resizer in ffdshow rev926, i got it set to 720/576 bicubic and resize allways and 0% border set

thing is - viewing the video on my desktop with normal 100% zoom using overlay/vm7 renderless/vmr9 renderless/haali- normal viewspace, but when in fullscreen there is about an inch of black border on the sides - is that normal ?

[haruhiko_yamagata]

Oops! True. Please wait.
Oops again, I replied too quickly. I tested with wrong settings.
All the case you pointed works OK for me.

[ilpippo80]

That's bad...
Which wrong settings? Maybe I had something wrong too.

[haruhiko_yamagata]

Resize was checked. :stupid:

[clsid]

just be using the resizer in ffdshow rev926, i got it set to 720/576 bicubic and resize allways and 0% border set

thing is - viewing the video on my desktop with normal 100% zoom using overlay/vm7 renderless/vmr9 renderless/haali- normal viewspace, but when in fullscreen there is about an inch of black border on the sides - is that normal ?
That can happen if you have "keep aspect ratio" enabled.

[foxyshadis]

You don't need to act cozy with me to tell me a good place to write up documentation :confused: edit: and in any case, I'm not doing this work on behalf of the CCCP. In any case, I've started the thing over on the mewiki (which is turning into a more general AV wiki by the day) here: http://mewiki.project357.com/wiki/Ffdshow_reference
I won't have more time to work on it until sunday, so feel free to add/copy/etc as you see fit. GPL fun: all work posted there is licenced under the GFDL, but I dual licence my first two revisions and release them into the public domain. If you want to start the reference somewhere else, that should be all you need.

I think that's a great idea and a great place for it, since you already have a well-known wiki set up. Thanks!

[ilpippo80]

ok, my bad, I just rechecked, I didn't understand that I had to disconnect and reconnect ffdshow in the graph after modifying the settings! also the bug with ffdshow(libmpeg2) only with VMR7 went away!
Everything works as it should now, thanks haruhiko! :)

[ilpippo80]

ehm, well, the truth is that there's another small bug, I noticed it during my tests...
with gabest's mpeg2 splitter and vmr9, with ffdshow mpeg2 decoding (but also with dscaler, not with mpv decoder) after seeking the field order seems to be wrong and the hw deinterlaced video becomes "bumpy" (goes 2 frames forward and 1 backward).
I can't tell if it works well with ms mpeg2 splitter because it doesn't allow me to seek at all in graphedit.
I don't know if you can reproduce this and if you have any interest in fixing it...

[haruhiko_yamagata]

ehm, well, the truth is that there's another small bug, I noticed it during my tests...
with gabest's mpeg2 splitter and vmr9, with ffdshow mpeg2 decoding (but also with dscaler, not with mpv decoder) after seeking the field order seems to be wrong and the hw deinterlaced video becomes "bumpy" (goes 2 frames forward and 1 backward).
I can't tell if it works well with ms mpeg2 splitter because it doesn't allow me to seek at all in graphedit.
I don't know if you can reproduce this and if you have any interest in fixing it...

http://support.microsoft.com/kb/924523/en-us
I can't reproduce untill now.
Is this related? If it is not reproducible in VMR7, it's possible.
Which version of direct X do you use?

[ilpippo80]

I only see it when hw deinterlacing is on, and it's the same artifact I see in progDVB (a program to watch DVB tv channels) after seeking.
I have it only with VMR9, not with VMR7.
The directx version reported in dxdiag is 9.0c (4.09.0000.0904).
Maybe it's just related with my hardware and video card drivers...

[ilpippo80]

I just noticed that I don't have it if I enable 'YUV mixing mode' in VMR9 renderer. Unfortunately it seems to be off by default, and I don't think there's a way to enable it globally...
I can enable it in MPC, though. I guess I could just keep using VMR9 in MPC and VMR7 in progDVB...

[ilpippo80]

Some more tests: what I wrote before is true only if ffdshow is used for mpeg2 decoding only.
If I have ffdshow(mpeg2)+ffdshow(uncompressed) or dscaler+ffdshow(uncompressed) I have this problem with VMR7 and VMR9, no matter if I check or uncheck YUV mixing mode and if I reconnect all the filters. No problems at all with MPV decoder also connecting it to ffdshow uncompressed.
Would you like me to upload one of the small mpeg2 captures I'm using for these tests? Maybe it could be of help...

[multiblitz]

Are there any plans that ffdshow can be used to playback hd-dvd ? Now that AnydvdHD is available...that would bump up the pq and give the PC agian the lead...

[_xxl]

FFmpeg, mplayer and ffdshow can't handle h264 HD-DVD evobs.No multithreaded decoder support.Ms VC-1 codec has multitheaded and DXVA, but no support yet for vc1 HD-DVD evobs in ffdshow.

[cc979]

That can happen if you have "keep aspect ratio" enabled.

so is it a small bug then ?

[haruhiko_yamagata]

Some more tests: what I wrote before is true only if ffdshow is used for mpeg2 decoding only.
If I have ffdshow(mpeg2)+ffdshow(uncompressed) or dscaler+ffdshow(uncompressed) I have this problem with VMR7 and VMR9, no matter if I check or uncheck YUV mixing mode and if I reconnect all the filters. No problems at all with MPV decoder also connecting it to ffdshow uncompressed.
Would you like me to upload one of the small mpeg2 captures I'm using for these tests? Maybe it could be of help...
Thank you for testing.
It's not reproducible for me. It may depend on the sample or your hardware. Please upload the sample.

Revision 933 - Directory Listing
Modified Sat Feb 17 13:58:33 2007 UTC (4 minutes, 35 seconds ago) by h_yamagata
Raw video and HW deinterlacing
enable interlaced flag only when ffdshow is inputing VIH2-interlaced format.
Though it was not symptomatic for me, it might not be safe to test dwTypeSpecificFlags without checking the connection type.

[ilpippo80]

@haruhiko
I sent you the sample...

[clsid]

so is it a small bug then ?
Only if there also are black bars at the top and bottom.

But why resize to 720x576 and then go to fullscreen (which does another resize operation)? Is there perhaps a PAL TV connected via TV-out?

[cc979]

Only if there also are black bars at the top and bottom.

But why resize to 720x576 and then go to fullscreen (which does another resize operation)? Is there perhaps a PAL TV connected via TV-out?

i was converting a hd vid and want see what options looked best

it was 'Elephants_Dream_HD.avi'

i will upload a snippet if you like

[cc979]

after testing more testing, with a new clip 'transformers.1080p.divx.avi'

its got no borders and its 1904x784, i have re-encoded it 640x274

resize off on both clips
using ffdshow not in fullscreen normal
using ffdshow in fullscreen normal

resize set to 720x576 on both clips
using ffdshow not in fullscreen only borders added to top and bottom
using ffdshow in fullscreen black borders on the sides

i did not matter which render i used either, its looking more like a bug to me

[clsid]

A sample would be helpful, because I cannot reproduce it.


But I think I have found another bug:
I re-encode a 640x352 sample with VirtualDub and ffdshow VFW and enable image processing. If I use the crop filter to remove a bit from top and bottom, then the actual video will be cropped, but not the frame size. So the output is still 640x352, but with black bars top and bottom, equal to the size I cropped.
And another one:
If I resize to 640x274 with keep aspect ratio on, then the frame size will stay 640x352 instead of resizing and added black bars to the sides. Without aspect ratio correction it works ok.

[cc979]

here is the a sample

http://www.mytempdir.com/1220860

i've just found if the subtitles if ticked even if it has none - it displays correctly

subtitles off - black borders on the sides

[Yong]

i think resize filter bugged since rev850, or may be earlier rev.
and i tried the resizer in zoomplayer, its only works in fullscreen mode,
windowed mode has same problem in mpc.

im using ffdshow_rev926_20070215_clsid_sse_icl9

[clsid]

I still cannot reproduce it :(

[_xxl]

New beta testers are required for ffdshow-tryouts.

[Yong]

Compiling error with r934:
ffdshowRemoteAPI.cpp: In member function 'LRESULT Tremote::remoteWndProc(HWND__*, UINT, WPARAM, LPARAM)':
ffdshowRemoteAPI.cpp:307: error: 'struct IffdshowDecA' has no member named 'grabNow'
make: *** [ffdshow_all.o] Error 1

[Yong]

http://img151.imageshack.us/img151/3088/clipboard01da0.gif
1. rundll32.exe crash if i delete the loaded preset image.
2. im getting "Reconnect failed, please restart video application" if using resize filter with VMR9 windowed/renderless mode.
3. the weird resize problem seems only happended if using overlay mixer/haali video renderer, im not sure though, need more testing :p
4. ffdshow crash with this sample, http://y0ngc6.googlepages.com/KoimomoDEMO300.mp4
, encoded with x264 r622, he aac 64kbps

[haruhiko_yamagata]

1. rundll32.exe crash if i delete the loaded preset image.
2. im getting "Reconnect failed, please restart video application" if using resize filter with VMR9 windowed/renderless mode.
3. the weird resize problem seems only happended if using overlay mixer/haali video renderer, im not sure though, need more testing :p
4. ffdshow crash with this sample, http://y0ngc6.googlepages.com/KoimomoDEMO300.mp4
, encoded with x264 r622, he aac 64kbps

1. OK, loaded preset should be protected.
2. Do you use rev 928 or later? Do you use queue?
4. It's not reproducible for me.

Thanks.

[haruhiko_yamagata]

@ilpippo80
Confirmed. Thank you for the sample.