Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th October 2019, 18:05   #23701  |  Link
v0lt
Registered User
 
Join Date: Dec 2008
Posts: 1,202
Quote:
Originally Posted by nevcairiel View Post
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.
v0lt is offline   Reply With Quote
Old 18th October 2019, 19:29   #23702  |  Link
tiresias
Registered User
 
Join Date: Apr 2004
Posts: 18
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?
tiresias is offline   Reply With Quote
Old 19th October 2019, 09:25   #23703  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 1,510
Take a look at the links of this post.
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v385.28),Win10 LTSB 1607,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED65B8(2160p@23/24/25/29/30/50/59/60Hz)
chros is offline   Reply With Quote
Old 4th November 2019, 16:20   #23704  |  Link
tiresias
Registered User
 
Join Date: Apr 2004
Posts: 18
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?
tiresias is offline   Reply With Quote
Old 4th November 2019, 17:03   #23705  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,840
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 5th November 2019, 20:13   #23706  |  Link
v0lt
Registered User
 
Join Date: Dec 2008
Posts: 1,202
Quote:
Originally Posted by tiresias View Post
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).
v0lt is offline   Reply With Quote
Old 11th November 2019, 08:25   #23707  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,985
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.
huhn is offline   Reply With Quote
Old 11th November 2019, 16:21   #23708  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 5,014
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.
clsid is offline   Reply With Quote
Old 11th November 2019, 16:36   #23709  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,985
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.
huhn is offline   Reply With Quote
Old 11th November 2019, 21:47   #23710  |  Link
littleD
Registered User
 
littleD's Avatar
 
Join Date: Aug 2008
Posts: 307
Quote:
Originally Posted by huhn View Post
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?
littleD is offline   Reply With Quote
Old 12th November 2019, 06:26   #23711  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,985
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.
huhn is offline   Reply With Quote
Old 27th November 2019, 09:14   #23712  |  Link
oldpainlesskodi
Registered User
 
Join Date: Apr 2017
Posts: 196
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?
__________________
Sapphire RX 5700 XT (19.12.2) Ryzen 7 3700x, PRIME X570-Pro, Win 10 x64 (1904.1), Silverstone LC13B-E, Onkyo TX-NR686, Samsung UE55KS8000, Mission M35i speakers, Kodi Dsplayer 17.6 X64

Last edited by oldpainlesskodi; 27th November 2019 at 13:08.
oldpainlesskodi is offline   Reply With Quote
Old 27th November 2019, 18:31   #23713  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 549
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.
__________________
HTPC: Windows 10 1809, MediaPortal 1, LAV Filters, ReClock, madVR. DVB-C TV, Panasonic GT60, 6.0 speakers Denon 2310, Core 2 Duo E7400, GeForce 1050 Ti
el Filou is offline   Reply With Quote
Old 27th November 2019, 19:13   #23714  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,985
https://github.com/alexmarsev/sanear
huhn is offline   Reply With Quote
Old 28th November 2019, 08:59   #23715  |  Link
oldpainlesskodi
Registered User
 
Join Date: Apr 2017
Posts: 196
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.
__________________
Sapphire RX 5700 XT (19.12.2) Ryzen 7 3700x, PRIME X570-Pro, Win 10 x64 (1904.1), Silverstone LC13B-E, Onkyo TX-NR686, Samsung UE55KS8000, Mission M35i speakers, Kodi Dsplayer 17.6 X64

Last edited by oldpainlesskodi; 28th November 2019 at 10:16.
oldpainlesskodi is offline   Reply With Quote
Old 28th November 2019, 13:49   #23716  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,840
"flat" audio is not a technical description that allows any kind of diagnosis. LAV decodes all audio as accurately as possible.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 28th November 2019, 14:09   #23717  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 549
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.
__________________
HTPC: Windows 10 1809, MediaPortal 1, LAV Filters, ReClock, madVR. DVB-C TV, Panasonic GT60, 6.0 speakers Denon 2310, Core 2 Duo E7400, GeForce 1050 Ti
el Filou is offline   Reply With Quote
Old 28th November 2019, 14:28   #23718  |  Link
oldpainlesskodi
Registered User
 
Join Date: Apr 2017
Posts: 196
Ok thanks both.
__________________
Sapphire RX 5700 XT (19.12.2) Ryzen 7 3700x, PRIME X570-Pro, Win 10 x64 (1904.1), Silverstone LC13B-E, Onkyo TX-NR686, Samsung UE55KS8000, Mission M35i speakers, Kodi Dsplayer 17.6 X64
oldpainlesskodi is offline   Reply With Quote
Old 28th November 2019, 19:04   #23719  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,840
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 29th November 2019, 08:53   #23720  |  Link
oldpainlesskodi
Registered User
 
Join Date: Apr 2017
Posts: 196
ok thanks Nev, will do a bit more digging.
__________________
Sapphire RX 5700 XT (19.12.2) Ryzen 7 3700x, PRIME X570-Pro, Win 10 x64 (1904.1), Silverstone LC13B-E, Onkyo TX-NR686, Samsung UE55KS8000, Mission M35i speakers, Kodi Dsplayer 17.6 X64
oldpainlesskodi is offline   Reply With Quote
Reply

Tags
decoders, directshow, filters, splitter

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:07.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.