allwinner-zh/media-codec demo

1298 views
Skip to first unread message

@lex

unread,
Dec 30, 2015, 10:05:46 AM12/30/15
to linux-sunxi
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

unread,
Dec 30, 2015, 12:18:49 PM12/30/15
to alex....@gmail.com, linux-sunxi
"@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

unread,
Dec 30, 2015, 1:14:57 PM12/30/15
to linux-sunxi, alex....@gmail.com, johns9...@yahoo.co.uk
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

unread,
Dec 30, 2015, 2:01:47 PM12/30/15
to alex....@gmail.com, linux-sunxi
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

unread,
Dec 30, 2015, 2:06:20 PM12/30/15
to linux-sunxi
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

unread,
Dec 30, 2015, 3:18:42 PM12/30/15
to linux-sunxi
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

unread,
Dec 30, 2015, 4:04:51 PM12/30/15
to linux-sunxi
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

unread,
Dec 30, 2015, 4:15:46 PM12/30/15
to @lex, linux-sunxi
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

unread,
Dec 30, 2015, 11:45:37 PM12/30/15
to linux...@googlegroups.com
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

unread,
Dec 31, 2015, 5:49:02 AM12/31/15
to linux-sunxi, mon...@iro.umontreal.ca
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

unread,
Dec 31, 2015, 12:11:52 PM12/31/15
to Rosimildo DaSilva, linux-sunxi
> 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

unread,
Jan 1, 2016, 8:08:30 AM1/1/16
to linux...@googlegroups.com, rosi...@gmail.com
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

unread,
Jan 1, 2016, 8:31:46 AM1/1/16
to linux...@googlegroups.com, mon...@iro.umontreal.ca
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

unread,
Jan 2, 2016, 8:47:18 AM1/2/16
to linux-sunxi, rosi...@gmail.com
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

unread,
Jan 3, 2016, 7:14:24 AM1/3/16
to linux-sunxi, rosi...@gmail.com
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

unread,
Jan 4, 2016, 2:06:48 PM1/4/16
to linux-sunxi, rosi...@gmail.com
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

unread,
Mar 11, 2016, 7:32:09 AM3/11/16
to linux-sunxi
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:


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

unread,
Mar 11, 2016, 8:45:25 AM3/11/16
to linux-sunxi
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

unread,
Mar 11, 2016, 8:53:36 AM3/11/16
to linux-sunxi
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

unread,
Mar 11, 2016, 2:18:52 PM3/11/16
to linux...@googlegroups.com, rosi...@gmail.com
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

unread,
Mar 11, 2016, 2:41:59 PM3/11/16
to Manuel Braga, linux-sunxi, rosi...@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

unread,
Mar 11, 2016, 4:42:35 PM3/11/16
to linux-sunxi, mul....@gmail.com, rosi...@gmail.com
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

unread,
Mar 11, 2016, 5:52:17 PM3/11/16
to alex....@gmail.com, linux-sunxi, Manuel Braga, rosi...@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

unread,
Mar 11, 2016, 6:08:21 PM3/11/16
to linux-sunxi, alex....@gmail.com, mul....@gmail.com, rosi...@gmail.com
Err... That was new to me. Without researching how do you grab video from this generic driver how good this camera performs?

@lex

unread,
Mar 11, 2016, 6:26:30 PM3/11/16
to linux-sunxi, alex....@gmail.com, mul....@gmail.com, rosi...@gmail.com
Can you please tell me the idVendor and idProduct for this camera?

jons...@gmail.com

unread,
Mar 11, 2016, 6:49:42 PM3/11/16
to folhaponto, linux-sunxi, Manuel Braga, Rosimildo DaSilva
[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

unread,
Mar 11, 2016, 6:58:36 PM3/11/16
to folhaponto, linux-sunxi, Manuel Braga, Rosimildo DaSilva
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

unread,
Mar 12, 2016, 8:49:38 AM3/12/16
to linux-sunxi, alex....@gmail.com, mul....@gmail.com, rosi...@gmail.com
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

unread,
Mar 12, 2016, 2:09:32 PM3/12/16
to folhaponto, linux-sunxi, Manuel Braga, Rosimildo DaSilva
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

unread,
Mar 12, 2016, 3:01:46 PM3/12/16
to linux-sunxi, alex....@gmail.com, mul....@gmail.com, rosi...@gmail.com
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

unread,
Mar 12, 2016, 3:36:08 PM3/12/16
to Rosimildo DaSilva, linux-sunxi, folhaponto, Manuel Braga
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

unread,
Mar 12, 2016, 5:55:57 PM3/12/16
to linux-sunxi, rosi...@gmail.com, alex....@gmail.com, mul....@gmail.com
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:

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

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

unread,
Mar 12, 2016, 6:10:57 PM3/12/16
to folhaponto, linux-sunxi, Rosimildo DaSilva, Manuel Braga
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

unread,
Mar 12, 2016, 6:15:35 PM3/12/16
to folhaponto, linux-sunxi, Rosimildo DaSilva, Manuel Braga
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

unread,
Mar 12, 2016, 6:47:38 PM3/12/16
to linux-sunxi, rosi...@gmail.com, alex....@gmail.com, mul....@gmail.com
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

@lex

unread,
Mar 12, 2016, 7:16:01 PM3/12/16
to linux-sunxi, alex....@gmail.com, rosi...@gmail.com, mul....@gmail.com
Interesting, can you check if it is a feature of this camera or the new kernel?
If you have OPI PC, can you check that?

Rosimildo DaSilva

unread,
Mar 12, 2016, 7:33:08 PM3/12/16
to linux-sunxi, alex....@gmail.com, rosi...@gmail.com, mul....@gmail.com
Some cameras are H.264 aware and they usually uses the UVC interface.

They usually are mounted as two /dev/videoX devices. The YUYV amd MJPEG are on video0 and H.264 on video1. I have a couple of ELP cameras that do that. They really good.

I have tested them OPI PC they work just fine.

R

jons...@gmail.com

unread,
Mar 12, 2016, 7:33:17 PM3/12/16
to folhaponto, linux-sunxi, Rosimildo DaSilva, Manuel Braga
On Sat, Mar 12, 2016 at 7:16 PM, @lex <alex....@gmail.com> wrote:
> Interesting, can you check if it is a feature of this camera or the new
> kernel?
> If you have OPI PC, can you check that?

It dual stream is feature of camera firmware. It is part of the Skype
certification requirements from 2012.

I think this can be done on the Logitech cameras too, but it is more
complex than simple two /dev/video devices.

@lex

unread,
Mar 12, 2016, 7:37:15 PM3/12/16
to linux-sunxi, rosi...@gmail.com, alex....@gmail.com, mul....@gmail.com
You are right, i changed the input format to NV12 on GuvcView and got lower CPU usage (250%) and Temp ~75C.
I does not help much overall.

jons...@gmail.com

unread,
Mar 12, 2016, 7:38:59 PM3/12/16
to folhaponto, linux-sunxi, Rosimildo DaSilva, Manuel Braga
On Sat, Mar 12, 2016 at 7:37 PM, @lex <alex....@gmail.com> wrote:
> You are right, i changed the input format to NV12 on GuvcView and got lower
> CPU usage (250%) and Temp ~75C.
> I does not help much overall.

You need an ffmpeg that has been taught how to use the hardware decode
features on your SOC.

Don't know if one exists for H3.

jons...@gmail.com

unread,
Mar 12, 2016, 7:40:16 PM3/12/16
to folhaponto, linux-sunxi, Rosimildo DaSilva, Manuel Braga
On Sat, Mar 12, 2016 at 7:38 PM, jons...@gmail.com <jons...@gmail.com> wrote:
> On Sat, Mar 12, 2016 at 7:37 PM, @lex <alex....@gmail.com> wrote:
>> You are right, i changed the input format to NV12 on GuvcView and got lower
>> CPU usage (250%) and Temp ~75C.
>> I does not help much overall.
>
> You need an ffmpeg that has been taught how to use the hardware decode
> features on your SOC.
>
> Don't know if one exists for H3.

Maybe this will work?...

https://github.com/stulluk/FFmpeg-Cedrus
--
Jon Smirl
jons...@gmail.com

@lex

unread,
Mar 13, 2016, 10:27:03 AM3/13/16
to linux-sunxi, alex....@gmail.com, rosi...@gmail.com, mul....@gmail.com
Rosimildo, 

Do you think you can do a rework on this ffmpeg tree and glue a C version of what you have achieved so far?

Rosimildo DaSilva

unread,
Mar 13, 2016, 11:16:03 AM3/13/16
to @lex, linux-sunxi, mul....@gmail.com
I will try in a few weeks.

I am going on a business trip for 2 wks, and when I get back I will try it.
The way it is now, it is very easy to use ffmpeg, but you have to use scripts to pipe FFMPEG preprocessing to the encoder, and use the "H264" stream with FFMPEG to mux it, and transport it.

R


Manuel Braga

unread,
Mar 13, 2016, 1:30:26 PM3/13/16
to Rosimildo DaSilva, @lex, linux-sunxi

Everyone is too "professional" to care for license issues.
Or are all you "stupid"?, or are playing under-politics?

Do you really are incapable to understand that i (we) can't help, if you
choose to run around the binary-blobs-with-no-license.

I am not here in my free time, to get involved in "license issues".

license-issues -> i can't help
no-license-issues -> i can help

Do you understand?


Why should allwinner do more, and care to respect the license of the
software that they are using, if the "user" are all happy with the
binary-blobs-with-random-license-issues. And them this is what happens,
they(allwinner) avoid the linux-sunxi community, because there are
assholes like me, that can't keep the mouth shut by keeping repeating
that "license-issues" are not acceptable. And as is always the same
people that that open the mouth, they are seen as the problem.
When in reality is the damn license-issues.


The "valid reason" that was asked some time ago, is just this.

A valid reason, is to respect the license of the software used, which
implicits, to choose the solution with no-license-issues.

And what we see here, you choose to work around with the
binary-blobs-with-random-license-issues.
I am sorry, but i can't help.

If you are doing this because cedrus(the project for libre and open
source for the video engine) *still* don't supports encoding in H3.
(And, i must say that this will be very simples to add.)

Is because, we can't do everything in the few free time that we(cedrus
people) have to spend in this. WE are forced to make decisions and
define priorities. Because everyone knows, we all have lifes beyond
sunxi.

Why are you wasting your time with blobs-with-random-license-issues,
when you could be helping cedrus moving forward.

Isn't this what "open source" means, working together for mutual
benefit.

Everyone is more than welcome to join and be part of cedrus.
And is up to everyone to make their choice.
--
Manuel Braga

Rosimildo DaSilva

unread,
Mar 13, 2016, 2:28:25 PM3/13/16
to Manuel Braga, @lex, linux-sunxi
Manuel,
IMHO, people just want a solution that works! 

Look what happened with the DECODER, Jemk implemented the VDPAU implementation, and nearly everyone has adopted it, instead of blobs! You what to know why ? Because, it works.
If we keep fighting license issues, it just delays to have a solution that works. 

If we implement some Cedrus that works with relatively new H3/A64 SOCs,  I can see more and more "image builders", like Armbian and others to adopt such a solution instead of Blobs.

Keep a halt at development until Licenses are resolved, it is not the best proposition, IMHO.

Anyway, I just published what I have done. 

For my projects, a way back I've got the same conclusion, like Jon, and went with H.264 cameras, and gave up on AW encoder.

My thought with releasing the code, was if someone would pick up and do some experiments with other Codecs, not just H.264.

I am willing to help with any initiative that is totally open source.

R

@lex

unread,
Mar 13, 2016, 3:16:12 PM3/13/16
to linux-sunxi, rosi...@gmail.com, alex....@gmail.com
I understand your concern and somewhat agree with you regarding the "stupid" question to ask to stick a blob to an open source, that should have never happened.
It happens in the name of science. Maybe this can wake-up people. 
Let's get to the point, someone who knows where the 'license-issues' are should step up, be brave and fill a license complaint and hurt where it should, 'sales'!
Why it takes so long (3 years)? When exactly this 'license issues' will be resolved? Why ffmpeg does not take any actions?
I don't have the answers, do you?

Manuel Braga

unread,
Mar 13, 2016, 5:16:48 PM3/13/16
to Rosimildo DaSilva, @lex, linux-sunxi
On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva
<rosi...@gmail.com> wrote:
> Manuel,
> IMHO, people just want a solution that works!

Do the blobs works? Early was said that there was some issues.
But i understand, what people want is _gratis_ things.


>
> Look what happened with the DECODER, Jemk implemented the VDPAU
> implementation, and nearly everyone has adopted it, instead of blobs!

Now, you say.
When the first working implementation of libvdpau-sunxi was in the end
of august of 2013, that is more than 2.5 years ago.
But there are still "blind" people in random places of the internet,
that makes the statement of "there isn't hardware accelerated decoding
in linux(version gnu) in sunxi".
And this is a recent example, just from last months.

Do people are so desperate for the _gratis_ things that they ignore the
existence of the work for a full 100% libre and open source software.


> You what to know why ? Because, it works.

It works, because it is full 100% libre and open source software, if
there are bugs(issues), we have the means to fix it.

With the binary-blobs-with-random-license-issues, this is not possible.

> If we keep fighting license issues, it just delays to have a solution
> that works.

The license-issues is the problem.
The license-issues is the reason.

>
> If we implement some Cedrus that works with relatively new H3/A64

The encoding side, you mean.
That is easy, just what is need is for someone to do the need work.
There isn't any technical difficulty, only is need time to do it.
Please help us(the cedrus people), so that we can arrange the time to
do it.


> SOCs, I can see more and more "image builders", like Armbian and
> others to adopt such a solution instead of Blobs.
>
> Keep a halt at development until Licenses are resolved, it is not the
> best proposition, IMHO.

There is not any halt. Just prioritizing by doing other things.


But again. The license-issues are the problem and the reason, for why
this linux-sunxi community is not doing more.
As everyone can see as example, the hdmi driver(H3) can't be mainlined
because, (everyone guessed?), the license-issues.



>
> Anyway, I just published what I have done.
>
> For my projects, a way back I've got the same conclusion, like Jon,
> and went with H.264 cameras, and gave up on AW encoder.
>
> My thought with releasing the code, was if someone would pick up and
> do some experiments with other Codecs, not just H.264.
>
> I am willing to help with any initiative that is totally open source.

You are very welcome to join us.
--
Manuel Braga

Manuel Braga

unread,
Mar 13, 2016, 5:32:05 PM3/13/16
to linux...@googlegroups.com, alex....@gmail.com
On Sun, 13 Mar 2016 12:16:11 -0700 (PDT) "@lex" <alex....@gmail.com>
wrote:
> I understand your concern and somewhat agree with you regarding the
> "stupid" question to ask to stick a blob to an open source, that
> should have never happened.
> It happens in the name of science. Maybe this can wake-up people.
> Let's get to the point, someone who knows where the 'license-issues'
> are should step up, be brave and fill a license complaint and hurt
> where it should, 'sales'!
> Why it takes so long (3 years)? When exactly this 'license issues'
> will be resolved? Why ffmpeg does not take any actions?
> I don't have the answers, do you?

Little fish, has no money to play the lawsuit game.
Big fish, has the money to lobby governments to extend copyright to a
ridicule amount of years.

That is why, it is important for the little fish stick together with
other little fishes, so that all together the little fishes can
equilibrate the power of big fish.
> > > <javascript:>>
> > wrote:
> > >
> > > > Rosimildo,
> > > >
> > > > Do you think you can do a rework on this ffmpeg tree and glue a
> > > > C version of what you have achieved so far?
> > > >
> > > >
> > > > On Saturday, March 12, 2016 at 9:40:16 PM UTC-3, Jon Smirl
> > > > wrote:
> > > >>
> > > >> On Sat, Mar 12, 2016 at 7:38 PM, jons...@gmail.com
> > > >> <jons...@gmail.com> wrote:
> > > >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex <alex....@gmail.com>
> > > >> > wrote:
> > > >> >> You are right, i changed the input format to NV12 on
> > > >> >> GuvcView and got
> > > >> lower
> > > >> >> CPU usage (250%) and Temp ~75C.
> > > >> >> I does not help much overall.
> > > >> >
> > > >> > You need an ffmpeg that has been taught how to use the
> > > >> > hardware decode features on your SOC.
> > > >> >
> > > >> > Don't know if one exists for H3.
> > > >>
> > > >> Maybe this will work?...
> > > >>
> > > >> https://github.com/stulluk/FFmpeg-Cedrus
> > > >>
> >
> > --
> > Manuel Braga
> >
>

--
Manuel Braga

jons...@gmail.com

unread,
Mar 13, 2016, 6:00:18 PM3/13/16
to Manuel Braga, Rosimildo DaSilva, @lex, linux-sunxi
We abandoned the Allwinner encoder hardware after discovering the
limitations of the hardware. The Allwinner encoder hardware is a
medium quality encoder that is not capable of making highly compressed
streams. But having said that, it is fine for use on a LAN, it just
isn't much good if you want to send a quality stream to a cell phone.
Another issue is that most of the Allwinner SOC don't have an ISP
(image signal processor) unit (some do, but most don't).

Manuel Braga

unread,
Mar 14, 2016, 2:23:05 PM3/14/16
to jons...@gmail.com, linux-sunxi
On Sun, 13 Mar 2016 18:00:17 -0400 "jons...@gmail.com"
<jons...@gmail.com> wrote:
> On Sun, Mar 13, 2016 at 5:16 PM, Manuel Braga <mul....@gmail.com>
> wrote:
> > On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva
> > <rosi...@gmail.com> wrote:
> >>
> >> If we implement some Cedrus that works with relatively new H3/A64
> >
> > The encoding side, you mean.
> > That is easy, just what is need is for someone to do the need work.
> > There isn't any technical difficulty, only is need time to do it.
> > Please help us(the cedrus people), so that we can arrange the time
> > to do it.
>
> We abandoned the Allwinner encoder hardware after discovering the
> limitations of the hardware. The Allwinner encoder hardware is a
> medium quality encoder that is not capable of making highly compressed
> streams. But having said that, it is fine for use on a LAN, it just
> isn't much good if you want to send a quality stream to a cell phone.
> Another issue is that most of the Allwinner SOC don't have an ISP
> (image signal processor) unit (some do, but most don't).


Right, this is one thing that most be made aware about this video
engine, to avoid be disappointed about the expected quality.

The h264 encoder can only do baseline profile (from what was found)
When setting low QP values, there are a point in which the bitstream
size stop decreasing, instead size get bigger, and with even lower
values the images get trashed beyond recognition.

And this is a hardware limitation.


About ISP, well it depends what one whats to do.
To encode in this video engine, the raw frames are feed to a called
isp subengine, which acts as a source for the subengine that does the
encoding. This "isp subengine" can do cropping, scaling, and take as
source some different formats, no much else.

And as you said, there is also in some socs a hardware block that
functions as an ISP, but i know nothing about it.


--
Manuel Braga

jons...@gmail.com

unread,
Mar 14, 2016, 2:44:06 PM3/14/16
to Manuel Braga, linux-sunxi
I want ISPs with denoising capability. Back to back frames can have a
lot of least significant bit jitter in them. The denoising detects
this and suppresses a lot of it. If you don't do this all of that
noise gets h.264 encoded and it can add 30-40% to the stream bandwidth
with useless noise.


>
> And as you said, there is also in some socs a hardware block that
> functions as an ISP, but i know nothing about it.
>
>
> --
> Manuel Braga



--
Jon Smirl
jons...@gmail.com
Reply all
Reply to author
Forward
0 new messages