Hardware Accelerated Video Encode

By Craig Hurst (Intel) (5 posts) on July 23, 2009 at 2:47 pm

This is another follow up to my previous post asking media developers for input. Last time I asked about the importance of HW accelerated video decode, but actually encode acceleration would be a far better place to drive performance for video editing or transcoding. The challenges I've heard from developers has been the lack of a standardized interface to do so. Yes decode interface exists in DXVA, but not for encode. I'm curious how much of an issue is this for developers? If a standard API existed that offered simple access to HW accelerated encode across a broad range of hardware, would developers be interested? What considerations or capabilities (like pre-processing for example) should be supported? Let me know your thoughts.

Categories: Media

Comments (7)

July 24, 2009 3:16 AM PDT


Neil		 Yes, I and my colleagues would definitely be interested in APIs that provided HW accelerated video encoding and decoding.

As an aside, is there an OpenGL equivalent of DXVA?
July 24, 2009 1:35 PM PDT

Maxym Dmytrychenko (Intel)
Total Points:
1,320
Status Points:
820
Brown Belt
 I would recomend to start on some baseline.

Suggestion for the such baseline - Media Foundation from Windows 7 or in details
http://msdn.microsoft.com/en-us/library/bb970511(VS.85).aspx
July 27, 2009 8:52 AM PDT


Bob Tasa		 Both encoding and decoding is important. It would be interesting if you target certain codecs such as DVCProHD and MJPEG as well as others. Does this mean there will be additions to handle 8 or 10 bit YUV data directly?
September 2, 2009 2:16 AM PDT

Igor Levicki
Total Points:
10,865
Status Points:
10,865
Black Belt
 @Maxym Dmytrychenko (Intel):

Your suggestion is OS dependent which is bad.

@Craig Hurst (Intel):

In my opinion the worst problem is high quality deinterlacing which is painfully slow even on a Nehalem CPU.

High quality deinterlacers (check mvBobMod and TempGaussMC AVISynth scripts to get an idea how they work) employ motion search, motion estimation, and motion compensation which practically duplicates those stages from the encoding pipeline and you certainly know those stages are the slowest.

Having high quality HW accelerated deinterlacer would thus also speed up the encoding process even if deinterlacing is not needed because it would expose motion search, motion estimation and motion compensation primitives.
September 24, 2009 1:29 PM PDT

Craig Hurst (Intel)
Total Points:
455
Status Points:
405
Green Belt
 Igor, we've just released the gold version of the Intel Media SDK (http://www.intel.com/software/mediasdk) that exposes HW acceleration for VPP functions including deinterlacing on G45/GM45 chipsets today and on future graphics products. It's free to download, and may be helpful.
October 5, 2009 9:47 AM PDT

Art Scott
Total Points:
25
Registered User
 Hi Criag.
I'm passionate about Larrabee HW acceleration.
See my YouTube video to try to comprehend:
http://www.youtube.com/watch?v=xbfARUZmxz8
Note Permon, 4 core 100%.

I studied my Intel SWPP Gartner report ... seemed to indicate
a consolidation of CODECs around H.264. We all love standards, that's why there's so many.
Gartner predicts that by 2013, 95 percent of video will be H.264 ...
So do H.264 really well.

Also "Running advanced multicore machines with today's software is like "putting a Ferrari engine in a go-cart," he said. "

So if you can tell me, since publically and privately available articles (I think I've read all of them), and Larrabee SDK and/or beta systems seem scarce as hens teeth, and harder to get ... (wish it was different, i.e. Intel should ENGAGE, LOL, ... no really)

So tell me ... how many different H.264 streams will it be possible to DECODE concurrently and in parallel with Larrabee?
How complex, exciting, dazzling can I make my art?

I fear that Intel has compartmentalized their Larrabee dev work into 3D game, and, Vid Codecs ...
sort of synth and vid ... not sure what sort of design meeting discussions that might create ...
I want them to work fantastically together.

Tell me something encouraging; even if it's just marketing.

Peace Love and Happiness
Art Scott
Artist, Semasiographologist
October 21, 2009 11:41 PM PDT

dierkschmedes
Total Points:
5
Registered User
 Hi Craig,
the architectural design with a "common" HW independent high level API (front end) is great. We hope to see more HW specific (e.g. specialized FPGA's or GPU's for H.264 encoding) back end implementations in the near future. To have a further "API" on top like DirectShow filters is great but should be only on top because other OS's like Mac OS or Linux doesn't have it. An interface for/to/with OpenGL would be great to - similar to the Direct3D Surfaces.
One last feature we are looking for is the capability to stream the encoded video via network. This requires also that the encoding will be done in realtime.

Dierk

Trackbacks (3)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*