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, 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. > > > 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: 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, > > > > 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. R > > -- > 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.
