LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Works perfectly for me. And the last two fixes are also impossible to influence anything there.

[NikosD]

I tried it many times to all 10 bit samples. Not even one worked in copy back.

Everything else (native, cuvid) is working fine for all clips.

Update:

Besides 740M, I tried latest nightly with a GT610.
Exactly the same behavior with 10 bit clips.

Fall back is working for DXVA native and CUVID, but not for DXVA copy-back (it's crashing during enumeration)

The only common of these different systems (Laptop w/740M and Desktop w/ GT610) is the Nvidia's driver version 344.11 and LAV filters.

[nevcairiel]

Still works just perfectly here, on two systems with NVIDIA. And like I mentioned before, the code just doesn't care if its run on NVIDIA or Intel, and the only changes made in that last version are impossible to cause issues like this. Noone else seemed to complain, either.

[NikosD]

OK.

For my systems, LAV 0.62.55 and LAV 0.62.57 have major differences specifically and only on 10 bit HEVC using Nvidia DXVA.

But maybe it's just me.

Don't expect though, a lot of people chasing latest nightly builds, checking compatibility issues with specific samples.

[NikosD]

Originally Posted by nevcairiel

I see no evidence that its 10-bit. But no, 10-bit doesn't really work.

I've just tried latest x64 version of PotPlayer using Intel's HEVC DXVA decoder and it can play fine most of my 10bit HEVC samples in HW.

Not all of them, because some they are just crashing the app.

The picture is not perfect, but how is even possible to decode 10 bit resolution in HW using HD 4600 ?

[nevcairiel]

Eh, the difference isn't that big, you can get away with most things by just throwing it at the same code, but anything thats not a perfect picture is absolutely not acceptable, and while a 8-bit decoder can potentially decode a partial picture of a 10-bit stream, its never going to be 100%. The decoder cannot even output a 10-bit picture, only 8-bit images, and as such its already impossible to get a 100% image out of it.

[cyberbeing]

Your latest nightly builds are no longer sending the subtitle styles from the correct segment on certain samples with mkv ordered chapters. This breakage appears to coincide with the recent FFMPEG library version jump, since the LAV 0.62.0 stable using the older libraries is unaffected.

[nevcairiel]

Fixed that just now.

[DragonQ]

Nev, is the source of your custom version of ffmpeg available anywhere? Most of the time when I see an interesting change in the LAV Filters tracker, it's just "update ffmpeg" so I can't see what actually has changed in the code.

[nevcairiel]

Its linked both in the readme or the first post of this thread.

[DragonQ]

Cheers.

[NikosD]

4K HEVC 8bit is crashing Intel's DXVA.

http://demo-uhd3d.com/files/uhd/Hisp...-2014_HEVC.zip

CPU plays fine.

Tell me if you want me to cut a small sample.

[cyberbeing]

Originally Posted by nevcairiel

Fixed that just now.

Thanks. I've now tested and confirmed your change yesterday fixed the issue. So it would seem that FFMPEG depreciating their internal AV_CODEC_ID_SSA format was the underlying cause.

[DragonQ]

Hmm, I found a weird issue today. I wanted to add an audio delay on my HTPC (I used to do this using my AVR but I need that set to no delay for other purposes) so I added a 280 ms delay in the LAV Audio settings. However, now I get a regular ~1 second pause in video every ~7.5 seconds (very regular) in MediaPortal (using EVR). It's entirely reproducible and once I turn off the delay everything's fine. What could cause this?

[Motenai Yoda]

Just me or there are some nasty artefacts with 62.0 and lossless x264 encodes?

[sneaker_ger]

Old x264 lossless encodes are not spec-compliant and the ffmpeg decoder is now following the spec more strictly. It's recommended to re-encode with a current x264 version. The next LAV version will restore the old behavior, though, simply because 99% of the lossless H.264 files out there were encoded using x264. New x264 encodes are compatible with every LAV version.

/edit:
Try this version (or a newer nightly):
http://forum.doom9.org/showpost.php?...ostcount=18024

[nevcairiel]

LAV Filters 0.63

LAV Splitter
- NEW: Support for playing AES encrypted HLS streams
- NEW: Advanced Subtitle selection allows selecting subtitles by a string match on the stream title
- NEW: Support for rtspu, rtspm, rtspt and rtsph URLs to force the RTSP transport protocol
- NEW: Animated GIF image support
- Fixed: Improved timestamp handling of badly muxed/corrupted H.264 streams
- Fixed: 4K ProRes streams in MKV didn't play reliably
- Fixed: Some HEVC streams in MKV/MP4 didn't play properly
- Fixed: VobSubs in MP4 didn't properly export their color palette
- Fixed: Streaming MP3s through the Microsoft URL filter could result in the last audio frame to be partially repeated
- Fixed: The duration of MP3 files would be wrong if it contained long IDv3 tags
- Fixed: TrueHD streams with an Dolby Atmos sub-stream were not demuxed properly

LAV Video
- NEW: Experimental support for CUVID and DXVA2 HEVC acceleration
- Faster: HEVC decoding is up to 100% faster
- Fixed: DVD subtitle rendering could crash in 64-bit builds

LAV Audio
- Fixed: TrueHD streams with an Dolby Atmos sub-stream did not decode

Download: Installer (both x86/x64) -- Zips: 32-bit & 64-bit

Its been a long time since the last release, which had a multitude of reasons which prevented me from working on LAV as much as I wanted, but I finally finished most of the things I did have planned for this version, so here it is!

Subtitle selection on string match

This feature was contributed to LAV, and it seems at least mildly useful. You can now select subtitle streams based on their title, however its limited to single words, as spaces are a separator for a new token.

Example Syntax:
eng@signs - Select any english subtitle tracks with "signs" in their title.

Note that string matches are case-sensitive, now that I'm writing this, it may make sense to change that to case-insensitive for the next version, maybe?

HEVC HW Acceleration

This version introduces experimental support for CUVID and DXVA2 HEVC HW acceleration on Intel Haswell and recent NVIDIA cards. On the current hardware, this is only a "Hybrid" acceleration, which means it uses the GPUs 3D shaders to perform calculations, and not dedicated decoding hardware like H.264 or MPEG-2 decoding would.

Only 4:2:0 8-bit is supported for now, we'll have to see if the GPU vendors support 10-bit properly at a later time. DXVA2 defines a specification for 10-bit, but its not supported by the GPU drivers (yet?).

Note that I still consider this feature highly experiemental, and it is disabled by default, but it seems to work quite decently nevertheless.

TrueHD Atmos

Really just a bugfix, but maybe still worth mentioning, TrueHD streams with an Atmos substream decode perfectly in this version. Its important to note that the Atmos data is just discarded and not decoded in any way, but the lossless TrueHD stream is decoded perfectly now, while before the Atmos extension screwed up decoding.

Anyway, have fun, and if you find any new issues, please do report them!

[Boltron]

Thank you.

[ryrynz]

Back into the swing of things, feels like a fairly quiet year in software development for AV related things compared to last year. Great release.

[Elbart_]

Originally Posted by nevcairiel

They look fine here, might be the video renderer causing the problem.
Note that non-mod2 height with 4:2:0 chroma subsampling is technically an invalid format.

When the WebM-reference-decoder is used within mpchc, there's no green line.

I'll do another test-run today.