LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Make sure you don't use MPC-HCs MPEG-TS source filter, it doesn't output VC-1 with the correct timestamps, and the WMV9 decoder has no workaround for that yet.
With LAV or Haali for MPEG-TS splitting it should be fine.

Works fine for me, at least.

[jmonier]

Make sure you don't use MPC-HCs MPEG-TS source filter, it doesn't output VC-1 with the correct timestamps, and the WMV9 decoder has no workaround for that yet.
With LAV or Haali for MPEG-TS splitting it should be fine.

Works fine for me, at least.

In all cases, I'm using the LAV Splitter and ZoomPlayer. It happens with both TS and MKV. I get the same results on two different machines.

Have you actually looked at the dropped frame count (in madVR)? The clip by itself doesn't look too bad, although you can see jerky motion if you look closely.

[nevcairiel]

Have you actually looked at the dropped frame count (in madVR)? The clip by itself doesn't look too bad, although you can see jerky motion if you look closely.

Zero dropped frames here.

Are you sure some refresh rate switcher isnt taking you to 30Hz instead of 60?

[Midzuki]

...
A big plus is that AviSynth also supports YV24, while AYUV is not supported.

You mean Avisynth 2.6, which still is "alphaware" :) alright.

[aufkrawall]

I guess (nev mentioned this before) the reason for the waiting has to do with the bug concerning YV24 in all MadVR version except the more recent one.
MadVR showed showed the U and V reversed (U was V and V was U).
This means that if people didn't update their Madvr yet for whatever reason, would get completely wrong colors.

Thanks for the explanation.


Mind you that EVR won't work at all with Y24, because it simply doesn't support this format.
Currently, only MadVR supports YV24.
A big plus is that AviSynth also supports YV24, while AYUV is not supported.
EVR supports AYUV but not YV24?
For me it doesn't work great with AYUV, picture is a little too dark (doesn't happen with madVR).
I thought changing to YV24 would fix this. :(

[Plutotype]

Hi Nev,

I have reported this issue in the past, but seeking in a VC-1 video when WMV9 DMO decodeer causes the lipsync issue. FFmpeg VC-1 is fine in this regard. Nothing crucial, but worth to mention.
Thanks

Pluto

[Pat357]

http://www.mediafire.com/?xr7ynkl2fg59g1c <- this is crazy it's a nvcuvenc h.264 transcode of the same mpeg-2 bitstream that brings the dxva2 native mpeg-2 down :P and it crashes also coincidence maybe though way to strange for one or this stream not important in which form triggers a bug in the MPC-HC render core but only with your DXVA2 Native ;)
Interesting information, and especially much and detailed !
What do you mean by a " nvcuvenc h.264 transcode" ?
Did you use the LAV cuvid decoder to decode and x264 to re-encode ?
You talk about "nvcuvenc" : is this a separate application from Nvidia ?
I thought the CUVID API can only decode, because there is no hardware in NVidia cards to encode, only to decode video.

However, I believe I saw something similar a long time ago from Neuron2 : there was even a source called nvcuvenc IIRC, but I never got it working.

[Pat357]

You mean Avisynth 2.6, which still is "alphaware" :) alright.
Alphaware doesn't mean to much in this context : I use the sET v2.6 MT build (13.09.2011) and never got any problem with it.
It seems to be very stable for me....
Look at MPC-HC, FFDshow, Madvr, PotP, ... : we all like to use the latest versions for the added features, but it's basically also still in "alpha-stage" !
The latest "official" FFDshow is from 2007 IIRC, are you still using this ? :rolleyes:
What version of LAV are you using ? version 1.0 ?:p

[Midzuki]

What version of LAV are you using ? version 1.0 ?:p

0.49.
As for Avisynth itself, I keep using version 2.5.8 --- but probably it's the time to go thru the "upgrade" :rolleyes:

OK, you are right this time :stupid:

[Pat357]

Make sure you don't use MPC-HCs MPEG-TS source filter, it doesn't output VC-1 with the correct timestamps, and the WMV9 decoder has no workaround for that yet.
With LAV or Haali for MPEG-TS splitting it should be fine.

Nev,
Is this also for WMV 1-2 or 3 ?
Does the code to decode VC1 also work for WMV3 ?
The reason I ask is when WMV3 can be fully accelerated (DXVA output) is it using the same VC-1 decoder on the graphic card
or is there next to H264,MPEG2,VC1 and MP4-ASP another piece of hardware that does the WMV3 acceleration to DXVA ?
One should think, if it is possible with the same HW, it should be possible with the same software... no?

This has always puzzled me..

[nevcairiel]

EVR supports AYUV but not YV24?
For me it doesn't work great with AYUV, picture is a little too dark (doesn't happen with madVR).
I thought changing to YV24 would fix this. :(

Thats the whole point. EVRs AYUV support is terribly broken, which is why i want to turn AYUV off by default, but i needed a replacement for 4:4:4 first. I implemented YV24 already, but its not activated yet.

EVR doesn't support anything but AYUV for 4:4:4, so instead it'll then get RGB, which is much better for EVR anyway, and madVR will receive YV24.

Does the code to decode VC1 also work for WMV3 ?
The reason I ask is when WMV3 can be fully accelerated (DXVA output) is it using the same VC-1 decoder on the graphic card


The new decoder works for both VC-1 and WMV3. Its essentially the same codec. WMV3 is Simple and Main Profile, and VC-1 adds a new "Advanced Profile", but otherwise its the same codec.
Same goes for DXVA.

WMV1/2 are completely different and not supported by hardware, or the new decoder.

PS:
I don't think i've seen WMV3 in MPEG-TS, so the post you quoted doesn't apply anyway.

[madshi]

Maybe you could use a 10bit 4:4:4 FOURCC for the time being, instead of AYUV?

[nevcairiel]

Maybe you could use a 10bit 4:4:4 FOURCC for the time being, instead of AYUV?

I could, but i never liked the idea of converting 8 to 10 bit.
I also would need to write such a function first, because i don't trust swscale (which is the fallback for all conversions that i didn't implement manually)

I'll just enable YV24 in one of the upcoming builds, and make people either turn it off or upgrade madVR if they complain. ;)

[madshi]

Yes, that's fine with me.

[e-t172]

Is there a way to check what output audio bit depths my audio card supports? I'm very sure it's 16-bit but I'm not 100% sure.

On Windows 7, you can see the list of supported audio formats in the properties of the audio output, "Advanced" tab.

Also, If I'm using ffdshow audio processor just to downmix the audio and LAV Audio for decoding, is it better to have LAV Audio send a 32-bit float stream to ffdshow audio processer and have ffdshow dither the bit depth to 16-bit or just deselect everything but 16-bit depth in LAV Audio and have ffdshow not touch the bit depth?

If you're processing the audio stream (in your case downmixing), then it's better to keep the audio in 32-bit float until the very last step. It very probably won't make a audible difference, but at least you'd be on the safe side.

[hoboX10]

Hey, I have a problem with the LAV video decoder, other people may have this too.

If I enable NVIDIA CUVID Hardware Acceleration with the latest drivers (version 295.73) then any H264 playback will cause a Blue Screen upon loading the decoder.

I should say that this is with NVIDIA's Verde drivers (Mobile Graphics Drivers) and may not be an issue with their standard graphics drivers.

Thanks for reading.

[jmonier]

Zero dropped frames here.

Are you sure some refresh rate switcher isnt taking you to 30Hz instead of 60?

I'm not using any sort of refresh rate changer. I can see no indication that the refresh rate is changing and the display always says 60.

Remember that this clip works fine (no dropped frames) when the wmv9 decoder AND yadif is used in ffdshow. It's only in LAV Video that the same combination gives a problem.

Just to be absolutely sure that we're on the same page: You do have yadif on, don't you? It only has the dropped frames when yadif is used.

This clip is from a blu-ray that is a real test of vc1 interlaced. I find that it needs a really fast cpu to run smoothly with the wmv9 decoder. It's not the only one that is like that, but there are certainly others that don't have nearly the problems. I do have a i7-2600, though, and have never seen any problems with it and this blu-ray except with LAV Video with yadif enabled. I also don't see any indication that the cpu is maxed out when the problem occurs.

EDIT (ADDED):

I've tried several different settings in madVR (including no, no, no, fw(s)) with no change. Basically the madVR queues are always almost empty indicating that LAV Video is not able to keep up.

MORE INFO:

If I check "Treat as progressive", there are no dropped frames, but I can see (if I look carefully) that the picture is NOT de-interlaced. That certainly seems to point to something that is happening in your yadif implementation.

[BetaBoy]

CoreAVC DXVA, Lav Video DXVA and Potplayer DXVA fail with these x264 streams (same visual problem mostly gray blocking on specific frames, ref frames related, the more surprising would be that Arcsoft and Cyberlink found a way to compensate it without losing DXVA, or they use quicksync natively and Intels Driver MSDK fixes it) Cyberlink DXVA and Arcsofts DXVA implementation handle them on Intel without problems and fully accelerated :)


We are looking into it... thank you for sure a great report!

[nevcairiel]

I also don't see any indication that the cpu is maxed out when the problem occurs.


Neither the decoder nor YADIF are multithreaded, so maxed out would mean that one core is maxed out, which really isn't easy to see.

Can you benchmark it with GraphStudio, and see what you get?
Without YADIF, i get 61 fps on that clip, with YADIF in 50/60p mode around 70. I can see how there isn't a big margin.

Before anyone asks, YADIF doesn't make it faster, during the deinterlacing process the frames get doubled.

I can probably move YADIF processing into a worker thread somehow so that decoding can already resume while YADIF is working, or try to multi-thread YADIF itself (or both).

[DragonQ]

I assumed that YADIF processing was on a separate thread to the decoding anyway?

[nevcairiel]

I assumed that YADIF processing was on a separate thread to the decoding anyway?

You assumed wrong.
That isn't really all that trivial, because the decoder likes to re-use the same data buffer, so it need to wait until YADIF is done.

Changing that so that i can feed the decoder with its own buffer is kinda tricky.

[nevcairiel]

Try this version, it adds multi-threading support to YADIF itself, in a rather simple way using OpenMP.

http://files.1f0.de/lavf/LAVFilters-0.49-yadifmt.zip

Performance went from 70 to 90 fps for me.
If i can move processing into a worker thread, it can probably make the yadif process nearly transparent.

[jmonier]

Try this version, it adds multi-threading support to YADIF itself, in a rather simple way using OpenMP.

http://files.1f0.de/lavf/LAVFilters-0.49-yadifmt.zip

Performance went from 70 to 90 fps for me.
If i can move processing into a worker thread, it can probably make the yadif process nearly transparent.

This version makes things better but not good enough. It starts out with no dropped frames and the queues are filling up better but never fill up totally (as they do normally). After a few seconds, the dropped frames start to appear and continue to increase.

I can't help thinking that there's something here that's using more cpu than it should (especially since ffdshow works fine with the same components).

I haven't used GraphStudio before so I'll try to get setup and check with that as soon as I can.

[nevcairiel]

You aren't using RGB32 output in combination with YADIF, are you?

I have a 2600k myself, and it plays just fine. But it gets slow when i use RGB output.

PS:
GraphStudio doesn't need much setup, just run the tool and select "View -> Decoder Performance" in the menu. Make sure renderer is null renderer, select file and LAV Video as decoder, and go.

[DragonQ]

If you are using RGB32, definitely try turning that off cos it was certainly much slower in a few tests I did with LAV a while ago.

[jmonier]

I got GraphStudio running. All output formats were checked but I unchecked RGB32 and RGB24 just to be safe and there was no difference.

With the NEW build I get 45 fps without YADIF and 66 fps with. I have no idea why mine should be so much slower than yours although mine is the non-K version. I remember something about the K version allowing access to the on-chip video, but I don't know what difference that would make and I could be mistaken anyway. In any case, I have the P67 chipset so I wouldn't have access to on-chip video. At least we know what the difference is between your's and mine even if we don't know why it should be.

CORRECTION: These numbers are on my i7-950 test machine. I still don't think that it should be that much slower, however. Later this afternoon (evening for you?), I'll get numbers off the i7-2600 machine.

[nevcairiel]

For the record, i just benchmarked ffdshow on that VC-1 sample with wmv9 and YADIF, and i only get 63 fps (90 fps for LAV).

Maybe you don't have "Double Framerate" checked in ffdshows YADIF? (its off by default)
If thats the case, you can set LAV to 25/30p to get the same effect. It'll need only half the processing power that way.

I'm now working on moving YADIF onto a worker thread to see what happens. Will be a while though, Inter-Thread-Communication is always a headache.

PS:
Its already evening. :)

[jmonier]

"Double Framerate" in ffdshow WAS off, however I set it on and everything still worked OK even on my i7-950. It benchmarked at 45 fps either way, so apparently "Double Framerate" is not working (or is done at no cost somehow?). It's fairly recent (3964 Jan 3 2012), what version are you using?

I checked decoding on my i7-2600 and it was 53 fps with YADIF off and 60 with YADIF on using 0.49. It went up to 80 using 0.49-yadifmt. It works perfectly with that build - no dropped frames and queues full (or almost) at all times.

I think that we're on the same page now. It looks like your 2600K is about 10% faster than my 2600 (and that made all the difference). Maybe it's overclocked?

For anyone reading this, I should emphasize that, in my experience, many vc1 interlaced files will work fine even with the original 0.49 build, but others won't. I don't know how to tell in advance which is which, however. It is very dependent on cpu speed. The Microsoft wmv decoder (even outside LAV Video) will have trouble with some vc1 interlaced files with all but the fastest cpu's.

[Pat357]

I've tried several different settings in madVR (including no, no, no, fw(s)) with no change. Basically the madVR queues are always almost empty indicating that LAV Video is not able to keep up.

I just checked your clip and, yes, I do see what you see.

LAV CUVID + HW interlacing : plays smooth
LAV (WMO) + Madvr (deinterlacing) : smooth
LAV (WMO) + yadif :
the first half of the clip, I see no dropped frames.
However, I see the decoder queue going down. Normally it stays at 15-16 (complete filled).
The second half of the clip, I notice a very low decoder queue (6 and lower) and at 80% of the clip, it starts dropping frames.

My first thought was it 's because both the WMO decoder and LAV-yadif are not multi-threaded.
Without yadif, the WMO decoder tops on 105 fps on my system, so that would mean that yadif is taken *a lot* resources.

The ffdshow implementation of Yadif is however MT IIRC, that's probably the reason why it runs smoother with the DMO decoder.

To make it simple for now, just disable yadif and let Madvr or EVR do the de-interlacing : it's faster and will give a superior result compared to yadif.

Nev : is making yadif multi-threaded still on your to do list ?

[dead_screem]

Is it just me or is the "Use Stream Aspect Ratio" option in LAV Video broke? Even with it checked, it always uses the container AR. I would think with that option checked it should be ignoring the container AR (passed from the splitter), right?

[Pat357]

I think that we're on the same page now. It looks like your 2600K is about 10% faster than my 2600 (and that made all the difference). Maybe it's overclocked?

For anyone reading this, I should emphasize that, in my experience, many vc1 interlaced files will work fine even with the original 0.49 build, but others won't. I don't know how to tell in advance which is which, however. It is very dependent on cpu speed. The Microsoft wmv decoder (even outside LAV Video) will have trouble with some vc1 interlaced files with all but the fastest cpu's.
That's why it's nice to have HW accelerated video using your GPU.

Tested with GraphstudioNext :
CUVID + HW interlacing 50/60 : 138 fps
DXVA-CB (no deinterlacing) : 69 fps
DXVA-CB + yadif MT (LAV) : 137 fps

It seems that yadif MT on my system can keep up with 69 fps coming in from VP and outputting 2*69 = 138 fps.
In this combination there is no noticeable slowdown because of yadif mt anymore.
It seems in general if the HW-modes can handle the stream, they don't suffer from performance degradation with certain VC-1 files like the WMO does.

[jmonier]

I just checked your clip and, yes, I do see what you see.

My first thought was it 's because both the WMO decoder and LAV-yadif are not multi-threaded.
Without yadif, the WMO decoder tops on 105 fps on my system, so that would mean that yadif is taken *a lot* resources.

The ffdshow implementation of Yadif is however MT IIRC, that's probably the reason why it runs smoother with the DMO decoder.

To make it simple for now, just disable yadif and let Madvr or EVR do the de-interlacing : it's faster and will give a superior result compared to yadif.

Nev : is making yadif multi-threaded still on your to do list ?

A lot of what you say has been covered in posts subsequent to the one of mine that you replied to.

I'm fully aware of the value of the madVR de-interlacer. I use Zoomplayer and in order to use subtitles I need the de-interlacing done prior to the renderer so it's not an option for general use right now. I do use the wmv decoder directly to the madVR de-interlacer for vc1 right now since there is very little vc1 interlaced material and thus the subtitle problem is not a big one. I'd rather use LAV Video for everything, however, so that's why I was trying this solution.

[Pat357]

Is it just me or is the "Use Stream Aspect Ratio" option in LAV Video broke? Even with it checked, it always uses the container AR. I would think with that option checked it should be ignoring the container AR (passed from the splitter), right?
If the stream has an aspect ratio, it should take this one.
Even when that option is checked and the stream has no aspect ratio, then it has no choice then take the one from the container.

[jmonier]

That's why it's nice to have HW accelerated video using your GPU.


It's fine if Nvidia works for you. For reasons unrelated to video decoding, it doesn't work for me. DXVA on ATI/AMD is not as clean so I prefer software decoding.

[Pat357]

A lot of what you say has been covered in posts subsequent to the one of mine that you replied to.

I'm fully aware of the value of the madVR de-interlacer. I use Zoomplayer and in order to use subtitles I need the de-interlacing done prior to the renderer so it's not an option for general use right now. I do use the wmv decoder directly to the madVR de-interlacer for vc1 right now since there is very little vc1 interlaced material and thus the subtitle problem is not a big one. I'd rather use LAV Video for everything, however, so that's why I was trying this solution.
Is dxva-cb + yadiff or cuvid with HW deinterlacing not an option ?
Ah.. you must have a GPU with slow copy back : ATI ?
On Nvidia, you would have the above very fast options.

Edit : you were a tad faster then me :D

[magic144]

@dead_screem - I think it very much depends on the player and the settings therein...

which player are you using
I had to take the time to learn what all the settings in ZP did recently, and how they interacted with LAV re: AR.

[dead_screem]

@dead_screem - I think it very much depends on the player and the settings therein...

which player are you using
I had to take the time to learn what all the settings in ZP did recently, and how they interacted with LAV re: AR.

MPC-HC.

And player shouldnt matter, at all.

for instance a file can have two different aspect ratios stored, one in the container and the one in the video stream. If a file has for instance 16:9 aspect in the container and 4:3 in the video stream. LAV Splitter will pass the 16:9 aspect from the container to the video decoder, but LAV Video just passes on the 16:9 container aspect to the Renderer instead of ignoring it and passing 4:3 what was in the video stream to the renderer. I tested with MPEG-2 and H.264/MPEG-4 AVC.

Ofcourse LAV would have no way to determine which aspect in the file is correct, thats what I thouht this option was for. But it doesn't appear to do anything.

[magic144]

@dead_screem
hmm, I had the opposite experience with ZP...
I wanted to remux an h.264 stream so as to set a container AR to override the stream's AR (which had been wrongly encoded)
if I unchecked the LAV setting it would work, and if I checked it, it would further depend on some ZP-specific interpretation options...

on the other hand, I tried the newly remuxed file in MPC-HC and it just used the container's AR - using the built-in decoder

EDIT - just tried MPC-HC with LAV Video on my test clip - it seems to behave as you would want - i.e. if I check the LAV setting, the video is rendered at the stream AR, but if I uncheck it, it uses the container AR...

MPC-HC 1.6.0.4014, LAV 0.49, EVR...

[dead_screem]

EDIT - just tried MPC-HC with LAV Video on my test clip - it seems to behave as you would want - i.e. if I check the LAV setting, the video is rendered at the stream AR, but if I uncheck it, it uses the container AR...

MPC-HC 1.6.0.4014, LAV 0.49, EVR...

What format of video is your test clip? small enough to put online somewhere so I can test?

[magic144]

This is it (it's only 3MB):-
http://www.mediafire.com/download.php?yje5lzz1wqkqvun

the vid stream is 1024*720, but needs to be displayed at 16:9 AR...
(I set the container display options to 1280*720)

[Midzuki]

Hmmm, maybe LAV Video should just use the same technique as the DivX H264 Decoder 8.2.0.26 ---

--- instead of a checkbox, a drop-down list. :p

[dead_screem]

Aha. The option DOES appear to work but LAV is using the "wrong" stream aspect.

the video stream info from media info from your file

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 10s 0ms
Bit rate : 2 075 Kbps
Nominal bit rate : 2 200 Kbps
Width : 1 024 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 1.422
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.113
Stream size : 2.47 MiB (90%)
Writing library : x264 core 107 r1745 4785e8e
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=2200 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Notice it has "Display aspect ratio" and "Original display aspect ratio" LAV Video is using the "Original display aspect ratio" from the stream instead of "Display aspect ratio" like it should.

My files (MPEG-2 and H.264) don't have a "Original display aspect ratio" field. but just a normal "Display aspect ratio" field only, so LAV Video must be thinking my files have no AR in the stream. And just fyi, 1 file I have is 720x480 with 16:9 aspect in the MPEG container but 2.35:1 "Display aspect ratio" in the MPEG-2 stream. I have another H.264 which has something weird as the aspect in the TS container like 15:11 but 4:3 as the "Display aspect ratio" in the stream. neither have a "Original display aspect ratio" field in the stream.

the "Original display aspect ratio" field in my limited experience, I almost never see set. And the few times I have seen it, its always been set to 1:1 like it is here. and the real aspect is at "Display aspect ratio"

[magic144]

Well, I'm no expert, I'll have to leave it to nev (or some other informed personage) to comment further.
:)

[nevcairiel]

Notice it has "Display aspect ratio" and "Original display aspect ratio" LAV Video is using the "Original display aspect ratio" from the stream instead of "Display aspect ratio" like it should.

My files (MPEG-2 and H.264) don't have a "Original display aspect ratio" field. but just a normal "Display aspect ratio" field only, so LAV Video must be thinking my files have no AR in the stream. And just fyi, 1 file I have is 720x480 with 16:9 aspect in the MPEG container but 2.35:1 "Display aspect ratio" in the MPEG-2 stream. I have another H.264 which has something weird as the aspect in the TS container like 15:11 but 4:3 as the "Display aspect ratio" in the stream. neither have a "Original display aspect ratio" field in the stream.

the "Original display aspect ratio" field in my limited experience, I almost never see set. And the few times I have seen it, its always been set to 1:1 like it is here. and the real aspect is at "Display aspect ratio"

Blame MediaInfo for confusing display of information.
If both fields are listed by MediaInfo, then "Display Aspect Ratio" is the Container AR, and "Original display aspect ratio" is the Bitstream AR. LAV Video does the right thing to use the Original display aspect ratio if you have Stream AR enabled. The Bitstream only ever contains one value, not two (or maybe zero)

If only one field is listed, your bet is as good as mine which field MediaInfo read there.
For the record, MPEG containers (ts/mpg) do NOT have a container AR, so any AR you see there is from the stream itself.

LAV Video does (mostly) the right thing. There is one known small glitch with the CUVID decoder when there is no stream AR at all, it assumes the resolution matches the AR. If you have a sample that has the correct AR with software decoding but wrong with CUVID, then give me a sample so i can fix it.

In my experience, Stream AR is only useful with MPEG TS files, for MKV or other containers with their own AR fields, alot of people neglect writing the proper AR into the Bitstream fields.
I've been pondering adding an option to LAV Splitter to overwrite the Bitstream AR with the Container AR for such formats (like Haali does), for one to help decoders that have no option to turn Bitstream AR off, and additionally to avoid having to flip that switch all the time.

[dead_screem]

Blame MediaInfo for confusing display of information.
If both fields are listed by MediaInfo, then "Display Aspect Ratio" is the Container AR, and "Original display aspect ratio" is the Bitstream AR. LAV Video does the right thing to use the Original display aspect ratio if you have Stream AR enabled. The Bitstream only ever contains one value, not two (or maybe zero)

If only one field is listed, your bet is as good as mine which field MediaInfo read there.
For the record, MPEG containers (ts/mpg) do NOT have a container AR, so any AR you see there is from the stream itself.

LAV Video does (mostly) the right thing. There is one known small glitch with the CUVID decoder when there is no stream AR at all, it assumes the resolution matches the AR. If you have a sample that has the correct AR with software decoding but wrong with CUVID, then give me a sample so i can fix it.

In my experience, Stream AR is only useful with MPEG TS files, for MKV or other containers with their own AR fields, alot of people neglect writing the proper AR into the Bitstream fields.
I've been pondering adding an option to LAV Splitter to overwrite the Bitstream AR with the Container AR for such formats (like Haali does), for one to help decoders that have no option to turn Bitstream AR off, and additionally to avoid having to flip that switch all the time.

http://www.4shared.com/video/NLQL0ENA/HALCALI.html
here is a MPEG-2 file, container AR is 16:9 (which is correct) stream AR is 2.35:1, which is wrong in this example but LAV Video never uses it no matter if the option is checked or unchecked. I can't seem to find any of my MPEG-2 files where the stream is right and container is wrong(I know I have some, but I have lots and lots, too many to sort through) I also can't find a H.264 TS that had this problem except the one I mentioned previously, which is a sample someone posted to this thread already, so you should already have it "538000Mhz.ts", container AR is 15:11 and stream AR is 4:3 and 4:3 never gets used by LAV, either with AR option checked or unchecked. I can reup that ts if you dont have it anymore.

[nevcairiel]

http://www.4shared.com/video/NLQL0ENA/HALCALI.html
here is a MPEG-2 file, container AR is 16:9 (which is correct) stream AR is 2.35:1, which is wrong in this example but LAV Video never uses it no matter if the option is checked or unchecked. I can't seem to find any of my MPEG-2 files where the stream is right and container is wrong(I know I have some, but I have lots and lots, too many to sort through) I also can't find a H.264 TS that had this problem except the one I mentioned previously, which is a sample someone posted to this thread already, so you should already have it "538000Mhz.ts", container AR is 15:11 and stream AR is 4:3 and 4:3 never gets used by LAV, either with AR option checked or unchecked. I can reup that ts if you dont have it anymore.

TS and MPG files do NOT have a Container AR. Its just not possible, they have no header to encode such things into.
I don't know how MediaInfo determines that value, but its clearly invalid. Don't trust MediaInfo unconditionally. The AR of that file is 16:9, and its clearly stated like that in the MPEG-2 Headers (the video stream headers, not the container)

[dead_screem]

TS and MPG files do NOT have a Container AR. Its just not possible, they have no header to encode such things into.

my mistake then. by all means educate me. the mpg i posted is 720x480 and correct aspect should be 16:9, which LAV splitter gets right. And turning the aspect ratio on/off and its always 16:9. Media info says the stream AR is 2.35:1.

MPC-HC's own decoder (libmpeg2) has a Use stream AR option, with it off it gets 16:9 (passed from the splitter, LAV and MPC-HC own TS splitter is the same) but with it on it gets 2.35:1 like what media info says. But LAV Video still gets 16:9 from stream AR. what is going on then?

edit
http://www.4shared.com/file/1RSRE8i1/538000Mhz.html
I cant find any of my h264 ts that had problems, but whatever. here is the other file I mentioned, LAV says 15:11 but mediainfo says 4:3... 4:3 is what it should be... but of course 15:11 (1.36) and 4:3 (1.33) are close enough that pepole wouldnt notice.

[nevcairiel]

MPEG-2 video is a bit special because its header information has the information in some odd ways, and ffmpeg has quite a few workarounds to rather match real-world files instead of strict specs. Its possible that libmpeg2 just strictly follows the spec and therefor ends up with a wrong AR.
Unless you can find a file that actually shows wrong behavior, there isn't anything to do for me.

Note that this depends on which codec is used, so H264 and MPEG-2 might be completely different beasts.

Edit:
The second file specifiys a aspect ratio index of "2", which according to the H264 spec is a SAR of 12:11*, which translates to a PAR of 15:11 on your videos resolution. Working as intended.
Like i said, don't take MediaInfo as an authoritative source for everything. It may be interpreting or mis-representing data.

* This particular AR seems to be meant for 4:3 PAL signals with horizontal overscan, at least according to the spec, which would explain why its being stretched to a slightly bit wider then 4:3

[BetaBoy]

CoreAVC DXVA, Lav Video DXVA and Potplayer DXVA fail with these x264 streams (same visual problem mostly gray blocking on specific frames, ref frames related, the more surprising would be that Arcsoft and Cyberlink found a way to compensate it without losing DXVA, or they use quicksync natively and Intels Driver MSDK fixes it) Cyberlink DXVA and Arcsofts DXVA implementation handle them on Intel without problems and fully accelerated :)

All of them Playback without issues with Cyberlinks and Arcsofts DXVA Decoder as well as Quicksync

http://www.mediafire.com/?scdzhe8e1gaxygh (gray blocking whole frames)
http://www.mediafire.com/?ucq118nxpnc4of7 (colored blocking part of frame then whole frames)
http://www.mediafire.com/?ykd7185z7j9db21 (practically every frame)
http://www.mediafire.com/?rld8gnlh52f03ud <- is a different decoding issue not ref frame related (Quicksync and Lav Video DXVA problem) plays flawless with Potplayer DXVA and CoreAVC DXVA
http://www.mediafire.com/?xr7ynkl2fg59g1c <- this is crazy it's a nvcuvenc h.264 transcode of the same mpeg-2 bitstream that brings the dxva2 native mpeg-2 down :P and it crashes also coincidence maybe though way to strange for one or this stream not important in which form triggers a bug in the MPC-HC render core but only with your DXVA2 Native ;)
http://www.mediafire.com/?sdqa98x8ig6msng <- fails with a green screen though arcsoft (black screen) and cyberlink (only decodes half of the stream) also have problems coreavc dxva plays it potplayer crashes in ntdll :P quicksync works
http://www.mediafire.com/?bji8i63j93skh2a <- sharing these Decoding problems on Blu-Ray Encodes with CoreAVC and Potplayers DXVA (Arcsoft and Cyberlink work)
http://www.mediafire.com/?wtku126e9k13z61 <- another blu-ray test in native m2ts same issue as above in .mkv

resolution, version and settings of different x264 streams showing the same decoding problem with DXVA decoding on both decoder

1280x720

x264 core 88 r1471 1144615

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=10 / psy=0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / wpredb=1 / wpredp=2 / keyint=350 / keyint_min=15 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=2pass / mbtree=1 / bitrate=10000 / ratetol=10.0 / qcomp=0.00 / qpmin=6 / qpmax=51 / qpstep=6 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00



1280x720

x264 core 98 r1629 2e81ce1


cabac=1 / ref=9 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=esa / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=16 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=abr / mbtree=1 / bitrate=15000 / ratetol=2.0 / qcomp=0.60 / qpmin=10 / qpmax=40 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


720x352

x264 core 104 r1713M c276662

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=23.3 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


1280x720

x264 core 112 r1834+3 ef18685

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / fade_compensate=0.30 / psy_rd=0.40:0.10 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / fgo=5 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60


1280x720

x264 core 114 r1913+431 3ad9c33

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.80 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / fgo=5 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=72 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.72 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.80


640x480

x264 core 115 r1947 b5a8ad7

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=tesa / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

640x480

x264 core 115 r2008 4c552d8

cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.80:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=12 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=2:0.40





comparable ref frame sei settings but no decoding issues (most probably decision wasn't as aggressive, working inefficient @ that time)

640x480

x264 core 50 svn-557M

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=6 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / chroma_qp_offset=0 / slices=2 / nr=0 / decimate=1 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=0 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=1885 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30


720x360

x264 core 57 svn-712M

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=esa / subme=7 / brdo=1 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=0 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=2000 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.3:0.0

1280x720

x264 core 61 r920M 8c8acae

cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=tesa / subme=7 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=300 / keyint_min=25 / scenecut=40(pre) / rc=crf / crf=19.0 / rceq='blurCplx^(1-qComp)' / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:1.00


1920x1080

x264 core 67 r1120M 8544346

cabac=1 / ref=8 / deblock=1:1:-3 / analyse=0x3:0x2 / me=umh / subme=9 / psy_rd=0.8:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=1 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=6115 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00


720x1280

x264 core 98 r1649 c54c47d

cabac=1 / ref=8 / deblock=1:-3:-3 / analyse=0x3:0x113 / me=umh / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=0 / b_bias=0 / direct=1 / weightb=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=3999 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

1280x720

x264 core 107 r1745 4785e8e

cabac=1 / ref=9 / deblock=1:0:0 / analyse=0x3:0x13 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=9 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=130 / rc=crf / mbtree=1 / crf=19.5 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60

PS: Nev could you test all these samples on your current Intel Driver i used 2639 for testing DXVA2 playback and confirm or deconfirm the issues thx
All the clips play fine with CoreAVC 3.1, however the 720p-cuda.mkv has the errors encoded into the stream itself.

[SeeMoreDigital]

I don't know how MediaInfo determines that value, but its clearly invalid. Don't trust MediaInfo unconditionally. The AR of that file is 16:9, and its clearly stated like that in the MPEG-2 Headers (the video stream headers, not the container)MediaInfo probably took the AR information from the "Sequence Display Extension"... on this occasion.