On Mon, 4 Jan 2016 10:57:41 -0800 (PST) Rosimildo DaSilva <[email protected]> wrote: > On Saturday, January 2, 2016 at 11:32:58 AM UTC-6, Manuel Braga wrote: > > > > On Sat, 2 Jan 2016 05:47:18 -0800 (PST) Rosimildo DaSilva > > <[email protected] <javascript:>> wrote: > > > Nove, > > > > > > I believe this community should take the ENCODER from a PoC level > > > to > > > > Who is this community? The same people that are here with zero > > support from the ones that have the most to benefit. > > > > Do you all expect from us to do all this huge work in this > > unfavorable conditions? > > > > > The community is sunxi. > > No, I don't expect a few developers to do all the work. But, if the > most skilled ones land a bare framework, more folks may help testing > and fixing bugs. > Ideally, AW should pay for such effort, but I would not hold my > breath waiting for AW to move in any way,
When allwinner has "trouble" into understanding the importance of respecting license of the software that is using, and to correctly license for distribution any proprietary binaries only software. Talking of "pay" is off-course it-not-will-happen. The "unfavorable conditions" and "no support" is not about begging for $$$. But sure, any serious business that recognizes value and wishes to have a more professional relationship, can choose to take this route. The other route, is to "support" and help in the creation of "favorable conditions" in which all this huge amount of work could be done at zero cost. Personally, i would liked very much to participate in the creation of this proper driver and would do this at zero cost (within my limits of available time). But with this unfavorable conditions, there are one thing that i can not accept, and that is, to get involved in hypothetical future "license issues" and be left alone in the task of enforcing the license of the source code that i had written. > > Maybe, someone like you ( nove or jemk ) could start a "kickstart > project" to bring "Media capabilities" to AW Soc's with a complete > open source stack. > I only see these community funded projects for some stupid peace of > H/W, and maybe someone should try to see how it works with S/W stacks. It would fail. The users that choose allwinner hardware, do it because of the price, to pay for software is unthinkable. To the users that sincerely would contribute to this, what i can suggest is to use their money to reward hardware vendors that do the right thing. > > > > > > > > a more or less demo similar to the one released by AW using the > > > blobs > > > > There are priorities and it arrives to a point in which we have to > > make a choice. We are here to make proper software, and the next > > step in this route is a proper driver for this video engine. > > > > But this will not happen tomorrow or in the next month, this is > > just not possible when this unfavorable conditions persist. > > > > > > > > > > It is very important ( IMHO ), if it works with a modern AW soc, > > > such as H3, since it is probably the most used SOC from AW, since > > > the A20, with the release of OPI-PC, and now with the sub $10's > > > release on the pipeline, they would be even more popular! > > > > If it is very important, why do we have zero support? Why isn't > > those hardware vendor and its users here asking for assistance? > > > > What can it be seen, is that in this last year events. not even a > > single discussion about the "license issues" in the forums of the > > random vendor. (expect one occurrence in a vendor blog) > > > > This shows the level of support and respect of the software that > > they are using. For this hardware vendors what they care is to sell > > the random board, and for that they only care about software the > > sufficient to fool the clueless user in giving them the money. > > > > For that, everyone is happy with an old kernel/uboot with random > > gpl violations and random license issues. > > > > With all this issues, with dumped old kernel trees that break api > > backward compatibility in every random soc release, it is very hard > > to offer adequate proper software. > > > > Look at the case of rockchip, in which its developers (full with > > rock-chips.com email) are contributing to the mainline kernel, that > > is not because one day they feel like to do this. But because of > > costumers that requested this kind of support, which google with > > its chromeos business is a direct cause. > > > > In allwinner world, this doesn't exist. > > > > > > > > > > > > I think starting from the initial demo provided by Jemk's for > > > A20, it should not be terribly difficult to get it to work with > > > H3.... https://github.com/jemk/cedrus/tree/master/h264enc > > > > If someone is in hurry to get something that works for the required > > user case, they are free to do those work themselves. > > We are here to offer help and assistance within our limits. > > > > > > > > > > > > What is missing on this example to be similar to the example > > > provided by AW, it lacks: > > > > > > + motion detection > > > + initial header info ( to be sent periodically ). > > > > > > > If someone wants for us to do this work, they must give us a > > *valid* reason, of why we should stop doing what we are doing now > > and prioritize this request. > > > > > I don't think it is a matter of prioritizing things... I see the > VDAPU approach by Jemk for the decoder as a *VALID* approach that > would validate the decode aspect of the H/W VPU, and more testing of > each decoder type... > > > If we do the same for an ENCODER, I mean: And that is what the proof-of-concept little simple programs are for, to prove (and validate) that we know how to use the hardware. > > > V4L2(in) --> ENCODER_CAPTURE --> FIFO( H264 initially ) > > This capture program could be used to feed ffmpeg or gstreamer, until > a proper mem2mem driver is completely written, You know about this? http://linux-sunxi.org/FFmpeg I never tried, so i can't say if it "works". But. We have two options: 1. work in a long term solution 2. work in a short term solution If option2 is chosen, that is time that is not spend doing the option1 As said, we need a valid reason why should be spent time (and the time that we have is spare) in option2. > > > > > > > > > Get this running on a H3 would be very useful to have a user base > > > that might push the open source solution really the way to go.... > > > > For that to happen, we need to have an user base that prefers a > > libre and open source solution first. > > > > Instead of a user base that prefers to run around a proprietary > > library binary blobs with a long history of license ambiguity > > issues. > > > > > I think users go for something that 'works'. I doubt they care one > way or the other, as long as it works. > > So far people don;t have gone one way or the other, since all choices > sucks big time. > I don't understand how can one of this choices be valid. In the same mode, i don't understand how can business that wish to stay lawful use a proprietary-binary-blob-library with license ambiguity issues, in any of their products. To let as disclaimer, that i don't have any problem againt the use of correctly licensed proprietary software in binary only form. -- 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.
