The current video pipeline contains many video frame copies, which is a waste of CPU cycles and memory. To be optimal in the off-main-thread compositing context, we need to decode video frames directly into some memory that can be accessed by the compositor. This memory can be gralloc on platforms that support it, or shmem, or whatever we have available. To do this we need an API in the decoder libs with callback functions called by the decoder so that gecko can allocate the appropriate buffer type, and callbacks to keep track of the reference counting of these buffers.

Here is an initial implementation of a modified version of the API proposed in bug 643454. This version of the API has been updated to work with Android's gralloc (which requires rectangular textures storing memory in a 2D-cacheable layout, and which can be remapped by the hardware), and to handle some of libtheora's post-processing cases, in which the luma plane and chroma planes are taken from a separate set of buffers (because post-processing on the chroma planes is skipped, so using the same set of buffers would require a copy).

Thanks Nicolas! Will start working on this soon :)

I have been very busy at work lately. Will work on this bug soon. Sorry about that.

(In reply to Luis de Bethencourt [:luisbg] from comment #6) > I have been very busy at work lately. Will work on this bug soon. > > Sorry about that. Don't worry Luis, I myself have been meaning to give you some pointers and provide whatever you need to get started on this, and I haven't got around doing it because I am busy as well. Don't hesitate to ping me for guidance by email and/or irc about this bug.

Will do Nicolas! Thanks :)