On Sun, Mar 13, 2016 at 5:16 PM, Manuel Braga <[email protected]> wrote: > On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva > <[email protected]> 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 <[email protected]> >> 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 >> > <[email protected]> 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 <[email protected]> >> > > 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, [email protected] >> > > >> <[email protected]> wrote: >> > > >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex <[email protected]> >> > > >> > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
