Log in

View Full Version : LAV Filters - DirectShow Media Splitter and Decoders


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 [474] 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508

huhn
14th October 2019, 16:52
it will use software in this case with no error code which is equivalent to none.

madVR runs in d3d9 it only accepts the frame from d3d11 and has limitations with it. mpc VR has "full" d3d11 scaling and even deinterlacing works too and it is a d3d11 renderer.

nevcairiel
14th October 2019, 16:54
mpc VR has "full" d3d11 scaling and even deinterlacing works too and it is a d3d11 renderer.

Which is nice, but doesn't really matter. The other capabilities of a renderer is where it counts.

huhn
14th October 2019, 17:15
sorry i have to disagree it matters if you can play interlaced content or not.
the more renderer that support this completely the better so hopefully madVR joins in and gives it the support it deserves.
not a problem in lavfilter anyway which is important here.

NikosD
14th October 2019, 18:15
D3D11 decoder also works with D3D9 renderers. But it will work in copyback mode.
MadVR runs in d3d9 it only accepts the frame from d3d11 and has limitations with it.
mpc VR has "full" d3d11 scaling and even deinterlacing works too and it is a d3d11 renderer. Which are the D3D11 renderers that work with LAV's D3D11VA decoder in native mode ?
MadVR only ?
Is there any MS renderer of latest Win10 compatible with LAV's native D3D11VA decoding ?

huhn
14th October 2019, 18:23
wrong thread.

mpcVR supports it (even in d3d9 mode it uses native just like madVR) with d3d11 processing but it's still yung and madVR only accept the image from it and uses d3d9 after that.

no clue about the rest.

NikosD
14th October 2019, 19:26
mpcVR ?
I missed that project!
Very interesting as I read now and kudos to @Aleksoid1978.

Does it currently work only using MPC-BE and its internal filters ?
Could someone install it and use it with MPC-HC and internal LAV filters ?

huhn
14th October 2019, 19:47
why don't you ask them in the mpc-be thread? for some reason they post new version in that thread not in a new one.
it's fully supported in mpc-be.
you can make it work in mpc-hc (i personally test it in there) but some feature don't work they need player support.

d3d11 native decode works perfectly with mpc VR so lavfilter is supported.

using mpc-be with lavfilter is pretty normal lavfilter simply has a bigger feature level.

in the end it is directshow and so it should work fine with ffdshow too.

Liisachan
14th October 2019, 23:56
I have added the collection type in the latest ffmpeg update, thanks!

Thanks a lot! Though perhpas these additional supports are superficial and trivial for developers, I really appreciate it.

(Background) Historically there were no official mime types for fonts, but lately they were officially registered as CSS @font-face has become so common. The mime type changes (legacy -> standard) are causing subtle problems, since embedded fonts are recognized by their mime types stored in MKVs. Players that can't handle new mime types can't show styled subs properly, in the worst case subs being totally unreadable!

v0lt
15th October 2019, 17:05
Please try again with the updates I pushed just now (tomorrows nightly, or your own builds).
I checked LAVFilters-0.74.1-28. I could not cause freezing after pressing the Stop button. Thank.

tiresias
18th October 2019, 18:29
Thanks for the clarification about the hardware decoder option.

I've been doing some more searching, and found some info specifically about the "DXVA2 native" and "DXVA2 copy-back" settings which I would like to clarify. Can I just run this by you for comments on what is right or wrong in the following statements:

If you are using the standard Windows EVR then it sounds like the best choice is probably "DXVA2 native" or "DXVA2 copy-back".

The setting "DXVA2 native" can only be used where the video decoder is connected directly to the renderer.

If there is a filter between the decoder and the renderer (or there is no renderer because we are outputting to a file) then "DXVA2 native" will drop back to software decoding.

If "DXVA2 copy-back" is selected, then you CAN use a filter between the decoder and the renderer and there is no drop back to software.

More recent GPUs are able to copy from video memory to system memory fast, so that there should not be a performance penalty in always selecting "DXVA2 copy-back" instead of "DXVA2 native" whether connecting directly to a renderer or not, or outputting to a file.

So, of the two settings, "DXVA2 copy-back" should always be selected, except that for OLDER GPUs that are slower to copy from video memory to system memory then selecting "DXVA2 native" may be more responsive when connected directly to a renderer.

Where "DXVA2 copy-back" is selected, regardless of whether the decoder is connected directly to the renderer or not, the decoder will use the first GPU that it finds to do the decoding, which might not be the same GPU that the renderer uses. In that case, is there a performance penalty or other problems where the decoder is using a different GPU to the renderer?

chros
19th October 2019, 08:25
Take a look at the links of this post (https://forum.doom9.org/showthread.php?p=1887838#post1887838).

tiresias
4th November 2019, 16:20
Thanks Chros, that helps a lot.

One more question...

It seems that the vast majority of desktops and laptops nowadays have some form of DXVA2 hardware acceleration. But the LAV Video Decoder installation default for Hardware Acceleration is "None", so inexperienced users are stuck with software decoding from the start (unless they investigate and change the setting).

Wouldn't it be better for the installation default to be DXVA2 copy-back instead? If there was any problem it would drop back to software (none) anyway.

It just seems that basic/inexperienced users are missing out on the hardware acceleration that their PC is capable of because they are set up with software decoding from the start.

Any thoughts on this?

nevcairiel
4th November 2019, 17:03
I don't believe "unexperienced" users should actually install LAV Filters themselves. They should just get MPC-HC or another player, which bundle everything they need, and players can also pre-configure it to how they see their user-base.

v0lt
5th November 2019, 20:13
Wouldn't it be better for the installation default to be DXVA2 copy-back instead?
It is a bad idea. The "copy-back" feature is redundant for most real systems (this will only increase power consumption). And on some systems (with integrated graphics) there will be problems with the frame output speed (50/60 fps will become unattainable).

huhn
11th November 2019, 08:25
just a small heads up that arm based windows notebooks/tables and such are now are now starting to show up.

one example is the surface pro x not a small product and important that it is from microsoft showing once more there commitment to arm.

clsid
11th November 2019, 16:21
Those Windows based ARM devices have x86 emulation, so MPC-HC and LAV Filters will work just fine. The chipset GPU supports hardware acceleration as well.

huhn
11th November 2019, 16:36
well yes but we talked about this before and nev was thinking about an arm build software decoding is important and the copy operation is as far as i know SIMD optimised.
the emulation is really slow. not a good video but better then nothing:
https://www.youtube.com/watch?v=oR0x_yx-6Rg

real world test with native x86 vs a emulated x86 is at ~11:20.
working is not always good enough...

and just to be clear not saying that this device is enough to justify an ARM build or even making it close to important but just look at the name of the processor this is mostly not the last one.

the surface 2? had a tegra too but newer devices used an intel CPU.

littleD
11th November 2019, 21:47
real world test with native x86 vs a emulated x86 is at ~11:20.
working is not always good enough...You mean geekbench chart, which is merely GPU measure benchmark?

I am worried more about raw CPU performance. Cinebench chart is not looking promising..

Is that really possible that emualted Windows gonna win with native arm Android system and even (nonexistent anymore) WinRT? Or other linux distro?

huhn
12th November 2019, 06:26
i mean the chrome test the emulated x86 on arm is not competitive at all but edge which was native arm vs native x86 was competitive.
beware these are pretty bad controlled test but they still hint that native ARM code is much faster then emulated code.

windows 10 is native ARM or with other words it has an ARM build.

oldpainlesskodi
27th November 2019, 09:14
Hi Guys,

Not sure if anyone can shed any light for me?

I have some videos with a aac 5.1 sound track, if I let Lav Audio handle the playback, the sound is as flat as a pancake (tried with saneer, with all the options on and off, no difference, and tried without saneer, again no difference). However, if I remove Lav audio from the chain, the sound is deep and high, and expansive. My windows audio (HDMI) device is set to 7.1 192 khz, so windows is doing the up sampling (or whatever the term is), but no matter what settings i use if I use Lav Audio, it still sounds flat (tried with mixing, and no mixing options on etc).

Maybe I have missed something obvious? I would have thought that using non-exclusive mode, they should sound the same?

el Filou
27th November 2019, 18:31
What is 'saneer'?
For the most accurate audio in LAV:
- enable all output formats
- disable DRC
- disable mixing (should not be needed if you use 7.1)
When you say "if I remove Lav audio from the chain", what decoder is used in that case? If the audio renderer is the same then that other decoder is probably applying processing to the audio that makes it sound different from the accurate decoding of LAV.

huhn
27th November 2019, 19:13
https://github.com/alexmarsev/sanear

oldpainlesskodi
28th November 2019, 08:59
Thanks for correcting my spelling error Huhn.

@ el Filou - yep, did all that (all the obvious stuff). I can use any other service to render (ffdshow) with all options disabled/inactive, and as I said, the sound is completely different.

Maybe Nev can shed some light.

nevcairiel
28th November 2019, 13:49
"flat" audio is not a technical description that allows any kind of diagnosis. LAV decodes all audio as accurately as possible.

el Filou
28th November 2019, 14:09
Did you try decoding a track to a WAV using something like ffmpeg or eac3to and then playing that WAV file to see if it's closer to what ffdshow or LAV outputs?
If you look on the Web for "WavDest", you can also try and get a WAV file output of both playback chains to find out what exactly is different in the sound, but you need to use GraphStudio.

LAV was mainly designed to be a simple and accurate decoder, while ffdshow is more a full-blown audio processing framework which increases the chances of 'doing something wrong' even unintentionally. If the sound is different between them, the most probable cause would be ffdshow modifying it rather than LAV not decoding it correctly.

oldpainlesskodi
28th November 2019, 14:28
Ok thanks both.

nevcairiel
28th November 2019, 19:04
The most likely case is that your AAC audio file decodes to a different channel layout then you might expect, since LAV actually tries to obey the layout information in the file, while older decoders like ffdshow just ignored such info and put it in a generic 5.1. That may be a case of a badly encoded audio stream, or just needing some tweaking in the audio renderer configuration to map it to the speakers you actually have.

Without a file at hand or some info I can actually go on (like maybe the output pin info of both LAV Audio and another decoder), its impossible to say anything else however.

oldpainlesskodi
29th November 2019, 08:53
ok thanks Nev, will do a bit more digging.

zerowalker
13th December 2019, 00:41
If a an mkv file have seeking issues (it seeks but it acts like an flv file and has to go through the entire file).
Is that the LAV Splitter that's the "problem", or is it the video decoder?
(I am using LAV obviously).

I basically have this issue with certain produced mkv files,
but VLC if i recall doesn't, so while the files might be odd, or perhaps wrong in some way, it can at least be handled.

And i would like to know what the problem is, and hopefully have it solved if possible.

But i need to know what handles the seeking first, and then perhaps give some sample (this might be hard though if you want to see it being slow, as then the file has to be very big, but if it's just a sample that has the issue and you can look at it's data somehow, that's easy enough).

Thanks:)!

LigH
13th December 2019, 09:11
Try to remultiplex the file to a new MKV with MKVToolnix or ffmpeg; if the problem persists, it's more probably the content for this file.

Anyway, different media players may use differently robust techniques (one may fail in case of issues where another may be able to skip). If you use LAV Filters with a generic media player, the DirectShow API may be the culprit; MPC-HC (and probably MPC-BE too) uses LAV Filters with another native API. And VLC uses the same core libraries but with an own "playback engine".

Olivier C.
13th December 2019, 19:40
Hi nevcairiel,

Some seamless branching BD (theatrical version / extended version) can not be played correctly.
The extended version (usually the longest MPLS) can hide some audio tracks. You can check theses hidden tracks in BDInfo, beginning with an asterix '*'.
LAVFDemuxer completely ignores this information. Therefore, when we launch the extend version (i.e. usually the longest playlist), the audio is out of sync when we reach a M2TS for which the initial language selected is not available.

For example :

Extended version :
-> playlist 00802.MPLS english only (german hidden)
-> 00001.M2TS (german and english)
-> 00002.M2TS (english only)

When we reach 00002.M2TS, audio is out of sync if we select german as initial audio track.


One solution could be to check the available audio tracks in the selected playlist (MPLS) and avoid selecting a track hidden by the playlist.
Or maybe LAV could change the audio track dynamically when the current audio language is not available in the current M2TS ?


Thanks a lot

hubblec4
14th December 2019, 13:55
Which Bluray is that. All my seamless branching BDs have ever all streams in all m2ts files. Your case is new for me.

Olivier C.
14th December 2019, 14:57
For example :
Kingdom Of Heaven (2005) - Director's Cut version


BDInfo - Director's Cut version - Spanish and French hidden by the playlist (see asterix '*') :

https://i.imgur.com/c8E9Uxk.jpg


BDInfo - Theatrical version - Spanish and French available :

https://i.imgur.com/HrJV7bF.jpg


Blu-Ray Menus -> French available only in theatrical version (as indicated) :

https://i.imgur.com/Re0DJSL.jpg

hubblec4
14th December 2019, 15:41
Wow, I have never seen this before, could you imagine to share the disc with me?
If so, I will offer my DiscShare tool to easy create a disc chunk.

Olivier C.
14th December 2019, 16:23
Yes, PM :)

I can provide more examples like this one.

I think it's time to fork and fix LAV + MPC-HC for BD stuff (forced subtitles / Blu-ray menus).

hubblec4
14th December 2019, 17:00
I think it's time to fork and fix LAV + MPC-HC for BD stuff (forced subtitles / Blu-ray menus).

This can also be a problem for chapterEditor's BD2mkv Multi-Edition-mkv mode, when MKVToolNix fails while muxing.
There is no check to omit streams which are not used in all editions.

clsid
14th December 2019, 17:06
I think it's time to fork and fix LAV + MPC-HC for BD stuff (forced subtitles / Blu-ray menus).Submit a patch and I will apply it to MPC-HC ;)

Olivier C.
14th December 2019, 17:28
According to my quick debug, I could find that LAV was the culprit.
LAV Splitter takes in account user preferences languages in order to select audio track but ignores that a track can be hidden by a playlist.
When you reach at some point a piece (M2TS) which does not contain the initial audio track selected by LAV (because the cutted scenes are available only in english for example), the audio part you can hear does not belong anymore to the video part. It's quite funny.

nevcairiel
14th December 2019, 17:45
LAV Splitter takes in account user preferences languages in order to select audio track but ignores that a track can be hidden by a playlist.


This is actually done intentionally, as people used to complain that some of the tracks aren't shown.
Its not really clear if a track is supposed to be hidden because its "incomplete", or if its missing for some other unwanted reason from the playlist, which does happen.


I think it's time to fork and fix LAV + MPC-HC for BD stuff (forced subtitles / Blu-ray menus).

Its easy to complain, hard to send improvements. :)
LAV will never offer Blu-ray menus, its not designed for such interactive access (and its also hard to make that happen in a generic filter like LAV, as it requires tight interaction with a player to work properly). It would be easier to make a stand-alone BD menu source filter then trying to shoe-horn that into LAV. Unfortunately all people that tried usually didn't stick around long enough to finish it, or have decent ambitions to do it right.
And without menus, its almost impossible to find forced subtitles reliably on all discs.

Olivier C.
14th December 2019, 17:45
Here is an interesting trace (libbluray) on the playlist which belongs to the Director's cut version :

LAVSplitter.ax(tid c68) 3629801 : Seek Request: 40912906507 (time); 13685463360 (byte), 91791360 (prev byte)
LAVSplitter.ax(tid c68) 3629802 : file_win32.c:47: Closed WIN32 file (0000020457FC6310)
Le thread 0x3664 s'est arrêté avec le code 0 (0x0).
LAVSplitter.ax(tid c68) 3629806 : [BD] file_win32.c:143: Opened WIN32 file Z:\\\BDMV\STREAM\00850.m2ts (00000204582C87A0)
LAVSplitter.ax(tid c68) 3629806 : [BD] register.c:420: bd_psr_write(): PSR7 (PLAYITEM) 0x0 -> 0x22
LAVSplitter.ax(tid c68) 3629806 : [BD] bluray.c:3111: PSR change: psr7 = 34
LAVSplitter.ax(tid c68) 3629806 : [BD] register.c:418: bd_psr_write(8, 524280): no change in value
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:3072: PSR write: psr8 = 524280
[B]LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:293: Stream with preferred language not found
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:314: Selected stream 0 (language eng)
LAVSplitter.ax(tid c68) 3629807 : register.c:418: bd_psr_write(1, 1): no change in value
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:3072: PSR write: psr1 = 1
[B]LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:293: Stream with preferred language not found
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:305: Subtitles disabled (audio is in the same language)
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:314: Selected stream 0 (language eng)
LAVSplitter.ax(tid c68) 3629807 : [BD] register.c:418: bd_psr_write(2, 268369921): no change in value
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:3072: PSR write: psr2 = 268369921
LAVSplitter.ax(tid c68) 3629807 : [BD] register.c:420: bd_psr_write(): PSR8 (TIME) 0x7fff8 -> 0xb6d700
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:3111: PSR change: psr8 = 11982592
LAVSplitter.ax(tid c68) 3629807 : [BD] register.c:420: bd_psr_write(): PSR5 (CHAPTER) 0x1 -> 0x19
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:3111: PSR change: psr5 = 25
LAVSplitter.ax(tid c68) 3629807 : [BD] bluray.c:1632: Seek to 13685463360
LAVSplitter.ax(tid c68) 3629807 : BD Seek to 13685463364, achieved 13685463360, correcting target by 4
LAVSplitter.ax(tid c68) 3629828 : New clip! offset: 38363739337 bytepos: 12822546432

I will try to investigate this a little further because it's quite annoying.

Olivier C.
14th December 2019, 17:54
This is actually done intentionally, as people used to complain that some of the tracks aren't shown.

I can understand but on the other side, this could lead to other problems when a playlist contains different M2TS with different audio tracks (Director's cut with restricted languages, etc).

Some commercial blu-ray players does not show you these hidden tracks.

Olivier C.
14th December 2019, 18:08
Its easy to complain, hard to send improvements. :)
LAV will never offer Blu-ray menus, its not designed for such interactive access (and its also hard to make that happen in a generic filter like LAV, as it requires tight interaction with a player to work properly). It would be easier to make a stand-alone BD menu source filter then trying to shoe-horn that into LAV. Unfortunately all people that tried usually didn't stick around long enough to finish it, or have decent ambitions to do it right.
And without menus, its almost impossible to find forced subtitles reliably on all discs.

I agree with you but :
- Jriver player can offer Blu-ray menus (thanks to libbluray and you)
- KODI player can offer Blu-ray menu

My opinion is that some small improvements can easily be done in MPC for the Blu-ray stuff but there is a lack of interest for the Blu-ray part in the MPC team (MPC-BE / MPC-HC).

Manni
14th December 2019, 23:40
I agree with you but :
- Jriver player can offer Blu-ray menus (thanks to libbluray and you)
- KODI player can offer Blu-ray menu

My opinion is that some small improvements can easily be done in MPC for the Blu-ray stuff but there is a lack of interest for the Blu-ray part in the MPC team (MPC-BE / MPC-HC).

There is a lack of interest because the MPC-BE devs probably rip to mkv and have no interest to spend the time developing menu support. CLSID only maintains MPC-HC and doesn't add features, but nothing stops you from contributing if it's "easy" :).

How about buying jRiver if you want bluray menus? That's what I did.

It's not expensive and it works GREAT.

It's also a way to show your appreciation for the work that Nevcairiel does on LAV :)

ryrynz
15th December 2019, 00:26
Yeah, menu support is no trivial task. Would recommend as Manni suggested.

Olivier C.
15th December 2019, 01:17
I personnaly use Jriver for audio only. I much prefer Kodi for TV shows and movies : 3d cases, animated posters, cinéma experience, sagas, scrapping, flexibility, look and feel, widgets like imdb top 250 and so on. As a french guy, I had to wait until Jriver 24 for multi language scrapping. TV shows posters are not scrapped in my native language but in english. A shame for a paid software.

I asked many times the Jriver team on the feature request post (forums) to use the mouse wheel for volume control but they don't want their users to use their mouses like they want. Too bad for a so simple thing. They are very nice for asking me every year to pay in avance a license for the next release without the possibility to ask a so simple parameter.

In fact, I would much prefer paying nevcareil or someone else for integrating blu Ray menus in MPC-HC rather than paying a 26th license to the Jriver team. Good developpers need to be supported and motivated.
I like MPC-HC and lav filters for mkv but it lacks some features for blu rays.

Just my personnal opinion

Olivier C.
15th December 2019, 01:26
nothing stops you from contributing if it's "easy" :).

For the "easy" improvements, I was referring to hidden tracks in a playlist.

Olivier C.
15th December 2019, 01:30
This is actually done intentionally, as people used to complain that some of the tracks aren't shown.
Its not really clear if a track is supposed to be hidden because its "incomplete", or if its missing for some other unwanted reason from the playlist, which does happen.


Why not selecting a track which is not hidden and let some users select another (hidden) track if they want. I was not asking for hiding them but just selecting a track in a more logical way.
This way, everyone should be happy.

Aleksoid1978
15th December 2019, 03:00
Yes, PM :)
I can provide more examples like this one.

Can you share disc for me - for improvement MPC-BE ?

Olivier C.
15th December 2019, 03:32
Yes, PM

Olivier C.
15th December 2019, 03:50
And without menus, its almost impossible to find forced subtitles reliably on all discs.

Yes, I agree, it's "almost" impossible but a quick scan of 30 sec can guess forced subtitles tracks with a much greater accuracy (98% ?) than the couple MPC-HC/MPC-BE + LAV (50% accuracy in BD FHD ? Better in BD UHD though because there aren't so many separate forced subtitles tracks in UHD).
A friend of mine has developed it in his player and it's very usable. 2% of the time, his tool is wrong.