ffdshow tryouts project: Discussion & Development

[TheShadowRunner]

I already did, tried up to the oldest ffdshow tryout build available on sourceforge, the bug is there.
It has never worked correctly for me.

[clsid]

It was fixed in 3031/3039. I tested old build 3040 and it is working. Will try newer ones now.

Edit: it was broken again in 3062.
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=3062

Edit: reason is discussed here:
http://forum.doom9.org/showthread.php?p=1312127#post1312127
http://forum.doom9.org/showthread.php?p=1319023#post1319023

A proper fix needs to be made that doesn't break resize/auto-crop.

[TheShadowRunner]

Are you sure? 3040 has the bug here.
Edit: a file (http://www.square-enix.co.jp/music/sem/page/xenogears_orchestra/swf/soundsbgm/pv.flv)showing the bug also on the bottom, maybe useful for testing in the future.

[tal.aloni]

Hi all,
I'm seeing that clsid modified ffmpeg's makefile in rev. 3733,
the following line was added:

$(shell test -d $(@) || mkdir -p $(@))


as a result, I'm getting errors when trying to build ffmpeg using cmd.exe and MinGW (TDM), any help would be appreciated.
('test' is not recognized as an internal or external command)

Thanks,
Tal Aloni

[mark0077]

Hi tal.aloni, clsid

A discussion over on the avs forums has found that ffdshow has been causing crashes when used with avisynth but only since the following ffdshow revision so I assume its this avisynth change that was made in ffdshow. As Set hasn't gotten back to us in a few weeks, I'm wondering what the procedure is for things like this. Should the patch be backed out as according to the guys on the avs forums, it does more harm than good.

Revision 3358 - Directory Listing
Modified Thu Apr 15 08:27:07 2010 UTC (10 months, 1 week ago) by tal_aloni
AviSynth Frame accurate seeking. (patch by SEt and Jeremy Duncan)

http://forum.doom9.org/showthread.php?p=1479990#post1479990

Thanks in advance,
Mark

[oddball]

Hey guys I am trying to use autoloading profiles to playback some problematic videos in episodic fashion. I am only able to create a profile for each episode right now which is not what I want. I need to have 2 profiles. One for episodes 1 and 15-18 and another for the episodes in between. Any ideas if.how I can do it? I can't seem to get it working with wildcards and there is a limits on the number of characters you can use on the filenames using the ; seperator method. Basically it only lets me enter 2 file names which is no good obviously. I don't want to rename the files to shorter names.

[clsid]

Hi all,
I'm seeing that clsid modified ffmpeg's makefile in rev. 3733,
the following line was added:

$(shell test -d $(@) || mkdir -p $(@))


as a result, I'm getting errors when trying to build ffmpeg using cmd.exe and MinGW (TDM), any help would be appreciated.
('test' is not recognized as an internal or external command)

Thanks,
Tal Aloni
I am not having any problems here during building. I also always use the Windows command prompt instead of MSYS.
Perhaps it depends on the version of make.exe? Can anybody else test it as well?

[clsid]

Hi tal.aloni, clsid

A discussion over on the avs forums has found that ffdshow has been causing crashes when used with avisynth but only since the following ffdshow revision so I assume its this avisynth change that was made in ffdshow. As Set hasn't gotten back to us in a few weeks, I'm wondering what the procedure is for things like this. Should the patch be backed out as according to the guys on the avs forums, it does more harm than good.

Revision 3358 - Directory Listing
Modified Thu Apr 15 08:27:07 2010 UTC (10 months, 1 week ago) by tal_aloni
AviSynth Frame accurate seeking. (patch by SEt and Jeremy Duncan)

http://forum.doom9.org/showthread.php?p=1479990#post1479990

Thanks in advance,
Mark
I don't mind if the patch is reverted if none of the Avisynth experts here can come up with a better fix.

[tal.aloni]

I don't mind if the patch is reverted if none of the Avisynth experts here can come up with a better fix.

same here,
I've notified the author of the patch a few days ago, he didn't reply yet. I'll revert it as soon as I'm able to build properly, I'll try updating mingw, I do have an older version.

Tal

[tal.aloni]

Updated to MinGW TDM 4.5.1 with Make 3.82.8,
Now I'm getting this error:

../makefile_c.inc:62: *** missing separator. Stop.


after replacing the spaces in line 62 with a TAB, I'm getting the previous error.
('test' is not recognized as an internal or external command)
any clue? which make version are you using that works?
clsid, are you sure there isn't any test.exe?

Thanks,
Tal

[mark0077]

same here,
I've notified the author of the patch a few days ago, he didn't reply yet. I'll revert it as soon as I'm able to build properly, I'll try updating mingw, I do have an older version.

Tal

Fantastic!! This will make alot of avisynth users HTPCs more stable until the patch can be readded without the crashes.

[nevcairiel]

I've been trying to figure out why ffdshow stops displaying subs after a while when used with LAV Splitter, but i have hit a wall. I was using a MKV with embedded VOB subs, and it did seem like every time there was a period of no subs being displayed (no talking), afterwards ffdshow would stop showing them, while the MPC-HC renderer happily continues. With the Gabest MKV Splitter, it works just fine.

What really puzzles me, however, is this: I used a Tee and a Dump filter and wrote the subtitle output of both the Gabest Splitter and of LAV Splitter into a file, including timestamps, flags and everything, and its perfectly identical. Unless ffdshow somehow has special handling when dealing with the Gabest MKV splitter, i don't know what the hell is going on.

I'll probably enhance the Dump filter somewhat to also write down commands like Flush and NewSegment, but i doubt that those are going over the stream mid-playback.

If anyone of you ffdshow guys has some more indeep knowledge of the subtitle code, i would appreciate any insight in the issue, as its really bugging me right now.

[mark0077]

Guys, I went to play an old space shuttle mpg file I downloaded last year to show someone and found with with ffdshow decoders, I get black / no output. I had to revert back to mpc-hc decoder. I tried with lav splitter and mpc-hc internal one, madVR renderer and evr-cp. If nobody can reproduce I'll try to make a sample if someone is interested in looking.

[ryrynz]

I don't mind if the patch is reverted if none of the Avisynth experts here can come up with a better fix.

Excellent, I posted this problem here 2 months ago.

http://sourceforge.net/tracker/?func=detail&atid=867360&aid=3158065&group_id=173941

It would have been nice to get an update on this sooner as it was easy to reproduce bug and an easy fix, I am looking forward to using new builds that don't crash.

I would like to question the bug submission process as it doesn't appear to be optimal, bugs get submitted, bugs get ignored.

[tal.aloni]

ryrynz, I apologize for that, I was responsible for the changes in rev. 3358, however, you have to realize we're all volunteers and we have other pressing matters in life, I became aware of this issue only last week (when mark0077 PMed me), next time, if possible, it would be best to narrow the bug down to a revision, and notify the developer who committed the changes as well.

mark0077, if it's just a single video and not a mpeg-wide issue, it's likely an issue with the video and not with ffdshow.

[ryrynz]

ryrynz, I apologize for that, I was responsible for the changes in rev. 3358, however, you have to realize we're all volunteers and we have other pressing matters in life, I became aware of this issue only last week (when mark0077 PMed me), next time, if possible, it would be best to narrow the bug down to a revision, and notify the developer who committed the changes as well.

I did narrow down the revision, I thought submitting through that website would have been enough and just waited it out expecting the bug submission process to follow it's course.
This process however seems to me to be somewhat ineffective, relying on the bug submitter to escalate issues rather than an administrator of the bug tracker.
I am aware of the development nature of this project and understand developers time constraints but I believe this is one area where things could certainly be improved.

[dann23]

@tal.aloni
last time I remember that you worked on implementing dxva on ffdshow and there were some improvements to make. do you plan to continue that work or we have to wait to get those improvements?

[tal.aloni]

dann23, while there are indeed several improvements that comes to mind, most of those will only be beneficial to a small subset of users.
for instance, when I tested graphic drivers to find out which supports DXVA hardware alpha blending (for subtiltes), my Radeon 4550 didn't support it at all, and my nVidia geforce 9300 onboard GPU offered very limited support (16 colors only - if I remember correctly), so I saw no point investing time there.

other improvements, like copying the decoded frame back to main memory and performing full post-processing fast enough to handle 24 1080p frames per second, require hardware architecture that can only be found on very recent systems, and those systems can decode H.264 without DXVA assistance.

Is there any specific improvement that you're interested in?
Regards,
Tal

[madshi]

other improvements, like copying the decoded frame back to main memory and performing full post-processing fast enough to handle 24 1080p frames per second, require hardware architecture that can only be found on very recent systems, and those systems can decode H.264 without DXVA assistance.
FWIW, whether copying decoded frames back to main memory is feasible depends mostly on the GPU. It seems that newer nVidia GPUs can do that very quickly. While all ATI and Intel GPUs are extremely slow doing that. I've just created a benchmark program for that and asked madVR users to test it. I've seen nVidia GPUs "download" NV12 1080p textures from GPU to main memory with up to 600fps. In contrast, all ATI and Intel GPU benchmarks are slower than the needed 24fps. The highest ATI result I have is 5fps.

[oddball]

Would it be possible to embed ffpresets and ffApresets in MKV files and have ffdshow autoload the presets from the MKV (Rather than have the file seperate with the same name)? It would make things much neater for me. I have a few encodes that require their own special presets and having a seperate preset file or having it listed under profiles is a bit messier than pulling it directly from an MKV file itself. Can you even embed a preset in an MKV?

[tal.aloni]

madshi! we're not worthy!

very interesting, thanks for the info!

[fastplayer]

@tal.aloni or any other dev:
Can you revert rev3358 and put the AviSynth users out of their misery?

[tal.aloni]

Can you revert rev3358 and put the AviSynth users out of their misery?

soon.

[tal.aloni]

Can you even embed a preset in an MKV?

theoretically yes, however, you have to add support for it for both the muxer (mkvtoolnix for example), and the demuxer (haali media splitter for example), and making ffdshow accept a preset in such a way sounds troublesome.
what's worse, it will benefit only a handful of users, I honestly don't see any reason to dedicate resources to such feature.

[madshi]

madshi! we're not worthy!
:eek:

very interesting, thanks for the info!
FWIW, with NVidia you can do this:

(1) DxvaNv12Surface.LockRect(READ_ONLY);

I've measured up to 500fps with newer GPUs. With ATI you can do this:

(1) StretchRect(DxvaNv12Surface, RgbRenderTargetTexture));
(2) GetRenderTargetData(RgbRenderTargetTexture)

That's quick enough for real time playback. Do not try to do "DxvaNv12Surface.LockRect(READ_ONLY)", you'll not get more than 5fps even with the latest ATI GPUs.

One problem with the suggested ATI solution is that you'll get the video data stretched without dithering (0 = black; 255 = white). So there may be banding artifacts. Also you probably can't influence which transfer matrix is used for the YCbCr -> RGB conversion. You can work around the banding problem by StretchRect-ing to a 10bit or 16bit RGB texture. Then you can stretch that back and dither it down to 8bit manually via CPU. Of course that costs performance (download + CPU).

[dann23]

dann23, while there are indeed several improvements that comes to mind, most of those will only be beneficial to a small subset of users.
for instance, when I tested graphic drivers to find out which supports DXVA hardware alpha blending (for subtiltes), my Radeon 4550 didn't support it at all, and my nVidia geforce 9300 onboard GPU offered very limited support (16 colors only - if I remember correctly), so I saw no point investing time there.

other improvements, like copying the decoded frame back to main memory and performing full post-processing fast enough to handle 24 1080p frames per second, require hardware architecture that can only be found on very recent systems, and those systems can decode H.264 without DXVA assistance.

Is there any specific improvement that you're interested in?
Regards,
Tal

I'm not interedted in something special. Just speed improvement. Last time I remember that you said about some work on improve performance when using subtitles.

[tal.aloni]

Last time I remember that you said about some work on improve performance when using subtitles.

now that you're mentioning it, there is one thing that we do that is not very efficient: we create an entire black frame at the same resolution as the video and then blend the subtitles to it, and then scan this frame pixel by pixel and for each pixel that has been modified we append it to the decoded frame.

it would be better to limit the scan range somehow (MPC-HC does a similar thing with their subtitle rendering), or write a new subtitle filter that is "write only" and can work directly on DXVA decoded surface.
both would improve performance somewhat (not sure how much), but any of them would require a lot of coding.


I'm not interedted in something special. Just speed improvement.

is it so bad when subtitles are on? which CPU?

Regards,
Tal

[tal.aloni]

regarding my build issues, apparently test.exe is part of msys,
and can be found in XhmikosR's MSYS/MinGW package here:
http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=
(thanks XhmikosR!)

however, I believe we should avoid another dependency, and I hope we can make do without test.exe.

[Inspector.Gadget]

Quick note for anybody upgrading to recent builds of ffdshow-tryouts, Haali splitter, and MPC-HC as I did: the culprit in lack of audio or stuttery decoding for MKV files with DTS audio, noticeably using ffdshow's libdts or libavcodec but not the MPC internal DTS decoder, is the 03/03/2011 version of Haali's splitter. Switching to the internal MKV splitter (and thus probably Gabest's external MKV splitter too) provides trouble-free decoding with both ffdshow decoders. It's a shame Haali has a track record of issuing updates that break various important functions of his splitter, but I hope this information will pre-empt some incorrect bug reports directed to ffdshow.

Edit: The above report is not particularly helpful as I was later able to play the previously problematic files even using the latest rev. of Haali's splitter without issue. Please see my immediate next post in this thread.

[dann23]

now that you're mentioning it, there is one thing that we do that is not very efficient: we create an entire black frame at the same resolution as the video and then blend the subtitles to it, and then scan this frame pixel by pixel and for each pixel that has been modified we append it to the decoded frame.

it would be better to limit the scan range somehow (MPC-HC does a similar thing with their subtitle rendering), or write a new subtitle filter that is "write only" and can work directly on DXVA decoded surface.
both would improve performance somewhat (not sure how much), but any of them would require a lot of coding.


is it so bad when subtitles are on? which CPU?

Regards,
Tal

CPU is athlon x2 6400+ :D
But what I tried to achieve is to watch movies using dxva and the cpu to stay at the lowest power state. At this state the cooler stops and it's complete silence :) The video card has a passive cooler so the main problem is the CPU :)
Right now it's almost perfect. The cooler starts from time to time and it's annoying.

[clsid]

Quick note for anybody upgrading to recent builds of ffdshow-tryouts, Haali splitter, and MPC-HC as I did: the culprit in lack of audio or stuttery decoding for MKV files with DTS audio, noticeably using ffdshow's libdts or libavcodec but not the MPC internal DTS decoder, is the 03/03/2011 version of Haali's splitter. Switching to the internal MKV splitter (and thus probably Gabest's external MKV splitter too) provides trouble-free decoding with both ffdshow decoders. It's a shame Haali has a track record of issuing updates that break various important functions of his splitter, but I hope this information will pre-empt some incorrect bug reports directed to ffdshow.So if I understand correctly, the previous version of Haali did not have this problem?

[fastplayer]

I can't reproduce this at all. DTS in MKV plays just fine.

[Inspector.Gadget]

So if I understand correctly, the previous version of Haali did not have this problem?

That's correct as far as my experience. I noticed about a week ago, using then-current 32-bit SVN versions of MPC-HC and ffdshow and the latest Haali splitter, that libavcodec wasn't decoding a 6.1 DTS-ES stream and producing any audible output; switching to libdts fixed this but IIRC broke decoding of normal 5.1 DTS streams. Thereafter, and now using rev. 3721, neither libavcodec nor libdts would decode a DTS-ES stream without major dropped video frames and audio stuttering but the internal MPC-HC decoder would apparently do so without issue. Now, using ffdshow rev 3721 and MPC-HC 1.5.1.2903 with the internal Matroska splitter enabled, I have no trouble. Haali still results in many dropped frames and audio drop-outs; the video stream is vanilla 720p level 4.1 stuff with a peak bitrate below 6mbps. The only change I've made to my system other than minor upgrades (e.g, 30 revisions or less) to MPC-HC and ffdshow is switching to the latest Haali from the previous versions; prior to that change, I had never seen any trouble with either libavcodec or libdts.

Edit: Dear all, please disregard the above as well as my prior report of behavior with DTS. Some hours later I re-opened the previously problematic files using all the same software (ffdshow 3721, MPC-HC 1.5.1.2903, latest Haali's) and didn't run into any problems. Nothing changed on my system in the interim. As I wasn't doing anything I/O or CPU intensive at the time I noticed the issues I can only hope this was a one-off problem. If it recurs in a reproduceable way, I will report it. My apologies for the false alarm.

[fastplayer]

Just a heads up: ffmpeg changed its name to libav.
Here's the "press release":
March 13, 2011

We, as a group of FFmpeg developers, have decided to continue developing FFmpeg under the name Libav. All existing infrastructure will be transferred to the libav.org domain.
Website: http://www.libav.org/
Git: git://git.libav.org/libav.git (see http://libav.org/download.html)
FATE: http://fate.libav.org/
Roundup: https://roundup.libav.org/
Patchwork: http://patches.libav.org/

You can update your git repository using the following command:

git remote set-url origin 'git://git.libav.org/libav'

For now we are still reachable over FFmpeg's mailing lists and irc channels but we will migrate to libav.org counterparts. For a transition period both the website and source might still contain references to FFmpeg. These will disappear over time, except where historically relevant.

Edit: No, they didn't... :rolleyes: See nevcairiel's post below.

[nevcairiel]

Actually, ffmpeg did not change its name. Some of the developers tried to take over ffmpeg, but got pushed back after a few weeks, so now they jump ship and start over with a new name (like they should've done from the start if they're unhappy and cannot reach consensus)

ffmpeg.org is still online, and will remain so.

I wouldn't put much into anything thats going on right now, just wait till it cools down again.

[fastplayer]

The "press release" reads like they're abandoning/replacing ffmpeg.org, at least to me...
Anyway, thanks for the info, nevcairiel! I usually only follow the commit log and not their discussions.

Edit: Looks like we've switched (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?revision=3774&view=revision)sides! :D

[tal.aloni]

changes made in rev. 3358 have now been reverted, I apologize for any inconvenience.

Tal

[mark0077]

Thanks Tal! Much appreciated.

[TheShadowRunner]

Edit: it was broken again in 3062.
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=3062

Edit: reason is discussed here:
http://forum.doom9.org/showthread.php?p=1312127#post1312127
http://forum.doom9.org/showthread.php?p=1319023#post1319023

A proper fix needs to be made that doesn't break resize/auto-crop.

So the bug is confirmed, thank you. Now how can I contact a developer able to fix this resize/auto-crop issue with FLV4, is someone in this thread up to it? (I'm an enduser and have no knowledge on how to do that whatsoever!)

[clsid]

There is nobody you can contact. Best you can do is open a bug report on the bug tracker. Then hope and wait until a volunteer comes to fix it.

[mark0077]

Guys, in the ffdshow video info area, where is the "Movie FPS" stat taken from? madshi kindly informed me that a file (maybe files) that I'm having issues with, are 24.000fps rather than 23.974 which ffdshow reports them as. Apart from visually looking wrong, something funky seems to be going on with these files with evr-cp renderer in mpc-hc showing a very "squiggly" looking green line in its graph rather than a perfectly smooth one which I come to expect. Even playing such files back at 24hz will drive evr-cp's graph mad so I can only assume these files have erratic / uneven timestamps....

Would it be alot of work for ffdshow to show the actual rate of the clip, perhaps calculated by looking at incoming timestamps? It might be very helpful, for me anyways, in debugging issues with frame rates of certain files / frame drops etc.

[ryrynz]

There is nobody you can contact. Best you can do is open a bug report on the bug tracker. Then hope and wait until a volunteer comes to fix it.

Best of luck with that.

BTW Bug 3158065 can now be closed.
Thanks Tal, I'm back to using new builds.

[LigH]

Just a heads up: ffmpeg changed its name to libav.

:eek: I'm getting curious if "ffdshow" will now be renamed too, e.g. to "avdshow" or similar... :rolleyes:

[madshi]

ffmpeg did not change its name at all, so why should ffdshow?

[VFR maniac]

ffdshow tryouts: clsid2 * r3774 /trunk/src/ (24 files in 4 dirs): Updated Libav
ffmpeg didn't change its name, but ffdshow has started to use name of libav.

[madshi]

Well, "libav" was always a synonym for ffmpeg, anyway. Even months/years ago I sometimes wrote "ffmpeg" and sometimes "libav", always meaning the same thing.

[LigH]

It looks like there are more or less two development teams and projects in parallel: The original "ffmpeg" and the forked "libav".

Now if the ffdshow developers decide to use source code from the "libav" project in the future (in favour over the "ffmpeg" sources – where a further development is not as obvious to me, I am not sure if there will be an active and competing team too), I wonder if that will be reflected in its name as well.

But not so much that it would ruin my sleep... we users will sit back and see how the whole issue develops.

[madshi]

Renaming a well known project usually doesn't make sense. E.g. my project "eac3to" has a really weird name. It's named that way because the very first version did nothing but convert E-AC3 to other formats. But now in the latest versions converting E-AC3 to other formats is like 0.1% of the functionality. The name should really be something completely different. But it doesn't make sense to rename it now because everybody knows it under its current name. In the same way it wouldn't make sense to rename ffdshow, because everybody is much too used to the current name.

[clsid]

Renaming is indeed a bad idea and won't happen.

[srv]

Hi All!
Simple question.
AAC encoder is supported in ffdshow ?
Thanks!