On Wed, Mar 18, 2015 at 11:48 AM, Michal Suchanek <[email protected]> wrote: > Hello, > > as this does not seem to get any attention from anyone who has some > idea about VE I will try to write some high level info which is > hopefully not completely wrong. > > On 16 March 2015 at 14:44, Simos Xenitellis <[email protected]> > wrote: >> Hi All, >> >> I recently I had a conversation with Manuel about what can be done for >> better support for the video engine ("CedarX") that is found in the >> A-series of SoCs from Allwinner. >> >> The way I understood all these was that there are short-term and >> long-term goals for better support with the video engine. >> >> The long-term goal would be to support CedarX in Video4Linux2 (V4L2), >> as it is already described in http://linux-sunxi.org/VE_Planning >> It makes sense to have CedarX supported in V4L2 (Linux kernel) as it >> is part of the mainlining process of the Allwinner SoCs. >> There are some open questions that need discussion (such as >> feasibility, what resources are needed, etc). > > This is most likely feasible. If the current v4l2 framework cannot > work with cedar hardware it should be updated to work with it. > Existing hardware is undisputable reality. > >> In addition, it is important to describe the benefits from having >> CedarX support in V4L2 and especially when we should expect to have >> the first benefits when starting work on this. > > The benefit is that the v4l2 framework is a standard linux interface. > Presumably adding support for v4l2 on application side and writing > v4l2 driver on kernel side should be something you do once for good. > From then on the application should not be bothered by new hardware > codecs emerging and the codec drivers not bothered by new applications > emerging. Practically different applications use different features > and different codecs implement different features so there is always > room for finding new and exciting bugs everywhere. Also Cedar will > probably be one of the first VEs to have such driver. >
As it looks that this would be a difficult task, it would make sense to make a case that Allwinner may want to allocate resources towards this direction. The ability to perform hardware audio/video encoding and decoding even as soon as the Linux kernel boots up, from the A10 SoC and onwards, would be amazing. However, does a video engine driver in V4L2 offer any benefits on Android? In terms of projects and software that support V4L2, there are the least those at http://en.wikipedia.org/wiki/Video4Linux Many of those are for watching video on screen (i.e. HDMI output or LCD). Wouldn't there be a bottleneck with the current state of video drivers on Linux? For an application to encode video from USB cameras (or MIPI, if available/usable) and stream over the network, I suppose it can implement it directly (V4L2) or use some existing software library. It looks like there would be no big problems here apart from bottlenecks elsewhere (number of cameras sending data, ethernet/wifi bandwidth). The important message here would be that if the benefits are really great, then it would justify to put many resources. When looking at https://github.com/torvalds/linux/tree/master/drivers/media/platform (Manuel pointed me to these), there is already a driver for Samsung SoCs (dir: s5p-jpeg and s5p-mfc) and also a driver for the Coda video engine for Freescale SoCs (dir: coda). > Also related is that the v4l2 driver should share buffers with any > image postprocessing engine(s) and display engine(s) (such as the > sunxi KMS driver) and camera drivers using some kernel-wide buffer > management. Ideally, the buffers can be passed around by a handle > without the application using the drivers ever looking at them (unless > it has some actual use for the data) or the kernel copying them. > Hardware restrictions and driver defects may apply. > >> I would like to let Manuel to take over here, explain and expand on >> what his thoughts are. >> >> The short-term goals would be to use better what is available now, >> include libvdpau (anything needs fixing?) > > AFAIK the libvdpau is more proof of concept than a finished driver. It > is usable with mplayer and probably implements exactly the features > mplayer uses. Using it with other players may need implementing new > features. Also the output is always on top regardless of X11 window > stacking. This is because it programs the hardware directly. X11 > integration would require that the X11 driver programs the hardware > instead and figures out what to do when the video output is *not* on > top. All this using the obsolete Allwinner video driver. > Would it make sense then to just focus on V4L2? I did not find an initial driver for V4L2. I would think the first step would be to have a driver that just detects the presence of the video engine hardware and report any details that the hardware can provide. Simos -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
