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]

Originally Posted by 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.

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.

Originally Posted by nevcairiel

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]

Originally Posted by nevcairiel

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]

Originally Posted by mindbomb

which gpus support quicksync?

Sandy Bridge (Core ix-2xxx or equivalent Celeron/Pentium) or newer.

Originally Posted by mindbomb

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/Compari...fth_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/Compari...ocessing_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]

Originally Posted by 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?

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.

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?

Originally Posted by nevcairiel

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. 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.

Originally Posted by wanezhiling

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]

Originally Posted by Keiyakusha

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.

Originally Posted by Keiyakusha

BTW half-checked ar setting in LAV decoder fails with this file. 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]

Originally Posted by nevcairiel

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.

Originally Posted by nevcairiel

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.

Originally Posted by sneaker_ger

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?

Originally Posted by sneaker_ger

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]

Originally Posted by Keiyakusha

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]

Originally Posted by nevcairiel

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.

Originally Posted by sneaker_ger

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.