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 <simos.li...@googlemail.com> 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.
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.
HTH
Michal
--
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.
