LAV Filters - DirectShow Media Splitter and Decoders

[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]

Originally Posted by nevcairiel

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?

[Keiyakusha]

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

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]

Originally Posted by wanezhiling

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?

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]

Originally Posted by Keiyakusha

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]

Originally Posted by nevcairiel

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]

Originally Posted by nevcairiel

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]

Originally Posted by Keiyakusha

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.

[sneaker_ger]

Originally Posted by Keiyakusha

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). With mpc-hc's internal MP4/MOV filter, I get both audio and video (LAV video reports: CDVH 960x720). I have the Raylight Decoder 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]

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

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 ?