ffdshow tryouts project: Discussion & Development

[adam777]

Adam, can you upload a sample file?

Sure.
Here - http://www.mediafire.com/?w0jfpn4ztyq7xzm
It's a few seconds from a 1080p60 clip linked here - http://forum.doom9.org/showthread.php?p=1488827#post1488827, spliited with mkvtoolnix
:thanks:

[clsid]

Fixed in 3832.

[adam777]

Fixed in 3832.

Indeed. :thanks:

[moonrak]

Fixed in 3832.
Where can I download 3832 from?
Moonrak

[fastplayer]

Where can I download 3832 from?
http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

[moonrak]

http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

My real question should have been:
Where is r3832 compiled by clsid?
:)
Moonrak

[Superb]

My real question should have been:
Where is r3832 compiled by clsid?
:)
MoonrakWhy does it matter to you? :confused:
You can also download it from http://www.xvidvideo.ru/

[moonrak]

Why does it matter to you? :confused:
You can also download it from http://www.xvidvideo.ru/

One hour ago the update was not in http://www.xvidvideo.ru/.
Now I can see it is.
In the past I have had issues with xhmikosr builds (don't know why) so I try to stay away from them.
:)
Moonrak

[tal.aloni]

@devs,
Can anyone that knows a bit about the audio parser have a look at this bug report? The problem has already been narrowed down to a specific revision.
https://sourceforge.net/tracker/?func=detail&aid=3294017&group_id=173941&atid=867360

I'll have a look in the next few days.

Edit: Fixed for rev. 3835

p.s. if any of you have a legal license to Windows Home Server (2003) please PM me

[Superb]

Very annoying regression:
ffdshow crashes when used to convert colorspace (NV12 -> RGB32) in Subtitle Workshop.
Worked w/ many revisions (including Beta 7), but started crashing a while ago.
Crashes randomly (my guess is ~80% of the time) on playback start/middle or when closing SW.

Background:
Subtitle Workshop 2.51. Windows 7. Nvidia card capable of H.264 dxva decoding (I have GT 430).
When tried opening mkv-h.264 file in SW, one has to use ffdshow in order to convert colorspace due to a SW's bug.
You would simply enable ffdshow video decoding for raw video (all supported) and it made SW work w/ mkv-h.264 files.
This workaround worked great until recently, when ffdshow started crashing.

EDIT: I started testing various revisions and will update here w/ results...
ffdshow_rev3832_20110429_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3802_20110402_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3700_20101226_xvidvideo-ru_x86-MSVC2010.exe - works
ffdshow_rev3750_20110125_xhmikosr_MSVC2010.exe - works
ffdshow_rev3775_20110314_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3762_20110219_xhmikosr_MSVC2010.exe - works
ffdshow_rev3768_20110304_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3765_20110225_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3763_20110219_xhmikosr_MSVC2010.exe - works

[oddball]

I'm unable to play a 1080p60fps clip fluidly with ffdshow in the filter chain. I get massive amounts of dropped frames. I'm using MPC-HC latest, internal splitter (tried external and makes no difference), CUVID as the decoder, ffdshow as the filter and MadVR as the renderer. When ffdshow is not in the chain the clip 'Birds' plays fluidly.

Clip is linked to in this thread.

http://forum.doom9.org/showthread.php?t=156660&highlight=birds+1080p

Likewise if I disable any filters in ffdshow and let it pass unmolested it plays near fluidly with the occasional dropped frame (It does not drop ANY frames if ffdshow is not in the chain).

GPU load is under 10%. CPU climbs to 60-70% on an Intel E7600. If I untick the filters then the video plays much more fluidly but the CPU hardly drops so I doub't it's a CPU usage issue. MPC-HC remains around the 60-70% usage mark regardless if I tick or untick any ffdshow filters. But it plays smoother with them unticked.

Any ideas why it's dropping massive amounts of frames when any filters are enabled? I am only seeing this on 1080p60fps video.

[tal.aloni]

oddball:
does it happen on default configuration as well?
try uninstalling and reinstalling to reset configuration, perhaps there is some setting that you're missing that's causing it.

also, please try beta 7 (rev 3154) as well as the latest revision.

[oddball]

I noticed it plays smoother with random pauses using overlay or ever. evr-cp it freezes more often and evr-sync it just stops playing altogether. I will try with the latest build on default configuraiton. Usually I output at YV12 with high quality YV12 to RGB conversion. If I untick that as well as drop frames after 1500 delay in decoder options it plays fluidly. But only using overlay.

[oddball]

I just tried with PotPlayer which is using even less CPU. Odd thing is using PotPlayer with ffdshow RAW filter and no filters ticked at all it plays slow motion video (audio stays the same) using EVR-CP. MadVR is an absolute no go. Continuous stutter and massive frame drops. Ah it does the slomo thing with EVR in MPC-HC too. It's like ffdshow can't process the frames fast enough to the renderer.

[oddball]

I uninstalled ffdshow completely and reinstalled the latest build 3836 and when using it for decoding the 1080p60fps Girl Yoon clip it EATS the CPU! Using MPC-HC internal decoder even with non-DXVA it hardly makes an impact on the CPU. What's wrong with ffdshow or my setup?

[oddball]

ffdshow is unable to keep up when using filters on RAW decoded video. It is dropping frames all over the place when trying to present frames to MadVR and does not do much better with any other renderer. Also if I allow ffdshow to decode the video it EATS the CPU using ffmpeg-mt or libav. I don't think CPU overhead is an issue anyhow. When I use a decoder that loads onto the GPU it makes no difference. ffdshow just cannot seem to push 1080p60fps video through it's filters fast enough and even drops a few odd frames with no filters ticked.

BTW I don't seem to have issues with 1080p @ 23.976fps I will have to test a 30FPS clip and see if that gives issues.

EDIT: No problems with 1080p @ 30FPS even with filters ticked. Only the 60fps stuff does not want to play ball with ffdshow in the chain.

EDIT2: For now I've had to setup a profile so that anything fps>30 gets sent unfiltered. Not ideal but the only way to get 1080p60fps playback with ffdshow in the chain.

EDIT3: btw I can just about use Sharpen (unsharp). If I do High quality YV12 to RGB conversion I start to see glitches here and there. Deband is a no go. I can only assume ffdshow has limits on certain filters when it comes to high res + high framerates or perhaps it's a system IO problem. Not too sure.

[mindbomb]

hey you guys, i have a question about ffdshow audio processor.

I'm using lav audio as my decoder, and ffdshow audio processor to downmix.

So, I'm wondering if selecting 24 bit output in ffdshow in this capacity actually leads to proper 24 bit output?

Let's say I have a 24 bit truehd file, then the processing chain would look like this with just 24 bit selected on the output page:

24 bit int from lav audio ->32 bit int for ffdshow processing -> 24 bit int again for ffdshow output

is that correct?

[nevcairiel]

f If I do High quality YV12 to RGB conversion I start to see glitches here and there. Deband is a no go. I can only assume ffdshow has limits on certain filters when it comes to high res + high framerates or perhaps it's a system IO problem. Not too sure.

Sounds like your CPU is just maxxed out. HQ RGB conversion takes alot of power.

Rather use a YUV output (YV12 or NV12), and let the renderer convert to RGB - madVR does a better job at it anyway. :)
Note that not everything is multithreaded (or can be), so if you see >50% load on a dual core, it could mean that one core is completely maxxed out.

[Superb]

Very annoying regression:
ffdshow crashes when used to convert colorspace (NV12 -> RGB32) in Subtitle Workshop.
Worked w/ many revisions (including Beta 7), but started crashing a while ago.
Crashes randomly (my guess is ~80% of the time) on playback start/middle or when closing SW.

Background:
Subtitle Workshop 2.51. Windows 7. Nvidia card capable of H.264 dxva decoding (I have GT 430).
When tried opening mkv-h.264 file in SW, one has to use ffdshow in order to convert colorspace due to a SW's bug.
You would simply enable ffdshow video decoding for raw video (all supported) and it made SW work w/ mkv-h.264 files.
This workaround worked great until recently, when ffdshow started crashing.

EDIT: I started testing various revisions and will update here w/ results...
ffdshow_rev3832_20110429_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3802_20110402_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3700_20101226_xvidvideo-ru_x86-MSVC2010.exe - works
ffdshow_rev3750_20110125_xhmikosr_MSVC2010.exe - works
ffdshow_rev3775_20110314_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3762_20110219_xhmikosr_MSVC2010.exe - works
ffdshow_rev3768_20110304_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3765_20110225_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3763_20110219_xhmikosr_MSVC2010.exe - worksAlright, reduced the problem to either 3764 or 3765.

3764 commit log (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&sortby=date&revision=3764) (by clsid2):
Updated FFmpeg

3765 commit log (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&sortby=date&revision=3765) (by stargazer69):
Output tab overhaul:
- Removed some never used colorspaces
- New colorspace priority lists
- Enable "Set interlaced flags in output media type" by default
- "Set interlaced flags in output media type" no longer disables YV12 output
- Enable high quality YV12/NV12/YUY2->RGB32 conversion by default

My guess is that 3765 caused the new crash regression (is has to do more w/ colorspace stuff), but I can't be sure unless someone provides me w/ 3764 compilation.

[oddball]

I tried overclocking my E7600 from stock 3.06Ghz to 3.8Ghz. CPU load hit's a max of 75% but generally stays under this when playing back Birds 1080p60fps. The big hitter is the deband filter. If I enable it I tend to get dropped frames all over the place. GPU load is low. CPU load as stated hits a max of 75% but general stays under 70% so it's not maxxed out at all. If I enable all colorspace outputs I get green on side of my HDTV and black and white on the other half. Most peculiar.

I still think something is up with ffdshow not being able to pass 1080p60fps through deband fast enough for some reason. I can get sharpening to work with 2 dropped frames on Birds 1080p60fps (always drops the 2 frames at the exact same points too).

Or is it really a case of when ffdshow load MPC-HC (Or the system in general) beyond 65% CPU then it all goes to hell?

EDIT:NV12 was the culprit for the green and black and white screen. If I untick that it looks correct.

[clsid]

CPU usage percentages are meaningless with multiple cores. If one core is maxed out, then the load it too high. It is as simple as that.

[e-t172]

Besides, you don't seem to realize that using image filters on 1920x1080 images 60 times per second means huge amounts of computing power. I wouldn't be surprised if current CPUs are unable to handle that. Especially if it's not multithreaded.

[mindbomb]

iirc, the hq rgb conversion is multithreaded, i think iv read that before. the other filters, idk.

another ffdshow raw audio processor question:
should i uncheck 16 bit int for processing?

It appears to be used for 16 bit sources, but wouldn't be better to convert them to 32 int and then process them, as is the case with 24 bit audio?

[oddball]

Well if Cameron and Jackson have their way high speed video will become the norm. Hopefully computers will catch up enough to process it with all the bells and whistles. Since the GPU is not loaded much though is there any way for something like ffdshow to throw some of the load onto the GPU (I'm talking about development not now obviously)? It just seems crazy that the CPU is having to do all of the work when the GPU is hardly being taxed at all (and since video is what the GPU is for....well you get the picture).

[mindbomb]

mpc-hc shaders or madvr might suit your needs oddball

[jmone]

I'm unable to play a 1080p60fps clip fluidly with ffdshow in the filter chain. I get massive amounts of dropped frames.

I have no issue with my own (or the birds) 50/60p content using FFDSHOW with ffmpeg-MT as the decoder - libav will drops frames as you have described.

[oddball]

MadVR is what I am using. Shaders do not give the fine control like ffdshow does. I like to use the sharpening + deband + high quality YV12 to RGB + MadVR because I'm like that. :)

Anyhow it all works with everything up to 720p @ 60FPS. Just not 1080p @ 60FPS. I can live without it for now ;o]

[nevcairiel]

"high quality YV12 to RGB" does not work with madVR, because madVR does not accept RGB input. Chances are, its just not doing anything for you. :p

[oddball]

I did wonder about that. Unticked.

[VipZ]

I have a small request, if its to much hassle just ignore this :p

I would like to be able to remove non libav components and not show up in the configuration, ie ff_kernelDeint, ff_samplerate, TomsMoComp_ff. Similar how the audio/video decoder's if not present don't show up as a decoder option.

Also what purpose does this file, openIE.js serve?

Thanks

[fastplayer]

Also what purpose does this file, openIE.js serve?
Creates a URL and passes arguments to a database for ffdshow's whitelist/blacklist feature.

[VipZ]

Creates a URL and passes arguments to a database for ffdshow's whitelist/blacklist feature.

Thanks, so its one more file on the chopping block.

[mark0077]

Hi guys, is anyone here involved with ffmpeg-mt. I was using a audio / video sync test today and actually surprisingly found more issues with several decoders / filters / renderers in my setup.

It has mpeg4 x-vid 320x288 video. One issue I now notice is that with ffmpeg-mt as the video decoder, audio / video goes significantly out of sync, maybe 0.5 of a second.
(I notice a seperate issue with audio / video desync also with madVR which is seperate from this issue). This ffmpeg-mt issue happens with any video renderer so its definitely ffmpeg-mt related.

Using libavcodec in ffdshow as the video decoder, I don't get the audio / video out of sync issue. Is this something that someone could be interested in looking into.

I'm using ffdshow 32bit 3838. The avi is on this page.

Page: http://editorsean.com/blog/49-audiovideosynctest
Direct Link: http://editorsean.com/content/video/av_sync/sound_in_sync_test.avi

Let me know if you'd like any more information if anyone wants to take a look at fixing it.

[clsid]

Unless anyone knows why it happens, I think I will just remove MPEG4 from ffmpeg-mt. Maybe it is an issue with packed bitstream.
Does anyone have similar sync issues with ffmpeg-mt VP3 and HuffYUV?

[mindbomb]

so, is it actually ideal to uncheck 16 bit int in the processing tab of ffdshow in my case, where i am using the mixer of it?

[Andy o]

I should have posted this in this thread in the first place, but TrueHD 7.1 swaps sides and rear surrounds:
http://forum.doom9.org/showthread.php?p=1498728

[nevcairiel]

The channel order was actually wrong in ffmpeg - at least up until a few weeks ago until it was fixed in ffmpeg. I guess ffdshow didn't compensate for the upstream fix. I had to remove my custom reordering of TrueHD at that poin.

[clsid]

Was the channel order correct before, or was it always wrong with ffdshow?

Changing this line in reorder_ch.h might fix it:
change
#define AF_CHANNEL_LAYOUT_LAVC_MLP_8CH_DEFAULT AF_CHANNEL_LAYOUT_7_1_B
to
#define AF_CHANNEL_LAYOUT_LAVC_MLP_8CH_DEFAULT AF_CHANNEL_LAYOUT_7_1_A

[CruNcher]

could somebody add it

videocodec ffmjpegb
info "FFmpeg MJPEG-B"
status working
fourcc mjpb ; Apple MJPEG-B (Quicktime)
driver ffmpeg
dll mjpegb
out 444P
out 422P
out 440P
out YUY2 ; queryed (conversion from yuv422p)
out YV12,I420,IYUV

i guess only the fourcc is missing but i could be wrong and the whole mjpb part is,as mjpa works ;)

[clsid]

Tried adding it a while ago. It didn't work properly.

[iSunrise]

Hi guys, is anyone here involved with ffmpeg-mt. I was using a audio / video sync test today and actually surprisingly found more issues with several decoders / filters / renderers in my setup.

It has mpeg4 x-vid 320x288 video. One issue I now notice is that with ffmpeg-mt as the video decoder, audio / video goes significantly out of sync, maybe 0.5 of a second.
(I notice a seperate issue with audio / video desync also with madVR which is seperate from this issue). This ffmpeg-mt issue happens with any video renderer so its definitely ffmpeg-mt related.

Using libavcodec in ffdshow as the video decoder, I don't get the audio / video out of sync issue. Is this something that someone could be interested in looking into.

I'm using ffdshow 32bit 3838. The avi is on this page.

Page: http://editorsean.com/blog/49-audiovideosynctest
Direct Link: http://editorsean.com/content/video/av_sync/sound_in_sync_test.avi

Let me know if you'd like any more information if anyone wants to take a look at fixing it.
Nice find there mark0077.

Yes, it seems to be ffmpeg-mt related, there´s no problem whatsoever, when using ffmpeg (libavcodec) instead.

@clsid:
Did some various tests with mpeg4 (xvid) and VP3 (vp31) encoded files (.avi container) and all of them exhibit the same problem.

[clsid]

Is the sync is correct with 1 thread, and the difference bigger with more threads?

[mark0077]

Hi clsid, yes that seems to be the case. Using 1 thread I get no desync. With 2 I can't hardly notice any problem to be honest. With 4 I notice a desync. With 8 its very noticible.

Turns out the madVR issue I thought was there because of differences in desync between on/off of one of its settings "prevent several frames in advance", doesn't exist at all. I can't explain why ffmpeg-mt might show differences in video / audio desync with this madVR option but using libavcodec shows no desync issues with any other combination of settings so theres no madVR issues at all. Let me know if you'd like to test any builds with any potential fixes etc. No problem.

[clsid]

Sync problem does not happen with H264, right?
I haven't found the code yet that handles the delay caused by frame threading.

[hoborg]

Hi.
Can be FFDShow dxva decoder updated to latest MPC-HC source (including fix in 3090)?

[Falcon4]

Okay. Help me out here, because I think in answering this question, one of two things will happen: either I'll find a much easier way to get this simple task done, or the ffdshow devs will see why VFW encoders are important. Either way, I can't figure out at what point VFW encoders were removed - or why, since it's part of ffmpeg's functionality that ffdshow is supposed to expose to dshow. Thread is kind of a mess...

Here's what I'm trying to use ffdshow for. I have a crappy capture adapter that uses DirectShow. It's connected to a night-vision VHS-C camcorder mounted on a tripod on my porch. It watches my car. It works good. However, the software is a godd*mn nightmare. My intended purpose is to capture the incoming video, encode it quickly (dual-core Atom D510 can keep up with lossless x264 and temporal smoothing filters in realtime with ffdshow), and drop it onto HDD. 1 full day of video is about 30gb. Absolutely perfect for my needs.

Small problem, though. VFW sucks, but there are no alternatives. I really want to be able to use DirectShow directly, not mucking with ffdshow's VFW afterthought. But there don't seem to be any real DirectShow capture applications on the internet... at ALL. I've googled it endlessly, and always come up blank*. The cleanest I could find is using GraphStudio to manually link a filter chain together, and it worked (barely) for a while, but that's completely unacceptable as a long-term solution.
(* - edit: take a look at this page of useless results yourself: http://www.google.com/search?hl=en&safe=off&qscrl=1&q=x264+video+capture+software&aq=f&aqi=&aql=f&oq= )

Then there's the x264 side, which has been quoted as saying that x264vfw is a dirty hack and no longer maintained. Um... what?!

So, ffdshow-VFW no longer serves any useful purpose whatsoever (no encoders, no purpose... wtf?)... and x264-VFW is no longer maintained because it's a "dirty hack". In addition, I've seen a good number of people complaining about the decision to remove encoders from ffdshow... and the official version (beta) still has them! Imagine when this change goes through to the beta. You think it's a minority now? I think a lot more people use ffdshow's VFW encoder than is being given credit ;)

Now, the question: Without any modern and supported VFW encoders, what am I supposed to use to capture video to x264?

edit: think I'll start collecting "reasons why ffdshow's VFW encoders are the keystone of x264 video capture and removing them is practically suicide"...
http://doom10.org/index.php?topic=905.0

[clsid]

What you have read about x264VFW are no facts, but opinions from people who hate VFW (or rather putting H.264 in AVI). They would say the same about ffdshow.

Fact is that x264VFW is better and more up-to-date than ffdshow ever was. If you are stuck with VFW, x264VFW is what you should use.

[Falcon4]

What you have read about x264VFW are no facts, but opinions from people who hate VFW (or rather putting H.264 in AVI). They would say the same about ffdshow.

Fact is that x264VFW is better and more up-to-date than ffdshow ever was. If you are stuck with VFW, x264VFW is what you should use.

I only wish the fantasy world of opinion were true. Sadly, no, it's an x264 admin/dev that I'm quoting, directly from a Google search for "x264 vfw", second result.

http://forum.doom9.org/showthread.php?t=89979
"Q11: What'st the difference between VFW and CLI?
A: VFW is Video For Windows, an ancient tech created by microsoft (copying some stuff from quicktime), full of quirks and not able to support modern codecs. x264VFW is a ugly hack to make x264 work (more or less) with VFW, hence softwares like virtualdub and its modifications. The use of x264VFW is NOT recommended. x264 VFW is no longer officially supported."

(sadly, the 21,000+ downloaders of the latest version (http://sourceforge.net/projects/x264vfw/files/x264vfw/32_1913bm_27769/) of x264vfw would beg to differ on that "ugly hack" and "more or less" thing)

So who's gonna support capture? I've got the old, useless, buggy, outdated, clunky, piece of junk (according to... well, not many people but the devs) x264 encoder in ffdshow running in VDub right now cranking out 30fps lossless and noise-reduced video crunching through my Atom right now at 19% CPU. I think it works pretty g*ddamn well! :P

[nevcairiel]

Who says a x264 developer can't have opinions? They may think x264VfW is bad, and don't officially support it, it may however still work just fine, and other people seem to actively maintain it.

x264 in ffdshow vfw has not been maintained for ages, and is guaranteed to be more out of date then any x264vfw.
Did you try x264vfw? Maybe it just works, no matter what some x264 developer claims. :p

So you have x264 in ffdshow vfw, which the devs claim is a dirty hack, and was therefor removed (and not supported or maintained before anyway)
And you have x264vfw, which the x264 devs claim is a dirty hack, and do not officially support it - however other developers do!

Now you choose. :D

[Falcon4]

Seems that x264 inside ffdshow gets more love than x264vfw, and it's hard to see why users of ffdshow, inside an ffdshow thread, would be arguing against one of--... nay, it's only true calling in life, IMO. MPC-HC has a better h264 implementation, and the other encoders in ffdshow are pointless if x264 can do it all better... so I really don't understand why the idea could even be conceived to take x264 out of "the x264 implementation for Windows", ffdshow.

I mean, you might as well say that Steve Jobs' opinions of Apple don't really matter about Apple. That's about as much sense as watering-down an x264 dev's opinion of x264vfw makes... :P

At least ffdshow provides a GUI for x264's options... I installed x264vfw and tested it out, it provided the same quality (same exact settings as I used in ffdshow-VFW far as I could interpret) and the same filtering at about half the performance of what ffdshow's implementation gave me: it averaged 17FPS (from 30fps capture), with 100% CPU on one core, while ffdshow-VFW skidded away with 30FPS at about 60% CPU on one core (17% CPU usage on 4 logical CPUs). Put simply, x264vfw really does suck in comparison to what ffdshow already had implemented.

It's pretty rare for an application to take such a huge step in functionality, on a developer's whim, and actually have that decision be disputed by more than a small number of people, and still be supported by the developers. Seriously, it's project suicide.