LAV Filters - DirectShow Media Splitter and Decoders

[sneaker_ger]

HD 6870 is UVD 3, not UVD/UVD+.
http://en.wikipedia.org/wiki/UVD#UVD_enabled_GPUs

[nevcairiel]

On HD 6870 such videos should work, if they don't work, you need to update your drivers. :)

[Snowknight26]

Nothing to update. I've been running the latest drivers for years as soon as they're released. Same issue exists with my friend's 7970 and another's 6870.

[sneaker_ger]

So, what does "much to my video card's dismay" mean? Too slow (< real-time) or artifacts? Because the decoding speed shouldn't really be noteworthy affected by the DPB size anyways - I don't know how fast UVD 3 is supposed to be. At least UVD 2.2 is too slow for 1080p60.

[Snowknight26]

It doesn't decode fast enough. By the end of the sample the decode rate drops to around 33fps. While it's playing the GUI of the player is essentially unresponsive.

Edit: Confirmed the issue on a 5850 as well.

[nevcairiel]

Oh yeah its not meant to check decode speed. On the UVD/UVD+ cards it wouldn't decode properly at all, only with artifacts, because the DPB is limited in size.

[Snowknight26]

Couldn't you simply not allow DXVA usage for anything that conforms to Level 4.2 or higher?

[sneaker_ger]

Then people will start complaining that their level 5.1 1080p24 movies with 16 ref frames stopped working with DXVA, although the cards do not have any problems with it.

[clsid]

If the problem is only with 60fps movies, then perhaps limit DXVA to 30fps max for ATI cards?

[nevcairiel]

The decoder doesn't particularly care what frame rate something is, it just decodes the frames as fast as it can, and since that frame rate information can be rather unreliable and hard to pinpoint exactly, i'm not going to add checks for that.
Too risky to get false-positives, and people complaining about that.

[kasper93]

http://stfcc.org/misc/H.264 1080p60 L5.0.mkv (http://stfcc.org/misc/H.264%201080p60%20L5.0.mkv)

Works fine on HD7700 both DXVA2n and DXVA2cb. With EVR-CP and madVR.

Make sure you have disabled all post processing filters in driver settings.

[Snowknight26]

Decoder Device Processor Device Time Frames FPS CPU GPU
H264_VLD_NoFGT ProgressiveDevice 14.036 1090 77.654 0 5
- ProgressiveDevice 2.554 1090 426.644 88 0
H264_VLD_NoFGT ProgressiveDevice 14.013 1090 77.779 0 4
- ProgressiveDevice 2.609 1090 417.66 85 0
- ProgressiveDevice 2.545 1090 428.245 89 0
H264_VLD_NoFGT ProgressiveDevice 13.878 1090 78.54 0 1
H264_VLD_NoFGT ProgressiveDevice 13.391 1090 78.239 0 1

Ironically enough DXVA Checker says the GPU should be able to play it smoothly with EVR using LAV Filters.

Edit: And now it plays fine with the same configuration as before. I'll just blame it on crappy AMD drivers/hardware/ULPS. Oh well, I don't care enough anymore.

[cyberbeing]

@nevcairiel

Is there anything you could do to make embedded MKV fonts appear in Windows' standard font dialog when loaded, similar to Haali Splitter?

This behavior seems a bit problematic for VSFilter's Style Editor, which uses the Windows' standard font dialog, in similar fashion to Notepad. The way LAV Splitter currently loads fonts into memory, causes them to be completely invisible to this dialog.

[nevcairiel]

The fonts are intentionally loaded private to the process and non-enumerable, so they don't mess with anything else.
However, JEEB wanted to check how Haali does its font loading exactly, because it also appears to somehow handle duplicate fonts (system+mkv) without screwing up some things.

[cyberbeing]

Oh well, I guess this Style Editor functionality may continue to be broken for users of LAV Splitter then, unless a sane workaround is found.

Do you have a recommended method to check if these privately loaded non-enumerable actually exist, since the entire point is we want to allow users to mess with them in the Style Editor for the currently loaded subtitle script?

[nevcairiel]

Since they can be used for actual subtitle rendering, i would assume if you request them by name it will also load them.

[mhourousha]

UVD3.0 for HD6XXX card,is not fast enough for 1080p60 H264 too.
the decode performance upgrade is so small compare to UVD2.2
UVD3.0 for HD7XXX,has 2x performance compare to it's predecessor roughly.

[cyberbeing]

Since they can be used for actual subtitle rendering, i would assume if you request them by name it will also load them.

The question is how could we check if these fonts actually exist, without actually loading them? Specifying the font name manually does not work with LAV Splitter from VSFilter's Windows standard font dialog. VSFilter doesn't actually load or handle fonts at all, it's all handled behind our backs by GDI and the Windows font sub-system. GDI unfortunately (fortunately?) has automatically fallback, which means there is no guarantee the the font requested is actually the font which ends up being loaded. Disabling the warning message is simple, but it would be nice to still to error out when a font really doesn't exist, and cannot be used.

Is there no way LAV Splitter could load fonts into the context of the media player's process, and make them enumerable for all active filters under that process?

[nevcairiel]

Is there no way LAV Splitter could load them into the the process of the media player, and make them enumerable for all active filters under that process?

Sure, but only if you save the font into an ugly temporary file first and then ask windows to load that, it cannot load differently from a memory image for some reason.

Like i said, there are also other issues if it tries to load a font from a MKV and you already have the same font in your system (and possibly the MKV font is a subset of the real font), and JEEB promised to look at Haali how it handles such, so maybe the whole font loading will be revised at some point.

[cyberbeing]

Why do you believe that Haali handles it in any special way?

As far as I can tell, it does nothing more than extract all fonts to your temp folder, calls AddFontResourceW (http://msdn.microsoft.com/en-us/library/windows/desktop/dd183326%28v=vs.85%29.aspx), on exit calls RemoveFontResourceW (http://msdn.microsoft.com/en-us/library/windows/desktop/dd162922%28v=vs.85%29.aspx), and then deletes all extracted fonts from the temp folder. Everything else is likely just default Windows behavior.

[nevcairiel]

Nothing related to actually loading the font, but some behavior would indicate that it does some special checks like if the font is already installed so it doesn't mess with system fonts, and before i would ever touch the code, i would like to know all the facts.

[kitame]

hey ya... question, is it possible to split the audio output to two outputs?
i mean, i have this situation where i have a stereo analog out and a digital 5.1 out, whenever i want to listen through my headphone i have to manually configure the settings to output as stereo and vice versa.
i know its just me being selfishly lazy but i'm taking my chances in asking anyway.

http://img96.imageshack.us/img96/7517/h1zh.jpg

[Soukyuu]

I'd be interested in multiple output (or a shortcut to switch audio outputs) as well, but I think that's more of a player-side thing than LAV-side.

[mindbomb]

the settings are stored in the registry. You can export the settings for headphones and then the settings for digital and then just run the .reg files to switch settings.

[blackjack12]

Nev ...

You might want to take a look when you have the time.

Not sure what is going on here.

http://forum.doom9.org/showpost.php?p=1636478&postcount=1377

UPDATE NOTE:
Solved - Need to uncheck Default track preference under playback tab in options with MPC-BE.

[LeChuck]

Hi Nevcairiel,

Maybe i found a bug in LAV Audio.

When playing the 2D Blu-ray Version of "Tron Legacy" the german audio track just goes silent at
01:23:28 and stays off until i seek to another position.

It happens with LAV Audio set to DTS Bitstreaming. Software-Decoding works fine with no audible artefacts.

It happens with v0.58.1 but also with older versions, e.g. v0.55.3

It does NOT happen using other audio decoders, e.g. ffdshow Audio rev.4477/4515 or MPC Audio Decoder 1.6.3/1.6.8, (each also set for DTS Bitstreaming)

System: Windows 7 x64 SP1
MPC-HC: all internal filters disabled, external filters LAV Splitter/Audio/Video preferred
LAV Audio: Bitstreaming for AC3, E-AC3 and DTS (not HD), any other settings on default
Audio: Creative Labs X-Fi -> TOSLINK -> Yamaha RX-V371

Here is a 30 sec sample file (Problem occuring on 00:08)
<http://sdrv.ms/11ta4p3>

I hope you can reproduce the problem.

[ryrynz]

It happens with LAV Audio set to DTS Bitstreaming.

There have been some DTS bitstreaming fixes made to the latest nightly builds. Grab the latest nightly build (http://roy.orz.hm/lavf-w32-nightlies/) from roytam and see if it fixes your issue. Just unzip the contents to your LAV installation directory.

[wanezhiling]

http://pan.baidu.com/share/link?shareid=3953506524&uk=3558042035
Hi nev, lav can't decode the 2 wavpack audios properly, mute.
ffdshow seems to work fine with default one(2ch), but doesn't work with second 6ch.

[LeChuck]

There have been some DTS bitstreaming fixes made to the latest nightly builds. Grab the latest nightly build (http://roy.orz.hm/lavf-w32-nightlies/) from roytam and see if it fixes your issue. Just unzip the contents to your LAV installation directory.

Thanks for the link.

I tried 'lavf-my130711-7324ccb.7z' but no change.

[nevcairiel]

http://pan.baidu.com/share/link?shareid=3953506524&uk=3558042035
Hi nev, lav can't decode the 2 wavpack audios properly, mute.
ffdshow seems to work fine with default one(2ch), but doesn't work with second 6ch.

Fixed the matroska wavpack demuxer, it should now work with recent libav/ffmpeg decoders again.

[wanezhiling]

:thanks: I will try later.

[NikosD]

At least UVD 2.2 is too slow for 1080p60.

Wrong.
UVD2.2 can play most of 60fps clips at a range of 55 to 57fps, like the one you posted.
I can play it in that range.

It doesn't decode fast enough. By the end of the sample the decode rate drops to around 33fps. While it's playing the GUI of the player is essentially unresponsive.

Edit: Confirmed the issue on a 5850 as well.

I can get that kind of low performance only if I use EVR Renderer instead of the EVR CP in PotPlayer.

Couldn't you simply not allow DXVA usage for anything that conforms to Level 4.2 or higher?

If the problem is only with 60fps movies, then perhaps limit DXVA to 30fps max for ATI cards?


@nevcairiel

Don't even think about it :eek:


EVR has better performance than EVR CP. And EVR CP has better performance than madVR. Or with other words: EVR has the best performance.

Just saying.



Completely wrong in case of UVD2.2 and PotPlayer.
UVD2.2 desperately needs EVR CP in PotPlayer in order to achieve max performance.
EVR is a kill.


Seems to play fine on NVIDIA GeForce GT 520 (GF119) / VP5 with MPC-HC 1.6.8.7417 + LAV 0.58.1 (DXVA2 native) + EVR.



For VP5 it's just the opposite.
VP5 needs pure EVR, not EVR CP.

[nevcairiel]

Wrong.
UVD2.2 can play most of 60fps clips at a range of 55 to 57fps, like the one you posted.
I can play it in that range.


If the clip is 60 fps and you can play it only at 55 to 57 fps, then it clearly is too slow.

[NikosD]

If you don't see the framerate counter, can you tell the difference between a "fast" system capable of 60fps and a "slow" one of only 57fps ?

[kitame]

the settings are stored in the registry. You can export the settings for headphones and then the settings for digital and then just run the .reg files to switch settings.

wait so theres no better work around?
i think its easier to change output on my soundcard settings, since LAV audio auto-adjusts to output settings then it should automatically downmix when set to two channels, and pass-through when set to six channels.

edit: on second thought just toggling the mixer on the 2nd tab sounds better.

[nevcairiel]

If you don't see the framerate counter, can you tell the difference between a "fast" system capable of 60fps and a "slow" one of only 57fps ?

If the decoder cannot keep up you'll get audio sync issues and frame drops, it is quite noticeable.

[NikosD]

There are no ifs here.
This is not the case.

Try any 60fps you want and tell me if you have issues with audio syncing or something.

The performance is very close to the target so it's impossible to have real problems.

[ryrynz]

The performance is very close to the target so it's impossible to have real problems.

For some losing frames and sync is a real issue, regardless of how minor it is. Leave it at that.

[NikosD]

Ok, so for the same people with those issues nevcairiel should not allow VP4 and all previous VPx generations (which means every Nvidia card before VP5 - Kepler) to use DXVA for every 1080p clip approaching 100Mbps bandwidth.

Because VP4 is too slow to keep up with large bandwidths, regardless frame rate.

VP4 is a slow decoder for those kind of clips even when the framerate is the lowest possible, 24 fps.

[detmek]

Decoder shoud not have any restrictions. If it can decode some video, fine. If it cann't, user should switch to software decoding or buy a better graphic card.

[NikosD]

You couldn't have said it better ;)

[clsid]

Nonsense. A decoder should not attempt to decode something if it knows beforehand it will fail. The problem in this specific case is that the decoder can't accurately predict if it will succeed or not.

@nev
Is it possible for the DXVA decoder to detect, during playback, that it is not fast enough for handling the current video stream, and fallback to software decoding (at a safe position, such as the next keyframe)? For CB no mediatype change should be needed right? Native would require a re-connect.

[NikosD]

And he has to do that for VP2, VP3 and VP4 for 1080p H.264 high bandwidth files.

But not all of them with the same criteria.

Because VP4 decodes faster than VP3 and VP3 faster than VP2.

Nonsense, I agree.

[nevcairiel]

@nev
Is it possible for the DXVA decoder to detect, during playback, that it is not fast enough for handling the current video stream, and fallback to software decoding (at a safe position, such as the next keyframe)? For CB no mediatype change should be needed right? Native would require a re-connect.

Nothing is completely impossible, but i simply will not do this, and neither would i accept a patch that does this.

[roytam1]

@nev:

$ git pull && git submodule update
Fetching submodule ffmpeg
From git://git.1f0.de/lavfsplitter
7324ccb..dca6fea master -> origin/master
From git://git.1f0.de/ffmpeg
75738ea..59f3711 master -> origin/master
Updating 7324ccb..dca6fea
Fast-forward
ffmpeg | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
fatal: reference is not a tree: 371c3fb61df18b7b5301a5f329f7f37a417fd612
Unable to checkout '371c3fb61df18b7b5301a5f329f7f37a417fd612' in submodule path 'ffmpeg'

[dansrfe]

Just wanted to report that the playlist "no audio" problem I was having with MPC-HC/LAV is no longer happening. I think it got fixed somewhere in the last couple of MPC-HC nightlys I installed.

[owlsroost]

It does what it says, it improves the detection of 100% progressive streams to ensure deinterlacing is turned off.
Previously it would rely on the media type information for this, but when watching Live TV for example, there typically is no such information available, and it could deinterlace some progressive broadcasts which didn't need it - and even cause some issues when double-rate deinterlacing a stream which already was 59.94 progressive (as i'm told some ATSC broadcasts in the US are)

Re. the changes to 'Aggressive Deinterlacing' in 0.58 - here in the UK we have H.264 HDTV channels that use a dynamic field/frame encoding scheme, so the stream changes very frequently between field and frame encoding (every few seconds or less sometimes).

With versions up to 0.57, setting 'Aggressive Deinterlacing' meant that as soon as it saw any interlaced (field based) content LAV video switched to assuming the stream was interlaced (and stayed that way). This was great, since (with a 50 Hz display) the EVR Mixer produced a constant 50 FPS output stream - otherwise the constant switching between 25 FPS and 50 FPS causes dropped frames at the switch points sometimes (downstream in MediaPortal).

With the 0.58 changes, 'Aggressive Deinterlacing' seems to behave the same as 'Auto' with these HDTV streams i.e. the EVR Mixer output 'tracks' the stream encoding changes.

Is it possible to have the old mode back (or an additional 'Super Aggressive' mode perhaps) ?

Thanks,

Tony

[nevcairiel]

Is it possible to have the old mode back (or an additional 'Super Aggressive' mode perhaps) ?


No, the old mode caused issues with other broadcasts, where the broadcast itself is at least behaving properly (ie. a one-time switch from interlaced to progressive), and i'm not breaking a proper broadcast to fix some terrible broadcast. A new mode is also not an option, too many options just cause confusion.

Personally, i've not seen a broadcast which really switches between a full progressive stream to a potentially interlaced stream all the time.
What is common is a stream marked as interlaced which then contains progressive frames - thats what aggressive deinterlacing was originally designed for.

You should probably talk to the media portal devs to look at their renderer so the frame drops can be avoided.
As an alternative you can of course use "Force" deinterlacing mode.

Or you could provide a recorded sample, maybe there is just some mis-detection going on.

In any case, the option is not meant to work-around any generic playback issues you might encounter, its supposed to ensure a frame gets deinterlaced when it needs to, if your frames are actually progressive and you don't get interlacing artifacts, then its not supposed to be on.

[owlsroost]

You should probably talk to the media portal devs to look at their renderer so the frame drops can be avoided.

That's me ;) - and I have tried to work around it (a lot).

As an alternative you can of course use "Force" deinterlacing mode.

Is it possible to do this programmatically (other than changing registry keys before LAV Video decoder is loaded each time) ?

I'll try and capture a small sample file.

(This is the BBC R&D dept background info about the encoding scheme - http://www.bbc.co.uk/blogs/researchanddevelopment/2011/04/software-upgrade-for-bbc-hd-on.shtml )

Note: I'm not suggesting LAV is handling the stream incorrectly - it actually handles it much better than most other decode filters - it's just that the old 'Aggressive Deinterlace' behaviour was a nice workaround to avoid the side effects :)

Thanks,

Tony

[nevcairiel]

From the description of the BBC it sounds like LAV is doing what its supposed to do. They deliver content as natively progressive whenever possible, and LAV handles it as such, to keep as much quality as possible. :)
I can probably tweak the aggressive mode so that it doesn't require a media-type reconnect on such switches, maybe that'll help already to avoid your frame drops. Instead, the frames will simply stop being flagged as interlaced.