Rearranging memory map

Can you pls share your chains.i.e how you plan to connect the links .This will determine the memory requirement and ddr b/w usage.

1. Do we need the tiled memory region for our application?

  -- If you are real time (i.e. you are not bottlenecked by ddr b/w) you do not need to use tiler memory

2. How much bitsream buffer do we really need to hold encoded video?

   -- We allocate (width * height )/2 per encoded bitstream buffer.Since we dont use a ring buffer but instead use discrete buffers we have to size it for max worst size encoded frame.

3. How much frame buffers do we really need to hold the raw frames to be encoded?

   -- Minimum is 3 output buffers per link

How plan for link connection is

capture (VPSS) -> ipcFrameOut (VPSS) -> (some processing in ISS) -> ipcFrameIn (VIDEO) -> encode (VIDEO) -> ipcBitOut (VIDEO) -> ipcFrameIn (Linux) -> tcp/ip

We are encoding a 5MP video steam @ 15 FPS in real time and streaming it live over ethernet.

We are optimizing the resources with the following targets in mind:

1. The stream must be real time and lower ethernet bandwidth is desired

2. Lower number of raw frame buffers is desired

3. Lower usage of bitstream buffer is desired

4. Reasonable high image quality and low latency is desired

There are other activities in the SoC involving DSP and DSP needs more memory for its own computation, and we are looking into the possibility of reducing tiled region / frame buffer / bitstream buffer to accomodate that. What is the typical number of raw frame buffers / number of bitstream buffers for this type of application? And what h.264 profile, h.264 number of reference frames or other h.264 parameters should we use to minimize buffer usage but still be able to steam over ethernet in real time?

Thanks

Tim

The chain you have mentioned is possible without tiler so you dont have to have tiled memory section.

For number of buffers in the usecase  you have mentioned the following links will allocate output buffers:

1. Capture output buffer : Capture frame Width x capture frame Height x BytesPerPixel x Number of Channels X Number of buffer per channel. 

2. (some processing in ISS) - OUtput buffer allocation depends on whether processing is done in place or not.

3. Encoder output - Bit stream - The size of a single bitstream buffer is generally sized as (w * h) / 2. The bitstream buffer has to be sized to worst case size of single encoded frame so it may  not be possible to reduce it much further.

4. Encoder internal reference buffers. - The number of reference frames depends on application configuration of the encoder. You can configure the encoder to use single reference frame.  This I believe is the default configuration .

I think you can reduce the number of output buffers to 3 per channel per link and check realtime performance.

For high quality the main factor is to choose a reasonable target bitrate.

To minimize latency you can enable notify between cores in ipc links.

Incase you have the DVR RDK release you can refer to the memory_analysis.xls which has details of memory usage for different usecases supported in DVR RDK.The usecase may not be directly applicable to your usecase but should give you an idea about memory requirement.

Hi Badri,

Thanks for the reply. We are now trying out modifying the memory map. Is it possible to move the bit steam buffer (SR1) to the higher 256MB region? I understand the higher 256MB region is not cached by the M3's, but is the bit stream buffer cache intensive?

Regards,

Tim

Yes you can move bitstream buffer to higher 256M region. The bitstream buffers are not accessed by M3 CPUs and has no performance impact when moved to higher 256M region