Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing

[STaRGaZeR]

Originally Posted by nevcairiel

After all, the important part is playback (at least for me), and if i can benchmark it at 300 fps, doing 24 fps in playback (or even 60 fps) is done at nearly no load at all.

Maximum speed is important for seeking too. Seeking with ATI's DXVA can be a pain (max. is only ~2x playback speed), while it's fast as hell with QS or software.

[CruNcher]

@ Egur
That MFX driver thing is definitely not UDA style like im used to hehe
so you have different directories and the same size .dll that get installed but based on Hardware Detection in the installer so the driver will get pretty big over the time with always cloning the same components for different hardware revisions with haswell their will be 3 by then, though ILK is not in that driver release anymore

That leaked Driver also seems to have OpenCL 1.1 support

Though what is strange is that they're actually 2 different libmfxhw revisions for both platforms i wonder how the installer makes the decission which to copy in the common files folder for general application use and why 2 revisions i guess 1 of those 2 fixes the VC-1 interlaced decoding issue

Current libmfxhw 18 Oct 2011

2.11.10.18
2.0.556.36397


New Driver libmfxhw 1 16 Dez 2011

3.11.12.16
3.0.253.38506

New Driver libmfxhw 2 19 Jan 2012

3.12.1.19
3.0.255.38772

both seem api version 1.03
the old one api version 1.01

[RBG]

Originally Posted by amtm

Because it's still used widely in TV broadcasting and for DVDs (you know those optical discs that still outsell Blu-Ray by quite a large margin)?

So what? How do you think what percentage of people are using their PC for DVD playback? Compared to all that huge amount of sold DVD's they are absolute minority. And the idea of watching DTV on a computer sounds just ridiculous to me.

Originally Posted by amtm

You ask why people want to benchmark a format that is still widely used for video?

Well, on PC it is not that widely used nowadays compared to h.264 or vc-1, moreover MPEG-2 itself is not a power hungry format, even an entry-level SB cpu can handle it easily without any kind of hardware accelerated decoding.

[CruNcher]

I got it (pretty windows standard actually)
seems Asus as Vendor was not in the list i added my Subsys Hardware ID and the installer accepts it

Jep seems to be a OEM ISV Driver

SLAOEMISV1/RBK/01-21-00 <- Software License Agreement OEM ISV

Voila installed

http://img851.imageshack.us/img851/1...verinstall.png

New Driver libmfxhw 2 19 Jan 2012

3.12.1.19
3.0.255.38772

was chosen by the installer


New Optimal 3D mode

http://img11.imageshack.us/img11/7656/optimal3dmode.png

could be something like Catalyst AI or some Optimization for Specific Engines (Games,Applications)

Design Order of the PP functions changed a bit

http://img195.imageshack.us/img195/363/designorder.png

2622 WPI :

http://img580.imageshack.us/img580/4057/2622.png

2626 WPI :

http://img836.imageshack.us/img836/8617/2626.png

GPU-Z still a no go

http://img27.imageshack.us/img27/163...capsviewer.png


Fixed as expected:

http://www.mediafire.com/?0ljab8afkp1jm47

[Mixer73]

Originally Posted by RBG

So what? How do you think what percentage of people are using their PC for DVD playback? Compared to all that huge amount of sold DVD's they are absolute minority. And the idea of watching DTV on a computer sounds just ridiculous to me.

Maybe I'm wierd but I watch MPEG2 on my computer every day. We still have MPEG2 DVB-T broadcast and I have dual head so I can watch TV on one screen and do other stuff on the other inbetween watching. More comfortable than using a laptop on the couch.

Originally Posted by RBG

Well, on PC it is not that widely used nowadays compared to h.264 or vc-1, moreover MPEG-2 itself is not a power hungry format, even an entry-level SB cpu can handle it easily without any kind of hardware accelerated decoding.

See above. However I get Nev's comment that MPEG2's simplicity makes it not the best tool for comparitive performance benchmarking. However its still a very important and oft-used format.

[NikosD]

Originally Posted by CruNcher

@ Egur

That leaked Driver also seems to have OpenCL 1.1 support

Originally Posted by CruNcher

GPU-Z still a no go

http://img27.imageshack.us/img27/163...capsviewer.png

I have told you before, but you didn't get it.

There is no such thing as HW OpenCL support for SandyBridge GPU.

It's only software support (CPU).

Did you actually test HW OpenCL support with the new driver ?

[ramicio]

I had to turn off "full floating point processing" in the renderer settings, and it works now.

[CruNcher]

Originally Posted by NikosD

I have told you before, but you didn't get it.

There is no such thing as HW OpenCL support for SandyBridge GPU.

It's only software support (CPU).

Did you actually test HW OpenCL support with the new driver ?

I said its OpenCL nothing more though it's anyway surprising don't you think that they provide the OpenCL support for the CPU with the GFX driver

[NikosD]

OpenCL support was there from the beginning.

What is the change with the new driver ?

OpenCL usually is paired with GPU because it's a lot faster than CPU (for the specific tasks)

And because Ivy will support HW OpenCL 1.1, they probably put it in GPU drivers from the beginning.

As a matter of fact, where else could they put it ?

GPU is inside CPU.

CPU and GPU drivers, go together.

[CruNcher]

Going way to oftop

https://forum.doom9.org/showthread.php?p=1559021

[RBG]

Originally Posted by Mixer73

We still have MPEG2 DVB-T broadcast and I have dual head so I can watch TV on one screen and do other stuff on the other inbetween watching.

I've got a hardware decoder for that stuff, and it is way better than a PC in terms of power consumption and reliability.

Originally Posted by Mixer73

See above. However I get Nev's comment that MPEG2's simplicity makes it not the best tool for comparitive performance benchmarking. However its still a very important and oft-used format..

As for me, there should be more VC-1 testing, as it really requires hw acceleration more than other formats, mostly because it lacks decent software decoders.

[NikosD]

"According to Digitimes, a weak global economy has caused a build-up of Sandy Bridge inventory both at Intel and OEMs.

If Intel went ahead and mass released Ivy Bridge in April, these Sandy Bridge parts would have to be thrown away or sold at much lower prices.

Now the plan is to release some Ivy Bridge chips in April, but postpone mass shipments (presumably of consumer-oriented parts) until after June.

System builders should still be able to get their hands on some mid- and high-end Ivy Bridge chips in April."

[nevcairiel]

All that means is that the low to mid-end dual core chips will be delayed. I can still get me a quadcore to build my high-end HTPC.

[CruNcher]

Nah i wouldn't buy Ivy Bridge i'll wait for Haswell the amazement will be much heavier by then, even if its a big change having the first Tri Gate Processor but i want the even more advanced one not the first one

Though since the first days i was always jumping forth and back from AMD/INTEL (with a short stay with Cyrix) and i guess not much will change and currently im in the INTEL stage again, though i want to see how Fusion Develops too and so i guess it could happen that the Next Bulldozer Generation is in between the Haswell shift

[STaRGaZeR]

Eric, take a look at this post. Forcing nOutputQueueLength in the QS config to 8 seems to fix it, but maybe there's more to it, related to your recent changes.

EDIT: after some time there is stutter here and there even with 8, just like with 16 but sporadic.

[nevcairiel]

Hey Eric,

it seems like the QS decoder isn't particularly happy with H264 in Annex B format (MEDIASUBTYPE_H264). I've been trying to improve rtp/rtsp streaming, and i figured with such a volatile stream it might be beneficial to let the splitter keep it in its original form (which is H264 AnnexB), however when i feed that to your QS decoder through LAV Video, i get nothing (only black screen, it doesn't seem to output any decoded frame)
Any ideas? I can try to upload a test build that does this so you can try to reproduce.

[egur]

Originally Posted by STaRGaZeR

Eric, take a look at this post. Forcing nOutputQueueLength in the QS config to 8 seems to fix it, but maybe there's more to it, related to your recent changes.

EDIT: after some time there is stutter here and there even with 8, just like with 16 but sporadic.

I can't test live TV, but Nev's point on the high delay during playback affecting live TV makes sense. Long queues provide good performance and good frame rate calculations. The latter isn't important for LAV as he disables the feature.
In order to reduce latency in live playback, the queues need to be much shorter. Since my decoder doesn't know the context, maybe the fix should be in the DirectShow decoder filter (LAV, ffdshow).
@Nev, any suggestions?

Originally Posted by nevcairiel

Hey Eric,

it seems like the QS decoder isn't particularly happy with H264 in Annex B format (MEDIASUBTYPE_H264). I've been trying to improve rtp/rtsp streaming, and i figured with such a volatile stream it might be beneficial to let the splitter keep it in its original form (which is H264 AnnexB), however when i feed that to your QS decoder through LAV Video, i get nothing (only black screen, it doesn't seem to output any decoded frame)
Any ideas? I can try to upload a test build that does this so you can try to reproduce.

I have a single clip with this subtype (MEDIASUBTYPE_H264) so my testing so fat was limited (works fine BTW).
The HW decoder only accepts this sort of stream. For AVC1 I have to convert it to such a stream.
I can try to reproduce, sure. Please supply a problematic clip. I don't think I need a your build unless you change the stream somehow.
Also, does it work with another splitter (Haali)?

[nevcairiel]

Originally Posted by egur

The HW decoder only accepts this sort of stream. For AVC1 I have to convert it to such a stream.
I can try to reproduce, sure. Please supply a problematic clip. I don't think I need a your build unless you change the stream somehow.
Also, does it work with another splitter (Haali)?

Its a streaming source, i cannot make it into a clip (and Haali doesnt support streaming protocols)

[nevcairiel]

Originally Posted by egur

I can't test live TV, but Nev's point on the high delay during playback affecting live TV makes sense. Long queues provide good performance and good frame rate calculations. The latter isn't important for LAV as he disables the feature.
In order to reduce latency in live playback, the queues need to be much shorter. Since my decoder doesn't know the context, maybe the fix should be in the DirectShow decoder filter (LAV, ffdshow).
@Nev, any suggestions?

Well how do your queues work? Does it not output anything until they are full?
Is it maybe possible to decrease the delay without cutting into the performance so drastically? (Using queues at 0 is quite the performance impact right now)

Specifying a context would require somehow listing all sorts of TV applications, which would be an impossible task.

[egur]

Without being able to debug, I can't root cause the decode problem (H264 fourcc). If there's a streaming setup I can run using a web source and not a live TV source then please specify the full setup and I'll debug it.

Regarding queue length and performance, I'm not sure why lengthening the queues remove such a big bottleneck. It took me a couple of hours tweaking with v0.22 which had less features than 0.26 (0.22 didn't have async decode or mt copy). The only way I managed to keep 0.22's performance high is to always use queues, even if they are not needed in a functional way (no need to calc time stamps). Applying that to 0.26 with some other fine tuning created v0.27.
I'll try to further root cause the bottleneck and hopefully use shorter queues.

If all else fails, we can go the GPU driver way - use profiles (e.g. cheat ). High queues for benchmarks and low/zero queues for the rest.