View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
jmone
24th April 2012, 10:29
If you are going to use madVR, I don't suggest using DDR3-1333.
Interesting as I get 0 dropped frames on 50i / 50p / 60i material on the i7 2600K 3000 iGPU using DDR3-1333 with MN. FYI - I agree with your EDID comments, I need to use a DVI (or HDMI) detective plus to stop issues when the "source" changes (AVR swithes away). I'm just not sure the upgrade to IVB is worth it.....
EDIT: Mem is Kingston KVR1333D3N9K2/8G 8GB KIT 1333MHz (PC3-10600) DDR3 NON-ECC CL9 240pin
jakmal
24th April 2012, 10:33
EVR uses what the driver recommends as the best algorithm. This is HW and driver specific. Different GPU can give completely different results.
EVR-CP is an open source project that implements EVR's interfaces.
Using EVR (in SNB/IVB) you'll get:
* Context adaptive scaling
* Deinterlacing and all video post processing algorithms found in the iGPU control panel.
Does this mean that context adaptive scaling isn't made available through the DXVA calls that EVR-CP makes? I look at the scaling performance of EVR just now, and it is pretty neat, and I think the quality is the same as that of the PowerDVD playback screenshot.
Any way to bring up statistics similar to what is obtained in EVR-CP by pressing Ctrl-J ?
aufkrawall
24th April 2012, 10:40
Considering IVB is even native 1600 now, getting 1333 seems just dumb. :)
I'd rather wait and spend the money on a good 28nm GPU.
Or on Trinity. ;)
nevcairiel
24th April 2012, 11:09
I'd rather wait and spend the money on a good 28nm GPU.
How is memory speed related to an external GPU?
A good GPU won't make bad RAM go fast. :p
egur
24th April 2012, 11:23
Does this mean that context adaptive scaling isn't made available through the DXVA calls that EVR-CP makes? I look at the scaling performance of EVR just now, and it is pretty neat, and I think the quality is the same as that of the PowerDVD playback screenshot.
Any way to bring up statistics similar to what is obtained in EVR-CP by pressing Ctrl-J ?
The quality should be the same as PowerDVD/WinDVD renderer as they'll use the HW scaler as well. They might opt for different video processing settings or even add their own algorithms into the mix.
For subtitles I use vobsub (2.0 if I remember correctly) so I don't rely on the renderer. Not optimal but it works just fine and I mostly watch TV shows and movies with subs.
I don't watch live TV through my HTPC so deinterlacing is hardly ever used.
EVR-CP produced some performance problems (i7-2600) on some situations and provided lower quality than EVR.
Sync issues exist but they are not that bad and mostly insignificant. It's not optimal but the whole setup is very simple (no dGPU).
People have different setups and watch different content.
For my needs the top priority are scaling quality and proper luma levels which work very well for me. I use very mild NR and sharpening. Mild settings on the total color control as well.
aufkrawall
24th April 2012, 11:25
How is memory speed related to an external GPU?
A good GPU won't make bad RAM go fast. :p
I haven't read the whole conversation. So I assumed RAM speed was somehow related to iGPU/shared memory stuff.
I don't see why one would need >1333 Mhz RAM to avoid dropped frames with madVR and hardware decoding like CUDA/QS.
Even software decoding should work.
nevcairiel
24th April 2012, 11:30
If your CPUs memory controller is officially rated for 1600Mhz, you really should get 1600 (or above) RAM, otherwise you just do waste performance. Its not like there is a big price gap (if one at all).
That the iGPU benefits from the memory speed more then most CPU applications is one factor, but not the whole argument. :)
aufkrawall
24th April 2012, 11:47
If your CPUs memory controller is officially rated for 1600Mhz, you really should get 1600 (or above) RAM, otherwise you just do waste performance. Its not like there is a big price gap (if one at all).
I've just tested my i5 2500k with 1033 Mhz RAM and there was no dropped frame either. :)
Test videos weren't easy: 1080p, 60fps, high bitrates and pure software decoding.
My assumption is: If there are dropped frames with low memory frequency, the problem could be caused by something else.
That the iGPU benefits from the memory speed more then most CPU applications is one factor, but not the whole argument. :)
Maybe the money should be spend on watercooling for CPU. ;)
Then you can have higher clocks which will be much more gainful.
nevcairiel
24th April 2012, 12:28
You really don't get the point. Oh well.
The point is that 1600Mhz RAM isn't more expensive then 1333Mhz RAM, both are about the same price around here, so when you get 1333 instead, you're just doing it wrong.
The bonus that the iGPU really benefits from the 1600Mhz over the 1333Mhz is irrelevant for that fact (although something important to know if you want to use the iGPU)
And no, overclocking won't help if your memory bandwidth is limiting.
SamuriHL
24th April 2012, 13:43
Guess I'm glad I sprung for the fast ram. :)
Sent from my Xoom using Tapatalk 2
STaRGaZeR
24th April 2012, 14:28
EVR doesn't offer proper subtitle support, and its vsync accuracy is a mess.
What accuracy? lol
andyvt
24th April 2012, 14:51
If its by design, its a bad design.
Why offer an option that doesn't work? Even more so, one that resets on its own all the time? :p
The rationale behind the feature was that they wanted it to reset when a new display was detected.
Obviously that doesn't work with HDMI displays because every time the system resyncs with the display it "detects" a new display. The important thing is that they are now aware of the use case and issue with the current approach and have at the very least documented a change request. While I don't personally find that feature valuable, it should work properly for those who do.
Anyway, its sad such a trivial issue will force me to install a GPU in this box. Well, to be honest the iGPU wasn't fast enough for madVR to be 100% reliable anyway, 720p60 content wasn't handled fast enough.
Sadly the AnandTech HTPC review didn't use 720p content, because with madVR 1080p actually has less load then 720p (1080p does not need Luma scaling)
What did you set the fix GPU memory size to in BIOS? What scaling settings are you using?
I did most of my testing with 480i content and as long as FSE was enabled it worked quite well.
aufkrawall
24th April 2012, 14:53
You really don't get the point. Oh well.
I did get it, no worries.
The point is that 1600Mhz RAM isn't more expensive then 1333Mhz RAM, both are about the same price around here, so when you get 1333 instead, you're just doing it wrong.
Did I say anything contrary?
I don't think so. ;)
But you also spoke of RAM with more than 2000 Mhz which doesn't make much sense at all.
And no, overclocking won't help if your memory bandwidth is limiting.
There is none, not even really with 1333 Mhz and IVB.
As long as you don't plan to do massive encoding, anything faster than 1600 Mhz is pointless, waste of money.
nevcairiel
24th April 2012, 15:39
What did you set the fix GPU memory size to in BIOS? What scaling settings are you using?
I did most of my testing with 480i content and as long as FSE was enabled it worked quite well.
Of course i increased the memory, to the maximum which seemed to be 1024MB on my board.
As i explained to jakmal earlier, 720p content is more computationally expensive to upscale to 1080p. He also confirmed that a 720p60 camcorder clip does not work flawlessly for him either.
My scaling was mentioned earlier in the thread, MN for Chroma, Lanczos3 for Luma.
As long as you don't plan to do massive encoding, anything faster than 1600 Mhz is pointless, waste of money.
Actually, if you plan to use the iGPU, it does benefit from faster memory. 2133 may be overkill, but 1833 will still show benefits.
Its not like 2133 memory is extremely expensive or anything, i paid for the 8GB kit 60€. A similar kit (same brand and line) with 1600 was 50€ at the time. I don't mind the 10€, i never did try to go cheap on my PCs, and i'll not start now. If i run a 300€ CPU, the 10€ for better RAM won't hurt. :p
Thinking about it, RAM has become so extremely cheap over the years....
DragonQ
24th April 2012, 15:46
There is none, not even really with 1333 Mhz and IVB.
As long as you don't plan to do massive encoding, anything faster than 1600 Mhz is pointless, waste of money.
I briefly considered getting an i3 (Sandy Bridge) and 1833 MHz RAM when building my HTPC but then I realised that a Celeron (Sandy Bridge), 1333 MHz RAM* and a GT 430 was cheaper and offered other advantages (such as hardware decoding with CUVID, better hardware deinterlacing, and custom refresh rates).
The i3 route would've given me a better CPU but I had no need for that when using hardware decoding and deinterlacing, so I considered it a waste of money.
If I were making the decision now, it'd be tougher because of the introduction of QuickSync and DXVA2 into LAV Filters, plus the fact that having a better CPU (i3 vs Celeron) would help with on-the-fly transcoding etc.
*Celerons only support running DDR3 SDRAM at 1066 MHz but 1333 MHz RAM was actually cheaper at the time. :p
SamuriHL
24th April 2012, 15:46
That's why I opted for the 2133 ram I got. It wasn't cheap, but, I will be doing TONS of encoding work on that machine. Personally, I'll be using my 5870 for output, but, I do want to try to get QS working for decoding and encoding in Media Converter. That would ROCK.
andyvt
24th April 2012, 15:53
Of course i increased the memory, to the maximum which seemed to be 1024MB on my board.
Common sense isn't common.
As i explained to jakmal earlier, 720p content is more computationally expensive to upscale to 1080p. He also confirmed that a 720p60 camcorder clip does not work flawlessly for him either.
My scaling was mentioned earlier in the thread, MN for Chroma, Lanczos3 for Luma.
Ganesh and I did not see identical results during testing.
The stats were generated w/ your settings and FSE enabled w/ DDR3-1333. While it was running the render queue was in the 14-16 range. I dropped it back to windowed to take the screenshot.
http://babgvant.com/images/hd4000mvl3fse.JPG
Not perfect, but not terrible either. When I get a chance I'll see if the results are any different w/ DDR3-1600.
aufkrawall
24th April 2012, 16:23
Actually, if you plan to use the iGPU, it does benefit from faster memory. 2133 may be overkill, but 1833 will still show benefits.
Its not like 2133 memory is extremely expensive or anything, i paid for the 8GB kit 60€. A similar kit (same brand and line) with 1600 was 50€ at the time. I don't mind the 10€, i never did try to go cheap on my PCs, and i'll not start now. If i run a 300€ CPU, the 10€ for better RAM won't hurt. :p
Thinking about it, RAM has become so extremely cheap over the years....
Yeah, it's not a big difference.
But I'm a a bit penny pinching when it's not about GPU power.
I paid 40€ for 2x 4 GB 1333 Mhz in December. When I got SNB I just overclocked it to 1600.
Common sense isn't common.
Ganesh and I did not see identical results during testing.
The stats were generated w/ your settings and FSE enabled w/ DDR3-1333. While it was running the render queue was in the 14-16 range. I dropped it back to windowed to take the screenshot.
http://babgvant.com/images/hd4000mvl3fse.JPG
Not perfect, but not terrible either. When I get a chance I'll see if the results are any different w/ DDR3-1600.
Try using new FSE with 16 frames presented in advance.
It helped me with a H.264 I444 60fps video.
andyvt
24th April 2012, 16:45
Try using new FSE with 16 fps presented in advance.
It helped me with a H.264 I444 60fps video.
http://babgvant.com/images/hd4000720pfsep16.jpg
No dropped frames with that setting selected. The presentation glitch occurs as playback begins.
noee
24th April 2012, 16:56
Pardon for the butt-in, but are you guys using the latest madVR? I thought the "GPU ram in use..." item was removed recently....
CruNcher
24th April 2012, 17:08
Does this mean that context adaptive scaling isn't made available through the DXVA calls that EVR-CP makes? I look at the scaling performance of EVR just now, and it is pretty neat, and I think the quality is the same as that of the PowerDVD playback screenshot.
Any way to bring up statistics similar to what is obtained in EVR-CP by pressing Ctrl-J ?
PowerDVDs custom EVR renderer fully supports SB and IVB, MPC-HC might be soon.
This (http://babgvant.com/images/snapshot_2500000064.png) is MS Decoder + EVR in GraphStudioNext @native size. LMK if you wanted something different.
Something looks strange there is no Chroma upsampling @ all visible here also you have to really work on your framework you need to hit the same frame :)
Is the RGB-HDMI black level issue only in IvyBridge?
My HTPC has a SandyBridge connected the same way and the black levels are perfect. I have Panasonic plasma (50" V20) with excellent black levels - makes it very easy to spot wrong settings.
I personally don't use MadVR, I use EVR.
EVR results were missing from the Anadtech review. EVR-CP provides worse results at worse performance. I don't see a reason to use it in SandyBridge or newer platforms.
8 tap Lanczos exhibits too much ringing (in upscaling). For MadVR, probably better (quality wise) to use 6 taps or even Bi-cubic.
In order to achieve Lanczos4 (8 taps) sharpness without (or little :) ) ringing, one needs a context adaptive algorithm like EVR provides. I hope MadVR will add this.
BTW, latest drivers on Intel's site is v2656.
Jan is working to support EVR scaling in EVR-CP once thats finished will be awesome, though of course waiting for the ffdshow-quicksync implementation of VPP features ;)
andyvt
24th April 2012, 17:10
Pardon for the butt-in, but are you guys using the latest madVR? I thought the "GPU ram in use..." item was removed recently....
http://babgvant.com/images/newmadvrhd4000.jpg
Needed an update.
aufkrawall
24th April 2012, 17:13
No dropped frames with that setting selected.
So, it's fine for you?
Btw: Are you using LAV splitter?
It reports 59.94 fps but maybe your video has exactly 60 fps.
This is fixed in the nightlies.
The presentation glitch occurs as playback begins.
If it's not related to FSE switch or normal issues in the beginning, it could be a glitch in the video itself. I have such a sample with lots of glitches.
andyvt
24th April 2012, 17:21
So, it's fine for you?
Btw: Are you using LAV splitter?
It reports 59.94 fps but maybe your video has exactly 60 fps.
This is fixed in the nightlies.
Yes to both. Playback works well. If you have a particular sample/content type you'd like tested LMK.
The 720p file is 59.94, it's an ATSC TV recording.
jakmal
24th April 2012, 21:23
Yes to both. Playback works well. If you have a particular sample/content type you'd like tested LMK.
The 720p file is 59.94, it's an ATSC TV recording.
Andrew,
My 720p60 testclip was this:
http://www.tomguilmette.com/wp/download/8/
[ downloaded from http://www.tomguilmette.com/wp/my-blog/archives/2500 ].
Can you check that with your configuration? So, if I understand right, you are saying on the whole that you have had better luck with using madVR on i7-3770K compared to Hendrik and me...
SamuriHL
24th April 2012, 21:43
And I can't play yet with my chosen madVR settings since I'm still waiting for my favorite shops to get the 3770k in stock. sigh. :)
andyvt
24th April 2012, 22:00
Andrew,
My 720p60 testclip was this:
http://www.tomguilmette.com/wp/download/8/
Taken just before the clip ended.
http://babgvant.com/images/gtssample.jpg
38 (of the 40) of the dropped frames and the 9 presentation glitches occurred in the first ~5 seconds.
nevcairiel
24th April 2012, 22:21
The difference seems to be the decoder used. Using QuickSync, the GPU is overloaded with 720p60, because it puts some extra strain on the GPU. With software decoding, the situation improves.
Still leaves the problem with my black levels :(
The desktop looks stupid with limited range.
jakmal
24th April 2012, 22:40
38 (of the 40) of the dropped frames and the 9 presentation glitches occurred in the first ~5 seconds.
If you let it run in 'Repeat forever' mode, you can see whether it actually drops any frames the second or third time around...
The difference seems to be the decoder used. Using QuickSync, the GPU is overloaded with 720p60, because it puts some extra strain on the GPU. With software decoding, the situation improves.
I tried both QS and DXVA2 CB.. so it looks like the GPU is still not fast enough for HW decode + madVR processing also.. ? I think that is quite acceptable.. Did you check the difference in CPU usage between the two ? i.e, how much more CPU usage exists when you do SW decode and then send to the GPU for madVR processing vs. doing GPU decode - copy back to system RAM? - and make madVR take it back to the GPU for further processing? In my experience, DXVA2 CB and DXVA2 native + madVR (which is basically SW decode, because I saw the active decoder to be avcodec in the LAV Video Decoder box) had very similar CPU usage...
On a separate note, do you guys observe any difference when the amount of DRAM devoted to the iGPU is varied in the BIOS?
nevcairiel
24th April 2012, 22:49
Did you check the difference in CPU usage between the two ? i.e, how much more CPU usage exists when you do SW decode and then send to the GPU for madVR processing vs. doing GPU decode - copy back to system RAM? - and make madVR take it back to the GPU for further processing? In my experience, DXVA2 CB and DXVA2 native + madVR (which is basically SW decode, because I saw the active decoder to be avcodec in the LAV Video Decoder box) had very similar CPU usage...
I did not compare the CPU usage directly, no.
However, a 3770 can process a 1080p or 720p file very easily. Also need to check the performance state of the CPU, in QS mode my 2600k will stay in its lowest clock state, while SW decoding actually causes it to go to max speed. Didn't check IVB.
Anyway, more tests when i have the time.
jakmal
24th April 2012, 22:54
I did not compare the CPU usage directly, no.
However, a 3770 can process a 1080p or 720p file very easily. Also need to check the performance state of the CPU, in QS mode my 2600k will stay in its lowest clock state, while SW decoding actually causes it to go to max speed. Didn't check IVB.
Anyway, more tests when i have the time.
Yes, Resource Monitor helpfully states the performance state (wrt clock speeds) of the CPU when giving the usage graphs.. Do you have any other tool to lump the CPU usage and the performance state together as a single metric?
chros
25th April 2012, 10:04
As i explained to jakmal earlier, 720p content is more computationally expensive to upscale to 1080p.
Yes, you are completely right.
Or take a laptop with hd4000 iGPU and with a 1280*720 display (or other non FullHD display with the desktop machine):
how well a 1080p24fps and a 1080p30fps will be played? (I even don't write down the last option in this row ... :) )
mindbomb
25th April 2012, 15:56
that should be even harder to do.
i'd like to see more how ram and gpu core overclocking play into this.
also, you can always lower chroma to bilinear, that isn't that big of a deal imo, and that should provide a big performance boost.
nevcairiel
25th April 2012, 16:14
Its been a while, but i have a fresh test build:
x86: http://files.1f0.de/lavf/LAVFilters-0.50.1-50-ga4c4634.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.50.1-50-ga4c4634-x64.zip
Not really anything big and note-worthy, its just been so long since the last release and so much has changed in ffmpeg that i feel like its better to post it here before tagging a release.
So, if you want, test away, and report any "new" problems!
Especially MKV has changed a bit, to avoid some issues i had to re-structure how the code is integrated. Hopefully, no visible changes at all (or well, maybe a crash less in some crazy circumstances!)
Anarchitektur
25th April 2012, 16:30
Its been a while, but i have a fresh test build:
x86: http://files.1f0.de/lavf/LAVFilters-0.50.1-50-ga4c4634.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.50.1-50-ga4c4634-x64.zip
Not really anything big and note-worthy, its just been so long since the last release and so much has changed in ffmpeg that i feel like its better to post it here before tagging a release.
So, if you want, test away, and reports any "new" problems!
Especially MKV has changed a bit, to avoid some issues i had to re-structure how the code is integrated. Hopefully, no visible changes at all (or well, maybe a crash less in some crazy circumstances!)
so this is latest "3d6a58a15573 - Remove now unused libz" or earlier?
nevcairiel
25th April 2012, 16:32
so this is latest "3d6a58a15573 - Remove now unused libz" or earlier?
technically its one before that, but the commit has no real influence.
jakmal
25th April 2012, 17:19
Hendrik,
Does the new release remove the max. 1080p limitation for DXVA2 / QS decode in LAV Video Decoder ? (the one that Andrew fixed locally to test out 4K acceleration in his review at Missing Remote)
Thanks!
nevcairiel
25th April 2012, 17:21
Does the new release remove the max. 1080p limitation for DXVA2 / QS decode in LAV Video Decoder ? (the one that Andrew fixed locally to test out 4K acceleration in his review at Missing Remote)
Of course not.
Like i explained numerous times before, the auto-detection of 4k hardware support is not working properly (yet), so i blacklisted it.
However, i only did so for DXVA2 Native.
QS has no such artificial limitation. If 4K decoding does not work (it doesn't for me), its most likely your driver being bad (or go blame egur)
Anarchitektur
25th April 2012, 17:57
...
BTW, regarding cryptic naming of files/builds, is it some sort of hash or something else... btw1 I briefly tried my videos and everything is fine with ga4c4634 including MKV on pot and MPC-HC
nevcairiel
25th April 2012, 18:03
BTW, regarding cryptic naming of files/builds, is it some sort of hash or something else...
Its the hash of the Git revision taken for this build.
0.50.1-50-ga4c4634.zip
0.50.1 is the last release
50 is the number of commits since then.
a4c4634 is the hash of the commit.
Dunno why they put a "g" before the hash, i just use "git describe" to name the files.
aufkrawall
25th April 2012, 19:59
nev,
in ffdshow AYUV output is unticked by default. If the renderer is EVR, it converts to RGB32, and if it's madVR, it converts to Y416 (lossless, I assume?).
This is the best behavior, IMHO.
It must be possible with LAV too. :)
nevcairiel
25th April 2012, 20:00
Converting 8-bit to 16-bit "just because" is NOT a good idea. I will never artificially increase the bitdepth of a format.
The next version will enable YV24 output though.
Pat357
25th April 2012, 20:00
All Nightly builds after Version: 0.50.1 – 2012/03/29 have constant stutters in video when used together with SVP (60fps interpolation).
See graph.
Going back to official version 0.50.1 from 2012/03/29 solves the stuttering problem.
Something else is wrong : look at your screen refresh-rate from the first picture : 56, ... an probably not even constant while it should be 60.
That's the reason why you see these "spikes".
Try with Madvr to find out your real refresh rate from your display.
aufkrawall
25th April 2012, 20:20
The next version will enable YV24 output though.
May I ask again what the pupose is?
madVR works just fine with AYUV.
nevcairiel
25th April 2012, 20:22
May I ask again what the pupose is?
madVR works just fine with AYUV.
Didn't you just try to make an argument for disabling AYUV by default?
I told you that converting to 16-bit is a bad idea, and instead i offer a proper 8-bit type, truely lossless. Whats the question now?
You seem confused today. :)
aufkrawall
25th April 2012, 20:27
Didn't you just try to make an argument for disabling AYUV by default?
I told you that converting to 16-bit is a bad idea, and instead i offer a proper 8-bit type, truely lossless. Whats the question now?
I thought that "replacing" AYUV by YV24 would fix the brightness issue with EVR. But then I read that EVR doesn't support YV24 at all.
So, what will happen with EVR and I444 source, blank/black screen?
You seem confused today. :)
Still? :D
nevcairiel
25th April 2012, 20:29
The priority is now YV24 > AYUV > RGB > ..etc.
So if EVR doesn't accept YV24, and AYUV is disabled, it'll go to RGB.
Simple enough now? :D
aufkrawall
25th April 2012, 20:31
The priority is now YV24 > AYUV > RGB > ..etc.
So if EVR doesn't accept YV24, and AYUV is disabled, it'll go to RGB.
Simple enough now? :D
Ok, thanks.
If that stupid EVR would just work right with AYUV...
dukey
25th April 2012, 21:12
It does. But the 'A' part in AYUV is for apha, it's only for substreams. The documentation does explicitly say AYUV is not supported on the primary pin. It's no wonder it doesn't work right.
hmkay
26th April 2012, 07:46
I'm using the advanced subtitles option to have only forced subtitles for my prefered audio and normal subtiltes for everything else. This works when opening a new file but not when switching audio streams while playing. I'm doing it directly inside the LAVsplitter filter menu. If there's no error on my part I'd like to request that the splitter re-estimates its subtitles choice everytime the audio stream gets changed. And wouldn't a ruleset like this be the prefered default setting for most people (prefered audio: forced, everything else, normal)?
Also is there a way to make MPC use the LAV Splitter Source instead of File Source? Blocking the later and setting LAV as preferred only gives me a "Cannot render file".
http://i.imgur.com/U826S.png
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.