LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Well, converting the dts decoder output to floats, at a level were its not clipped yet, would be rather annoying considering the way the decoder is currently hooked into ffmpeg. Not sure I want to hack up all the things for some theoretical problem that may have been isolated to one disc. There is no clear evidence this is a common problem. Other discs may have hard clipping baked into their waveform and there is nothing to recover, so...

[Manni]

Originally Posted by nevcairiel

LAV Filters 0.67

LAV Splitter
- NEW: Support for HTTPS URLs
- NEW: Automatic selection of the highest quality variant in HLS streams
- Changed: Reverted back to the old ASF demuxer
- Changed: Backported ASF seeking improvements to the old ASF demuxer
- Fixed: ASS in AVI did not work in recent versions
- Fixed: RTP/RTSP did not work properly in 0.66

LAV Video
- NEW: Improved DVD subtitle and menu drawing with madVR (support for madVRs subtitle repositioning and lower latency)
- Changed: HEVC and 4K HWAccel is enabled by default
- Changed: Enabled DXVA2-CB Direct Mode with YV12 output on 8-bit sources
- Fixed: DVD menus could show a black screen instead of the menu in some situations

LAV Audio
- Fixed: Improved clipping behavior in badly mastered DTS-HD tracks

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

I'm going on vacation soon and wanted to release this before, so that I can focus on a bunch of new things after getting back.
This release contains mostly maintenance, and a few new features like HTTPS support, which was asked for a couple times.

Otherwise new is support for drawing DVD menus and subtitles directly through madVR, which lowers the latency of interactive menus, and allows madVRs subtitle moving logic to be used.
A recent version of madVR is required, 0.89.10 or newer.

For the next version after this one, I have a few changes planned for hardware acceleration, mostly involving a new settings UI for them and a bit more flexibility like allowing fallback to DXVA2-CB if Native doesn't work.
On top of that, I have been working on VP9 DXVA2 support, and it will also be part of the next release, but its not quite done yet. VP8 is also in the pipeline, but I need a Intel drivers first that support VP8 DXVA2, which should appear sometime in the future.

As always, if you encounter a problem, especially if its a regression, please report the problem in as great detail as possible, with a test-case to reproduce it if applicable, so it can be fixed more easily.

Have fun and take care!

Thanks for the new release, and have a great holiday.

[Hockey Man]

Hi nevcairiel

These segment linked files are having problems with LAV Filters 0.67.
https://www.sendspace.com/file/s07fim
https://www.sendspace.com/file/1ons84

To reproduce the problem, seek from the Intro -> Opening -> Part A. madVR won’t fill queues, and the audio and video end up going out of sync.

Sorry, I don’t know if this is actually a LAV Filters or madVR problem, but I thought I’d report it here since LAV Filters 0.66 is still working alright though.

[nevcairiel]

Originally Posted by Hockey Man

Hi nevcairiel

These segment linked files are having problems with LAV Filters 0.67.
https://www.sendspace.com/file/s07fim
https://www.sendspace.com/file/1ons84

To reproduce the problem, seek from the Intro -> Opening -> Part A. madVR won’t fill queues, and the audio and video end up going out of sync.

Seems generally fine here. Maybe its a performance thing?

I see one thing that isn't quite right, but shouldn't cause sync issues, unless performance is at its max. Will try to fix that part, maybe it helps.

Edit:
I resolved the issue I noticed, which should lead to much lower performance requirements again (it was needlessly converting everything, because the segments are in a different format)

[romulous]

Originally Posted by nevcairiel

LAV Filters 0.67
LAV Splitter
- Changed: Reverted back to the old ASF demuxer
- Changed: Backported ASF seeking improvements to the old ASF demuxer

Hi nev,

Just to confirm my understanding of this is correct. In 0.66.0, you changed over to the new demuxer (in an attempt to fix the known LAV issue of slow WMV seeking). In 0.66.0-33, you reverted back to the old demuxer after some complaints about the new one. Sometime between 0.66.0-33 and 0.67.0, you added the seeking improvements from the new demuxer into the old demuxer (which is the demuxer that LAV uses now)?

In short, the WMV seeking has been improved without the stability issues of the new demuxer? I did check the commits log, and there is nothing there that looks like the changes were backported from the new demuxer to the old one, which is why I ask (unless it was in the 'updated ffmpeg' commit, the changes being done on the ffmpeg side).

romulous

[nevcairiel]

Hopefully, yes.
The seeking index in asf files is rather weird, and the proper solution would be to inspect every seeking offset and find the timestamp that goes with it, however that would be rather slow as the code would have to seek to every index and read a couple packets, so not ideal.

[hubblec4]

Hi nevcairiel

I have today updated LAV to 0.67, MadVR to 0.89.17 and MPC-HC to 1.70.14(nightly).

Then I tested the Aliens DVD and it plays fine, the menu always visible and the vob-buttons useble
BUT
the whole video(and menu) show a 4:3 format (normal 16:9).

What or which updated component has this new issue?

[nevcairiel]

Originally Posted by hubblec4

What or which updated component has this new issue?

Likely madVR, madshi did a lot of things to DVD aspect ratio stuff which I don't quite understand why.
You can always confirm by switching to EVR temporarily, if AR is correct there, you know where to go!

[hubblec4]

Originally Posted by nevcairiel

Likely madVR, madshi did a lot of things to DVD aspect ratio stuff which I don't quite understand why.
You can always confirm by switching to EVR temporarily, if AR is correct there, you know where to go!

You are right, with EVR it plays with 16:9 format.
I will post it in madVR thread.

[chros]

Originally Posted by superb

please don't. Some of us appreciate your hard work and are happy you share these status updates.

+1

Originally Posted by manni

thanks for the new release, and have a great holiday.

+1

[KoD]

Hi nevcariel,

I have an issue that seems to be triggered by enabling the "Adaptive HW deinterlacing" in the QuickSync decoder, when the video output is done through a discrete graphics card and not directly by the iGPU. I was first under the impression that it was a madVR issue, and have been reporting this in the madVR thread here and here, but after many tests, including using Windows Media Player with the external LAV filters, I am convinced the issue is on the decoder side, and not in the player or the renderer.

Would it be possible to have a look, maybe it's something easy to fix. The sample file (35Mb) is a straight remux to mkv of the first minute of the first episode of a Start Trek Voyager PAL DVD (25i).

The CPU is an Intel 4790K, OS in Win 8.1, the Intel Graphics driver is the latest available for Haswell for Win 8.1 (10.18.14.4294 from the package that Intel advertises on its download website as 15.36.26.4294). The newer Intel Graphics driver package on their website has drivers for Haswell only for Windows 10!

[nevcairiel]

QuickSync is an external component, please report all problems to the author. I do not maintain the related code myself, and do not plan to take over that part either.
The best course of action is to let the renderer perform the deinterlacing, its more efficient and less error prone.

http://sourceforge.net/projects/qsdecoder/
http://forum.doom9.org/showthread.php?t=162442

Unfortunately, the author seems to have lost interest, which may lead to removing the QS decoder from LAV eventually, as its been collecting issues for a while already.
I generally do not recommend using it at all, anymore.

[KoD]

Ok, will try to contact the author.

madshi says he can not retrieve the data from a DXVA video surface without some kind of damage to the chroma information, which is what happens when DXVA deinterlacing is performed by madVR. Using any elaborate scaling algorithms after that does not make much sense. That's why I am interested in making deinterlacing by QS work, because it seems to be the only way to get good quality deinterlacing and color info that is not damaged. So please, don't remove it yet!

[nevcairiel]

Interlaced content already starts out damaged, sorry.

[nussman]

But interlaced content is still very commen for dvb sources.

What about using gpu deinterlacing with dxva copyback (in LAV before copyback) to avoid these issues? Would this be possible?

[nevcairiel]

Its one of the options that I'm exploring, but still needs some figuring out if it would work properly.

[huhn]

madVR could copyback by it self.

[Overdrive80]

Hi, if someone can answer me I will thank.

Is posible get a result like in below snapshot with lavfilters instead of haali? I am refering that mpc can shows embeded tags of matroska. (Sorry for my english)



Thanks.

[nevcairiel]

Such details should be mostly available today. If you have a file with more tags than LAV exports, please share a sample, and I'll see what data I can find.

[sneaker_ger]

No 0.67 nightly on server?