x264 Known Hardware accelleration problems and solutions

[shon3i]

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 (and standards are normaly exactly their to prevent such interoperability problems) That will be nice :D really but Cyberlink decoder is restricted as you know.

Combination mkv->cyberlink is prue horror now :D

[Atak_Snajpera]

Finally b-pyramid is working on PSP. However I've noticed one corrupted frame when the thunder hits the tree.
http://www.mediafire.com/?dxdytdmddzk

Everything is fine without b-pyramid
http://www.mediafire.com/?0mmu111invm

[CruNcher]

Finally b-pyramid is working on PSP. However I've noticed one corrupted frame when the thunder hits the tree.
http://www.mediafire.com/?dxdytdmddzk

Everything is fine without b-pyramid
http://www.mediafire.com/?0mmu111invm

Playing those 2 in Hardware Mode on Nvidia via Cyberlink for both the FPS slows down after 7 seconds of playback (it drops suddenly from 24 down to 17 and goes lower and lower) i don't like that. Have to check more carefully whats couseing this. (Useing MPCHC standard MP4 Parser gonna try Haalis).

Drag and Drop into PowerDVD shows the same deacerllerating playback speed problems after 7 seconds so it seems no parser problem @ all. (I would guess level is wrong it looks like the same problem as the continuis 20 fps playback problem just that the fps is constantly droping down over time (maybe when hitting b-frames?). (Or Mp4box is buggy and does something wrong, wouldn't suprise me really :P) gonna check the bitstream.

Bitstream alone shows no playback Problems in Hardware Mode. Muxing with Mp4creator and Mp4box with and without sound and gonna check again ;)


I:\test>mp4creator -create=logo.h264 -rate=23.976 test.mp4
Error decoding sei message

hmmm

ok worked anyways but still decreasing the fps, looked @ the bitstream and the only thing i can see is that their are 2 pp following after a sequence of pbpbpbpbpbpb but could be also pure accident that it slowdown @ the same time as those 2 pp appear in the stream, as the bitstream alone has no playback problems inside of PowerDVD with Hardware accelleration

@UsedUser could you confirm this Problem with your Nvidia Card and Cyberlinks Decoder in combination with Atak_Snajperas Samples please, i also wrote something allready about this decreasing fps problem when i still had my 7600 GS and i think i found a strange workaround @ that time for it , note the decreasing fps also happens with this stream in any other container.

[shon3i]

Playing those 2 in Hardware Mode on Nvidia via Cyberlink for both the FPS slows down after 7 seconds of playback (it drops suddenly from 24 down to 17 and goes lower and lower) i don't like that. Have to check more carefully whats couseing this. (Useing MPCHC standard MP4 Parser gonna try Haalis).

I have this problem only when i use wrong level. For example when i use level higher than 3.1 for SD (720x576)

[CruNcher]

Nope the problem is another and i found a workaround i think allready for this @ the time it had todo with direct_pred mode

http://forum.doom9.org/showthread.php?t=124945
http://forum.doom9.org/showthread.php?t=127712


EDIT: OK i hope once and forall i found it, it seemes to be the direct_pred option that couses trouble with Cyberlink and PV1 DXVA i found a workarround by useing temporal but after creation of the .mp4 in either avidemux or mencoder it is damaged even if you use temporal prediction you have to first extract the raw stream (from the corrupted .mp4 you get from avidemux/mencoder (it might look ok but it isn't not for the combination of Haali Spliter and Cyberlink Decoder)) with yamb (mp4box) for example and create a new .mp4 this fixes the slowdown problem with Cyberlink once and for all if your stream was set on direct_pred=none/spatial/auto then you won't be able to mux the demuxed raw stream correctly with mp4box again it will end with a damaged .mp4 (not finished) direct_pred=temporal is the only way that i found that avoids this slowdown and remuxing problems with mp4box :) (FINALY)


Im not sure if that really was the problem but @ that time it fixed those slowdowns and i know it was a PAL sequence that i had problems with so the resolution of the stream is not the problem

@Atak_Snajpera
could you redo this sample useing --direct temporal :)

[Atak_Snajpera]

The result is even worse in this clip. At the end you will see nice dancing blocks :)

http://www.mediafire.com/?a0j0tgqzbid

[shon3i]

Nope the problem is another and i found a workaround i think allready for this @ the time it had todo with direct_pred modeI am not sure, because i saw this problem first time when i encode with Elecard Converter Studio 2.0. When i do a single pass VBR everything was fine, but when i do two passes, clip got 20fps bug. I dont know how to change prediction mode in elecard.

btw in Ateme Digital Serie by default is temopral selected, and with ateme i don't have any problems with DXVA

[CruNcher]

No no the problem isn't the 20fps bug its much much worse then that, the Framerate is decreasing constantly after about 5 seconds of playback with Cyberlinks Decoder, that's much much worse then if it would just playback constantly @ 20 fps :), but only in .MP4 .MKV useing Cyberlinks Decoder over Directshow not with the Bitstream itself in Cyberlinks PowerDVD. But also with Mainconcepts Bitstream parser via Directshow and Cyberlinks Decoder (only allways in Hardware Decoding Mode).

@Atak_Snajpera
Yep and it's still decreasing so that isn't the problem (i slowly belive this is either an VBV problem or Cyberlinks Decoder is somehow bugged with this kind of streams when reading them from a container but dunno why this is the case, but it's really the worst case scenario for Hardware Playback via Cyberlinks Decoder and DXVA) Looking @ the stream again i see this 2 pp frames exactly @ the time the problem seems to beginn hmmm (could be also just pure coincidence tough).

http://s6.directupload.net/images/080123/o869sqtb.png


Could you please post the complete encoding settings and all stuff you used to create this stream (Encoding/Muxing) :)

Also i would really like to know if ATIs UVD Decoder shows the same problems with Cyberlinks Decoder in Hardware Mode with this clip.

Could you also please cut a longer version it's hard to see what's happening in Cyberlinks PowerDVD with the MP4 i think it's not the same whats happening in a Directshow Player tough i can see that some Frames go missing, but i can't see the extreme FPS decrease it's going to fast black and i can't be sure that the fps would decrease over the whole time of the playback as it does in a Directshow Player. In MPCHC i'ts very obvious to identify that the FPS is constantly decreasing as playback is very fast slowdowned.

With Hardware Decoding Enabled (Cyberlink Decoder,VMR9 Renderless)

http://s2.directupload.net/images/080123/iebss9mt.png

The FPS is constantly decreasing from 23-24 fps after around 5 secs

Hardware Decoding Disabled (Cyberlink Decoder,VMR9 Renderless)

http://s5.directupload.net/images/080123/qzj8oowo.png

Everything is fine

I tried it with all Mp4 Splitter (Internal Mp4 Splitter,Mainconcept Mp4 Demultiplexer, Haali, Cyberlink-7 Mpeg-4 Splitter) allways the same result in Hardware Mode :(

[Atak_Snajpera]

I was talking about playback on PSP not PC.

[CruNcher]

Yes but this is also Hardware Playback and that problems are visible here means there could be problems visible on other Devices (in wich form they showup is another thing).
If X264 is not full hardware compatible then you will get errors in many forms on many devices and those don't have to be the same problems.

So please post your settings and the exact way you created this stream also wich tool you used for muxing, and if possible a longer sample that has some other frames where you could see slowdowns visually :), also try to use VBV and see if that fixes your problems on the PSP (im gonna test on my PSP as soon as i have updated it with the latest M33 firm, didn't used it for a long time now)

But yeah i suspect that this decreasing FPS problem is more a Cyberlink Decoder in combination with Splitter problem than a X264 hardware problem, but i wan't to know wich settings causeing this decreasing fps behaveiour with Cyberlinks Decoder and certain X264 streams :)

[shon3i]

No no the problem isn't the 20fps bug its much much worse then that, the Framerate is decreasing constantly after about 5 seconds of playback with Cyberlinks Decoder,Yes i was talking and mean about same problem, but i use word "20 fps bug". Framerate is vary, but i realy don't know maybe some bug in elecard. This is happens only when i use two pass encoding.

[tetsuo55]

Thanks to MPC HC i have now 100% dxva decoding from some files, other files do not work, it really does not matter what the resolution is, does anyone know of a tool that can analyze the mkv files and tell me what encoding options where used or something? so i can at least find out what went wrong?

[Dark Shikari]

Thanks to MPC HC i have now 100% dxva decoding from some files, other files do not work, it really does not matter what the resolution is, does anyone know of a tool that can analyze the mkv files and tell me what encoding options where used or something? so i can at least find out what went wrong?Running unix command "strings" on the file will display the x264 header with all encoding options used.

[tetsuo55]

Running unix command "strings" on the file will display the x264 header with all encoding options used.

That wont work in windows directly, do i need to add it as a switch to a x264.exe or mkvgui.exe??

[professor_desty_nova]

Thanks to MPC HC i have now 100% dxva decoding from some files, other files do not work, it really does not matter what the resolution is, does anyone know of a tool that can analyze the mkv files and tell me what encoding options where used or something? so i can at least find out what went wrong?

Have you tried AVInaptic? (search the forums for it :) )

Here is an example of the output it gives:

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-680
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=3
User data: deblock=1:0:0
User data: analyse=0x1:0x111
User data: me=hex
User data: subme=4
User data: brdo=0
User data: mixed_ref=0
User data: me_range=16
User data: chroma_me=1
User data: trellis=0
User data: 8x8dct=0
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=1
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=0
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=0
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40
User data: rc=abr
User data: bitrate=268167020
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: ip_ratio=1.40
User data: pb_ratio=1.30
SPS id: 0
Profile: Main@L5.1
Num ref frames: 4
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: No

[audyovydeo]

That wont work in windows directly, do i need to add it as a switch to a x264.exe or mkvgui.exe??

You could also instal Cygwin, and make Windows more bearable.
Much more useful interface than Vista, believe me ;-)



cheers
audyovydeo

[tetsuo55]

thanks, can someone explain why file 1 does not work with dxva. and file 2 does
file 1(does NOT work with DXVA)
[ About H.264 encoding ]

User data: x264
User data: core 56 svn-677
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:0:0
User data: analyse=0x3:0x113
User data: me=umh
User data: subme=7
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=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=6
User data: nr=0
User data: decimate=1
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=5970
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
SPS id: 0
Profile: High@L4.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


file 2 (works with dxva)
[ 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

[audyovydeo]

thanks, can someone explain why file 1 does not work with dxva. and file 2 does


mmmh, one is Level 4.1 , two is 5.1.
If you encode two @4.1, what gives ?

cheers
a/v

[CruNcher]

resolution?
also look @ the build's could be mvrange or most probably num_ref_frames problem which i supose
core 56 svn-677
core 56 svn-681

[tetsuo55]

Yeah, i use a decoder that ignores the level, so in this case thats not the problem (besides the level5.1 file is the one that actually works)

[tetsuo55]

resolution?

sorry, both files are the same
[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 1280 x 720
Frame aspect ratio: 16:9 = 1.777777
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 16:9 = 1.777777
Framerate: 23.975986 fps

[CruNcher]

unlikely that it's a num_ref_frames problem then so only wrong mvrange is left, but for software decoder this should be no problem hardware are very likely to fail playing back this stream and i don't see how it could be fixed or workarround to make it working :( and the last option then i think would be reencoding unless something else ist the problem which i might don't see yet. What's the Device (chip) on which you try to playback the Stream?. But i also don't know how a wrong mvrange should pretend the stream from being played back @ all it's not saved in the bitstream so no way possible for the Device to know how it was encoded before playing it back and only then errors should become visible. To my knowledge so far only wrong SAR, wrong num_ref_frames, wrong level_idc could pretend Hardware playback completly (black Screen) under certain circumstances.

[tetsuo55]

i am using MPC HC as the decoder

Hardware is : ATI HD2400pro, cat 7.12, reg entries for full hd applied

decoding style used is: bitstream, no FGT

[CruNcher]

Hmm did you tried also Cyberlinks Decoder in Hardware mode do you get the same results with it?
hmm also i realized now that the threads are different and i could think that a slice decoding problem might also couse problems i saw that with MPC HC Decoder and Apples Slice Encoded streams happening they get borked (most of the times only 1 part of the slice is played back), but im not sure how this old X264 rev worked and if there where any bugs in that regard :( hmm could you repeat the same encoding with the same exact settings on a new SVN build, hopefully it will playback then. But trying first with Cyberlinks Decoder is generaly a good idea, because MPC HC DXVA Decoder is still buggy as mentioned above (Quicktime Problem).

[tetsuo55]

EDIT: cyberlink gives me the same results

[CruNcher]

Ok then i would ask you even if it sounds silly to use Trahalds newest h264info on the file 1 bitstream and change it's num_ref_frames to 7 :P and try to playback it again.

[tetsuo55]

Ok then i would ask you even if it sounds silly to use Trahalds newest h264info on the file 1 bitstream and change it's num_ref_frames to 7 :P and try to playback it again.


IT WORKED. the stream has been fixed!!

wierd, simply remuxing the original stream fixes it too

[CruNcher]

yep also my experience with some streams just remux them or rebuild them (without any of the options changed) and suddenly they work, it's a strange world (full of bugs) ;)

[nautilus7]

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-677
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:0:0
User data: analyse=0x3:0x113
User data: me=umh
User data: subme=7
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=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=6
User data: nr=0
User data: decimate=1
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=5970
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
SPS id: 0
Profile: High@L4.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

Can you explain me how to set avinaptic to show these info? I tried 2 .mkv (x264) files, but didn't get these info (encoding parameters).

[tetsuo55]

i just used: file > open

and the version is: avinaptic-20071118-full-fixed

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

Well i checked all my files, they all fall within the ref frames limit.

I am going to try and remux them all to new mkv's, then if i find any streams that still do not work i will try the h264info 7 ref frames and level 4 trick. I'll post results later

[jamos]

I'm seeing the following settings for the PS3 profile:

--level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid

It includes >2 b-frames, adaptive b-frames, and b-frame pyramids, all of which have been noted for their potential to break DXVA. Unless someone has already tested them @ 1080p + num_ref_frames < 5?

I know that if the num_ref_frames < 5 even with the above options it will play back fine on a PS3 or my computer in 1080p.

[CruNcher]

i just used: file > open

and the version is: avinaptic-20071118-full-fixed

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

Well i checked all my files, they all fall within the ref frames limit.

I am going to try and remux them all to new mkv's, then if i find any streams that still do not work i will try the h264info 7 ref frames and level 4 trick. I'll post results later

great tetsuo55 awaiting your report :)

@jamos
yes i don't know how the PS3 works but maybe it's useing the same way the xbx360 does and has 2 specific decoder functions 1 for customer content (the dashboard AVC/VC-1 decoder) and 1 for comercial content (HD-DVD Decoder) seeing a little into all this AVCHD and the different types of content even signaled in the .EVO format makes me belive that since HD-DVD and Blu-Ray customer content get's strictly cuted of from commercial content and almost every device detects that, might be thought as a way to protect the Hypervisor and HDCP from being exploited in the early days ;).

[nautilus7]

Same here. Then i suppose it has to do with the file.

[UsedUser]

Running unix command "strings" on the file will display the x264 header with all encoding options used.
Though I prefer the ease of AVInaptic, particularly because it tells you right out the num_ref_frames, there is also SysInternals strings (http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx) for Windows. Does essentially the same thing.

I know that if the num_ref_frames < 5 even with the above options it will play back fine on a PS3 or my computer in 1080p.
A little late to the game with that one. :)

It is now down to one feature, as long as L4.1 compliance is followed, that may disrupt DXVA: b-pyramid.

[tetsuo55]

Setting ref frames to 7 and changing the idc to 4 made this file playable, but its choppy and crashes the pc

Original data, my guess is the 10 ref frames are killing this one
[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 1280 x 720
Frame aspect ratio: 16:9 = 1.777777
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 16:9 = 1.777777
Framerate: 23.976024 fps

[ About H.264 encoding ]

User data: x264
User data: core 56 svn-682C
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=7
User data: deblock=1:0:0
User data: analyse=0x3:0x133
User data: me=umh
User data: fpel_cmp=sad
User data: subme=7
User data: me-prepass=0
User data: brdo=0
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=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=6
User data: nr=0
User data: decimate=1
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=240
User data: keyint_min=24
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=5521
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
SPS id: 0
Profile: High@L4.1
Num ref frames: 10
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

[CruNcher]

yep for that one it's better to reencode or just watch it with a Software Decoder but be aware changing num_ref_frames will also make those problems visible in Software Decoding so leave it in that case where it is :)

[tetsuo55]

Okay here is another file

Remuxing >> still no dxva
Changing idc to 4 and 7 ref frames with h264 info >> still no dxva

Original file info:

[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 1280 x 536
Frame aspect ratio: 160:67 = 2.388059
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 160:67 = 2.388059
Framerate: 23.976043 fps

[ About H.264 encoding ]

User data: x264
User data: core 57 svn-709C
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=0
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=1
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=6011
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

[CruNcher]

Resolution isn't mod16 that's gonna fail on most devices it has a reason why HDTV is transmited in 1088 ;) and cores like Nvidia upscale it to that if they get 1080 tough for custom resolutions this might not work correctly also on ATIs core. You could try to use the Size feature in h264info to change the height to a mod16 resolution maybe it works then :). Also X264 should have warned you when encoding this that it isn't mod16 and could couse problems.

[tetsuo55]

changing it to 1280x544 failed, avinaptic says its a mod32 height, that should be okay right?
im trying to change the ref frames to 7 on this height edited sample

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

EDIT:

ref frames 7 didnt help either, so unless 544 is still a wrong height then there has to be something else wrong with this file

[KoD]

changing it to 1280x544 failed, avinaptic says its a mod32 height, that should be okay right?
im trying to change the ref frames to 7 on this height edited sample

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

EDIT:

ref frames 7 didnt help either, so unless 544 is still a wrong height then there has to be something else wrong with this file

If you take a clay statue and attach a label "Made of gold", do you think the statue suddenly turned into a gold statue ?

[KoD]

changing it to 1280x544 failed, avinaptic says its a mod32 height, that should be okay right?
im trying to change the ref frames to 7 on this height edited sample

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

EDIT:

ref frames 7 didnt help either, so unless 544 is still a wrong height then there has to be something else wrong with this file

If you take a clay statue and attach a label "Made of gold", do you think the statue suddenly turned into a gold statue ?

How about making the statue out of gold from the beginning, which in your case means reencoding the video stream with parameters that hardware chips can handle. These parameters have already been posted before.

[tetsuo55]

If you take a clay statue and attach a label "Made of gold", do you think the statue suddenly turned into a gold statue ?

How about making the statue out of gold from the beginning, which in your case means reencoding the video stream with parameters that hardware chips can handle. These parameters have already been posted before.

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.

[CruNcher]

Yep take that stream aside now tetsuo55 and go on we must suspect for now that the resolution is the problem, waste not to much time on 1 sample, keep on.

[KoD]

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.

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.

[CruNcher]

Kod that's wrong what you say some Players wan't to know first what the Bitstream says and if it the Parser of the Player doesn't like the info it get's from the Bitstream it will not even start playing it back (even if it could with some visual problems). And check your PC you allways double post ;)

[tetsuo55]

yeah some players block on headers, it was the resolution after all, as soon as i fixed the resolution the file worked :)

however the resolution i tried initially was incorrect

[tetsuo55]

Okay i have my results:

Non working files fail for one of 3 reasons:

1. too many ref frames
2. non-mod16 resolution
3. container problems

There are also 3 solutions to get the file accelerated

1. change ref frames to 7 with h264info, however most of the time this will cause corrupt frames, better to re-encode
2. Change the resolution to a mod16 resolution with h264info, sometimes this causes a colored line beneath the image, no other problems
3. Remux the streams with the latest version of the container-muxer

As you can see from my results, any file can be forced to be decoded by hardware, its only the h264 header the decoder looks at not the actual stream.

now the qustion remains, many video's are not mod16 when the black bars are fully cropped, what is the best way to both keep mod16 but also to not have a wrong size black bar that interfers with the encoding process?

[foxyshadis]

Resize in or out a tiny bit. I don't care if it's under a 5% AR error, which is most peoples' threshold. Some can't even tell with 10% or 20%, you know because they watch uncorrected anamorphic. :p You can also mirror out the first/last line or two.

Will it work with a mod-8 but non-mod-16 resolution? Add a little mirroring to the chroma without affecting the luma.

[CruNcher]

Okay i have my results:

Non working files fail for one of 3 reasons:

1. too many ref frames
2. non-mod16 resolution
3. container problems

There are also 3 solutions to get the file accelerated

1. change ref frames to 7 with h264info, however most of the time this will cause corrupt frames, better to re-encode
2. Change the resolution to a mod16 resolution with h264info, sometimes this causes a colored line beneath the image, no other problems
3. Remux the streams with the latest version of the container-muxer

As you can see from my results, any file can be forced to be decoded by hardware, its only the h264 header the decoder looks at not the actual stream.

now the qustion remains, many video's are not mod16 when the black bars are fully cropped, what is the best way to both keep mod16 but also to not have a wrong size black bar that interfers with the encoding process?

Non working files fail for one of 5 reasons:

1. too many ref frames
2. non-mod16 resolution
3. container problems
4. wrong Sar (only allowed are 1:1/4:3/5:4/16:9)
5. wrong Level (5.1 will fail most of the times better use for most HD content 4.1 SD content 3.x)

There are also 5 solutions to get the file accelerated (decoded)

1. change ref frames to 7 with h264info, however most of the time this will cause corrupt frames, better to re-encode
2. Change the resolution to a mod16 resolution with h264info, sometimes this causes a colored (or gray) line beneath the image, no other problems
3. Remux the streams with the latest version of the container-muxer
4. Change the Sar with h264info
5. Change the level_idc with h264info

[microchip8]

Hi,

Maybe a bit off topic, but does anyone knows the vbv_maxrate and vbv_bufsize for compliant SD streams (@L3.1) so they will be playable on stand-alone HW players?