View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
VictorLS
6th September 2019, 15:59
steakhutzeee
I hope I understand you right this time ;)
LigH
8th September 2019, 11:14
@steakhutzeee: Please don't miss the difference between container and content formats.
Matroska/WebM, MP4/MOV, MPEG PS/TS/PVA ... are containers. They may contain a variety of content formats (like AVC/H.264, HEVC/H.265, WMV/VC-1, VP8/VP9, AV1 ... video, and several audio formats).
Splitters separate the content from the container. Decoders decode the content. You can disable player internal filters for each of them separately. Know what you may have, then you will know what you may want to control.
steakhutzeee
8th September 2019, 22:46
@steakhutzeee: Please don't miss the difference between container and content formats.
Matroska/WebM, MP4/MOV, MPEG PS/TS/PVA ... are containers. They may contain a variety of content formats (like AVC/H.264, HEVC/H.265, WMV/VC-1, VP8/VP9, AV1 ... video, and several audio formats).
Splitters separate the content from the container. Decoders decode the content. You can disable player internal filters for each of them separately. Know what you may have, then you will know what you may want to control.
Thank you very much for the clarification :thanks:
sneaker_ger
14th September 2019, 08:11
Automatic nightly builds are broken?
NikosD
15th September 2019, 07:41
Automatic nightly builds are broken? Looks like that.
Latest September commits haven't compiled yet to nightly builds which are still on August.
el Filou
16th September 2019, 15:29
Strange thing I noticed: since the new dav1d version in 74.1-20, AV1 decoding is actually slower (about 6-7%), both on my Core 2 and my Haswell. (8-bit clip)
nevcairiel
16th September 2019, 18:56
The Virtual Machine that does my nightly builds is currently down, I'll bring it back up soon.
Regarding dav1d performance, sometimes security fixes can cause that, but there is more speedup coming soon as well.
Sometimes multi-threading is also weirdly affected, resulting in overall lower CPU usage, but no gain in speed directly.
ryrynz
1st October 2019, 00:45
Any chance of a Dav1d update in next nightly?
nevcairiel
1st October 2019, 11:26
There will be a new dav1d release soon (once some more improvements are done), not before then.
clsid
3rd October 2019, 14:53
This file (https://drive.google.com/open?id=1QupN_FIkpxenpdl2HYlOdZOEPN4Ajbd2) doesn't play smoothly with DXVA2 Native. No problem with Copy-back.
NikosD
3rd October 2019, 21:34
This file (https://drive.google.com/open?id=1QupN_FIkpxenpdl2HYlOdZOEPN4Ajbd2) doesn't play smoothly with DXVA2 Native. No problem with Copy-back. Indeed, what a sample!
I tried it using iGPU HD 4400 and Turing 1660 and DXVA2 native doesn't play smoothly.
On the other hand, all copy-back modes QuickSync, NVCUVID, D3D11 etc work fine.
Aleksoid1978
4th October 2019, 01:28
Interesting sample - bug only on LAV Video + LAV Source + EVR/EVR-CP.
If use MPC VR or madVR - perfect playback :)
el Filou
4th October 2019, 19:36
Remuxing it to MKV plays smoothly too even with DXVA2 native + EVR.
When looking at EVR stats when playing the FLV, jitter reaches 40+ ms. Timing issue in the container? (Edit: the remuxed MKV is 7/6 seconds shorter video/audio runtime than the FLV)
thrawnrulz68
5th October 2019, 06:15
Does anyone know if the MSA1 (Microsoft Screen Application Decoder) still works in the latest version of LAV? For some reason, mine no longer does. I have not had any other problems and even MSS1 and MSS2 (the other Microsoft screen codecs) seem to work. Was MSA1 removed?
There is a sample a little before halfway down this page: http://samples.ffmpeg.org/V-codecs/
thrawnrulz68
5th October 2019, 06:28
I was actually messing around with some other samples from the ffmpeg site and the following do not seem to work with MPC-HC 1.8.7 and the latest LAV on my system either (even with all formats checked in LAV Splitter and LAV Video Decoder):
CDXL (http://samples.ffmpeg.org/cdxl/)
Newtek SpeedHQ (http://samples.ffmpeg.org/V-codecs/ - near the bottom)
VP4 (http://samples.ffmpeg.org/V-codecs/VP4/)
VP5 (http://samples.ffmpeg.org/V-codecs/VP5/)
Any ideas?
v0lt
5th October 2019, 06:39
Any ideas?
Nobody needs this. :)
littleD
5th October 2019, 07:10
I was actually messing around with some other samples from the ffmpeg site and the following do not seem to work with MPC-HC 1.8.7 and the latest LAV on my system either (even with all formats checked in LAV Splitter and LAV Video Decoder):
CDXL (http://samples.ffmpeg.org/cdxl/)
Newtek SpeedHQ (http://samples.ffmpeg.org/V-codecs/ - near the bottom)
VP4 (http://samples.ffmpeg.org/V-codecs/VP4/)
VP5 (http://samples.ffmpeg.org/V-codecs/VP5/)
Any ideas?You may read nice blog of unreleased? NihAV library here (https://codecs.multimedia.cx/) Just search for old entries or keywords. I am sure he works at least on VPX codec family.
v0lt
5th October 2019, 11:32
LAVFilters-0.74.1-21...24.
Players (MPC-BE, MPC-HC) freeze after pressing the stop button when playing YouTube videos.
huhn
5th October 2019, 14:03
is there a way to get reason/information out of lavfilter when software fallback is used?
nautilus7
5th October 2019, 14:37
Hi, I captured a FTA satellite feed the other day, which I have trouble decoding properly (both in my satellite receiver and in MPC-HC with DXVA2). The weird thing is that with no video acceleration in LAV filters, it plays back fine. Can anyone explain me what's wrong/different with this video that creates problems to the hardware decoders? Or is there a bug somewhere? Thanks.
Sample: https://drive.google.com/open?id=1eQot_p-4hlDB169v2ZUF9HvNJ0fYz5Dh
el Filou
5th October 2019, 15:14
Funny thing: CUVID decodes it just fine too, it's only DXVA that has a problem with it. :confused:
nautilus7
5th October 2019, 16:20
Yep, I noticed that as well. Sorry for not mentioning it.
NikosD
6th October 2019, 08:33
Sample: https://drive.google.com/open?id=1eQot_p-4hlDB169v2ZUF9HvNJ0fYz5Dh Using iGPU HD 4400 (Core i3 4170 Haswell) it plays fine with DXVA2/D3D11VA modes (DAVA2 Native, copy-back & D3D11VA copy-back)
Using QuickSync decoder, it start with artifacts but then the decoded stream goes back to normal.
The same happens when you seek with QS decoder.
The first few seconds have artifacts but then everything is back to normal.
On the other hand, using nVidia GTX 1660, only NVCUVID is fine.
nautilus7
6th October 2019, 09:30
Hm, thanks. I am with an old nvidia 650 Ti.
aufkrawall
6th October 2019, 12:59
Try capturing to another container format like mkv, ffmpeg bombards we with errors when playing this file (which ceases after remuxing to mkv).
NikosD
6th October 2019, 17:05
Try capturing to another container format like mkv, ffmpeg bombards we with errors when playing this file (which ceases after remuxing to mkv). The reason reporting samples that they seem to not work properly, is not always to fix the sample (almost never) but to change the decoder in a way to deal even with "difficult" cases, to make the decoder more resilient to such cases and sometimes to fix a bug.
VictorLS
6th October 2019, 17:31
aufkrawall
Commonly it's not container but "broken" stream problem - may be in your case mkv is played with i.e. LAV Video Decoder with CUVID or without acceleration but ts with another decoder with DXVA/D3D11 acceleration.
I don't know about nautilus7's file but know about my files recorded from SATs like RussiaHD.ts (7MB) https://yadi.sk/d/0TeXaMEg3LiiVA http://forum.doom9.org/showthread.php?p=1784923#post1784923 and http://forum.doom9.org/showthread.php?p=1787253#post1787253 and even muxed in mkv file recorded by some my Russian compatriot after first minute of playing Ч_Г_Д.mkv (153MB) https://yadi.sk/i/YlWK7rqeesHkSA has artifacts with any acceleration but NVIDIA CUVID because nevcairiel despite of not wanting to solve this in LAV Video Decoder http://forum.doom9.org/showthread.php?p=1784851#post1784851 did it ;)
I've just seen with 0.74.1.24-git even with checked Enable CUVID DXVA Processing artifacts absent (early was) so I believe from some version of LAV Video Decoder CUVID DXVA Processing was disabled at all as minimum for Win7 and if I'm right Enable CUVID DXVA Processing is atavism ;)
PS. nVIDIA can't solve that artifacts with DXVA problem (it's in WinXP and very old videocards too) until now so I'm sure it can't be solved at all.
Returning to theme of quasi-interlaced h265 SD and HD channels beginning from here http://forum.doom9.org/showthread.php?p=1846579#post1846579 - it seems ffmpeg still haven't support that so my beta-version of instruction I promised to write http://forum.doom9.org/showthread.php?p=1881908#post1881908 in a root of portable donateware SAT-receiving application SmartDVB 0.5.3.26 can be downloaded from http://www.smartdvb.net/tempsite/index.html in folder HEVC_quasi_interlaced may help to play such channels almost without flickering. If anybody have argue proposition to improve that write in PM, please.
aufkrawall
6th October 2019, 17:40
The reason reporting samples that they seem to not work properly, is not always to fix the sample (almost never) but to change the decoder in a way to deal even with "difficult" cases, to make the decoder more resilient to such cases and sometimes to fix a bug.
Still the user deliberately creates .ts files, which are limited crap vs. mkv.
nautilus7
6th October 2019, 18:40
It's a satellite transmission, where .ts is the standard container...
el Filou
6th October 2019, 18:43
TS is the standard format for digital TV broadcasts, there should not be a need to convert it to play it back. Some splitters designed for local file playback can have problems with it when it comes to things like seeking, but it should not cause video decoding problems. This file shows artifacts even when I play it with MediaPortal, that comes with a splitter dedicated to and optimised for TS playback.
The bug may well be in the program that originally recorded the file, but it's not the format's inherent fault.
VictorLS
6th October 2019, 19:47
The bug may well be in the program that originally recorded the file, but it's not the format's inherent fault.
No, that "broken" streams are done with various programs and even hardware receivers all over the world https://forum.doom9.org/showthread.php?p=1784869#post1784869 but artifacts problem while playing "broken" streams is with DXVA nVIDIA (and may be AMD and some Intel with just QuickSync as NikosD has described) videocards only so I suppose it's coder on transmitting side issue (in Ч_Г_Д.mkv it appears after first minute when i.e. coder was some malfunction) - I even tried to analyze that streams but I'm not professional in it to find the cause of artifacts - IPB structure seems OK in a minute of Ч_Г_Д.mkv - I just almost always use NVIDIA CUVID, excluding 4K HLG https://forum.doom9.org/showthread.php?t=176909 because my GTX750v2 on GM206 is too weak for that - have to use DXVA2(native) in that case, for hardware acceleration while watching all SAT streams directly including that "broken" streams without any artifacts.
el Filou
7th October 2019, 14:39
@nautilus I tried the sample on a Radeon and it decodes just fine so it looks like an NVIDIA specific DXVA bug, you should report it to them.
VictorLS
8th October 2019, 10:39
you should report it to them.
I've reported them with btw RussiaHD.ts sample
PS. nVIDIA can't solve that artifacts with DXVA problem (it's in WinXP and very old videocards too) until now so I'm sure it can't be solved at all.
ReferenceNumber 161108-000131
NamedIDOptList Unresolved
Created 11/08/2016 05:26 AM
UpdatedTime 11/22/2017 08:25 AM
Liisachan
9th October 2019, 13:20
@nevcairiel
MKV files with fonts (attached using new standard Media Types) play just fine now if the latest LAV Splitter is used externally - even with the official (old) MPC-HC from 2017 or MPC from 2009! Thank you so much :)
I have one additional request. Could you please add support for "font/collection" and/or extension .ttc (.TTC) as AV_CODEC_ID_TTF? A ttc file is already working when attached as "application/x-truetype-font", but afaik its standard Media Type (https://www.iana.org/assignments/media-types/media-types.xhtml#font) is font/collection (https://www.iana.org/assignments/media-types/font/collection). TTC files are used commonly in a few countries.
:thanks:
Links for others who may be interested in this:
Related code changes (https://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=8066ee422778255341277dd50d83ceb5b1f6a4b2) (matroska: add new standard font mimetypes, 2019-10-06)
nevcairiel's post (https://forum.doom9.org/showthread.php?p=1886821#post1886821) (MKVToolNix@doom9, 2019-10-07)
LAVFilters-0.74.1-26.exe (https://files.1f0.de/lavf/nightly/) (2019-10-09)
clsid
9th October 2019, 13:24
LAVFilters-0.74.1-21...24.
Players (MPC-BE, MPC-HC) freeze after pressing the stop button when playing YouTube videos.Confirmed.
PCU
10th October 2019, 10:27
latest version of lav filters (mpc-hc: by clsid) can't play this file?
https://www.mediafire.com/file/9s2208grgritj2w/attrfmv1.avi/file
this video is divx video fmv from lord of the rings 3 video game for pc.
LigH
10th October 2019, 12:18
FourCC = DXGM; not one of the usual codec markers for a supposedly DivX 5.0.3 compatible video stream.
Patched the FourCC to "DX50" and it plays. So ... try a "FourCC Patcher" as easy workaround.
PCU
10th October 2019, 13:32
i can't patch it, so there's no any other ways, right?
filler56789
11th October 2019, 00:38
i can't patch it, so there's no any other ways, right?
Download avic.exe from Videohelp:
https://www.videohelp.com/software/AVI-FourCC-Code-Changer
ryrynz
12th October 2019, 06:50
There will be a new dav1d release soon
Soon has come *rubs hands*
orion44
13th October 2019, 22:57
What was the last version of LAV Filters that supported Windows XP with Service Pack 2?
el Filou
13th October 2019, 23:42
https://github.com/Nevcairiel/LAVFilters/blob/master/CHANGELOG.txt
Last release to support XP was 0.70.2, no idea exactly what nightly build between that one and 0.71.0 removed support.
Edit: it needs SP3. I really have no idea why so many people insist on running an even older Service Pack on an already obsolete OS.
nevcairiel
14th October 2019, 10:52
Soon has come *rubs hands*
Indeed, I have pushed an updated dav1d library.
nevcairiel
14th October 2019, 11:13
LAVFilters-0.74.1-21...24.
Players (MPC-BE, MPC-HC) freeze after pressing the stop button when playing YouTube videos.
Confirmed.
Please try again with the updates I pushed just now (tomorrows nightly, or your own builds).
nevcairiel
14th October 2019, 11:17
I have one additional request. Could you please add support for "font/collection" and/or extension .ttc (.TTC) as AV_CODEC_ID_TTF? A ttc file is already working when attached as "application/x-truetype-font", but afaik its standard Media Type (https://www.iana.org/assignments/media-types/media-types.xhtml#font) is font/collection (https://www.iana.org/assignments/media-types/font/collection). TTC files are used commonly in a few countries.
I have added the collection type in the latest ffmpeg update, thanks!
ryrynz
14th October 2019, 11:32
Indeed, I have pushed an updated dav1d library.
Thanks, been a bit of talk about this release, this places AV1 into prime time.
tiresias
14th October 2019, 15:47
I have a couple of questions about the LAV video decoder's "Hardware decoder to use" setting.
If a hardware decoder setting such as DXVA2 native or DXA2 copy-back had been selected and saved, what does the LAV video decoder do if the actual hardware is no longer available - say it has been removed or the driver becomes disabled/faulty ?
Does the LAV video decoder just fall back gracefully and silently to software decoding (equivalent to the "none" setting), or does it get into an error state ?
Also, if I understand correctly, the D3D11 setting is just for use with the MadVR renderer which can use DX11. With the D3D11 setting saved, what does the decoder do if it is connected to a renderer than can only do DX9 (such as EVR) - does it drop back to software, or DXVA2 native, or DXVA copy-back or something else?
clsid
14th October 2019, 16:07
If a previously used GPU is no longer available, it will simply pick the first available one.
D3D11 decoder also works with D3D9 renderers. But it will work in copyback mode.
tiresias
14th October 2019, 16:37
If a previously used GPU is no longer available, it will simply pick the first available one.
Thanks. So if for some crazy reason it can't successfully use a GPU, will it always drop back to software mode rather than abort with error?
nevcairiel
14th October 2019, 16:45
Thanks. So if for some crazy reason it can't successfully use a GPU, will it always drop back to software mode rather than abort with error?
If your selected GPU is not usable, it'll use the primary GPU, and if thats also not capable of decoding, it should switch to software.
Do note however that fallback from DXVA2-Native to software is a bit limited in some situations, but in this case when the GPU isn't usable at all, it should probably manage.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.