View Full Version : Media Player Classic Home Cinema (MPC-HC) - DXVA!
So, nVidia cards never auto-expand, which is better than ATI. If only there are ways to disable the auto expand feature in CCC, it would be good.
with nvidia cards the "16-235->0-255" shader must be used with VMR9 renderless on SD and HD material. i get the same result as you with double expansion on ATI if i combine 2 "16-235->0-255" shaders:
with just 1 shader:
http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_1shader.jpg (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/1shader.jpg)
with 2 "16-235->0-255" shaders combined:
http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_2shader.jpg (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/2shader.jpg)
@ranpha
I use DVI, 1680x1050@60hz.
@gngn
The shader must also be used with evr for vista rtm and with evr custom presenter on vista sp1.
@ohropax
When VMR9 renderless with 'remove-tearing' option is selected, the user can no longer switch from fullscreen to regular display mode. Could this be changed please?
It cannot be changed because that option puts the renderer in exclusive mode making the video always fullscreen and always on top. Use CTRL+C to close the video and change the settings.
.....I have discovered that with VMR Mixer Mode on expansion is not quite done correctly either with HD or SD. "Video Black", luma 16, is mapped to RGB "1" instead of "0". With VMR Mixer mode off it is correctly set to RGB "0".I have found a workaround for the workaround!
If you turn on YUV Mixing as well as the VMR Mixer the levels are correct.
raynor
3rd July 2008, 20:33
Any chance of making the OSD more configurable in the future ?
I'm thinking about ...
- selecting the font size (right now the OSD is too small to read
for me from a distance)
- selecting the OSD color (font and background)
- selecting the OSD position
- maybe making it transparent (i.e. no blue background like it
is now now, but just displaying the font - similar to the OSDs
on most TVs)
Another thing:
Maybe there should be a README file included in the distribution
that points to the download location of the DirectX Rediustributable Update
(which is required for the shaders to work) ... because there are many questions
in this thread about why the shaders are not working. This would help new users.
Also, workarounds for known problems could be included
in that readme file such as that if your colors are "washed out"
with VMR9 and EVR you should use the 16-235->0-255 shader,
etc.
What do you think ?
ohropax
3rd July 2008, 20:38
It cannot be changed because that option puts the renderer in exclusive mode making the video always fullscreen and always on top. Use CTRL+C to close the video and change the settings.
@kado
That is what i guessed, so my simple proposal is to reopen the renderer (or even the complete decoding chain) when switching to fullscreen or back.
Or do you have suggestion for a renderer configuration that fulfills the previously mentioned constrains?
@ranpha
Shader ON (720p) (http://pwp.netcabo.pt/kado/s_on_hd.jpg)
Shader Off (720p) (http://pwp.netcabo.pt/kado/s_off_hd.jpg)
@hwti
Use this tool (http://bluesky23.hp.infoseek.co.jp/index.html#DXVAChecker) and post your hardware capabilities please.
Decoder device:
ModeMPEG2_IDCT: DXVA2, NV12, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_A: DXVA1, NV12, 720x480 / 1280x720 / 1920x1080
ModeMPEG2_C: DXVA1, NV12, 720x480 / 1280x720 / 1920x1080
ModeH264_VLD_NoFGT: DXVA2, NV12, 720x480 / 1280x720 / 1920x1080
ModeVC1_VLD: DXVA1/2, NV12, 720x480 / 1280x720 / 1920x1080
5B23D46D-FA5F-4FDC-B78A-7EB2787942EC: DXVA2, NV12, 720x480 / 1280x720 / 1920x1080
Processor device:
ATI Radeon HD 4800 Series
[YUY2]
AdaptiveDevice: DXVA2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 1
DeinterlaceTechnology: PixelAdaptive
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / Constriction
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
BobDevice: DXVA1/2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 0
DeinterlaceTechnology: BOBVerticalStretch
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / Constriction
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
ProgressiveDevice: DXVA1/2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 0
DeinterlaceTechnology: Unknown
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / Constriction
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
SoftwareDevice: DXVA2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: SoftwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 0
DeinterlaceTechnology: BOBVerticalStretch
ProcAmpControlCaps: None
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / PlanarAlpha
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
[UYVY]
BobDevice: DXVA1/2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 0
DeinterlaceTechnology: BOBVerticalStretch
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / Constriction
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
ProgressiveDevice: DXVA1/2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 0
DeinterlaceTechnology: Unknown
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / Constriction
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
[NV12]
VectorAdaptiveDevice: DXVA1, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice / EmulatedDXVA2
NumForwardRefSamples: 0
NumBackwardRefSamples: 2
DeinterlaceTechnology: PixelAdaptive
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended
MotionAdaptiveDevice: DXVA1, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice / EmulatedDXVA2
NumForwardRefSamples: 0
NumBackwardRefSamples: 2
DeinterlaceTechnology: PixelAdaptive
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended
AdaptiveDevice: DXVA1, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice / EmulatedDXVA2
NumForwardRefSamples: 0
NumBackwardRefSamples: 1
DeinterlaceTechnology: PixelAdaptive
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended
BobDevice: DXVA1/2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 0
DeinterlaceTechnology: BOBVerticalStretch
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / Constriction
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
ProgressiveDevice: DXVA1/2, 720x480 / 1280x720 / 1920x1080
DeviceCaps: HardwareDevice
NumForwardRefSamples: 0
NumBackwardRefSamples: 0
DeinterlaceTechnology: Unknown
ProcAmpControlCaps: Brightness / Contrast / Hue / Saturation
VideoProcessorOperations: YUV2RGB / StretchX / StretchY / SubRects / SubStreams / SubStreamsExtended / YUV2RGBExtended / Constriction
NoiseFilterTechnology: Unsupported
DetailFilterTechnology: Unsupported
It is strange that I have more choice in DXVA1 than DXVA2 (VectorAdaptiveDevice, PixelAdaptiveDevice)
Another thing : with ATI MPEG decoder for MPEG2 (seems to be DXVA1 only) :
- EVR custom renderer crashes
- VMR9 custom renderer shows no picture (zoom is grayed in menu), but statistics tells frames are "drawn"
ericab
3rd July 2008, 22:57
hwti
use the code box man
[-aRcTiC-]
3rd July 2008, 23:18
Kinda new to this and i need help.
3850 agp
amd x2 4200+
catalyst 8.6 agp hotfix
MPC-HC v604
In Vista 32bit DXVA works on both vc1 and h264 videos (720p&1080P) Heres dxvachecker..
http://img357.imageshack.us/img357/2070/dxva3850xq0.th.jpg (http://img357.imageshack.us/my.php?image=dxva3850xq0.jpg)
But in XP 64bit it doesnt work and dxvachecker doesnt even list h264 or vc1 decoder devices.
http://img159.imageshack.us/img159/2600/3850kn3.th.png (http://img159.imageshack.us/my.php?image=3850kn3.png)
Is it drivers or is there something missing, what gives?
GTPVHD
4th July 2008, 06:28
WMV9 DXVA decoder seems to be broken with recent releases also on Nvidia 8/9 series cards at least on XP SP3 with WMP11 installed for the latest codecs. Nvidia 8/9 series exposes ModeWMV9_IDCT which can be confirmed using DXVACheker 1.6. Previously, WMV9 files show DXVA: WMV9 IDCT in use when using CTRL+J, with the recent builds including 629 it now shows DXVA: Not using DXVA. It's only partial acceleration and I understand it's not suppose to work at all on non bitstream processing(VLD) hardware but it did work on the 58x builds before the 586/587.
This is the file I used to test. 1080p WMV9.
http://us.download.nvidia.com/downloads/nZone/videos/nzm_PureVideo_SDvsHD.wmv
Casimir666
4th July 2008, 07:07
WMV9 DXVA decoder seems to be broken with recent releases also on Nvidia 8/9 series cards at least on XP SP3 with WMP11 installed for the latest codecs. Nvidia 8/9 series exposes ModeWMV9_IDCT which can be confirmed using DXVACheker 1.6. Previously, WMV9 files show DXVA: WMV9 IDCT in use when using CTRL+J, with the recent builds including 629 it now shows DXVA: Not using DXVA. It's only partial acceleration and I understand it's not suppose to work at all on non bitstream processing(VLD) hardware but it did work on the 58x builds before the 586/587.
This is the file I used to test. 1080p WMV9.
http://us.download.nvidia.com/downloads/nZone/videos/nzm_PureVideo_SDvsHD.wmv
You should disable internal VC1 decoder, and use Microsoft DMO decoder to have acceleration with nVidia.
So guys, without being pushy, what gives with these bugs?
It seems pretty significant to me that with a number of popular renderer options Blu-ray/HD-DVD sourced video is displayed in the wrong aspect ratio and in some cases with actual noise in the last 8 lines, but no one involved in cutting code has replied at all, even just to say they don't plan to fix it. This was first raised on the 24th May.
Likewise, although it is only a one level shift, not correctly expanding video levels with the VMR mixer engaged (unless in YUV mixing mode) is a fairly basic bug.
Is that because no one is responsible for that part of the application and so it is not fixable, or because people think I am mad or what?
@ohropax
your main problem is tearing because the other stuff can be used with evr custom presenter, I have no tearing in my system fortunately but you should try other set of drivers for your gpu.
@clsid, casimir
MPC crashes if you open the mpc video decoder options from the ffdshow audio decoder icon using build 629, did not happen with build 622, maybe because of the dxva/ffmpeg filter separation.
clsid
4th July 2008, 15:14
@clsid, casimir
MPC crashes if you open the mpc video decoder options from the ffdshow audio decoder icon using build 629, did not happen with build 622, maybe because of the dxva/ffmpeg filter separation.
The filter is not separated yet, just its configuration options have been altered. I'll attempt filter separation in the near future (my goal is to make it possible to build MPC with DXVA but without FFmpeg decoders).
I had a crash problem when accessing the options in MPC, but that was solved after doing a full rebuild. So please try if that also solves your problem.
@clsid, casimir
MPC crashes if you open the mpc video decoder options from the ffdshow audio decoder icon using build 629, did not happen with build 622, maybe because of the dxva/ffmpeg filter separation.
no problems on my system with the 629 version from xvidvideo.ru.
s174955
4th July 2008, 15:49
Maybe try an earlier Catalyst (after a clean uninstall of course). I am running 8.3 with a 3850 on XP and it is perfect in VMR9 renderless. Totally dependable. I use D3D normally, but apart from a bit of tearing and slightly less dependable frame rate it works fine without.
Haven't tried yet with version 8.3. But noticed that when I use the PowerDVD 8 h264 decoder, everyting works fine in vmr9 renderless.
So I do have dxva + subtitles, though not with the MPCDedocer. Glad it works now though.
Haven't tried yet with version 8.3. But noticed that when I use the PowerDVD 8 h264 decoder, everyting works fine in vmr9 renderless.
So I do have dxva + subtitles, though not with the MPCDedocer. Glad it works now though.I have now upgraded to the 8.7 beta and all is working fine in MPC-HC and PowerDVD 8. VC-1 and AVC acceleration OK.
(The other bugs with Blu-ray playback and expansion are unchanged.)
ChronoReverse
4th July 2008, 16:15
So, nVidia cards never auto-expand, which is better than ATI. If only there are ways to disable the auto expand feature in CCC, it would be good.
Do you use DVI or HDMI for your display?
How is it better to be _not_ doing something that's supposed to be done?:confused:
You should disable internal VC1 decoder, and use Microsoft DMO decoder to have acceleration with nVidia.
From my trials, it makes Hardware Deinterlacing but no HW decoding; CPU utilization is %60 with WMVideo decoder DMO.
6750 CPU, 2gb RAM, 8600GTS, FW 175.19, alexins' 629...
(BTW, 629 chooses DMO by itself even internal VC1 selected...)
ranpha
4th July 2008, 18:19
Is there any chance that the screenshot-taking error with vanilla EVR renderer be fixed?
The filter is not separated yet, just its configuration options have been altered. I'll attempt filter separation in the near future (my goal is to make it possible to build MPC with DXVA but without FFmpeg decoders).
ffdshow isn't stable enough on every pc. Internal mpc decoders have no incompatibility issues with any app that users use. Maybe mpcvideodec.ax could be compiled without FFmpeg decoders, only to be used with DXVA.
clsid
4th July 2008, 19:18
Since when is ffdshow not stable enough? Applications that don't like ffdshow can easily be blacklisted.
At this moment the internal decoders don't work properly in combination with the Overlay Mixer. Some files just freeze at the beginning.
I hope Casimir will eventually split the current CMPCVideoDecFilter into two filters within mpcvideodec.ax, one for software decoding and one for DXVA. I would attempt it myself, but I don't understand the code good enough yet to know what code is DXVA related and what not.
ramonchin
4th July 2008, 20:54
Since some x264 videos hangs when DXVA is On, I'd like to set MPCVideodec.ax to decode only H264 footage but not x264. I prefer CoreAVC for x264.
Is this possible? How?
Nowadays, Can MPCVideodec.ax decode interlaced H264 streams (HD sat channels)?
Is xvidvideo.ru the address where I can find always the last version?
I've ATI 3850HD
Thanks!
clsid
4th July 2008, 22:33
x264 is not a video format. x264 is an encoder that produces H.264 video. So what you are asking make no sense at all ;)
x264 is not a video format. x264 is an encoder that produces H.264 video. So what you are asking make no sense at all ;)
There is a misunderstanding here:
As far as i understood ramonchin knows it is not a video format.
*.264 avc profile may be in these styles:
h264, encoded by pro encoders like Elecard or MC or
x264, encoded by open source encoders like we find in sourceforge net.
The question was whether the possibility is existent of using different decoders for those two types separately or not.
In this case the answer will be "no"; you can not use different decoders for x264 or h264 files.
73ChargerFan
5th July 2008, 00:50
@ohropax
It cannot be changed because that option puts the renderer in exclusive mode making the video always fullscreen and always on top. Use CTRL+C to close the video and change the settings.
How about this:
on request for menu
{
pause playback
copy frame image
switch display mode
display image
do the menu thing...
switch mode back to directx full screen
resume playback
}
73ChargerFan
5th July 2008, 00:56
Feature Request:
Add a "Apply & Restart" button to the options dialog.
- restart the application, with the new options
- resume playback of same file, with same video style (full screen or windowed, where, size)
- seek to the same position
- leave it on pause
@73ChargerFan
I suppose the graph must be rebuild to change the display mode (between normal and exclusive mode).
@ChronoReverse
Because you will have to disable or enable the shader depending on the video resolution. ATI makes expansion on HD but not in SD. nVidia does not make any expansion.
73ChargerFan
5th July 2008, 01:58
@73ChargerFan
I suppose the graph must be rebuild to change the display mode (between normal and exclusive mode).
Perhaps, if you're trying to play the video under the new display mode. I imagine using a screen grab as a static background while the menu is being displayed, then restoring the real display mode.
Perhaps, if you're trying to play the video under the new display mode. I imagine using a screen grab as a static background while the menu is being displayed, then restoring the real display mode.
How about OSD style menu?
if [options] choice is selected, minimizing the render window and showing option window.
crlorentzen
5th July 2008, 05:26
How is it better to be _not_ doing something that's supposed to be done?:confused:
I think ranpha's point is that with an nVidia device we can simply enable a single expansion in our codec/shaders and not worry since nVidia consistently does not change the luma. Earlier in this thread it was stated that ATi does the expansion on some but not all video, I do not know if this is accurate or not as I only have nVidia cards currently, but if that is true then it is better how nVidia does it because it is consistent.
Now we should also go over if the expansion is really something that it's supposed to do. I think most of us in this thread would agree that with properly calibrated monitor (e.g. 0-255 is fully set) applying the TV-PC luma fix (expand 16-235 to 0-255) should be done somewhere along the line to get back the original artistic intention. So as we can infer from the statement above, some people would disagree that the expansion should be done at all, I do not. I believe in a proper expansion, however, I am trying to do a complete analysis. So for those that don't believe in expansion immediately nVidia is the best as it never does this expansion.
Next we have those that agree with expansion. In this case I believe nVidia to be in a better state again, as I can simply configure my playback program to do the expansion and be assured of a single expansion and proper display. However, with ATi, assuming it is true that sometimes it does not expand video, then you get into a sticky situation where you need to constantly question whether you need to enable your expansion or not. And I Hate! having to constantly flip flop settings.
Anyways, I hope this helps to flesh out the statement made by ranpha, sorry for hijacking the thread for a bit. I do think I remember someone offered a way to make it so that ATi always did the expansion, but, not sure...
Why they expand HD but not SD, by default I really do not know. It sounds mad, but it has been like that for a long time now so they must really think it is a good idea :confused:
Fortunately the "USEBT601CSC" = "1" registry setting fixes ATI so it expands everything. This has the additional advantage that it works in all applications including PowerDVD. No need to individually tweak levels in each media player you use. Also, if you connect an ATI card to an HDMI TV using their HDMI dongle the card changes behaviour and outputs everything, including "the desktop", so photos etc. @ video levels and using YCbCr.
So, with the registry tweak I would say ATI is in a better position than Nvidia. But without it things are just plain weird!
Why they expand HD but not SD, by default I really do not know. It sounds mad, but it has been like that for a long time now so they must really think it is a good idea :confused:
Fortunately the "USEBT601CSC" = "1" registry setting fixes ATI so it expands everything. This has the additional advantage that it works in all applications including PowerDVD. No need to individually tweak levels in each media player you use. Also, if you connect an ATI card to an HDMI TV using their HDMI dongle the card changes behaviour and outputs everything, including "the desktop", so photos etc. @ video levels and using YCbCr.
So, with the registry tweak I would say ATI is in a better position than Nvidia. But without it things are just plain weird!
Got a bit confused about the ATi's behavior regarding HDMI out. I wonder what's the best setup, since I'll have an ATi 4850 in my hands in about 3 hours :devil:
Well I have a 3850, but from what I have read the 4850 behaves the same.
You will need to use the above tweak to get DXVA SD video to consistently output the same levels as HD and the desktop.
I am on XP (almost exclusively VMR9). I read EVR on Vista may not need tweaking, but still it is good to apply the tweak so everything is consistent, whatever player/renderer being used.
Then use the ATI dongle, which hopefully you will get with your card (not all have them), and all content (desktop, HD and SD) will be output @video levels, which is particularly good if your HTPC is going though and AVR or HDMI switcher, shared with other set top boxes, DVD players etc. Then you can calibrate the shared TV input for video levels and everything will be displayed correctly.
Thanks for explaining, let's just hope that the card will work with motherboard first, since it's an nvidia board with PCIe 1.1 only. If all goes well, I should be watching my favorite anime in MPC-HC in my LG 32" TV via HDMI tonight.
@73ChargerFan
I suppose the graph must be rebuild to change the display mode (between normal and exclusive mode).
The display mode should only concern the renderer, so if anything only the (custom) renderer would have to cope with it.
And since it's perfectly possible to use Direct3D in a window with controls and other windows obscuring the viewport it should be possible to make the renderer display the video in non-exclusive mode - with added tearing, though.
You'll of course get the same symptoms as with games when switching - the display mode will change so the screen will flicker, but I guess that's not much of a problem... :)
By the way - would it be possible to open dialogs on the monitor with the taskbar if I activate them via the tray icon?
Since I'm using VMR9 with Direct3D on my second monitor while the MPC icon is in the tray on my first monitor this actually allows for a lot of control; it's just that the dialogs open on the screen where the video is and I have to fumble around with Alt-Space + M, a cursor key and the mouse to drag it across to the first screen...
np: DJ Flush - Baila Redux (Musick To Play In The Club)
clsid
5th July 2008, 11:57
There is a misunderstanding here:
As far as i understood ramonchin knows it is not a video format.
*.264 avc profile may be in these styles:
h264, encoded by pro encoders like Elecard or MC or
x264, encoded by open source encoders like we find in sourceforge net.
The question was whether the possibility is existent of using different decoders for those two types separately or not.
In this case the answer will be "no"; you can not use different decoders for x264 or h264 files.
*sigh*
There is no such thing as a x264 file.
And x264 does not output some special form of H.264 video that makes it different from other encoders.
*sigh*
There is no such thing as a x264 file.
And x264 does not output some special form of H.264 video that makes it different from other encoders.
I didn't tell this, just tried to decode the question :)
hi alexins, i have a question.
Even i select haali under external filters as preferred i got this graph behind your compilation v.629.
It doesn't seem haali's or mpc's splitter.
What is this?
http://img394.imageshack.us/img394/8522/alexinson0.th.jpg (http://img394.imageshack.us/my.php?image=alexinson0.jpg)
alexins
5th July 2008, 16:13
Hi rica!
I have constructed two schedules with usage of standalone filters mpc-hc v.629 (http://www.xvidvideo.ru/content/view/59/2/). The first uses only standalone filters. The second uses standalone filters and plus Haali Media Splitter.
Only standalone filters:
http://i050.radikal.ru/0807/a1/75c8f36e322ct.jpg (http://radikal.ru/F/i050.radikal.ru/0807/a1/75c8f36e322c.png.html)
Standalone filters and Haali Media Splitter:
http://i004.radikal.ru/0807/2d/62b74faf61c6t.jpg (http://radikal.ru/F/i004.radikal.ru/0807/2d/62b74faf61c6.png.html)
http://i069.radikal.ru/0807/c4/d136f747c414t.jpg (http://radikal.ru/F/i069.radikal.ru/0807/c4/d136f747c414.png.html)
ramonchin
5th July 2008, 17:17
Does standalone filter decode H264 interlaced sat channels? I only get black screen. :(
ADude
5th July 2008, 19:02
And x264 does not output some special form of H.264 video that makes it different from other encoders.
If you are correct, then that is one of the biggest Internet Myths.
The general conventional wisdom is that x264 often creates H.264 video files that are not DXVA compliant.
And therefore if you play a lot of H.264 videos made by amateur encoders that use x264, then you are better off with CoreAVC than with DXVA.
clsid
5th July 2008, 19:27
Other H.264 encoders can also produce output that is not DXVA compliant. A perfectly valid H.264 video stream is not necessarily DXVA compliant because hardware decoders only support a subset of the H.264 feature set. It is not the fault of x264 that most people on the Internet are morons. There are plenty of front-ends for x264 that have settings profiles that ensure DXVA compatibility.
MPC has some DXVA compatibility checks. If those fail, then it falls back to software decoding, allowing you to automatically use CoreAVC (if you disable the internal FFmpeg decoder).
Other H.264 encoders can also produce output that is not DXVA compliant. A perfectly valid H.264 video stream is not necessarily DXVA compliant because hardware decoders only support a subset of the H.264 feature set. It is not the fault of x264 that most people on the Internet are morons. There are plenty of front-ends for x264 that have settings profiles that ensure DXVA compatibility.
MPC has some DXVA compatibility checks. If those fail, then it falls back to software decoding, allowing you to automatically use CoreAVC (if you disable the internal FFmpeg decoder).
Actually, that doesn't seem to work in the latest SVN (629). It falls back to internal ffmpeg no matter what, even if H264/AVC (FFmpeg) is unchecked. To fallback to external decoder H264/AVC (DXVA) must also be unchecked. Bug?
Shinigami-Sama
5th July 2008, 20:26
If you are correct, then that is one of the biggest Internet Myths.
The general conventional wisdom is that x264 often creates H.264 video files that are not DXVA compliant.
And therefore if you play a lot of H.264 videos made by amateur encoders that use x264, then you are better off with CoreAVC than with DXVA.
a lot of amature encoders can't produce a stream that doesn't look like its been through a meatgrinder first too...
clsid
5th July 2008, 20:41
Actually, that doesn't seem to work in the latest SVN (629). It falls back to internal ffmpeg no matter what, even if H264/AVC (FFmpeg) is unchecked. To fallback to external decoder H264/AVC (DXVA) must also be unchecked. Bug?
It works correctly here. Although I haven't got a DXVA capable card, but that shouldn't make a difference. Anyone else having this problem?
@cca
Fallback to external filter works properly here. With enabled dxva and disabled ffmpeg if the clip is not dxva compilant coreavc decoder will be used.
@all
More testing would be needed to optimize the dxva compilance checks because i have "10 reference frame" files (Kurenai by BSS starting in ep2, ep1 is not dxva compilant) that internal does not play but cyberlink decoder plays.
alexins
5th July 2008, 21:04
It works correctly here. Although I haven't got a DXVA capable card, but that shouldn't make a difference. Anyone else having this problem?
MPC-HC r.630
http://i078.radikal.ru/0807/13/e1a5fa554829t.jpg (http://radikal.ru/F/i078.radikal.ru/0807/13/e1a5fa554829.jpg.html)
http://i008.radikal.ru/0807/46/0bca41c38574t.jpg (http://radikal.ru/F/i008.radikal.ru/0807/46/0bca41c38574.jpg.html)
http://i008.radikal.ru/0807/bb/155b45a0fe46t.jpg (http://radikal.ru/F/i008.radikal.ru/0807/bb/155b45a0fe46.jpg.html)
General
Complete name : F:\video\Spaceballs.HDTV.720p.x264.Rus.mkv
Format : Matroska
File size : 4.89 GiB
Duration : 1h 36mn
Overal bit rate : 7275 Kbps
Encoded date : UTC 2007-06-04 10:15:05
Writing application : mkvmerge v2.0.2 ('You're My Flame') built on Feb 21 2007 23:40:55
Writing library : libebml v0.7.7 + libmatroska v0.8.1
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 36mn
Bit rate : 5244 Kbps
Nominal bit rate : 5555 Kbps
Width : 1280 pixels
Height : 720 pixels
Display aspect ratio : 16/9
Frame rate : 23.976 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.251
Writing library : x264 core 48 svn-537M
Encoding settings : cabac=1 / ref=6 / deblock=1:-2:-2 / analyse=0x1:0x131 / me=hex / subme=5 / brdo=0 / mixed_ref=0 /
me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / chroma_qp_offset=0 / slices=2 / nr=0 / decimate=1 / bframes=4 /
b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=210 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=
5555 / ratetol=3.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=
1.40 / pb_ratio=1.30
Language : English
Audio #1
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 1h 36mn
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Rear: L R, LFE
Sampling rate : 48.0 KHz
Language : Russian
Audio #2
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 1h 36mn
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Rear: L R, LFE
Sampling rate : 48.0 KHz
Language : Russian
Audio #3
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 1h 36mn
Bit rate : 768 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Resolution : 24 bits
Language : English
Audio #4
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 1h 36mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Language : English
Format profile : Main@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Is this DXVA compatible?
I'm scratching my head now. I do have CoreAVC too, but if I don't uncheck the internal DXVA filter, internal FFmpeg is used, even if that is unchecked! I don't get it.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.