LAV Filters - DirectShow Media Splitter and Decoders

[tobindac]

I'll drop a note. The splitter appears unable to see different channels on an MPEG-TS file (recorded on VLC from a digital tv tuner). The Haali Splitter appears to normally offer to change channels in the stream.

[Vasilich]

what channels? do you mean several video streams?
part of that recorded file can help to analyze.

[nevcairiel]

Multi-Program TS streams are not supported. You will just get one program of LAVs choosing.

[tobindac]

Multi-Program TS streams are not supported. You will just get one program of LAVs choosing.

Haali does give a choice to selecte a Channel/Program, but it doesn't let you seek!

[littleD]

It would be nice to have issue #3 fixed ;)

[Blight]

nev:
I've been testing hardware accelerated video decoding on one of the new breed of sub-$99 windows 8.1 tablets.
In this case, it's a 7" 1280x800 running on Intel Baytrail Z3735G Quad-core processor with 1GB of ram.

I tried playing an 1080p h264/aac clip and I'm getting some strange results:
Software decoding : 40% CPU
QuickSync : 44% CPU (active decoder "quicksync")
DXVA Copyback : 72% CPU (active decoder "dxva2cb")
DXVA native : 3% CPU (active decoder "dxva2n")

This is with EVR used as the video renderer.

I also tried the same file on an Asus T100 10" convertible 2-in-1 running on an Intel Baytrail Z3740 with 2GB ram and received the same results.

Does it make sense that the memory overhead of the copy-back function used in QuickSync and DXVA2-Copyback takes so much CPU power that it is even slower than software decoding?

[andyvt]

nev:
I've been testing hardware accelerated video decoding on one of the new breed of sub-$99 windows 8.1 tablets.
In this case, it's a 7" 1280x800 running on Intel Baytrail Z3735G Quad-core processor with 1GB of ram.

I tried playing an 1080p h264/aac clip and I'm getting some strange results:
Software decoding : 40% CPU
QuickSync : 44% CPU (active decoder "quicksync")
DXVA Copyback : 72% CPU (active decoder "dxva2cb")
DXVA native : 3% CPU (active decoder "dxva2n")

This is with EVR used as the video renderer.

I also tried the same file on an Asus T100 10" convertible 2-in-1 running on an Intel Baytrail Z3740 with 2GB ram and received the same results.

Does it make sense that the memory overhead of the copy-back function used in QuickSync and DXVA2-Copyback takes so much CPU power that it is even slower than software decoding?

FWIW, I noted similar results with the Baytrail NUC. In that case I think it is because of the RAM speed and that it is single-channel. If the devices that you are testing are configured in a similar way (one channel of slow RAM), it probably memory overhead as well.

That said, you can't rely on utilization % by itself if the chip supports dynamic throttling. To make it useful you have to normalize % to current frequency.

[nevcairiel]

Native DXVA2 is really the only mode that is going to work reliably on such low power devices. That said, the upcoming LAV version with the new DXVA2-CB Direct mode should reduce its CPU overhead significantly, somewhere below the QuickSync number, and presumably below software decoding as well.

[NikosD]

Does it make sense that the memory overhead of the copy-back function used in QuickSync and DXVA2-Copyback takes so much CPU power that it is even slower than software decoding?

You could try latest nightly version 0.63.0.75 with the new DXVA Copy-Back direct enabled and post your results if you see any difference.

[P.J]

Anyway to boost the volume in stereo ac3 tracks? PowerDVD can do it very well but LAV Audio :(

[nevcairiel]

LAV is a decoder, not a volume booster.

[LigH]

ffdshow has post processing features for audio too. LAV Filters are rather pure, in comparison.

[P.J]

LAV is a decoder, not a volume booster.

I mean the Dynamic Range setting: :confused:

http://phota.me/zYIy.png

[Snowknight26]

The most you can do is change the mixing levels from 0.71 to 1.0. Otherwise you'll need something like ffdshow.

[Schwartz]

32 bit MPC-HC, madVR, internal LAV Filters 0.63.0.52: DXVA native works.
64 bit Media Player .NET, external LAV Filters 0.63 or 0.63.0.75: DXVA native falls back to avcodec.

Using Windows 8.1, ATI R9 270x, Catalyst 14.12. Playing MPEG4 Video (H264).

Is there a way to fix this?

[huhn]

32 bit MPC-HC, madVR, internal LAV Filters 0.63.0.52: DXVA native works.
64 bit Media Player .NET, external LAV Filters 0.63 or 0.63.0.75: DXVA native falls back to avcodec.

Using Windows 8.1, ATI R9 270x, Catalyst 14.12. Playing MPEG4 Video (H264).

Is there a way to fix this?

MPDN has to support native DXVA and it looks like it doesn't do that.
you can use copyback. not sure if the new copy back direct which is not released yet will work with MPDN.

[06_taro]

copyback direct works with MPDN.

[Anakunda]

Where's LAV 0.64 to download? (I don't want source codes)

[huhn]

Where's LAV 0.64 to download? (I don't want source codes)

it's not released yet. the newest official nightly builds are always here:
http://files.1f0.de/lavf/nightly/

[Anakunda]

Oh, to soon. It's here tho
https://github.com/Nevcairiel/LAVFilters/releases/download/0.64/LAVFilters-0.64-Installer.exe

0.64.0 - 2015/02/13
General

NEW: Individual LAV Filters can now be blacklisted through the registry by creating a key with the executable name in HKCU\Software\LAV<Filter>\Blacklist

LAV Splitter

NEW: Support for RTMP using rtmpdump-style parameter syntax
NEW: Support for Opus-in-TS
Fixed: The language reported for audio/subtitle streams on some Blu-rays could be wrong

LAV Video

NEW: HEVC Main10 decoding in DXVA2 Copy-Back mode
Faster: DXVA2 Copy-Back in direct output mode uses up to 50% less CPU and performance is improved accordingly
Fixed: H.264 streams with only DTS timestamps would play out of sync with DXVA2
Fixed: DXVA2 could crash on some MPEG-2 streams
Fixed: Improved compatibility with a few HEVC streams when using DXVA2

[nevcairiel]

LAV Filters 0.64

General
- NEW: Individual LAV Filters can now be blacklisted through the registry by creating a key with the executable name in HKCU\Software\LAV\<Filter>\Blacklist

LAV Splitter
- NEW: Support for RTMP using rtmpdump-style parameter syntax
- NEW: Support for Opus-in-TS
- Fixed: The language reported for audio/subtitle streams on some Blu-rays could be wrong

LAV Video
- NEW: HEVC Main10 decoding in DXVA2 Copy-Back mode
- Faster: DXVA2 Copy-Back in direct output mode uses up to 50% less CPU and performance is improved accordingly
- Fixed: H.264 streams with only DTS timestamps would play out of sync with DXVA2
- Fixed: DXVA2 could crash on some MPEG-2 streams
- Fixed: Improved compatibility with a few HEVC streams when using DXVA2

Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.64.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.64.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.64-x64.zip)

DXVA2 HEVC Main10 (10-bit) support

LAV Video now supports 10-bit HEVC decoding through DXVA2, on hardware which supports the Main10 profile!
It has been developed and tested on the NVIDIA GTX 960, which is the first desktop GPU with a full hardware HEVC decoder, and it works quite nice and fast (4k @ 100-120 fps)

At this time I have no information if it also works on Intels Main10 decoding on the Broadwell iGPU, since I do not have access to such hardware.

Note that at this time 10-bit decoding is limited to DXVA2 Copy-Back mode, because the video renderers did not want to cooperate in Native 10-bit mode.

DXVA2 Copy-Back "Direct" mode

To reduce the CPU overhead and the speed limitations of the DXVA2 Copy-Back mode, LAV Video 0.64 introduces a new "Direct" mode.
Direct Mode reduces the CPU overhead by up to 50%, resulting in significantly reduced CPU usage figures.

The concept is simple: When possible, LAV Video will do one processing step less, and try to copy the video image from the GPU to the video renderer as directly as possible.
This has a few limitations however. It only works in specifically designed output paths, specifically NV12 decoding -> NV12 output, P010 decoding -> P010 output, and P010 decoding -> NV12 output.
In addition, direct mode cannot be used when YADIF deinterlacing is required.

Direct Mode is not an option, it'll simply turn on when its possible to be used, and turn off when not (ie. with YADIF or when an unsupported conversion is required).

More...

Everything else should be pretty self-explanatory. Nothing too fancy. RTMP is now officially supported using the same parameter syntax as librtmp/rtmpdump use. The feature was contributed by the MPC-HC authors.
Opus in MPEG-TS streams can now be demuxed and decoded. To make this possible, Opus is now decoded by the "native" ffmpeg Opus decoder, and no longer libopus.

Soon..

I have some plans to work on a few of the long standing feature requests and a few of my own ideas very soon, so a new feature push may not be too far out.

In any case, have fun!

PS:
Impatient people, don't even allow an hour to post the versions everywhere and write a post, jeez.

[huhn]

direct mode even works with xy vsfilter nice.

[Virtual_ManPL]

Thank you very much nevcairiel, good job! :thanks:
64bit build performance is really getting more and more awesome in HEVC decoder, compared to 32bit one. :cool:

[madshi]

Is there anything specific the renderer has to do to make direct mode work, or to optimize performance, or anything like that?

[Blight]

nev:
Will DXVA2-CD directmode improve performance when using "lav video -> directvobsub -> evr" ?

[wanezhiling]

EVR doesn't support native 10-bit mode, how about madVR?

[nevcairiel]

Is there anything specific the renderer has to do to make direct mode work, or to optimize performance, or anything like that?

Just the usual, make sure memory buffers are using at least 16-byte aligned allocations, and the stride it requests is at least 16 pixel aligned.
Most renderers do this anyway. Post-processors like ffdshow don't always do it.

nev:
Will DXVA2-CD directmode improve performance when using "lav video -> directvobsub -> evr" ?

Maybe. DirectVobSub is stupid. It can help if the video width is mod 16 (common 1920, 1280, ... are OK), if its not, then Direct Mode doesn't work with DirectVobSub, since it doesn't request a stride from the video decoder.

[manolito]

Thanks a lot for the new version... :thanks:

Somehow I can't get the blacklist feature working. :stupid:

Tried it with these formats, but both do not have any effect:

http://i59.tinypic.com/2j6wk6.jpg

http://i57.tinypic.com/b4jokw.jpg


Please explain the exact way how to add this to the registry...


Thanks
manolito

[nevcairiel]

It needs to be a DWORD value with the name of the executable as name and a non-zero value, so "avstodvd.exe" with value "1" should work.
You can set it to 0 to disable the blacklist for that process, which makes testing easier than always deleting and re-creating the entry.

[manolito]

Thanks very much, I would never have found this by myself...


Cheers
manolito

[STaRGaZeR]

Thanks for the new version!

[JarrettH]

This has likely been asked in the past, but what is a situation for needing hardware decoding? On my machine, an old one (Core 2 Duo E6600, GTX 550 TI), using hardware decoding makes my rendering times in madvr slower, and back home on my Mom's i3 with a GT 730, it also is unnecessary. Are we past the point where hardware decoding is relevant? :thanks:

[huhn]

This has likely been asked in the past, but what is a situation for needing hardware decoding? On my machine, an old one (Core 2 Duo E6600, GTX 550 TI), using hardware decoding makes my rendering times in madvr slower, and back home on my Mom's i3 with a GT 730, it also is unnecessary. Are we past the point where hardware decoding is relevant? :thanks:

than try to use software decoder for UHD with 80+ mbit.

with stuff up to 40 mbit AVC and a CPU like a i3 it's not really needed and using hardware decoding with a powerful GPU can easily waste power and doesn't save any. but for HEVC we will need hardware decoder again.

a PC with a INTEL iGPU can save a lot of power by using hardware decoding. and it is totally needed for mobile devices.

[SithUK]

I have experienced a stuttering issue with playback using mpc HC recently. I investigated and found the issue was with insufficient buffering with LAV filter. I've copied the post in the original thread below.

http://forum.doom9.org/showthread.php?t=153450


I have found a fix to the stuttering issue.

The stuttering issue is due to the buffer size not being the 256MB set under "Maximum Queue Memory" in the splitter settings (view->options->internal filters). I observed a significantly smaller buffer size of approximately 10MB instead of 256MB.

The smaller buffer size was insufficient to deal with the performance variability over my wireless network.

The fix involves using a hex editor to modify the LAVSplitter.ax file in the LAVfilters subfolder of the MPC-HC installation folder. The details of the fix are at the following link.

http://superuser.com/questions/84220...e-aggressively

I have carried out the fix on version 1.7.7 of MPC-HC and can verify that it resolved my buffering issue. I can see that the program is buffering 256MB instead of approximately 10MB when I turn on "statistics" (view->statistics).

Playback performance has been rock solid since.

[sneaker_ger]

64bit build performance is really getting more and more awesome in HEVC decoder, compared to 32bit one. :cool:
I am testing HEVC 64 bit decoding performance from time to time and could not measure any improvements compared to 0.63 (when Nev ported all those HEVC optimizations) at all. (Core i7-860)

[clsid]

There have been a whole bunch of HEVC improvements in the past week. So performance will be even better once Nev updates FFmpeg again. Good news is that new optimizations for x86 have been added as well.

Thanks for the new version!

[JarrettH]

:readfaq:than try to use software decoder for UHD with 80+ mbit.

with stuff up to 40 mbit AVC and a CPU like a i3 it's not really needed and using hardware decoding with a powerful GPU can easily waste power and doesn't save any. but for HEVC we will need hardware decoder again.

a PC with a INTEL iGPU can save a lot of power by using hardware decoding. and it is totally needed for mobile devices.

Thanks. And yeah, none of what I decode is as intensive as a blu-ray.

Is DXVA2-CB preferred over Quicksync? I thought I read something about Quicksync not being recommended (this is for a laptop)

[Snowknight26]

It seems like with 0.64, seeking in an H.264 stream with DXVA on causes pixelation for the first frame after the seek. At least it happens consistently with my R9 290 on Windows 7.

[foxyshadis]

than try to use software decoder for UHD with 80+ mbit.

with stuff up to 40 mbit AVC and a CPU like a i3 it's not really needed and using hardware decoding with a powerful GPU can easily waste power and doesn't save any. but for HEVC we will need hardware decoder again.

a PC with a INTEL iGPU can save a lot of power by using hardware decoding. and it is totally needed for mobile devices.

AVC hardware decoding is NEVER wasting power, it's always going to be lower-power than CPU decoding because it's dedicated low-power hardware. The last AMD/NVidia GPUs that used hybrid decoding were released in 2006, and Intel has always either supported it totally (since 2009) or not at all, no hybrid option. Using hardware decoding lets both your CPU and GPU clock down to minimum, assuming you don't use a lot of fancy post-processing.

[huhn]

AVC hardware decoding is NEVER wasting power, it's always going to be lower-power than CPU decoding because it's dedicated low-power hardware. The last AMD/NVidia GPUs that used hybrid decoding were released in 2006, and Intel has always either supported it totally (since 2009) or not at all, no hybrid option. Using hardware decoding lets both your CPU and GPU clock down to minimum, assuming you don't use a lot of fancy post-processing.

the problem is the GPU enters a mid powerstate or with CUVID even highest powerstate and this eats on powerful cards more power than CPU decoding.

they don't stay at min clock. of course i can't say this for all cards i don't have all.
and hybrid decoding is back in intel and nvidia with HEVC in nearly all cards but that's not the point here.

[nevcairiel]

the problem is the GPU enters a mid powerstate or with CUVID even highest powerstate and this eats on powerful cards more power than CPU decoding.

they don't stay at min clock. of course i can't say this for all cards i don't have all.
and hybrid decoding is back in intel and nvidia with HEVC in nearly all cards but that's not the point here.

NVIDIA at least doesn't do this with DXVA2 decoding, its pure load based scaling.
CUVID is special since it uses CUDA, which always forces the GPU into max performance mode for the best performance. Personally I see no use for either CUVID and QuickSync these days anymore, though.

[huhn]

NVIDIA at least doesn't do this with DXVA2 decoding, its pure load based scaling.
CUVID is special since it uses CUDA, which always forces the GPU into max performance mode for the best performance. Personally I see no use for either CUVID and QuickSync these days anymore, though.

I think quicksync can be very useful when used in a PC with a powerful GPU that's is entering a mid powerstate when using DXVA. but about CUVID I don't see a use for it too.

looks like NVIDA does a good job on this topic. unlike my not used AMD 6770 that enter mid powerstate when DXVA is used and can't even go to high performance mode.

[Virtual_ManPL]

Is there anything specific the renderer has to do to make direct mode work, or to optimize performance, or anything like that?

How about finally releasing madVR which supports 64bit? :devil:
It will be a nice performance boost, especially when some decoders are clearly better in 64bit, than in 32bit builds.

I am testing HEVC 64 bit decoding performance from time to time and could not measure any improvements compared to 0.63 (when Nev ported all those HEVC optimizations) at all. (Core i7-860)

I never said that I'm comparing performance of only 2 latest builds of LAV Filters (0.63 and 0.64 ones).
My point was that comparing first release of LAV Filters (0.59 version) with H.265/HEVC support and the latest one (0.64 version),
we can see that 64bit build performance is really getting better and better in HEVC decoder, compared to 32bit one build with each new release.
Finally the 64bit builds are getting serious attention. :cool:

[sneaker_ger]

Well, 0.63 is old. The git had the optimizations in August 2014, that's why I had to wonder about your comment. It's not getting better and better with each new release, it got better once 6 months ago.

[DragonQ]

Personally I see no use for either CUVID and QuickSync these days anymore, though.

Hardware deinterlacing + post-processing.

[huhn]

Hardware deinterlacing + post-processing.

the CUVID deinterlacer is the same as the DXVA.

[DragonQ]

the CUVID deinterlacer is the same as the DXVA.
Don't see how that's relevant.

[aufkrawall]

CUVID is special since it uses CUDA, which always forces the GPU into max performance mode for the best performance.
Almost. At least with Maxwell 2, memory doesn't run with full clock in CUDA P2 state.
But not very relevant regarding energy consumption.

With GTX 960, HEVC decoding is still ALU-hybrid? Or just with 10 bit?

[Gravitator]

Can make a binding decoder to the format? I need to H.264 through CUDA, and H.265 through DXVA2 (priority decoder/format).

[nevcairiel]

With GTX 960, HEVC decoding is still ALU-hybrid? Or just with 10 bit?

Both 8 and 10-bit are 100% decoded by a dedicated ASIC on the GTX 960.