Encode frames with vpu directly from framebuffer

cancel
Showing results for 
Search instead for 
Did you mean: 

Encode frames with vpu directly from framebuffer

Jump to solution
723 Views
alexandershashk
Contributor II

Hello,


I have a task to broadcast an x11 desktop as h264 stream, but desktop capturing is terribly slow on fullhd utilizing only x11 api. As a workaround I want to point vpu directly on framebuffer:

  1. get fb_info with ioctl()
  2. mmap() fb
  3. pass fb pointer to vpu.

Will this work and I'll have best possible performance or I'll get problems?

PS: I'm using custom wandboard implementation with ubuntu 13.10, my xorg.conf is pretty usual: vivante driver and /dev/fb0 as framebuffer. GLX and EGL are functional, so graphic stack seems ok. Or if you have any ideas how x11 capturing can be improved - please share them.

Thanks

Labels (4)
1 Solution
71 Views
EricNelson
Senior Contributor II

Hi Alexander,

This could work for you except for one thing... The VPU encoder(s) mostly want an array of frame-buffers, and the X11 drivers don't currently support even double-buffering.

The encoders generally need at least two, but often three or more frames to build "B"etween-frames inside a GOP (Group of Pictures).

Even if they did support this (as Wayland does), coordinating ownership of the buffers (releasing them back to the display when the owner is done with them) would be tricky at best.

You might consider a simpler form of DMA'ing from the frame-buffer into your next encode buffer at each vertical sync

(or perhaps every other to get 30fps from a 60fps display). If used properly, either the IPU or GPU can do the DMA transfer for you.

View solution in original post

0 Kudos
3 Replies
72 Views
EricNelson
Senior Contributor II

Hi Alexander,

This could work for you except for one thing... The VPU encoder(s) mostly want an array of frame-buffers, and the X11 drivers don't currently support even double-buffering.

The encoders generally need at least two, but often three or more frames to build "B"etween-frames inside a GOP (Group of Pictures).

Even if they did support this (as Wayland does), coordinating ownership of the buffers (releasing them back to the display when the owner is done with them) would be tricky at best.

You might consider a simpler form of DMA'ing from the frame-buffer into your next encode buffer at each vertical sync

(or perhaps every other to get 30fps from a 60fps display). If used properly, either the IPU or GPU can do the DMA transfer for you.

View solution in original post

0 Kudos
71 Views
alexandershashk
Contributor II

Hi Eric,

Thank you for taking time to answer. This is very useful advice. I was not aware that user application should manage extra buffers for encoding GOPs. I supposed this is hidden from user application.

Question about DMA. I clearly understand that DMA frees cpu from moving bytes from one place to another, so cpu can do something other while dma is working, but is dma faster than memcpy on imx6? If there only benefit that dma just frees cpu and actually requires same time to finish as memcpy, then I'd prefer simpler memcpy for my case.

0 Kudos
71 Views
EricNelson
Senior Contributor II

Hi Alexander,

Yes. DMA will be faster for a number of reasons. CPU instruction overhead is the first, but the memory cache is equally important.

Video buffers (frame-buffer) are generally configured as non-cacheable to the CPU so a write to a pixel will occur immediately. As a consequence, memcpy will cause individual memory accesses to hit DDR. DMA operations will perform burst transfers, which saves some overhead across the CPU->DDR link.