x264 Known Hardware accelleration problems and solutions

[tetsuo55]

Um if you don't have a PS2/X360 and don't intend to play in one, why would you give a damn what they can or can't do?

Lets say you have this movie, and you transcode that movie with x264, and then take the disc to a friend, who only has a xbox360, the file would have to be compatible with the xbox 360 in order to work.

I have encountered this problemen quite a few times (most people i know seem to have wildly different setups of video plaback hardware @_@)

Also i think the programmers of x264 would like for their program to be as compatible as possible with all the playback solutions, as this would lead to more users of the program.

[audyovydeo]

Um if you don't have a PS2/X360 and don't intend to play in one, why would you give a damn what they can or can't do?

Hello ? Don't forget this thread's title :

"x264 + more than 4 ref frames = no DXVA or 20fps bug (ati avivo, nvidia purevideo)"

so everyone who's hoping to get their video card to do what it's marketed to do ought to be interested.

cheers
audyovydeo

[tetsuo55]

I tested clips at 480p and 576p on my Nvidia 8800GT (G92 decoder).

They worked with DXVA at L4.1, L4.0, L3.2 settings, but showed choppy playback and/or block errors.

My test methodology was to keep the DPB size within L4.1, which at either 480p or 576p allows DPB=16. Then I dropped the level_idc tag from 4.1 to 4.0 to 3.2 to 3.1, looking to see if the L4.1 streams could be decoded smoothly if the level_idc was lower. This demonstrated that the stream itself has to have DPB size within L3.1.

I then encoded 480p and 576p streams at their L3.1 DPB size limits, with the level_idc set at 4.1. DXVA worked, but as with the L4.1 streams with a level_idc of 5.1, playback was choppy with the level_idc set too high. This showed the level_idc needs to be L3.1.

For 480p and 576p, the DPB size needs to stay within L3.1, and the level_idc needs to be L3.1 for smooth playback.

The bottom line overall seems to be that streams need to comply with and declare L4.1 for HD and L3.1 for SD.

The following SD streams had smooth playback with DXVA:

480p, ref=13, bframes=3, DPB=13, level_idc=3.1
576p, ref=11, bframes=3, DPB=11, level_idc=3.1


The following SD streams had choppy playback with DXVA:

480p, ref=16, bframes=16, b-pyramid=on, DPB=16, level_idc=4.1
480p, ref=16, bframes=16, DPB=16, level_idc=4.1
480p, ref=16, bframes=16, DPB=16, level_idc=4.0
480p, ref=16, bframes=16, DPB=16, level_idc=3.2
480p, ref=16, bframes=16, DPB=16, level_idc=3.1
480p, ref=13, bframes=3, DPB=13, level_idc=4.1

576p, ref=16, bframes=16, b-pyramid=on, DPB=16, level_idc=4.1
576p, ref=16, bframes=16, DPB=16, level_idc=4.1
576p, ref=16, bframes=16, DPB=16, level_idc=4.0
576p, ref=16, bframes=16, DPB=16, level_idc=3.2
576p, ref=16, bframes=16, DPB=16, level_idc=3.1
576p, ref=11, bframes=3, DPB=11, level_idc=4.1


So what would you advice for best overal settings for 720x(any)?

Or de they have to be split up in 720x576 and 720x480?
Also would these settings still be valid for the no black space resolutions like.

640x352
608x256
592x448
720x544
640x360

[UsedUser]

So what would you advice for best overal settings for 720x(any)?
A safe value for 720x(720 or less) would be DPB=8.

Or de they have to be split up in 720x576 and 720x480?
Also would these settings still be valid for the no black space resolutions like.

640x352
608x256
592x448
720x544
640x360
My personal preference, I would use the PS3 profile without B-pyramid for everything. That would result in DPB=3, no matter the resolution.

If I was feeling lucky, I might push up to DPB=5, but that's it. The quality / encoding time balance is good for me right about there. The Ateme encoder in Nero Digital maxes out at 3-5 DPB as well.

I think I've finally arrived at set-it-and-forget options with the PS3 profile sans B-pyramid.

[valnar]

My personal preference, I would use the PS3 profile without B-pyramid for everything. That would result in DPB=3, no matter the resolution.


But what about this?
The bottom line overall seems to be that streams need to comply with and declare L4.1 for HD and L3.1 for SD.


I've made two profiles just in case - one for SD/DVD and one for HD. The difference is the Level and vbv-maxrate.

I also use CRF instead.

--pass 1 --crf 20 --stats ".stats" --progress --keyint 250 --bframes 3 --qpmin 10 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter -2,-1 --subme 6 --direct auto --vbv-maxrate 14000 --me umh --level 4.1 --merange 12 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --no-dct-decimate



-Robert

[Sharktooth]

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?

[UsedUser]

Oops, you need to encode with at least as many refs as B-frames, otherwise some of the B-frames won't have any future ref.
-r2 -b2 --no-b-adapt worked. -r3 -b3 --no-b-adapt still doesn't work.

I'm also interested in how the 3 experiments fare when not stressing the DPB. So try each with "-r2 -b2" and "-r3 -b3".
--b-adapt on or off?

[UsedUser]

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?
It would be great.

My vote would be to have a DXVA-HD profile: PS3 settings, except without B-pyramid; and a DXVA-SD profile: PS3 settings, except without B-pyramid and with --level 3.1.

Though, since we're still working out B-frame issues with B-pyramid, maybe we should wait until the finished patches get into the code.

[tetsuo55]

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?

It would be great.

My vote would be to have a DXVA-HD profile: PS3 settings, except without B-pyramid; and a DXVA-SD profile: PS3 settings, except without B-pyramid and with --level 3.1.

Though, since we're still working out B-frame issues with B-pyramid, maybe we should wait until the finished patches get into the code.

i think UsedUser is right, we should have it all figured out, and (if needed) x264 should be updated before the gui's

[akupenguin]

--b-adapt on or off?
If b-adapt has anything to do with compatibility, the decoder is much more crippled than I thought.

[shon3i]

I found this profiles in Elecard Converter Studio 2.0, and i think will be usefull here

"BluRay SD AVC", resolution if not will be automaticly resized to 720x576 and aspet ratio can be changed, and profile have this options

http://img229.imageshack.us/img229/1678/bluraysd1at2.jpg
http://img229.imageshack.us/img229/7814/bluraysd2bi9.jpg
http://img229.imageshack.us/img229/515/bluraysd3br6.jpg

"BluRay HD AVC", resolution if not will be automaticly resized to 1920x1080 and aspet ratio can be changed, and profile have this options

http://img229.imageshack.us/img229/1048/blurayhd1dj9.jpg
http://img70.imageshack.us/img70/3497/blurayhd2av1.jpg
http://img518.imageshack.us/img518/1059/blurayhd3jc7.jpg


And aslo i found some interesting thing in both, ateme and elecard/mainconcept's documentation for AVC encoders, to use MV Range of 255 for SD and 511 for HD.

[Manao]

ateme and elecard/mainconcept's documentation for AVC encoders, to use MV Range of 255 for SD and 511 for HDMV Range is given by the level, not by the encoder. And there seem to be a typo in Elecard Converter Studio 2.0, since level 3.2 has a MV range of 511, not 255.

[akupenguin]

MV Range is limited by level, but the encoder is free to pick a smaller value, and may or may not specify the value it picked in the VUI header.

[CruNcher]

NVIDIA GeForce 8800 GT
ModeMPEG2_IDCT: [NV12] 720x480 / 1280x720 / 1920x1080
ModeVC1_IDCT: [NV12] 720x480 / 1280x720 / 1920x1080
ModeWMV9_IDCT: [NV12] 720x480 / 1280x720 / 1920x1080
ModeVC1_MoComp: [NV12] 720x480 / 1280x720 / 1920x1080
ModeWMV9_MoComp: [NV12] 720x480 / 1280x720 / 1920x1080
ModeVC1_PostProc: [NV12] 720x480 / 1280x720 / 1920x1080
ModeWMV9_PostProc: [NV12] 720x480 / 1280x720 / 1920x1080
1720AC81-9D1B-4F63-9A37-4A88483D0B87: [NV12]
ModeH264_VLD_NoFGT: [NV12]


AVC/H.264:

ffdshow Video Decoder
Unknown

MainConcept AVC/H.264 Video Decoder [avc1 1920x1080]
Unsupported

CyberLink H.264/AVC Decoder (PDVD7.x) [avc1 1920x1080]
ModeH264_VLD_NoFGT(*)
ModeH264_VLD_FGT
ModeH264_MoComp_PureVideo
NV12 (ModeH264_MoComp_NoFGT)
ModeH264_MoComp_Avivo
ModeMPEG2_IDCT

Nero DVD Decoder [avc1 1920x1080]
ModeH264_MoComp_PureVideo
ModeH264_MoComp_Avivo
GUID_NULL

Nero Video Decoder [avc1 1920x1080]
ModeH264_MoComp_PureVideo
ModeH264_MoComp_Avivo
GUID_NULL

CoreAVC Video Decoder [avc1 1920x1080]
Unsupported

MPEG-2:

fdshow Video Decoder
Unknown

Elecard MPEG-2 Video Decoder [MPEG2 1920x1080]
ModeMPEG2_B
ModeMPEG2_D(*)
ModeMPEG2_A
ModeMPEG2_C

MainConcept MPEG-2 Video Decoder [MPEG2 1920x1080]
ModeMPEG2_B
ModeMPEG2_D(*)
ModeMPEG2_A
ModeMPEG2_C

CyberLink Video/SP Decoder (PDVD7) [MPEG2 1920x1080]
ModeMPEG2_VLD
ModeMPEG2_D
ModeMPEG2_B
ModeMPEG2_C(*)
ModeMPEG2_A

Nero DVD Decoder [MPEG2 1920x1080]
ModeMPEG2_D
ModeMPEG2_C
ModeMPEG2_B
ModeMPEG2_A

Nero Video Decoder [MPEG2 1920x1080]
ModeMPEG2_D
ModeMPEG2_C
ModeMPEG2_B
ModeMPEG2_A

ArcSoft MPEG Video Decoder [MPEG2 1920x1080]
Unsupported

Sonic Cinemaster® VideoDecoder 4.1 [MPEG2 1920x1080]
None

ArcSoft Video Decoder [MPEG2 1920x1080]
ModeMPEG2_D(*)
ModeMPEG2_C
ModeMPEG2_B
ModeMPEG2_A

CyberLink Video/SP BD-HD Decoder (PDVD7.x)
Unknown

ArcSoft DVD Video Decoder
Unknown

VC-1:

ffdshow Video Decoder
Unknown

MainConcept VC-1 Decoder [WVC1 1920x1080]
Unsupported

WMVideo Decoder DMO [WVC1 1920x1080]
ModeVC1_IDCT(*)
ModeVC1_MoComp
ModeVC1_PostProc

Nero DVD Decoder [WVC1 1920x1080]
GUID_NULL

Nero Video Decoder [WVC1 1920x1080]
GUID_NULL

Sonic Cinemaster® VideoDecoder 4.1 [WVC1 1920x1080]
None

This http://bluesky23.hp.infoseek.co.jp/DXVAChecker_1401.zip is a cool programm it analyzes the Dshow filter it's DXVA capabilities and even shows the use of the PureVideo or Avivo API :)
You can also find Parser/Decoder problems that way :)

[shon3i]

I tested with one HD and one SD resolution.

HD - 1920x1080 - Elecard Conveter Studio 2.0 - Blurray HD AVC profile - 23.976 fps - decodes smoothly in mkv container with DTS audio, no errors.

SD - 720x432 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - still have 20fps bug

SD - 720x576 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - Everything is fine.

Looks like for SD, resoultion must be 720x576 or 852x480.

EDIT: Did is somebody make Elecard/Mainconcept H264 to decode with HW acceleration?

[Sharktooth]

Though, since we're still working out B-frame issues with B-pyramid, maybe we should wait until the finished patches get into the code.
Yes, sure, im only asking that coz i will completely re-organize the profiles.

[tetsuo55]

Any news on the "B-frame issues with B-pyramid"

And shon3i

What level did you select for this one?

SD - 720x432 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - still have 20fps bug

[bob0r]

...

This http://bluesky23.hp.infoseek.co.jp/DXVAChecker_1401.zip is a cool programm it analyzes the Dshow filter it's DXVA capabilities and even shows the use of the PureVideo or Avivo API :)
You can also find Parser/Decoder problems that way :)

This fine is 404, can you upload it somewhere?

[TheShadowRunner]

Try this :
http://bluesky23.hp.infoseek.co.jp/DXVAChecker_1501.zip
requires .NET 3 (arg)

[shon3i]

And shon3i

What level did you select for this one?

SD - 720x432 - Elecard Conveter Studio 2.0 - Blurray SD AVC profile - 25.000fps - still have 20fps bugI tryed with 3.2 and 4.1. I doing some testing right now, to see what problem can be.

[CruNcher]

Also be carefull wrong --sar can also result in Black Screens geez

[karspen1]

I'm benchmarking gpu dxva performance right now (working at a computer magazine). Do anyone know a (free) high bitrate h.264 sample video that is verified to work with DXVA enabled? Using Cyberlink right now and a having great trouble just to get rid of the dreaded "black screen".

[shon3i]

I'm benchmarking gpu dxva performance right now (working at a computer magazine). Do anyone know a (free) high bitrate h.264 sample video that is verified to work with DXVA enabled? Using Cyberlink right now and a having great trouble just to get rid of the dreaded "black screen".
Apple HD trailers, www.apple.com/trailers

[TheShadowRunner]

this too:
http://www.apple.com/quicktime/guide/hd/
check BBC Japan & BBC Life in the blue.
They work perfect with DXVA and are quite complex encodes (Japan especially).
Later,

TSR

[tetsuo55]

Q: would you like to have "DXVA friendly" profiles based on your findings in MeGUI?

With the commit of the DPB patch, b-refs and b-pyramids can be maxed out (see here http://forum.doom9.org/showpost.php?p=1088556&postcount=4)

So using the settings form this thread + b-pyramids should result in the best encode:

http://www.avsforum.com/avs-vb/showthread.php?t=972503

Unless anyone finds any problems with the newest x264 and the settings from that thread + b-pyramids than this should now be added to the frontends

[shon3i]

Like CruNcher says, aslo wrong SAR settings can make 20fps bug or black screen. I have trouble with anamorphic encode 720x576 and signaled with sar 16:11 for pal DVD which equals DAR 16:9, during playback video isn't played smoothly. Looks like sar 1:1 best solution.

[valnar]

With the commit of the DPB patch, b-refs and b-pyramids can be maxed out (see here http://forum.doom9.org/showpost.php?p=1088556&postcount=4)

So using the settings form this thread + b-pyramids should result in the best encode:

http://www.avsforum.com/avs-vb/showthread.php?t=972503

Unless anyone finds any problems with the newest x264 and the settings from that thread + b-pyramids than this should now be added to the frontends

Do we really need B-pyramids? Even if it works now, I still vote against it.

Robert

[akupenguin]

So using the settings form this thread + b-pyramids should result in the best encode:
http://www.avsforum.com/avs-vb/showthread.php?t=972503

Not quite. Not only pyramid was improved, conventional B-frames also used to count against refs. So increment ref compared to that thread.

Do we really need B-pyramids? Even if it works now, I still vote against it.
And you want to sacrifice some compression ratio just because ...?

[Sagekilla]

Not quite. Not only pyramid was improved, conventional B-frames also used to count against refs. So increment ref compared to that thread.


And you want to sacrifice some compression ratio just because ...?

Agreed.. It sounds like a step backwards to completely remove b pyramids, and I've seen sizeable benefits from using it.

[UsedUser]

With the commit of the DPB patch, b-refs and b-pyramids can be maxed out (see here http://forum.doom9.org/showpost.php?p=1088556&postcount=4)

So using the settings form this thread + b-pyramids should result in the best encode:

http://www.avsforum.com/avs-vb/showthread.php?t=972503

Unless anyone finds any problems with the newest x264 and the settings from that thread + b-pyramids than this should now be added to the frontends

Not quite. Not only pyramid was improved, conventional B-frames also used to count against refs. So increment ref compared to that thread.


And you want to sacrifice some compression ratio just because ...?
I did some testing with svn-721. B-pyramid is still causing corruption (block errors?), even if the DPB isn't maxed out for L4.1:

1080p DXVA without corruption:
DPB=4: --ref 4 --bframes 3
DPB=3: --ref 3 --bframes 3

1080p DXVA with corruption:
DPB=4: --ref 4 --bframes 3 --b-pyramid
DPB=3: --ref 3 --bframes 3 --b-pyramid

[UsedUser]

@akupenguin

Just to tidy up, here are all my results from your patch experiments.

No corruption @ 1080p:
2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
3 Ref 3 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
4 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
4 Ref 3 Bfr B-Pyramid Clip2 svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

Corruption @ 1080p:
2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref

Maybe corruption, maybe just macroblocking on a difficult-to-encode clip @ 1080p:
2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
3 Ref 3 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
4 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

No Corruption @ 720p:
8 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
7 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref

Maybe corruption, maybe just macroblocking on a difficult-to-encode clip @ 720p:
8 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

Corruption @ 720p:
9 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
9 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1

[akupenguin]

I don't see any pattern in those results

[UsedUser]

I don't see any pattern in those results
Are there other combinations of encoding options you want tested?

It's up to you to interpret the results, but as best as I can gather:

no-bref: Successful at and below L4.1 limits, except when pushed to higher numbers of ref frames. I will do a few more 720p encodes to see what --ref value is allowable.

all-bref: Unsuccessful: x264 crashed on all encodes except -r2 -b2, where it showed corruption.

no-L1: Maybe successful: When I encoded "Clip2", which was easier to encode, I didn't see any corruption. So, whatever that patch changed likely just made quality suffer to the point that I saw really bad macroblocking on "Clip1". That macroblocking appeared with the no-L1 patch, but didn't appear on the same clip with the other patches.

I try to grab some screen caps to demonstrate the difference b/w what I'm calling "corruption" vs. "macroblocking". I don't understand enough to speak intelligently about it.

[UsedUser]

I added some 720p results. DPB=7 or 8 is fine. DPB=9 is too much.

I think overall, DPB=8 as a max for 720p is a better recommendation, no matter the patches. DPB=3 is generally safer for 1080p, as well.

[shon3i]

@UsedUser, how look that "block errors" in video, because i encode some 1080p, 720p, 576p clips with this settings translated to Elecard Converter Studio including b-pyramids, and i don't saw any problem with DXVA?

[UsedUser]

Screen caps from my test encodes. Click the thumbnail for the full view.

First, comparisons of the patch experiments @ 1080p. Two screen shots [numbered] per clip.

no-bref (good results)
Good: [1] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adaptsvn-.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adaptsvn-.jpg)

Good: [2] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adapts-1.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adapts-1.jpg)

no-L1 (mixed results)
Some blocking: [1] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
This opening part of the test clip is when I see blocking with the no-L1 patch, then the rest of the clip plays without issue. The result for this encode is similar to the other no-L1 encodes. The blocking does not occur with a software decoder, so it is still something related to DXVA.
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adapts-2.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adapts-2.jpg)

Good: [2] 1080p 2 Ref 2 Bfr B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_no-L1
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrB-PyramidNoB-Adapts-3.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrB-PyramidNoB-Adapts-3.jpg)

all-bref (poor results)
Blocking: [1] 1080p 2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrNoB-PyramidNoB-Adaptsv.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrNoB-PyramidNoB-Adaptsv.jpg)

Blocking: [2] 1080p 2 Ref 2 Bfr No B-Pyramid No B-Adapt svn-717M-ref_dpb-dxva_pyramid_experiment_all-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_1080p2Ref2BfrNoB-PyramidNoB-Adap-1.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/1080p2Ref2BfrNoB-PyramidNoB-Adap-1.jpg)


Next, a comparison of the no-bref patch experiment @ 720p. One screenshot from each clip.

Good: 720p 8 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_720p8Ref3BfrB-Pyramidsvn-717M-ref_d.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/720p8Ref3BfrB-Pyramidsvn-717M-ref_d.jpg)

Blocking: 720p 9 Ref 3 Bfr B-Pyramid svn-717M-ref_dpb-dxva_pyramid_experiment_no-bref
http://s63.photobucket.com/albums/h145/exdeus/x264/th_720p9Ref3BfrB-Pyramidsvn-717M-ref_d.jpg (http://i63.photobucket.com/albums/h145/exdeus/x264/720p9Ref3BfrB-Pyramidsvn-717M-ref_d.jpg)


Lastly, with the no-L1 patch, the DPB=9 clip blue-screened my PC twice when trying to capture in PowerDVD, so I gave up. You get the idea.

[UsedUser]

@UsedUser, how look that "block errors" in video, because i encode some 1080p, 720p, 576p clips with this settings translated to Elecard Converter Studio including b-pyramids, and i don't saw any problem with DXVA?
If you're using Elecard, then we're talking about completely different things.

I'm testing some experimental patches for x264. For each screen cap, I gave the resolution, the important encoding settings, the x264 revision, and the patches applied.

The "normal" (trunk) builds of x264 have produced good results for HD @ L4.1 and SD @ L3.1, similar to your Elecard settings, though without B-pyramids.

[akupenguin]

Updated all b-ref patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_all-bref.diff).

And if that still doesn't work for you, here's some clips I made
conventional_b3r1.264 (http://akuvian.org/src/x264/grimm_conventional_b3r1.264)
pyramid_b3r1.264 (http://akuvian.org/src/x264/grimm_pyramid_b3r1.264)
all-bref_b1r1.264 (http://akuvian.org/src/x264/grimm_all-bref_b1r1.264)
all-bref_b2r2.264 (http://akuvian.org/src/x264/grimm_all-bref_b2r2.264)
all-bref_b3r3.264 (http://akuvian.org/src/x264/grimm_all-bref_b3r3.264)
all-bref_b4r4.264 (http://akuvian.org/src/x264/grimm_all-bref_b4r4.264)
no-L1_b3r1.264 (http://akuvian.org/src/x264/grimm_no-L1_b3r1.264)
no-bref_b3r1.264 (http://akuvian.org/src/x264/grimm_no-bref_b3r1.264)

[UsedUser]

Updated all b-ref patch (http://akuvian.org/src/x264/x264_dxva_pyramid_experiment_all-bref.diff).
Test for dxva_pyramid_experiment_all-bref patch v2. Overall, lots of video corruption with all-bref.

896x480
Good (smooth playback req'd setting L3.1 with h264info):
grimm_conventional_b3r1.264
grimm_no-bref_b3r1.264

Corruption:
grimm_all-bref_b1r1.264
grimm_all-bref_b2r2.264
grimm_all-bref_b3r3.264
grimm_no-L1_b3r1.264
grimm_pyramid_b3r1.264


1080p
Corruption:
3 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref
4 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref


720p
Corruption:
8 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref
9 Ref 3 Bfr No B-Pyramid svn-721-dxva_pyramid_experiment_all-bref

[CruNcher]

OK here are the results aku (forced Cyberlinks Decoder Framework Parser/Decoder via drag and drop the bitstreams into PowerDVD directly "no directshow intereferences by other parser/splitter or whatever can be caused this way")


Nvidia 8800 GT G92 BSP/VP2 Windows XP SP2 Forceware 169.21 WHQL (Windows "NG" specialy modified Windows XP version by me with very low memory consumption)

grimm_all-bref_b1r1.264 <- OK
grimm_all-bref_b1r2.264 <- OK
grimm_all-bref_b2r2.264 <- OK
grimm_all-bref_b2r3.264 <- OK
grimm_all-bref_b3r3.264 <- OK
grimm_conventional_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)
grimm_no-bref_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)
grimm_no-L1_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)
grimm_pyramid_b3r1.264 <- stuttering in some frames most probably b-frame sequence (wrong level?)

So not the same Results as UsedUser as i only experience these stutterings nothing more (no frame corruption @ all) :) except that their is a slight flickering in the dark scene when the camera moves backward away from the little girl (on the left and right side it's flickering "dark area") but i think thats comeing from the Encode itself not from a HDC problem gonna check with Software Decoding again.

Edit: Yep the flickering is a problem of the encode no frame corruption coused by Hardware Decoding visible to me

Useing H264info Alpha 16 changeing Level to 3.1 fixes all of the stuttering Bitstreams (so all of those playback fine now)

grimm_all-bref_b1r1.264 <- OK
grimm_all-bref_b1r2.264 <- OK
grimm_all-bref_b2r2.264 <- OK
grimm_all-bref_b2r3.264 <- OK
grimm_all-bref_b3r3.264 <- OK
grimm_conventional_b3r1.264 <- OK (after changeing level to 3.1)
grimm_no-bref_b3r1.264 <- OK (after changeing level to 3.1)
grimm_no-L1_b3r1.264 <- OK (after changeing level to 3.1)
grimm_pyramid_b3r1.264 <- OK (after changeing level to 3.1)

I think this is a more efficient way too look for interoperability between X264 and Hardware Decoding doing this via a Directshow based Player like Mplayer Classic and Haali or other Parser (embedding the bitstream into MKV/Mp4/AVI) connecting to Cyberlinks Decoder or others (will most probably result in problems, because of the differences how they are designed and like each other)
100% interoperability between them can't be guranted so it's more efficient to use 1 Framework by a company that is established with their Products and has to addhere to the Standard for them and Cyberlinks Player does play every Standard conform Bitstream (HD-DVD,Blu-Ray) it seems within it's own Framework and in Combination with Nvidias/ATIs Hardware Accelleration APIs)

[UsedUser]

I think this is a more efficient way too look for interoperability between X264 and Hardware Decoding doing this via a Directshow based Player like Mplayer Classic and Haali or other Parser (embedding the bitstream into MKV/Mp4/AVI) connecting to Cyberlinks Decoder or others (will most probably result in problems, because of the differences how they are designed and like each other))
Well, it's disconcerting that we've arrived at contradictory results using the same decoder (Cyberlink) and same hardware (NVIDIA 8800GT).

However, I've gotten the same results despite the container (testing raw AVC, MKV, MP4), and despite the player (ZoomPlayer, MPC HC, or PowerDVD).

If a clip shows corruption, it shows corruption in the same way, at the same time, no matter the container or player.

I did test the previous clips with an ATI HD2600 and saw similar corruption results. I will have to test these new clips to see if the results are consistent.

[CruNcher]

Mabye there are differences in the Quality between G92 Chips and their BSP/VP2 Core (would be bad, but i doubt it). Or maybe your problems arise because of Mainboard Chipset problems (so something with the data transfer of the bitstream to the card goes wrong, to slow or gets corrupted on the way to the Core, defective Memory ?, overclock problems?).
Such Problems could pretty well exist i remember the non 100% compatible Via Chipsets to the PCI standard back in the 90s :)
Btw i knew this would happen, more and more people are coming and reporting about Hardware Decoding Problems, but most probably alot of them are guys that have bad non standard complaint bitstreams so suffer from the num_ref_frame problem or level_idc flag problem.
To tell most of those that probably all their streams are useless and need to be reencoded (for some generations of Hardware) especialy those that suffer from the num_ref_frame problem is hard :(

A Mod should made a Sticky and send those people into this thread or they gonna swap all around the board about Hardware Decoding Problems.

Hardware Decoding Problems analysed so far:
Num_ref_frame overusage = Results in a Black Screen (workaround is existing by changeing the num_ref_frame flag but no 100% fix solution most probably reencoding is needed)
level_idc flag wrong = Result is a Black Screen aswell as B-frame decoding problems resulting in either stuttering frames or desecending fps like the 20 fps bug (also has todo with Parser/Splitter/Decoder combination) (workaround is existing by changeing the level_idc flag works 100%)
Wrong --sar = Result is a Black Screen (also here a workaround is exisiting and can fix the encodes but most probably they will be wrongly displayed then on Hardware Decoders)

[akupenguin]

I added some 720p results. DPB=7 or 8 is fine. DPB=9 is too much.

I think overall, DPB=8 as a max for 720p is a better recommendation, no matter the patches. DPB=3 is generally safer for 1080p, as well.

That implies that the DPB limit is somewhat less than the max allowed by level 4.1 (in particular, that it's between 11059200 and 12441600 bytes whereas level 4.1 is 12582912), so I'd like to know exactly what it is.
Could you encode a variety of resolutions, and determine the max usable number of refs for each?
e.g. encode 1280x720 ref9, 1264x720 ref9, 1248x720 ref9, ..., until one works

[CruNcher]

Current Trunk (--bframes 0 --ref 9/10 --level 4.1 --sar 1:1)
1280x720 ref10 <- x264 [warning]: DPB size (13824000) > level limit (12582912) (sporadic block errors, still good watchable)
1280x720 ref9 <- OK

--bframes 4 --ref 9 --b-pyramid --level 4.1 --sar 1:1
1280x720 <- OK

[UsedUser]

Ugh. Well, I have to apologize. It looks like something is definitely wrong with my Nvidia 8800GT setup. I won't be testing there anymore until I get it figured out.

I had been testing everything on both my 8800GT setup and my ATI HD2600PRO setup, until the box with the ATI card had a meltdown.

Now, I've rebuilt that box and did some testing.

All the "grimm" clips look good on the HD2600. No block errors, no corruption, just framerate issues that are resolved by changing to L3.1.

I retested the experimental patches as well. Each of the three experimental patches, and the DPB patch by itself (i.e., svn-721), all showed good playback with DXVA. No corruption issues. DPB=9 @ 720p is still the max, as DPB=10 black screens. DPB=4 @ 1080p is still the max as well. But it doesn't appear that either B-frames or B-Pyramids present an issue with the DPB patch.

Looks like I was leading things in the wrong direction. CruNcher, thanks for checking against my results. I will retest every encode I made since the beginning and see what results I get.

[CruNcher]

I found another Problem with --sar and Haalis Splitter in combination with Cyberlinks Decoder, it doesn't accept the AR from .MKV files only the Bitstream SAR but when muxed in .MKV it doesn't get the Bitstreams SAR anymore (seems Haalis Splitter can't provide it to the Decoder) and so displays it as 1:1 (Directshow Problem).
Videolan and Mplayer have no problem with this they seem to Parse the Bitstream SAR also when the Bitstream is embeded in .MKV.

[shon3i]

I found another Problem with --sar and Haalis Splitter in combination with Cyberlinks Decoder, it doesn't accept the AR from .MKV files only the Bitstream SAR but when muxed in .MKV it doesn't get the Bitstreams SAR anymore (seems Haalis Splitter can't provide it to the Decoder) and so displays it as 1:1 (Directshow Problem).
Videolan and Mplayer have no problem with this they seem to Parse the Bitstream SAR also when the Bitstream is embeded in .MKV.
Yes. So i started to encode SD rips with par/dar 1:1, and resize it to for example 1024x576 if source is 720x576.

[CruNcher]

Yeah but unfortunately that won't work for my Mini-HD-DVD Project if i wan't to maintain Hardware Compatibility and Small Bitrate Resolutions (1440x1080,1280x1080), but ok the question remains if i ever take the bitstream into .MKV after that, most probably then MP4 or let it stay in EVO and that should work allways without problems :) Hmm strange with the Overlay Mixer it works but as soon as you go Fullscreen baam 1:1.

Edit: This really gets over strange now with Overlay Mixer even streams playback that showed a Black Screen before, jesus alot in this regards is messed up with Haalis Splitter and Cyberlinks Decoder, ahh ok no real hardware acceleration then Video: YUY2 1920x1088 (16:9) 29.97fps strange some work in Overlay Mixer with Hardware Accelleration some don't a real chaos :D

[shon3i]

Edit: This really gets over strange now with Overlay Mixer even streams playback that showed a Black Screen before, jesus alot in this regards is messed up with Haalis Splitter and Cyberlinks Decoder, ahh ok no real hardware acceleration then Video: YUY2 1920x1088 (16:9) 29.97fps strange some work in Overlay Mixer with Hardware Accelleration some don't a real chaos
Yes but there isn't acceleration like you say. You can disable DXVA in Cyberlink Decored with WMR 7/9 and you will get picture. Only with DXVA, black screen is showed

[CruNcher]

Yes but i would love to have the whole time Hardware Accelleration working, without thinking about either how to encode stuff correctly or about the combinations of Parser/Splitter/Renderer that allow me to achive that task, this is as unfriendly as it can get :D (and standards are normaly exactly their to prevent such interoperability problems)
The problem in this case with Matroska and Cyberlinks Decoder is that Matroska is no standard and Cyberlink doesn't support it and so the only one that can try to solve this problems is Haali himself.
I would really like to use Matroska the whole time i really like it but such stuff really makes me think of this again and not better stay with MP4 and avoid such problems entirely for all Hardware Capapble Decoders @ the moment and in the future. Also the fact that all the new Devices support MP4 nowdays is a big bonus, that's why i love Sonys PSP and the concept of portability 1 Stream just move it and play it (no reencoding), that's how everything should work :) so you can watch your SD AVC encode on your PC,PS3 and just take it on the go to your PSP without doing anything (thats user friendliness) (and im happy that UMD failed so horribly or we for sure wouldn't have had this possiblity so fast) but ok that's over also now that we have on our PCs no SD anymore but HD so we have to reencode again, but therforce we have a big quality gain also for our portable devices ;)