LAV Filters - DirectShow Media Splitter and Decoders

[clsid]

It does not support (or need) wildcard characters. Just search for lav and it will show everything that contains that string.

[nevcairiel]

I have a question regarding the WEBVTT support added in latest nightly build:
https://github.com/Nevcairiel/LAVFilters/issues/80

I made a testfile and muxed a WEBVTT subtitle into a MKV using latest continuous build of MKVToolNix 55.0:
https://drive.google.com/file/d/1euLqLi02YvRhWqpx99clO2NvWwRjnnWv/view?usp=sharing

Subtitle is not listed in MPC-BE, but if I use internal filters it is.
I don't know, perhaps there is support for external files only, I don't know. Please help :)

Shows up just fine for me in MPC-HC with the latest nightly build.
Note that I have no idea what kind of support MPC-BE has for WebVTT subtitles, they may not support the way LAV Splitter exports them (which is based on the Microsoft Media Foundation subtype as well as the WebM Packet format), since there is no "official" way.

In case anyone is interested in adding support for WebVTT, the format is pretty simple, so i'll quickly outline below how LAV Splitter exports it to DirectShow:

MediaSubtype = {C886D215-F485-40BB-8DB6-FADBC619A45D} = MFSubtitleFormat_WebVTT
Packet Format based on the WebM packaging:
- First Line: WebVTT Cue Identifier, if any, or an empty line
- Second Line: WebVTT Cue Settings, if any, or an empty line
- Third Line onwards: Actual subtitles

The first/second line are always present, even if they are entirely empty and are just a line-break, so if a parser does not care for this information, they can always skip the first and/or second line to get to the subtitle data.
All possible combinations of line-breaks are allowed, although LAV will always use a windows-style CRLF linebreak.

[stax76]

But there are very user-friendly frontends:

https://github.com/mpv-player/mpv/wiki/Applications-using-mpv

One of them is a little project of mine, ok it's nowadays my favorite project since I gave up encoding.

[digimaster]

Hi,

I have an issue with a MOV file, captured with Blackmagic Card: it's an HDR file (Mediainfo confirm this) but Lav Video seems not to pass the correct data to Madvr that shows REC709 (best guess), no REC2020, no HDR.

And now, the really strange thing: if I use FFmpeg to mux this file in a MKV container, LAV pass the right data to Madvr (REC2020, HDR with correct metadata).

This is the MOV Mediainfo:

General
Complete name Untitled 01.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt 2005.03 (qt )
File size : 1.24 GiB
Duration : 6 s 629 ms
Overall bit rate : 1 604 Mb/s
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15
Writing library : Apple QuickTime
TIM : 00:00:00:00
TSC : 24000
TSZ : 1001

Video
ID : 1
Format : YUV
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 6 s 629 ms
Duration_LastFrame : 4 s 127 ms
Bit rate mode : Constant
Bit rate : 4 242 Mb/s
Width : 3 840 pixels
Clean aperture width : pixel0
Height : 2 160 pixels
Clean aperture height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 1.24 GiB (100%)
Language : English
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 400 cd/m2

Audio
ID : 2
Format : PCM
Format settings : Little / Signed
Codec ID : in24
Duration : 6 s 629 ms
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 1.82 MiB (0%)
Language : English
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15

Other
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 6 s 629 ms
Frame rate : 23.976 (24000/1001) FPS
Time code of first frame : 00:00:00:00
Time code, striped : Yes
Title : 001
Language : English
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15

This is the MKV Mediainfo (video only):

General
Unique ID : 63447010645303056334747674940859238427 (0x2FBB732405003FF5758FB55567D8481B)
Complete name Untitled 01.mkv
Format : Matroska
Format version : Version 4
File size : 1.24 GiB
Duration : 6 s 629 ms
Overall bit rate : 1 602 Mb/s
Writing application : Lavf58.47.100
Writing library : Lavf58.47.100
ErrorDetectionType : Per level 1

Video
ID : 1
Format : YUV
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MS/VFW/FOURCC / v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 6 s 629 ms
Bit rate : 1 570 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV / YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
Bits/(Pixel*Frame) : 7.885
Time code of first frame : 00:00:00:00
Time code source : Matroska tags
Stream size : 1.21 GiB (98%)
Writing library : Uncompressed 10-Bit YUV
Language : English
Default : Yes
Forced : No
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000
Maximum Frame-Average Light Level : 400

Any suggestions?

Thanks!

[Aleksoid1978]

Hi,

I have an issue with a MOV file, captured with Blackmagic Card: it's an HDR file (Mediainfo confirm this) but Lav Video seems not to pass the correct data to Madvr that shows REC709 (best guess), no REC2020, no HDR.

And now, the really strange thing: if I use FFmpeg to mux this file in a MKV container, LAV pass the right data to Madvr (REC2020, HDR with correct metadata).

This is the MOV Mediainfo:

General
Complete name Untitled 01.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt 2005.03 (qt )
File size : 1.24 GiB
Duration : 6 s 629 ms
Overall bit rate : 1 604 Mb/s
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15
Writing library : Apple QuickTime
TIM : 00:00:00:00
TSC : 24000
TSZ : 1001

Video
ID : 1
Format : YUV
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 6 s 629 ms
Duration_LastFrame : 4 s 127 ms
Bit rate mode : Constant
Bit rate : 4 242 Mb/s
Width : 3 840 pixels
Clean aperture width : pixel0
Height : 2 160 pixels
Clean aperture height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 1.24 GiB (100%)
Language : English
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 400 cd/m2

Audio
ID : 2
Format : PCM
Format settings : Little / Signed
Codec ID : in24
Duration : 6 s 629 ms
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 1.82 MiB (0%)
Language : English
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15

Other
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 6 s 629 ms
Frame rate : 23.976 (24000/1001) FPS
Time code of first frame : 00:00:00:00
Time code, striped : Yes
Title : 001
Language : English
Encoded date : UTC 2021-03-24 16:42:15
Tagged date : UTC 2021-03-24 16:42:15

This is the MKV Mediainfo (video only):

General
Unique ID : 63447010645303056334747674940859238427 (0x2FBB732405003FF5758FB55567D8481B)
Complete name Untitled 01.mkv
Format : Matroska
Format version : Version 4
File size : 1.24 GiB
Duration : 6 s 629 ms
Overall bit rate : 1 602 Mb/s
Writing application : Lavf58.47.100
Writing library : Lavf58.47.100
ErrorDetectionType : Per level 1

Video
ID : 1
Format : YUV
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MS/VFW/FOURCC / v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 6 s 629 ms
Bit rate : 1 570 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV / YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
Bits/(Pixel*Frame) : 7.885
Time code of first frame : 00:00:00:00
Time code source : Matroska tags
Stream size : 1.21 GiB (98%)
Writing library : Uncompressed 10-Bit YUV
Language : English
Default : Yes
Forced : No
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000
Maximum Frame-Average Light Level : 400

Any suggestions?

Thanks!

Upload MOV.

[digimaster]

Here you go:

https://we.tl/t-32ohn4k4XH

Thanks!

[Aleksoid1978]

Here you go:

https://we.tl/t-32ohn4k4XH

Thanks!

You file don't contain info about: Color primaries, Transfer characteristics and Matrix coefficients. Only HDR metadata.

[digimaster]

Yeah, but the same file in MKV container play well. So...

And, in any case, a file with these specs can't be REC709, no HDR...

[digimaster]

This one has all info (Color primaries, Transfer characteristics and Matrix coefficients), same issue:

https://we.tl/t-0gqx7SuLFP

Thanks for your help!

[Qotscha]

Are there plans to add support for WebVTT also with HLS (example (https://demo.unified-streaming.com/video/tears-of-steel/tears-of-steel-multiple-subtitles.ism/.m3u8))?

[nevcairiel]

Are there plans to add support for WebVTT also with HLS (example (https://demo.unified-streaming.com/video/tears-of-steel/tears-of-steel-multiple-subtitles.ism/.m3u8))?

The HLS parser does not fully support subtitles yet, so no immediate plans right now.

[digimaster]

Hi Nev,

Have you had the chance to read my previous post? This issue seems incomprehensible...

Thanks for your help!

[nevcairiel]

LAV Filters 0.75

LAV Splitter
- NEW: Support for DASH streaming
- NEW: WebVTT support in Matroska/WebM
- Changed: Improved Font support from Matroska files
- Fixed: Large queue size limits could result in the wrong limit being applied
- Fixed: Resolved a memory leak in Matroska demuxing
- Fixed: Avoid selecting a stream with only a single video frame in MP4 files, which is often a cover art
- Fixed: Seeking in Matroska files with only audio cue points did not function
- Fixed: Seeking to the beginning of certain HLS streams did not work properly
- Fixed: Duration information in Matroska files is more reliable

LAV Video
- NEW: AV1 DXVA2/D3D11 hardware decoding support
- NEW: ProRes 4444 XQ support
- Faster: Updated dav1d decoder and improved thread configuration for significantly improved AV1 decoding speed
- Fixed: Added a workaround for VP9 hardware decoding on AMD video cards
- Fixed: H.264 streams exceeding the Level 5.1 DPB limit will no longer be hardware decoded
- Fixed: Improved handling of missing reference frames in H.264 streams with hardware decoding
- Fixed: HEVC streams encoding 8-bit video in a Main10 profile can be properly hardware decoded
- Deprecated: NVIDIA CUVID and Intel QuickSync have been deprecated for future removal/replacement

LAV Audio
- Fixed: Resolved an issue with glitching TrueHD bitstreaming on seamless-branching titles
- Fixed: Resolved a compatibility issue with some playback applications
- Deprecated: Support for the binary DTS decoder (dtsdecoderdll.dll) has been deprecated for future removal

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

Its been two years since the last release, which is a factor of LAV getting more mature/stable and the last two years being rather busy to complete a few changes I wanted for the next release.
Some of those changes have been worked on, some have been postponed for the next version, hopefully not in two more years.

Lets dive into some of the notable improvements since 0.74

AV1 improvements and DXVA2/D3D11 support

A lot has changed in the AV1 landscape in the last two years. The dav1d decoder is a lot faster now, and we finally have hardware acceleration on all three major GPU vendors, NVIDIA 30-series, AMD 6000 series, and Intel Xe.
One caveat for hardware decoding, film grain synthesis may not work on Intel or AMD. Due to lack of hardware I did not have the ability to test. On NVIDIA 30-series, it works, however.

DASH streaming

LAV Splitter now supports rudimentary DASH streaming, through FFmpeg. However, I must note that the DASH demuxer in FFmpeg is not perfect, and I can only provide it "as-is", and would suggest to reproduce and report issues with DASH streams directly to FFmpeg.

WebVTT support
LAV Splitter now supports demuxing WebVTT subtitles from Matroska/WebM, as well as from stand-alone files.
As with any new subtitle standard, support in the subtitle renderer is required to display them.

If any developers of subtitle renderers/players are interested in adding support for WebVTT, I've documented the basic packet format that LAV Splitter sends here:
https://forum.doom9.org/showthread.php?p=1938913#post1938913

Matroska improvements

A lot of improvements for Matroska have accumulated. Better font support, support for the Matroska rotation tags, improved seeking, better duration reporting on some oddly muxed Matroska files, and overall fixes.

Hardware acceleration improvements

In LAV Video, nearly everything is about hardware accelerated decoding. Additional checks to avoid decoding incompatible streams with hardware, improvements to handle streams in hardware that previously could not, and fixes to error concealment with missing frames.

Deprecations

I'm sure some of these will be controversial, but they currently just suffer bitrot and lack key features.

NVIDIA CUVID and Intel QuickSync are deprecated, not recommended for usage, and will be removed in a future version.

However, there is some light at the end of the tunnel. A replacement for the old CUVID implementation, which had serious deficiencies, will hopefully be available at the same time, based on FFmpegs NVDEC hardware acceleration support, which solves many of the shortcomings (like missing HDR metadata, among other things), while still providing deinterlacing out of the box. And maybe even with D3D11 interop, which means that it could devlier d3d11 native frames to the renderer, and avoid the copy-back overhead.

As for Intel QuickSync, frankly Intels decoding API is cumbersome to work with, I have no modern Intel GPU available to me, and unless key advantages come to light to give it the same treatment as CUVID/NVDEC, it should simply get replaced by DXVA2/D3D11.
As a bonus, it might be possible to enable decoder-based deinterlacing for DXVA2/D3D11, even in native-decoding mode, but I cannot promise this and its mostly a theoretical thought at the moment.

A bit more clearcut, the old binary dtsdecoderdll.dll support is also scheduled for removal from LAV Audio. With the complete FFmpeg DTS-HD decoder it serves practically no purpose anymore, and the software its from no longer exists.

As always, please report issues, specifically regressions, in as much detail as possible with a sample file if applicable.

Have fun!

[digimaster]

Hi Nev,

I've just tried this new release, unfortunately the issue is still there...

[nevcairiel]

There were no claims to have it fixed, and repeatedly asking isn't going to make it so either. :)
I do not have the time to immediately investigate any forum post. If you want to make sure it gets seen, there is a bug tracker for it, include all the details and the file.

[digimaster]

My previous post was only for info purpose, not to complain in any way. I'm going to the Bug Tracker just now.

Thanks for your great work!

[SamuriHL]

Looks like a nice solid build, thanks! Looking forward to trying the new nVidia side of that when it's ready. That sounds intriguing.

[VBB]

Thanks Nev!

[chros]

Me. too!

[el Filou]

Anyone else getting a "this file is not often downloaded and might be dangerous" when downloading the last release with Chrome?
I get that with Windows SmartScreen but I never got that in Chrome even with the nightlies. Oh well, passed it through VirusTotal and there wasn't any warning, but still strange.

[jmone]

Thanks Nev! Lots of goodies to try.

AV1 Questions:
- Does it support Main (0), High (1), and Professional (2) profiles?
- Any one have links to UHD AV1 Samples at various frame rates etc?

[nevcairiel]

In Software, any single AV1 file should be supported.

In Hardware, only Main profile is supported for now, even though the specification includes support for more modes, until I get hardware that can handle it, there is little I can do.

[nevcairiel]

Anyone else getting a "this file is not often downloaded and might be dangerous" when downloading the last release with Chrome?
I get that with Windows SmartScreen but I never got that in Chrome even with the nightlies. Oh well, passed it through VirusTotal and there wasn't any warning, but still strange.

These warnings are how Microsoft wants you to buy expensive EV certificates, as thats the only way to by-pass it entirely. They have absolute no data on the file being "bad", they just throw a warning at you because they don't know it, and you didn't pay them to avoid it.

Otherwise, it'll go away after a while as those checks get used to the file. The issue being exacerbated as I got a new signing certificate, the old one expired.

[jmone]

...good point, looks like the current 30 series only supports decoding Main profile (8 or 10 bit, 4:2:0 or 4:0:0) but all the way to Level 6 (up to 8K@30fps or 4K@120fps). Shame options for AV1 encoder support is still not that great.

[tormento]

Out of curiosity: why to deprecate CUVID if the withdraw is to lose the hardware deinterlacer? Can't find any way to have it back with other methods.

[wai148]

hardware deinterlacer CUVID very good

[onekmilesbehind]

Out of curiosity: why to deprecate CUVID if the withdraw is to lose the hardware deinterlacer? Can't find any way to have it back with other methods.

Check the "Deprecations" section of Nev's most recent release notes, a successor implementation should be available in the future.

[nevcairiel]

Out of curiosity: why to deprecate CUVID if the withdraw is to lose the hardware deinterlacer? Can't find any way to have it back with other methods.

Because it has no future, and already several problems, and leaving something around to suffer bitrot because it could be useful for someone is not how I work.

[levizx]

looks awesome!

one issue i have is right now my laptop has intel gen 10 (no av1) and rtx30, the only combination that works is to use d3d11+manually choose rtx30, d3d11+auto defaults to intel, and both dxva2 options require an active display so these are out.

is there any chance to add hw capability detection to use discreet gpu for av1 only if the cpu/apu doesn't support it (such as intel up to gen10 amd amd apu with vega)?

Thank you.

[nevcairiel]

Its a one-time setup step to select the more capable GPU, auto-detection wouldn't add any additional capability and add quite a bunch of additional layers, so not likely. "Native" modes are required to share the device with the renderer (the renderer picks), so those don't get a choice anyway.

[Marsu42]

LAV Filters 0.75
[CODE]
One caveat for hardware decoding, film grain synthesis may not work on Intel or AMD. Due to lack of hardware I did not have the ability to test. On NVIDIA 30-series, it works, however.


Is there a specific concern film grain synthesis might not work on non-Nvidia hardware, or is it simply due to lack of test hardware? Thanks!

[mts1]

Hi guys.

I have a question about VP9 hardware acceleration using Radeon WX 7100.
Is it possible to have it with LAV Filters?
If not, would it be possible to have it in the near future? Or this is dead end?
Perhaps you know any other way/filters to achieve that?

Thanks.

[huhn]

this is a polaris based card the VP9 decoder is hybrid which is often worse than just using the CPU and is currently not available at all there where only a could of old drivers where it worked in chrome.

i have not rechecked this information in a long time so things could be different but it should still be a dead end.

[levizx]

Its a one-time setup step to select the more capable GPU.

yes, it's more capable, but also much more power hungry. that's not good for a laptop and sometimes defeats the purpose of having hw decoder altogether.

[mts1]

this is a polaris based card the VP9 decoder is hybrid which is often worse than just using the CPU and is currently not available at all there where only a could of old drivers where it worked in chrome.

i have not rechecked this information in a long time so things could be different but it should still be a dead end.

Got it.
Thanks.

[Sunspark]

I think I have located a video decoding bug, but I am not certain if the issue is LAV or another part of the chain.

A 10-bit P010 anime file is the source, being displayed in D3D9 exclusive on Windows 10.

DXVA2 Copy-Back - Works
DXVA2 Native - Video is split in two, left half is purple tinted, and right half is a solid block of green
Intel Quicksync - Works
DX11 Native - Image freezes
DX11 Copy-Back - Works

The issue with the DXVA2 and DX11 Native modes doesn't happen with non-P010 videos. I also checked and it was present in the previous release as well.

[wanezhiling]

Hi, lav hw decoding seems not work with this clip (https://mega.nz/file/Y18ATDIL#jW3ArmEYBFmoLtz33oMGc6cTuFgh1p4yIGQPliYAVM0), always sw decoding.

anyone confirm?

[el Filou]

A 10-bit P010 anime file is the source [...] The issue with the DXVA2 and DX11 Native modes doesn't happen with non-P010 videos.P010 is normally an output format, what's the video format + encoding (level, profile, other coding parameters)? Maybe post the video section of MediaInfo.
What's the hardware and driver? Does this also happen with older/newer drivers?
What's the video renderer? Does it also happen with other renderers/other modes than D3D9 exclusive?

[Sunspark]

P010 is normally an output format, what's the video format + encoding (level, profile, other coding parameters)? Maybe post the video section of MediaInfo.
What's the hardware and driver? Does this also happen with older/newer drivers?
What's the video renderer? Does it also happen with other renderers/other modes than D3D9 exclusive?

Hardware is an Intel HD Graphics 6000 (Broadwell CPU). MadVR .92.17 is the video renderer. The image/chroma scaling I'm using with it is DXVA.

Mediainfo below. Looking at it, I didn't realize that it was HEVC.. Interesting! I guess that explains why my CPU was running higher than expected while it was playing since on this GPU for things like VP9 it runs in hybrid mode (both cpu and some functions in gpu).

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 24 min 21 s
Bit rate : 3 078 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.062
Stream size : 536 MiB (87%)
Writing library : x265 3.3+2-gbe2d82093:[Windows][GCC 9.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=24 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=35040 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=1:1 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=1.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=0.80 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0
Default : Yes
Forced : No

[nevcairiel]

Hi, lav hw decoding seems not work with this clip (https://mega.nz/file/Y18ATDIL#jW3ArmEYBFmoLtz33oMGc6cTuFgh1p4yIGQPliYAVM0), always sw decoding.

anyone confirm?

The video has too many reference frames. H.264 4K at Level 5.1 only supports up to 5, not 16 as the video uses.

[DMU]

anyone confirm?

CPU: AMD Ryzen 3 3200G with Radeon Vega Graphics
GPU: AMD Radeon(TM) Vega 8 Graphics
Decoder: LAV Video Decoder
Decoder Device: H264_VLD_NoFGT
Frames: 1798
FPS: 174.177 [152-182]
CPU Usage: -
GPU 3D Engine Usage: 15 [14-16] %
GPU Video Codec 0 Engine Usage: 93 [86-95] %

[wanezhiling]

The video has too many reference frames. H.264 4K at Level 5.1 only supports up to 5, not 16 as the video uses.
Got it, thanks.

CPU: AMD Ryzen 3 3200G with Radeon Vega Graphics
GPU: AMD Radeon(TM) Vega 8 Graphics
Decoder: LAV Video Decoder
Decoder Device: H264_VLD_NoFGT
Frames: 1798
FPS: 174.177 [152-182]
CPU Usage: -
GPU 3D Engine Usage: 15 [14-16] %
GPU Video Codec 0 Engine Usage: 93 [86-95] %
As nevcairiel explained above, LAV won't decode such file in hw, so maybe something is wrong on your side?

[DMU]

I would be glad if you find something wrong on my side.
Pic (https://drive.google.com/file/d/11eT_8pLURN6uNvxUAfuvgr23Nejauh5W/view?usp=sharing).

[wanezhiling]

I would be glad if you find something wrong on my side.
Pic (https://drive.google.com/file/d/11eT_8pLURN6uNvxUAfuvgr23Nejauh5W/view?usp=sharing).

Because you are using an old LAV build(0.74.1-92) which still supports such H.264 file in hw decoding.

Update your MPC-HC (https://github.com/clsid2/mpc-hc/releases) and your lav will lose that ability.:p

[el Filou]

Hardware is an Intel HD Graphics 6000 (Broadwell CPU). [...] Looking at it, I didn't realize that it was HEVC.. Interesting!Interesting indeed, because IIRC the HEVC decoder in Broadwell was hybrid (used GPU compute and not fixed function unit), so maybe that's where the difference comes from? I would think it's a driver problem but it's hard to know really. Does it give a corrupt image too when using standard EVR ?

[VictorLS]

Because you are using an old LAV build(0.74.1-92) which still supports such H.264 file in hw decoding.
Update your MPC-HC and your lav will lose that ability.:p
Even next 0.74.1-98 can't DXVA2 HW acceleration of your Girls.Generation.Oh.4in1.201002.HDTV.x264.2160p.120fps.DTSES.6.1ch.mkv but even newest 0.75.0-2 can old NVIDIA CUVID acceleration with about 100 MB more videomemory consumption (so about 700 MB of 1 GB of my GTX750v2 GM206 videocard) than DXVA2 native in 0.74.1-92 but NVIDIA CUVID can't decode all frames while audio stops (DXVA2 native in 0.74.1-92 and also Cyberlink, MainConcept and MPC-BE Video Decoder with DXVA can).

[nevcairiel]

Don't encode your videos out of spec if you want them to work better. If it actually uses 16 ref frames on 4K, then it would artifact decoding in hardware, I didn't add those checks out of nowhere, and this was on modern NVIDIA hardware too.
If it doesn't use all 16 but is flagged to contain 16, then the stream is just bad. As a general rule, 16 ref frames rarely offer a solid advantage, which is why it was reduced on HEVC again to max 8 active ref frames per frame as well.

Artifacts are the worst thing that can happen. I rather not decode some obscure out-of-spec video in hardware then risk artifacts. That has always been my stance on this.

[Sunspark]

Interesting indeed, because IIRC the HEVC decoder in Broadwell was hybrid (used GPU compute and not fixed function unit), so maybe that's where the difference comes from? I would think it's a driver problem but it's hard to know really. Does it give a corrupt image too when using standard EVR ?

No, I checked just now with EVR Custom Presenter, and it displayed fine in DXVA2 Native mode. Thanks for the suggestion to check that.

So based on this, it appears that the bug may be with MadVR after all which hasn't received a public update for a couple years now.

Update: I found a way to make it work in DXVA2 Native mode w/ MadVR for this type of video. If you uncheck "Present frames in advance" it will change it to backbuffers which is D3D9 Old Path. Frames in advance is D3D9 New Path. Not completely sure what the difference between Old and New is, but old works if you want to use Native instead of Copy-Back and even more curious, it very subtly appears to be smoother on panning motion than new.

[VictorLS]

Don't encode your videos out of spec if you want them to work better.
Most cases is playing enocoded by someone files (streams, i.e. from SAT) but not own encoded.
Artifacts are the worst thing that can happen. I rather not decode some obscure out-of-spec video in hardware then risk artifacts. That has always been my stance on this.
So you still live in ideal world and still don't want to give choice for people as v0lt in their modern MPC-VR with always turning on HLG processing or MPC-BE Video Decoder - just one version has Skip non I-frames (newer has Skip B-frames only isn't enough for 8K in my case)
https://i.postimg.cc/mtQP0pM7/MPC-BE-Video-Decoder-Settings.png (https://postimg.cc/mtQP0pM7)
I use 1.5.3(build4166) (https://disk.yandex.ru/d/ZBA-K2-6UUV4TQ) only - in case of LAV Video Decoder I'll have to use i.e. 0.74.1-92 in case of playing such Girls.Generation.Oh.4in1.201002.HDTV.x264.2160p.120fps.DTSES.6.1ch.mkv files but I prefer use one (desirable most modern) and most universal video decoder with various settings for all possible cases - if I see artifacts with DXVA2 I prefer just change acceleration to NVIDIA CUVID then install older version of LAV Video Decoder ;)

[nevcairiel]

So you still live in ideal world and still don't want to give choice for people

Luckily, I don't have to care what you think, and those options will never happen. You are free to not use my software if you don't like my decisions. I don't get anything from it.