Video Decoding Questions for Software Developers

[Esotic]

Just cuz I'm curious about this...

Isn't MPEG1/2 decoding built into most graphic chipsets? If so, wouldn't MPEG be the video format of choice for speed reasons?

Can any of the software developers out there comment on this? Does your program make use of hardware acceleration or is there some reason that it can't?

Enquiring minds want to know,

-Esotic

[Esotic]

Hmmm... here's some DirectX info on the MSDN.

http://msdn.microsoft.com/archive/de...celeration.asp

[Toolmaker]

Originally posted by Esotic
Just cuz I'm curious about this...

Isn't MPEG1/2 decoding built into most graphic chipsets? If so, wouldn't MPEG be the video format of choice for speed reasons?

Can any of the software developers out there comment on this? Does your program make use of hardware acceleration or is there some reason that it can't?

Enquiring mind want to know,

-Esotic

I think I know what you mean. And if so, the answer is yes (with a few twists).

You are thinking that any system that pumps content in kernel mode directly from the HD to the video card will have lower latency than one that thunks to user mode and uses a software based codec.

Right?


Of course if you want to scrub, or play it backwards, then every frame must be a key frame. No problem. Write your own off-line compressor. Don?t abandon MPEG 2.

Right?

There is another video standard built into most video cards called SD-DVCR (aka SMPTE 314M / IEC 61834) that IMO, is also a very good choice, because every frame is always a key frame. Some folks will stumble over the interlace issue, but again, the solution is to write your own off-line compressor (to guarantee 100% correlation between fields).

I would love to connect with any other software developers who understand what I?m talking about. I?ve already done a great deal of work in this area.

The trouble I have is this: I?m a 44 year-old adult, and I can?t afford to work for free.

[Esotic]

I'm just curious as to whether or not we as the VJ developer community are missing some hardware acceleration options.

I do all my VJ programming as a hobby, so I'm all about kickin' it open source.

And I love garlic cheese bread,

-Esotic

[Toolmaker]

Originally posted by Esotic
I'm just curious as to whether or not we as the VJ developer community are missing some hardware acceleration options.

I do all my VJ programming as a hobby, so I'm all about kickin' it open source.

And I love garlic cheese bread,

-Esotic

I wish my landlord loved garlic cheese bread.

As long as VJ apps continue to use Quicktime or Jitter as their rendering engine, they will be missing some hardware acceleration options.

The next big leap (at least in the Microsoft world) is to begin writing virtual kernel-streaming device drivers and wire them directly to the graphics card with DirectShow.

[VJamm]

mmm - well on windows most people are using DirectShow MPEG decompression, and without specialist hardware, I'm not convinced there's any hardware MPEG decompression to be had there, certainly not if you want to do anything with the frames.

The DirectShow architecture does allow for stuff to be dropped onto hardware when it's installed in your windows - I think the guys up at Camart in Cambridge have some hardware decompression / compression stuff going on in the version of the VJamm ScratchPad project they have running on a Perception video editing system there - but practically speaking I don't think we're missing much - stop me if I'm wrong - as regards normal VJsoftware running on laptops / shuttles etc.

Russell

[elbows]

I didnt think there were many VJ apps that used Quicktime or Jitter as rendering engine on the PC?

[elbows]

Originally posted by VJamm
mmm - well on windows most people are using DirectShow MPEG decompression, and without specialist hardware, I'm not convinced there's any hardware MPEG decompression to be had there, certainly not if you want to do anything with the frames.

The DirectShow architecture does allow for stuff to be dropped onto hardware when it's installed in your windows - I think the guys up at Camart in Cambridge have some hardware decompression / compression stuff going on in the version of the VJamm ScratchPad project they have running on a Perception video editing system there - but practically speaking I don't think we're missing much - stop me if I'm wrong - as regards normal VJsoftware running on laptops / shuttles etc.

Russell

Oops my last post was written before yours appeared, sorry about that.

Anyway I broadly agree with you there, and as CPUs etc have got faster I dont see video decompression as a major use of my system resources anymore, its become less of an issue as the years fly by.

Still having said that, Id like to know if there is anything real to be gained in practical terms from latest nvidia graphics spec waffling on about decoding and encoding features, or whether its mostly useless hype.

[sleepytom]

i guess its the old up down up thing again...

if there is hardware decompression on GPU then thats all good and well but to get the frames back to do any software processing would mean getting all the decompressed frames back down the agp before sending them up again for output.

i guess nvidia would like us to avoid any cpu effects processing and do it all up on the graphics card so the file decompression would take place before gpu / pixelshader effects and youwould just send it up the agp once.

but nvidia don't have any intrest in older hardware where we might like to be able to support graphics chipsets that are a few years old (like most laptops have)

the current developments in nvidia land seem to be geared towards low CPU use HDTV playback

[Toolmaker]

Originally posted by VJamm
...certainly not if you want to do anything with the frames.

Hi Russell.

I guess it depends on what you want to do.

Look at the Cube sample in the DX9 SDK.

What?s going on there?

Who?s doing the thinking?

Professor ATI, or Professor Intel?