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

[jonsm...@gmail.com]

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

I want ISPs with denoising capability. Back to back frames can have a
lot of least significant bit jitter in them. The denoising detects
this and suppresses a lot of it. If you don't do this all of that
noise gets h.264 encoded and it can add 30-40% to the stream bandwidth
with useless noise.


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



-- 
Jon Smirl
jonsm...@gmail.com

-- 
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"
 wrote:
> On Sun, Mar 13, 2016 at 5:16 PM, Manuel Braga 
> wrote:
> > On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva
> >  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

[jonsm...@gmail.com]

On Sun, Mar 13, 2016 at 5:16 PM, Manuel Braga  wrote:
> On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva
>  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.

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


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

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

[Manuel Braga]

On Sun, 13 Mar 2016 12:16:11 -0700 (PDT) "@lex" 
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 
> >  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  > > > 
> > 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 
> > > >>  wrote: 
> > > >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex 
> > > >> > wrote: 
> > > >> >> You are right, i changed the input format to NV12 on
> > > >> >> GuvcView and got 
> > > >> lower 
> > > >> >> CPU usage (250%) and Temp ~75C. 
> > > >> >> I does not help much overall. 
> > > >> > 
> > > >> > You need an ffmpeg that has been taught how to use the
> > > >> > hardware decode features on your SOC. 
> > > >> > 
> > > >> > Don't know if one exists for H3. 
> > > >> 
> > > >> Maybe this will work?... 
> > > >> 
> > > >> https://github.com/stulluk/FFmpeg-Cedrus 
> > > >> 
> >
> > -- 
> > Manuel Braga 
> >
> 

-- 
Manuel Braga

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

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

[Manuel Braga]

On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva
 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 
> 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
> >  wrote:
> > > I will try in a few weeks.
> > >
> > > I am going on a business trip for 2 wks, 

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

[@lex]

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?

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 
>  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  
> 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 
> > >>  wrote: 
> > >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex  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] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

Manuel,
IMHO, people just want a solution that works!

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

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

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

Anyway, I just published what I have done.

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

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

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

R

On Sun, Mar 13, 2016 at 12:30 PM, 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
>  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  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
> > >>  wrote:
> > >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex  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] 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
 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  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
> >>  wrote:
> >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex  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] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

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  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 
>> wrote:
>> > On Sat, Mar 12, 2016 at 7:37 PM, @lex  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
>>
>> >
>> >
>> >>
>> >>
>> >> On Saturday, March 12, 2016 at 8:47:38 PM UTC-3, Rosimildo DaSilva
>> wrote:
>> >>>
>> >>> I have this camera, and if you change the "start_video.sh" script to
>> >>> something like this
>> >>> you can see... the results... the CPU usage is much lower...
>> >>>
>> >>> echo "Starting H264 Encoder..."
>> >>> $FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720
>> -i
>> >>> $SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \
>> >>>$ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720
>> -o
>> >>> /tmp/out1.h264
>> >>> ;;
>> >>>
>> >>> R
>> >>>
>> >>> On Saturday, March 12, 2016 at 4:55:57 PM UTC-6, @lex wrote:
>> 
>>  Inspired by so many good arguments on USB uvc cameras i decided to
>> test
>>  one, a 720P HD used in ODROID, so you can take a look and see how
>> good it is
>>  for Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode
>> by HW
>>  worth the effort or we throw in the towel, it is up to you.
>> 
>>  This is simple test, done with Orange Pi PC, with a tuned 3.4.39
>> kernel
>>  and with ssvb fex (TKaiser advice) to solve the so known temperature
>> issues
>>  this board faces when running at high speed.
>> 
>>  The uvc camera is ODROID 720 HD:
>>  [  196.199875] ehci_irq: highspeed device connect
>>  [  196.460139] usb 4-1: new high-speed USB device number 2 using
>>  sunxi-ehci
>>  [  196.890710] 2:3:1: cannot get freq at ep 0x84
>>  [  196.892434] usbcore: registered new interface driver
>> snd-usb-audio
>>  [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera
>> (1b71:0056)
>>  [  196.938300] is_otg_flag: 0x0,
>>  [  196.938479] usbcore: registered new interface driver uvcvideo
>>  [  196.938489] USB Video Class driver (v1.1.1)
>>  [  196.976118] 2:3:1: cannot get freq at ep 0x84
>> 
>> 
>>  As Jon said, you don't need to do anything, just plug it in and
>> start
>>  using the UVC camera compliant. No need to worry about drivers,
>> etc..
>>  This camera has MPJEG mode and YUV mode:
>>  ioctl: VIDIOC_ENUM_FMT
>>  Index   : 0
>>  Type: Video Capture
>>  Pixel Format: 'MJPG' (compressed)
>>  Name: MJPEG
>>  Size: Discrete 1280x720
>>  Interval: Discrete 0.033s (30.000 fps)
>>  Interval: Discrete 0.040s (25.000 fps)
>>  Interval: Discrete 0.050s (20.000 fps)
>>  Interval: Discrete 0.067s (15.000 fps)
>>  Interval: Discrete 0.100s (10.000 fps)
>>  Interval: Discrete 0.200s (5.000 fps)
>>  Size: Discrete 640x480
>>  Interval: Discrete 0.033s (30.000 fps)
>>  Interval: Discrete 0.040s (25.000 fps)
>>  Interval: Discrete 0.050s (20.000 fps)
>>  Interval: Discrete 0.067s (15.000 fps)
>>  Interval: Discrete 0.100s (10.000 fps)
>>  Interval: Discrete 0.200s (5.000 fps)
>>  Size: Discrete 640x360
>>  Interval: Discrete 0.033s (30.000 fps)
>>  Interval: Discrete 0.040s (25.000 fps)
>>  Interval: Discrete 0.050s (20.000 fps)
>>  Interval: Discrete 0.067s (15.000 fps)
>>  Interval: Discrete 0.100s (10.000 fps)
>>  Interval: Discrete 0.200s (5.000 fps)
>>  Size: Discrete 544x288
>>  Interval: Discrete 0.033s (30.000 fps)
>>  Interval: Discrete 0.040s (25.000 fps)
>>  Interval: Discrete 0.050s (20.000 fps)
>>  Interval: Discrete 0.067s (15.000 fps)
>>  Interval: Discrete 0.100s (10.000 fps)
>>  Interval: Discrete 0.200s (5.000 fps)
>>  Size: Discrete 432x240
>>  Interval: Discrete 0.017s (60.000 fps)
>>  Interval: Discrete 0.033s (30.000 fps)
>>  Interval: Discrete 0.040s (25.000 fps)
>>  Interval: Discrete 0.050s (20.000 fps)
>>  Interval: Discrete 0.067s (15.000 fps)
>>  Interval: Discrete 0.100s (10.000 fps)
>>  

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

[@lex]

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  
> 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 
>
> > 
> > 
> >> 
> >> 
> >> On Saturday, March 12, 2016 at 8:47:38 PM UTC-3, Rosimildo DaSilva 
> wrote: 
> >>> 
> >>> I have this camera, and if you change the "start_video.sh" script to 
> >>> something like this 
> >>> you can see... the results... the CPU usage is much lower... 
> >>> 
> >>> echo "Starting H264 Encoder..." 
> >>> $FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720 -i 
> >>> $SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \ 
> >>>$ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720 
> -o 
> >>> /tmp/out1.h264 
> >>> ;; 
> >>> 
> >>> R 
> >>> 
> >>> On Saturday, March 12, 2016 at 4:55:57 PM UTC-6, @lex wrote: 
>  
>  Inspired by so many good arguments on USB uvc cameras i decided to 
> test 
>  one, a 720P HD used in ODROID, so you can take a look and see how 
> good it is 
>  for Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode 
> by HW 
>  worth the effort or we throw in the towel, it is up to you. 
>  
>  This is simple test, done with Orange Pi PC, with a tuned 3.4.39 
> kernel 
>  and with ssvb fex (TKaiser advice) to solve the so known temperature 
> issues 
>  this board faces when running at high speed. 
>  
>  The uvc camera is ODROID 720 HD: 
>  [  196.199875] ehci_irq: highspeed device connect 
>  [  196.460139] usb 4-1: new high-speed USB device number 2 using 
>  sunxi-ehci 
>  [  196.890710] 2:3:1: cannot get freq at ep 0x84 
>  [  196.892434] usbcore: registered new interface driver snd-usb-audio 
>  [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera 
> (1b71:0056) 
>  [  196.938300] is_otg_flag: 0x0, 
>  [  196.938479] usbcore: registered new interface driver uvcvideo 
>  [  196.938489] USB Video Class driver (v1.1.1) 
>  [  196.976118] 2:3:1: cannot get freq at ep 0x84 
>  
>  
>  As Jon said, you don't need to do anything, just plug it in and start 
>  using the UVC camera compliant. No need to worry about drivers, etc.. 
>  This camera has MPJEG mode and YUV mode: 
>  ioctl: VIDIOC_ENUM_FMT 
>  Index   : 0 
>  Type: Video Capture 
>  Pixel Format: 'MJPG' (compressed) 
>  Name: MJPEG 
>  Size: Discrete 1280x720 
>  Interval: Discrete 0.033s (30.000 fps) 
>  Interval: Discrete 0.040s (25.000 fps) 
>  Interval: Discrete 0.050s (20.000 fps) 
>  Interval: Discrete 0.067s (15.000 fps) 
>  Interval: Discrete 0.100s (10.000 fps) 
>  Interval: Discrete 0.200s (5.000 fps) 
>  Size: Discrete 640x480 
>  Interval: Discrete 0.033s (30.000 fps) 
>  Interval: Discrete 0.040s (25.000 fps) 
>  Interval: Discrete 0.050s (20.000 fps) 
>  Interval: Discrete 0.067s (15.000 fps) 
>  Interval: Discrete 0.100s (10.000 fps) 
>  Interval: Discrete 0.200s (5.000 fps) 
>  Size: Discrete 640x360 
>  Interval: Discrete 0.033s (30.000 fps) 
>  Interval: Discrete 0.040s (25.000 fps) 
>  Interval: Discrete 0.050s (20.000 fps) 
>  Interval: Discrete 0.067s (15.000 fps) 
>  Interval: Discrete 0.100s (10.000 fps) 
>  Interval: Discrete 0.200s (5.000 fps) 
>  Size: Discrete 544x288 
>  Interval: Discrete 0.033s (30.000 fps) 
>  Interval: Discrete 0.040s (25.000 fps) 
>  Interval: Discrete 0.050s (20.000 fps) 
>  Interval: Discrete 0.067s (15.000 fps) 
>  Interval: Discrete 0.100s (10.000 fps) 
>  Interval: Discrete 0.200s (5.000 fps) 
>  Size: Discrete 432x240 
>  Interval: Discrete 0.017s (60.000 fps) 
>  Interval: Discrete 0.033s (30.000 fps) 
>  Interval: Discrete 0.040s (25.000 fps) 
>  Interval: Discrete 0.050s (20.000 fps) 
>  Interval: Discrete 0.067s (15.000 fps) 
>  Interval: Discrete 0.100s (10.000 fps) 
>  Interval: Discrete 0.200s (5.000 fps) 
>  Size: Discrete 352x288 
>  Interval: Discrete 0.017s (60.000 fps) 
>  Interval: Discrete 0.033s (30.000 fps) 
>  Interval: Discrete 0.040s (25.000 fps) 
>  Interval: Discrete 0.050s (20.000 fps) 
>  Interval: Discrete 0.067s (15.000 fps) 
>  Interval: Discrete 0.100s (10.000 fps) 
>  Interval: Discrete 0.200s (5.000 

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

[jonsm...@gmail.com]

On Sat, Mar 12, 2016 at 7:38 PM, jonsm...@gmail.com  wrote:
> On Sat, Mar 12, 2016 at 7:37 PM, @lex  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

>
>
>>
>>
>> On Saturday, March 12, 2016 at 8:47:38 PM UTC-3, Rosimildo DaSilva wrote:
>>>
>>> I have this camera, and if you change the "start_video.sh" script to
>>> something like this
>>> you can see... the results... the CPU usage is much lower...
>>>
>>> echo "Starting H264 Encoder..."
>>> $FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720 -i
>>> $SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \
>>>$ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720 -o
>>> /tmp/out1.h264
>>> ;;
>>>
>>> R
>>>
>>> On Saturday, March 12, 2016 at 4:55:57 PM UTC-6, @lex wrote:

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

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

 The uvc camera is ODROID 720 HD:
 [  196.199875] ehci_irq: highspeed device connect
 [  196.460139] usb 4-1: new high-speed USB device number 2 using
 sunxi-ehci
 [  196.890710] 2:3:1: cannot get freq at ep 0x84
 [  196.892434] usbcore: registered new interface driver snd-usb-audio
 [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056)
 [  196.938300] is_otg_flag: 0x0,
 [  196.938479] usbcore: registered new interface driver uvcvideo
 [  196.938489] USB Video Class driver (v1.1.1)
 [  196.976118] 2:3:1: cannot get freq at ep 0x84


 As Jon said, you don't need to do anything, just plug it in and start
 using the UVC camera compliant. No need to worry about drivers, etc..
 This camera has MPJEG mode and YUV mode:
 ioctl: VIDIOC_ENUM_FMT
 Index   : 0
 Type: Video Capture
 Pixel Format: 'MJPG' (compressed)
 Name: MJPEG
 Size: Discrete 1280x720
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 fps)
 Interval: Discrete 0.100s (10.000 fps)
 Interval: Discrete 0.200s (5.000 fps)
 Size: Discrete 640x480
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 fps)
 Interval: Discrete 0.100s (10.000 fps)
 Interval: Discrete 0.200s (5.000 fps)
 Size: Discrete 640x360
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 fps)
 Interval: Discrete 0.100s (10.000 fps)
 Interval: Discrete 0.200s (5.000 fps)
 Size: Discrete 544x288
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 fps)
 Interval: Discrete 0.100s (10.000 fps)
 Interval: Discrete 0.200s (5.000 fps)
 Size: Discrete 432x240
 Interval: Discrete 0.017s (60.000 fps)
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 fps)
 Interval: Discrete 0.100s (10.000 fps)
 Interval: Discrete 0.200s (5.000 fps)
 Size: Discrete 352x288
 Interval: Discrete 0.017s (60.000 fps)
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 fps)
 Interval: Discrete 0.100s (10.000 fps)
 Interval: Discrete 0.200s (5.000 fps)
 Size: Discrete 320x240
 Interval: Discrete 0.017s (60.000 fps)
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 fps)
 Interval: Discrete 0.100s (10.000 fps)
 Interval: Discrete 0.200s (5.000 fps)
 Size: Discrete 752x416
 Interval: Discrete 0.033s (30.000 fps)
 Interval: Discrete 0.040s (25.000 fps)
 Interval: Discrete 0.050s (20.000 fps)
 Interval: Discrete 0.067s (15.000 

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

[@lex]

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.

On Saturday, March 12, 2016 at 8:47:38 PM UTC-3, Rosimildo DaSilva wrote:
>
> I have this camera, and if you change the "start_video.sh" script to 
> something like this
> you can see... the results... the CPU usage is much lower...
>
> echo "Starting H264 Encoder..."
> $FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720 -i 
> $SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \
>$ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720 -o 
> /tmp/out1.h264
> ;;
>
> R
>
> On Saturday, March 12, 2016 at 4:55:57 PM UTC-6, @lex wrote:
>>
>> Inspired by so many good arguments on USB uvc cameras i decided to test 
>> one, a 720P HD used in ODROID, so you can take a look and see how good it 
>> is for Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by 
>> HW worth the effort or we throw in the towel, it is up to you.
>>
>> This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel 
>> and with ssvb fex (TKaiser advice) to solve the so known temperature issues 
>> this board faces when running at high speed.
>>
>> The uvc camera is ODROID 720 HD:
>> [  196.199875] ehci_irq: highspeed device connect
>> [  196.460139] usb 4-1: new high-speed USB device number 2 using 
>> sunxi-ehci
>> [  196.890710] 2:3:1: cannot get freq at ep 0x84
>> [  196.892434] usbcore: registered new interface driver snd-usb-audio
>> [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056)
>> [  196.938300] is_otg_flag: 0x0,
>> [  196.938479] usbcore: registered new interface driver uvcvideo
>> [  196.938489] USB Video Class driver (v1.1.1)
>> [  196.976118] 2:3:1: cannot get freq at ep 0x84
>>
>>
>> As Jon said, you don't need to do anything, just plug it in and start 
>> using the UVC camera compliant. No need to worry about drivers, etc..
>> This camera has MPJEG mode and YUV mode:
>> ioctl: VIDIOC_ENUM_FMT
>> Index   : 0
>> Type: Video Capture
>> Pixel Format: 'MJPG' (compressed)
>> Name: MJPEG
>> Size: Discrete 1280x720
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 640x480
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 640x360
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 544x288
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 432x240
>> Interval: Discrete 0.017s (60.000 fps)
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 352x288
>> Interval: Discrete 0.017s (60.000 fps)
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 320x240
>> Interval: Discrete 0.017s (60.000 fps)
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 752x416
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 800x448
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 800x600
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 

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

[Rosimildo DaSilva]

Some cameras are H.264 aware and they usually uses the UVC interface.

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

I have tested them OPI PC they work just fine.

R




On Saturday, March 12, 2016 at 6:16:01 PM UTC-6, @lex wrote:
>
> Interesting, can you check if it is a feature of this camera or the new 
> kernel?
> If you have OPI PC, can you check that?
>
> On Saturday, March 12, 2016 at 8:10:57 PM UTC-3, Jon Smirl wrote:
>>
>> Look carefully at my sonix video parameters... 
>> notice that there are two /dev/videoX devices 
>>
>> This is done so that the screen display app can use the the 
>> uncompressed stream while forwarding on the h.264 stream without 
>> decompressing it. The uncompressed stream does not need much CPU to 
>> display. 
>>
>> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video1 
>> --list-formats-ext 
>> ioctl: VIDIOC_ENUM_FMT 
>> Index   : 0 
>> Type: Video Capture 
>> Pixel Format: 'YUYV' 
>> Name: YUYV 4:2:2 
>> Size: Discrete 1280x720 
>> Interval: Discrete 0.200s (5.000 fps) 
>> Size: Discrete 640x480 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>> Size: Discrete 320x240 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>>
>> Both MJPG and h.264 work at 720P30. 
>> Index   : 1 
>> Type: Video Capture 
>> Pixel Format: 'MJPG' (compressed) 
>> Name: Motion-JPEG 
>> Size: Discrete 1280x720 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>> Size: Discrete 640x480 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>> Size: Discrete 320x240 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>>
>> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video2 
>> --list-formats-ext 
>> ioctl: VIDIOC_ENUM_FMT 
>> Index   : 0 
>> Type: Video Capture 
>> Pixel Format: 'H264' (compressed) 
>> Name: H.264 
>> Size: Discrete 1280x720 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>> Size: Discrete 640x480 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>> Size: Discrete 320x240 
>> Interval: Discrete 0.033s (30.000 fps) 
>> Interval: Discrete 0.050s (20.000 fps) 
>> Interval: Discrete 0.067s (15.000 fps) 
>> Interval: Discrete 0.100s (10.000 fps) 
>> Interval: Discrete 0.200s (5.000 fps) 
>>
>> On Sat, Mar 12, 2016 at 5:55 PM, @lex  wrote: 
>> > Inspired by so many good arguments on USB uvc cameras i decided to test 
>> one, 
>> > a 720P HD used in ODROID, so you can take a look and see how good it is 
>> for 
>> > Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by HW 
>> worth 
>> > the effort or we throw in the towel, it is up to you. 
>> > 
>> > This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel 
>> and 
>> > with ssvb fex (TKaiser advice) to solve the so known temperature issues 
>> this 
>> > board faces when running at high speed. 
>> > 
>> > The uvc camera is ODROID 720 HD: 
>> > [  196.199875] ehci_irq: highspeed device connect 
>> > [  196.460139] usb 4-1: new high-speed USB device number 2 using 
>> sunxi-ehci 
>> > [  196.890710] 2:3:1: cannot get freq at ep 0x84 
>> > [  196.892434] usbcore: registered new interface driver snd-usb-audio 
>> > [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera 
>> (1b71:0056) 
>> > [  196.938300] is_otg_flag: 0x0, 
>> > [  196.938479] usbcore: registered new interface driver uvcvideo 
>> > [  196.938489] USB Video Class driver (v1.1.1) 
>> > [  196.976118] 2:3:1: cannot get freq at ep 0x84 
>> > 
>> > 
>> > As Jon said, you don't need to do anything, just plug it in and start 
>> using 
>> > the UVC camera compliant. No need to worry about drivers, etc.. 
>> > This camera has MPJEG mode and YUV mode: 
>> > ioctl: VIDIOC_ENUM_FMT 
>> > Index

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

[jonsm...@gmail.com]

On Sat, Mar 12, 2016 at 7:16 PM, @lex  wrote:
> Interesting, can you check if it is a feature of this camera or the new
> kernel?
> If you have OPI PC, can you check that?

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

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

>
>
> On Saturday, March 12, 2016 at 8:10:57 PM UTC-3, Jon Smirl wrote:
>>
>> Look carefully at my sonix video parameters...
>> notice that there are two /dev/videoX devices
>>
>> This is done so that the screen display app can use the the
>> uncompressed stream while forwarding on the h.264 stream without
>> decompressing it. The uncompressed stream does not need much CPU to
>> display.
>>
>> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video1
>> --list-formats-ext
>> ioctl: VIDIOC_ENUM_FMT
>> Index   : 0
>> Type: Video Capture
>> Pixel Format: 'YUYV'
>> Name: YUYV 4:2:2
>> Size: Discrete 1280x720
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 640x480
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 320x240
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>>
>> Both MJPG and h.264 work at 720P30.
>> Index   : 1
>> Type: Video Capture
>> Pixel Format: 'MJPG' (compressed)
>> Name: Motion-JPEG
>> Size: Discrete 1280x720
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 640x480
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 320x240
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>>
>> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video2
>> --list-formats-ext
>> ioctl: VIDIOC_ENUM_FMT
>> Index   : 0
>> Type: Video Capture
>> Pixel Format: 'H264' (compressed)
>> Name: H.264
>> Size: Discrete 1280x720
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 640x480
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>> Size: Discrete 320x240
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.050s (20.000 fps)
>> Interval: Discrete 0.067s (15.000 fps)
>> Interval: Discrete 0.100s (10.000 fps)
>> Interval: Discrete 0.200s (5.000 fps)
>>
>> On Sat, Mar 12, 2016 at 5:55 PM, @lex  wrote:
>> > Inspired by so many good arguments on USB uvc cameras i decided to test
>> > one,
>> > a 720P HD used in ODROID, so you can take a look and see how good it is
>> > for
>> > Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by HW
>> > worth
>> > the effort or we throw in the towel, it is up to you.
>> >
>> > This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel
>> > and
>> > with ssvb fex (TKaiser advice) to solve the so known temperature issues
>> > this
>> > board faces when running at high speed.
>> >
>> > The uvc camera is ODROID 720 HD:
>> > [  196.199875] ehci_irq: highspeed device connect
>> > [  196.460139] usb 4-1: new high-speed USB device number 2 using
>> > sunxi-ehci
>> > [  196.890710] 2:3:1: cannot get freq at ep 0x84
>> > [  196.892434] usbcore: registered new interface driver snd-usb-audio
>> > [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera
>> > (1b71:0056)
>> > [  196.938300] is_otg_flag: 0x0,
>> > [  196.938479] usbcore: registered new interface driver uvcvideo
>> > [  196.938489] USB Video Class driver (v1.1.1)
>> > [  196.976118] 2:3:1: cannot get freq at ep 0x84
>> >
>> >
>> > As Jon said, you don't need to do anything, just plug it in and start
>> > using
>> > the UVC camera compliant. No need to worry about drivers, etc..
>> > This camera has MPJEG mode and YUV mode:
>> > ioctl: VIDIOC_ENUM_FMT
>> > Index   : 0
>> > Type: Video Capture
>> > Pixel Format: 'MJPG' (compressed)
>> > Name: MJPEG
>> > Size: Discrete 1280x720
>> > Interval: Discrete 

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

[@lex]

Interesting, can you check if it is a feature of this camera or the new 
kernel?
If you have OPI PC, can you check that?

On Saturday, March 12, 2016 at 8:10:57 PM UTC-3, Jon Smirl wrote:
>
> Look carefully at my sonix video parameters... 
> notice that there are two /dev/videoX devices 
>
> This is done so that the screen display app can use the the 
> uncompressed stream while forwarding on the h.264 stream without 
> decompressing it. The uncompressed stream does not need much CPU to 
> display. 
>
> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video1 
> --list-formats-ext 
> ioctl: VIDIOC_ENUM_FMT 
> Index   : 0 
> Type: Video Capture 
> Pixel Format: 'YUYV' 
> Name: YUYV 4:2:2 
> Size: Discrete 1280x720 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 640x480 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 320x240 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
>
> Both MJPG and h.264 work at 720P30. 
> Index   : 1 
> Type: Video Capture 
> Pixel Format: 'MJPG' (compressed) 
> Name: Motion-JPEG 
> Size: Discrete 1280x720 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 640x480 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 320x240 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
>
> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video2 
> --list-formats-ext 
> ioctl: VIDIOC_ENUM_FMT 
> Index   : 0 
> Type: Video Capture 
> Pixel Format: 'H264' (compressed) 
> Name: H.264 
> Size: Discrete 1280x720 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 640x480 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 320x240 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
>
> On Sat, Mar 12, 2016 at 5:55 PM, @lex  
> wrote: 
> > Inspired by so many good arguments on USB uvc cameras i decided to test 
> one, 
> > a 720P HD used in ODROID, so you can take a look and see how good it is 
> for 
> > Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by HW 
> worth 
> > the effort or we throw in the towel, it is up to you. 
> > 
> > This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel 
> and 
> > with ssvb fex (TKaiser advice) to solve the so known temperature issues 
> this 
> > board faces when running at high speed. 
> > 
> > The uvc camera is ODROID 720 HD: 
> > [  196.199875] ehci_irq: highspeed device connect 
> > [  196.460139] usb 4-1: new high-speed USB device number 2 using 
> sunxi-ehci 
> > [  196.890710] 2:3:1: cannot get freq at ep 0x84 
> > [  196.892434] usbcore: registered new interface driver snd-usb-audio 
> > [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera 
> (1b71:0056) 
> > [  196.938300] is_otg_flag: 0x0, 
> > [  196.938479] usbcore: registered new interface driver uvcvideo 
> > [  196.938489] USB Video Class driver (v1.1.1) 
> > [  196.976118] 2:3:1: cannot get freq at ep 0x84 
> > 
> > 
> > As Jon said, you don't need to do anything, just plug it in and start 
> using 
> > the UVC camera compliant. No need to worry about drivers, etc.. 
> > This camera has MPJEG mode and YUV mode: 
> > ioctl: VIDIOC_ENUM_FMT 
> > Index   : 0 
> > Type: Video Capture 
> > Pixel Format: 'MJPG' (compressed) 
> > Name: MJPEG 
> > Size: Discrete 1280x720 
> > Interval: Discrete 0.033s (30.000 fps) 
> > Interval: Discrete 0.040s (25.000 fps) 
> > Interval: Discrete 0.050s (20.000 fps) 
> > Interval: Discrete 0.067s (15.000 fps) 
> > Interval: Discrete 0.100s (10.000 fps) 
> > Interval: Discrete 0.200s (5.000 fps) 
> > Size: Discrete 640x480 
> > Interval: Discrete 0.033s (30.000 fps) 
> > 

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

[Rosimildo DaSilva]

I have this camera, and if you change the "start_video.sh" script to 
something like this
you can see... the results... the CPU usage is much lower...

echo "Starting H264 Encoder..."
$FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720 -i 
$SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \
   $ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720 -o 
/tmp/out1.h264
;;

R

On Saturday, March 12, 2016 at 4:55:57 PM UTC-6, @lex wrote:
>
> Inspired by so many good arguments on USB uvc cameras i decided to test 
> one, a 720P HD used in ODROID, so you can take a look and see how good it 
> is for Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by 
> HW worth the effort or we throw in the towel, it is up to you.
>
> This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel 
> and with ssvb fex (TKaiser advice) to solve the so known temperature issues 
> this board faces when running at high speed.
>
> The uvc camera is ODROID 720 HD:
> [  196.199875] ehci_irq: highspeed device connect
> [  196.460139] usb 4-1: new high-speed USB device number 2 using sunxi-ehci
> [  196.890710] 2:3:1: cannot get freq at ep 0x84
> [  196.892434] usbcore: registered new interface driver snd-usb-audio
> [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056)
> [  196.938300] is_otg_flag: 0x0,
> [  196.938479] usbcore: registered new interface driver uvcvideo
> [  196.938489] USB Video Class driver (v1.1.1)
> [  196.976118] 2:3:1: cannot get freq at ep 0x84
>
>
> As Jon said, you don't need to do anything, just plug it in and start 
> using the UVC camera compliant. No need to worry about drivers, etc..
> This camera has MPJEG mode and YUV mode:
> ioctl: VIDIOC_ENUM_FMT
> Index   : 0
> Type: Video Capture
> Pixel Format: 'MJPG' (compressed)
> Name: MJPEG
> Size: Discrete 1280x720
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 640x480
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 640x360
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 544x288
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 432x240
> Interval: Discrete 0.017s (60.000 fps)
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 352x288
> Interval: Discrete 0.017s (60.000 fps)
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 320x240
> Interval: Discrete 0.017s (60.000 fps)
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 752x416
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 800x448
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 800x600
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 864x480
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 

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

[jonsm...@gmail.com]

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

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

On Sat, Mar 12, 2016 at 6:10 PM, jonsm...@gmail.com  wrote:
> Look carefully at my sonix video parameters...
> notice that there are two /dev/videoX devices
>
> This is done so that the screen display app can use the the
> uncompressed stream while forwarding on the h.264 stream without
> decompressing it. The uncompressed stream does not need much CPU to
> display.
>
> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video1 
> --list-formats-ext
> ioctl: VIDIOC_ENUM_FMT
> Index   : 0
> Type: Video Capture
> Pixel Format: 'YUYV'
> Name: YUYV 4:2:2
> Size: Discrete 1280x720
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 640x480
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 320x240
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
>
> Both MJPG and h.264 work at 720P30.
> Index   : 1
> Type: Video Capture
> Pixel Format: 'MJPG' (compressed)
> Name: Motion-JPEG
> Size: Discrete 1280x720
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 640x480
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 320x240
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
>
> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video2 
> --list-formats-ext
> ioctl: VIDIOC_ENUM_FMT
> Index   : 0
> Type: Video Capture
> Pixel Format: 'H264' (compressed)
> Name: H.264
> Size: Discrete 1280x720
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 640x480
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 320x240
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
>
> On Sat, Mar 12, 2016 at 5:55 PM, @lex  wrote:
>> Inspired by so many good arguments on USB uvc cameras i decided to test one,
>> a 720P HD used in ODROID, so you can take a look and see how good it is for
>> Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by HW worth
>> the effort or we throw in the towel, it is up to you.
>>
>> This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel and
>> with ssvb fex (TKaiser advice) to solve the so known temperature issues this
>> board faces when running at high speed.
>>
>> The uvc camera is ODROID 720 HD:
>> [  196.199875] ehci_irq: highspeed device connect
>> [  196.460139] usb 4-1: new high-speed USB device number 2 using sunxi-ehci
>> [  196.890710] 2:3:1: cannot get freq at ep 0x84
>> [  196.892434] usbcore: registered new interface driver snd-usb-audio
>> [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056)
>> [  196.938300] is_otg_flag: 0x0,
>> [  196.938479] usbcore: registered new interface driver uvcvideo
>> [  196.938489] USB Video Class driver (v1.1.1)
>> [  196.976118] 2:3:1: cannot get freq at ep 0x84
>>
>>
>> As Jon said, you don't need to do anything, just plug it in and start using
>> the UVC camera compliant. No need to worry about drivers, etc..
>> This camera has MPJEG mode and YUV mode:
>> ioctl: VIDIOC_ENUM_FMT
>> Index   : 0
>> Type: Video Capture
>> Pixel Format: 'MJPG' (compressed)
>> Name: MJPEG
>> Size: Discrete 1280x720
>> Interval: Discrete 0.033s (30.000 fps)
>> Interval: Discrete 0.040s (25.000 fps)
>> Interval: Discrete 

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

[jonsm...@gmail.com]

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

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

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

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

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

On Sat, Mar 12, 2016 at 5:55 PM, @lex  wrote:
> Inspired by so many good arguments on USB uvc cameras i decided to test one,
> a 720P HD used in ODROID, so you can take a look and see how good it is for
> Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode by HW worth
> the effort or we throw in the towel, it is up to you.
>
> This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel and
> with ssvb fex (TKaiser advice) to solve the so known temperature issues this
> board faces when running at high speed.
>
> The uvc camera is ODROID 720 HD:
> [  196.199875] ehci_irq: highspeed device connect
> [  196.460139] usb 4-1: new high-speed USB device number 2 using sunxi-ehci
> [  196.890710] 2:3:1: cannot get freq at ep 0x84
> [  196.892434] usbcore: registered new interface driver snd-usb-audio
> [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056)
> [  196.938300] is_otg_flag: 0x0,
> [  196.938479] usbcore: registered new interface driver uvcvideo
> [  196.938489] USB Video Class driver (v1.1.1)
> [  196.976118] 2:3:1: cannot get freq at ep 0x84
>
>
> As Jon said, you don't need to do anything, just plug it in and start using
> the UVC camera compliant. No need to worry about drivers, etc..
> This camera has MPJEG mode and YUV mode:
> ioctl: VIDIOC_ENUM_FMT
> Index   : 0
> Type: Video Capture
> Pixel Format: 'MJPG' (compressed)
> Name: MJPEG
> Size: Discrete 1280x720
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 640x480
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 640x360
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s (25.000 fps)
> Interval: Discrete 0.050s (20.000 fps)
> Interval: Discrete 0.067s (15.000 fps)
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
> Size: Discrete 544x288
> Interval: Discrete 0.033s (30.000 fps)
> Interval: Discrete 0.040s 

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

[@lex]

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

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

The uvc camera is ODROID 720 HD:
[  196.199875] ehci_irq: highspeed device connect
[  196.460139] usb 4-1: new high-speed USB device number 2 using sunxi-ehci
[  196.890710] 2:3:1: cannot get freq at ep 0x84
[  196.892434] usbcore: registered new interface driver snd-usb-audio
[  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056)
[  196.938300] is_otg_flag: 0x0,
[  196.938479] usbcore: registered new interface driver uvcvideo
[  196.938489] USB Video Class driver (v1.1.1)
[  196.976118] 2:3:1: cannot get freq at ep 0x84


As Jon said, you don't need to do anything, just plug it in and start using 
the UVC camera compliant. No need to worry about drivers, etc..
This camera has MPJEG mode and YUV mode:
ioctl: VIDIOC_ENUM_FMT
Index   : 0
Type: Video Capture
Pixel Format: 'MJPG' (compressed)
Name: MJPEG
Size: Discrete 1280x720
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 640x480
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 640x360
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 544x288
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 432x240
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 352x288
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 320x240
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 752x416
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 800x448
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 800x600
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 864x480
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 960x544
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 960x720
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.200s (5.000 fps)
Size: Discrete 1024x576
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.100s (10.000 fps)

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

[Rosimildo DaSilva]

Jon,
Thanks for yours always informative posts.

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


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

THanks, R




On Saturday, March 12, 2016 at 1:09:32 PM UTC-6, Jon Smirl wrote:
>
> gspca is around 10 years old and it pre-dates UVC. 
>
> The 291 image chip can take higher resolution stills, but mine only 
> has a 720P sensor on it. 
> The 292 image chip has similar performance at 1080P. 
>
> I have wasted far too much time trying to get Allwinner cameras 
> working properly and I won't touch them any more. 
>
> Our current product uses a more advanced camera similar to this one: 
>
> http://world.taobao.com/item/521668890252.htm?spm=a312a.7700714.0.0.ekoWOi#detail
>  
> But these boards are too hard to interface with for casual use. The 
> main advantage to these chips is that they can simultaneously provide 
> three versions of the h.264 stream at different resolutions. The Sonix 
> chips are single stream but far easier to use. 
>
> This is cheapest, decent h.264 720P camera I camera I am aware of - $6.12 
>
> http://world.taobao.com/item/527850462938.htm?spm=a312a.7700714.0.0.d9CEzd#detail
>  
> You would need to attach to it using Ethernet, USB access requires 
> custom firmware. 
>
> Here are all of the modes supported by the 291 chips. 
> Note that it supports 720P30 h.264 
>
> this first mode is uncompressed, 480Mb USB limits it to 720P5 
> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video1 
> --list-formats-ext 
> ioctl: VIDIOC_ENUM_FMT 
> Index   : 0 
> Type: Video Capture 
> Pixel Format: 'YUYV' 
> Name: YUYV 4:2:2 
> Size: Discrete 1280x720 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 640x480 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 320x240 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
>
> Both MJPG and h.264 work at 720P30. 
> Index   : 1 
> Type: Video Capture 
> Pixel Format: 'MJPG' (compressed) 
> Name: Motion-JPEG 
> Size: Discrete 1280x720 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 640x480 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 320x240 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
>
> jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video2 
> --list-formats-ext 
> ioctl: VIDIOC_ENUM_FMT 
> Index   : 0 
> Type: Video Capture 
> Pixel Format: 'H264' (compressed) 
> Name: H.264 
> Size: Discrete 1280x720 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 640x480 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
> Size: Discrete 320x240 
> Interval: Discrete 0.033s (30.000 fps) 
> Interval: Discrete 0.050s (20.000 fps) 
> Interval: Discrete 0.067s (15.000 fps) 
> Interval: Discrete 0.100s (10.000 fps) 
> Interval: Discrete 0.200s (5.000 fps) 
>
>
>
> On Sat, Mar 12, 2016 at 8:49 AM, @lex  
> wrote: 
> > Thanks Jon. 
> > 
> > I have some thoughts on this proposed hardware solution: 
> > 
> > * This camera will not be recognized as uvc usb device, unless you add 
> it to 
> > the device list, no big deal i think. 
> > Your kernel is 3.3 but i think you or someone else already added it to 
> uvc 
> > device list. (i may be wrong), 
> > 
> > * Orange PI ONE has only one USB, so you will need to access the device 
> > remotely, 
> > 
> > * Grabbing the video can be done with V4l2 as usual, 
> > 
> > * I tested here a usb Labtec gspca camera which is VGA JPEG 30 FPS, and 

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

[jonsm...@gmail.com]

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

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

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

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

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

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

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

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

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



On Sat, Mar 12, 2016 at 8:49 AM, @lex  wrote:
> Thanks Jon.
>
> I have some thoughts on this proposed hardware solution:
>
> * This camera will not be recognized as uvc usb device, unless you add it to
> the device list, no big deal i think.
> Your kernel is 3.3 but i think you or someone else already added it to uvc
> device list. (i may be wrong),
>
> * Orange PI ONE has only one USB, so you will need to access the device
> remotely,
>
> * Grabbing the video can be done with V4l2 as usual,
>
> * I tested here a usb Labtec gspca camera which is VGA JPEG 30 FPS, and its
> performance is about ~9 fps, that means USB camera tend to perform below
> specifications when not in Desktop, may be the usb bandwidth is a
> constraint,
>
> * Original OPI camera is $ 5.90 while the one you pointed is $ 8.52 plus
> some usb cable and may need some wiring/soldering,
>
> * Logitec is out of question, i cannot get one for less than $ 100.00. And
> considering spending $ 10.00 / 15.00 on a sbc board and another $ 100.00 is
> only viable if you don't want to mess with software.
>
> * No tinkering, no learning and no solution for the upcoming Allwinner new
> devices going this route.
>
> So, guys lets's get back to work, the fight is not over yet.
>
> @lex
>
>
> On Friday, March 11, 2016 at 8:49:42 PM UTC-3, Jon Smirl wrote:
>>
>> [33718.237465] usb 2-5.1: new high-speed USB device number 12 using
>> ehci-pci
>> [33718.782014] usb 2-5.1: new high-speed USB device number 13 using
>> ehci-pci
>> [33719.121687] usb 

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

[@lex]

Thanks Jon.

I have some thoughts on this proposed hardware solution:

* This camera will not be recognized as uvc usb device, unless you add it 
to the device list, no big deal i think. 
Your kernel is 3.3 but i think you or someone else already added it to uvc 
device list. (i may be wrong),

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

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

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

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

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

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

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

@lex


On Friday, March 11, 2016 at 8:49:42 PM UTC-3, Jon Smirl wrote:
>
> [33718.237465] usb 2-5.1: new high-speed USB device number 12 using 
> ehci-pci 
> [33718.782014] usb 2-5.1: new high-speed USB device number 13 using 
> ehci-pci 
> [33719.121687] usb 2-5.1: New USB device found, idVendor=18e3, 
> idProduct=5100 
> [33719.121692] usb 2-5.1: New USB device strings: Mfr=2, Product=1, 
> SerialNumber=3 
> [33719.121696] usb 2-5.1: Product: USB 2.0 Camera 
> [33719.121698] usb 2-5.1: Manufacturer: Sonix Technology Co., Ltd. 
> [33719.121701] usb 2-5.1: SerialNumber: SN0001 
> [33719.122631] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:5100) 
> [33719.146885] uvcvideo: Unable to create debugfs 2-13 directory. 
> [33719.147213] input: USB 2.0 Camera as 
> /devices/pci:00/:00:1d.7/usb2/2-5/2-5.1/2-5.1:1.0/input/input15 
> jonsmirl@terra:/work/gm/linux-3.3-fa$ 
>
> On Fri, Mar 11, 2016 at 6:26 PM, @lex  
> wrote: 
> > Can you please tell me the idVendor and idProduct for this camera? 
> > 
> > 
> > On Friday, March 11, 2016 at 8:08:21 PM UTC-3, @lex wrote: 
> >> 
> >> Err... That was new to me. Without researching how do you grab video 
> from 
> >> this generic driver how good this camera performs? 
> >> 
> >> On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl wrote: 
> >>> 
> >>> On Fri, Mar 11, 2016 at 4:42 PM, @lex  wrote: 
> >>> > Seems to be a nice camera, but that depends on your kernel version. 
> >>> > There is no support for SN9C291 OV9712 on kernel v3.4.39. 
> >>> > And no support on odroid-3.8.30 on my U3 also. 
> >>> > Don't know about armbian legacy kernel version, but i don't expect 
> >>> > there 
> >>> > will be support also. 
> >>> 
> >>> The camera does not need a specific driver, it uses the generic USB 
> >>> Video driver. 
> >>> It is like a USB mouse or keyboard, you don't need a specific driver 
> >>> for every different one. 
> >>> 
> >>> Drivers/Multimedia/Media USB/USB Video Class (UVC) 
> >>> 
> >>> Kconfig USB_VIDEO_CLASS 
> >>> 
> >>> This support dates way back to around 2.4 or so. Almost every desktop 
> >>> web cam works using this driver. 
> >>> 
> >>> > 
> >>> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote: 
> >>> >> 
> >>> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga  
> >>> >> wrote: 
> >>> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva 
> >>> >> >  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". 
> >>> >> 
> >>> >> I gave up fighting with Allwinner's encoder long ago. It is far 
> easier 
> >>> >> to just plug in a USB based h.264 camera. You can easily buy ones 
> from 
> >>> >> Logitech for $50. 
> >>> >> 
> >>> >> If you want it at the hardware level, look at chips from Sonix. 
> Here 
> >>> >> is a board based on the SN9C291 for $8.50. The bare chips are about 
> >>> >> $4. 
> >>> >> 
> >>> >> 
> >>> >> 
> 

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

[jonsm...@gmail.com]

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

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

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

And all of this works without writing any more drivers.

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



On Fri, Mar 11, 2016 at 6:08 PM, @lex  wrote:
> Err... That was new to me. Without researching how do you grab video from
> this generic driver how good this camera performs?
>
> On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl wrote:
>>
>> On Fri, Mar 11, 2016 at 4:42 PM, @lex  wrote:
>> > Seems to be a nice camera, but that depends on your kernel version.
>> > There is no support for SN9C291 OV9712 on kernel v3.4.39.
>> > And no support on odroid-3.8.30 on my U3 also.
>> > Don't know about armbian legacy kernel version, but i don't expect there
>> > will be support also.
>>
>> The camera does not need a specific driver, it uses the generic USB
>> Video driver.
>> It is like a USB mouse or keyboard, you don't need a specific driver
>> for every different one.
>>
>> Drivers/Multimedia/Media USB/USB Video Class (UVC)
>>
>> Kconfig USB_VIDEO_CLASS
>>
>> This support dates way back to around 2.4 or so. Almost every desktop
>> web cam works using this driver.
>>
>> >
>> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote:
>> >>
>> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga 
>> >> wrote:
>> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva
>> >> >  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".
>> >>
>> >> I gave up fighting with Allwinner's encoder long ago. It is far easier
>> >> to just plug in a USB based h.264 camera. You can easily buy ones from
>> >> Logitech for $50.
>> >>
>> >> If you want it at the hardware level, look at chips from Sonix. Here
>> >> is a board based on the SN9C291 for $8.50. The bare chips are about
>> >> $4.
>> >>
>> >>
>> >> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail
>> >>
>> >> Note that this PCBA is the same price as most bare image sensors
>> >> mounted on a flex cable. Plus I find it much easier to wire things
>> >> with a simple USB cable instead of an FFC.
>> >>
>> >> The Sonix chips will appear as USB UVC devices when plugged into Linux
>> >> and they will need no special drivers. They also work on Windows.
>> >>
>> >>
>> >>
>> >> >
>> >> > --
>> >> > Manuel Braga
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "linux-sunxi" group.
>> >> > To unsubscribe from this group and stop receiving emails from it,
>> >> > send
>> >> > an email to linux-sunxi...@googlegroups.com.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >>
>> >> --
>> >> Jon Smirl
>> >> jons...@gmail.com
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "linux-sunxi" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to linux-sunxi...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Jon Smirl
>> jons...@gmail.com
>
> --
> 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.



-- 
Jon Smirl
jonsm...@gmail.com

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

[jonsm...@gmail.com]

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

On Fri, Mar 11, 2016 at 6:26 PM, @lex  wrote:
> Can you please tell me the idVendor and idProduct for this camera?
>
>
> On Friday, March 11, 2016 at 8:08:21 PM UTC-3, @lex wrote:
>>
>> Err... That was new to me. Without researching how do you grab video from
>> this generic driver how good this camera performs?
>>
>> On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl wrote:
>>>
>>> On Fri, Mar 11, 2016 at 4:42 PM, @lex  wrote:
>>> > Seems to be a nice camera, but that depends on your kernel version.
>>> > There is no support for SN9C291 OV9712 on kernel v3.4.39.
>>> > And no support on odroid-3.8.30 on my U3 also.
>>> > Don't know about armbian legacy kernel version, but i don't expect
>>> > there
>>> > will be support also.
>>>
>>> The camera does not need a specific driver, it uses the generic USB
>>> Video driver.
>>> It is like a USB mouse or keyboard, you don't need a specific driver
>>> for every different one.
>>>
>>> Drivers/Multimedia/Media USB/USB Video Class (UVC)
>>>
>>> Kconfig USB_VIDEO_CLASS
>>>
>>> This support dates way back to around 2.4 or so. Almost every desktop
>>> web cam works using this driver.
>>>
>>> >
>>> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote:
>>> >>
>>> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga 
>>> >> wrote:
>>> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva
>>> >> >  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".
>>> >>
>>> >> I gave up fighting with Allwinner's encoder long ago. It is far easier
>>> >> to just plug in a USB based h.264 camera. You can easily buy ones from
>>> >> Logitech for $50.
>>> >>
>>> >> If you want it at the hardware level, look at chips from Sonix. Here
>>> >> is a board based on the SN9C291 for $8.50. The bare chips are about
>>> >> $4.
>>> >>
>>> >>
>>> >> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail
>>> >>
>>> >> Note that this PCBA is the same price as most bare image sensors
>>> >> mounted on a flex cable. Plus I find it much easier to wire things
>>> >> with a simple USB cable instead of an FFC.
>>> >>
>>> >> The Sonix chips will appear as USB UVC devices when plugged into Linux
>>> >> and they will need no special drivers. They also work on Windows.
>>> >>
>>> >>
>>> >>
>>> >> >
>>> >> > --
>>> >> > Manuel Braga
>>> >> >
>>> >> > --
>>> >> > You received this message because you are subscribed to the Google
>>> >> > Groups "linux-sunxi" group.
>>> >> > To unsubscribe from this group and stop receiving emails from it,
>>> >> > send
>>> >> > an email to linux-sunxi...@googlegroups.com.
>>> >> > For more options, visit https://groups.google.com/d/optout.
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Jon Smirl
>>> >> jons...@gmail.com
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "linux-sunxi" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to linux-sunxi...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Jon Smirl
>>> jons...@gmail.com
>
> --
> 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 

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

[@lex]

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

On Friday, March 11, 2016 at 8:08:21 PM UTC-3, @lex wrote:
>
> Err... That was new to me. Without researching how do you grab video from 
> this generic driver how good this camera performs?
>
> On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl wrote:
>>
>> On Fri, Mar 11, 2016 at 4:42 PM, @lex  wrote: 
>> > Seems to be a nice camera, but that depends on your kernel version. 
>> > There is no support for SN9C291 OV9712 on kernel v3.4.39. 
>> > And no support on odroid-3.8.30 on my U3 also. 
>> > Don't know about armbian legacy kernel version, but i don't expect 
>> there 
>> > will be support also. 
>>
>> The camera does not need a specific driver, it uses the generic USB 
>> Video driver. 
>> It is like a USB mouse or keyboard, you don't need a specific driver 
>> for every different one. 
>>
>> Drivers/Multimedia/Media USB/USB Video Class (UVC) 
>>
>> Kconfig USB_VIDEO_CLASS 
>>
>> This support dates way back to around 2.4 or so. Almost every desktop 
>> web cam works using this driver. 
>>
>> > 
>> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote: 
>> >> 
>> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga  
>> wrote: 
>> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva 
>> >> >  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". 
>> >> 
>> >> I gave up fighting with Allwinner's encoder long ago. It is far easier 
>> >> to just plug in a USB based h.264 camera. You can easily buy ones from 
>> >> Logitech for $50. 
>> >> 
>> >> If you want it at the hardware level, look at chips from Sonix. Here 
>> >> is a board based on the SN9C291 for $8.50. The bare chips are about 
>> >> $4. 
>> >> 
>> >> 
>> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail
>>  
>> >> 
>> >> Note that this PCBA is the same price as most bare image sensors 
>> >> mounted on a flex cable. Plus I find it much easier to wire things 
>> >> with a simple USB cable instead of an FFC. 
>> >> 
>> >> The Sonix chips will appear as USB UVC devices when plugged into Linux 
>> >> and they will need no special drivers. They also work on Windows. 
>> >> 
>> >> 
>> >> 
>> >> > 
>> >> > -- 
>> >> > Manuel Braga 
>> >> > 
>> >> > -- 
>> >> > You received this message because you are subscribed to the Google 
>> >> > Groups "linux-sunxi" group. 
>> >> > To unsubscribe from this group and stop receiving emails from it, 
>> send 
>> >> > an email to linux-sunxi...@googlegroups.com. 
>> >> > For more options, visit https://groups.google.com/d/optout. 
>> >> 
>> >> 
>> >> 
>> >> -- 
>> >> Jon Smirl 
>> >> jons...@gmail.com 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "linux-sunxi" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to linux-sunxi...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>
>>
>> -- 
>> Jon Smirl 
>> jons...@gmail.com 
>>
>

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

[jonsm...@gmail.com]

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

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

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

Kconfig USB_VIDEO_CLASS

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

>
> On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote:
>>
>> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga  wrote:
>> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva
>> >  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".
>>
>> I gave up fighting with Allwinner's encoder long ago. It is far easier
>> to just plug in a USB based h.264 camera. You can easily buy ones from
>> Logitech for $50.
>>
>> If you want it at the hardware level, look at chips from Sonix. Here
>> is a board based on the SN9C291 for $8.50. The bare chips are about
>> $4.
>>
>> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail
>>
>> Note that this PCBA is the same price as most bare image sensors
>> mounted on a flex cable. Plus I find it much easier to wire things
>> with a simple USB cable instead of an FFC.
>>
>> The Sonix chips will appear as USB UVC devices when plugged into Linux
>> and they will need no special drivers. They also work on Windows.
>>
>>
>>
>> >
>> > --
>> > Manuel Braga
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "linux-sunxi" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to linux-sunxi...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Jon Smirl
>> jons...@gmail.com
>
> --
> 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.



-- 
Jon Smirl
jonsm...@gmail.com

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

[@lex]

Seems to be a nice camera, but that depends on your kernel version.
There is no support for SN9C291 OV9712 on kernel v3.4.39.
And no support on odroid-3.8.30 on my U3 also.
Don't know about armbian legacy kernel version, but i don't expect there 
will be support also.

On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote:
>
> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga  > wrote: 
> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva 
> >  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". 
>
> I gave up fighting with Allwinner's encoder long ago. It is far easier 
> to just plug in a USB based h.264 camera. You can easily buy ones from 
> Logitech for $50. 
>
> If you want it at the hardware level, look at chips from Sonix. Here 
> is a board based on the SN9C291 for $8.50. The bare chips are about 
> $4. 
>
> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail
>  
>
> Note that this PCBA is the same price as most bare image sensors 
> mounted on a flex cable. Plus I find it much easier to wire things 
> with a simple USB cable instead of an FFC. 
>
> The Sonix chips will appear as USB UVC devices when plugged into Linux 
> and they will need no special drivers. They also work on Windows. 
>
>
>
> > 
> > -- 
> > Manuel Braga 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "linux-sunxi" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to linux-sunxi...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Jon Smirl 
> jons...@gmail.com  
>

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

[jonsm...@gmail.com]

On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga  wrote:
> On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva
>  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".

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

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

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

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



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



-- 
Jon Smirl
jonsm...@gmail.com

-- 
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
 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] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

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

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

R

On Sunday, January 3, 2016 at 6:14:24 AM UTC-6, @lex wrote:
>
> Considering my level of skill, i believe getting a workable sample without 
> memory leaks first would benefit also this new cheap HW that is coming.
> Cheap HW, cheap (or a good) camera and a working HW encoding engine would 
> be more attractive to advanced developers and give a reason to the good 
> people who works on the ve reverse eng. to keep on going.
> This thinking may falls under the 100% *gratis* source driver not as an 
> option but a necessity.
>
> On Saturday, January 2, 2016 at 11:47:18 AM UTC-2, Rosimildo DaSilva wrote:
>>
>> Nove,
>>
>> I believe this community should take the ENCODER from a PoC level to a 
>> more or less demo similar to the one released by AW using the blobs
>> https://github.com/juanfont/cedar-encoder
>>
>> It is very important ( IMHO ), if it works with a modern AW soc, such as 
>> H3, since it is probably the most used SOC from AW, since the A20, with the 
>> release of OPI-PC, and now with the sub $10's release on the pipeline, they 
>> would be even more popular!
>>
>> http://www.cnx-software.com/2016/01/02/orange-pi-one-is-a-10-quad-core-board-with-ethernet-and-hdmi/
>>
>> I think starting from the initial demo provided by Jemk's for A20, it 
>> should not be terribly difficult to get it to work with H3
>> https://github.com/jemk/cedrus/tree/master/h264enc
>>
>> What is missing on this example to be similar to the example provided by 
>> AW, it lacks:
>>
>>+ motion detection
>>+ initial header info ( to be sent periodically ).
>>
>> Get this running on a H3 would be very useful to have a user base that 
>> might push the open source solution really the way to go
>>
>> R
>>
>> On Friday, January 1, 2016 at 7:08:30 AM UTC-6, Manuel Braga wrote:
>>>
>>> On Thu, 31 Dec 2015 02:49:02 -0800 (PST) Rosimildo DaSilva 
>>>  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

[@lex]

Considering my level of skill, i believe getting a workable sample without 
memory leaks first would benefit also this new cheap HW that is coming.
Cheap HW, cheap (or a good) camera and a working HW encoding engine would 
be more attractive to advanced developers and give a reason to the good 
people who works on the ve reverse eng. to keep on going.
This thinking may falls under the 100% *gratis* source driver not as an 
option but a necessity.

On Saturday, January 2, 2016 at 11:47:18 AM UTC-2, Rosimildo DaSilva wrote:
>
> Nove,
>
> I believe this community should take the ENCODER from a PoC level to a 
> more or less demo similar to the one released by AW using the blobs
> https://github.com/juanfont/cedar-encoder
>
> It is very important ( IMHO ), if it works with a modern AW soc, such as 
> H3, since it is probably the most used SOC from AW, since the A20, with the 
> release of OPI-PC, and now with the sub $10's release on the pipeline, they 
> would be even more popular!
>
> http://www.cnx-software.com/2016/01/02/orange-pi-one-is-a-10-quad-core-board-with-ethernet-and-hdmi/
>
> I think starting from the initial demo provided by Jemk's for A20, it 
> should not be terribly difficult to get it to work with H3
> https://github.com/jemk/cedrus/tree/master/h264enc
>
> What is missing on this example to be similar to the example provided by 
> AW, it lacks:
>
>+ motion detection
>+ initial header info ( to be sent periodically ).
>
> Get this running on a H3 would be very useful to have a user base that 
> might push the open source solution really the way to go
>
> R
>
> On Friday, January 1, 2016 at 7:08:30 AM UTC-6, Manuel Braga wrote:
>>
>> On Thu, 31 Dec 2015 02:49:02 -0800 (PST) Rosimildo DaSilva 
>>  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 02:49:02 -0800 (PST) Rosimildo DaSilva
 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
 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: allwinner-zh/media-codec demo

[Danny Milosavljevic]

Hi,

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

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

Regards,
   Danny

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