Media Player Classic Home Cinema (MPC-HC) - DXVA!

[clsid]

Can somebody try this release of VSFilter with Haali Renderer and told me if it solve the freeze problem in mpc :

http://www.zshare.net/download/16633220b12de839/
Still freezes :(

[sneaker_ger]

Still freezes :(

here too

[tetsuo55]

Not all my files with low resolution and 16 ref frames decoded properly with DXVA (stop after a few frames). Limitation 11+ is better. I suggest tetsuo55 code and 13+ ref. frames limitation (official 3.1 level max for 720x480 and probably less).

But some did? can you show me the details for those files? And those that did not work?

[XibaD]

Well, it's weird. Now with the latest version of MPC-HC (718) and with the latest Catalyst drivers (8.8 beta 8.52.2) DXVA works for me in Windows XP x64. I don't know what changed... Works with all the videos that worked in Windows XP x86.

:)

[tetsuo55]

Casimir thanks for compiling a test build with my code.

To get more accurate test results i need a build that tries to decode everything with DXVA.

My current testing has determined 2 things:

1.the switchpoint between L3.1 and L4.1 decoder settings is somewhere between width=720 and width=960 (to find the exact point i need a build that plays everything with DXVA)
Height does not seem to be a factor.

2.Files with more than 11 ref frames do indeed work, but as Mathaul already said there is a bug in MPC-HC.
this bug is not only triggered by 11+ files but can even occur with lower ref frames.

I have uploaded a file, its 720x480 and has 13 ref frames. On my HD2600 the video works for 21 seconds and then hangs, seeking fixes the stream for a while until another hang occurs.

This video proves that higher than 11 ref frames can be accurately decoded but also proves there is a bug in the MPC-HC decoder.

720x480x13
http://www.megaupload.com/?d=3DBRRAAG

PS, this file could point the way to a FIX, as long as i stay under the L3.1 DPB limit, any valid combination of height+width+refframes will always hang when it reaches 21 seconds.

[marc99]

But some did? can you show me the details for those files? And those that did not work?

Sample files BAD and OK.

http://www.sendspace.com/file/hcoi0u

http://www.sendspace.com/file/nvd45j

Your sample "Dolphins_720.mkv" works fine for me (never stop).

[tetsuo55]

Sample files BAD and OK.

http://www.sendspace.com/file/hcoi0u

http://www.sendspace.com/file/nvd45j

Your sample "Dolphins_720.mkv" works fine for me (never stop).

Thanks again:

So the 11 ref frame limit bug seems to only effect ATi and not NVIDIA, as the working file has 16 ref frames.

That BAD file will never work. The reason it does not work is because it was encoded incorrectly due to a bug in x264. Put simply the file actually acts like a 17 ref frame file due to this bug. Re-encoding it with a current version of x264, with exactly the same settings would result in a working file.

The good news is that we can update the DXVA detection script to block that file too.

So we have 3 things now:
1. My code works correctly, apart from the fact that the L3.1/L4.1 split is not 1024.
2. On nvidia all files that should work do work now, and those that do not are encoded incorrectly, these can be filtered out by adjusting the detection code(check for x264 version and bframes in addition to resolution and ref frames).
3. On ati there is a bug which prevents files with more than 11 ref frames to work.


Casimir, i read in another forum that you are close to fixing the 11 ref frame bug, is this true?
If you want i can start working on the code to filter out files like bad.mkv that marc99 posted

Here is what the new code needs to do:

Resolution+Ref_frame_limit_check
{ Check if numbers match L4.1 } // we do this already
{ Check if its not a L3.1 FILE } // we do this already
{ Check if the file is encoded with a broken x264 version} // anything below revision 721 is broken
{ Check if the file is broken by counting Bframes as an extra ref frame} // recheck if dpb limit is met


Some more tst files, marc99 do these all work for you?
http://www.megaupload.com/?d=5GXC4D65

[gngn]

720x480x13
http://www.megaupload.com/?d=3DBRRAAG




it will hang on my system also after 21sec with your version. the oficial r718 will drop DXVA for this file and use software decoding.
a version with forced DXVA decoding should be interesting.

edit:
320x240x16.mkv - freezes instantly
320x240x15.mkv - freezes after 2 sec
640x480x14.mkv - freezes after 21 sec. whats with this 21 sec?

[marc99]

Some more tst files, marc99 do these all work for you?
http://www.megaupload.com/?d=5GXC4D65

640x480x14.mkv - all ok
320x240x15.mkv - all ok
320x240x16.mkv - stops at 23 s

I use Vista. MPC-HC has different code for Vista and XP. Vista is more compatible.

[gngn]

{ Check if the file is encoded with a broken x264 version} // anything below revision 721 is broken




does this mean that results from test-files encoded by x264 below revision 721 should not be posted, as they are flawed?


for Nvidia Vista sure is the better OS when playing in DXVA. is it related to the EVR buffers?

[tetsuo55]

640x480x14.mkv - all ok
320x240x15.mkv - all ok
320x240x16.mkv - stops at 23 s

I use Vista. MPC-HC has different code for Vista and XP. Vista is more compatible.

thanks for testing

does this mean that results from test-files encoded by x264 below revision 721 should not be posted, as they are flawed?


for Nvidia Vista sure is the better OS when playing in DXVA. is it related to the EVR buffers?

It does seem that currently the vista code is better, however eventually the compatibility for XP and Vista should be the same.

Revisions below 721 can create valid files. its just that b-frames count as Ref frames, and can add up to 2 ref frames to the total in a worse-case situation

[Lys]

When I get a UAC prompt and either cancel or permit, the video freezes, but the sound continues. This is with build 604 up to 680ish. If you pause and resume, the player crashes.

Vista Home Basic SP1, GeForce 8600 GT 256MB, 2GB RAM, 177.79 beta and latest WHQL both don't work. Using EVR.

[MatMaul]

Here is what the new code needs to do:

Resolution+Ref_frame_limit_check
{ Check if numbers match L4.1 } // we do this already
{ Check if its not a L3.1 FILE } // we do this already
{ Check if the file is encoded with a broken x264 version} // anything below revision 721 is broken
{ Check if the file is broken by counting Bframes as an extra ref frame} // recheck if dpb limit is met

wrong, the number of refs we read in MPC is the correct one. x264 was not broken, it is just the old --ref option which did not match the DPB but an other value (number of ref in the L1 picture store or something like that :P )
try an old encode, you will see --ref 9 in the userdata of the stream and 11 or 12 in the number detected in the SPS by MediaInfo or MPC

about the testing of the code, please test with cyberlink decoder you will perhaps have some surprise like some SD files with 15-16 refs which decode just fine in DXVA mode

[Casimir666]

@clsid
:thanks:

@Casimir
Is the translation "European Portuguese" or "Brazilian Portuguese"? Because they are not the same.
Current translator is Brazilian so if you want you can do the Portuguese version. Give me you email by P.M and i'll send you a document with explanations ;-)


Casimir, i read in another forum that you are close to fixing the 11 ref frame bug, is this true?
If you want i can start working on the code to filter out files like bad.mkv that marc99 posted
:confused:
It's a fake information. As Matmaul say we know there is something poorly programmed in the output buffer, but I've not working on it for a while.


If you want to disable DXVA compatibility check, just add this key in registry :
HKEY_CURRENT_USER\Software\Gabest\Filters\MPC Video Decoder
- Key name : CompatibilityMode
- type : DWORD
- value : 15

[tetsuo55]

wrong, the number of refs we read in MPC is the correct one. x264 was not broken, is is just the old --ref option which did not match the DPB but an other value (number of ref in the L1 picture store or something like that :P )
try an old encode, you will see --refs 9 in the userdata of the stream and 11 or 12 in the number detected in the SPS by MediaInfo or MPC

I know the detected number is correct, i guess my explenation is not clear

This is what happened:
Encode settings.
Ref 16
Bframes 16
B-pyarmids yes

These settings would result in 17 or 18 ref frames. H264 is not capabable of this so everything above 16 gets cropped so to speak. The resulting file would work in software mode, but would be unmappable/unsliceable in hardware mode.

[MatMaul]

These settings would result in 17 or 18 ref frames. H264 is not capabable of this so everything above 16 gets cropped so to speak. The resulting file would work in software mode, but would be unmappable in hardware mode.
I never heard about x264 create such obviously incompliant stream. please post a source or a sample.

[tetsuo55]

I never heard about x264 create such obviously incompliant stream. please post a source or a sample.

Sample can be found here:
Sample file BAD.
http://www.sendspace.com/file/hcoi0u


Post where x264 dev told me they fixed the bug:
http://forum.doom9.org/showthread.php?p=1088894

PS, i think with the correct settings in the decoder we can completely ignore L3.1 in the future, however until now i have not seen any outside of L3.1DPB files work in either MPC-HC or PowerDVD


:confused:
It's a fake information. As Matmaul say we know there is something poorly programmed in the output buffer, but I've not working on it for a while.


If you want to disable DXVA compatibility check, just add this key in registry :
HKEY_CURRENT_USER\Software\Gabest\Filters\MPC Video Decoder
- Key name : CompatibilityMode
- type : DWORD
- value : 15

Okay, i have been trying to learn about DXVA hope i can help you more than just the filtering of valid files.

At least we know that the way you're doing it for Nvidia in Vista EVR is the correct method as proven by marc99, can you apply the same method to XP EVR?

[Sharktooth]

i dont think x264 will produce that... crap...
have you any proof (samples) of what you're saying?

[Casimir666]

Still freezes :(

And with this one ?
http://www.zshare.net/download/166777564490f1f5/

[MatMaul]

the sample is fine according to mediainfo. lol this sample was created which x264 rev819. and the topic is unrelated, they talk about mapping the behavior of --ref with the dpb then they can create level4.1 compliant files easily, not about files which are uncompliant regarding the overall 16 limit of the standard.

[tetsuo55]

the sample is fine according to mediainfo. lol this sample was created which x264 rev819. and the topic is unrelated, they talk about mapping the behavior of --ref with the dpb then they can create level4.1 compliant files easily, not about files which are uncompliant regarding the overall 16 limit of the standard.

Whoops your right.That file should work. The only difference between that file and the other one he posted is the number of bframes, the non working one has 16 and the working one has 3.

The behaviour also meant that ref 16 + b-pyramids would not work. This was confirmed in the past over at avsforums. Those tests where al done near the end of 2007 and all with PowerDVD

If BAD.mkv does NOT work with the powerdvd decoder than it has to be invalid, if it does work there is another bug in the MPC-HC decoder and that bug is then related to the bframes.

--------

I am not near my encoding system now, a nice test would be a file encoded with:
Resolution=704*400
Ref=15
Bframes=16
B-pyramids=yes

And then use avinaptic to check the real number of ref-frames.

[Tery]

nobody ?

I really like, being able to choose which Screen to use when playing full screen, but sometimesI play video fullscreen on computer screen sometimes not, and it is really anoying to modify preferences each times.

Would it be possible to add command key, in preferences to be able to configure two keys (or more if people have more than two screen), to play full screen on screen 1 or 2 .... ?
Like F11 play full screen on screen1, and F12 play full screen on screen2.

Or something like two left click, play full screen on screen1 and two right click play it on screen2 ? (and two middle click play it on screen3 .... :D)

Thanks for your great work, keep going :)

Tery.

[tetsuo55]

Leaving past results in the past.

I'm still working on my test set.

-As many resolutions as possible below width=1024
Each resolution within L3.1 DPB
Each resolution out of L3.1 DPB

The files are encoded with b-frames 3, no-b-pyramids

marc99, so far your setup seems to play everything. when i upload them could you try them on MPC-HC and PowerDVD?

When i finish this set i will try another batch with b-frames 16, i cannot enable b-pyramids with my encoder frontend

[clsid]

And with this one ?
http://www.zshare.net/download/166777564490f1f5/
Also freezes.

Sometimes it doesn't freeze. But that is maybe 1 out of 20 times.

When MPC freezes, the Haali and DirectVobSub icons are visible in the system tray. The ffdshow (which I use for decoding) icons are not yet visible. Using another decoder doesn't make any difference.

Freeze occurs immediately after the MPC window resizes.

[sneaker_ger]

Also freezes.

Sometimes it doesn't freeze. But that is maybe 1 out of 20 times.

When MPC freezes, the Haali and DirectVobSub icons are visible in the system tray. The ffdshow (which I use for decoding) icons are not yet visible. Using another decoder doesn't make any difference.

Freeze occurs immediately after the MPC window resizes.

Still freezes here too, but I noticed a very strange behavior on both this build and the build before:
Both worked the frist time I tried them and only the first time. I did an "regsvr32 /u vsfilter.dll", then copied the new vsfilter.dll to windows\system32 and then did a "regsvr32 vsfilter.dll". The first time I tried to play a file with it it worked - both builds. Beginning with the second trial both of them always crashed MPC. Unregistering and Registering the same files again did not work though. :confused:

[alexins]

Media Player Classic HomeCinema (x86), svn 720 (http://www.xvidvideo.ru/content/view/135/1/)
Media Player Classic HomeCinema (x64), svn 720 (http://www.xvidvideo.ru/content/view/136/1/)

Supported languages: CN, CZ, DE, ES, FR, HU, IT, KR, PL, RU, SK, TR, UA

FIX : Crashes when next playlist item starts while MINIMIZED (bug #2035083 (http://sourceforge.net/tracker/index.php?func=detail&aid=2035083&group_id=170561&atid=854651)); Updated German translation

Changes log (http://www.xvidvideo.ru/content/view/7/17/)

[ADude]

Are you talking about MPEG1 inside Matroska container? Or the MPEG-PS splitter (which you should not enable) of Haali? There is a topic about Haali Media Splitter on this forum, you can report bugs there.

Here is the message I posted:
I've found that the latest version of Haali Media Splitter (29 March 2008) does not work properly with MPEG-1 videos - they stop at the beginning and state that the file is length 0:00.

If I use MPC-HC internal media splitter for MPEG-1, it is fine, but I want to use Haali Media Splitter for MPEG2 TS/PS and MPC-HC's internal splitter either does all MPEG-1 and MPEG-2 or none. .

Any way around this ?

PS I did a search, and I see a long "Haali Renderer" thread, but no corresponding one for the splitter, just various short threads about problems, often with no reply...

[marc99]

(...)marc99, so far your setup seems to play everything. when i upload them could you try them on MPC-HC and PowerDVD?


All 11+ reference frames files with CyberLink Decoder plays wrong (macroblocks).

[tetsuo55]

Interesting that PowerDVD fails to decode over 11 frames too.

I have used the no-dxva check reg-key. this is my conclusion:

The DXVA decoder as implemented in current videocards is a L4.1 device. As such it will decode any stream within the L4.1 DPB.
If a file which does not fit into L4.1 DPB is forced onto the DXVA decoder things like green screens and full system crashes occur.


How i tested this was:
Create a valid L3.1 stream, but push the number of ref-frames over the L3.1 limit, exact same behaviour as a valid stream within L3.1 limit but with more than 11 ref frames was the result.

At this point:
In XP any resolution + ref frame combination thats stays under L4.1DPB and 11 ref frames will work 100% ok
In Vista any resolution + ref frame combination that stats under L4.DPB will work 99% ok in vista (still testing the b-frames)

[clsid]

PS I did a search, and I see a long "Haali Renderer" thread, but no corresponding one for the splitter, just various short threads about problems, often with no reply...This is the topic:
http://forum.doom9.org/showthread.php?t=80762

[clsid]

Still freezes here too, but I noticed a very strange behavior on both this build and the build before:
Both worked the frist time I tried them and only the first time. I did an "regsvr32 /u vsfilter.dll", then copied the new vsfilter.dll to windows\system32 and then did a "regsvr32 vsfilter.dll". The first time I tried to play a file with it it worked - both builds. Beginning with the second trial both of them always crashed MPC. Unregistering and Registering the same files again did not work though. :confused:
I can confirm this behavior. Good find.

I will try to figure out what changes after the first run that breaks things. Starting RegMon now.

[clsid]

Still freezes here too, but I noticed a very strange behavior on both this build and the build before:
Both worked the frist time I tried them and only the first time. I did an "regsvr32 /u vsfilter.dll", then copied the new vsfilter.dll to windows\system32 and then did a "regsvr32 vsfilter.dll". The first time I tried to play a file with it it worked - both builds. Beginning with the second trial both of them always crashed MPC. Unregistering and Registering the same files again did not work though. :confused:
I can confirm this behavior. Good find.

Haali renderer plus DirectVobSub works fine for me in GraphEdit.

[Shakey_Jake33]

This isn't a bug in MPC-HC as such, just wanted to share something I noticed today. Some of you will know that Nvidia GPU's on laptops have a feature called Powermizer, which will dynamically downclock when idle. It's a great feature, but it really confuses EVR Custom Presenter. When full screen, my GPU will run at full 400MHz. When Windowed, it will downclock to 275MHz over time, and then 169MHz. This is fine, that's plenty for video... but this sequence of downclocking seems to confuse EVR Custom Presenter and it will drop loads of frames. I can close the player and start the video again in 169MHz mode and it will play fine, so it's clearly the sequence of the changing clock speed that screws something up in EVR, rather than the clock speed itself. It also does not occur with Haali renderer.

This does not happen in normal EVR or Haali Renderer, so I've had to revert back to 32-bit player/codecs so I can use Haali until he makes a 64-bit version. A shame because I like EVR Custom Presenter, but this behaviour makes it unsuitable for laptops with Nvidia GPU's and Powermizer enabled.
Quoting my own post because I mentioned it's not a bug in MPC-HC. However, since this does not occur using the 'normal' EVR (.NET3), it's surely an issue exclusive to MPC's 'custom presenter' implementation of EVR.

Powermizer is a feature in Nvidia mobile GPU's allowing the GPU to dynamically change clock speed. This saves battery and reduces temps. It has 3 different modes - Low Power 2D, Low Power 3D and Performance 3D. On my 8400m GS, these are 169MHz core clock/100Mhz memory clock, 275MHz/301MHz and 400MHz/600Mhz respectively.

The actual speed the GPU is running at is not important (I'm not using DXVA fyi), as long as it consistantly stays in one speed mode. But this isn't what happens, it changes depending on the complexity of what's on screen, and switches to full speed mode when going full screen. This is the same on any renderer. The problem with EVR Custom Presenter exclusively is that when the clock speed gradually lowers (as it seems to during the course of a video, or going full screen then windowed), EVR begins to drop loads of frames. Clearly this is not because of the lower clock speed, but the fact that the GPU speeds are changing confuses it. As I say, this only happens in Custom Presenter.

Anyone can try this out for themselves by downloading GPU-Z and watching the clock speeds and frames dropped, and will notice as soon as it drops down to 'Low Power 2D' mode after coming down from a higher mode, frames will drop.

I recognise it's hardly high priority, but it potentially effects anyone with a laptop w/ an Nvidia-based GPU.

[ADude]

This is the topic:
http://forum.doom9.org/showthread.php?t=80762

Thanks, it doesn't have the word "Haali" in the title.

It would still be helpful for MPC-HC to have separate splitter selection for MPEG-1, MPEG-2, MPEG-2 TS and MPEG-2 PS (such as found in other players like Zoom).

[Kado]

@Shakey_Jake33
I have a 9800GTX (desktop) and have been playing with Riva Tuner changing clock speeds for all stuff like core, shader and memory. With or without DXVA I don't get any dropped frames using EVR CP while changing the clock speeds.
Try recent drivers from Laptopvideo2go (http://www.laptopvideo2go.com/) and update you DirectX to the latest revision (http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en).

[rahzel]

can you guys give me some help in setting up the Output settings?
i've done a lot of googling and searching within this thread but i still have a few questions. first of all, i'm using winXP Pro SP3 with a 7800 GT. my current settings are:
VMR9 renderless mode
surface - 3d surfaces
bicubic resizer (0.75)
vmr9 mixer mode checked
yuv mixing checked

so my questions are, what do most people use for the resizer? i heard some people find 1.0 to be too sharp so i'm using 0.75 atm. i don't really have the eyes to tell the difference, so if someone could tell me which is a good compromise, that would be great. :)

should yuv mixing be checked? checked or unchecked, i don't really notice any difference.

also, for "directshow audio" i have several options, which one should i choose?

fwiw, i have CoreAVC installed.

edit: something else i found odd was that bilinear ps2.0 looks the same as bicubic ps2.0. i took screencaps of each and zoomed in on both and they look exactly the same. again, i have a 7800 GT. my drivers are somewhat out of date (haven't updated for a few months) but that should be a problem... my card is PS 2.0 capable afaik.

[Shakey_Jake33]

@Shakey_Jake33
I have a 9800GTX (desktop) and have been playing with Riva Tuner changing clock speeds for all stuff like core, shader and memory. With or without DXVA I don't get any dropped frames using EVR CP while changing the clock speeds.
Try recent drivers from Laptopvideo2go (http://www.laptopvideo2go.com/) and update you DirectX to the latest revision (http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en).
I'm afraid the same happens on the newer 174.31, 174.74 and 175.80 revisions (I've been doing a huge amount of driver switching recently). I'll do some tests later to see if the same happens in Vista 64-bit.

[Casimir666]

Still freezes :(

One more try with this one :

http://www.zshare.net/download/16759901141ff297/

[sneaker_ger]

One more try with this one :

http://www.zshare.net/download/16759901141ff297/

Seems to work fine now.

[clsid]

Works here too :)

[Casimir666]

Works here too :)

Cool :cool:
Reason was an old workaround for Hollywood+ renderer not completly removed from mpc (call to IFilterGraph function in StartStreaming cause deadlock with Haali)

[clsid]

Great work!

[alexins]

Media Player Classic HomeCinema (x86), svn 724 (http://www.xvidvideo.ru/content/view/145/1/)
Media Player Classic HomeCinema (x64), svn 724 (http://www.xvidvideo.ru/content/view/146/1/)

Supported languages: CN, CZ, DE, ES, FR, HU, IT, KR, PL, RU, SK, TR, UA

Updated FFmpeg; Fixed : random freeze when using mpc-hc, vsfilter and Haali renderer at the same time

Changes log (http://www.xvidvideo.ru/content/view/7/17/)

[Mangix]

no idea if this should be here, but can anyone give an explaination of the shaders that mpc has and what they do? or maybe a link?

edit: new DirectX is out.

http://www.microsoft.com/downloads/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&DisplayLang=en

[Zulithe]

if i double-click a file in explorer and it launches in MPC while another file is already playing, mpc appears to try to play them both simultaneously. this doesn't always happen, but frequent enough that it is bothersome. Any tips? I tried disabling internal filters and that didn't do it. I tried changing render modes to others my PC supports, also didn't notice a change.

I'm on Vista 32bit with the latest directx installed. I use ffdshow ( ffdshow_rev2063_20080804_clsid.exe )

[MatMaul]

@tetsuo55, about max refs check (again :p ) :
seems like we check the wrong parameter, according to the specs we need to check sps->vui->max_dec_frame_buffering and, according to this post (http://forum.doom9.org/showthread.php?p=1169034#post1169034), this is not the same as sps->num_ref_frames (which is what sps->ref_frame_count refers to in libavcodec).

Do you understood the same thing ? I made the patch and it is ready to commit.

[tetsuo55]

@tetsuo55, about max refs check (again :p ) :
seems like we check the wrong parameter, according to the specs we need to check sps->vui->max_dec_frame_buffering and, according to this post (http://forum.doom9.org/showthread.php?p=1169034#post1169034), this is not the same as sps->num_ref_frames (which is what sps->ref_frame_count refers to in libavcodec).

Do you understood the same thing ? I made the patch and it is ready to commit.

I think that might work, as long as it doesn't break detection of correctly encoded files? As far as we know only x264 does this.

We are checking the correct parameter, its just that x264 is not writing the correct number to that parameter.

The discussion is not finished yet. I hope a patch will be thought up soon to fix the problem

Is your patch still limiting to 11 ref frames?

Every is already in agreement that x264 is doing something "differently". Still some files might work while others are broken (because b-frames and ref frames are used dynamically and it doesn't break until the total of ref+bframe goes over the DBP) Still almost all fullhd encodes in the wild use b-pyramids and should constantly be going out of DPB but are not.

[MatMaul]

I am not talking about x264 here (even if it is this post which point that in my mind).
I don't know if you have the h264 standard but dpb check as to be done against max_dec_frame_buffering and not num_ref_frames that's all.
here is an extract of the standard :
max_dec_frame_buffering <= MaxDpbSize, where MaxDpbSize is equal to Min( 1024 * MaxDPB / ( PicWidthInMbs * FrameHeightInMbs * 384 ), 16 )
and max_dec_frame_buffering != num_ref_frames

[tetsuo55]

I am not talking about x264 here (even if it is this post which point that in my mind).
I don't know if you have the h264 standard but dpb check as to be done against max_dec_frame_buffering and not num_ref_frames that's all.
here is an extract of the standard :

and max_dec_frame_buffering != num_ref_frames

Oh now i see.
In that case i agree, 2 birds in 1 stone. We check the correct value and we work around the x264 bug

[MatMaul]

Oh now i see.
In that case i agree, 2 birds in 1 stone. We check the correct value and we work around the x264 bug
I don't thing this works around the x264 bug because x264 seems to write the wrong max_dec_frame_buffering value (in x264 max_dec_frame_buffering = num_ref_frames which seems to not be true when you use b-pyramid)
I reread pengvado-DS IRC chat and pengvado said that dxva seems to handle correctly 4-ref bpyramid files (so dpb=5>maxDPB) so I don't know if I should change that...