LAV Filters - DirectShow Media Splitter and Decoders

[Aleksoid1978]

There is no Atmos/DTS:X decoder. ffmpeg can decode only TrueHD/DTS.

[jaytrinitron]

Originally Posted by Aleksoid1978

There is no Atmos/DTS:X decoder. ffmpeg can decode only TrueHD/DTS.

Oh yeah I had forgot there was nothing for PC that decodes that. But Atmos and DTS:X have a DTS-HD MA and TrueHD core right? And what about on the video side? Can I still put a UHD disc in and have MPC-HC play it, with HDR, 4k, 10 bit and all the rest (using LAV)?

[nevcairiel]

Originally Posted by jaytrinitron

Oh yeah I had forgot there was nothing for PC that decodes that. But Atmos and DTS:X have a DTS-HD MA and TrueHD core right? And what about on the video side? Can I still put a UHD disc in and have MPC-HC play it, with HDR, 4k, 10 bit and all the rest (using LAV)?

If you have a way to decrypt the disc, it should work.

[PCU]

i don't know why, but the quality of d3d11 hardware acceleration is so much better than intel quicksync.

[Klaus1189]

I use latest versions of MPC-BE x64, LAV Filters and madVR and MPC-BE crashes when I play a file recorded with my STB. Going back to 0.71.0-5 works fine.

EDIT: reinstalled latest LAV 0.71.0-8, now it is fine. I don't know what it was.

[P.J]

Why does AYUV use about twice more CPU rather than RGB32 for 4:4:4 10bit videos?

[neno]

Hi, nevcairiel. I use lav 0.71 with latest madVR in D3D11 native mode, and the picture is always(no matter what video) split into the top and bottom part. The top part is the picture content turned into a flat size, and the bottom part is often a green image.
While D3D11 CB can just play normally.
I use WIN10 and a RX480.
Is there any idea about the problem?
Thanks.

[nevcairiel]

Sounds like a driver problem to me. But you'll probably want to talk to madshi instead, since madVR handles the processing of "native" frames.

[JarrettH]

Did anything change with the audio mixing or DRC since the last stable version?

I can't decide now whether to use software or D3D11. Versus software, D3D11 is a bit faster on native 1080p movies and slightly slower when upscaling (for example 720p) is involved.

[steakhutzeee]

Hi, can you give me details about this?

D3D11 hardware accelerated decoding (native mode with madVR, Copy-Back otherwise).

Can't update lav/madvr now. This means in madvr there is a new D3D11 option?

Just curious, btw I'll update these days. Thanks

[sneaker_ger]

https://forum.doom9.org/showpost.php...ostcount=22604

[kolak]

Originally Posted by nevcairiel

PCs cannot stay in YUV. Its always RGB at some point. Basically you always have to feed RGB to the GPU, even if the GPU then outputs YUV again (which should therefor be avoided, if possible).

What about OpenGL?

[nevcairiel]

The final frame buffer is always RGB.

[kolak]

Thank you.
Is it really a problem assuming we convert YUV<=>RGB at high precision? All high-end grading/finishing tools operate on GPU so on RGB (even if source is YUV based) and no one really questions this.
I assume this is not end of the world (if done accurately) as at the end signal will became RGB anyway (at the display).

If we talk about pure transcoding then this should be avoided (as in this case it's much easier).

[nevcairiel]

No, its perfectly fine. There is just a bit of loss in every YUV<->RGB conversion due to potential rounding, so if you do something like YUV (file) -> RGB (frame buffer) -> YUV (HDMI) -> RGB (display), thats a lot of conversions. Best would of course be to do YUV (file) -> RGB (everywhere else), but a lot of things don't necessarily support that.

[kolak]

So in case of a player if you can send RGB over HDMI it's better to set output to RGB to limit number of conversions.

In the same time if you use e.g. DisplayPort 1.2+ connection to your "end monitor", which supports RGB for "all" signals (at least up to UHD 60p 10bit) then you don't really loose quality at all compared to some pro equipment which can send YUV data "as is" to monitor. In both cases you end up with 1x YUV->RGB conversion for YUV based source (assuming your player path is well designed). The difference is that conversion happens at different stage.
For high-end work which is RGB based (from source) you are actually gaining quality and reducing delay which is always present with additional pro cards (data has to go from GPU to the card).

[pkirill]

Hello Hendrik, thanks for the great project.
We are making an educational application (CoSpaces) and we need to be able to play mp4 and m4a audio in our app.
We have many target platforms: WebGL, iOS, Android, and Windows.
All we know that on Windows DirectShow stack does not support playing m4a out of the box.
So I have two questions here:

Is it possible to include you binaries into our app ?
Is it possible to use you binaries inside the app (in our process) without COM registration on the admin level, having only user level rights.
To build a FilterGraph over a m4a with you splitter in the process.

Thanks
-Kirill

[LigH]

LAV Filters is a DirectShow interface for the libavcodec / libavformat libraries, the kernels of the ffmpeg project. To create platform independent software, you may better focus on using the kernel libraries, rather than subtracting DirectShow from this one, I believe... mplayer derivates and VLC may be the more useful places to start from, IMHO.

[pkirill]

Originally Posted by LigH

LAV Filters is a DirectShow interface for the libavcodec / libavformat libraries,

That is exactly what I need.
I need only windows implementation, all other plaforms has build in playing capabilities.

[LigH]

But you don't want to install them as DirectShow filters system-wide?

MPC-HC uses LAV Filters as "internal splitter/decoder", and the AviSynth plugin DSS2Mod (to be found e.g. in the Xvid4PSP project, or in the AviSynth Wiki) can do that as well. If you have developers who are able to read their C/C++ sources, you will most probably find how they do that directly, bypassing DirectShow automatic graph building.