[vlc-devel] Video processing APIs
agent_007 at luukku.com
Tue May 19 08:39:36 CEST 2009
Andre-John Mas kirjoitti 19.05.2009 kello 02:12:
> On 18-May-2009, at 18:03, Jean-Baptiste Kempf wrote:
> > On Mon, May 18, 2009 at 11:27:02PM +0300, Rémi Denis-Courmont wrote :
> >> Slightly up the stack, it is just as messy with those challengers:
> >> - VA-API (Intel)
> >> - VDPAU (NVidia)
> >> - Xvideo BA (AMD/ATI)
> >> - DirectX VA (Microsoft)
> >> - OpenMAX integration layer
> >> - I wonder what Apple is doing?
> >> And of course, we still have Xvideo Motion Compensation on older
> >> hardware.
> > Windows states of affair seems easy: DxVA and almost everyone
> > implements
> > it.
Problem with DxVA is the limitations that make some videos undecodable.
This isn't yet huge issue, but there already hundreds of x264 encoded videos that won't work with DxVA because they use wrong profiles/levels.
> > Linux is a bit more complex, but VAAPI seems to be nice, because there
> > is already a working VDPAU backend and a half-working XvBA backend to
> > it.
> > Apple seems to speak about OpenCL all the time, but I haven't seen a
> > video decoding API (except QT X, maybe) using GPU. And I doubt that
> > they
> > will release one since they don't think anything else than QT should
> > decode video. And they are so open lately...
> > CuDA and OpenCL are more for video filtering, I guess...
CuDA has video decoders, they are usable e.g. in TMPGenc Xpress 4.0 and in CoreAVC.
And IMHO the OpenCL is the best option to go. It can be easily used for DSP (Wiki example shows simple FFT)
http://en.wikipedia.org/wiki/OpenCL#Example so it can avoid the decoding limitations of DxVA. Also it doesn't require another video output module and OpenCL support can be implemented to any device (it doesn't have to be GPU). Best part is that we (VLC devels) don't really have to do anything, because someone is going to eventually implement the OpenCL support to libavcodec.
> Although we do risk some fragmentation, it is certainly best to have
> an implementation that uses one of the APIs, than wait for ever. I
> also agree that voting with code is better than endless 'comity' style
> discussions. Better have something that we can use, than a pipe dream.
> I certainly look forward to the results of Etienne's summer of code.
> Looking at OpenMax, this appears to be higher level then OpenCL, so it
> is quite possible we will see OpenMax based codecs that will take
> advantage of OpenCL for its low level work. I would imagine that with
> OpenMax we would see the implementation of certain codecs move out of
> the ffmpeg/VLC space and into something that is accessible more widely
> at an OS level?
> ref: http://www.khronos.org/openmax/
> Reading further I see that VA-API is at the same level as OpenMax, so
> likewise it can base itself on whatever is available, whether it be
> OpenCL or DirectX Compute. I assumed, incorrectly, that VA-API was at
> the same level as OpenCL.
> ref: http://en.wikipedia.org/wiki/VaAPI
> As to OpenCL, we will probably see more happening once Apple has
> released Snow Leopard, and from what I have read there is certainly a
> want to push this as an industry standard. I suppose the deciding
> factors will be the terms of licensing and the ease of implementation.
> OpenCL is more of a number crunching API, that can take advantage of
> specialized processors, such as what is found in the form of GPUs.
> ref: http://www.khronos.org/opencl/
> From what I have gathered Nvidia has already shown interest to
> migrate their PhysX from CUDA to OpenCL, and they have even indicated
> they are interested in making it on ATI cards - I would guess this
> plays into making PhysX more interesting to potential licensees and
> would also help reduce the cost of code maintenance.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
Luukku Plus paketilla pääset eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku
More information about the vlc-devel