Re: [linux-sunxi] Re: PoC tvin2jpeg_h264 with veisp scaling

[Manuel Braga]

On Mon, 6 Mar 2017 00:51:08 -0800 (PST) Milos Ladni
 wrote:
>  Hi,
> 
> > What i can suggest you to do is to make an experience, to check if
> > the hardware is been correctly configured for each task.
> >
> > Before selecting the subengine for each task change, to do a
> > hardware reset first. (In your tvin2jpeg.c, in function
> > ve_selectsubengine put a call to the reset ioctl before selecting
> > the subengine)
> >
> > This experience will allow us to arrive to this conclusions.
> >
> > * If things will break in all cases, is because the hardware is not
> > been cleanly configured.
> >
> > * If this will fix, then congratulations you helped in finding what
> > the hardware can or not can do. And this means that we have to keep
> > track of the hardware state and reset it when things go off hand.
> 
> Thank you Manuel,
> I resolve the issue by reset ioctl every time before select next 
> subengine,  as you suggested.

Good to hear, but this was only to try to find what is causing, and not
to be a solution. The hardware should be expected to work without this
reseting.

But congratulations, you were the first to try to use the decoder and
encoder "at the same time" and this experience shows that there is
some weird interaction happening. This only applies to A20 and similar,
the never hardware is different as allows to simultaneous enable both
encoder and decoder.

I will try to see what could be the cause.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: PoC tvin2jpeg_h264 with veisp scaling

[Manuel Braga]

On Thu, 2 Mar 2017 07:58:21 -0800 (PST) Milos Ladni
 wrote:
>  Hi,
> 
> >  The application crashs(segfault?), and running under a debugger
> > doesn't give any clues about what could be?
> 
> The app works fine and then in some arbitrary moment when need to
> decode new frame which consisting from few slices it stuck on first
> slice in this frame while first_mb_in_slice=0.
> The h264Dec return 0x60017000 status code which means 'irec_busy', 
> 'intra_pred_busy' and 'mcri_busy'. What this flags means?
> After that i can not clear this flags anymore and party begins.  It's
> look like whole h264 engine (Enc and Dec) go crazy.
> When try to parse slice header from VLD i get incorrect data, whole
> slice header is filled with wrong data which of course cause
> segfault. Segfault happen because of wrong parsed data..
> Like VLD memory buffer is out of order, some mess happened..
> I tried to put h264Enc and h264Dec in same execute thread but  the
> same is happening.
> When 0x60017000 status code once happen on h264Dec, h264Enc also stop 
> working ant return some error status code when try to encode. It
> should be different subengines, is not?

It is not.
They are "subengines" because they have different functions, not
because they are independents of each other.
As you know, the hardware have a general register area, which in the
subengines are enabled not by a bit flag, but as 4bit number and
especially in the case of A20 alike, only one can be enabled at the
same time. Also we don't know the hardware internals which can/could
have shared blocks.

Is expected that if the hardware gets into an undefined state, things
will break everywhere, you have to reset the hardware to continue using.



What i can suggest you to do is to make an experience, to check if the
hardware is been correctly configured for each task.

Before selecting the subengine for each task change, to do a hardware
reset first. (In your tvin2jpeg.c, in function ve_selectsubengine put a
call to the reset ioctl before selecting the subengine)

This experience will allow us to arrive to this conclusions.

* If things will break in all cases, is because the hardware is not been
cleanly configured.

* If this will fix, then congratulations you helped in finding what the
hardware can or not can do. And this means that we have to keep track
of the hardware state and reset it when things go off hand.


> It does not always happen in the same frame, even if i always play
> same source, there are no rules..
> I know that you do not have time, do you know someone who can help
> me..? How can I find out what happens to VLD?

I will see what i can do next week, but i can't promise anything.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: PoC tvin2jpeg_h264 with veisp scaling

[Manuel Braga]

Hi.

On Fri, 24 Feb 2017 05:55:31 -0800 (PST) Milos Ladni
 wrote:
> Thank you Manuel!

I did nothing, if there is thanks is for you.


> 
> I managed to make a H264 decoder and it works fine.
> Now i can run all four operation simultaneous but...
> 
> Known bug:
> For now the app can play source with 'num_ref_frames' greater or
> equal to 1 but if i try to play source with 'num_ref_frames: 3'
> simultaneous with 264Enc the app crash for unknown reasons.
> If i play source with 'num_ref_frames: 1' it works ok..
> If i play source with 'num_ref_frames: 3' it works ok..
> If i run simultaneous only jpegEnc jpegDec and h264Dec all works no
> matter what the value of 'num_ref_frames' is.
> But when i want simultaneous h264Enc and h264Dec with source for
> decoder with 'num_ref_frames: 3' the app crash..
> There is no problem if  'num_ref_frames: 1'..
> Very strange.. I am no sure why, h264Enc and h264Dec even do not use
> the same subengine..

The application crashs(segfault?), and running under a debugger doesn't
give any clues about what could be?

You are now linking a lot of more libraries and is a bit scary, there
can be bizarre interactions happening that could manifest as
"inexplicable" segfaults. If this is the case in which the cause can't
be found, then you should try to reduce and only link the absolute
need libraries.

(This is me talking without actually having run/tested you application.)

Sorry for not be able to help you more, but there is no time to do more.


> Which is the best time to lock the hardware? 

You set the hardware to do 1 task and only that task, and you wait until
completed. This includes just reading registers, even within different
subengines this can/could give undefined behavior.

But you know, the problem is the /dev/cedarv driver, and the userside
should not have to worry about this things.

That is why for the proper driver, because with a V4L2 proper driver
the hardware is "multiplexed" allowing "any" number of possible
"simultaneous" concurrent tasks by any application.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: PoC tvin2jpeg_h264 with veisp scaling

[Manuel Braga]

Hi.

On Tue, 10 Jan 2017 01:05:16 -0800 (PST) Milos Ladni
 wrote:
>  Hi again,
> 
> I just wanted to make PoC test simultaneous tasks for my future
> project and to show others how much this platform is powerful.
> I need tvin, h264-jpeg encoder+scaler and decoder. Maybe i do not
> need all four operation simultaneous, but for now i have two cases:
> - tvin+h264Enc+jpegEnc+scaler + jpegDec (this i have already finished
> in my PoC app)
> - tvin+h264Enc+jpegEnc+scaler + h264Dec (i am working on this)
> Currently the major problem is vdpau, because i can not use any other 
> feature od VE while vdpau is working.

This is not a problem of vdpau (or the libvdpau-sunxi backend).

But from the limitation of the vendor VE kernel driver(/dev/cedar_dev)
which is too simplistic for allowing this simultaneous use by multiple
applications. Your case is only one application but in the end is the
same thing, you have to keep track and assure that the VE hardware is
been accessed only one time by one individual task.
This i repeat, because of the /dev/cedar_dev kernel driver.

> I do not need low level app, just  opportunity to do simultaneous
> tasks. Do you have suggestion how to do that?

As previous said, if after consider that this will be something that is
worth to be done. One way is to get the sources and change them to
remove anything not wanted.

 
> > With this codecs, things get more complex and is more easy to just
> > try to use an existent media api with already media application
> > support, than have to write everything for scratch.
> 
> On which api you specifically thinking?

Here, i was talking about vdpau and the reasons why was chosen.


But anymore, as in talking about implementing the support for a new
userspace media api, only makes sense after having a proper kernel
driver for the hardware.
As can be seen from the wiki page and following linked pages.
http://linux-sunxi.org/Cedrus

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: PoC tvin2jpeg_h264 with veisp scaling

[Manuel Braga]

Hi.

On Mon, 9 Jan 2017 01:50:40 -0800 (PST) Milos Ladni
 wrote:
>  Hello Manuel,
> I just added  hw JPEG decoder in my apps.
> Now i can do simultaneous h264 encoding, jpeg encoding and jpeg
> decoding with just ~20% CPU and 25 fps.

Great.

> How app works:
> Take frame from camera tv-in CVBS 720x576, show it on display by
> sunxi display engine in smaller resolution 542x359
> position x30y121 (use display scaler mode), encode raw frame to jpeg 
> (VGA-QVGA) /tmp/jpegTestXXX.jpg, after that decode
> the same frame from previous encoded jpeg /tmp/jpegTestXXX.jpg to
> raw, show decodec frame on display (right up position 200x150
> x580y121), encode raw frame from camera to h264 /tmp/tvin.h264 and
> mux it to mkv container /tmp/tvin.mkv.

That is something complicated that you are making, but if this is what
you want then okay. (You know, you are encoding and then decode to
display, is funny and is also a good test to see all is working.)

> 
> Do you know for any simple PoC example for h264 decoder? 

There isn't any. Sorry.
The h264 decoder work was added directly in the form of vdpau backend,
so a poc never existed.

> I would like to add all four operation jpeg-h264 encoder-decoder to
> my example app.
> I know for vdpau but i think that it's a little more complicated. I
> need simple PoC h264 decoder app.

With this codecs, things get more complex and is more easy to just try
to use an existent media api with already media application support,
than have to write everything for scratch.

For you case, as you are doing everything as low-level and wants to do
simultaneous tasks, it will not be so simples as to just implement what
is need for using vdpau as the api. You will need to make changes to
libvdpau-sunxi to the point of reimplementing a new h264 decoder.

You have to consider if the result wanted is worth the trouble.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] PoC tvin2jpeg_h264 with veisp scaling

[Manuel Braga]

On Thu, 24 Nov 2016 23:14:21 -0800 (PST) Milos Ladni
 wrote:
> 
> It would be nice to implement this. 
> If you have a time to find example please send me.

This is what i did 2years ago to learn how to use libavformat to do
muxing, was almost perfect expect for some needed fixes.

This was only done to learn and not to be used, and was made to be very
minimal as can be seen by the definition of global static context.
But if this facilitates in any way, then great.

http://dl.linux-sunxi.org/users/nove/testmux.tar.gz

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] PoC tvin2jpeg_h264 with veisp scaling

[Manuel Braga]

Hi.
Good work.

I took a look (not tested in the hardware, sorry is the usual no time),
and what you wrote in the readme about the divide scaler bug.

>From only a quick look, is hard to understand how you are using it, but
before that, last time maybe wasn't very clear explained what this
"divide scaler" really is.
This is a feature of the veisp to make "thumbnails", basically when
encoding is also possible to get the exactly picture as raw pixels of
what was encoded.

Meaning that this "divider scaler" can not affect the picture size that
will be encoded.

If there aren't any need for smaller raw pictures, then just only use
the arbitrary scaler.


Another thing were you speak about muxing into video containers, if you
have interest to implement this. I have somewhere a very simple example
of using ffmpeg libavformat to do this, much more easy to understand
that any of ffmpeg examples or test cases.
Just tell, i have to go find where is, first.



On Thu, 24 Nov 2016 04:20:38 -0800 (PST) Milos Ladni
 wrote:
> Hello,
> 
> This is yet another Proof of Concept analogue TV decoder (TV-IN) and 
> hardware accelerated H264-JPEG encoder with VEISP scaling for sunxi.
> This example capture frames from tvin (CVBS) scale it to VGA or QVGA
> and simultaneous encode frame to jpeg image and h264 stream.
> sunxi-tvin2jpeg_h264
> 
> 
> --
> Milos Ladicorbic
> 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] ISP scaling A20

[Manuel Braga]

On Thu, 27 Oct 2016 03:54:49 -0700 (PDT) Milos Ladni
<milosladicor...@gmail.com> wrote:
> Cool, arbitrary scaler is working now..:)
> Thank you a lot Manuel!

And thanks you too, for reporting that it works.

 
> By the way, divide-scaler is not working properly yet, maybe i do not
> need it anymore but It would be nice if i can contribute to the
> development of VE.

Is likely to be a wrong value written in a register, and talking about
this do check if MACC_ISP_OUTPIC_STRIDE has the stride of the *output*
matching the divisor used.
http://linux-sunxi.org/VE_Register_guide#MACC_ISP_PIC_STRIDE


> These days i will try to merge tvin and hw jpeg encoder in simple 
> application and i will push it on github. Maybe one day someone needs
> it..
> 
> > This looks familiar, but i can't remember what. 
> > Are you flushing the cache for the buffers? 
> 
> Yes, i am flushing the buffers. 
> I am think that hardware has some bugs or there are missing
> documentation how to do that.

If the above hit does not make it work, only by seeing the source code
is that i can try to spot the error.
Anything more is only guessing. 


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] ISP scaling A20

[Manuel Braga]

Hi.

On Tue, 25 Oct 2016 06:14:48 -0700 (PDT) Milos Ladni
<milosladicor...@gmail.com> wrote:
> Hi Manuel,
> 
> thanks for your reply, your e-mails encouraging me.
> I think that in first step this can be quick and more simpler
> solution. At first i will try this scale down with VEISP
> scaler-divider (size divided by 1, 2 and 4 factors) and then if this
> is done and if you can get me some instructions i can write more
> flexible solution from your first proposal. For me, the best solution

The other way is not hard, in only that will need to be generated a
table of coefficients for the scaler, and that was still not verified
that this is working in the hardware, after this will be possible to
explain with more certainty.


> would be standard VGA and QVGA resolutions. Okay, i can crop image
> from 720x576 to 640x480 by software and than scale down with VEISP
> divider if i need but this is rough solution with unnecessary

> copying. For simpler solution i suppose that i need to set
> MACC_ISP_SCALER_FACTOR as you mentioned to 1, 2 or 4 but i am not
> sure what else should be done? This registers are not described in

Yes you are right. Some years ago there was in the plan to make some
diagrams of the way how to configure the hardware, but because of some
distractions this was never made.
But keep with the questions, and i will answer.

No, MACC_ISP_SCALER_FACTOR is for the arbitary scaler(the other way)
and is not need to set any register with SCALER in the name.


> detail. This days i am locking in your PoC jpeg encoder as you
> mentioned before and i hope that i will succeed to scale down source
> image by VEISP divider.

Ok, first to explain how this works with the POC.
  
raw source => (VEISP subengine -> VEAVC subengine) => jpeg bitstream

To enable output, is only need to change in the VEISP side. For that.

In the MACC_ISP_CTRL register.
 MACC_ISP_CTRL_OUTPUT_EN most be set.
 Bits [27:25] are the output image size divisor(1,2 or 4)

And MACC_ISP_OUTPUT_LUMA and MACC_ISP_OUTPUT_CHROMA most be set with
valid buffers.

Take attention that this will not affect the size of the image encoded
into jpeg, and is only possible to get the raw pixels.
To encode to jpeg, you have to rerun this step with the now obtained
image as source.

To tell the truth, this way is only good if you need the raw pixels,
with the arbitary scaler the cropping and scaling is directly done for
the encoded image.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] ISP scaling A20

[Manuel Braga]

Hi.

On Fri, 21 Oct 2016 03:19:46 -0700 (PDT) Milos Ladni
<milosladicor...@gmail.com> wrote:
> Hi everyone,
> 
> Because there are PoC of hardware JPEG encoding and decoding, i am
> now interesting of hw scaling..
> Does does anyone tried to scale image (raw yuv 4:2:2 4:2:0 or rgb)
> with A20 hardware?
> How can i do this? I need scaler to scale image from one resolution
> to another.
> Concretely i read frame from tvin 720x576 4:2:0 and convert it to
> jpeg with libjpegturbo, but i want to switch to hw scaler-encoder

I forgot last time, there is another way from what was writing in the
previous email, but is only better if what is need is only a scale down
image at multiple of image sizes (size divided by 1, 2 and 4 factors)

As said, the VEISP has a scaler that can use arbitrary scale factors
(within a min/max), but doesn't need to use it, because when configured
to (also) output raw pixels is possible to choose the outputted size.
For your example of a source of 720x576, it can output (simultaneous
when encoding) the sizes 720x576 or 360x288 or 180x144.

If this isn't what you are looking or instead also wants to correct
the aspect ratio to get square pixels, then the only option is to use
the arbitrary scale factor scaler, as talked in the other email.


> conversion now. The best solution would be 
> {[raw image] -> [scaler] -> [raw image]}
>  but alternative solution can be 
> {[raw image] -> [scaler -> encoder (jpeg-h264)] -> [compressed 
> image-stream]}
> Can i use ISP as separated block or i need to use it as part of
> jpeg-h264 encoder?
> Can i utilize G2D for this purpose for example?
> Does anyone tried anything similar with A20?
> 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] ISP scaling A20

[Manuel Braga]

Hello.

On Fri, 21 Oct 2016 03:19:46 -0700 (PDT) Milos Ladni
<milosladicor...@gmail.com> wrote:
> Hi everyone,
> 
> Because there are PoC of hardware JPEG encoding and decoding, i am
> now interesting of hw scaling..
> Does does anyone tried to scale image (raw yuv 4:2:2 4:2:0 or rgb)
> with A20 hardware?
> How can i do this? I need scaler to scale image from one resolution
> to another.

Yes, there are multiple ways using different hardware blocks, for A20
there is by the use of:

 - display engine (it has a readback feature somewhere, i am not aware
   of someone ever had tried to use, also i do know little about this
   display engine)
 
 - G2D, the 2d engine (i also do not know much about, never used)

 - video engine (aka VPU), more correctly the isp subengine of the video
   engine that can do scaling and cropping at the source for the
   encoding step


> Concretely i read frame from tvin 720x576 4:2:0 and convert it to
> jpeg with libjpegturbo, but i want to switch to hw scaler-encoder
> conversion now. The best solution would be 
> {[raw image] -> [scaler] -> [raw image]}

If is to encode to jpeg the scaled image, then the next is the best.

>  but alternative solution can be 
> {[raw image] -> [scaler -> encoder (jpeg-h264)] -> [compressed 
> image-stream]}

The video engine when encoding takes as source from the veisp
subengine, meaning the scaling and encoding is one step.

> Can i use ISP as separated block or i need to use it as part of
> jpeg-h264 encoder?

First, to not be any confusion we have to define what is the hardware
that is been talked about when using the simple word "ISP". The reason
is that for newer socs (than A20), there is another "ISP" hardware
block.

To make clear, when talking about the isp subengine of the video
engine, is better to call this by the name VEISP.


> Can i utilize G2D for this purpose for example?

Yes.
But it can be done in one step by using VEISP, which can also output
raw pixels (if need).

Actually the video engine can when encoding, also simultaneous in the
same single step output the frame encoded as raw pixels (that is
the VEISP doing).

> Does anyone tried anything similar with A20?
> 

The jpeg encoding PoC that you probable have (the one written by me),
does not enable the scaler, because at the time of the writing there
was not enough information to understand the meaning of the need scaler
coefficients.

That changed some months ago, but this new information is still not
verified that works. This was and is something that is in my todo list,
but never got to do it, because of time.
If you want to use VEISP, then this can be a reason for me to hurry,
and i can see what i can do in the next 2 weeks (if i can allocate time)

Is not very complicated, but takes time to verify that is correct.
And if you can't wait for me to do this, then you are free to give a
try, just say it and start making questions, i can forward the details
of what has to be done (only by words, not source code).


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] VLC with cedarx for A13 on Android (We need to outsource)

[Manuel Braga]

Hi, thanks for contacting the linux-sunxi community.

In the subject line says Android, and this requires to explain, that.
The linux-sunxi community, is basically just working with gnu/linux
type OS, and Android is not much cared about.
But as both (gnu/linux and android) have the same linux kernel in
common, the work that linux-sunxi is doing to improve and upstream can
be certainly be used by android (in the future).

Also was used the word "cedarx", which must be explained that is the
name of the proprietary-binary-blobs library for the sunxi's video
engine hardware. The cedarx-library has a long history of license
ambiguity issues, which Allwinner has some difficulties in understanding
the importance of resolving this so called "license-issues".

The linux-sunxi community tried to get Allwinner collaboration, but
after of a huge amount of "trouble", the best that could be achieved can
be seen in this page http://linux-sunxi.org/CedarX

For this reason, the use of the cedarx-library is not recommended.

The good news, is that this sunxi video engine hardware, has been
already reverse-engineered with successful results, as in this page
tries to explain. http://linux-sunxi.org/Cedrus

This means, that is not required to be dependents of this troublesome
cedarx-library.

But.
The linux-sunxi community is currently only focused in mainline and
upstream work, and there is still plenty to be done.

The A13 soc happens to be the most advanced with the mainline kernel
support, but the Android requirement makes this a complicated matter.



On Tue, 24 May 2016 06:14:12 -0700 (PDT) Mehmet Kurnaz
<hmehmetkur...@gmail.com> wrote:
> Hello everybody,
> 
> We will use A13 for a project that should play MPEG2 TS stream(HTTP
> stream over ethernet) and full hd videos. In the old project we used
> VLC libraries for another platform and want to use same applications. 

If you read the Cedrus wiki page (indicated above), you will find that
currently only exists a vdpau backend implementation for 3.4 kernel. 
And Android + vdpau not been impossible, will certainly be an aberration
that probable should never be tried.

But, you speak about only VLC libraries (in android), this is different
and possible. Simply one could use the fact that Cedrus is a project
100% open-source and just write the support into VLC (for android).

If this interest you, we can forward discuss about how this could be
done.


> Can anybody quote a price and time for this project?

As said above, the people in the linux-sunxi community don't have much
interest in Android and i myself am included.

But if someone wishes to take this opportunity and the route described
above (using the work of the cedrus project and not the
cedarx-license-issues-library), we(the cedrus people) would be happy to
collaborate to make this possible.
Just use this maillist or join us at #cedrus on freenode to chat.


--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: CedarX Encoder Demo

[Manuel Braga]

Hi.

On Sat, 21 May 2016 14:07:37 -0700 (PDT) Rosimildo DaSilva
<rosimi...@gmail.com> wrote:
> Stefan,
> 
> It might look a waste from your point of view, but not from mine.
> 
> I had a task to evaluate AW native encoder on H3, but my conclusion
> was such that I was not able to match the performance and quality of
> native H.264 cameras, without the proper documentation from AW, which
> they never released.
> So, the project I am working on, has decided to use H264 cameras!
> ( for now ).
> 
> Also, I was never able to get the VP8 encoder to work at all.

Well, vp8 encoding is not presented as feature in any datasheets, if
the hardware do really supports is another matter.


> 
> Anyway, between just deleting the sources from my dev machine, I
> decided to place in a git rep, just in case it is useful to someone
> else!

Sorry for being the asshole, but i can not stay silent.
If nobody speaks, in just a few months everything will be forgotten,
and the technical-clueless-user will think that the license-issues are
resolved and no more an issue.

Sorry to say, but this is only useful to whitewashing and make believe
that is acceptable to use the
proprietary-binary-blobs-with-random-license-issues, in a community
that claims to be an open-source community.

And that is why, i will reply to whoever who forgets to clearly
recognize that license-issues exist. Because the same error committed 3
years ago, should not be repeated again.

3 years ago, was when for the first time was discovered the amount of
the license-violations in the cedarx-library, but as we(the linux-sunxi
community) wished to have a positive relation will Allwinner, we let
this information out of public knowledge. Because we preferred to work
with Allwinner that to go bother and scare way with this license-issues.

And the work that was happen at that same time, had demonstrated the
feasibility of the video-engine-reversing-engineering-effort. And to go
bother Allwinner with license-issues that nobody likes to be involved
would not bring any benefit.

But, what happened, everyone already knows.
The reversing-engineering-effort was ignored, and instead it was
expected from the linux-sunxi community to accepted the
proprietary-binary-blobs-with-random-license-issues, and in this
conditions nobody that claims to be part of an open-source-community
should be indifferent and stay silent.

And that is why, i speak.

--
Manuel Braga

> 
> No hard feelings!
> 
> R
> On Saturday, May 21, 2016 at 3:25:33 PM UTC-5, Stefan Monnier wrote:
> >
> > > I have added "V4l2" sources to the CedarX encoder demo. 
> > > This is basically the "Camera" sources from AW demo that was
> > > around for A20... 
> >
> > IOW a complete waste of time. 
> > I'd encourage you instead to work with the Cedrus library, which
> > has the philosophical/ethical advantage of being Free Software, and
> > the technical advantages of not being a dead-end black-box. 
> >
> >
> > 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] CedarX Encoder Demo

[Manuel Braga]

On Sat, 21 May 2016 20:33:18 +0200 Bastiaan van den Berg
<buzzti...@gmail.com> wrote:
> On Sat, May 21, 2016 at 5:27 PM, Rosimildo DaSilva
> <rosimi...@gmail.com> wrote:
> 
> > I have added "V4l2" sources to the CedarX encoder demo.
> >
> > This is basically the "Camera" sources from AW demo that was around
> > for A20...
> >
> >
> Thanks, good job
> 

Thanks and good job for you too, in reassuring the true nature of this
sunxi community. As a community were "everyone" is too "professional" to
recognize the existence of the unspeakable random-license-issues, as
the real problem that is stopping the creation of without-license-issues
proper upstream software.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] CedarX Encoder Demo

[Manuel Braga]

Hi.

Unfortunately, i can't give thanks and say good job.

What rests is the never ending repeating the same thing, because as you
already know, this is using the proprietary-binary-blobs with the
random-license-issues that "everybody" is too "professional" to care.

Whatever is thought of me, as being an extremist or fanatic or with an
agenda against evil-proprietary-binary-blobs doesn't change anything.
I am well aware, that there are business and users that are pragmatic
and just search for something that works(tm), and give none preference
about if close-source or if open-source.

And i respect their decision.


What i can't do, and which i will not keep my mouth shut about, is.
When the effort for a 100% libre and open-source driver and software is
being ignored, and instead there is a preference for the
proprietary-binary-blobs with the random-license-issues.

And i repeat again, random-license-issues that stop the contribution of
people that wishes to not be an *excuse* to the continuous disregard of
license-issues which in certain cases are to the point of being
clear GPL-violations, that is very well know to exist in this
embedded-software-development world.

In this 4+ years of linux-sunxi.org community existence, didn't nobody
thought why this CedarX library isn't integrated in a easy form to use?

The answer is, because of license-issues.

Why the popular media player called XBMC/Kodi doesn't support and
even why are their developers are actively "boycotting" allwinner
devices?

The answer is, because of license-issues.


But this is this sunxi community.
A community which their "users" prefer to work in the
proprietary-binary-blobs-with-random-license-issues, than to support or
help or join the effort for the creation of a
mainlineable-100%-libre-open-source-driver-and-software

What can i do?
Please tell me that you don't expect from me to be the sucker that has
to do all this work "alone", when at the same time, the ones that will
the most benefit are doing nothing to help.
And to make clear, this is not a begging for money, i personally would
be very happy do this at zero cost for a community that cares about
software and about the respect of the licenses used.

To terminate, if there is anyone reading this that wishes to be part of
this community, by doing what they can to help or contribute in this
effort. We are at #cedrus in freenode, everybody is welcomed to join us.


--
Manuel Braga

On Sat, 21 May 2016 08:27:04 -0700 (PDT) Rosimildo DaSilva
<rosimi...@gmail.com> wrote:
> I have added "V4l2" sources to the CedarX encoder demo.
> 
> This is basically the "Camera" sources from AW demo that was around
> for A20...
> 
> https://github.com/rosimildo/videoenc
> 
> Instructions to compile and install is on the repository.
> 
> 
> If you have a V4L2 source ( web camera ) as /dev/video0:
> 
>   mkfifo /tmp/out1.h264
>  ./videoenc -i /dev/video0 -k 2 -r 25 -b 1024 -s 640x480 -o 
> /tmp/out1.h264
> 
> The output file "out1.h264" cam be played on VLC or ffplay.
> 
> R
> 



-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Manuel Braga]

On Sun, 13 Mar 2016 18:00:17 -0400 "jonsm...@gmail.com"
<jonsm...@gmail.com> wrote:
> On Sun, Mar 13, 2016 at 5:16 PM, Manuel Braga <mul.br...@gmail.com>
> wrote:
> > On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva
> > <rosimi...@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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Manuel Braga]

On Sun, 13 Mar 2016 12:16:11 -0700 (PDT) "@lex" <alex.mob...@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.





> 
> On Sunday, March 13, 2016 at 2:30:26 PM UTC-3, Manuel Braga wrote:
> >
> >
> > 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. 
> >
> >
> >
> >
> > On Sun, 13 Mar 2016 10:16:01 -0500 Rosimildo DaSilva 
> > <rosi...@gmail.com > wrote: 
> > > 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 
> > > 
> > > 
> > > 
> > > On Sun, Mar 13, 2016 at 9:27 AM, @lex <alex@gmail.com
> > > > 
> > 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, 20

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Manuel Braga]

On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva
<rosimi...@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.



> 
> R
> 
> On Sun, Mar 13, 2016 at 12:30 PM, Manuel Braga <mul.br...@gmail.com>
> wrote:
> 
> >
> > 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-rand

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Manuel Braga]

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.




On Sun, 13 Mar 2016 10:16:01 -0500 Rosimildo DaSilva
<rosimi...@gmail.com> wrote:
> 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
> 
> 
> 
> On Sun, Mar 13, 2016 at 9:27 AM, @lex <alex.mob...@gmail.com> 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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Banana Pi (M1), Bananian and hardware acceleration for VLC

[Manuel Braga]

On Fri, 11 Mar 2016 12:45:59 -0800 (PST) Patrick Frank
<patrick.frank@gmail.com> wrote:
> Thank you for posting that article, Manuel.
> I must admit that I do not fully understand hardware internals and I
> did not buy my Banana Pi for educational purposes. I wanted to build
> a cheap multimedia center.
> So when the video encoding takes places in the VPU I am assuming the 
> component that is used in the Banana Pi M1 is not capable of 1080p
> video playback? Or what is the message behind your posting?

Hi.
The message was that you are in the wrong path.

A20, which your device use, is well capable of 1080p hardware
accelerated video playback. In the case of wanting to know more, here
is a link here for information reference. http://linux-sunxi.org/Cedrus

One thing to have attention, is to use a media player with support to
use vdpau. 

As i know it is a pain to do source code compiling for someone that is
not here for "educational purposes". I advise you to just use a ready
made image.

>From my knowledge, i believe that http://www.armbian.com/ is one of
those, which already include the above software ready to use.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Banana Pi (M1), Bananian and hardware acceleration for VLC

[Manuel Braga]

On Thu, 10 Mar 2016 08:00:42 -0800 (PST) Patrick Frank
<patrick.frank@gmail.com> wrote:
> Hello,
> 
> on my Banana Pi (I think its an M1) I run the Jessie image from 
> bananian.org with LXDE and VLC via HDMI.
> And videos with a 720p resolution play well but only with 1:1 size
> not on fullscreen.
> Videos with 1080p resolution do not play properly either way.
> 
> So I enabled the Mali driver in the kernel and lsmod shows that it
> was loaded successfully.
> Then I followed linux-sunxi.org/Mali_binary_driver and
> linux-sunxi.org/Xorg and /var/log/Xorg.0.log shows that fbturbo
> loaded successfully.
> 
> But the problem with VLC stays the same. Any ideas how to
> troubleshoot this problem?
> 

Hello.
It appears that you are having a misunderstand by thinking that to have
hardware accelerated video decoding would require a GPU (3d graphic
engine), this is not true.

You can find a explication in this link.
http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Manuel Braga]

On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva
<rosimi...@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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] ve encondig JPEG / H264 for H3

[Manuel Braga]

On Fri, 12 Feb 2016 15:38:29 -0800 (PST) "@lex" <alex.mob...@gmail.com>
wrote:
> Thanks for answering.
> 
> I want to encode (JPEG and H264) images i grab from the camera and
> send it to clients (linux and windows) and this could be used on all
> new H3 devices and everybody else could benefit from this. Simple as
> that.
> 
> Sure this can be done without HW encoding or no encoding at all but
> we need a lot of bandwith.

Please be aware, that this video engine can only encode h264 in
baseline profile, or more correctly, there isn't information if the
hardware can or how to make it use a bigger profile.
With low bitrate, the quality of the image will be very bad. So take
account of using at least 4-5Mbps for 720p video for acceptable
quality, as example.


> 
> If you have spare time and are willing to get this done i can arrange
> to send you a Opi one or Opi PC, what do you think?

Thanks for the offer, but it is as you said. And as i said in last
month, there isn't enough time to do everything, we have to make
choices, and i choose to not "waste" time in a temporary workaround.
But that is only me, others can do what they think is better.
And if there are others, like you that don't want to wait, then you all
know what to do.

And as i did here, i am available to answer any questions.


> 
> I hope the child has not been born dead already!

A unborn child should not be expected to walk.

 
> 
> On Friday, February 12, 2016 at 8:48:48 PM UTC-2, Manuel Braga wrote:
> >
> > On Fri, 12 Feb 2016 05:59:36 -0800 (PST) "@lex" <alex....@gmail.com 
> > > 
> > wrote: 
> > > Hi, 
> > > 
> > > This is my attempt to port jepoc (Manuel Braga) to encode JPEG on
> > > H3 and later try H264 using ve (Jens Kuske). 
> >
> > Thanks for doing something. 
> > Things will only happen, if there are people that wishes then to
> > happen. 
> >
> >
> > > Needless to say, it does not work yet (or may never work), just 
> > > compile and run without encoding for several reason. 
> >
> > This is a huge mess, with each new soc release, there are a new
> > vendor kernel that unfortunately keeps breaking backward
> > compatibility. And this happens to be the case for the kernel used
> > for H3, and its /dev/cedar_dev kernel driver. 
> >
> >
> > The differences to be aware are: 
> >
> >   1. memory allocator now used is ion (/dev/ion). 
> >   2. ioctls numbers were changed in a not backward compatibility
> > way. 3. the H3 video engine hardware is a new version, in which the
> > way to enable the subengine for enconding changed. 
> >
> > 1 and 2 is only a software problem, and there is already support in 
> > libvdpau-sunxi for H3 (that faces this same dificuties). But there
> > is still a problem with the ioctl, libvdpau-sunxi uses a hack with
> > a ioctl offset to workaround this. 
> > But for encoding is need a ioctl that is not there. The ioctl to
> > wait for the interrupt of the encoding subengine
> > (IOCTL_WAIT_VE_EN). 
> >
> > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/1e4a69db3ebb2aa51570c9880102766a6d333257/drivers/media/cedar-ve/cedar_ve.h#L8
> >  
> >
> > For point 3. 
> > In newer video engine hardware versions (newer then A20/A13), the 
> > decode/encode was split, now requiring different setting to enable
> > the subengine for encoding (that is in the VE_CTRL register) 
> > http://linux-sunxi.org/VE_Register_guide#MACC_VE_CTRL 
> > bits 6 and 7 must be set 
> > bits[3:0] are now only used for selecting decoding, and can be set
> > 0x7 
> >
> >
> > All this, i am saying without actually having tried in the
> > hardware, there can be incorrections, and the differences in how to
> > set the encoding process could be more than expected. Please take
> > attention. 
> >
> >
> > > 
> > > Since the authors are willing to help, i invite them and all
> > > others to have a look, fix, suggest, contribute as you wish in a
> > > hope it can do something useful. 
> >
> > Unfortunately, i don't have a H3 or similar newer (video engine)
> > device in my hands. This creates a limit in how can i help, because
> > of not having the hardware to experiment to see what works or not
> > works. But i am available to (try) answer any questions. 
> >
> >
> > > 
> > > And sorry for the monolithic way of programming, it was just
> > > easier for me to get it compiled. 
> > > 
> > > https://github.com/avafinger/jepocx 
> >
> > If you could had made your changes 

Re: [linux-sunxi] ve encondig JPEG / H264 for H3

[Manuel Braga]

On Fri, 12 Feb 2016 05:59:36 -0800 (PST) "@lex" <alex.mob...@gmail.com>
wrote:
> Hi,
> 
> This is my attempt to port jepoc (Manuel Braga) to encode JPEG on H3
> and later try H264 using ve (Jens Kuske).

Thanks for doing something.
Things will only happen, if there are people that wishes then to happen.


> Needless to say, it does not work yet (or may never work), just
> compile and run without encoding for several reason.

This is a huge mess, with each new soc release, there are a new vendor
kernel that unfortunately keeps breaking backward compatibility. And
this happens to be the case for the kernel used for H3, and its
/dev/cedar_dev kernel driver.


The differences to be aware are:

  1. memory allocator now used is ion (/dev/ion).
  2. ioctls numbers were changed in a not backward compatibility way.
  3. the H3 video engine hardware is a new version, in which the way to
 enable the subengine for enconding changed.

1 and 2 is only a software problem, and there is already support in
libvdpau-sunxi for H3 (that faces this same dificuties). But there is
still a problem with the ioctl, libvdpau-sunxi uses a hack with a ioctl
offset to workaround this.
But for encoding is need a ioctl that is not there. The ioctl to wait
for the interrupt of the encoding subengine (IOCTL_WAIT_VE_EN).
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/1e4a69db3ebb2aa51570c9880102766a6d333257/drivers/media/cedar-ve/cedar_ve.h#L8

For point 3.
In newer video engine hardware versions (newer then A20/A13), the
decode/encode was split, now requiring different setting to enable the
subengine for encoding (that is in the VE_CTRL register)
http://linux-sunxi.org/VE_Register_guide#MACC_VE_CTRL
bits 6 and 7 must be set
bits[3:0] are now only used for selecting decoding, and can be set 0x7


All this, i am saying without actually having tried in the hardware,
there can be incorrections, and the differences in how to set the
encoding process could be more than expected. Please take attention.


> 
> Since the authors are willing to help, i invite them and all others
> to have a look, fix, suggest, contribute as you wish in a hope it can
> do something useful.

Unfortunately, i don't have a H3 or similar newer (video engine) device
in my hands. This creates a limit in how can i help, because of not
having the hardware to experiment to see what works or not works.
But i am available to (try) answer any questions.


> 
> And sorry for the monolithic way of programming, it was just easier
> for me to get it compiled.
> 
> https://github.com/avafinger/jepocx

If you could had made your changes in a separated commit, that would
make easy to see them.

But, first.
I would like to ask, what do you want to do? Your requirements/user
case?

Because, i think it would be more useful to add support to the usual
ffmpeg/gstreamer (whatever is preferred). Keeping in mind that this is
only a temporary solution until there is something better.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] random source related video engine things

[Manuel Braga]

On Sat, 2 Jan 2016 18:11:08 + Simon Kenyon <simoncken...@gmail.com>
wrote:
> are there no better supported chips with similar functionality and
> similar price points? if there are, why not move to them?
> 
> if you keep banging your head on the wall, all you end up with is a
> bloody forehead.

Safety first, any banging are done wearing a helmet. (joking)

> 
> in the interests of full disclosure. i am a lurker here. have been
> for several years. i have several devices with AW chips in them. i
> have not plugged one in in a long time.
> 
> have signed up for a pine64. but really not sure why i bothered.
> 
> i cannot see the situation changing unless there is a fundamental
> shift in thinking from allwinner. —

Is not only allwinner.
But also the random board vendor and its users, if they were willing.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: random source related video engine things

[Manuel Braga]

On Mon, 4 Jan 2016 10:57:41 -0800 (PST) Rosimildo DaSilva
<rosimi...@gmail.com> wrote:
> On Saturday, January 2, 2016 at 11:32:58 AM UTC-6, Manuel Braga wrote:
> >
> > On Sat, 2 Jan 2016 05:47:18 -0800 (PST) Rosimildo DaSilva 
> > <rosi...@gmail.com > wrote: 
> > > Nove, 
> > > 
> > > I believe this community should take the ENCODER from a PoC level
> > > to 
> >
> > Who is this community? The same people that are here with zero
> > support from the ones that have the most to benefit. 
> >
> > Do you all expect from us to do all this huge work in this
> > unfavorable conditions? 
> >
> >
> The community is sunxi. 
> 
> No, I don't expect a few developers to do all the work. But, if the
> most skilled ones land a bare framework,  more folks may help testing
> and fixing bugs.
> Ideally, AW should pay for such effort, but I would not hold my
> breath waiting for AW to move in any way,

When allwinner has "trouble" into understanding the importance of
respecting license of the software that is using, and to correctly
license for distribution any proprietary binaries only software.
Talking of "pay" is off-course it-not-will-happen.

The "unfavorable conditions" and "no support" is not about begging for
$$$. But sure, any serious business that recognizes value and wishes to
have a more professional relationship, can choose to take this route.

The other route, is to "support" and help in the creation of "favorable
conditions" in which all this huge amount of work could be done at zero
cost.

Personally, i would liked very much to participate in the creation of
this proper driver and would do this at zero cost (within my limits of
available time).
But with this unfavorable conditions, there are one thing that i can not
accept, and that is, to get involved in hypothetical future "license
issues" and be left alone in the task of enforcing the license of the
source code that i had written.


> 
> Maybe, someone like you ( nove or jemk ) could start a "kickstart
> project" to bring "Media capabilities" to AW Soc's with a complete
> open source stack. 
> I only see these community funded projects for some stupid peace of
> H/W, and maybe someone should try to see how it works with S/W stacks.

It would fail.
The users that choose allwinner hardware, do it because of the price, to
pay for software is unthinkable.

To the users that sincerely would contribute to this, what i can
suggest is to use their money to reward hardware vendors that do the
right thing.


> 
>  
> 
> >
> > > a more or less demo similar to the one released by AW using the
> > > blobs 
> >
> > There are priorities and it arrives to a point in which we have to
> > make a choice. We are here to make proper software, and the next
> > step in this route is a proper driver for this video engine. 
> >
> > But this will not happen tomorrow or in the next month, this is
> > just not possible when this unfavorable conditions persist. 
> >
> >
> > > 
> > > 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! 
> >
> > If it is very important, why do we have zero support? Why isn't
> > those hardware vendor and its users here asking for assistance? 
> >
> > What can it be seen, is that in this last year events. not even a 
> > single discussion about the "license issues" in the forums of the 
> > random vendor. (expect one occurrence in a vendor blog) 
> >
> > This shows the level of support and respect of the software that
> > they are using. For this hardware vendors what they care is to sell
> > the random board, and for that they only care about software the
> > sufficient to fool the clueless user in giving them the money. 
> >
> > For that, everyone is happy with an old kernel/uboot with random
> > gpl violations and random license issues. 
> >
> > With all this issues, with dumped old kernel trees that break api 
> > backward compatibility in every random soc release, it is very hard
> > to offer adequate proper software. 
> >
> > Look at the case of rockchip, in which its developers (full with 
> > rock-chips.com email) are contributing to the mainline kernel, that
> > is not because one day they feel like to do this. But because of 
> > costumers that requested this kind of support, w

[linux-sunxi] random source related video engine things

[Manuel Braga]

On Sat, 2 Jan 2016 05:47:18 -0800 (PST) Rosimildo DaSilva
<rosimi...@gmail.com> wrote:
> Nove,
> 
> I believe this community should take the ENCODER from a PoC level to

Who is this community? The same people that are here with zero support
from the ones that have the most to benefit.

Do you all expect from us to do all this huge work in this unfavorable
conditions?


> a more or less demo similar to the one released by AW using the blobs

There are priorities and it arrives to a point in which we have to make
a choice. We are here to make proper software, and the next step in
this route is a proper driver for this video engine.

But this will not happen tomorrow or in the next month, this is just
not possible when this unfavorable conditions persist.


> 
> 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!

If it is very important, why do we have zero support? Why isn't those
hardware vendor and its users here asking for assistance?

What can it be seen, is that in this last year events. not even a
single discussion about the "license issues" in the forums of the
random vendor. (expect one occurrence in a vendor blog)

This shows the level of support and respect of the software that they
are using. For this hardware vendors what they care is to sell the
random board, and for that they only care about software the sufficient
to fool the clueless user in giving them the money.

For that, everyone is happy with an old kernel/uboot with random gpl
violations and random license issues.

With all this issues, with dumped old kernel trees that break api
backward compatibility in every random soc release, it is very hard to
offer adequate proper software.

Look at the case of rockchip, in which its developers (full with
rock-chips.com email) are contributing to the mainline kernel, that is
not because one day they feel like to do this. But because of
costumers that requested this kind of support, which google with its
chromeos business is a direct cause.

In allwinner world, this doesn't exist.



> 
> 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

If someone is in hurry to get something that works for the required
user case, they are free to do those work themselves.
We are here to offer help and assistance within our limits.



> 
> 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 ).
>

If someone wants for us to do this work, they must give us a *valid*
reason, of why we should stop doing what we are doing now and prioritize
this request.
 

> 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

For that to happen, we need to have an user base that prefers a libre
and open source solution first.

Instead of a user base that prefers to run around a proprietary library
binary blobs with a long history of license ambiguity issues.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Manuel Braga]

On Thu, 31 Dec 2015 02:49:02 -0800 (PST) Rosimildo DaSilva
<rosimi...@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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Manuel Braga]

On Thu, 31 Dec 2015 12:11:42 -0500 Stefan Monnier
<monn...@iro.umontreal.ca> wrote:
> > 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.
> 
> I know libvdpau-sunxi won't do what he wants right now, which is why
> I said:
> > > It needs a lot of work, but  at least it's cleaner and will
> > > benefit more people in the long run.

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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Jpeg Encoding

[Manuel Braga]

Hello.

On Thu, 17 Dec 2015 15:30:44 + (UTC) Martin <bananajoe4...@gmx.de>
wrote:
> Manuel Braga <mul.braga@...> writes:
> 
> > 
> > > there is no possibility for jpeg-encoding,is it?
> > 
> > Yes there is, the hardware supports jpeg baseline encoding, maximum
> > 4080x4080, this is the same type for mjpeg.
> > 
> > And it is already almost complete reverse engineered, only misses
> > some checks in rounding values in the quantization step.
> > https://gitorious.org/recedro/jepoc
> > Of course this is a prof of concept, only a test to confirming how
> > the hardware works. But all that is need is there.
> > 
> I know this is a quite old thread, but I would like to implement jpeg
> thumbnail encoding in XMBC (since jpeg HW decoding is working now),

This is interesting, is the work(source) available somewhere?


> but gitorious has closed down and therefore the link
> https://gitorious.org/recedro/jepoc
> is no longer working.
> Is this proof of concept for JPEG encoding on Allwinner A10/A20
> anywhere else available?

http://dl.linux-sunxi.org/users/nove/jepoc.tar.gz
Until a new place is found, a tarball should suffice.

But as you well are aware, this a proof of concept with the function to
prove that we understand how to use this hardware. And only that.

It is not recommend to use this for any other function.


The correct solution is to work for a proper driver for this video
engine, and then work with the upstream people to assure proper
support for the (random) software.


But, it is seen that majority of the hardware vendors and its users are
more interested to run around binaries blob with license ambiguity
issues.
Than to support the work this community (linux-sunxi) is doing.

And off course with this unfavorable conditions, is natural this work
for an 100% free-and-open-source proper driver is not at the level of
advance that we all wish it to be.

If only if.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] KMS - VE - Lima

[Manuel Braga]

ny driver, because i don't
want to be *alone* in the likelihood of having to remember that license
violations aren't acceptable.


Next would be about the random board vendors and its users, that talk
about open-source and desire to have hardware accelerated media-playback
which for them open-source is only for marketing, and that do nothing
to support this community.

But by writing all this, is enough to get in bad mood, so i end here.
As i would prefer to spend my time in technical matters that keeping
rewind the same tape.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [ANNOUNCE] Allwinner releasing CedarX open source

[Manuel Braga]

On Sun, 12 Jul 2015 17:41:04 -0700 (PDT) rainboy...@gmail.com wrote:
 Hi, all:
does the cedarx runs ok?  i compile the lib as follow:

Hi,
Up to now, i am not aware of any reports of people trying to work with
this new sunxi-cedarx library. (strangely, after so much asking/begging
directly to allwinner to open-source the cedarx library)

You are the first (to my knowledge), that is trying to use this
library, meaning that the only answer to the question i can give is,
i don't know if this new cedarx library runs ok.
(i still didn't arrange time to look more in detail and actually try it)


If you happen to get some success, please report back.
Or even better, help the next person(s) avoid the trouble that you are
having by adding your finding to the linux-sunxi wiki?
Maybe in a new page like in http://linux-sunxi.org/sunxi-cedarx



 1. ./bootstrap
 2. ./configure --prefix=/home/test/ --host=arm-linux-gnueabihf (im
 not sure the parameter is ok or not)
 3. make  make install

Did you also tried by compiling natively?
If not, try first this way, before going for cross-compiling.


 
 then so file generated, then run demo in sunxi-cedarx/demo/vencoder
 on A20 board, then tell me segment fault...

Then run under a debugger and see where the segment fault is happening,
if is in open-source part, then it can be fixed because to segment
fault is itself a bug, and should have checks and instead print a error
message, which helps to see what is wrong or missing.

If is in the close-source-plugin, then there isn't much that can be
done, other than maybe, more asking/begging allwinner to release a
new close-source-plugin-binary which with some luck could fix the issue.


 it's strange that there is no code to call VEncoderRegister function
 in Venc_device.c.

Not strange at all, this new open-source cedarx library is dependent in
the use of close-source-plugin-binaries to offer the encoding feature
that you wish to use.


 
 
 On Tuesday, May 19, 2015 at 8:47:45 AM UTC+8, kevin.z.m.zh wrote:
 
   Hi All,
 
  We're proud to announce a new code release today for CedarX. Before
  delving into the details, I'd like to share some context:
 
  1. As a growing company, we are doing our best to understand the
  needs of the
  open source software community. This is a learning process. We're
  working with different people across the Linux development
  community to better understand best practices. 
 
  2. Open source software development is a collaborative process. It
  works because people genuinely want to help others improve and be
  successful. Some
  people are new and others help them learn the ropes over time. We
  hope that this same positive feedback process can be applied to GPL.
 
  With that context, here's an update on our CedarX code release (we
  welcome constructive feedback!)
 
  1. New code architecture. Driver has been split into several
  plugins, one plugin per video format. 
  2. GPL-complaint. We have scanned and analyzed the code to ensure
  that there
  is no GPL code used or called.
  3. Partial CedarX video decoder source code release. MPEG2, MPEG4,
  MJPEG, and
  H264 drivers source code available. 
 
  We hope this is helpful to everyone. If not, please let us know how
  we can improve. Thanks!
 
   --
   Best Regards,
  kevin.z.m
 
   
   NOTICE: This e-mail and any included attachments are intended only
  for the sole use of named and intended recipient (s) only. If you
  are the named and intended recipient, please note that the
  information contained in this email and its embedded files are
  confidential and privileged. If you are neither the intended nor
  named recipient, you are hereby notified that any unauthorized
  review, use, disclosure, dissemination, distribution, or copying of
  this communication, or any of its contents, is strictly prohibited.
  Please reply to the sender and destroy the original message and all
  your records of this message (whether electronic or otherwise).
  Furthermore, you should not disclose to any other person, use, copy
  or disseminate the contents of this e-mail and/or the documents
  accompanying it. 
 
 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Further Allwinner misbehaviour.

[Manuel Braga]

On Mon, 29 Jun 2015 02:33:40 +0200 Henrik Nordström
hen...@henriknordstrom.net wrote:
 fre 2015-06-26 klockan 01:12 +1000 skrev Julian Calaby:
  
  It's obvious what is required:
  1. Datasheets
  2. Programming manuals
  3. GPL compliant drivers
  4. (L)GPL compliant userspace stuff
 
  and maybe
  
  5. Some on-going contribution to the community
 
 And
 
 6. That community uses and improves the free alternatives developed by
 the community instead of encouraging further bad actions in paths that
 is unlikely to ever result in anything meeting the broad community
 goals.
 

This is rather a complicated matter, that all depends in the
definition of community, in this case the linux-sunxi community.

And only comes to my mind as answer: What more do you want from us?
Because this one side taking convey the felling of whatever we do, is
not enough, and will never be enough.

What can we do?
If there are still things not done, is not because the people involved
in those things, didn't work or are working harder enough. Maybe
even the opposite happened, they worked harder than they cloud, just at
the end to get their work felt unappreciated or even to the point of
being ignored.

What kind of motivation one can get, from seeing users (in random
places) asking/begging for open-source drivers, when those same
users not even acknowledge in those same asking/begging posts that we
exist.

With this conditions, is only natural to exist bigger priorities
greater than sunxi, and this is want makes us to arrive to this present
situation.


A community is not a community, when is always the same people
giving, and the same people taking.

And is my personal opinion, that the hardware vendors (the ones that are
getting monetary profit), and the users (the ones that gave money to
hardware vendors), are in fault.

Because without support, linux-sunxi community can't do more.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Further Allwinner misbehaviour.

[Manuel Braga]

On Mon, 29 Jun 2015 02:19:00 +0200 Henrik Nordström
hen...@henriknordstrom.net wrote:
 tor 2015-06-25 klockan 12:13 +0200 skrev Luc Verhaegen:
  The bad copyright headers is just stupidity. The direct loading of
  non-LGPLed binaries into LGPLed code is very deliberate.
 
 And to my best understanding is not in any way a violation of the LGPL
 license. Care to explain what I am missing? (ignoring any past state
 of these files)

We are all IANAL. And i can only give my opinion.


 If the code had been GPL licensed then sure. But this is LGPL with
 it's implicit linking exception.

LGPL was created to allow close-source proprietary programs linking to
LGPL licensed libraries. The user can choose to not use the proprietary
program, and by doing so, this doesn't have an effect in the user
ability or in the functionality of the LGPL library, to be used in other
uses.

In this case.
A LGPL licensed library is linking with a proprietary close-source
plugin. The user can choose to not use the proprietary plugin, but by
doing so, as the interesting functionality  are implemented in the
close-source plugin, the user is left with nothing more that a wrapper,
which doesn't have much useful. (expecting the existence of the plugins
with source available)

Repeating the IANAL, i don't know if the LGPL license allow or not
allows this case.

But.
We should not exit the context of why this new cedarx library came to
existence. As the license issues of the older cedarx library were so
out of proportion, that the only way to resolve them, was to accept
a rewrite of a new cedarx library with equal functionally.

After all of this, to get this new cedarx library with uses proprietary
close-source plugins, only appears to be a way that allwinner is using
to escape their responsibilities.

And this behaviour is not acceptable, and should be spoken out.

As Allwinner itself wrote:
Allwinner is joining the Linux Foundation to support Linux and to
improve what we see as two important open source software development
capabilities: collaboration and compliance,

 
 Regards
 Henrik
 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Further Allwinner misbehaviour.

[Manuel Braga]

On Mon, 22 Jun 2015 12:07:24 -0400 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 On Mon, Jun 22, 2015 at 11:54 AM, Rodrigo Pereira
 rodrigo2kpere...@gmail.com wrote:
  I don't understand any advantages of put a device driver code in
  secret. Someone can explain the advantage of a secret device
  driver? Maybe is about money. They want to license the code to some
  company and charge money for that. In case I want to buy the source
  code, how much this will cost?
 
 There are many reasons for keeping device drivers code secret...

I am answering, not to oppose this points, but because i believe that
this answer should be complemented in the context of allwinner's video
engine. That has been in the focus of this discussions. So here goes.
 

 1) You believe you have an innovative hardware implementation and are
 protecting it via trade secret. Releasing the driver source code will
 provide register definitions and an understanding of how the hardware
 works. Competitors will see this and copy your hardware.

Register definitions, which in large part have been already Reverse
Engineered by the people involved in the Cedrus effort, that had
started 2 years ago and which results can be seen in the wiki for
everyone that wants to see.
http://linux-sunxi.org/VE_Register_guide

What little is still missing is only a question of priorities and
needs, because as everyone can see, this information was and is
more than enough for the creation of a working vdpau implementation.
http://linux-sunxi.org/Cedrus
https://github.com/linux-sunxi/libvdpau-sunxi

There is nothing to hide.


 
 2) Your hardware implementation is violating patents or you are afraid
 that people will sue you for patent infringement even when you aren't.
 Closed source makes it much hard for trolls to launch a patent suit.

This patent trolls will not be very successful if they can be stopped by
close source software, or are the patent trolls too greed to paid
someone to look for targets.

This video engine was already successful reverse engineered, where it
was found that this video engine hardware is of fixed-function-kind.
Meaning that everything (the codec) are done by the hardware in the
silicon die. The software driver task in only one of feeding the
hardware.

All the secrets or patenta are in the hardware, and not in the software.

 
 3) You have licensed third party code for use in your device driver
 and you don't have the ability to open source. The third party that
 wrote this code wants to sell it multiple times so they refuse to open
 source.  Common example -- lighting or physic engines in GPU drivers.

Then here, the solution is to rewrite what can not be open-sourced, 
and as this video engine is very simples, this is not difficult task.

As can be seen, by the current cedarx driver, which is a rewrite.



 
 4) You are afraid competitors with similar hardware will take the
 source you have worked hard to write, modify a few lines, and have a
 free driver for their hardware.

Free, like taking the linux kernel source and the android kernel source,
and modify to add support for the some particular socs.
Or by taking some LGPL license source code and include in a video
engine driver.


 
 5) Your hardware is really messed up and almost broken. These warts
 are embarrassing and you hide the work arounds in closed source.

Actually, this video engine is not bad.
It has some (hardware) limitations, but this has been improving in
newer versions, and up to now, i only found one undefined (maybe
better to say unexpected because should not happen in normal use)
This to say, that this video engine hardware is very well behaved,
whatever can be writing to registers or whatever state the hardware get
into, can always be recovered from.

 
 6) You licensed the IP for the hardware. As part of the IP licensing
 agreement you are required to keep the register definitions closed.

Register definitions that are already here,
http://linux-sunxi.org/VE_Register_guide
which everyone can see, that there isn't anything to hide.
 
 
 7) Your secret driver code is violating someone's copyright.

Like the copyright of open source software developers that published
source code under a (L)GPL license.


 
 and so on.
 
 
 
 
  Em segunda-feira, 22 de junho de 2015 09:19:54 UTC-3, Luc Verhaegen
  escreveu:
 
  Hi,
 
  It's been a month since Allwinners big open source release,
  where they tried to shut up the big (and very justified) GPL
  violations noise by releasing some code which moves decoder codecs
  into modules, and by releasing some codecs as open source as well.
  As i predicted then, Allwinner now has taken the next step:
 
  They produced a binary for the decoder, which is loaded in:
 
  https://github.com/allwinner-zh/media-codec/blob/72f2b8537/sunxi-cedarx/SOURCE/vencoder/venc_device.c
 
  Note the Proprietary license notice on top of this and other new
  files.
 
  Even if we ignore the past, all of this is built together with
  LGPLed 

Re: [linux-sunxi] New CedarX API documentation

[Manuel Braga]

On Fri, 12 Jun 2015 05:49:43 -0700 (PDT) yonnetbili...@gmail.com wrote:
 Hi everyone;
 
 I just get some new files regarding CedarX, and uploaded to
 https://github.com/stulluk/CedarX-12.06.2015

Thanks. This is a newer version of what is in the official
repository at https://github.com/allwinner-zh/media-codec
This throw away code dumps, only creates confusion.

But, at the first glance, i see 2 license issues.
* vencoder source code files have a proprietary and confidential header
* the close-source-plugins-binary-blobs have no license

With this license issues, i don't see how this can be usable.


 
 I hope professional friends may have a look, especially to the DOC

I am not a professional, so take what i have to say for what it's worth.



 folder and the example C application.

The documentation is in Chinese, but is not a problem when one can look
at the source code, and with all this in the end we will even arrive to
learn some Chinese. Is really not a problem.

That is a simple example in how to use the cedarx api for encoding, if
that is too hard to use, then there is also an OpenMax implementation.
Up to now only has support for decoding, hopeful encoding will also be
eventually added.
But take notice that when using OpenMax, that is an api that tries to
offer an abstraction of the hardware, there can be a performance
penalty caused by a conversion of picture pixel data formats in the cpu.
(the file transform_color_format.c) as is in the case of decoding in
A10/A20/A13


Be careful of what i am saying, because i have not yet tried to
compile or use this newer more open source cedarx, in the same mode i
also never used anything with OpenMax.
So i don't know if is working.


 
 Is it useful for linux-sunxi?

Only if there is someone that will take the trouble.

Allwinner is still learning in how to collaborate with the community.
Until then, the only way that linux-sunxi community could make any use
of this would be to fork it. And everyone can see how troublesome this
could become when the linux-sunxi community has so great difficulties of
getting answers from allwinner, related to this video engine hardware.




 Can we use this in Android?

Because of close-source-plugins-binary-blobs, would be required to also
have them in the armel form for Android.
I presume, i didn't tested, that those binaries in this dump are armhf.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [ANNOUNCE] Allwinner releasing CedarX open source

[Manuel Braga]

On Tue, 19 May 2015 08:44:13 +0800 ke...@allwinnertech.com
ke...@allwinnertech.com wrote:
 3. Partial CedarX video decoder source code release. MPEG2, MPEG4,
 MJPEG, and H264 drivers source code available.

And for the others codecs, what are allwinner plans?
Should we expect for them to also be released, and which and in what
time frame should be this expected to happen?

This would be a very useful information to have, because this would help
us decide if we also have to reverse engineering h265, or only wait for
your release.
As h265 is the next much wished codec to have, is certain it will be
reversed engineered if allwinner takes too long.

Don't forget that, VP8 decoding, h264 encoding, jpeg encoding, was
also successful reversed engineered.
This is only to tell that, it is hardware documentation that we are
interested in, not the software in the form of your cedarx library.




 
 We hope this is helpful to everyone. If not, please let us know how
 we can improve. Thanks!

In the socs datasheets, in the video engine features description, it has
as feature alpha bending. Can we have more information what is mean by
this.

I tried my guess by poking random isp subengine registers but only we
could find is at the wiki page.
http://linux-sunxi.org/VE_Register_guide#ISP_Engine_Registers

If this is what it appears to be, then this would be very useful for
subtitles/osd, because if the bending can occur in the video engine,
then this is optimal in the performance point of view.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [ANNOUNCE] Allwinner releasing CedarX open source

[Manuel Braga]

On Tue, 19 May 2015 08:44:13 +0800 ke...@allwinnertech.com
ke...@allwinnertech.com wrote:
 2. Open source software development is a collaborative process. It
 works because people genuinely want to help others improve and be
 successful. Some people are new and others help them learn the ropes
 over time. We hope that this same positive feedback process can be
 applied to GPL.
 

I am sorry, but i find curious the reference here to the GPL license.

In order of Some people are new and others help them learn the ropes
over time., i will try to explain.


This, have nothing to do with any particular license.
The GPL license is only the most known and used copyleft license, and
by being so, is the license that is more talked about. And by this, it
happened to be the license(LGPL) involved in ours license issues.
It would happened with any other license, the problems are the existence
of the issues by itself.

The key point here, is that the existence of the issues is a
disrespect towards the developers that wrote those same software source
code, and in some cases did without paid and in their free time.

And is not with license issues that allwinner or any other will
attract the contribution of open source developers.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Directions for video engine support (CedarX)

[Manuel Braga]

(The subject has, CedarX is the name of the proprietaries libraries, and
by so is not my business.)


On Thu, 19 Mar 2015 12:39:22 +0200 Simos Xenitellis
simos.li...@googlemail.com wrote:
 
 Would it make sense then to just focus on V4L2?
 I did not find an initial driver for V4L2. I would think the first
 step would be to have a driver that just detects the presence of the
 video engine hardware and report any details that the hardware can
 provide.
 

As said we have for more than 1 year all the information(from reverse
engineering) need to start, meaning that we could have already a V4l2
driver in somewhat functional state by now. If only there was more
support.

I took the task to start this driver, but every week there are only
distractions, that hit hard in the motivation.

And this last weeks are a very good example, to see this huge disregard
of the software licenses used. Makes me wonder how in the future the
license of this v4l2 driver will be handled.

It's very simple, if you all want a proper mainlined driver for this
video engine, then you all should support the people working to make
this a reality.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: What open source community is this?

[Manuel Braga]

On Mon, 16 Mar 2015 10:24:59 +0800 Quink wantl...@gmail.com wrote:
 I'm an employee of allwinner, and I joined this mailing list before
 joined the company. I speak for myself here. I have a Cubieboard2 (I
 bought it to do real-time vibration control as a graduate students.)
 runing Linux and want to playback video on that, and I saw some
 people have the same idea too. I want to find a workable solution,
 that's all.

Thanks for explaining, to have this information given to me in private
created a burden into me, because of not be able to tell others.



 
 So, if we can get all of the source code from allwinner, and work out
 the complete open source solution, that is the best.
 
 If we can't, I want to find out just a workable solution. The graphic
 card AMD radeon 545v didn't work well with open source driver until
 Linux kernel 3.13. Before that, I have to use my laptop too, with AMD
 private driver. It seems that no one takes the cedar binaries as a
 solution, no matter whether it has been cleaned of not.

Speaking for myself, binaries blobs are not my business. Is not the
reason why i joined sunxi, and as so, i have not desire to waste time
with binaries blobs.


 
 If Cedrus is the only workable solution, I will try to figure out how
 to contribute to this project.
 
 On Mon, Mar 16, 2015 at 5:03 AM, Manuel Braga mul.br...@gmail.com
 wrote:
 
  On Sun, 15 Mar 2015 23:51:03 +0800 Quink wantl...@gmail.com wrote:
   Sorry Simos, I just want to invite some students in local
   community to join sunxi
   and take part in GSOC.
 
  And everyone are welcome to join sunxi. And the GSOC idea is not
  bad, please do invite students.
 
   That email has nothing to do with the CedarX.
   It's so sad that there are so many misunderstand. If we have more
 
  I agree, let's resolve this misunderstanding.
  Simos for whatever reason, still didn't make public what he wrote
  to me in our private exchange. And this is making me suspicious.
 
  Maybe you Quink, could help here.
  By telling, who are you?, and your connection to allwinner?, if any.
  What is you want to do?
  And, what kind of help are expected from linux-sunxi?
 
 
   tolerant attitudes, technical discussing should not become a
   flashpoint, and we can be more
 
  Your technical question that was made in your last email is
  unanswered because was part of an email that started with a
  flashpoint. Let's keep the technical discussing, separated from
  flashpoints.
 
   open too.
 
  Yes, let's all be open.
 
  --
  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+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: What open source community is this?

[Manuel Braga]

On Sun, 15 Mar 2015 23:51:03 +0800 Quink wantl...@gmail.com wrote:
 Sorry Simos, I just want to invite some students in local community
 to join sunxi
 and take part in GSOC.

And everyone are welcome to join sunxi. And the GSOC idea is not bad,
please do invite students.

 That email has nothing to do with the CedarX.
 It's so sad that there are so many misunderstand. If we have more

I agree, let's resolve this misunderstanding.
Simos for whatever reason, still didn't make public what he wrote to me
in our private exchange. And this is making me suspicious.

Maybe you Quink, could help here.
By telling, who are you?, and your connection to allwinner?, if any.
What is you want to do?
And, what kind of help are expected from linux-sunxi?


 tolerant attitudes, technical discussing should not become a
 flashpoint, and we can be more

Your technical question that was made in your last email is unanswered
because was part of an email that started with a flashpoint.
Let's keep the technical discussing, separated from flashpoints.

 open too.

Yes, let's all be open.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: What open source community is this?

[Manuel Braga]

On Fri, 13 Mar 2015 19:31:47 +0200 Simos Xenitellis
simos.li...@googlemail.com wrote:
 On Fri, Mar 13, 2015 at 7:11 PM, Manuel Braga mul.br...@gmail.com
 wrote:
  Hi.
 
  What open source community is this?
  When others decide at our back, don't say what are their plans, and
  ask us to help them, and then expect us to accept the result.
 
  Simos, i am repented to have answered to your private emails asking
  for help. I did in good fate, in the hopes that we all could
  collaborate (not fight) to create great software for this hardware.
 
  In that private exchange, i repeated multiple times that technical
  discussing should be made in public, but Simos i see nothing.
 
 
  And is not nice to find this.
  https://groups.google.com/forum/#!topic/szdiy/goBZ5nZOEbU
  (And no, is not a GEM driver, what is need, as i said to you, and
  explained forward)
  If this was the plan, why not present this in mailing list.
 
  Why this behavior, why this secretism, where is the open?
  I don't understand.
  Why don't you write in this mailing list, what you writed to me,
  and go directly to the point.
 
 
  Simos, one last thing.
  With binaries blobs, you will no get the proper driver that you
  wish.
 
 
 Fuck my life.[non-native speakers: it's an expression like what
 have I done to deserve this].

Also me, what we all have done to deserve all this problems caused by
this video engine.



 Manuel, you are quoting an email that I sent to Quink BEFORE I
 consulted you. In that email it says I asked Manuel Braga for some
 input and will come back to you.
 That email shows my BEFORE knowledge.
 
 In that email I suggested to Quink to try for GSOC because his G+
 profile mentions
 that he is either a Uni student or a recent graduate (so his
 colleagues might find it interesting).

Odd, in our private exchange, i got the impression that you told me
that he(Quink) was someone else. Maybe you and Quink should explain
better, who is who and what do are expecting from the rest of us.
As i asked you to do, in our private exchange.


(By the way, i don't know how GSOC handles binary globs)


 He should not have forwarded my email (it's etiquette not to forward
 private mails) but anyway, I do not hold grudges.
 @Quink: We are still good.
 
 What I see here is that you have been influenced by the negative vibes
 and interpreted that mail in the most negative/wrong way.

Is not that email.
What is negative here is the secretism floating around. And this is not
healthy for an supposed open source community.

 
 Simos

And i repeat again.
Why don't you write in this mailing list, what you wrote to me, and go
directly to the point. The others also have the right to know, and i
don't see what is wrong with its content, that should not be public.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Allwinner GPL violations: definitive proof.

[Manuel Braga]

Hi,

On Thu, 5 Mar 2015 20:41:36 +0100 Michal Suchanek hramr...@gmail.com
wrote:
 Hello,
 
 On 5 March 2015 at 18:35, Henrik Nordström
 hen...@henriknordstrom.net wrote:
  ons 2015-03-04 klockan 17:41 + skrev Manuel Braga:
 
  What we get? Just indifference that the reverse engineering effort
  even exists.
 
  Sorry you get this impression.

Who is not guilt, don't raise the hand.

Just that this video engine has been so problematic not only for me
and the others involved, but also for all sunxi community.



 
  I know I have been silent, but that's mostly because video is not
  something I am interested in, and especially not Allwinners binary
  take on it. But it does not mean that I am indifferent to your
  effort, not at all, to me the documentation of the CedarX hardware
  and proof of concept software was and is very important, even if
  far from feature complete.
 
 
 It WorksForMe(tm). I can play video with mplayer which is how I use
 video most of the time even on systems with multiple choices of a
 media player. And with opensource drivers which I can expect to
 continue working as long as sunxi hardware has any use. Thanks for
 that.
 
 Yes, it is a gross hack. But for more progress the other parts to
 which the VE engine is to be hooked have to be ready - like the KMS
 driver. Technically one can be writing a VE driver without a KMS
 driver which is then just plugged in ... and you can see all the bugs
 then.

The video engine is the least priority item in the wish list, but is
dependent of all the others. I understand that, and also don't see a
point of wasting time in a 100% open source driver and software for it,
if the only way to use it requires hardware that is limited by binaries
blobs (for example; dram initialization). This is not me going for a
full 100% or nothing, just a question of priorities.

Did you every see me asking for KMS(or whatever name) driver? You don't
because i never asked. Why? Because i don't need to ask. 





 ...
 
 So, please, try to limit the corrosive and bitter posts.


And again the discussing went the same path.

I like that there are harsh agents, it make the ones that see this
community as a source of gratis labor think two times. It makes me
fell that i am not been abused, and different personalties make the
world colorful. But just a personal opinion.


Wouldn't be better to talk instead of fighting.

Because the way that you (all) are responding to the harshness
looks like fighting to me, and again the fighting is obscuring the
problem that is the reason of the harshness in the first place.

Why not say, Luc, last commit demonstrated that allwinner is clueless
in how to fix this license issues, please stop the stick waving.

And this mistakes that allwinner is doing by trying to fix this license
issues, is more of a concern (in $business$ matters) than being public
shamed about license noncompliance.


Anyway today there are good news in the allwinner git repository.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Derailed thread

[Manuel Braga]

Hi,

On Thu, 5 Mar 2015 02:13:48 +0200 Simos Xenitellis
simos.li...@googlemail.com wrote:
 In your case, you have things to lose from this community. You have
 invested in this project. You have invested so much that you would be
 even a suitable recruit
 for Allwinner. Even having access to internal documents and source
 in order to produce a proper libvdpau.

Maybe i am wrong, but this form of speaking makes me beleave that you
are associating Luc to the video engine work. And this is incorrect, he
has nothing to do with it.

If you or someone else is not happy with the work done, then it is *me*
the one to go complain.

Also the proper thing needed is a proper mainlined kernel driver for
this video engine, but appears that i am almost exclusive the only one
speaking this need.
See, this is the page http://linux-sunxi.org/VE_Planning, but in this
conditions (well i thought that linux-sunxi was a community), there is
no desire to spend the time nor motivation to continue. And to make
clear is not because fault of documentation, we have already all that
is need more that 1 and half year.

But what i see is only talking about binaries, and that is not my
business.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Allwinner GPL violations: definitive proof.

[Manuel Braga]

Hi,

On Wed, 4 Mar 2015 09:46:07 -0300 Rodrigo Pereira
rodrigo2kpere...@gmail.com wrote:
 
 This is because reverse engeneering is a PITA, I suppose.
 
 http://linux-sunxi.org/CedarX/Reverse_Engineering
 

I disagree.
Reverse engineering is an enjoyable and fun thing to do.
And as can be see in the above url, it only took a space of a few weeks
to get successful results, with the majority of the work done by only
one person.

What is PITA, is to be ignored.

After all this work done, we(the people that work by reverse
engineering this video engine, so that would be possible to write a
proper driver that can be mainlined).

What we get? Just indifference that the reverse engineering effort even
exists.
Look at this maillist, people here begging allwinner for a binary with
a correct license (because without a license without issues, nobody
that wants to stay lawful can even use the binary).
And for what?, this binary will not magical resolve all the things, this
binary is a stopper for a proper driver, this binary can't be part of
mainline kernel.
Don't forget what happened around two years ago, when the developers of
an unnamed favorite media player tried to add hardware acceleration.

What we get? Endless users asking why it doesn't work, but incapable in
recognizing the work that must be done before.
In the end, the users expect all from us, but is not enough.


You know, if we(the reverse engineering people) had a bit more support,
we would be motivated to work a bit harder, so that maybe today we all
would be much happier.
And this page would have progressed much more.
http://linux-sunxi.org/VE_Planning


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Allwinner GPL violations: definitive proof.

[Manuel Braga]

Hi,

On Wed, 25 Feb 2015 14:06:59 +0800 ke...@allwinnertech.com
ke...@allwinnertech.com wrote:
 Hi, Luc,
 
 Allwinner is trying to fix the GPL issue taken on Cedarx.

That is the right thing, and thank you for this statement.


 We have release the latest version of cedarx with LGPL. And just
 close the code of Video Engine hardware, the framework and API is

Why is close?
Please open the code of Video Engine hardware.

If allwinner still isn't aware. The Video Engine hardware was successful
reversed engineering more that 1 year already. With the result been the
fantastic 100% open source libvdpau-sunxi implementation.
http://linux-sunxi.org/VE_Register_guide
There isn't anything to hide.

Allwinner only has to win by publising more open information about
the video engine hardware.
By the means of open source code, or any form of hardware documentation.

I, as one of the Video Engine hardware reverse engineering developers
that wishes to have a proper 100% open source mainlined kernel driver.
Ask cooperation from allwinner.

Thanks.
Manuel Braga


 opensource. We will review the code again, to fix the GPL issues
 still existed. We are trying to do better, if you found any GPL
 issue, please let us know, we will fix it and update it ASAP.
 
 About the kernel GPL issue, we are fixing it now, we will update the
 code to open some drivers. Thanks.
 
 Best Regards.
 
 ke...@allwinnertech.com
 
 From: Luc Verhaegenmailto:l...@skynet.be
 Date: 2015-02-25 11:55
 To: linux-sunxi@googlegroups.commailto:linux-sunxi@googlegroups.com
 CC: Meng Zhangmailto:ke...@allwinnertech.com;
 sh...@allwinnertech.commailto:sh...@allwinnertech.com Subject:
 Allwinner GPL violations: definitive proof. This was just posted on
 the allwinner github account:
 
 https://github.com/allwinner-zh/media-codec
 
 This contains:
 
 https://github.com/allwinner-zh/media-codec/blob/master/sunxi-cedarx/LIBRARY/CODEC/VIDEO/DECODER/libvdecoder.so
 
 This binary contains symbols from both ffmpeg (LGPL, but
 altered/hacked up) and libVP62 (anti-compiled from java, and taken
 off the web in 2006). The LGPL forces Allwinner to produce the full
 and complete source code of these binaries. How they are going to
 explain libVP62 to On2 Technologies, now google, is beyond me (cfr.
 http://en.wikipedia.org/wiki/VP6)
 
 With all the previous indiscretions, it was always possible to claim
 that there was some chance that Allwinner was not the source of the
 many violations. It was always pretty clear that Allwinner was the
 source, there were just too many coincidences, the violation was too
 all encompassing, and not a single device maker spilled the goods.
 The fact that they threw out a kernel tree with most code and all
 binaries removed, was, despite being a ludicrous and laughable
 action, another very clear sign that Allwinner was indeed the source
 of these violations.
 
 Now however, the fact that allwinner posted this very clearly shows
 that Allwinner is the source. It is absolutely unequivocal this time
 round.
 
 To top this off, it is 6 months after the last GPL violation
 shitstorm. This puts serious doubts behind the claims that Allwinner
 truly is learning and willing to cooperate.
 
 Allwinner, it is very high time to start playing nice. You've been at
 it for 4 years now and seem utterly incapable of or unwilling to
 change.
 
 Luc Verhaegen.
 NOTICE: This e-mail and any included attachments are intended only
 for the sole use of named and intended recipient (s) only. If you are
 the named and intended recipient, please note that the information
 contained in this email and its embedded files are confidential and
 privileged. If you are neither the intended nor named recipient, you
 are hereby notified that any unauthorized review, use, disclosure,
 dissemination, distribution, or copying of this communication, or any
 of its contents, is strictly prohibited. Please reply to the sender
 and destroy the original message and all your records of this message
 (whether electronic or otherwise). Furthermore, you should not
 disclose to any other person, use, copy or disseminate the contents
 of this e-mail and/or the documents accompanying it.
 



-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Video engine talking (was: Communication with Allwinner)

[Manuel Braga]

Hi,

On Fri, 20 Feb 2015 03:03:08 -0800 (PST) mike.v...@gmail.com wrote:
 On Tuesday, February 17, 2015 at 6:56:13 PM UTC+1, Manuel Braga wrote:
  On Tue, 17 Feb 2015 12:00:27 +0200 Simos Xenitellis
   
   At http://www.phoronix.com/scan.php?page=news_itempx=MTg4Mjg it
   mentions that Intel is doing Linux work on the PowerVR VXD392 VPU
   (as is used on Baytrail).
   Is the VPU similar to what exists on the A80?
  
  What is a VPU?, wikipedia says that a VPU is another term for GPU.
  And at the end this is huge confusion, that make people believe
  that for have hardware accelerated video playback is a requirement
  to have and use the GPU.
 
 CPU : Central Processing Unit
 GPU : Graphics Processing Unit
 VPU : Video Processing unit
 
 GPU, VPU are specialized processing unit/cores for specific workloads
 to unload the CPU or gain performance which is out of reach for a
 general purpose PU 
 
 GPGPU: General purpose GPU. - OpeCL etc. 
 
 Not that confusing IMHO, A little archaic perhaps. 

Tell that to wikipedia, for them the V is not for video, but visual.
http://en.wikipedia.org/w/index.php?title=Video_processing_unitredirect=no

 
  
  This is wrong, it come from the fact that in the PC(x86) world are
  used graphic cards that are actually are (gpu + display engine +
  video codec engine), so this is 3 kind of difference hardware types
  put together in this some called graphic card.
  As this graphic card is one identity, it is usually all handled by
  the same software driver.
 
 In x86 land we started with CGA, EGA and VGA cards. Which were a
 little more than Diplay Controllers. And were called video cards
 which was used pre x68. Because the C64 etc used a composite video
 signal to interface with tv's/display's
 
 Than came the graphics accelerators, which would offload graphics
 processing from the CPU and send results back to CPU or directly to
 the display controller. 
 
 http://commons.wikimedia.org/wiki/File:VideoLogic_Apocalypse_3Dx.jpg#mediaviewer/File:VideoLogic_Apocalypse_3Dx.jpg
 An ancient PowerVR GPU for x86 without the display controller.
 
 
 Because the chain CPU-GPU/Display Controller-Display. The display
 controller became embedded to the GPU cards.
 
 Apart from that the came MPEG cards wich would decode MPEG video and
 'stream' the result back to the system.
 
 Because video decoding, VPU, should at the same place as the GPU the
 chain is broken. CPU - VPU - CPU - GPU - Display
 
 Thus most GPU cards now have a video decoder onboard as well.
 CPU - VPU/GPU/Display Controller - Display
 
  
  In ARM case this is not the case,
  http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
 
 The driver issue is more a Mix and Match issue. In x86 the
 GPU/VPU/Display Controller are usually on one device. The set is
 alway the same and using a single driver makes sense. 
 
 In ARM land the CPU,GPU,VPU,Display Controller are mixed and matched
 on a single device. Thus a single driver does not make sense. Hence
 the need for seperate drives and some glue (DeviceTree). Also the
 parts are no longer aligned but are placed side by side on the same
 memory(bus).
 
 Luc has mostly figured out the Mali GPU and is now working on the
 display controller.

Thanks for helping make things more clear.


 
 For A312 and A80 they chose Imagination's PowerVR as the GPU, I don't
 know if they chose the use Imagination parts for the Display
 Controller and VPU

For the VPU, there isn't a reason why it is not the same as from all
other socs. Moreover in the datasheets the features match in equal mode.
Also same simple kernel driver. 

But as i don't own A31*/A80 devices, i can't take the 30 minutes that
would take to make this clear without any doubt.


 
  
  Please lets use a more correct term, that creates no ambiguity of
  what we are speaking about.
  
  Video Codec Engine, is the correct name for this type hardware in
  the sunxi(allwinner) case. This is the hardware to use for decoding
  and encoding of video codecs.
 
 codec comes from coding and decoding. The VPU does more:
 ColorCode conversion
 Scaling
 etc.
 
 So calling it a mere codec is not more accurate.
 
 Media Processing Unit I think is better. It whould also cover the
 audio codec and remove the confusion with video cards

http://linux-sunxi.org/Category:Video_Engine

Let's call it Media Accelerate Video Engine


 
 But the Market/Marketing is stuck on the video term. 

Allwinner is simply calling video engine.


 
  
  And in sunxi, sometimes called also cedar engine and it is the
  *same* Video Codec Engine in all allwinner socs.
  A10/A10s/A13/A20/A23/A31/A31s/A33/A80/A80T/A83T/H3/H8
  (with some minor and or new feature hardware versions)
  
  How do i know?
  From the kernel source code make available from allwinner.
  
  To the best of what could be found, this Video Codec Engine is a
  custom design made by www.chipsbank.com for allwinner. And this
  makes

Re: [linux-sunxi] Re: Communication with Allwinner

[Manuel Braga]

Hi,

On Tue, 17 Feb 2015 12:00:27 +0200 Simos Xenitellis
simos.li...@googlemail.com wrote:
 Hi David,
 
 Thanks for doing this and taking things forward!
 
 On Mon, Feb 16, 2015 at 9:54 PM, David Lanzendörfer
 david.lanzendoer...@o2s.ch wrote:
  Hi
  Javqui is not referring to the GPU but the VPU (Video). CedarX.
  MPEG-1/2, H.264, DivX, etc.
 
  Besides the opened part from PowerVR is sadly one of their
  publication stunts. http://libv.livejournal.com/. And when the PR
  department gets confronted with their own BS, they give you the
  silence treatment
 
  The only one thing I can say is PowerVR is poison. They don't even
  bow to Intel, Search for Poulsbo.
  I know it very well since I already have run Linux on Intel Atom
  CloverTrail platform and on BayTrail.
 
 
 At http://www.phoronix.com/scan.php?page=news_itempx=MTg4Mjg it
 mentions that Intel is doing Linux work on the PowerVR VXD392 VPU (as
 is used on Baytrail).
 Is the VPU similar to what exists on the A80?

What is a VPU?, wikipedia says that a VPU is another term for GPU.
And at the end this is huge confusion, that make people believe that for
have hardware accelerated video playback is a requirement to have and
use the GPU.

This is wrong, it come from the fact that in the PC(x86) world are used
graphic cards that are actually are (gpu + display engine + video codec
engine), so this is 3 kind of difference hardware types put together in
this some called graphic card.
As this graphic card is one identity, it is usually all handled by the
same software driver.

In ARM case this is not the case,
http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/

Please lets use a more correct term, that creates no ambiguity of what
we are speaking about.

Video Codec Engine, is the correct name for this type hardware in the
sunxi(allwinner) case. This is the hardware to use for decoding and
encoding of video codecs.

And in sunxi, sometimes called also cedar engine and it is the *same*
Video Codec Engine in all allwinner socs.
A10/A10s/A13/A20/A23/A31/A31s/A33/A80/A80T/A83T/H3/H8
(with some minor and or new feature hardware versions)

How do i know?
From the kernel source code make available from allwinner.

To the best of what could be found, this Video Codec Engine is a custom
design made by www.chipsbank.com for allwinner. And this makes believe
that is allwinner propriety and only used in allwinner socs.

 
 Regarding the older SoCs in the A series, it is important to have a
 view whether there will be effort to support the VPU on Linux.

Did you already hear of libvdpau-sunxi? do you know what it is?
It is 100% open source, vdpau driver for this video codec engine by the
means of reverse engineering.
http://linux-sunxi.org/Cedrus
http://linux-sunxi.org/CedarX/Reverse_Engineering

Of course the work is not ended, this is only a workaround and the
plans to move and to make a proper driver that has the chances to be
mainlined is here:
http://linux-sunxi.org/VE_Planning


 I have the impression that it would greatly benefit boards like the
 Banana Pi, the OLinuXinos, the Cubieboards, etc.

I agree, but where is the support?
The support to the people that are working to make possible to have a
proper mainlined driver for this video codec engine.

 
  So open GPU Drivers for A80, is not going to happen. It didn't
  happen for Intel Atom, it didn't happen when the FSF made it a
  priority project. Besides the A80 will not exist long enough.
  The A64 might have the same GPU as well... So it's not about making
  an A80 specific driver but a generic control for Rogue.
  Besides. Poulsbo at least initializes with linux-next.
 
  If Allwinner is interested in FOSS gpu drivers, which they should
  be, they'd better support the Lima, Etnaviv, etc. projects.
  It doesn't support 4K high resolution video...
  It doesn't crash on regular basis either though.
  But the regular Mali just doesn't provide enough performance for
  these high end purpose this A64/A80 is intended for...
  I think at some point of time Allwinner will accomplish what FSF
  ist just talking about, just because Allwinner wants to have more
  spare time by streaming up as many drivers as possible -_-
 
 
 It makes business sense to be open and I think it is healthy to align
 with the FSF
 goals because it's also good for business.
 The field of SoC manufacturers gets somewhat saturated,
 and those that will get open first, will probably capture the market.
 
 Simos
 

-- 
thanks for reading.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Moving forward

[Manuel Braga]

On Fri, 29 Aug 2014 14:59:48 +0300 Simos Xenitellis
simos.li...@googlemail.com wrote:

 
 It has been said already that there are two main options:
 
 1. Start working at once with the AW engineers to send upstream any
 code that is missing (Linux kernel drivers, make upstream u-boot work
 with all AW SoCs, etc). As a resource, those two Linux kernel
 engineers from AW are available to help now. The access to the AW
 kernel engineers is the most important resource.
 Then, the GPL issues would be gradually resolved.
 
 2. Get AW to spend resources to go through and vet tarballs of source
 code. I suppose it would take a lot of resources from AW, the result
 would be old versions of the source code and we would not have
 started yet to talk to the engineers.
 This option is a painful option, and should only be the last option.
 
 In both options, the end result would probably be the same, however
 Option 1 will get results faster and is the most beneficial for the
 future of the community.
 
 As a community, it makes sense to try Option 1 and see where it gets
 us in, let's say, three months. If we do not get any results, then
 many more may choose to go for Option 2.
 
 It worries me however that for Option 1, Luc will make this list a
 living hell. He will sabotage any effort in order not to be proved
 wrong. In this sense, it would be silly for an AW engineer to join
 the list and attempt to discuss here. I can already predict endless
 questions about licensing towards the engineers (these are not for
 the engineers to discuss).

Why Luc, and not me, or any other else?
Because was only him, that took the trouble to document in the wiki the
license compliance issues that were already know more than 1 year ago.
And to have pointed that this license compliance issues is a stopper
 * to the progression of the mainline work
 * to have serious companies(that care about respecting licenses) take
   allwinner socs serious

Look at this
http://www.cnx-software.com/2014/08/26/allwinner-a80-linux-sdk-released/
read the comments, who will take allwinner serious?

We, this community, can help allwinner find solutions to resolve this
mess, only allwinner needs to have the will to actually listening to
us.


 
 We have the opportunity to draw a line and move forward.
 Which one is the smartest option?

None is the smartest option. Both options are complementary to each
other. That means that there is no need to choose.

Nobody is stopping allwinner engineers to participate in this maillist,
or in any other way that is suited to work for mainline kernel.
If they wish. They know what to do, if not we are here to help them.


 Simos
 



-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: GPL Violations round-up.

[Manuel Braga]

On Fri, 29 Aug 2014 17:26:58 +0100 Simon Kenyon
simoncken...@gmail.com wrote:
 the question going through my head is:
 are the blobs in question derived from (L)GPL code?
 if not, then there is no violation
 

Did you try to look at our wiki?
There was one person that spend considerable amount of time to document
all the issues. http://linux-sunxi.org/GPL_Violations

Off course i am not a lawyer, but with my limited understanding  i can
see two types of issues.
 1. in kernel tree binary only form blobs that link with the kernel
 2. the proprietary video engine libraries are made with some parts
that correspond to lgpl source code.

This is only what i can see by observation, because i am not
involved in finding this dirty details.

But if there is still doubt that there are issues, i am sure that
someone will help to make those issues more clear.

To add.
Nobody is saying give us the source or else.

I am sure that this can be resolved pacifically, with the both sides
get rewarded at the end.
But for that, it is need to exist dialog, and to recognize the issues as
issues.



-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Moving forward

[Manuel Braga]

This email got somehow lost.

On Fri, 29 Aug 2014 14:30:57 +0100 Manuel Braga mul.br...@gmail.com
wrote:
 On Fri, 29 Aug 2014 14:59:48 +0300 Simos Xenitellis
 simos.li...@googlemail.com wrote:
   
  
  We have the opportunity to draw a line and move forward.
  Which one is the smartest option?  
 
 None is the smartest option. Both options are complementary to each
 other. That means that there is no need to choose.  

To expand.

Allwinner only has to make available sourcecode dumps or
documentation or whatever, or even have allwinner engineers working in
the secret parts that can't be public, and come on with any solution.

We, or Allwinner, or both(this community and allwinner) work together
in mainlining.

Allwinner then can port back to its SDK, and at same time by doing so
those license compliance issues get resolved.

 
 Nobody is stopping allwinner engineers to participate in this
 maillist, or in any other way that is suited to work for mainline
 kernel. If they wish. They know what to do, if not we are here to
 help them.
   

-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Jpeg decoded using Cedarx

[Manuel Braga]

On Mon, 28 Jul 2014 16:19:50 +0800 (CST) li lijiamin...@163.com wrote:
 hi all,
 
 
 I use the code in github(https://github.com/jemk/cedrus) to decode
 jpeg in A20, but found that the code has bug when decode many jpeg

Of course it has bugs, those are experimental source code not intended
to be used in any way, other than to be used for reverse engineering.

If your intension is not that, then you are only wasting your time when
trying to use this.


 files one by one. if any of you have similar experience, please give
 me a guide. thank you very much.

Sorry, i can't guide you.

 
 
 By the way, I can't find out the email of jemk, if anyone kowns it,
 please tell me. I am really appreciated.

...
 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Allwinner SDK 2.0 and h.264 support

[Manuel Braga]

On Fri, 18 Apr 2014 14:44:44 -0400 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 When is that from? STB SDK 2.0 has been out about 30 days now.
 
 It is using kernel 3.4.39

That file has a server date of 17 Jan 1014.
But this SDKs are only useful if there have anything new, from what we
current have.



This is situation ridicule, Allwinner should make this available to us.
And not we have to randomly wait for one customer to arrive.



 
 
 On Fri, Apr 18, 2014 at 6:13 AM, Manuel Braga mul.br...@gmail.com
 wrote:
 
  On Thu, 17 Apr 2014 16:06:02 -0400 jonsm...@gmail.com
  jonsm...@gmail.com wrote:
   I just got a hold of the Allwinner STB SDK 2.0 for A20. There are
   major improvements to their h2.64 encoder blob in it.  Old blob
   was almost unusable. This one seems to working much better.
 
 
  
   Now that they have fixed h.264 encoding Skype is using the
   hardware encoder instead of reverting to software VP8 encode. You
   can get 720P/1080P instead of only VGA on Skype.
  
   Not sure about licenses and how to get this into a form sunxi can
   use.
  
 
  Is newer than this?
  http://dl.cubieboard.org/software/a20-cubieboard/android/android-SDK.zip
 
  --
 
  --
  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+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 
 
 



-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Allwinner SDK 2.0 and h.264 support

[Manuel Braga]

On Thu, 17 Apr 2014 16:06:02 -0400 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 I just got a hold of the Allwinner STB SDK 2.0 for A20. There are
 major improvements to their h2.64 encoder blob in it.  Old blob was
 almost unusable. This one seems to working much better.


 
 Now that they have fixed h.264 encoding Skype is using the hardware
 encoder instead of reverting to software VP8 encode. You can get
 720P/1080P instead of only VGA on Skype.

 Not sure about licenses and how to get this into a form sunxi can use.
 

Is newer than this?
http://dl.cubieboard.org/software/a20-cubieboard/android/android-SDK.zip

-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] YUYV vs NV12 with camera

[Manuel Braga]

On Tue, 25 Feb 2014 11:45:07 -0500 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 This is a more recent h264 build from Allwinner.
 
 Can someone check it into git?

I can't do everything, as time is always a problem, there is
priorities. And this is not one right now, we already found the general
working of the hardware encoder part. 

But any new binaries are always interesting, but i only do work as
need, and when the time arrive is very probable that will exist again
a new binaries dump. So this is the situation.

If is here someone listen and can't wait for the RE results, then
please go ahead, put this in shape to be useful in any way.
It will also be good for us(RE).


-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] YUYV vs NV12 with camera

[Manuel Braga]

On Mon, 24 Feb 2014 19:38:46 -0500 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 On Mon, Feb 24, 2014 at 6:21 PM, Manuel Braga mul.br...@gmail.com
 wrote:
  On Mon, 24 Feb 2014 16:17:31 -0500 jonsm...@gmail.com
  jonsm...@gmail.com wrote:
  Compare it to these public Dropcams. They are using a slightly
  better image sensor - OV5630. 500Kb/s 720P h.264 high encoding.
  https://www.dropcam.com/cameras/featured
 
  CPU - http://www.ambarella.com/
 
  I'd love to get that good of quality recording.
 
  You know who to go complain = Allwinner
 
 What I can't tell is if the hardware is good and the software is just
 messed up, or if the hardware is fundamentally broken.
 
 So maybe I can do an experiment. First I can save some uncompressed
 stills to assess the camera.
 
 Second, there is uncompressed test 720P video here.
 https://media.xiph.org/video/derf/
 
 I can feed it through the compression hardware and compare to x86
 software encoders. This works since there is no requirement to
 compress in real-time. There is no way to save real-time uncompressed
 video on the A20. It is just too fast. Would you happen to already
 have an app written that can compress the raw video?

https://github.com/patrickhwood/h264encoder
This is it, remenber NV12 format, both width and height must be a
32 multiple.


 
 This will provide some good data for Allwinner if it show problems in
 the h264 encoder.
 


-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] YUYV vs NV12 with camera

[Manuel Braga]

On Tue, 25 Feb 2014 11:42:06 -0500 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 On Tue, Feb 25, 2014 at 9:40 AM, Manuel Braga mul.br...@gmail.com
 wrote:
  On Mon, 24 Feb 2014 19:38:46 -0500 jonsm...@gmail.com
  jonsm...@gmail.com wrote:
  On Mon, Feb 24, 2014 at 6:21 PM, Manuel Braga mul.br...@gmail.com
  wrote:
   On Mon, 24 Feb 2014 16:17:31 -0500 jonsm...@gmail.com
   jonsm...@gmail.com wrote:
   Compare it to these public Dropcams. They are using a slightly
   better image sensor - OV5630. 500Kb/s 720P h.264 high encoding.
   https://www.dropcam.com/cameras/featured
  
   CPU - http://www.ambarella.com/
  
   I'd love to get that good of quality recording.
  
   You know who to go complain = Allwinner
 
  What I can't tell is if the hardware is good and the software is
  just messed up, or if the hardware is fundamentally broken.
 
  So maybe I can do an experiment. First I can save some uncompressed
  stills to assess the camera.
 
  Second, there is uncompressed test 720P video here.
  https://media.xiph.org/video/derf/
 
  I can feed it through the compression hardware and compare to x86
  software encoders. This works since there is no requirement to
  compress in real-time. There is no way to save real-time
  uncompressed video on the A20. It is just too fast. Would you
  happen to already have an app written that can compress the raw
  video?
 
  https://github.com/patrickhwood/h264encoder
  This is it, remenber NV12 format, both width and height must be a
  32 multiple.
 
 720 is 16 multiple. Is that easy to change?

Is explained in the README.
You can use avconv(from libav ) or ffmpeg, to convert any video file
into the right format.

But looking at it, is only padding width, needs (not tested)
-vf pad=trunc((iw+31)/32)*32:trunc((ih+31)/32)*32

Example:
a video 1200x720, round up the sizes to a multiple of 32
becoming 1216x736, convert this way

avconv -i originalvideo -vf pad=1216:736 -pix_fmt nv12 -f rawvideo \
rightformatrawvideo_1216x736.nv12

naming the rightformatrawvideo this way with the sizes and nv12
extension is required, this is were the encoder gets the size to
configure the hardware.

simpleencoder.static rightformatrawvideo_1216x736.nv12 -o video.mkv



 
 NV12 is same as YUV 4:2:0, right?
 There are uncompressed YUV 4:2:0 720P samples here.
 https://media.xiph.org/video/derf/
 
No. It is similar, but the difference is in how the pixel data is
packed.






-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] YUYV vs NV12 with camera

[Manuel Braga]

On Mon, 24 Feb 2014 13:17:36 -0500 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 NV12 gives the correct color space (I was in NV21 earlier). This
 camera must be wired in the opposite of the other ones I have. It is
 also flipped left to right and I haven't figured out where to fix
 that.
 
 Compressed image quality is very poor. This is 3Mb/s.
 enc_fmt.profileIdc = 100; /* high profile */

This number goes direct to the output bitstream whatever is it value.
Allwinner advertises that the hardware supports high profile, but is
this really true? Or is there somekind of limit in the binary blob?

I don't know enough of h264 codec internal details to check if or not
the result really has high profile features. This should be checked.

Another suspicious thing, in the recent openmax source code dumped,
is hardcoded to use baseline profile only.


By the way, you know that, few week ago, cubietech dumped a new android
SDK that has openmax for cedar hardware. There is openmax source for
decode and encode. Don't know if works or not.


 enc_fmt.levelIdc = 31;
 enc_fmt.qp_max = 40;
 enc_fmt.qp_min = 20;
 
 https://drive.google.com/file/d/0B-2Z6FDzyIwrMFpsN3lvRnpRQVU/edit?usp=sharing

Magic School Bus, one of the rare few North American cartoons that i
liked to watch.

-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] YUYV vs NV12 with camera

[Manuel Braga]

On Mon, 24 Feb 2014 16:17:31 -0500 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 Compare it to these public Dropcams. They are using a slightly better
 image sensor - OV5630. 500Kb/s 720P h.264 high encoding.
 https://www.dropcam.com/cameras/featured
 
 CPU - http://www.ambarella.com/
 
 I'd love to get that good of quality recording.

You know who to go complain = Allwinner


-- 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Beta H264 encoder for Linux armhf

[Manuel Braga]

On Sat, 11 Jan 2014 23:19:43 -0500 jonsm...@gmail.com
jonsm...@gmail.com wrote:
 I have a beta H264 encoder sample app form Allwinner compiled for
 armhf. I've been playing around with it and it doesn't work right.
 But the problems don't seem to be with the h.264 encoder working it
 is with things like threads and buffer management.

 Let me know if you are interested in working with this. Once
 everything works I can put it up on github. I have source for the
 sample app but not for the encoder library.
Not having the encoder library, remembers me of this one
https://github.com/linux-sunxi/cedarx-libs/tree/master/enc_dec_demo
If is the same, them is a dead end.
Don't forget that armel libraries compiled in a static binaries runs in
armhf roofs.


Anyway, for the curious people that reads the irc logs, there was some
news yesterday.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.