LAV Filters - DirectShow Media Splitter and Decoders

[andyvt]

For decoding, all H.264/AVC decoders are required to be bit-for-bit identical. Its encoding quality that suffers in hardware vs. software implementations (i.e. x264).

I tested this recently (http://www.missingremote.com/review/intel-quick-sync-examining-haswell-performance), and Haswell's QS results were better than x264 (via Handbrake).

[nevcairiel]

I ran into a dx50 video that plays fine with ffdshow/mplayer, but looks corrupted with LAV, here's a sample:
https://mega.co.nz/#!g0wHiSbR!N64PEETN6LDYkvsy1oEVMGWE-uZkxNhb4k5T1uLLsqw

Looks OK to me.
What exactly is wrong there?

Are you using CUVID mpeg4 decoding? If so, try turning that off?

[NikosD]

This may have been so 5-6 years ago when your CPU was new, but today the CPUs with software decoders are much faster than AMDs or NVIDIAs decoders (on H.264/MPEG2).

Nowadays and the last many years, if you see the figures a huge amount of CPUs sold are Intel's CPUs.
Most of them, even the chiper ones with the lowest performance, have the fastest HW decoder available which is QuickSync and most of the times that HW decoder is faster than the CPU that covers it.

So in other words, every SandyBridge or better CPU has a HW decoder, most of the times faster than the CPU.

There are cases that low frequency Ivy or Haswell CPUs cannot even decode in realtime 4K H.264 clips that QuickSync can do with ease.

Anyway I believe that using a very fast dedicated HW for playback of video, that is offered for free in every Intel CPU or AMD/Nvidia GPU sold the last many years, leaving CPU available for doing things that is more general purpose, is an efficient way of using a modern system.

For laptop users especially, that are tied with battery consumption, I think that HW decoding is almost one-way solution.

[QBhd]

I used to think that way too, but since I had my Phenom II 965 and now my current FX-8350, I just go Software decoding and let the CPU do the work. If I want to do an encode while watching TV, the modern CPU's don't even break a sweat and playback is flawless and smooth. The only downside to doing both at the same time, it takes slightly longer to finish the encode. All one needs to do is make sure you use an encoder that allows you to set the priority to low (meGUI is an example) and presto, no issues with playback while still consuming 100% of the CPU usage. And decoding an mkv remux of a BluRay barely uses 5% of my CPU.

QB

[NikosD]

I have lost contact with modern AMD processors, so can you tell me if you can play in realtime 4K H.264 clips ?

Try for example a tough one like 4K Ducks of 370Mbps clip.

[Reino]

As I'm still using an AMD Athlon XP 3200+ (yes, it's about time I'd upgrade :p) I'm trying to use DXVA as much as possible. Software decoding 1080p is a no go and 720p barely. High cpu loads! I'm also trying to recover a direct link for internet-streams as much as possible too (Youtube, uitzendinggemist.nl (Dutch tv broadcast), etc.), because flashplayers are too much of a burden on my cpu.
Although I hear everyone talking about performance, I'm much more interested in power consumption! Of course on my system that would be a hugh difference (cpu vs. gpu), but I can't imagine even a modern cpu would consume less power decoding a 1080p stream compared to a hardware implementation.


Nev, have you considered these, post1632484 & post1633682, requests?

[STaRGaZeR]

I tested this recently (http://www.missingremote.com/review/intel-quick-sync-examining-haswell-performance), and Haswell's QS results were better than x264 (via Handbrake).

You did the comparison using CQP? Seriously? ;)

[andyvt]

You did the comparison using CQP? Seriously? ;)

I plan to rerun the tests when Intel publishes the driver that supports look ahead. If you'd like to see another method included, LMK.

[STaRGaZeR]

I plan to rerun the tests when Intel publishes the driver that supports look ahead. If you'd like to see another method included, LMK.

You don't need lookahead to test other real life ratecontrol algorithms. Also I'm not sure if you know about --ipratio and --pbratio in x264, but with default settings --qp is not really constant quantizer across all frames. Plus no speed tests, different presets for both QS and x264...

All in all is an apples to oranges, useless comparison against x264. That review is only useful to show how Haswell and Ivy's QS fare against each other.

[andyvt]

You don't need lookahead to test 2-pass, or any other real life ratecontrol algorithm. Also I'm not sure if you know about --ipratio and --pbratio in x264, but with default settings --qp is not really constant quantizer across all frames. Plus no speed tests, different presets for both QS and x264...

All in all is an apples to oranges, useless comparison against x264. That review is only useful to show how Haswell and Ivy's QS fare against each other.

I used Handbrake because it is an accessible tool that many people use for archiving content, then selected its "best" setting. The point wasn't to try each permutation that x264 provides. If there is a specific setting you'd like tested I'm more than happy to include that in the update.

I didn't include speed tests because that doesn't really matter when comparing QS to x264 (it was a different of minutes versus many hours on a very powerful i7).

[mzso]

Looks OK to me.
What exactly is wrong there?

Are you using CUVID mpeg4 decoding? If so, try turning that off?

Yep, I was. It decodes fine if I disable it. So it's a hardware bug then?

[nevcairiel]

More likely a driver bug, but MPEG-4 decoding not being perfect in CUVID is just a known issue.

[moffy]

Well I guess no response means I am basically correct and that there are no plans to introduce PGS subtitles.

[Rimsky]

MKV container has params for cropping image
http://images.vfl.ru/ii/1377148789/37e1fec4/2942030_m.jpg (http://vfl.ru/fotos/37e1fec42942030.html)

_____________


Nobody supports it except VLCPlayer

Can LAVSplitter with LAVVideo work with this params correctly?
It need for remuxes to cropping black bars without recoding

[jj666]

PGS subtitles are working fine.

Cheers,

-jj-

[DragonQ]

MKV container has params for cropping image
_____________

Nobody supports it except VLCPlayer

Can LAVSplitter with LAVVideo work with this params correctly?
It need for remuxes to cropping black bars without recoding
Hmm didn't even know that. Would be useful for correcting Rec.601 mistakes too (e.g. stretching 1920x1080 to 1969x1080 but then cropping the outer 49 pixels) without re-encoding.

[Keiyakusha]

MKV container has params for cropping image

This is a stupid feature imo and only adds confusion. We already have stream sar vs container dar issues. Learn to encode files in the right way to begin with.

[Rimsky]

Learn to encode files in the right way to begin with.

did you meen that bluray encode wrong way?

[Keiyakusha]

did you meen that bluray encode wrong way?
If you're talking about bluray that you remuxed without reencoding, there is no reason to crop anything from it. It should be already correct/compliant/whatever.
If you want to encode some video yourself, regardless of what source you use and you need to crop something - simply crop it properly before encoding.

[Rimsky]

If you're talking about bluray that you remuxed without reencoding, there is no reason to crop anything from it.
or rly?
http://www.youtube.com/watch?v=yTzTpW3kTBE

[Keiyakusha]

or rly?
http://www.youtube.com/watch?v=yTzTpW3kTBE
Not sure what you want to show me with this video but it have nothing to do with mkv cropping.

[nevcairiel]

You do realize that even if this was supported, that LAV wouldn't actually do any cropping, but just forward these values to the renderer, so the renderer does the cropping, right?
Since SVP uses ffdshow, and ffdshow is dead and buried, nothing would change there. :)

[Rimsky]

Not sure what you want to show me with this video but it have nothing to do with mkv cropping.

lighting black bars 21:9 video on the 16:9 TV

[Rimsky]

You do realize that even if this was supported, that LAV wouldn't actually do any cropping, but just forward these values to the renderer, so the renderer does the cropping, right?

nope, I suppose that lavslitter get this crop params and send it to lavvideo and LAVVideo crop it becouse if it forward to the render a) it may be lost in the chain of the filters b) render doesnt support cropping

[Keiyakusha]

You do realize that even if this was supported, that LAV wouldn't actually do any cropping, but just forward these values to the renderer, so the renderer does the cropping, right?
Since SVP uses ffdshow, and ffdshow is dead and buried, nothing would change there. :)
I don't think that mkv cares about in what way this actually happens (or it does?). So it can be implemented on decoder level... b-but this is such a bad idea.

lighting black bars 21:9 video on the 16:9 TV

Ask SVP or whatever software creates these bars to handle this out of the box.
If it can attach these bars to cropped material, it should also be able to crop black bars 1st.

[clsid]

LAV Video does not crop because that is very inefficient, due to data copies and alignment issues, certainly when cropping from left/top.

[clsid]

Well I guess no response means I am basically correct and that there are no plans to introduce PGS subtitles.
You need a subtitle render such as xy-VSFilter.

[STaRGaZeR]

I used Handbrake because it is an accessible tool that many people use for archiving content, then selected its "best" setting. The point wasn't to try each permutation that x264 provides. If there is a specific setting you'd like tested I'm more than happy to include that in the update.

I didn't include speed tests because that doesn't really matter when comparing QS to x264 (it was a different of minutes versus many hours on a very powerful i7).

That's because of the settings you used. As I said it's an apples to oranges comparison. No need to try every permutation, use the presets for quick testing. Last time I checked the faster presets in x264 were comparable in speed with higher quality. And for f*cks sake, don't use CQP.

[nevcairiel]

nope, I suppose that lavslitter get this crop params and send it to lavvideo and LAVVideo crop it becouse if it forward to the render a) it may be lost in the chain of the filters b) render doesnt support cropping

Sucks if you use a bad renderer. :)
If i ever implement it, i will quite certainly not make LAV apply the cropping, because its just a big headache, especially with DXVA decoding. A renderer can even crop with DXVA.

[mzso]

You do realize that even if this was supported, that LAV wouldn't actually do any cropping, but just forward these values to the renderer, so the renderer does the cropping, right?
Since SVP uses ffdshow, and ffdshow is dead and buried, nothing would change there. :)

Since when?

[derpycat]

Question about audio: if I want a 5.1 16-bit output (actually 5.0) for everything, not including stereo, what would be the correct settings?

I currently have "Output Formats" in the first tab set to only "16-bit Integer", in the second tab I have "Enable Mixing" set to 5.1. Do I need to touch the mix levels? I also have "Don't mix Stereo sources" ticked. Any changes?

Thanks

[kasper93]

Since when?

Quite some time actually.

[nevcairiel]

Question about audio: if I want a 5.1 16-bit output (actually 5.0) for everything, not including stereo, what would be the correct settings?

I currently have "Output Formats" in the first tab set to only "16-bit Integer", in the second tab I have "Enable Mixing" set to 5.1. Do I need to touch the mix levels? I also have "Don't mix Stereo sources" ticked. Any changes?

That sounds about right.

[derpycat]

Thanks, and also should I tick "Use dithering for 16-bit input?"

[nevcairiel]

For best quality that should be ticked, yes. Should be on by default.

[derpycat]

It's because I just unticked everything but 16-bit, but I shall tick this one too. Cheers

[DragonQ]

Will be testing a 10-bit 1080p video on my HTPC tomorrow. I assume CUVID doesn't support this and LAV will fall back to software decoding? Wish me luck. :scared:

[nhakobian]

Will be testing a 10-bit 1080p video on my HTPC tomorrow. I assume CUVID doesn't support this and LAV will fall back to software decoding? Wish me luck. :scared:

No hardware decoder currently decodes 10-bit video. If my memory serves, it should fall back to software.

[moffy]

Thank you clsid for your response. As I suspected all but DVD subtitles are handled externally to LAVVideo. Well I might try and add them, as I need a hook into both the DVD and PGS subtitles. Not that familiar with DirectShow or LibAV but I'll see how I go. Any advice appreciated.

[DragonQ]

This is a stupid feature imo and only adds confusion. We already have stream sar vs container dar issues. Learn to encode files in the right way to begin with.
Tell that to broadcasters.

[DragonQ]

That sounds about right.
I've noticed that when channels switch from 5.1 to 2.0 for adverts, the volume increases. I'm not talking about DRC used for adverts, I mean the actual volume level goes up because the switch is often made during the sponsor clips and I hear the sound jump up/down. I'm unsure if it's because of my settings or just something that happens when downmixing. My settings are as follows:

[X] Enable Mixing
[4.0] Output Speaker Configuration
[0.71] Center Mix Level
[0.71] Surround Mix Level
[??] LFE Mix Level

[ ] Don't Mix Stereo Sources
[X] Normalise Matrix
[X] Clipping Protection

[None] Matrix Encoding

[nevcairiel]

normalize matrix will reduce the volume when downmixing, so when it switches to stereo and doesnt downmix anymore, the volume reduction goes away.
I would suggest to disable normalize matrix and just use clipping protection.

[DragonQ]

I had assumed that when Don't Mix Stereo Sources was unticked, the downmixing parameters would still apply for stereo sources, including normalising the matrix. Would this not make more sense, and make the volume level match?

[nevcairiel]

Matrix normalization is only used when you actually downmix something (and when the matrix sums go above > 1.0), but since stereo fits into 4.0, there is no need to downmix, its just padded with empty channels.
All it does is make sure that no output channel has a sum of source channgels above 1.0, so that you never ever can get clipping. It does not guarantee consistent volume between streams.

[DragonQ]

Right, but would it not be more sensible to normalise the matrix always to get consistent volumes? People could still avoid this by ticking Don't Mix Stereo Sources.

[nevcairiel]

Thats not what matrix normalization does.

All it does is normalize it so that the maximum mixing coefficient is 1.0, this completely depends on your mixing factors, input and ouput channels.
If you want consistent volumes for all streams, turn it off. It actively works against this.

[shpitz]

Hi,
using MPC-BE with LAV Splitter v0.58.2 video plays upside-down.
If I use the internal splitter it show correctly.

Am I missing something?

This is an MP4 recorded by a phone.

[wanezhiling]

Sample file, please.

[betaking]

how to set windows environment variables to complier lav?

[Aleksoid1978]

Hi,
using MPC-BE with LAV Splitter v0.58.2 video plays upside-down.
If I use the internal splitter it show correctly.

Am I missing something?

This is an MP4 recorded by a phone.

I think it's record with rotate flag.