New FFmpeg-based DirectShow decoder

[Andrey O.]

We have uploaded a new FFmpeg-based multi-format DirectShow source filter.

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]

Originally Posted by betaking

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) 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. 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. 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
shareware

[Andrey O.]

Originally Posted by LoRd_MuldeR

Sound like yet another LAV Filters. 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.

[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]

Originally Posted by Andrey O.

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]

Originally Posted by pirlouy

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