LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

The QuickSync decoder is a third party component, not controlled by LAV.

Personally, I don't recommend using it at all, and have been thinking about removing it in the future, in favor of the DXVA2 decoders. The QS decoders has a few annoying bugs, and I don't want to try to fix yet another decoder which offers no tangible advantages.
Any features it currently has (like using D3D11 to use a iGPU without a screen connected) could be implemented in the DXVA2 decoders instead.

[NikosD]

OK I'll post my finding to Eric's thread.

It's still useful for VC-1/WMV3 decoding for Sandybridge (no DXVA decoder for Sandy)

Also, it's useful for transcoding apps like StaxRip and others which can use only Copy-Back or QS and no native mode.
QS is usually faster than Copy-Back.

Moreover, there are clips (a few) which are compatible with QS but not DXVA which falls back to SW to decode them (mainly VC-1/WMV3)

And finally QS decode supports HW deinterlacing.

For all these reasons, I think you should keep it in LAV.

[nevcairiel]

Absolute speed in benchmarking is not really a big important factor to me, since no real-world use-case would ever use that.
You will always do something with the video you decode, be it display it to the user, or encode it into another format - in which case that process will be slowing down everything so much that even the decoder running at half speed will still produce frames fast enough.

And since DXVA2 Direct Mode, the difference is minimal, DXVA2 is even faster in some cases now.

I already said that missing features could be implemented, as well.

In the end, its just me that decides, so I'll do what I think is best.
QS has a bunch of bugs, some from the driver, some from Erics code, and unfortunately "normal" people think they need to use it on Intel, so they run into those bugs and have no idea what to do, so they come and report them, and I have to tell them to simply not use it, again and again.

[NikosD]

About your last paragraph, I agree with you, a lot of people think that way.

But about transcoding speed, your thought is wrong.

Most of the times, a slow decoder leads to a slow transcoding process although the encoding speed is more important than decoding speed.

A half speed decoder will probably lead to an almost half transcoding speed.

Even minor decoding performance differences, like those between Copy-Back and QS, give different transcoding results.

QS is most of the times faster than copy-back and gives faster transcoding speed in real life, I'm not talking about benchmarks.

[Magik Mark]

Which will give us a smoother video:

1, Lav Cuvid Deinterlacing on and Nvidia Deinterlacing off
2. Lav Cuvid Deinterlacing on and Nvidia Deinterlacing on
3. Lav Cuvid Deinterlacing off and Nvidia Deinterlacing on

4. DXVA2 and Nvidia Deinterlacing on
5. DXVA2 Yadiff on and Nvidia Deinterlacing on
6. DXVA2 Yadiff on and Nvidia Deinterlacing off

How come Nvidia doesn't have the option for 24/25 & 50/60 frame interpolation?

[huhn]

Originally Posted by Magik Mark

Which will give us a smoother video:

1, Lav Cuvid Deinterlacing on and Nvidia Deinterlacing off
2. Lav Cuvid Deinterlacing on and Nvidia Deinterlacing on
3. Lav Cuvid Deinterlacing off and Nvidia Deinterlacing on

4. DXVA2 and Nvidia Deinterlacing on
5. DXVA2 Yadiff on and Nvidia Deinterlacing on
6. DXVA2 Yadiff on and Nvidia Deinterlacing off

How come Nvidia doesn't have the option for 24/25 & 50/60 frame interpolation?

lav CUVID uses the same deinterlacer as DXVA they are the same.
the DXVA version always uses 50/60 and this is not an interpolation it is simply needed for interlaced material.

i think nvidia deinterlacer is better than yadif but feel free to test it your self.

[huhn]

Originally Posted by NikosD

About your last paragraph, I agree with you, a lot of people think that way.

But about transcoding speed, your thought is wrong.

Most of the times, a slow decoder leads to a slow transcoding process although the encoding speed is more important than decoding speed.

A half speed decoder will probably lead to an almost half transcoding speed.

Even minor decoding performance differences, like those between Copy-Back and QS, give different transcoding results.

QS is most of the times faster than copy-back and gives faster transcoding speed in real life, I'm not talking about benchmarks.

most people care about quality and don't use an hardware encoder so no this is not the case. xvid, x264, x265 are the most used encoder by far.

[NikosD]

Originally Posted by huhn

most people care about quality and don't use an hardware encoder so no this is not the case. xvid, x264, x265 are the most used encoder by far.

Your answer is completely irrelevant with the subject we were talking about - which was HW decoding and not HW encoding.

I think is the 4th or 5th time that you answer at my posts, posting irrelevant replies.

Please PAY ATTENTION to what I write exactly, before you answer to me.

Thanks!

[huhn]

Originally Posted by NikosD

Your answer is completely irrelevant with the subject we were talking about - which was HW decoding and not HW encoding.

I think is the 4th or 5th time that you answer at my posts, posting irrelevant replies.

Please PAY ATTENTION to what I write exactly, before you answer to me.

Thanks!

only hardware encoder reach a speed where decoding speed shows a real difference. for a high quality x264 encode it is meaningless.

[LigH]

If you want to benchmark decoders, compare their scripts (without any filters, only pure *Source filter) with AVSmeter. Then compare their decoding frame rates with the encoder frame rate...

By the way, depending on the decoder chip generation, hardware decoders can be slower than multi-threaded CPU software decoders (e.g. Nvidia PureVideo V2 and V3 are quite annoyingly frame rate limited).

P.S.: This is a thread about the DirectShow versions of LAV Filters. Who would use DirectShowSource in a conversion, as long as there are native AviSynth source filters? Apparently I am just as wrong here; sorry.

[NikosD]

Have you tried to convert a VC-1/WMV3 clip with an Avisynth filter ?

And yes of course I have benchmarked decoders using AVSMeter another reason to say that copy-back is slower than QS (sometimes a lot slower, other times with a small difference)

[huhn]

i can easily open a vc-1 stream from a BD with ffmepsource2.

and yet again it doesn't really matter how fast avsmeter is as long as it is not slower as real world encoding.

@ligh

i agree dss is not a proper source.

[carlos.henrique]

Hello,

I´m using LAV Audio Decoder to process audio streams from brazilian DVB-T broadcasts and noticed something.

Some transmissions here have multiple audio streams. If I select a stereo audio stream, LAV Audio Decoder works fine, but if I select a 5.1 stream the resulting audio is not properly decoded. These happened in both 0.64.0 and 0.65.0 versions.

I have uploaded two files, one stereo and other 5.1, that were dumped directly from the audio streams being broadcasted:
http://www.fileconvoy.com/dfl.php?id...ade222e22f61ad

I have tried playing these files with ffplay and it works fine for both, identifying them as aac_latm streams. I then built a filtergraph for playing each file using LAV Splitter Source and LAV Audio Decoder and the same thing happened again: the stereo stream played fine, the 5.1 stream did not.

As a side note, when decoding from live broadcasts I wasn´t using LAV Splitter, only LAV Audio Decoder was involved on the chain.

I would be very grateful if someone could test these files and confirm my results, or else tell me what am I missing.

Thanks in advance guys.

[foxyshadis]

The only use case I can think of where realtime transcoding matters to normal people is AVC->ASP for old XBox streaming, or HEVC->AVC or VP9->AVC for newer consoles/TVs/etc. I doubt you'd get enough difference to go up a preset just from changing to faster decoding, especially if it involved using up some of the CPU resources.

[mindbomb]

I always thought the difference between the hardware decoders was that copyback was mainly limited to full bitstream decoding, and cuvid and quicksync could more easily do formats where only hybrid decoding was supported. But copyback does support hybrid hevc decoding, so I don't even know anymore.

[edcrfv94]

if have a Extra Audio *like flac mka , seek will very slow
Can it be fix?

[huhn]

Originally Posted by mindbomb

I always thought the difference between the hardware decoders was that copyback was mainly limited to full bitstream decoding, and cuvid and quicksync could more easily do formats where only hybrid decoding was supported. But copyback does support hybrid hevc decoding, so I don't even know anymore.

the difference is that CUVID and QS are always copyback no matter what. CUVID can do some more uninportant codecs like MPEG4 ASP but who needs a hardware MPEG4 ASP decoder?

CUVID and DXVA use the same decoder for HEVC/AVC/VC-1 making CUVID pretty much useless these days.

if i'm not mistaken QS can decode VC-1 and intel DXVA(ivy/sandy no clue about haswell) can't decode that.

older AMD GPUs have pretty bad DXVA decoder that can't decode UHD AVC. QS could be useful in these cases. but in general if hardware decoding is needed DXVA should deliver anything that is needed.

[romulous]

Found a clip where the audio does not work correctly on my 5.1 system:
http://videos.hd-trailers.net/Missio...1080p-HDTN.mp4 (174MB)

Audio for certain parts of the trailer is impossible to hear (using LAV 0.65, default configuration). AC3Filter is fine.

[nevcairiel]

Originally Posted by carlos.henrique

I have uploaded two files, one stereo and other 5.1, that were dumped directly from the audio streams being broadcasted:
http://www.fileconvoy.com/dfl.php?id...ade222e22f61ad

I have tried playing these files with ffplay and it works fine for both, identifying them as aac_latm streams. I then built a filtergraph for playing each file using LAV Splitter Source and LAV Audio Decoder and the same thing happened again: the stereo stream played fine, the 5.1 stream did not

Actually, ffplay and ffmpeg have the same problems - LAV is just more aggressive at maintaining audio/video sync, which causes audio glitching.
But the core problem is the same - the ffmpeg aac decoder fails to decode a few of the audio frames, which result in missing audio (which triggers LAVs A/V sync correction logic).

I recommend to report this directly to ffmpeg (http://ffmpeg.org/bugreports.html)

[nevcairiel]

Originally Posted by romulous

Found a clip where the audio does not work correctly on my 5.1 system:
http://videos.hd-trailers.net/Missio...1080p-HDTN.mp4 (174MB)

Audio for certain parts of the trailer is impossible to hear (using LAV 0.65, default configuration). AC3Filter is fine.

Seems to play just fine here.