New FFmpeg-based DirectShow decoder

[Andrey O.]

We have uploaded a new FFmpeg-based multi-format DirectShow source filter (http://blog.medialooks.com/0LyGa6/).

This filter makes things more predictable and reliable by replacing multiple filters (readers, splitters & decoders) with just one.

It also supports reverse playback & fast seeking.

User feedback would be very welcome. :)

[betaking]

I have a question? FFMPEG can be used for a commercial license it?

[fagoatse]

I have a question? FFMPEG can be used for a commercial license it?

yes, but you have to publish any source code changes you've made to it.(correct me if im wrong)

[Andrey O.]

Yes, it is possible to use FFmpeg in commercial (non-free) applications.

FFmpeg (except for several optional parts such as the x264 encoder) is licensed under the GNU Lesser General Public License (LGPL (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html)) version 2.1 or later. Here's a quote that explains the logic behind this license:

"Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.

[...] However, the Lesser license provides advantages in certain special circumstances.

For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library."

There are however, a bunch of things the vendor has to do in order to comply with the license. FFmpeg has its own LGPL compliance checklist (http://ffmpeg.org/legal.html). I would only add to it that the text of the license itself should also be distributed.

[LoRd_MuldeR]

Sound like yet another LAV Filters (http://forum.doom9.org/showthread.php?t=156191). How does this project compare to LAV Filters? LAV Splitter, LAV Video and LAV Audio combined in one filter?

[pirlouy]

Maybe you don't want to talk about it, but are there any advantages compared to LAV Filters (+ default Windows decoder) ?
Edit: Arf, toasted.

[kerimcem]

Standard €950
Pro With MXF, LXF and
closed captions support €1450:devil:
shareware :(

[Andrey O.]

Sound like yet another LAV Filters (http://forum.doom9.org/showthread.php?t=156191). How does this project compare to LAV Filters? LAV Splitter, LAV Video and LAV Audio combined in one filter?

Roughly speaking, yes. However, this design has led to the possibility of implementing at least the following features:

- Seamless file switching. You no longer need to use multiple graphs if you want to implement gapless file playback.
- Reverse playback, even for files with temporal compression (H.264, MPEG-2, MPEG-4).

Both are difficult to implement within the traditional approach.

More detailed argumentation is available in the post (http://blog.medialooks.com/0LyGa6/).

[dukey]

How would you handle a DXVA supported file type say, H264, and then changing to VC1 which the graphics card might not support in DXVA mode

[Andrey O.]

We don't use DXVA. We decode with the CPU only. If we were to use GPUs, we would interface with the cards directly.

Anyway, why would you want to use GPUs for decoding? We have never observed such a need.

[Guest]

Anyway, why would you want to use GPUs for decoding? We have never observed such a need. To offload from the CPU the decoding load when transcoding, saving more CPU for the encoding. Also, to utilize features on the GPU such as deinterlacing and resizing, again offloading that from the CPU. Finally, many streams are properly handled by the GPU decoder while not being handled correctly by some well-known software decoders (e.g., interlaced VC-1 etc.).

[dukey]

My pentium 4 machine is not fast enough to decode a lot of H264 without hardware acceleration.

[Qaq]

I use to listen to a movie sound and not to a fan noise. I only use SW decoding for low bitrate videos.

[pirlouy]

GPU decoding is not recommended IMO. You're too much dependent from a driver, and Nvidia and AMD/ATI have proved to suck at releasing correct drivers. Maybe it's Windows fault, but as much as possible, I think it's better to use software decoding.
And if you're ready to buy this decoder, I guess your computer can handle software decoding easily.

I'm not ready to buy this filter, but it's nice to have more choices and new ideas. Good luck with your directshow filter. :)

[Guest]

Nvidia and AMD/ATI have proved to suck at releasing correct drivers This is grossly false and inflammatory. My thousands of users of DGDecNV will attest to that. The nVidia drivers succeed admirably on several difficult stream types that fail miserably with some well-known software decoders. And nVidia is always keen and fast to correct issues that are brought to their attention.

[pirlouy]

Ahh. Good for you.
But it won't change my opinion on what I think about their drivers. I had several issues with nVidia some years ago, that I swore I would not buy nVidia again. Then I took an ATI, but there were also problems, and I've read Intel users have their difficulties too. So in the end, they are all the same to me.

But I am not a developer, and my opinion was just as a basic user, which certainly explains our different points of view.

For the decoding being better with CUDA, I'm a bit surprised, it can help if your CPU is not good enough, but I don't understand what you call "fail miserably". Not enough power, or just bad decoding ? If it's the later, it just means it's a bug.

[Guest]

I'm talking about outright bugs, that have not been corrected after a long time and being well known. Just a bug, no problem, eh? OK for software but not GPU? Anyway, you gave your opinion, and me mine. Now let's stay on topic.

[Andrey O.]

Thank you, guys.

Because x264 is GPL-based and very difficult to license for commercial use, we'll be challenged to build GPU-powered encoders for the 3 main vendors (ATI, Nvidia and Intel).

Once we are done with that and if we have enough requests for GPU-powered decoding, we'll consider implementing it as well.

[Guest]

Andrey we are talking about decoding on the GPU, not encoding.

[TheElix]

Wow, it's very glitch-y for a €950 product. I wasn't able to use it with MPC-HC.
http://imageshack.us/photo/my-images/36/nnh0.png

[iSunrise]

@Andrey
Does the trial change any directshow, registry or other specific settings if I would just give it a testrun and remove it afterwards? Don´t want to mess up anything on my production system. Thanks! (Yes, I have backups.)

Software-decoding only is perfectly fine for me, even though I never really encountered serious issues with NV hardware, GPU decoding should only be considered if everything else (the base) is already rock-stable. Every additional element that is not entirely in your control would contribute to potential problems. But it´s nice that you consider implementing GPU-decoding for the future. In some cases (they may not be very common), where you have very heavy clips, the heavy burden on CPU decoding only may limit the use of your filter. And since you want to target professionals here, it should also cope with these cases.

Also, like neuron2 has already mentioned, even software-decoding has it´s problems, e.x. with interlaced VC-1. For a filter that costs $950 at least, it should be able to perfectly deal with that, too (not just because of the reason, that it´s also used on Blu-Rays).

[Andrey O.]

@Andrey
Does the trial change any directshow, registry or other specific settings if I would just give it a testrun and remove it afterwards? Don´t want to mess up anything on my production system. Thanks! (Yes, I have backups.)

No. We don't use merits and we don't register any extensions, so even if you don't remove it the performance of other tools will not be affected.

Would be happy to hear what you think.

[xabregas]

Roughly speaking, yes. However, this design has led to the possibility of implementing at least the following features:

- Seamless file switching. You no longer need to use multiple graphs if you want to implement gapless file playback.
- Reverse playback, even for files with temporal compression (H.264, MPEG-2, MPEG-4).

Both are difficult to implement within the traditional approach.

More detailed argumentation is available in the post (http://blog.medialooks.com/0LyGa6/).

Gapless playback???

I have lav filters + cuda + madvr and i have no frame drops, no gapless, perfect smooth playback for free...

And u forgot about the people who need to playback some videos with scaling 720p to 1080p, doing that by CPU u will need several CPUS within a limited amount of time, and the power?

:sly:

For that price i would buy a decent CPU and GPU to handle 4k playback with madvr JINC :D

[Andrey O.]

Gapless playback???

I have lav filters + cuda + madvr and i have no frame drops, no gapless, perfect smooth playback for free...

Are you sure we understand the same thing under "gapless playback"? We understand this (http://en.wikipedia.org/wiki/Gapless_playback), but for video. Back where we come from (the TV industry), this is the #1 requirement for software players.

Suppose you are building software for the following use case. A playlist is being played out to a Blackmagic I/O device and broadcast through an external encoder. To change from one file to the next one on the playlist you'll need to stop the graph, kill it and build another one. This will result in loss of signal on the output of the Blackmagic regardless of how powerful your CPUs and GPUs are. This is just the nature of DirectShow.

You can avoid this problem by using multiple graphs, but it will take much more time to finish your product. A good theoretical intro on this can be found on the GMFBridge web site (http://www.gdcl.co.uk/gmfbridge/). Compare it to writing a single line of code, which is: IFileSourceFilter::Load().

On a side note, our filter can also change audio tracks and TS programs on the fly (without stopping and re-building the graph).

This is to emphasize that our filter is not an end-user product. I completely agree that for this price you can get yourself a new computer, let alone a CPU. But when someone's building a business app, they take into account the time and effort it takes and they compare it against vendors that are often more expensive.

[Andrey O.]

And u forgot about the people who need to playback some videos with scaling 720p to 1080p, doing that by CPU u will need several CPUS within a limited amount of time, and the power?

Not sure what you mean.

The only use case we could think of is - again - playing out to an external device such as Blackmagic or Deltacast. In this case we'll connect to the device with a set of parameters and we'll scale the video before the renderer in order to make sure the output parameters are consistent.

When people play videos to the screen, scaling (and deinterlacing) happens on the side of the renderer and is usually done by the GPU. Including the case when our filter is used for decoding.

[iSunrise]

No. We don't use merits and we don't register any extensions, so even if you don't remove it the performance of other tools will not be affected.

Would be happy to hear what you think.
Just went through some of my files that I usually use for testing.

Questions:

1) I can´t access the filter properties in PotPlayer. It´s greyed out. Do you know why that is?
2) I can´t find an audio stream switcher (is that hidden under the filter properties?)
3) Is there a way to configure the output colorspace?
4) I encountered several crashes when playing/skipping files on PotPlayer and on GraphStudio (e.x. when I adjusted the rate-control slider)

It doesn´t seem to be ready for prime-time, yet.

[Vsevolod]

Hello, i'm developer if this filter. The answer delayed, as i'm need to wait 5 days, before forum allow me to post replies :)


1) I can´t access the filter properties in PotPlayer. It´s greyed out. Do you know why that is?

Hmm.. No.. I'm check filter with PotPlayer, and the PP really not displayed. What interesting - for other our filters (e.g. Quicktime Source) the PP displayed ok. We will investigate this issue...


2) I can´t find an audio stream switcher (is that hidden under the filter properties?)

Yes, you are right - you can switch audio track via property page (for PotPlayer it's not available :( ), via interface call e.g. pMFSource.PropsSet( "audio_track", "2"), or via registry you can specify the default audio track:
[HKEY_CURRENT_USER\Software\MediaLooks\MFormats\MReaderDS]
audio_track='2'


3) Is there a way to configure the output colorspace?

The output format (including colorspace, resulution, aspect_ratio, etc.) can be configured via IAMStreamConfig::SetFormat() call on output pin.
- By default filter output is 4:2:2 YUV (UYVY) for files with 4:2:0, 4:1:1, 4:2:2 YUV pixel formats, or RGB32/ARGB32 for files with 4:4:4 RGB or for files with alpha channel.

The other picture/scaling properties e.g. interlace type (top, bottom, progressive), fields swaping, aspect_ratio, scaling type (letter-box, crop, none), cropping, mirroring of images can be adjusted via property page.

Btw. Why you want to change the output colorspace ?


4) I encountered several crashes when playing/skipping files on PotPlayer and on GraphStudio (e.x. when I adjusted the rate-control slider)

Can you more detailed describe this problem ?
- does crashes occurs during reverse playback or during forward playback ?
- can you provide link to files on which we can repeat this problem ?

I'm ask, as for now, we have some issues with reverse playback of certain files (especially with wrong pts), and working for improve filter stability.

Btw. The new version of filter available, in this version we improve property page - now it's have list of properties what could be changed during playback, add x64 support, add 'crop', 'mirror' properties, latest FFmpeg build used (e.g. for H.265 decoding) and have some other improvements.
(unfortunate PP still not displayed in PotPlayer :( )

[sheppaul]

I just wonder if this is a directshow decoder for general use (end users).

[Andrey O.]

sheppaul, thanks for asking. At this moment we target developers only. However, if you tell us how exactly you want to use the filter, we can eventually come up with alternative ideas.