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]

Originally Posted by 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.

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]

Originally Posted by KoD

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]

Originally Posted by 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.

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]

Originally Posted by 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.

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]

Originally Posted by 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)

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 (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 )







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 (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 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]

Originally Posted by CruNcher

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]

Originally Posted by 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)

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]

Originally Posted by arfster

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]

Originally Posted by CiNcH

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.