MKV and 8500 Full Hardware Acceleration

[RaggedEdge]

There is a growing army of PureVideo2 graphic card users, that would love to off load the MKV x264 decode process entirely to the GPU.

However the Haali Splitter seems to operate differently to the AVI Splitter in that identical H.254 720P data will play well on the on the AVI Splitter, but slow down to 20 FPS on the Haali Splitter.

1080P x264 does not seem to work at all in full hardware decode mode (using the Cyberlink H.264 AVC decoder). Software decode does work, but CPU usage sky rockets, and on peaks causes stuttering.

Are the root of these problems in the Haali Splitter or the Cyberlink H.264 AVC Decoder?

[check]

it's quite possibly related to the fact your h264 is in AVI, which means it's been packed into a vfw stream rather than being a native h264 stream. Try transmuxing the data out of vfw into another format, such as mp4 or mkv.

[RaggedEdge]

it's quite possibly related to the fact your h264 is in AVI, which means it's been packed into a vfw stream rather than being a native h264 stream. Try transmuxing the data out of vfw into another format, such as mp4 or mkv.

The original data file was a BBC HD Discovery 720P x264 MKV File.

The utility (mkv2vfr.exe) that comes with the Haali Splitter allows you to create AVI files from MKV files i.e. the AVI file will pack the exact same x264 data, that is in the MKV file.

Therefore, the data is in x264 format and common to both the AVI and MKV file.

While I'm on the subject, does anyone know how you can use the Mkv2vfr.exe utility to transfer the video and the audio to AVI? At the moment I can only tranfer the video.

[KoD]

It could also be graphic card drivers or hardware limitation.

[RaggedEdge]

It could also be graphic card drivers or hardware limitation.

At the moment it's beginning to look like Cyberlink is not fully compatible with the Haali Splitter when it comes to fully accelerating MKV files on the 8500/8600.

However, it's a bit strange that the same decoder works fine in software mode.

[arfster]

Little suggestion: in software mode the cyberlink decoder flagreads to decide video/film, while in hardware it does "smart" analysis. Given that it looks to be wrongly IVTC'ing (ie dumping every 6th frame, resulting in 24*5/6=20fps exactly), why would it only do this with mkv through haali? Anyone know or can speculate what flag or timing issues coming from haali could confuse the 8500/8600, yet not the decoder in software mode?

As above, if you remux the same video into another container it works perfectly.

[Schmendrick]

@RaggedEdge: Like you I also have found that Mkv2vfr.exe only muxes the video track into the AVI-container. I am using VirtualDubMod to add the audio AC3-track to the AVI-file which I had produced using Mkv2vfr.exe. The H264 originates from a DVB-S2-recoding recorded in MPEG-PES-stream format which is first muxed in the mkv-container and then into AVI as mentioned. The audio-track also originates also out of a MPEG-PES-AC3-track. The PES-format has the advantage that it contains PTS-values (presentation time stamps) which allows to calculate the exact audio/video-delay so that the final AVI-video has video/audio synchronity. On my Core2Duo-T5600 (2x1.86GHz) using the CoreAVC-decoder these videos can be played without stutter in software decoding at 40-60% processor load.

[RaggedEdge]

@RaggedEdge: Like you I also have found that Mkv2vfr.exe only muxes the video track into the AVI-container. I am using VirtualDubMod to add the audio AC3-track to the AVI-file which I had produced using Mkv2vfr.exe. The H264 originates from a DVB-S2-recoding recorded in MPEG-PES-stream format which is first muxed in the mkv-container and then into AVI as mentioned. The audio-track also originates also out of a MPEG-PES-AC3-track. The PES-format has the advantage that it contains PTS-values (presentation time stamps) which allows to calculate the exact audio/video-delay so that the final AVI-video has video/audio synchronity. On my Core2Duo-T5600 (2x1.86GHz) using the CoreAVC-decoder these videos can be played without stutter in software decoding at 40-60% processor load.

I ignored VirtualDubMode, thinking it may put the audio out of sync, but if you've already had success, I'll give it a go too.

At the moment, I just use graphedit with two file sources: one is the original MKV file with the video path deleted, and the other is the AVI file just containing the video. This keeps the audio in sync too, but it's not exactly user friendly!

I put together a VistaMCE PC using old components. The Intel P4 3GHz (Hyperthreading) is a bit too weak for software only, which is why I'm eager to get this hardware acceleration working. On this CPU, with HW acceleration the load is at less then 5%, in software it climbs to 100% (plus stuttering).

It's a crying shame that the hardware is not being allowed to deliver it's potential because of the software.

[RaggedEdge]

Little suggestion: in software mode the cyberlink decoder flagreads to decide video/film, while in hardware it does "smart" analysis. Given that it looks to be wrongly IVTC'ing (ie dumping every 6th frame, resulting in 24*5/6=20fps exactly), why would it only do this with mkv through haali? Anyone know or can speculate what flag or timing issues coming from haali could confuse the 8500/8600, yet not the decoder in software mode?

As above, if you remux the same video into another container it works perfectly.

On my setup, I find the video plays back at the full 24FPS for about 20 or so seconds, and then starts to drop to 20FPS.

It's strange that it works perfectly for the first 20 seconds after hitting one of the navigation buttons.

[arfster]

Found a similar thing happening in DVBViewer, only with the Cyberlink decoder. That app has its own source, and they made a "quickndirty hack" (their words) to fix it, basically involving little more than adding a little latency to the source filter. With a DVB app, this may be the equivalent of buffering a bit more.

At a guess, this maybe means haali is not feeding the cyberlink decoder enough data on time, so it decides to lower the frame rate.

[CiNcH]

I have just pushed the PureVideo HD 2 engine within my GeForce 8600GTS a little bit. Therefore I have created a rather complex H.264 HD stream:

Encoder: x264 (svn-598 Build)
Resolution: 1080p (Full-HD)
Nominal Bitrate: 30 mbps (VBR)
H.264 Tools: i8x8 (High Profile), CABAC, Deblocking
Container: MKV

I have performed two passes which resulted in a pretty variable bitrate according to the complexity of the different scenes. Nominal bitrate was chosen to be 30 mbps, peaks even almost reached 50 mbps (26:35 minutes took 5.5GB).

Filter Chain:
- Haali Media Splitter
- CyberLink H.264 Decoder 7.x
- VMR9

PureVideo HD 2 did a great job on this sample. Even though it is specified to work with bitrates up to 40 mbps it even handeled the short 50 mbps peaks properly without any glitches. CPU usage hardly reached 5% on a 2GHz downclocked Core 2 Duo.

Disabling PureVideo HD 2 resultet in 50% CPU usage, but this time SpeedStep clocked the CPU mostly at 2.67 GHz.

I did not mux audio into the MKV container yet. I may do so at a later time with DTS track.

(tested under Windows XP with ForceWare Beta 165.01)

[CruNcher]

I have just pushed the PureVideo HD 2 engine within my GeForce 8600GTS a little bit. Therefore I have created a rather complex H.264 HD stream:

Encoder: x264 (svn-598 Build)
Resolution: 1080p (Full-HD)
Nominal Bitrate: 30 mbps (VBR)
H.264 Tools: i8x8 (High Profile), CABAC, Deblocking
Container: MKV

I have performed two passes which resulted in a pretty variable bitrate according to the complexity of the different scenes. Nominal bitrate was chosen to be 30 mbps, peaks even almost reached 50 mbps (26:35 minutes took 5.5GB).

Filter Chain:
- Haali Media Splitter
- CyberLink H.264 Decoder 7.x
- VMR9

PureVideo HD 2 did a great job on this sample. Even though it is specified to work with bitrates up to 40 mbps it even handeled the short 50 mbps peaks properly without any glitches. CPU usage hardly reached 5% on a 2GHz downclocked Core 2 Duo.

Disabling PureVideo HD 2 resultet in 50% CPU usage, but this time SpeedStep clocked the CPU mostly at 2.67 GHz.

I did not mux audio into the MKV container yet. I may do so at a later time with DTS track.

(tested under Windows XP with ForceWare Beta 165.01)

Nice results indeed i trust Doom9 user results more then sites as Hardspell or Co :P looking @ those results for example im not sure to belive them that UVD's AVC Engine is twice as good as PV2's but who knows, fact is that for VC-1 it seemes really much better alot of independent tests all arround the web show this, then Nvidias Engine :D (Nvidia doesn't seem to care about VC-1 because of the less complexity compared to AVC FreXt, hmm saving money in dev time wherever possible it looks like the moto here was "ah the C2D/X2 consumers use todays have no problem to handle that little more decoding complexity so we don't need it for the GPU" ;), bad thinking for Mobile situations, but indeed who the hell really watches HD-DVD on his Notebook on the road, it seemes to less for Nvidia (or that was the reason to leave it out of the Desktop Chips (very clever resource management and R&D i would call this then) so it could be a different situation in the Mobile ones would be interesting to test this too ;) )

http://www.hardspell.com/pic/2007/4/17/5230ce13-18ff-47a6-91c1-89b50786eb8f.gif
http://www.hardspell.com/pic/2007/5/15/0a89f21d-cbec-4425-a69c-f6af385fb013.gif

http://www.hardspell.com/pic/2007/4/17/156e2ec6-6804-404f-956f-0d91d04a217a.gif
http://www.hardspell.com/pic/2007/5/15/661832bc-0e5e-4f23-8be2-10c9ff35aa1b.gif

Im thinking of replacing my old 7600 GS with a X2600XT DDR3 in the next weeks (but maybe im also waiting for the X2600 XT "Gemini" to arrive first a little more 3D power wouldn't be bad @ all at low power consumption as a bonus ;) and maybe you can Compute on each core sometime in the near future :D (Encoding) ) so im gonna test it myself. Especialy bitstream compatibilty as i found some problems with X264 + MP4/MKV + Cyberlinks Decoder on 7600 GS (PV1 DXVA) that doesn't happen with Commercial H.264 Encoders the "continues slowdown" problem, i described in another thread it's the most problematic of them and doesn't happen with Encoders from like Ateme/Mainconcept/Moonlight (old one) only with X264 (maybe a problem with the mvrange highert then 511 in combination with PV1 (DXVA) that was fixed in 663 now (but as this happens only for X264 bitstreams in MP4/MKV i doub't it i think more of a timestamp problem, didn't had the time yet to retest 663 but i will).
Would be cool if we could use the same test files then and compare those results between Nvidia's and Ati's Engine especialy for the Adaptive Deinterlacing part (should reach better quality results then Yadif now does, if i look @ my old Nvidia Deinterlacing results with the Previous GPU Generation (G7x PV1) ) and the last Driver i tested (97.94) allready showed the new Deinterlacing Code wich was better then Yadif, but the ShaderCode seemed to be to slow for the G7x especialy for HD so with the G8x it should reach Realtime now in the newest Vista/XP drivers, if my thoughts are correct.
Compareing that with Ati's Deinterlacing Quality would be really cool (as im still belive that ATI is still a tad better in Video Quality then Nvidia, but for sure the distance is smaller now then it was some years ago as Nvidia did big Research in the last years, their own Mpeg-2 Decoder really showed that (it's almost compareable between Intel and AMD Intel did 2x more Research improvements then AMD it seemes and now AMD stucks behind them, but it isn't exactly the 100% same situation with Nvidia & Ati the research difference is not that big i would say ;) im still waiting for Nvidias own AVC/VC-1 Decoder *g* but i doub't it will come that soon (seeing 3rd party licensing the PV1/PV2 runs so great and PV2/UVD is a direct playback on the Chip now with it's own Engine and Code in the driver package (nvucode.bin).
But i feel i have to leave to Ati again especialy as i still find Video Quality more important then 3D speed and their is not such a big difference between the 3D power if you look @ the lower Energy the RV6xx series needs compared to Nvidias (G8x) cores those 10 fps difference in some applications between the 8600GTS and X2600XT seems really normal to me (looking from the R&D perspective) but seeing that you can save 80 € and some more bucks in terms of Energy (Energy Prices go out of the roof slowly here in Germany) i don't think im gonna buy the Nvidia 8600GTS hehe, but this is a personal preference of mine im no fanboy as you see that i switch from one to the other if i think R&D is better on 1 side happens almost every next generation ;) except such situations as between AMD/Intel wich really where strange, but slowly also come to an end and normal R&D rules seem to set in so the distance is not that big anymore then it was @ the beginning with the C2D ;) )

PS: We should really start on developing Video GPU Encoding more think of the possibilty to use 4 cores like CPU(2) and GPU(2) simultaniously :D 2 cores do the Post Processing (Avisynth) and the others the Encoding or situations like 1 core does the Post 2 the Encoding and 1 the Decoding to see in near realtime what your final results will be, exciting to think about the possibilities.

[HowlerX]

This are my big wall o' TEXT.

Invariably, I always start to read your posts and just give up. Your lack of punctuation makes reading anything you post a real chore. And I really, REALLY have interest in this subject you are posting on.

Regardless, I find it unfortunate that Nvidia decided not to include full VC-1 acceleration in their latest cards. That and the fact that their driver support for WinXP (not to mention Vista) has gone down the drain will probably mean my first Radeon purchase in the coming months.

[CiNcH]

I have now found a problem with PureVideo HD 2. It does not seem to handle MBAFF of BBC HD correctly. Playback becomes jerky after a few seconds of proper decoding.
PAFF of German television H.264 HD channels is handeled correctly however.

[arfster]

Is that DVBviewer by any chance? There's a dvbsource latency option you can add that fixes it.

[CiNcH]

Different story ;) . The problem you are mentioning is related to CyberLink's "software algorithms" to decode H.264 that are causing trouble.

[RaggedEdge]

I have just pushed the PureVideo HD 2 engine within my GeForce 8600GTS a little bit. Therefore I have created a rather complex H.264 HD stream:

Encoder: x264 (svn-598 Build)
Resolution: 1080p (Full-HD)
Nominal Bitrate: 30 mbps (VBR)
H.264 Tools: i8x8 (High Profile), CABAC, Deblocking
Container: MKV

I have performed two passes which resulted in a pretty variable bitrate according to the complexity of the different scenes. Nominal bitrate was chosen to be 30 mbps, peaks even almost reached 50 mbps (26:35 minutes took 5.5GB).

Filter Chain:
- Haali Media Splitter
- CyberLink H.264 Decoder 7.x
- VMR9

PureVideo HD 2 did a great job on this sample. Even though it is specified to work with bitrates up to 40 mbps it even handeled the short 50 mbps peaks properly without any glitches. CPU usage hardly reached 5% on a 2GHz downclocked Core 2 Duo.

Disabling PureVideo HD 2 resultet in 50% CPU usage, but this time SpeedStep clocked the CPU mostly at 2.67 GHz.

I did not mux audio into the MKV container yet. I may do so at a later time with DTS track.

(tested under Windows XP with ForceWare Beta 165.01)

I notice you used VMR - in my own experiments I could never get full h.264 acceleration to work without EVR. I thought DXVA2 was only available in EVR and that it was required to do full hardware decode.

[RaggedEdge]

Is that DVBviewer by any chance? There's a dvbsource latency option you can add that fixes it.

I'm hoping the next round of driver, cyberlink and Haali splitter updates, begin to address these problems.

The Vista Beta drivers have been stuck at 158.45 for a long time now... maybe their actually working hard to fix this stuff.

[CiNcH]

I notice you used VMR - in my own experiments I could never get full h.264 acceleration to work without EVR. I thought DXVA2 was only available in EVR and that it was required to do full hardware decode.

True for Vista. Under XP, nVIDIA specified and implemented proprietary API's which are currently only used by CyberLink's H.264 decoder from PowerDVD 7.3.2911.

[RaggedEdge]

True for Vista. Under XP, nVIDIA specified and implemented proprietary API's which are currently only used by CyberLink's H.264 decoder from PowerDVD 7.3.2911.

That makes sense :)

Are we any closer to determining where the x264 MKV file hardware decoding is going wrong?

I.e. is it the Haali Splitter, Cyberlink's H.264 AVC Decoder or the construction of the MKV file itself.

[CiNcH]

Probably you should try a different MKV demuxer. It can't be a conflict between container and decoder as at the time video reaches the decoder it is nothing but raw H.264 material. The only problem I can think of is that the demuxer propagates wrong video information on the output pin. But why should the decoder only be affected when acceleration is enabled...

I don't even think that it is a demuxer problem. As I said, PureVideo HD 2 seems to be having problems decoding MBAFF'd source material. So this is probably the cause of your problem...

[RaggedEdge]

I don't even think that it is a demuxer problem. As I said, PureVideo HD 2 seems to be having problems decoding MBAFF'd source material. So this is probably the cause of your problem...

That's encouraging - it sounds like the problem you described could be fixed by a NVidia driver update.

Haali and Cyberlink don't seem to interested in this problem :(

[CiNcH]

OK, sorry, MBAFF works perfectly with PureVideo HD 2. It was problem with the player and the renderer in my case...

[RaggedEdge]

OK, sorry, MBAFF works perfectly with PureVideo HD 2. It was problem with the player and the renderer in my case...

Does that mean you can playback MKV files back fine too? Or just content from another HD source?

If you can playback MKV without the stuttering (20FPS) issue, then please tell us more...

[arfster]

Probably you should try a different MKV demuxer. It can't be a conflict between container and decoder as at the time video reaches the decoder it is nothing but raw H.264 material. The only problem I can think of is that the demuxer propagates wrong video information on the output pin. But why should the decoder only be affected when acceleration is enabled...


I'd thought something similar, but the same h264 video in another container format works fine, even when also played back through Haali. It also happens only with the 8500/8600 and 2400/2600, which perhaps suggests it's something odd about the fact these cards that do total bitstream offload rather than traditional acceleration?

Alternatively, could it be some buffering issue where the card doesn't receive enough data on time, so drops the frame rate by a fixed amount? It can't be a coincidence it dumps it down from 24 to exactly 20.

[RaggedEdge]

I'd thought something similar, but the same h264 video in another container format works fine, even when also played back through Haali. It also happens only with the 8500/8600 and 2400/2600, which perhaps suggests it's something odd about the fact these cards that do total bitstream offload rather than traditional acceleration?

Alternatively, could it be some buffering issue where the card doesn't receive enough data on time, so drops the frame rate by a fixed amount? It can't be a coincidence it dumps it down from 24 to exactly 20.

I guess the common denominator is the Cyberlink Decoder and Haali Splitter in that case, and the fault must lie in one or the other.

There are some buffer values in the Haali Splitter - are these relevant to the delay you mentioned?

[arfster]

I guess the common denominator is the Cyberlink Decoder and Haali Splitter in that case, and the fault must lie in one or the other.

There are some buffer values in the Haali Splitter - are these relevant to the delay you mentioned?


Tried those before, no luck.

Unfortunately we have no other mkv splitter, and no other decoder, so hard to tell :-)

[CruNcher]

After a long and nerve striking search
http://forum.doom9.org/showthread.php?p=1022197#post1022197

could be also your problems answer, try it :)

[RaggedEdge]

After a long and nerve striking search
http://forum.doom9.org/showthread.php?p=1022197#post1022197

could be also your problems answer, try it :)

Sounds like your on to something there CruNcher.

Keep us posted on your findings - you obviously know far more then most.

If there's any specific test you'd like us to try then let us know and I'm sure most of us would be more then happy to help out.

[morph166955]

Ok I just last night finished up my brand spankin new HTPC with a nice 8600GTS in it so I'm very interested in helpin out here if I can! My first question though is PureVideo HD part of the nVidia driver or is it a separate program like original PureVideo? I believe its the former since I for the life of me couldn't find anything to download/bu off of nVidia's site like I did with original PureVideo. My system is running Vista Ultimate 32-bit (and yes I want to be on 64-bit but I had 32-bit around which was free and legal for me to use since I won it from microsoft a while back). I have CoreAVC 1.3, ffdshow rev1324 from x264.nl and the current version of Haali from there as well loaded and running. I'm running the forceware 158.24 driver with my own tweak to let me run at 720p in it. I am noticing that my CPU usage even on high bitrate scenes is still pretty low (sub 40%). Is there a way to disable the gpu H.264 processing to see if its working?

I'm here to help so if theres any tests I can run to push this ahead let me know!

[arfster]

PVHD is a marketing term, and really a bit of stupidity by NVidia to confuse everybody :-)

For h264 acceleration, you need the right card (8600GTS = fine), right OS (at present Vista, XP in future), and a decoder that supports Purevideo2 (ie the fancy-ass bit that does h264 decoding in the 8500/8600). CoreAVC doesn't have any hardware acceleration support at all, and neither does ffdshow - at present, the only one that really works is PowerDVD 7.3.

[morph166955]

ok, so i will work on getting powerdvd then. is there any particular version of it I need? I heard that there is a bluray/hddvd version or something like that so i'm just asking so i get the right thing the first time.

EDIT: so did some more looking into it, i need powerdvd ultra i believe right?

[morph166955]

So I just ran some tests to see how my system would perform and I got some very interesting yet odd results.

First off, my test source was the original m2ts file from the xmen 3 bluray (yes the 20 some odd gig file). I decrypted it down to my hard drive so it was reading it from a 150GB WD Raptor drive. The specific spot that I use is right between 130k and 135k frames since it has some good runs around 20mbit/s but then also peaks up as high as 45mbit/s. This is being run straight through graphedit so that I know the exact filter chain its going through.

What I was seeing which boggled my mind is that no matter what the scene was (i even seeked to one that was down in the 7-9mbit/s range) the cpu just kinda floated between 45% and 75% (both cores running according to the graphs) and occasionally it would jump up to 100% for like half a second or less. The filter chain for this was:

m2ts -> cyberlink PDVD7.x H.264/AVC Decoder -> ffdshow Video Decoder -> video renderer

ffdshow was automatically in when i had graphedit render the file originally, it is however set to disabled for h.264 decoding and from what i was seeing it was only getting a YUY2 input from coreavc that it was dealing with. i also used ffdshow for their nice OSD to see the cpu usage and such. The one other thing in there (which may be in the chain as the m2ts) is the current haali splitter. I know it was running because I was watching it and its graphs also while watching the video in their little screen. It did run perfectly smoothly (atleast to my eye). I saw no visible a/v desyncs or any sort of jumpyness with the video at all and ffdshow stayed pegged at atleast 23.976 fps being pumped into it.

I think my next test is going ot be to remove the haali splitter to see if its causing any sort of difference. any other suggestions on what to try/set?

[morph166955]

so i did a little bit more playing around with graphedit and i think i found the problem. there are two decoders (well 3 actually but lets just go with 2 since i think one is irrelevant anyway for this). thers the H.264/AVC Decoder, and the BD-HD Decoder. if you go into the options, the BD-HD Decoder has the hardware acceleration box in it, the other one only has the DxVA option. I tried to force it to go to the BD-HD decoder but it could never build a filter chain no matter what i used to pipe it. I'm going to keep playing with it but if anyones got ideas let me know!

[arfster]

When ffdshow appears after the decoder like that, it's working as a postprocessor. To get rid of this, go into ffdshow and set codecs/raw video to disabled. Any postprocessor between the decoder and renderer will automatically stop hardware acceleration.

Oh, and you need to use EVR as the renderer, or you won't get any acceleraiton either (WMP or PDVD do). When you have acceleration working, you'll notice the cpu dropping to <2%, and the pin output of the video decoder will be called dxva.nv12 or something similar (dxva=hardware acceleration).

The BDHD decoder is something else entirely, ignore that, it will never work outside PDVD.

[CruNcher]

And don't forget with XP you won't get any accelleration with PV yet only UVD (ATI HD2400/2800 series) works their as of now Nvidia seams to be ultra slow in porting their new Hardware accelleration code to the XP drivers.

@arfster
Mediacoder(mencoder)/Avidemux are bugged in terms of .mp4 muxing seams they use libavformat for .mp4 muxing and that is not working correctly with B-frames yet, that coused the problems for me with Cyberlinks Decoder.
What i said about direct_pred in the post to akupenguin is not quiet right it's working fine (at least with the encoding settings i use now,seams space was running out so the files couldn't mux sucessfull (dumb mp4box temp file creation) ;) ) but the final .mp4 from both Mencoder and Avidemux are wrong and you have to remux them to repair it, also as stated by Mencoder when useing the libavformat muxer the files gonna playback in Mplayer/VLC and such but aren't standard complaint and so can bork and they definately do bork with Nvidias Hardware accelleration via Cyberlinks Decoder.

PS: And the best thing is look @ all the Video Converters (GUis for Mencoder/ffmpeg) on the market that use libavformat they are borked too, they even warn the people with the i_certify_that_my_video_stream_does_not_use_b_frames (option you have to set before muxing would work) thing and a big fat warning message of playback problems that could occour with such libavformat .mp4, but it seams many think this is only meant for .avi (me did too), and the Avidemux author made the same mistake, it seams it's useing libavformat for muxing .mp4 so it should warn people about useing b-frames as mencoder does.
Better would be to use gpac (mp4box) or even my altime favourite mpeg4ip (mp4creator wich doesn't do this shit temp file creation on win32 like mp4box (when muxing non direct), but it needs to be enhanced with some mp4box features like branding and stuff) :P

[RaggedEdge]

When ffdshow appears after the decoder like that, it's working as a postprocessor. To get rid of this, go into ffdshow and set codecs/raw video to disabled. Any postprocessor between the decoder and renderer will automatically stop hardware acceleration.

Oh, and you need to use EVR as the renderer, or you won't get any acceleraiton either (WMP or PDVD do). When you have acceleration working, you'll notice the cpu dropping to <2%, and the pin output of the video decoder will be called dxva.nv12 or something similar (dxva=hardware acceleration).

The BDHD decoder is something else entirely, ignore that, it will never work outside PDVD.


Have you found anyway of getting hardware acceleration working in Vista 32Bit MCE?

My CPU hits a 100% with H.264 files in MCE, and I haven't found any registry settings that would allow me to set Cyberlink's AVC H.264 decoder as the default. Or could this be an EVR problem in MCE?

[morph166955]

My vista-32 system defaults to the cyberlink decoder as long as i have h.264 shut off in ffdshow. im goign to attempt to disable the raw video part of ffdshow also as mentioned earlier. my E6600 touches 100% for a brief moment in a crazy high bitrate 1080p scene so im not really overly worried about this working immediately since my cpu is doing a sufficient enough job but i would like it working either way since thats why i paid for that card.

[morph166955]

I have modified the ffdshow settings and removed the rawvideo option so it doesnt even show up on the graph now. So as it stands my graph is just:

m2ts (haali) -> cyberlink H.264/AVC Decoder (PDVD7.x) -> video renderer

that doesnt do anything in terms of passing it off. my cpu still is around 45-65% exactly like before. I cant for the life of me get the BD/HD decoder to work which is the only one that specifically says Hardware Acceleration in the options. anyone else got an idea?

[arfster]

"Video renderer" is VMR7, and in Vista h264 acceleration only works with EVR as the renderer.

[CruNcher]

are you sure -> video renderer is capable of hardware accelleration in your vista case DXVA 2.0 ? i doub't it try "Enhanced Video Renderer" or "Video Mixing Renderer 9 (for XP DXVA 1.0)" :)

PS: Huh hehe arfster was faster :D

[morph166955]

ok...ill try that. Is there a more full name to EVR so I know what I'm looking for?

[RaggedEdge]

EVR = Enhanced Video Renderer, as per Cruncher's post.

I just tried the Vista 32Bit 162.15 driver - the 20FPS bug remains (much like we expected!).

On the postivie side, the new drivers have completely fixed an overscan issue with my Samsung Plasma TV. Although, it takes a fluke to get it working - NVidia are a disaster in the HTPC market at the moment!

Thought: I wounder how difficult it would be to write a H.264 hardware decoder for PureVideo2? I would imagine the code would only have to grab the raw H.264 data, and pass it into the PureVideo2 API for decoding.

I maybe missing a million tricks here, but it sounds straightforward in principle, given the hardware takes care of everything... right?

[morph166955]

Ooooooo new drivers? I shall have to investigate!

I'll try the EVR tonight to see if that fixes things. Can anyone think of anything else that I can try if that fails? I'd like to generate a list of things to try through the day today so that I have more then a few minutes worth of things to play with tonight just in case.

Also, I was reading earlier in this thread about possible problems with the haali splitter, is that still the case or was that decided to be a non issue? I know that my m2ts file is being processed via haali right now so I would like to know that isnt causing a problem.

[CruNcher]

@all
New Cyberlink Decoder and Black Screen/Slowdown problems fixed a Blu-Ray stream (.m2ts) bug in Haalis Splitter found it seams (frame skipping)

http://forum.doom9.org/showthread.php?p=1023806#post1023806

[morph166955]

IT WORKED!!!

when I forced to "haali -> cyberlink decoder -> EVR" in graph edit I got cpu percentages of 4-7%!!!!!!

Now the question is how do i get that to work in vista media center? Vista is definitely grabbing the standard video renderer instead of the EVR to do its work and I'd really enjoy passing off my video to the GPU instead of the CPU when I watch my stuff through media center like I want to.

[Theliel]

Media center/WMP in vista use EVR, so you only need force Cyberlink decoder for all H264 content. change merit in gspot for example for Cyberlink h264/avc decoder and set this to MERIT_PREFERRED

[AKarpo]

IT WORKED!!!

when I forced to "haali -> cyberlink decoder -> EVR" in graph edit I got cpu percentages of 4-7%!!!!!!

Now the question is how do i get that to work in vista media center? Vista is definitely grabbing the standard video renderer instead of the EVR to do its work and I'd really enjoy passing off my video to the GPU instead of the CPU when I watch my stuff through media center like I want to.

Nice, nice. What are your hardware specs/setup? Are you getting these results with .MKV playback? Do tell.

[morph166955]

I'll reconfirm with mkv, i confirmed it with a raw m2ts file i extracted from a bluray disc. I figured if nothing else, that should work. I'll test it with an mkv in a few minutes and report back. I'll post the specs then also

EDIT: Most definitely working with mkv files. I've got one playing right now through graphedit with the same chain as before and im averaging 2% cpu usage, ive even seen it drop to 0% a few times although i dont quite believe that. Scenes were explosions/high motion so I should have seen at least something on it but not even a bump.

I think its safe to say, this thing works! Now I gotta get media center to just handle it properly and im set!

@Theliei
can you be more specific to how to do that or provide a link of some sort to the software you mentioned? i'm not too up on the priorities and matches and all of that. THANKS!

[AKarpo]

I'll reconfirm with mkv, i confirmed it with a raw m2ts file i extracted from a bluray disc. I figured if nothing else, that should work. I'll test it with an mkv in a few minutes and report back. I'll post the specs then also

EDIT: Most definitely working with mkv files. I've got one playing right now through graphedit with the same chain as before and im averaging 2% cpu usage, ive even seen it drop to 0% a few times although i dont quite believe that. Scenes were explosions/high motion so I should have seen at least something on it but not even a bump.

I think its safe to say, this thing works! Now I gotta get media center to just handle it properly and im set!

@Theliei
can you be more specific to how to do that or provide a link of some sort to the software you mentioned? i'm not too up on the priorities and matches and all of that. THANKS!

Could you maybe include a step by step process that would explain to someone who is not familiar with graphedit as to how to "force" this; "when I forced to "haali -> cyberlink decoder -> EVR" in graph edit I got cpu percentages of 4-7%!!!!!!". I've got Haali and the cyberlink decoder, but I've never used graphedit to manipulate how the stream is processed/decoded. I've used graphedit before, however I'm having difficulty finding EVR in any of the filters that I can insert.