LAV Filters - DirectShow Media Splitter and Decoders

[Nintendo Maniac 64]

I've found it problematic actually, with a low clocked athlon x2, and playing the video through chrome's html5. That might have been more an issue with chrome's decoder though.

That's VP9 - YouTube no longer makes the VP8 formats available other than for 360p (which on PC is a "plan C" behind VP9's "plan A" and h.264's "plan B", though it's used as "plan A" on low-performance embedded platforms like the Nintendo Wii).

You can see which format is being used via right-clicking on the video and then selecting "Stats for nerds".

FYI, I used an Athlon 64 x2 4800+ as my main PC until the mobo died 6 months ago.

[ryrynz]

All 64 bit chips have SSE2 don't they? I take it 64 bit LAV is built with the same requirements as the 32 bit builds.

If so, how come the 64 bit versions don't have SSE2 requirements? When I tested an SSE2 32 bit build there wasn't much of an improvement
but maybe things are a bit different now with the newer codecs or maybe 64 bit builds would stand to gain a larger speed increase.

When were you planning on implementing the future SSE2 requirement Nev?

[LigH]

As far as I remember, HEVC decoding can have a measurable speed difference between 32 bit and 64 bit code, making good use e.g. of the wider and more CPU registers.

And yes, SSE2 should be available on quite all common 64 bit CPUs for desktop PCs. It was introduced in the intel Pentium 4 and adapted for Athlon64 by AMD.

[nevcairiel]

All 64 bit chips have SSE2 don't they? I take it 64 bit LAV is built with the same requirements as the 32 bit builds.

If so, how come the 64 bit versions don't have SSE2 requirements?

All 64-bit builds automatically make use of SSE2, since as you say its available in all 64-bit CPUs.

[NikosD]

x64 is an architecture built by AMD as an extension to x86, which was built by Intel and Intel originally had no plans of being compatible with x64, but after a while followed AMD.

SSE2 is a requirement for x64 architecture, but not for x86.

So you can build a 32bit application without SSE2, although the first Pentium 4 processors were x86 and they had SSE2, but not the x86 Athlons which had SSE only.

About LAV x64 and HEVC decoding specifically, it's a lot faster than LAV x86.

Not because of the superiority of x64 vs x86 architecture, but because of specially written assembly code available only to x64 HEVC decoding algorithm.

The x86 HEVC lucks that assembly optimised code and most likely the ffmpeg developers of x64 assembly will never port it to x86 assembly.

Moreover, Nevcairiel uses a special coding of intrinsics from OpenHEVC project only for LAV x64 version, which further increase the speed of LAV x64 vs LAV x86 for HEVC decoding.

[nevcairiel]

Moreover, Nevcairiel uses a special coding of intrinsics from OpenHEVC project only for LAV x64 version, which further increase the speed of LAV x64 vs LAV x86 for HEVC decoding.

Actually thats not true, many of the intrinsics are also available in 32-bit builds, however due to the limited number of registers in 32-bit they are not as fast as in a 64-bit build, because it needs to load/store from memory more often.

[NikosD]

The difference is huge between LAV x64 and LAV x86 and I wouldn't say "not as fast as".

If the problem is in the limitations of x86 architecture and because the real number of registers is huge in all modern processors, maybe converting intrinsics to assembly code could produce close to x64 performance for x86 ?

Because other implementations of x86 HEVC decoders like Strongene's Lentoid, Cyberlink's PowerDVD and above all Microsoft's Windows 10 HEVC decoder are usually faster or a lot faster than LAV x86.

[ryrynz]

All 64-bit builds automatically make use of SSE2, since as you say its available in all 64-bit CPUs.

Was meaning the compiler optimization from the future build, if they all have the instruction set then might as well make it a requirement for the 64 bit build.

[LigH]

In x86-64 (AMD64) execution mode, twice as many CPU registers are available as in x86-32 mode. You can't use the other half while executing a Win32 application, there are no valid opcodes for accessing these registers in this mode.

Avoiding RAM access by preferring CPU register access instead may cause a remarkable speedup. And the more often it can be avoided repeatedly in tight loops, the more it will affect the overall performance.

[nevcairiel]

Was meaning the compiler optimization from the future build, if they all have the instruction set then might as well make it a requirement for the 64 bit build.

SSE2 is active for x64 builds already. Like I said, unless you specifically go out of your way to turn it off, its always on for 64-bit builds.

If the problem is in the limitations of x86 architecture and because the real number of registers is huge in all modern processors, maybe converting intrinsics to assembly code could produce close to x64 performance for x86 ?

It would yield quite significant speed-ups for 32-bit as well. You are welcome to do that. :)
The problem is that its quite complex work and requires a lot of time, and most developers just don't care about 32-bit anymore. Why would they? You could just use 64-bit and get all the speed-ups without weeks and weeks of extra developer work! :)

The only reason to use 32-bit is legacy stuff. The solution is to get rid of legacy software and use modern solutions instead!

[NikosD]

For many people (but clearly not me) in this forum and similar, a good reason for x86 apps is MadVR, since is still x86 I think :)

Personally I always use the x64 version, if both exist.

[madshi]

There will be an x64 version of madVR sooner or later. There was no good reason for that until now, but HEVC decoder performance is something I can't ignore. However, there's not much real HEVC content out there, yet, so x64 madVR is still not at the very top of my priority list.

[NikosD]

Good to know for many people using and loving - I could say - MadVR.

I personally have used a lot more times eac3to and other programs developed by you than MadVR, but I could be the only one here :)

[zerowalker]

nevcairiel did you see my question before about QS and Zoom Player?

[nevcairiel]

nevcairiel did you see my question before about QS and Zoom Player?

Use DXVA2-CB if you want trick mode playback (faster or slower playback).

[bergqvistjl]

Hi, I have files that i've recorded via satellite h.264 video with AC3 audio where the Audio stream changes mid-playback from a 192kbps 2.0 feed into a 384kbps 5.1 feed (Still AC3, and still on a single audio stream). Now it seems that LAV isn't registering the change from 2.0 to 5.1 or vice versa. It seems to only take the channels specified in the file's container header (I think), which appears to be the audio format at the first frame of the video, and then use that throughout. I can see this in the Status tab of the audio decoder.

It still says that the format is AC3 - 2.0 channels yet a couple of seconds into the video, the channels switch to 5.1, yet the Mixer tab doesn't appear to have recognised this change.

I know the audio track is correct as VLC player correctly switches as appropriate. According to the makers of VideoRedo (which I use to re-edit my videos - if i remove those first few seconds of stereo, LAV correctly plays back the file as 5.1), "However any player that can play AC3 will ignore the container header and simply decode the frames based on the channel counts in their individual headers."

Does LAV do this, and if not, could it be changed so it does, thereby picking up the channel change when it occurs.

It's strange because it appears to be inconsistent. Sometimes it detects when the input audio changes, and output's it as 5.1, yet sometimes it only detects that the input audio has changes, but outputs it in stereo instead :/

OK i've got it. This assumes what i've said about the container header holding the number of channels in the first frame of the video is right:

LAV detects when the Input audio changes from 5.1 to 2.0 and vice versa correctly, no matter what the container header appears to be. However it outputs the audio in always the format that the container header is. So if the file starts with the audio in stereo, then it'll always output that no matter what the input audio currently is. However if the file starts with the audio in 5.1, then it'll always output it in 5.1, no matter whether the input audio is stereo or not. Is this the desired behaviour? Surely (if i'm not wanting LAV to up or downmix the audio or anything like that), it should be outputting in the same format that the input currently is, not what the container header is?

Obviously using the channels in the container header doesn't matter if the audio channels don't change, but when they do, that container header is incorrect from that point on.

[nevcairiel]

On-the-fly changes work just fine with AC3. The only reason it would downmix is if the audio renderer doesn't accept the new format, then it would try to convert to the previous format.
Note that the status tab doesn't update its info when its already visible, you would need to re-open it for the changes to become visible.

If you want further assistance, I suggest you cut a small sample that demonstrates what you think is the problem.

PS:
TS files (as recorded from TV) don't have a "container header" for its streams.

[zerowalker]

Use DXVA2-CB if you want trick mode playback (faster or slower playback).

But isn't that only GPU decoding then?
It doesn't use QS.

[bergqvistjl]

On-the-fly changes work just fine with AC3. The only reason it would downmix is if the audio renderer doesn't accept the new format, then it would try to convert to the previous format.
Note that the status tab doesn't update its info when its already visible, you would need to re-open it for the changes to become visible.

If you want further assistance, I suggest you cut a small sample that demonstrates what you think is the problem.

PS:
TS files (as recorded from TV) don't have a "container header" for its streams.
OK, well the RAW file in question (recorded using MythTV - lets assume no container header exists) starts off with the audio in 5.1 (end of previous program), and as you can see, the input format has been detected correctly, but the output format is in Stereo according to LAV:
http://i.imgur.com/Yc1A21j.jpg

After this, the input audio drops back to 2.0 again for the trailers:
http://i.imgur.com/iLqmfXQ.jpg

When the main program starts & switches to 5.1 again, this is what LAV picks up:
http://i.imgur.com/M1igvQD.jpg

Now, the audio switches from 2.0 to 5.1 a second or so after the main program begins. If I do a fast-frame copy using video redo, including that second or so where the audio is in Stereo I get the same results
as above, i.e. when the program switches to 5.1, the output remains in 2 channels (because the container header is set to 2.0 as thats what the file begins with - that doesnt' explain the raw file from above as that starts in 5.1, has no container header yet LAV outputs that in stereo too).

However if I do a fast-frame copy using videoredo chopping the video a bit more so that i begin with the audio starts when it's already switched to 5.1 (so VRD has set the container header to 5.1 then perhaps?), this is what i see throughout - LAV is now outputting in 5.1:
http://i.imgur.com/COS8uRu.jpg

[nevcairiel]

Obviously it manages to decode the audio properly and also notices that the input is 6 channel. Like I said in my previous post, the only reason it would ever downmix (short of you configuring it to in the Mixer settings) would be if the audio renderer refuses to accept the new format. LAVs entire design is based on the fact to try to deliver the audio as untouched and close to the original as possible, every time the input changes, it'll try to send it 1:1 to the audio renderer. If this one refuses the new format, it'll resort to trying to make it happy.

In short, check with your audio renderer, or supply a sample file. Repeated explanations, with or without screenshots, don't bring you any closer to any solutions I'm afraid.

[bergqvistjl]

Obviously it manages to decode the audio properly and also notices that the input is 6 channel. Like I said in my previous post, the only reason it would ever downmix (short of you configuring it to in the Mixer settings) would be if the audio renderer refuses to accept the new format. LAVs entire design is based on the fact to try to deliver the audio as untouched and close to the original as possible, every time the input changes, it'll try to send it 1:1 to the audio renderer. If this one refuses the new format, it'll resort to trying to make it happy.

In short, check with your audio renderer, or supply a sample file. Repeated explanations, with or without screenshots, don't bring you any closer to any solutions I'm afraid.I'll supply sample files tomorrow :) In the mean time, where would I find out what my audio renderer is? It seems like it's being inconsistent then, accepting some versions of the file yet refusing others

[nevcairiel]

In most cases its part of your player.

[bergqvistjl]

In most cases its part of your player.Well this is on Windows Media Player on Windows 8.1 x64, though i've disabled Media Foundation so I can use LAV. I thought LAV was the one decoding the audio though?

I'll link you 3 files tomorrow:
1. The raw file as captured by MythTV
2. The trimmed file of just the program in question (including the first few seconds in Stereo)
3. That same trimmed file, but trimming off those first few stereo seconds, so that it only contains the 5.1 portion.

2 & 3 trimmed using VideoRedo. My above problems occur when playing back files 1 and 2. 3 plays back fine but then the audio stays at the same number of channels throughout.

[nevcairiel]

Windows Media Player uses certain audio post processing components which are unfortunately incapable of reliably switching their input format, so for WMP there is no solution I'm afraid.

[bergqvistjl]

Windows Media Player uses certain audio post processing components which are unfortunately incapable of reliably switching their input format, so for WMP there is no solution I'm afraid.
So from what it seems like, is that WMP will accept a 5.1 audio track if that's what the file starts out as, but if you try to change the channels mid-stream, it won't accept the change and will continue to play the audio as though the number of channels was the same at the start?

I've just played the files through MPC-HC and the LAV audio status page is outputting the files correctly, on the fly, so that's that solved. Thanks :)

Seems like WMP adheres to the container flag if present - (then if not i guess defaults to stereo) to determine the channels it will accept for playback. Rather annoying...

[nevcairiel]

So from what it seems like, is that WMP will accept a 5.1 audio track if that's what the file starts out as, but if you try to change the channels mid-stream, it won't accept the change and will continue to play the audio as though the number of channels was the same at the start?

Pretty much, yes.
It'll generally always accept whichever format the file starts with, as thats what LAV will also present to it on creation of the video playback chain, but it cannot switch to another format on-the-fly unfortunately.

[bergqvistjl]

Pretty much, yes.
It'll generally always accept whichever format the file starts with, as thats what LAV will also present to it on creation of the video playback chain, but it cannot switch to another format on-the-fly unfortunately.Damn. Although that doesn't explain why it puts my raw ts file that starts with 5.1 audio down to stereo as well :/ But maybe thats because that file lacks the container header that VRD creates when I trim the files down (so it defaults to stereo), yet when there IS a container header, whether 5.1 or stereo, it follows that?

[Magik Mark]

Playing around with hevc file I recently downloaded. No problem with CPU decoding. I can't seem to activate the hardware acceleration. No problem with other file formats. I'm using the latest nightly version of lav v.48

Any thoughts?

[LigH]

To use hardware acceleration for decoding, both your hardware has to be capable of supporting this format, and your video has to be compatible (e.g. limited encoding complexity, maybe even resolution constraints). Apart from that, we can't give you much more help than you gave us details.

[Magik Mark]

To use hardware acceleration for decoding, both your hardware has to be capable of supporting this format, and your video has to be compatible (e.g. limited encoding complexity, maybe even resolution constraints). Apart from that, we can't give you much more help than you gave us details.

Thanks for the prompt reply LigH. I'm new to Hevc. I'm using Nvidia GTX 550ti. Not sure if this hardware supports this file format. Guess Not. Do you happen to know where I can get a list of supported hardware?

[LigH]

Hardware decoding support for HEVC is very rare. Consider only the most recent GPU models.

Are there any GPU's that support HEVC yet? (http://forum.doom9.org/showthread.php?t=170987) ... Nvidia Maxwell. Certainly not a 550, several years old.

[NikosD]

For Nvidia cards you need a Kepler or Maxwell 1/2 card, preferably with a lot of shaders.

For AMD cards, even 2009 ATI's cards can do the job (Radeon 5000 series and above) and you need again a lot of shaders.

For Intel iGPUs, you need latest Haswell CPUs (I' m not sure about Ivy)

[nevcairiel]

No current GPU supports HEVC. All the pseudo-support is done in drivers and drivers alone (by using the GPUs shaders).
Rumor is that maybe the upcoming NVIDIA GTX 960 may support HEVC completely, but we'll have to see.

[NikosD]

It's a very real support of GPUs, offloading a part of decoding load from CPU to GPU shaders, which is not so efficient like dedicated HW for that purpose in terms of speed and power consumption.

But it's 100% real support.

[nevcairiel]

OpenCL or shader usage is not "real support". Its just GPGPU, any GPU with enough processing power can do that, its just a driver feature - its entirely software! Its obvious because even the old Kepler cards can do that, or the even much older AMD cards, which clearly have no hardware for HEVC at all.
"Real support" is a dedicated hardware decoding ASIC for that codec.

This "hybrid" support is slow and inefficient. At 4K its barely usable because its too slow.

Its like saying my CPU has HEVC support because I have a decoder which runs on the CPU. :)

[NikosD]

You are making a big mistake here.

The whole concept of HW acceleration is to have another processor than CPU to accelerate a specific task.

So, by definition the GPU support of HEVC video acceleration is a real HW support assistance to CPU using a different processor - the GPU.

Of course the HW of a dedicated ASIC is much more efficient than GPU shaders.

About speed, you are definitely making another big mistake, If you see the results of Nvidia 770 using GPU shaders on 4K HEVC content at my signature link.

Looking at benchmark results, it's clear that 770 is faster than most CPUs available today!

[nevcairiel]

Eh, believe what you want, but the argument is not if its useful or faster or anything really, its just that the GPU does not actually support it, or even need to support it.
The GPU supports OpenCL and Shader Programming. The driver supports HEVC. The driver uses OpenCL and Shaders to decode HEVC.

There is a HUGE difference to this mode and actual proper hardware decoding with actual decoding hardware. Its a important and crucial difference to make, and if you consider it all the same then the mistake is yours.
The hybrid decoding can work on any hardware that is fast enough. Full hardware decoding requires actual decoding hardware. Its a drastic difference in functionality, and absolutely important to differentiate.

PS:
The fact remains that UHD/4K is unfortunately still too slow, even with GPU decoding. If its faster than most CPUs is irrelevant if its still too slow for fluid playback.
An average of ~30 fps on low bitrate clips is sadly not enough to call "fast enough".

Wasn't that even part of your "conclusion" in your own thread? That we need pure hardware decoders for 4K?

[NikosD]

GPU shaders are not pseudo hardware or hardware emulation.

GPU shaders are real hardware and any video decoding process executing there, it's called HW decoding (partial or full)

I'm the one who always used and asked for ASIC HW decoding, so I don't have anything else to add on this.

Just that we have 3 different types of decoding: SW, Hybrid (SW and HW) and HW decoding just like the name of my thread about the evaluation of HEVC decoders.

Nothing else to add.

P.S
Nvidia 770 without being the fastest card out there, reaches between 120fps to 190 fps on 4K HEVC clips on average.

[LigH]

If I understand the situation correctly: In contrast to HEVC decoding with software for highly parallelizable processors (not specifically made for the needs of a HEVC decoder, only for generic mathematical instructions), AVC decoding is done in a dedicated decoding processor (specifically made for decoding AVC and other video, e.g. the PureVideo decoder chip for Nvidia cards).

So AVC decoding is done like cutting a tree using one chainsaw (intended for this purpose), HEVC decoding is done like using hundreds of pocket knife saws (not intended but capable due to the huge number).

[NikosD]

The key questions for the subject are:

1) What is hybrid decoding ?

2) Is hybrid decoding a HW decoding ?

3) How could we call ASIC decoding ?

Replies:

1) Hybrid decoding can be called the partial HW decoding, meaning that you need SW (CPU) decoding for a part of the video decoding algorithm and HW (ASIC or GPU) decoding for the rest of the part of the algorithm.

Hybrid decoding can also be called every mixed SW(CPU) and HW(GPU) solution, not evolving ASIC.

But then how could we call ASIC based decoding ?

2) Whatever option you prefer of the previous reply, Hybrid decoding engages HW.
That's why you see the phrase 'Playing [H/W]' when DXVA HEVC is used by MPC-HC for GPU assisted HEVC decoding.

3) We call it HW decoding, but because hybrid decoding is HW decoding too, we could call it pure HW decoding.

That's all!

[NikosD]

I'm using Nvidia GTX 550ti. Not sure if this hardware supports this file format. Guess Not.?

There is no HEVC DXVA driver support for Fermi cards like yours, but if Nvidia decides to build a decent, real OpenCL driver, then you will have hybrid HEVC OpenCL acceleration using Lentoid or Cyberlink HEVC decoders.

Ask for a real OpenCL driver from Nvidia.

[nussman]

Hi,

I am a little bit confused about 10bit HEVC GPU decoding.
It works for 8bit HEVC but fails for 10bit (Nvidia GTX750i Ti, Driver 347.09).
Is this a driver, renderer (EVR/madVR) or decoder (LAV) issue?

[NikosD]

There is no 10bit HEVC hybrid decoder yet, only SW.

It should fall back to SW mode, decoded by CPU automatically.

[nussman]

That means: driver does simply not support 10bit (yet?)?
As nevcairiel already pointed out "HEVC hybrid decoder" ist just "software" on GPU.
So why no 10bit support?

[NikosD]

For the same reason that there is no DXVA HEVC support for AMD cards, no DXVA HEVC support for Nvidia Fermi cards or Ivybridge iGPU.

For Intel there is a table here which shows which iGPUs will get 10bit HEVC and VP9 partial acceleration.

https://communities.intel.com/thread/59216

So if we want to be more exact, some Broadwell iGPUs already have 10bit HEVC but LAV doesn't support it yet.

[NikosD]

That's VP9 - YouTube no longer makes the VP8 formats available other than for 360p (which on PC is a "plan C" behind VP9's "plan A" and h.264's "plan B", though it's used as "plan A" on low-performance embedded platforms like the Nintendo Wii).

You can see which format is being used via right-clicking on the video and then selecting "Stats for nerds".


I'm using latest Chrome under Win 8.1 and I'm trying to play Youtube videos in VP8 codec, but it seems impossible.

Even if I manually select 360p or even 240p, I always get VP9 codec.

Is there any setting inside Chrome or any preference in youtube.com service to "force" Youtube servers to send VP8 stream with Chrome or IE or any other browser ?

[Nintendo Maniac 64]

I'm using latest Chrome under Win 8.1 and I'm trying to play Youtube videos in VP8 codec, but it seems impossible.

Even if I manually select 360p or even 240p, I always get VP9 codec.

Is there any setting inside Chrome or any preference in youtube.com service to "force" Youtube servers to send VP8 stream with Chrome or IE or any other browser ?

There is no way to force YouTube to use VP8 because all versions of chrome have built-in h.264 support. You would need to use Chromium for that, and possibly on an OS without built-in h.264 support (such as XP). You would also need a video without VP9 encodes (most commonly found on videos that were uploaded less than 20 hours ago).

Honestly it's easier to just download the VP8 version via a YouTube downloader and play the WebM file directly in Chrome.

[ryrynz]

Nev could you hammer through the CueDuration and CueRelativePosition support?

[Telion]

Yeah, that would be much appreciated.

[Stereodude]

Rumor is that maybe the upcoming NVIDIA GTX 960 may support HEVC completely, but we'll have to see.
No longer a rumor. The 960 has full HEVC decoding.
On a feature note, while GM206 is officially classified as a Maxwell 2 part there is one small but very notable feature difference that needs to be pointed out, and we’ll get to in-depth in our full review. When it comes to HEVC (H.265) decoding, GM204, GM1xx, and GK1xx GPUs all offer limited HEVC decoding via a hybrid process that offloads some parts to the GPU fixed function units and shaders, and other parts to software entirely. However as of GM206 NVIDIA’s fixed function HEVC decoder has been completed and rolled into this GPU, making this the first discrete GPU with full HEVC decoding support.