H264 encoder – gst-plugin-cedar

The support from the linux-sunxi community for the Allwinner Chips is quite impressive – because 720p50 Video is producing a lot of data it is good to have a working encoder solution available, while debugging our V4L2 – Kernel Module.

Adding support for compressing Video to h264 on the Allwinner A10/A20 is as easy as the following steps – which are copy and pasted from n8body’s Blog which relies on the gst-plugin-cedar. We are compiling the plugin directly on the target Hardware.

1. get gst-plugin-cedar Source


$ git clone https://github.com/ebutera/gst-plugin-cedar

2. get tools needed for building


$ sudo apt-get install gstreamer0.10-tools libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev

3. compile the code


$ ./autogen.sh && make

4. place the plugins in the appropriate directory (/usr/lib/arm-linux-gnueabihf/gstreamer-0.10/)

One question that still bothers me is if gst-plugin-cedar is using the full capabilities of Allwinners H.264 Hardware-Encoder or if its only supporting I-Frames – because the Wiki from linux-sunxi.org is showing a Proof of Concept Status for this binary blob free encoder. sure this can be determined very quickly by looking at the statistics of a encoded file.

Happy Holidays btw.

Update:

I just verified that the current gst-plugin-cedar only produces I-Frames. This can be done using ffprobe from the ffmpeg project.


$ ffprobe -show_frames ~/test.mkv

which shows the detail of all frames inside the video. All frames where flaged at keyframes which is synonymous to I-Frames.

Advertisement

first video

The V4L2 driver for the ADV7611 shows some first signes of live 🙂

sure there are some issues but this is a video already captured with gstreamer 😉

As an HDMI-Source I also used a Lime

IMG_20141211_160102

Settings are 480p – the green color most likely is a result of a wrong colorspace – we are inputing RGB888 into the CSI1 of the A10 and this looks like that the data is interpreted as YUV..

further the Image is a bit offset to the bottom right … but it is a stable picture this is telling us that PIXEL_CLOCK, HSYNC and VSYNC are working 🙂

The flickering is because the V4L2 currently reports a Framerate of 100 Hz but the input signal is 60 Hz.

The adv7611 module can be found at the github – Makefile still needs to be written.

the module depends on other modules (videobuf-core, videobuf-dma-contig, sun4i_csi1), load it in the following order

modprobe videobuf-core
modprobe videobuf-dma-contig
insmod adv7611.ko
modprobe sun4i_csi1

In order to use the module, also the script.bin file at the first partition of the LIME A10 – sdcard needs to be adjusted there for sunxi-tools are needed. Find more info here and here. You can also download script.bin from the github.

Hackathon Report Day2

Day two of the Hackathon started with a discovery that the pinout of the cyrstal we ordered was mirrored – that was also the reason why we couldn’t measure the clock on the crystal – to resolve this issue we flipping the crystal and soldered it in dead bug style

OLYMPUS DIGITAL CAMERAyou can also see that we used some capton-tape in order to avoid shorts on the pads – after making this modifaction the board came up fine with working crystal (no need to enable a register in the ADV7611) as it comes up by default with clock enabled. We were very happy to have this part working 🙂

OLYMPUS DIGITAL CAMERAThe next step was to initialize the ADV7611 to a point where we could establish a HDMI Link – for this reason we basically copied the register settings from a adv761x – v4l2 patch for the linux kernel. This worked pretty straight forward but we came accross the following issue: The ADV7611 uses a one fixed I2C Address and and additionally 7 programmable I2C addresses. But when using i2cdetect for some reason the programmable I2C Addresses where not shown up correctly – So Georg had the idea that we should just try to communicate to these addresses via i2cget to see if we get some response, which worked out fine – so this problem was an issue with i2cdetect on the LIME Hardware. The problem showed up with addresses in the 0x60-0x6x Range … Strange, but once we knew that everything is fine we continued.

We used another LIME as HDMI Source and connected the two devices together.

OLYMPUS DIGITAL CAMERA

With the basic settings taken from the v4l2 patch we could establish a 480p60 link between the two boards. To see if everything was working we checked the Register 0x6A to see if Bit 4 (TMDS_CLK_A_RAW – TMDS clock detected on port A) and Bit 6 (TMDSPLL_LCK_A_RAW – TMDS PLL on port A is locked to the incoming clock) were set. Next we veryfied the Pixel Clock which was coming out of the ADV7611 which was about 27 Mhz, what was expected.

the code for reading the CLK/PLL Info is:

i2cget -y 1 0x4c 0x6A

When measuring HSYNC and VSYNC we noticed some strange behaviour caused by shorts on the PCB – we continuied working with the second prototyp, which didn’t showed this problem – and Fritz was fixing Prototype 1 in the meantime.

By tweaking the Framerate setting to 50Hz we could establish a 720p50 link with a pixel clock of about 75 Mhz.

We tested further to see if there was real data coming out of the ADV7611 by displaying a simple zebra-pattern.

pattern_lines_black_white_720_480

This way we could count the White-Pixels on the Dataline in respect to the pixel clock and on the osziloskope we could really count the 30 white and 30 black alternating pixels in each line. – So we proven that we are producing a picture on the parallel CSI-Bus, which still may have some issues but could already be clearly distinguished from noise.

So the first steps on the Hardware are looking good – the next step is to import a still image using the CSI-Peripheral of the Allwinner A10 – after a short discussion we decided that it would be necessary to implement this as linux kernel module – so we followed the instructions of Olimex to cross compile the kernel for Olimex Lime and started crafting a kernel module. The process described in the howto was straight forward – Only the indenting of the of the kernel module Makefile – that we copied and pasted made some problems. With an working environment to build kernel modules we wanted to read a register of the CSI1-Peripheral to veryify its after-reset state. – This was a bit tricky because we had to enable the clock of the CSI1-Peripheral first – so at the End of Day 2 we couldn’t make this step.

But the day after I had a look at the i2c-sunxi.c driver to see how to enable the peripherals in a proper way – so after some playing around and releasing the CSI1 from reset state we could read the cfg register.


[  818.413777] ahb_csi1 Clk enabled!
[  818.419033] csi1 Clk enabled!
[  818.427087] ccm_csi1_clk: 0x80000000!
[  818.433797] ahb1 clock gating: 0x0014fa3c!
[  818.445265] after reset ccm_csi1_clk: 0xc0000000!
[  819.242955] ioremap ok!
[  819.247678] Register = 0x00300205

So we can communicate with the CSI1-Peripheral – The Source can be found on github – Next we need a linux kernel module that initializes the CSI1-Peripheral and tries to capture a single from to a allocated memory location.

Hackathon Report Day1

On the first day of the Videobrick Hackathon at OTELO Vöcklabruck we focused on populating the PCBs – we used steel-stencile (sponserd by wedirekt) for applying the solderpaste at top side of the Videobrick PCB. In the next step we placed all top components and then we put the competed PCB in the “reflow” oven – which is a simple backing oven (with max. temp of 230 degrees celsius) – Altough it would be more controlled to use a temperature controller for the reflow profile, we just heated the oven to max. temperature and right after all the solder melted we switched off power and opened the oven door to let the PCB cool down.

P1030734After reflow soldering we needed to clean up the excess solder to remove any shorts that we produced during the process. A stereo-microscope is very handy for this purpose:

P1030738Here is a picture that shows the VideoBrick installed on top of the Olimex LIME:

P1030730Connecting both Input and Output HDMI is possible but space is a bit tight so we might consider moving the HDMI Connector more towards the Edge of the PCB for future revisions. But all in all (considering it is a Prototyp) the mechanical results are not to bad 🙂

On the Softwareside Georg Lippitsch figured out that using the i2ctools is a straight forward way to communicate with the ADV7611 – but before that we needed to release the reset line, which is connected to PC24.

Fourtunatly controlling the GPIOs can be done with a shell script:


# enable reset pin
echo 14 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio14_pc24/direction
echo 0 > /sys/class/gpio/gpio14_pc24/value
sleep 1
echo 1 > /sys/class/gpio/gpio14_pc24/value

Reading the Revision of the ADV7611 afterwards is as easy as that:


i2cget -y 1 0x4c 0xea w

At the end of Day One of the Hackathon we could communicate with the ADV7611 but for some reason the crystal didn’t seem to work, but debugging this issue was left for Day Two.

Many thanks to Fritz and Fabian from OTELO Gmunden for supporting us at the Hackathon

Videobrick Hackaton

We are happy to announce our first Videobrick Hackaton.

It will take place in Otelo Vöcklabruck during Friday 10th October and Saturday 11th October, from 10:00AM. We would like to invite everyone willing to hack and join our Videobrick project and learn about technics related with electronics

Video brick is an early prototype of an open source and hardware device for audio and video (live) streaming. It has been started in early 2014 by Georg Ottinger (OTELO VB), Georg Lippitsch (mbcast.com, Wien) and Gabriel Lucas (MediaLab Prado, Madrid)

Right now it´s a research project around the HDMI signals and SOC (System On Chips).

At this moment we are developing a shield that would fit on top of a OlinuXino A10-LIME (an open hardware developing platform with good performance, price and philosophy). You could find the schematics in our github account.

We would like to invite you to join and hack with us. The program for these days would be:

  • SMD assemble with stencils and a microscope. Take a look to this nice tutorial explaining the process of doing the stencils.
  • Reflow with toast oven
  • Hardware checking
  • I2C debugging
  • Embedded Linux with the Olimex LIME
  • Linux kernel driver programming

We will keep you post with news of the hackaton and future steps.

VideobrickPCBs ready

Based on the shield templates that Olimex has published we are building an early prototype for an A10-OlinuXino-LIME shield. You could find the design in our github.

Here is how it looks.

Videobrick shield

Videobrick Shield

Thanks to our great supporter WeDireckt we got some PCBs that would be used to prototype the early development of the Videobrick. This ones would be used in our next Videobrick Hackaton.

Videobrick pcb for A10-OlinuXino-LIME shield

Videobrick pcb

They look quite pretty 😀

Olimex LIME just arrived!

Olimex Olinuxino A10 LIME board on a tree

Olimex Olinuxino A10 LIME board

We got our first sponsorship from Olimex: A10-OLinuxXino-LIME that we would use to start prototyping and developing our videobrick PCBs.

OLinuXino is an open hardware board capable of running Linux and Android very well suited for DIY projects like videobrick.

This comparison is useful for getting a clear idea of the differences between boards.

Image by TechWatch

Image by TechWatch

If you are learning about A10 take a look to this good resources: wiki & manual & github