x264 Known Hardware accelleration problems and solutions

[Dark Shikari]

On this topic, what is the actual buffer size and max bitrate required for hardware 4.1 support?

I'm seeing vastly conflicting information everywhere; the H.264 standard says the L4.1 CPB size is 62500kbits, while the MeGUI profiles have both 9000 and 14475, and max bitrate seems to vary wildly between 25000 and 50000 (!?).

What are the actual correct numbers?

[shon3i]

I have same dilemma, but it seems MeGUI SA-HD-DVD profiles work correctly with hardware players.

I compare two streams:

x264 SA-HD-DVD profile:



Elecard BluRay HD AVC profile:



EDIT: But Elecard HDDVD AVC profile have VBV at 15098880

[CruNcher]

@Dark Shikari
a funny thing is for HD-DVD those buffer data seem to be confidential and only known by those who read the NDAed Specs for it and they aren't allowed to make them public, tough i think they gonna be revealed soon now that HD-DVD is about to virtualy die

[highjds]

Help me T..T

--------------------------------------------------------------------------------

Hi !!

I wishes that we should understand although my English is awkward.

I'm living in South-Korea and use the megui currently.

I do ripping for collection and store.

I read DXVA encoding article some time ago.
(x264 + more than 4 ref frames = no DXVA or 20fps bug (ati avivo, nvidia purevideo)

Change the option in the megui is difficult to me.
I want to turn off the option not to be display in the information for a 'me-prepass = 0'.
And, We are marked by qcomp=1.00 after encoding.

Will I get DXVA Profile's file though I am sorry?

I want the profile of the option like below.
Your aid is urgent me. Please!!!

My E-mail : highjds@naver.com

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-681
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:-3:-3
User data: analyse=0x3:0x133
User data: me=umh
User data: fpel_cmp=sad
User data: subme=6
User data: me-prepass=0
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=2
User data: deadzone=10,10
User data: chroma_qp_offset=0
User data: threads=3
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=5621
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=1:0.7:15.0
SPS id: 0
Profile: High@L5.1
Num ref frames: 8
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Custom intra4X4 luma:
6 7 10 16
7 7 11 17
10 11 12 20
12 13 20 16
Custom intra4X4 chromau:
16 16 16 16
16 16 16 16
16 16 16 16
16 16 16 16
Custom inter4X4 luma:
10 13 28 41
13 14 32 84
28 32 41 111
41 46 111 16
Custom inter4X4 chromau:
16 16 16 16
16 16 16 16
16 16 16 16
16 16 16 16
Custom intra8X8 luma:
9 9 10 10 11 16 21 29
9 9 10 10 11 16 21 29
10 10 10 10 11 16 22 31
10 10 10 11 11 17 23 33
11 11 11 11 11 19 25 36
12 12 13 13 14 20 27 40
15 15 16 16 21 27 31 45
20 20 21 22 36 40 45 16
Custom inter8X8 luma:
12 13 15 18 20 70 163 255
13 13 16 18 20 72 170 255
15 16 17 19 21 81 190 255
18 18 19 21 23 96 228 255
20 20 21 23 25 120 255 255
33 34 36 39 45 32 255 255
64 66 71 80 164 255 255 255
151 155 169 192 255 255 255 10

[tetsuo55]

Has anyone tested non standard mod16 width's??

Something like 1600x720?

So to create a 100% compatible file:

-use the latest svn revision of x264
-use a SAR of 1:1/4:3/5:4/16:9
-For resolutions higher than 720x576
--mod16 width X mod16 height X ref frames <= 8355840
-For resolutions equal or lower than 720x576
--mod16 width X mod16 height X ref frames <= 4561920

other settings do not seem to matter

[UsedUser]

Originally Posted by tetsuo55

im trying to change the ref frames to 7 on this height edited sample

Originally Posted by tetsuo55

The point here is to find out why 90-100% compliant files do not get DXVA acceleration, most of the files i am testing here conform to all the DXVA specs but do not get accelerated, i'm simply trying to find out why. By changing certain things with h264info the problem can either be solved or the real issue found. This might even lead to another incompatible feature being found, even if it doesnt, the guide to fixing existing encodes can be updated with more fixes.

Originally Posted by KoD

Ok, I get your point. But you need to get mine, too. Simply changing the label is not going to make the content the chips receive any different than before changing it. Saying in the label the frame is now 1280x544 does not change the fact the chip receives a 1280 x 536 frame to decode. Saying in the label the stream uses only 7 reference fames does not change the fact the chip receives a stream which has more than 7 reference frames in certain spots. If the chip did not like it before, it's not going to like it now either despite what your advertisement (label) said.

While there is value in determining what in a stream's header makes a particular decoder refuse to decode the stream, it is important to note that figuring that out, in some situations, may be fruitless.

What I mean to say is, changing the num_ref_frames by editing the header doesn't actually change the DPB required by the stream, so (as KoD pointed out), it doesn't ultimately help anything. While you may discover that the decoder is checking the stream header for num_ref_frames, it is doing so for a reason, because even if you get the decoder to successfully decode the stream, you get errors because it is, in actuality, out of spec with L4.1. The actual num_ref_frames for a stream cannot be changed by simply editing the header.

On the other hand, --level is not often specified when using x264, and as a result, the encoder defaults to labeling the stream L5.1 (presumably because it is safe to say any stream under L5.1 will also comply with L5.1). So, you get streams that comply with L4.1 in DPB size and other parameters, but are labeled L5.1. Editing the header to change the level_idc label to L4.1 is all that is required to get the decoder to decode successfully without errors.

Overall, you may expose what parameters the decoder is checking for, but it doesn't change the fact that level_idc is editable, and it is on you to ensure the stream complies with the label you give it, while num_ref_frames is not editable. DPB size is a hard requirement.

[tetsuo55]

Originally Posted by UsedUser

snip

I'm sorry but you are wrong, except for those clips i have that have ref frames that are way out of bounds, all my previously non working files work now. (although some have a line of artifacts below the rendered image, but this does not always appear, and its basically a dark grey line)

My testing reveals that decoders only check the packet header, and then let the videocard decode whatever is inside if it passes the required checks. after that it becomes obvious that only a too high number of ref frames causes any real problems with the playback (artifacts, stuttering, 20fps)

[CruNcher]

Originally Posted by tetsuo55

I'm sorry but you are wrong, except for those clips i have that have ref frames that are way out of bounds, all my previously non working files work now. (although some have a line of artifacts below the rendered image, but this does not always appear, and its basically a dark grey line)

My testing reveals that decoders only check the packet header, and then let the videocard decode whatever is inside if it passes the required checks. after that it becomes obvious that only a too high number of ref frames causes any real problems with the playback (artifacts, stuttering, 20fps)

Tough the Dark Grey line is because that file wasn't mod16 encoded and you forced it to be mod16
And i allready made clear that changing this num_ref_frames for what tetsuo55 describes as "out of bounds" encoded streams will couse visual problems in most hardware decoders and even in software you gonna see the same problems then changing the num_ref_frames, but this was just thougt as a workaround for acceptable Visual error rates (and maybe hardware decoder that can handle it) and if one can't live with this he could still retranscode it (wich is of course the prefered method to handle such out of spec streams)

[tetsuo55]

Indeed, the best solution is to re-encode, especially with a new AQ patched SVN build

By the way, does anyone know a solution to this related DXVA problem? its a problem with remuxing MPEG2 streams: http://forum.doom9.org/showthread.php?t=134615

(i think MKV and haali splitter might still have a lot of DXVA incompatibility issues)

[UsedUser]

Originally Posted by tetsuo55

My testing reveals that decoders only check the packet header, and then let the videocard decode whatever is inside if it passes the required checks. after that it becomes obvious that only a too high number of ref frames causes any real problems with the playback (artifacts, stuttering, 20fps)

That's exactly what I said. You can get the decoder to decode the stream, but it's still out of spec, so you get errors (artifacts, stuttering, 20fps, etc). Which is in contrast to tightening the IDC label to inform the decoder the stream is actually in spec.

So, if you don't get a properly decoded stream, again, it's essentially fruitless. Sure you can get DXVA, but how is that superior to software decoding if it's fraught with errors? Perhaps some are minor, but at least for me, the goal here was to get DXVA for an intact stream.

[tetsuo55]

Originally Posted by Dark Shikari

On this topic, what is the actual buffer size and max bitrate required for hardware 4.1 support?

I'm seeing vastly conflicting information everywhere; the H.264 standard says the L4.1 CPB size is 62500kbits, while the MeGUI profiles have both 9000 and 14475, and max bitrate seems to vary wildly between 25000 and 50000 (!?).

What are the actual correct numbers?

this is indeed very interessting info

Could someone encode some test samples??

20 seconds video or something

1 with a CPB size of 62500kbits, other settings same as we use for DXVA compatibility
2 with a CPB size of 14475kbits, other settings same as we use for DXVA compatibility
3 with a CPB size of 9000kbits, other settings same as we use for DXVA compatibility
4. bitrate of 50000, other settings same as we use for DXVA compatibility

if 4 doesn't work try 25000, if that does we could up it until the limit is found


What i know about blu-ray/HDDVD benchmarks 50000 is the max for these disc's standard. some discs have already been released which are well over the 40000, it would be interesting to find the real upper limit, keep going up if 50000 works


-------------------

Again, its clear now that as long as you keep SAR. ref frame limit and mod16 x264 creates a DXVA compatible file, the only thing thats not completely clear is that if pyramids does or doesn't break compatibily on standalones and consoles(ps3/xbox360)

It would be nice to see an option in x264 or frontends that auto-selects the maximum number of ref frames based on the resolution with a -hardware or -dxva switch

[akupenguin]

You have to determine max bitrate before you can experiment with CPB. Because if you disagree with the decoder about what speed the CPB is filling, then you'll disagree about its fullness. But you don't need to know CPB to test bitrate, assuming your sample is long enough to overflow any reasonable CPB if bitrate is too high.

[shon3i]

Originally Posted by tetsuo55

It would be nice to see an option in x264 or frontends that auto-selects the maximum number of ref frames based on the resolution with a -hardware or -dxva switch

Or automaticly make decision based on resolution and framerate. I don't see point to somebody now encode with high level than should.

[CruNcher]

Mod please sticky this and rename it to something like (Known Hardware accelleration problems with X264)

[ggab]

and could anybody make a litle sumary post? (collecting the facts about you should care about doing your own DXVA enable's encodes)

thnks

[tetsuo55]

Originally Posted by ggab

and could anybody make a litle sumary post? (collecting the facts about you should care about doing your own DXVA enable's encodes)

thnks

I updated the first post.

However i still think that x264 or the frontends should auto calculate the correct settings now that we know all the facts (besides max bitrate and CPB)

[CruNcher]

Also everyone should be aware that X264s VBV is not 100% standard complaint yet so it could fail in alot of situations so even if you take care there's no guarante that it works 100% with every device in every situation im afraid.

[tetsuo55]

what VBV? and what seems to be the problem with it?

[CruNcher]

it's the Video Buffer Verifier it's there to control to heavy bitrate spikes and hold everything constant so Hardware Decoders have no problems to decode a stream (complexity) and it's clearly in the Spec how a stream has to look like in terms of bitrate complexity for every level (some devices have their own VBV also it's called CPB i think Coded Picture Buffer specs, HD-DVD and Blu-Ray)

[UsedUser]

I have a little time to execute some test cases, but I'm not very knowledgeable about CPB. I've picked up from CruNcher that VBV is synonymous with CPB. I'm not sure, though, if we're talking about max bitrate or VBV max bitrate, or if they should correspond.

Are these what I should be testing? What am I looking for (breaking DXVA (software decoding), stuttering, picture corruption)?

Baseline:

--pass 2 --stats ".stats" --level 4.1 --bframes 3 --weightb --direct auto --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct

Plus these additional settings:

Establishing max bitrate:
1. --bitrate 62500 --vbv-maxrate 62500
2. --bitrate 50000 --vbv-maxrate 50000
3. --bitrate 25000 --vbv-maxrate 25000
4. [lower or higher values to nail down max bitrate]

Establishing max VBV size (let [maxrate] = the max bitrate determined above):
1. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize [maxrate]
2. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize 25000
3. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize 14475
4. --bitrate [maxrate] --vbv-maxrate [maxrate] --vbv-bufsize 9000