LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

I hope you updated LAV in MC properly, in its plugins folder? Otherwise the version mismatch of its integrated plugin and any stand-alone installed versions can easily result in crashes.

What kind of video? Everything? Anything special?
The only changes between 0.53.2 and 0.54.1 are either DVD or DXVA related, nothing much else. Do you use DXVA?

[Weirdo]

I hope you updated LAV in MC properly, in its plugins folder? Otherwise the version mismatch of its integrated plugin and any stand-alone installed versions can easily result in crashes.
No, haven't touched that. I thought MC does not use it's own plugin folder in custom mode (where you manually select Directshow filters), only in RO mode. DVBViewer crashes too, though.

What kind of video? Everything? Anything special?
The only changes between 0.53.2 and 0.54.1 are either DVD or DXVA related, nothing much else. Do you use DXVA?
Only tried regular DVB-T SD H.264 channels, using DXVA copy-back/native. It'll almost always crash after a while. I'll keep using 0.53.2 and post back if it crashes, too.

[nevcairiel]

It plays fine, and then without doing anything it would suddenly crash?
In Live TV only, in MC18 too? Or also file playback?

[Weirdo]

It plays fine, and then without doing anything it would suddenly crash?
In Live TV only, in MC18 too? Or also file playback?
I've noticed it on live tv only, on both players. Yes, a sudden crash. I'll have to reinstall 0.54 for more info, 0.53 seems to work fine.

[mindbomb]

i have a question about intel and hardware acceleration:
which gpus support quicksync?
which support dxva?
and which support the clearvideo thing only?
And what decoders support that?

[DragonQ]

which gpus support quicksync?
Sandy Bridge (Core ix-2xxx or equivalent Celeron/Pentium) or newer.

which support dxva?
Any of them with an IGP, AFAIK.

[nevcairiel]

The first Intel with DXVA was the G35/G965 chipset, plenty old.
Anything before Sandy Bridge only supports Intels special "ClearVideo" mode (except possibly for MPEG-2). Sandy Bridge and above add support for standard H.264 DXVA, but not for VC-1 (VC-1 only runs through QuickSync)

[wanezhiling]

About ClearVideo and QuickSync, you could click the link:http://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units#Fifth_generation

Note1: All Clarkdale and above GPUs support QuickSync decoding, Celeron and Pentium just dont support QuickSync encoding.
Note2: Egur's QuickSync decoder blocked Clarkdale, so you need a SNB CPU @ least.




About DXVA, click the link above again.http://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units

Start from G33(third generation), MPEG2 has been fully supported, but no H.264 and VC-1.
Start from G45(fourth generation), H.264 and VC-1 are fully supported too, which is a "milestone" for Intel HD technology.
Note: Clarkdale/SNB/IVB(fifth/sixth/seventh generation) GPUs' VC-1 is a bit strange. Only CyberLink and ArcSoft have access to VC-1_VLD(full acceleration), other players/decoders stay VC-1_IDCT(partial acceleration).;)

[Warlock]

Guys, how dxva native has incompatibility problem with the xy-VSFilter? I did a test, every time I select the dxva native mode, I open any video, falls in software mode. The only format that works in dxva native when the xy-VSFilter is enabled, it is .MP4. I turned off the xy-VSFilter and activated the subtitle renderer of mpc-hc. After that, all videos began to be recognized by the dxva native mode, with the exception of 10-bit videos. How can I solve this problem between dxva native and xy-VSFilter?

[Keiyakusha]

Guys, how dxva native has incompatibility problem with the xy-VSFilter? I did a test, every time I select the dxva native mode, I open any video, falls in software mode. The only format that works in dxva native when the xy-VSFilter is enabled, it is .MP4. I turned off the xy-VSFilter and activated the subtitle renderer of mpc-hc. After that, all videos began to be recognized by the dxva native mode, with the exception of 10-bit videos. How can I solve this problem between dxva native and xy-VSFilter?

dxva native is not supposed to work if you use any additional filters, be it xy-vsfilter or anything else. if something tells you that it works, you likely misunderstood something or its just wrong. internal renderer and vsfilter is a different things, don't compare them.

[andybkma]

Win 7 64 bit, Zoom Player

nev, seemed to have stumbled upon a bug using LAV Splitter 54.1 where certain widescreen .mp4 or .m4v/avc vids don't display properly as they should (in widescreen format) but instead as a square fullscreen. Using a different mp4 splitter such as AVSplitter fixes the problem so can only assume the problem is with LAV Splitter. I went back four or five LAV versions to see if the problem persisted and it did so it seems this is not a new problem.

Sample link: http://filestay.com/p1ercgk44qcx/mp4_displays_in_fullscreen.m4v.html

[nevcairiel]

The file is working as intended, its just muxed wrong.
The MP4 file specifies a AR of 3:2, and the H264 stream an AR of 16:9. Which should be used for playback?

LAV Splitter will always output the 3:2 AR, because its a splitter, it reads the container values, not the stream values.
LAV Video (by default) trusts the AR from the Splitter in MP4 files, because most people do the muxing correct and the encoding wrong. The muxed value is also easier to fix then the encoded value in the video stream. There is an option to control how Stream AR is handled in the LAV Video options if you don't like it behaving correctly. :p

PS:
Please use better file hosts, that page is just horrible. Took about 5 minutes until the download started, and took like 40 minutes to download that 67mb file. Whats wrong with mediafire?

[wanezhiling]

How will Haali work in that condition?



There is an option to control how Stream AR is handled in the LAV Video options if you don't like it behaving correctly.
That option should be checked by default. I think 99% people want to watch 16:9 not 3:2/4:3

[Keiyakusha]

Never understood why container AR should take preference. The option to chose between them should be of course, as you not always can fix already broken files. But default should read stream info only. User should be forced to do one of the following: a) fix the existing stream b) reencode stream with correct settings c) temporarily change setting in LAV to read container ar d) temporarily redefine ar in player's playback settings
Plenty of options! And by using container AR they'll just never learn how to produce correct files. User should see that what they did is not correct. There is no way to make a warning in x264 or something as it have no idea what ar should be in which situation.
Personally I always use ar info only. BTW half-checked ar setting in LAV decoder fails with this file (http://dl.dropbox.com/u/110558786/Samples/LAV_AR_Test.mkv). But obviously works with reading ar from stream. There is no more correct way to produce this file, so why should broken files work and normal not?

[nevcairiel]

It doesn't "fail", you just produced a broken file, with conflicting information. In my experience (from users complaining and files i have seen), its far more common for the container AR to either: not be set at all (which is fine, and stream AR is used), or the container AR be set correctly, sometimes with a non-existant or broken stream AR, and the users expect it to be used for playback. Note that this only applies to MKV and MP4.

Using the container AR is perfectly valid, because not all video formats even have a stream AR.

If you think anything else is better, the option lets you configure it however you want.

That option should be checked by default. I think 99% people want to watch 16:9 not 3:2/4:3

For this sample, sure, i probably have a list of samples which only work properly with the current mode.
There have been plenty complains to other decoder authors for not adding an option to ignore stream AR, because they didn't want it to be used.

[sneaker_ger]

And by using container AR they'll just never learn how to produce correct files. User should see that what they did is not correct.

Then people will start producing files with wrong container AR. There is no right or wrong here.

BTW half-checked ar setting in LAV decoder fails with this file (http://dl.dropbox.com/u/110558786/Samples/LAV_AR_Test.mkv). But obviously works with reading ar from stream.

Yes, it does exactly what it is supposed to do. I think changing AR is not allowed in Matroska anyways. (Or was it changing resolution?)

[Keiyakusha]

It doesn't "fail", you just produced a broken file, with conflicting information.

Since when variable ar is broken? Any two valid appended h264 streams give us valid h264 stream. Stream not breaks mkv and will be spitted by any compliant splitter. Decoder is the one who fails here.

the container AR be set correctly, sometimes with a non-existant or broken stream AR, and the users expect it to be used for playback
I gave 4 options to deal with this case. There is no reason to hide an issue instead of making them fix it.

hen people will start producing files with wrong container AR. There is no right or wrong here.
I don't really understand why. Lets assume that now the do it right, why would they stop doing it?

Yes, it does exactly what it is supposed to do. I think changing AR is not allowed in Matroska anyways. (Or was it changing resolution?)
Resolution is constant, ar is different. It doesn't needs to be supported. ar info exists in stream, martoska ar perfectly fine to be used as fallback.

[nevcairiel]

It doesn't matter what you think is the correct way to produce files anyway. The defaults in LAV are choosen to be correct with as many files as possible, based on empirecal evidence based on user complaints and sample files i gathered over the years. A correctly encoded and muxed file would usually work, broken in any direction needs some kind of compromise.

[sneaker_ger]

I don't really understand why. Lets assume that now the do it right, why would they stop doing it?

Currently: LAV uses container AR by default and people make broken files without using the correct bitstream AR
Your solution: LAV uses bitstream AR by default and people will make files without using the correct container AR

Whatever LAV does, people will produce broken files.

And who is to define that bitstream AR takes preference over container AR anyways?

[Keiyakusha]

The defaults in LAV are choosen to be correct with as many files as possible
I see. Next step would be to add denoising, edge enchancing and various other things that makes files better than they are. Just like in every second crappy payware out there.

Your solution: LAV uses bitstream AR by default and people will make files without using the correct container AR
There is no way to produce incorrect container ar unless you explicitly set it incorrectly. These users just need to RTFM. On the other hand by not setting stream ar it produces incorrect result.

[nevcairiel]

There is also no way to set a wrong stream ar unless you explictly set a wrong one. I fail to see the point of the argument.

[wanezhiling]

For this sample, sure, i probably have a list of samples which only work properly with the current mode.
There have been plenty complains to other decoder authors for not adding an option to ignore stream AR, because they didn't want it to be used.
Adding an option for users is pretty nice, but what the default setting should be annoys me. Is LAV video decoder the first one to do that? :p

[Keiyakusha]

There is also no way to set a wrong stream ar unless you explictly set a wrong one. I fail to see the point of the argument.
What I mean is setting container ar is the step that you can't skip. It is mandatory element. But it is possible to skip setting stream ar, which is what often happens. In case of anamorphic encode not setting stream ar equals to setting it wrong. Edit: but this was just answer to sneaker_ger, it wasn't meant to support my previous posts about ar.

[sneaker_ger]

Adding an option for users is pretty nice, but what the default setting should be annoys me. Is LAV video decoder the first one to do that? :p

Not really. Haali's splitter would always use the container AR, too, for example. (It would even manipulate bitstream AR to match container AR in real-time)
Also, the option is already there. We are not talking about adding it.

[nevcairiel]

What I mean is setting container ar is the step that you can't skip.

Sure you can, container AR isn't really a mandatory element, in MKV at least, not sure about MP4, but i bet its not mandatory there either.

Anyway, this is all about what default option is selected. If you think its wrong, make your case with reasonable arguments that can be followed and understood, get some real world data to back it up, and i'll see about changing it.
I won't change it because one of you guys "thinks" it should be different, give me a good reason to break playback of files that started working when i set the default to this.

[sneaker_ger]

Sure you can, container AR isn't really a mandatory element, in MKV at least

If the elements don't exist, the Matroska specs will mandate that DisplayWidth=PixelWidth and DisplayHeight=PixelHeight (if DisplayUnit==0, which is its default value). So not setting them for anamorphic streams is a very bad idea, even though these elements might not be strictly speaking "mandatory".

[Keiyakusha]

Sure you can, container AR isn't really a mandatory element, in MKV at least, not sure about MP4, but i bet its not mandatory there either.

Anyway, this is all about what default option is selected. If you think its wrong, make your case with reasonable arguments that can be followed and understood, get some real world data to back it up, and i'll see about changing it.
I won't change it because one of you guys "thinks" it should be different, give me a good reason to break playback of files that started working when i set the default to this.

Hmm maybe I confused it with resolution that is not "display". But I think any software sets something, if it is not specified it makes is equal to resolution. Anyway the point was that if now user produces file with correct container ar, there is no much reason for him to stop doing so. This is offtopic really lets move on.

I'm not really asking to change the defaults, either way it doesn't really affects me. I just believe always the root of the problem should be fixed. As for arguments, I believe I made one. There is no reason the file I posted shouldn't work. It doesn't breaks mkv, any valid splitter will be ok with it. If mkv forbids that, it should always force ar to be removed from the stream.

[nevcairiel]

It doesn't breaks mkv, any valid splitter will be ok with it.

Haali will most likely not work with that, it always enforces the container AR, even modifies the bitstream to do so. I wonder if its still considered a "valid" splitter. :p

[sneaker_ger]

If mkv forbids that, it should always force ar to be removed from the stream.

Mkvmerge actually did just that for a long time, until people complained about files not working on their broken players.

[Keiyakusha]

Yes I know, but I think anything that haali does "on the fly" or what mkvmerge did is not really defined in mkv specification, isn't it? On the other hand thing about ar in h264 stream (well not only ar) is defined in h264 specs.
Also it is arguable that what haali does is not a bug. And to be honest right now common opinion is that haali is broken. Not because of AR though. ^__^

[Weirdo]

The 0.54.1 crash is probably a false alarm, after reinstalling it one more time, it's ok.

A question on the splitter: I'm trying to play .mov DVC-PRO HD files (sample (http://www.mediafire.com/?mc9h4k985y31lku)). With mpc-hc's internal MP4/MOV filter, I get both audio and video (LAV video reports: CDVH 960x720). I have the Raylight Decoder (http://dvfilm.com/raylight/decoder/index.htm) installed, which is probably why the video plays fine. When I enable the LAV Splitter (and source) there is no video. Is this unsupported?

[sneaker_ger]

Yes I know, but I think anything that haali does "on the fly" or what mkvmerge did is not really defined in mkv specification, isn't it?

Well, the mkv spec only defines how to read the format and it says that AR is to be derived from the DisplayWidth and DisplayHeight elements. Nothing more and nothing less. Of course it doesn't say anything about how this has to be implemented in e.g. DirectShow.

[DragonQ]

I don't have any data regarding whether stream ARs or container ARs are more often correct but surely container AR should be preferred, simply because it's so easy to change. Just remux with MKVMerge or TSMuxer, etc. Fixing stream ARs is a nightmare for most file types, meaning you usually need to re-encode, which is slow and results in a loss of quality. Also, I've seen incorrect stream AR in TV streams, so it's not like it's only amateur content creators that get this wrong.

In an ideal world, the container and stream AR would always match but this isn't always the case so container AR should be preferred by default. If you happen to have a lot of files with incorrect container ARs but correct stream ARs, and you don't want to spend time fixing them, then you can change the setting.

[06_taro]

Ideally a good encoder should set both stream ar and container ar correctly. If one doesn't do so, container ar is supposed to override stream ar, or else why is container ar needed? If one sample has correct stream ar but incorrect container ar, I think it is that particular sample which should be blamed, not a splitter or decoder which behaves reasonably, and even offers an option to let you choose another behaviour, although not by default.

btw stream ar is still editable without re-encoding by some tools with bitstream filter, like mp4box and roozhou's FFmpeg.

[dansrfe]

In what case would it be beneficial to use Intel QuickSync or DXVA2 to decode? I'm confused about when QuickSync should be used and when regular CPU decoding is used. Same thing for DXVA2 vs CUVID vs CPU decoding.

[nevcairiel]

Hardware decoders usually use less power, because they are running in fixed-function hardware and not in general-purpose hardware like the CPU.
Additionally, some slower/older CPUs may have issues with complex formats (especially VC-1 interlaced requires quite some CPU because the decoder isn't well optimized for multi-threading)

[dansrfe]

So if I have a GTX 670 and i7 3770K I should be using CUVID or QuickSync? DXVA2 is mainly for ATI users right?

[nevcairiel]

DXVA2 Native uses the least power, and if you don't need software post-processing like ffdshow raw or VSFilter, you can use it and benefit the most from it. If you use such post-processing, i would recommend either CUVID or DXVA2-CB, as thats most likely your active GPU, and QuickSync only works if the Intel GPU is active.

[egur]

@Nev
You can test for specific capabilities (fourcc, resolution, etc.) by calling the TestMediaType function on IQuickSync.

As for VC-1 DXVA2 support on Intel's iGPU by CyberLink and Arcsoft, they might also use the Intel Media SDK. I didn't check the players but at least one other product uses it.
I'll ask internally if there's a reason why this capability isn't enumerated properly.

[Carpo]

what would people suggest for someone who has a 560ti and a i7 2600 (getting a newer card is not an option) would it be the same as above - CUVID or DXVA2-CB ?

[fagoatse]

what would people suggest for someone who has a 560ti and a i7 2600 (getting a newer card is not an option) would it be the same as above - CUVID or DXVA2-CB ?

why bother with HW accel with such a rig?

[clsid]

To summarize some of my findings with testing DVD playback:

Problem 1: Messed up video if stride was guessed. Can be solved by using the calculated stride value.
Problem 2: Black screen with Overlay Mixer and interlaced video. Can be solved by never setting the interlaced flag in output mediatype when connected to Overlay Mixer. I don't think that Overlay is capable of doing interlacing anyway.
Problem 3: No DVD menu in WMP11 on XP. I have verified that CLAVVideoSubtitleInputPin::CheckMediaType is never called. So it seems the graph builder somehow doesn't like a dynamically created pin. Perhaps you can implement a workaround where LAV Video takes the initiative to connect the pin to the DVD Navigator? This should only be needed for the combo XP + wmplayer.exe/ehshell.exe.

[kasper93]

@nevcairiel
LAV Video Decoder crash on loop of the dvd menu with madVR. Can be reproduced if we hover on other button before the loop. Or just when madVR debug info is opened (crtl+j). Work fine with ffdshow...

Dump: http://dl.dropbox.com/u/16282309/LAV/dmp.7z
DVD menu: http://dl.dropbox.com/u/16282309/LAV/DVD.7z

[nevcairiel]

@nevcairiel
LAV Video Decoder crash on loop of the dvd menu with madVR. Can be reproduced if we hover on other button before the loop. Or just when madVR debug info is opened (crtl+j). Work fine with ffdshow...

Dump: http://dl.dropbox.com/u/16282309/LAV/dmp.7z
DVD menu: http://dl.dropbox.com/u/16282309/LAV/DVD.7z

I can't reproduce any crash, tried hovering over buttons, turning on madVRs debug OSD, all seems fine.
Its also a dump without heap info, those are only marginally useful.

[kasper93]

WOW, that is weird. This crash seems to be more random then I thought. Sometimes it works sometimes it doesn't :| I will try to gather more info and tell you if I get something solid.

[Pomegranate]

Hi!

I have a question about using LAV Audio + Kernel streaming via Reclock. I get heavy distortion with 32 bit floating point. So, I've unticked this option and LAV automatically does 32-bit FP to 24 bit integer, which is really nice. Do you recommend doing it this way, as opposed to outputting 32-bit FP to Reclock and letting Reclock do the conversion to 24 bit?

I also used eac3to to generate 32-bit integer and 64-bit integer wav files. The 32-bit integer file plays correctly via LAV audio + Reclock, meaning the sound card can decode 32-bit integer PCM. LAV audio reads the 64-bit integer as 32-bit FP, I'm not really sure what to make of that.

In any case, what do you recommend? Also, would there be any audible difference between 32-bit and 24-bit representations of a lossy encoded file?

[Anleck]

My problem (see post (http://forum.doom9.org/showthread.php?p=1603164#post1603164)) persists. I reinstalled with Windows 8 pro 6.2.9200 - all freashly downloaded drivers and software.

On a side note media performance is fantastic. Just need to kill this one little gremlin.

E7500 (2933Mhz) | ASRock P45XE | 4G Patriot PSD22G80026 800Mhz @ 800Mhz (6-6-6-18 CR2) / Dual Channel
EVGA GTS 450 (1G GDDR5) | Nvidia 310.64 x64 | DirectX 11.0 | WDDM 1.2
Windows 8 Pro x64 6.2.9200 ( HPET | AHCI )
MPC-BE 1.0.3.1 x64 | LAV filters 0.54.1 x64

[dansrfe]

Pomegranate,

I feed 32 bit floating point into ReClock which dithers it down to 24 bit integer and IMO it sounds the best. Do you get the distortion on all files or certain files only?

[Superb]

My problem (see post (http://forum.doom9.org/showthread.php?p=1603164#post1603164)) persists. I reinstalled with Windows 8 pro 6.2.9200 - all freashly downloaded drivers and software.

On a side note media performance is fantastic. Just need to kill this one little gremlin.

E7500 (2933Mhz) | ASRock P45XE | 4G Patriot PSD22G80026 800Mhz @ 800Mhz (6-6-6-18 CR2) / Dual Channel
EVGA GTS 450 (1G GDDR5) | Nvidia 310.64 x64 | DirectX 11.0 | WDDM 1.2
Windows 8 Pro x64 6.2.9200 ( HPET | AHCI )
MPC-BE 1.0.3.1 x64 | LAV filters 0.54.1 x64LAV Splitter is not a DVD Navigator.
LAV Video works together w/ the Microsoft DVD Navigator (comes w/ Windows 7; not sure about 8).

[Anleck]

Ok, thank-you Superb.


Swear when I checked the filter list on DVDs it was LAV all the way - I must be wrong.


A big thanks to Nev, LAV filters + HPET have made the biggest and best difference to my media experince.