Page History

...

Introduction

This page dedicated to understanding of High level design for RDK Media Streaming in R-Pi Zero.

• Supported WiFi connection.
• v4l2 Driver is used to capture data from RPI-0 camera Device.
• /dev/video0 is the RPI-0 camera device to capture data.
• Supported Soc level Gstreamer plugins to capture data from camera device.
• Supported H264 encoding format.
• Supported SD,HD,FUll HD resolution.
• Supported automatic boot-up process for RMS functionality.

Architecture

Image Removed

Design Considerations

• Gstreamer Soc Implementation for RPI-0 Camera
  

 Image Removed

• Enabled V4l2 driver in part of RPI-0 to capture data from /dev/video0  device.
• Implemented soc level gstreamer pipeline with v4l2src plugin,omxh264enc plugin and appsink plugin.
• V4l2src plugin is used to capture raw data from camera through v4l2 driver and transmitted captured raw data into omxh264enc plugin to encode raw data into h264 encoding format.After that transmitted encoded data into appsink plugin to wrote encoded data into 8080 port of mongoose server.
• Registered 8080 port in Mongoose server to listen data.
• Supported resolution SD( 640*480 , 720*576 ) ,HD( 1280*720 ) and Full HD( 1920*1080 )

• Gstreamer Implementation in RMS
  

Image Removed

...

document covers the design approach used for upgrading firmware for RPI RDK Camera devices using XCONF server & TFTP protocol.

Architecture

Image Added

Design Considerations

Initially we need to do firmware configuration in XCONF server i.e we need to create firmware config ,firmware rule,download filter info(protocol(TFTP),IP address) etc corresponding to RPI MAC address

Next we need to have TFTP server in public network,so that it can be accessed by the device

In RPI we have to create a script which will be called by the systemd service file on boot up,When the device boots the script will read the cloud firmware version using a curl request and it will check with the local FW version,If the device FW version and cloud FW version are different then it will go with further processing as below

RPI will send curl request to XCONF and XCONF will send firmware config info(protocol,firmware location,firmware version,etc..) to RPi & it will process the response and based on the protocol it will download from TFTP server and proceeds with partition creation & flashing

By default RPI is having only SD card support for flashing OS and boot,right now we have only two partitions,one for Kernel(FAT32) ~40MB & other for rootfs(ext3) ~ 360 MB(mmcblk0p1,mmcblk0p2)

As part of our approach,during run time we are creating two more partitions using fdisk and mkfs.ext3 (mmcblk0p3,mmcblk0p4) will be doing reboot to take this partitions into effect

After booting we will be upgrading the new image

Sequence Diagram

Image Added

...