allwinner-zh/media-codec demo

[@lex]

Hi,

I am trying to make the vencoder demo works, the sample provided in media-codec from allwinner.

Bear in mind i am new to the encoding process, let's see if what i want is possible and if i am doing the right way and if you can help.

I would like to convert a 720p YUV420 image i grabbed from my camera into JPEG image, that is all i need, the fastest way possible using less CPU.

I managed to compile the demo and the framework, so i changed the following:

src_width = 1280;

src_height = 720;

dst_width = 1280;

dst_height = 720;

codecType = VENC_CODED_JPEG;

baseConfig.eInpuFormat = VENC_PIXEL_YUV420SP;

I get "segmentation fault" with this parameters.

So, the questions are:

a) Is my understanding that i can use this to encode my YUV to JPEG correct?

b) Has anyone tested, used or checked if the framework really works?

c) Can you share a piece of code to achieve this simple task? or even share a YUV sample image that works with the demo?

@lex

[John S]

"@lex" <alex....@gmail.com> wrote:
> I am trying to make the vencoder demo works

[snip]

You need to say what OS, kernel, hardware etc.

John

[@lex]

Ok John,

Hardware: Orange PI-PC

Kernel: 3.4.39 (legacy code)

OS: Lubuntu 14.04.3 with mali enabled

cedarx: /dev/cedar_dev

also Orange PI-Plus 2, same as above.

I thought this was irrelevant, and this should work across all hardware with legacy kernel, well that was my plan, so i could have this working with A20,A10,A83T.

Is any way i could check if /dev/cedar_dev is working properly?

if you need further info, please ask.

@lex

[John S]

I've none of the items you list but anyone who may be able to answer at least knows now what you have.

John


---

[Rosimildo DaSilva]

The code is not complete and some folks have added "Issues" to the github.

Basically two thing are missing:

a) The "DEVICES" code are missings
b) Memory Allocators are missing ( ION and/or SUNXI_MEM )

Unless AW really does something to fix it, it is useless the code.


R

[@lex]

Thank you Rosimildo for the info, that really broke my legs!

Do you have any suggestion how i can encode it with easy?

[Rosimildo DaSilva]

I think the best is to use the "BLOBs". I have not seen any blob with encoder calls fro H3 yet, but my guess they must be available somewhere!

R

[Danny Milosavljevic]

Hi,

check the Dec 2015 linux-sunxi archives, topic "Jpeg Encoding" for a proof-of-concept.

(I didn't run it, but did compile it. The file "picture.c" contains the picture to encode)

Regards,
Danny

[Stefan Monnier]

Don't waste your time with allwinner-zh/media-codec.
Try and use the libvdpau-sunxi instead. It needs a lot of work, but
at least it's cleaner and will benefit more people in the long run.


Stefan

> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Rosimildo DaSilva]

Stefan,

He is looking for an Encoder and libvdpau-sunxi providers a decoder functionality.
I don't think there is any RE encoder code, except this stupidity that AW released, very incomplete. There is a PoC of a H264 encoder, but that is not available for anything beyond A10/A20, I guess.

R

[Stefan Monnier]

> He is looking for an Encoder and libvdpau-sunxi providers a decoder
> functionality.
> I don't think there is any RE encoder code, except this stupidity that AW
> released, very incomplete. There is a PoC of a H264 encoder, but that is
> not available for anything beyond A10/A20, I guess.

[Manuel Braga]

On Thu, 31 Dec 2015 02:49:02 -0800 (PST) Rosimildo DaSilva
<rosi...@gmail.com> wrote:
> Stefan,
>
> He is looking for an Encoder and libvdpau-sunxi providers a decoder
> functionality.

This is correct.

> I don't think there is any RE encoder code, except this stupidity

Did you try to check the wiki?
Let's see.
In http://linux-sunxi.org/Cedrus#Supported_codec_matrix, it says that
JPEG/MJPEG encoding support has a PoC.
In http://linux-sunxi.org/CedarX/Reverse_Engineering, it says that in
15 January 2014 Jpeg encoding proof-of-concept by nove jepoc

And in this maillist last 17 of december, someone asked for this poc
source code, which got this same day reply
http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/20659

> that AW released, very incomplete. There is a PoC of a H264 encoder,
> but that is not available for anything beyond A10/A20, I guess.

This video engine has multiple hardware reversions, but are done by
keeping the compatibility.

If the result of the video engine reverse engineering effort, currently
only works in A10/A10s/A13/A20 and recently H3, is not because of a
technical difficulty, but only because this happens to be the hardware
that the people working in this has in their hands.

If someone has the need to expand this work to other socs, only is need
to talk to us (the people that is working in the video engine reverse
engineering effort) to find a solution.

--
Manuel Braga

[Manuel Braga]

By all this time, it is pretty clear that the majority does not wants a
100% libre-open-source driver, instead what the majority wants is a
100% *gratis* source driver.

This is the reason for the level of support that we are receiving.

Because to help create favorable conditions in which this huge amount
of work could be realized at zero cost, is a too high price to pay for
this majority.

--
Manuel Braga

[Rosimildo DaSilva]

Nove,

I believe this community should take the ENCODER from a PoC level to a more or less demo similar to the one released by AW using the blobs
https://github.com/juanfont/cedar-encoder

It is very important ( IMHO ), if it works with a modern AW soc, such as H3, since it is probably the most used SOC from AW, since the A20, with the release of OPI-PC, and now with the sub $10's release on the pipeline, they would be even more popular!
http://www.cnx-software.com/2016/01/02/orange-pi-one-is-a-10-quad-core-board-with-ethernet-and-hdmi/

I think starting from the initial demo provided by Jemk's for A20, it should not be terribly difficult to get it to work with H3....
https://github.com/jemk/cedrus/tree/master/h264enc

What is missing on this example to be similar to the example provided by AW, it lacks:

   + motion detection
   + initial header info ( to be sent periodically ).

Get this running on a H3 would be very useful to have a user base that might push the open source solution really the way to go....

R

[@lex]

Considering my level of skill, i believe getting a workable sample without memory leaks first would benefit also this new cheap HW that is coming.

Cheap HW, cheap (or a good) camera and a working HW encoding engine would be more attractive to advanced developers and give a reason to the good people who works on the ve reverse eng. to keep on going.

This thinking may falls under the 100% *gratis* source driver not as an option but a necessity.

[Rosimildo DaSilva]

I believe that a few user cases of the ENCODER as a "capture" input for FFMPEG or GSTREAMER would be very helpful to ensure the RE regs are correct and logic validated.

It may not be a final approach, but it may help defining the bits and parts of a mem2mem driver for the AW's VPU....

R

[Rosimildo DaSilva]

Hi guys,

I have finally completed an initial version of AW H/W encoder based utility. It is based on H3 blobs, provided by AW.

See README:

https://github.com/rosimildo/videoenc

This is a starting point, and hope we get some traction to implement something using open sources... but this might provide some test points to archive the goal.

Thanks, Rosimildo

On Wednesday, December 30, 2015 at 9:05:46 AM UTC-6, @lex wrote:

[@lex]

Thank you Rosimildo!

I will try it out and see how i can glue it to a 'C' program, if you don't mind being asked very basic questions.

Don't get me wrong but why you choose C++? I will take some time to port it to C.

Anyways thanks for the hard work.

@lex

[Rosimildo DaSilva]

It is just my preference. I am open to see some porting to C, if most prefers it!

C++ has much more abstractions, and it is easier to read. :-)

Anyway, like I said, this is a starting point... and the goal of all of us, is to have an open source solution.

I did not mention, but I founf two issues withe blobs:

a) Motion Detection causes segmentation fault, whenever enabled.

b) FFMPEG complains that timestamp ( PTS/DTS ) are missing on the H264 stream generated by the encoder... I've tried many things ( code is commented out ), but nothing worked.

Anyway, let me know what you think, and I am here to answer any question you might have

Rosimildo

[Manuel Braga]

On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva
<rosi...@gmail.com> wrote:
>
> I did not mention, but I founf two issues withe blobs:
>
> a) Motion Detection causes segmentation fault, whenever enabled.
> b) FFMPEG complains that timestamp ( PTS/DTS ) are missing on the
> H264 stream generated by the encoder... I've tried many things ( code
> is commented out ), but nothing worked.

There is another issue, that i believe to be important.
But for whatever reasons, it has to be constantly remembered about its
existence.

And that issue is:

c) The proprietaries binary blobs don't have a clear license attached.

And in the copyright law, any "things" with "no license" by default fell
in the "all rights reserved".

--
Manuel Braga

[jons...@gmail.com]

I gave up fighting with Allwinner's encoder long ago. It is far easier
to just plug in a USB based h.264 camera. You can easily buy ones from
Logitech for $50.

If you want it at the hardware level, look at chips from Sonix. Here
is a board based on the SN9C291 for $8.50. The bare chips are about
$4.
https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail

Note that this PCBA is the same price as most bare image sensors
mounted on a flex cable. Plus I find it much easier to wire things
with a simple USB cable instead of an FFC.

The Sonix chips will appear as USB UVC devices when plugged into Linux
and they will need no special drivers. They also work on Windows.



>
> --
> Manuel Braga

>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Jon Smirl
jons...@gmail.com

[@lex]

Seems to be a nice camera, but that depends on your kernel version.

There is no support for SN9C291 OV9712 on kernel v3.4.39.

And no support on odroid-3.8.30 on my U3 also.

Don't know about armbian legacy kernel version, but i don't expect there will be support also.

[jons...@gmail.com]

On Fri, Mar 11, 2016 at 4:42 PM, @lex <alex....@gmail.com> wrote:
> Seems to be a nice camera, but that depends on your kernel version.
> There is no support for SN9C291 OV9712 on kernel v3.4.39.
> And no support on odroid-3.8.30 on my U3 also.
> Don't know about armbian legacy kernel version, but i don't expect there
> will be support also.

The camera does not need a specific driver, it uses the generic USB
Video driver.
It is like a USB mouse or keyboard, you don't need a specific driver
for every different one.

Drivers/Multimedia/Media USB/USB Video Class (UVC)

Kconfig USB_VIDEO_CLASS

This support dates way back to around 2.4 or so. Almost every desktop
web cam works using this driver.

[@lex]

Err... That was new to me. Without researching how do you grab video from this generic driver how good this camera performs?

[@lex]

Can you please tell me the idVendor and idProduct for this camera?

[jons...@gmail.com]

[33718.237465] usb 2-5.1: new high-speed USB device number 12 using ehci-pci
[33718.782014] usb 2-5.1: new high-speed USB device number 13 using ehci-pci
[33719.121687] usb 2-5.1: New USB device found, idVendor=18e3, idProduct=5100
[33719.121692] usb 2-5.1: New USB device strings: Mfr=2, Product=1,
SerialNumber=3
[33719.121696] usb 2-5.1: Product: USB 2.0 Camera
[33719.121698] usb 2-5.1: Manufacturer: Sonix Technology Co., Ltd.
[33719.121701] usb 2-5.1: SerialNumber: SN0001
[33719.122631] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:5100)
[33719.146885] uvcvideo: Unable to create debugfs 2-13 directory.
[33719.147213] input: USB 2.0 Camera as
/devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5.1/2-5.1:1.0/input/input15
jonsmirl@terra:/work/gm/linux-3.3-fa$

[jons...@gmail.com]

The 291 chip is 720P30, the 292 chip is 1080P30.
They do decent h.264 compression. Some chips are better, a lot are worse.
Both chips are fine for web cam use.

There is desktop app called cheese that will take snaphots. You can
look at the source to see how it works.

Note that these chips operate in a lot of different modes.
streaming h.264
streaming mpeg
JPEG stills
uncompressed streaming
uncompressed stills

And all of this works without writing any more drivers.

While you wait three weeks for things to come from China I have seen
the Logitech HD Pro Webcam C920 recently on sale for $50. It is very
similar.

[@lex]

Thanks Jon.

I have some thoughts on this proposed hardware solution:

* This camera will not be recognized as uvc usb device, unless you add it to the device list, no big deal i think. 

Your kernel is 3.3 but i think you or someone else already added it to uvc device list. (i may be wrong),

* Orange PI ONE has only one USB, so you will need to access the device remotely,

* Grabbing the video can be done with V4l2 as usual,

* I tested here a usb Labtec gspca camera which is VGA JPEG 30 FPS, and its performance is about ~9 fps, that means USB camera tend to perform below specifications when not in Desktop, may be the usb bandwidth is a constraint,

* Original OPI camera is $ 5.90 while the one you pointed is $ 8.52 plus some usb cable and may need some wiring/soldering,

* Logitec is out of question, i cannot get one for less than $ 100.00. And considering spending $ 10.00 / 15.00 on a sbc board and another $ 100.00 is only viable if you don't want to mess with software.

* No tinkering, no learning and no solution for the upcoming Allwinner new devices going this route.

So, guys lets's get back to work, the fight is not over yet.

@lex

[jons...@gmail.com]

gspca is around 10 years old and it pre-dates UVC.

The 291 image chip can take higher resolution stills, but mine only
has a 720P sensor on it.
The 292 image chip has similar performance at 1080P.

I have wasted far too much time trying to get Allwinner cameras
working properly and I won't touch them any more.

Our current product uses a more advanced camera similar to this one:
http://world.taobao.com/item/521668890252.htm?spm=a312a.7700714.0.0.ekoWOi#detail
But these boards are too hard to interface with for casual use. The
main advantage to these chips is that they can simultaneously provide
three versions of the h.264 stream at different resolutions. The Sonix
chips are single stream but far easier to use.

This is cheapest, decent h.264 720P camera I camera I am aware of - $6.12
http://world.taobao.com/item/527850462938.htm?spm=a312a.7700714.0.0.d9CEzd#detail
You would need to attach to it using Ethernet, USB access requires
custom firmware.

Here are all of the modes supported by the 291 chips.
Note that it supports 720P30 h.264

this first mode is uncompressed, 480Mb USB limits it to 720P5
jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video1 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'YUYV'
Name : YUYV 4:2:2
Size: Discrete 1280x720
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 640x480
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 320x240
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)

Both MJPG and h.264 work at 720P30.
Index : 1
Type : Video Capture
Pixel Format: 'MJPG' (compressed)
Name : Motion-JPEG
Size: Discrete 1280x720
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 640x480
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 320x240
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)

jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video2 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'H264' (compressed)
Name : H.264
Size: Discrete 1280x720
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 640x480
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 320x240
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)

[Rosimildo DaSilva]

Jon,

Thanks for yours always informative posts.

I think someone should come up with a HDMI ==> CSI (MIPI ) interface board for these OrangePI PCs... it would be owesome...., instead of these gspca crap... they have now.

Jon, maybe you can help me... I am looking for an 720p or 1080p camera, H264 compressed video,  and with Wired ( and WI-FI a plus ), with AUDIO input... something that has also AUDIO as input and not just video.

If you know any cameras with that capability, and in the US$50 range, let me know.

THanks, R

[jons...@gmail.com]

On Sat, Mar 12, 2016 at 3:01 PM, Rosimildo DaSilva <rosi...@gmail.com> wrote:
> Jon,
> Thanks for yours always informative posts.
>
> I think someone should come up with a HDMI ==> CSI (MIPI ) interface board
> for these OrangePI PCs... it would be owesome...., instead of these gspca
> crap... they have now.

newer Allwinner chips such as the A64 support MIPI displays. For
example the Pine64 uses the A64, but I don't know if they exposed the
DSI interface.

>
>
> Jon, maybe you can help me... I am looking for an 720p or 1080p camera, H264
> compressed video, and with Wired ( and WI-FI a plus ), with AUDIO input...
> something that has also AUDIO as input and not just video.
> If you know any cameras with that capability, and in the US$50 range, let me
> know.

Look for little surveillance camera like this one:
http://www.amazon.com/Vanxse%C2%AE-Pinhole-Security-Network-Surveillance/dp/B00QRM9AFG/ref=sr_1_1
They contain those standardized, square camera boards I linked to earlier.
You need to access these over Ethernet. Internally most run Linux on an ARM9.

The Sonix chips support audio input. Don't know if that taobao board exposes it.

Here is C920 for $60 shipped.
http://www.wirelessoemshop.com/logitech-hd-pro-webcam-c920/
It was at Amazon last week for $50 shipped but it is sold out now.

If you drop h.264 and just use MJPG you can find USB cameras for $10.

Look for deals on web cams. All web cams stream video and audio.

[@lex]

Inspired by so many good arguments on USB uvc cameras i decided to test one, a 720P HD used in ODROID, so you can take a look and see how good it is for Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by HW worth the effort or we throw in the towel, it is up to you.

This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel and with ssvb fex (TKaiser advice) to solve the so known temperature issues this board faces when running at high speed.

The uvc camera is ODROID 720 HD:

[  196.199875] ehci_irq: highspeed device connect

[  196.460139] usb 4-1: new high-speed USB device number 2 using sunxi-ehci

[  196.890710] 2:3:1: cannot get freq at ep 0x84

[  196.892434] usbcore: registered new interface driver snd-usb-audio

[  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056)

[  196.938300] is_otg_flag: 0x0,

[  196.938479] usbcore: registered new interface driver uvcvideo

[  196.938489] USB Video Class driver (v1.1.1)

[  196.976118] 2:3:1: cannot get freq at ep 0x84

As Jon said, you don't need to do anything, just plug it in and start using the UVC camera compliant. No need to worry about drivers, etc..

This camera has MPJEG mode and YUV mode:

ioctl: VIDIOC_ENUM_FMT

Index       : 0

Type        : Video Capture

Pixel Format: 'MJPG' (compressed)

Name        : MJPEG

Size: Discrete 1280x720

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 640x480

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 640x360

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 544x288

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 432x240

Interval: Discrete 0.017s (60.000 fps)

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 352x288

Interval: Discrete 0.017s (60.000 fps)

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 320x240

Interval: Discrete 0.017s (60.000 fps)

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 752x416

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 800x448

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 800x600

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 864x480

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 960x544

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 960x720

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 1024x576

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 1184x656

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Index       : 1

Type        : Video Capture

Pixel Format: 'YUYV'

Name        : YUV 4:2:2 (YUYV)

Size: Discrete 640x480

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 640x360

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 544x288

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 432x240

Interval: Discrete 0.017s (60.000 fps)

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 352x288

Interval: Discrete 0.017s (60.000 fps)

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 320x240

Interval: Discrete 0.017s (60.000 fps)

Interval: Discrete 0.033s (30.000 fps)

Interval: Discrete 0.040s (25.000 fps)

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 752x416

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 800x448

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 864x480

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 800x600

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 960x544

Interval: Discrete 0.050s (20.000 fps)

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 1024x576

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 960x720

Interval: Discrete 0.067s (15.000 fps)

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 1184x656

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

Size: Discrete 1280x720

Interval: Discrete 0.100s (10.000 fps)

Interval: Discrete 0.200s (5.000 fps)

So i tested it with GuvcView, in YUV mode and MJPEG mode.

I came to the following conclusion (but you can have your own):

* CPU intensive usage, even for compressed MJPEG, this is necessary because GuvcView needs to decompress MJPEG and render it on screen, so decoding is by software.

* Raised CPU temp. ~80C and all sort of issues that come with it.

* UVC cameras will have good use for streaming MJPEG or H264, without rendering it to screen. Forget about Cheese, GuvcView and apps. Maybe it is good for motion and OpenCV, you have to find out.

Finally, have a look to image quality here:

https://plus.google.com/u/0/photos/photo/113203245923875824895/6261286144173300082

https://plus.google.com/u/0/photos/photo/113203245923875824895/6261288269096376978

https://plus.google.com/u/0/photos/photo/113203245923875824895/6261280022112589490

And you can compare it to the Cheap Orange Pi Camera here:

https://plus.google.com/u/0/photos/photo/113203245923875824895/6248912774577238658

https://plus.google.com/u/0/photos/photo/113203245923875824895/6248917191401732482

And Rosimildo, Orange PI PC has built in Microphone and you can grab sound from it, again in order to sync the sound with image you need HW encoding.

This is my 2 cents.

@lex

[jons...@gmail.com]

Look carefully at my sonix video parameters...
notice that there are two /dev/videoX devices

This is done so that the screen display app can use the the
uncompressed stream while forwarding on the h.264 stream without
decompressing it. The uncompressed stream does not need much CPU to
display.

[jons...@gmail.com]

My examples are running on Ubuntu with kernel 4.2.
jonsmirl@terra:/work/gm/linux-3.3-fa$ uname -a
Linux terra 4.2.0-33-generic #38-Ubuntu SMP Tue Mar 8 22:42:18 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
jonsmirl@terra:/work/gm/linux-3.3-fa$

The linux-3.3-fa prompt is because I am painfully working on an ARM9
vendor kernel when the vendor does not update their code. I am porting
features from the current kernel back to their old system. I don't
have the source for everything to forward port their code.

--
Jon Smirl
jons...@gmail.com

[Rosimildo DaSilva]

I have this camera, and if you change the "start_video.sh" script to something like this....

you can see... the results... the CPU usage is much lower...

            echo "Starting H264 Encoder..."

            $FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720 -i $SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \

               $ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720 -o /tmp/out1.h264

            ;;

R