View Full Version : DXVA - How to tell if it's really working?
Dal
5th August 2010, 08:34
Hi, I'm not sure this is the right place to post this, feel free to move it where it belongs.
I use MeGui to encode SD streams (from DVBViewer) into h264 format, using the DXVA profiles in MeGui.
MediaInfo gives me this info about one of the files (it is inside a mkv container):
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@3.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 11mn 9s
Bit rate : 1 494 Kbps
Width : 544 pixels
Height : 400 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.275
Stream size : 117 MiB (85%)
Writing library : x264 core 104 r1677 19df41a
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1494 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=17500 / vbv_bufsize=14000 / ip_ratio=1.40 / aq=1:1.00 / nal_hrd=none
Is the Level setting and ReFrames correct for this resolution?
But how can I tell that hardware acceleration is really used when playing those files?
I haven't come across an easy way to show this.
Usually, I use Zoom Player (with PowerDVD Decoder v8 and v10).
I see that PowerDVD is in use, but I haven't found a way to see if it actually uses hardware acceleration to play the file.
So is there a program to detect this? Some other player maybe?
It would have been nice to be 100% sure if my settings are correct before I start encoding all my movies and series to a DXVA compatible format.
Thank you.
TheImperial2004
5th August 2010, 09:06
Hi .
I always AviDemux to encode using Libx264 . And "All" of my encodes are playing using DXVA under MPC-HC . Whatever encoding settings I use , it'll play using DXVA . I'm not sure about profiles though , as AviDemux won't allow me to set them .
https://9188951803476329622-a-1802744773732722657-s-sites.googlegroups.com/site/theimperial2004/capture..GIF?attachauth=ANoY7coyOii5tJdD_Zkduj-a_QnF72Sn18z2GBUT5vTVQPk4ncfQ56rM6P2kRZPVIl4ei3ZU8Z44xpVb_tnWGY5O_nn1Gx2eB6obqzFkO28CBTQWz9C49AScR5LGSPIBhsLxjMNVDvcKuRvBrg_v9ki_vkadZ7P-kkMrECVnwC4biwZ44QeUeJ8-ixYzaRkAvDTYOIIVmUNe&attredirects=0
Good luck ;)
tetsuo55
5th August 2010, 09:18
Open your task manager and check the cpu usage
for an sd file it should be near 0, for hd file between 5 and 20
nurbs
5th August 2010, 09:23
That's pretty outdated.
There are no problems with b-pyramid or a large number of b-frames.
You don't need to manually specify the number of reference frames, since as long as you set the level x264 will take care of it. Many hardware decoders (mainly GPUs and some standalones) don't care about the DPB limit of level 4.1, but it's still a good idea to keep within that limit to ensure maximum compatibility.
If you set a level don't forget the appropriate VBV settings.
TheImperial2004
5th August 2010, 09:32
That's pretty outdated.
I'll re-edit my post :) thanks for the clarification .
Edit : I encoded some samples now using various combos of settings and all of them played fine using DXVA under MPC-HC (SD & HD samples) .
Dal
5th August 2010, 11:37
Thank you all for your answers.
Open your task manager and check the cpu usage
for an sd file it should be near 0, for hd file between 5 and 20
Is this really the only way? If so, there is obviously a gap in all the fine programs available in this scene; a kind of hardware acceleraton detector :)
You don't need to manually specify the number of reference frames, since as long as you set the level x264 will take care of it. Many hardware decoders (mainly GPUs and some standalones) don't care about the DPB limit of level 4.1, but it's still a good idea to keep within that limit to ensure maximum compatibility.
If you set a level don't forget the appropriate VBV settings.
Maybe a stupid question, but what are the VBV settings?
What is the criteria for HA to kick in anyways?
Is that the level is properly set (3.1 for SD, 4.1 for HD, what is 5.1 for?) combined with the right number of ReFrames?
But x264 will take care of the referance frames now? But it wasn't always like this?
I encoded some samples now using various combos of settings and all of them played fine using DXVA under MPC-HC (SD & HD samples) .
Very nice, but how can you be *sure* that DXVA is actually in use?
Thanks again.
TheImperial2004
5th August 2010, 11:49
Very nice, but how can you be *sure* that DXVA is actually in use?
Simply , check MPC-HC status bar . It should show : Playing [DXVA] , that means your video decoding is accelerated . OR , check your task manager to see how is your CPU load . It should be near 0% for SD content and 5 - 20% for HD as tetsuo55 states . Heck , you can even use CPU-Z to check CPU load -if C1E(2) is enabled- :)
Good luck ;)
nurbs
5th August 2010, 11:50
VBV settings are the maximum rate at which the player can read (defined by the profile and level; look it up in the wikipedia H.264 article) and the buffer size on the player. The latter is generally not specified in the manual, but the rule of thumb is to use the same setting as for the maximum rate.
For SD you can use level 3.0 or higher, for 720p 3.1 or higher and above that level 4.0 or higher. If you specify the level x264 will automatically reduce the number of reference frames unless you specify a higher number manually. It didn't always do that. Most hardware players (standalone and GPU; mobile is usually more restricted) should handle level 4.1 since that is more or less what blu-ray uses.
TheImperial2004 knows that DXVA is used because MPC-HC shows "playing [DXVA]" when it is used.
TheImperial2004
5th August 2010, 11:55
TheImperial2004 knows that DXVA is used because MPC-HC shows "playing [DXVA]" when it is used.
Yup . And it doesn't show it if DXVA wasn't acually in use :)
Dal
5th August 2010, 12:06
VBV settings are the maximum rate at which the player can read (defined by the profile and level; look it up in the wikipedia H.264 article) and the buffer size on the player. The latter is generally not specified in the manual, but the rule of thumb is to use the same setting as for the maximum rate.
For SD you can use level 3.0 or higher, for 720p 3.1 or higher and above that level 4.0 or higher. If you specify the level x264 will automatically reduce the number of reference frames unless you specify a higher number manually. It didn't always do that. Most hardware players (standalone and GPU; mobile is usually more restricted) should handle level 4.1 since that is more or less what blu-ray uses.
Ok, thank you.
So what you're basically saying is that if I use MeGui as encoder and choose one of the DXVA profiles (there are only two left I see), together with the bitrate calculator for file size, I shouldn't need to worry about anything else? DXVA support will be present? :P
Just out of curiousity: If HD material is hardware accelerated with level 4.1, what is the point of setting it higher, say to level 5.1? What is the difference?
Yup . And it doesn't show it if DXVA wasn't acually in use :)
Nice! I need to encode some samples to provoke this to happen, seeing is believing :)
nurbs
5th August 2010, 12:23
I just looked at those MeGUI presets and they have level and VBV parameters set so DXVA will work. In the main window of the codec configuration you can adjust the "preset" slider to select your desired speed/quality tradeoff and the "tuning" dropdown where you can tune for your content, like film or animation. As long as you don't touch anything else it's guaranteed to work.
Higher levels mainly allow you to use higher resolutions and/or framerates, more reference frames at the same resolution and higher VBV maximum bitrate.
The resolutions and framerates don't matter if your source material is from DVD and Blu-Ray (unless you have a 1080i30 source and bob it to 1080p60). VBV maxrate doesn't matter either in most backup scenarios since the bitrates most people use are too small for it to be a problem. Reference frames bring a little extra quality, but with each additional reference frame you gain only about half as much as with the previous one, so the benefit is diminishing. Extra reference frames are generally more useful on animation, but that's what the tunings I mentioned take care of.
littleD
5th August 2010, 12:23
TheImperial2004 knows that DXVA is used because MPC-HC shows "playing [DXVA]" when it is used.
Yup . And it doesn't show it if DXVA wasn't acually in use
There is case when you see no dxva while it is in use. MPC-HC +EVR+h264 on win XP.
Just out of curiousity: If HD material is hardware accelerated with level 4.1, what is the point of setting it higher, say to level 5.1? What is the difference? I see no point. Difference is your gpu wont accelerate 5.1 if you have Radeon 3xxx or lower.
TheImperial2004
5th August 2010, 12:33
There is case when you see no dxva while it is in use. MPC-HC +EVR+h264 on win XP.
hmm . I thought that EVR was only available under Vista , 7 and Server 2008's ?
JEEB
5th August 2010, 12:38
hmm . I thought that EVR was only available under Vista , 7 and Server 2008's ?
It comes with .NET 3.0 or 3.5 IIRC, which is available for XP as well.
Keiyakusha
5th August 2010, 17:04
EVR is available for XP but DXVA won't work with it. For DXVA on XP VMR9 should be used.
Mounir
5th August 2010, 18:11
dxva also work in Overlay, i know i use it
http://en.wikipedia.org/wiki/DirectX_Video_Acceleration
littleD
5th August 2010, 19:52
EVR is available for XP but DXVA won't work with it. For DXVA on XP VMR9 should be used.
Yes, You can. Just make sure You have dxva2.dll in system32 folder. Even if drivers natively dont support specific format in dxva2 (only h264 on radeon with xp, rest formats are supported), it still can play with evr in dxva1 compatibility mode. :rolleyes:
Dal
3rd September 2010, 23:25
I just looked at those MeGUI presets and they have level and VBV parameters set so DXVA will work. In the main window of the codec configuration you can adjust the "preset" slider to select your desired speed/quality tradeoff and the "tuning" dropdown where you can tune for your content, like film or animation. As long as you don't touch anything else it's guaranteed to work.
Hello again.
Maybe this post should have been posted to other forums, like the MeGui forum and the x264 forum, it's kinda hard to say what the problem is. But since we started a DXVA discussion here, I'll post it here first:
I just discovered something very sad. I say sad because I have already encoded many files with this setting:
Lately I have begun to use the MeGUI setting called x264: DXVA Standard Def, but I tweaked it to use Automated 2-pass (actually, the Bitrate Calculator enforces that) and dragged the slider to Slower and Very Slow.
Those two settings sets the referance frames to 8 and 16 respectively.
But today I was going to try the encoded files on a computer other than the one I usually use, playing them with Media Player Classic Home Cinema. I noticed that the DXVA display did not show up as it should in the bottom bar.
That was with the last officially released MPCHC (1.3.1249.0)
With newer beta versions, the DXVA flag is raised, but the picture is full of artifacts.
Double checking this on my main computer, the problem is the same there.
When using FFDShow DXVA decoder (in Zoom Player), the picture is also full of artifacts.
I guess that rules out bugs with both MPCHC and FFDShow, since MCPHC uses it's own internal filters?
Going through the files with Mediainfo, it dawns on me that all the files with problem has 16 referance frames, and even those with 8 referance frames has problems, only with fewer artifacts.
The reason I haven't discovered this before, is because my normal settings; Zoom Player using Cyberlink Video Decoder v10, plays the files without problems, seemingly with DXVA on.
However, unfortunately the files does not seem to be compatible with the rest of the world :(
This leaves a few questions:
- Is 8 and 16 referance frames not compatible with the Level3.1 (SD video) setting?
- Are there bugs in FFDShow DXVA Decoder and MPCHC?
- Is there something wrong with the MeGui DXVA settings?
- Are my files lost forever, or is there a way to change the referance frames?
Feeling a bit frustrated now, I really hope someone out there has an answer / solution for this.
BTW: Samples can be provided any time.
Thanks again.
Sharktooth
4th September 2010, 03:42
what version of megui and presets you used for your encodes?
btw, i dont think there is a known software that can change the refs vaule.
Dal
4th September 2010, 07:48
Hi, and thanks for answering.
what version of megui and presets you used for your encodes?
I use MeGUI v0.3.5.8 with Tx264 v5.3 presets.
btw, i dont think there is a known software that can change the refs vaule.
Yeah, I was afraid of that :(
nurbs
4th September 2010, 09:20
8 reference frames are within the limit of level 3.1 if the output is DVD resolution (720*576 or 720*480) or below. The newer versions of the megui presets have set --level 3.1, so the number of reference frames are automatically reduced to the level limit unless
a) you specify the reference frames manually (--ref x)
b) you remove the --level switch
c) there is a bug in megui that causes one of the above to happen if you change something else
Dal
4th September 2010, 12:58
8 reference frames are within the limit of level 3.1 if the output is DVD resolution (720*576 or 720*480) or below. The newer versions of the megui presets have set --level 3.1, so the number of reference frames are automatically reduced to the level limit unless
a) you specify the reference frames manually (--ref x)
b) you remove the --level switch
c) there is a bug in megui that causes one of the above to happen if you change something else
Hi,
So you are saying I shouldn't experience problems when using 8 referance frames? The output is usually 544x400 (416).
Here's what I do in MeGUI:
I choose DXVA Standard Def. as encoder setting and choose Bitrate Calculator from the menu. I do my settings there (choosing file size), and press apply. When I do that I get a question if I want to turn on automatic 2-pass (I'm not sure if that is the exact phrase, I don't have it in front of me). I press yes. Then I press the config button, and when entering the x264 configuration dialog, I drag the slider to very slow. Then I press OK and Yes. That's it.
So I'm leaning against your option c).
nm
4th September 2010, 13:07
So I'm leaning against your option c).
That's easy to check from the userdata SEI written by x264. MediaInfo will show it (as in your first post), or you could post a clip so others can try it out too.
Which graphics card and driver are you using?
Dal
4th September 2010, 13:31
That's easy to check from the userdata SEI written by x264. MediaInfo will show it (as in your first post), or you could post a clip so others can try it out too.
You mean this info?
General
Complete name : D:\Captures\komprimeres\encoded\08-27_13-25-00_Disney Channel (nor)_Phineas og Ferb.0.demuxed.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 120 MiB
Duration : 10mn 33s
Overall bit rate : 1 595 Kbps
Encoded date : UTC 2010-08-30 22:19:53
Tagged date : UTC 2010-08-30 22:19:53
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 10mn 33s
Bit rate mode : Variable
Bit rate : 1 592 Kbps
Maximum bit rate : 7 763 Kbps
Width : 544 pixels
Height : 400 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.293
Stream size : 120 MiB (100%)
Writing library : x264 core 104 r1703 cd21d05
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=1592 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=17500 / vbv_bufsize=14000 / ip_ratio=1.40 / aq=1:1.00 / nal_hrd=none
Encoded date : UTC 2010-08-30 22:19:53
Tagged date : UTC 2010-08-30 22:34:40
Mediainfo is how I found out about this problem (the 16 referance frames), btw.
Which graphics card and driver are you using?
I use a ATI 4850 with v10.7 drivers.
nm
4th September 2010, 15:00
The settings seem fine to me, but the driver may disagree. There may be some reference frame limit for SD video regardless of the actual frame size. Post a sample so people can try it out on other systems.
I also see that you are using MP4 as container. There is currently a problem in MP4Box that causes playback issues when muxing video encoded with latest x264 versions. See: http://forum.doom9.org/showthread.php?t=156110
Try MKV instead of MP4 to see if this is the cause.
Ma-Xell
4th September 2010, 15:17
Also if you are using the CoreAVC H.264 decoder the icon in the task bar/system tray turns green.
Dal
4th September 2010, 16:36
The settings seem fine to me, but the driver may disagree. There may be some reference frame limit for SD video regardless of the actual frame size.
So as far as you know, there is no problem with 16 referance frames for SD video?
Post a sample so people can try it out on other systems.
Here is a 2min sample, made exactly the same way as I always do, complete with audio :)
http://gaasdal.net/web-pics/sample.mkv
I also see that you are using MP4 as container.
I'm not. I always use MKV as container. The Mediainfo info you saw, was just from the video file alone.
Dal
4th September 2010, 16:40
Also if you are using the CoreAVC H.264 decoder the icon in the task bar/system tray turns green.
CoreAVC does not support ATI / DXVA yet, only CUDA.
v2.1 is supposed to support it, though.
nm
4th September 2010, 17:31
So as far as you know, there is no problem with 16 referance frames for SD video?
No, there may very well be problems with some driver and GPU combinations. I wouldn't go over 11 reference frames for SD content. Still, this doesn't explain your problems with 8 reference frames.
Dal
4th September 2010, 18:36
Still, this doesn't explain your problems with 8 reference frames.
About that, I tried to reproduce that using the same source file I made the 16 ref frames sample I uploaded earlier. But the output looks fine, no artifacts.
But at the same time I sit here looking at several files claiming to have 8 referance frames, and they are full of artifacts.
Heres is Mediainfo on one of them:
General
Complete name : N:\TV\Barn\Rampete Robin\mkv\Rampete Robins rampete hamster.mkv
Format : Matroska
File size : 126 MiB
Duration : 10mn 52s
Overall bit rate : 1 617 Kbps
Encoded date : UTC 2010-08-06 16:38:03
Writing application : mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 3 2010 22:54:08
Writing library : libebml v1.0.0 + libmatroska v1.0.0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Muxing mode : Container profile=Unknown@3.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 10mn 52s
Bit rate : 1 500 Kbps
Width : 720 pixels
Height : 400 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.208
Stream size : 114 MiB (91%)
Writing library : x264 core 104 r1677 19df41a
Encoding settings : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=1500 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=17500 / vbv_bufsize=14000 / ip_ratio=1.40 / aq=1:1.00 / nal_hrd=none
I could of course upload one of them, but I don't know how legal it is, since it is a full episode recorded from TV. It is from an open channel (not pay TV), though.
Maybe if there is a program that can cut out a small part of the mkv file?
nurbs
4th September 2010, 20:38
The number of reference frames is alright for both the files you posted, so your problems are either player or hardware related.
Dal
4th September 2010, 21:02
The number of reference frames is alright for both the files you posted, so your problems are either player or hardware related.Did you download the sample file? How did it play for you?
nurbs
4th September 2010, 21:10
I didn't download it because I'm not at a PC that has hardware decoding right now, I'll do so tomorrow. All I'm saying is that the number of reference frames of both of the files doesn't exceed the limit imposed by using level 3.1, so hardware decoders supporting that level should play it. Since most hardware players (other than portables) usually support level 4.1 or even above (at least more reference frames) a SD file with 16 refs shouldn't be an issue.
While we're at the topic of hardware, what graphics card do you have and are the drivers up to date?
Dal
5th September 2010, 12:25
While we're at the topic of hardware, what graphics card do you have and are the drivers up to date?
Not the newest, I'm afraid: I have a ATI 4850, and using the 10.7 drivers.
I installed the 10.8, but I had to revert back to 10.7 again because a game I'm currently playing became unstable.
nurbs
5th September 2010, 14:09
I tested your sample with MPC-HC 1.2.2331.0 and DXVA didn't work, so I went into the decoder configuration and set the "DXVA compatibility check" option to "Skip ref frame check" and then it worked without problems on my card (GF 460). It's strange because the number of reference frames is within the limit if I'm not mistaken. Maybe there is a bug in the check MPC-HC does. I would post the issue in the MPC-HC thread and ask the developers what they think if I were you.
edit:
I forgot to mention I had an ATI 38xx and it handled level 4.1 content fine.
Dal
6th September 2010, 09:01
I tested your sample with MPC-HC 1.2.2331.0 and DXVA didn't work, so I went into the decoder configuration and set the "DXVA compatibility check" option to "Skip ref frame check" and then it worked without problems on my card (GF 460). It's strange because the number of reference frames is within the limit if I'm not mistaken. Maybe there is a bug in the check MPC-HC does. I would post the issue in the MPC-HC thread and ask the developers what they think if I were you.
Yeah, maybe. But remember, I also got the same artifacts and errors while using FFDShow DXVA as decoder.
And as far as I know MPC-HC does not use FFDshow at all?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.