Am 12.12.2014 07:46, schrieb [email protected]:
Hi,
I use the library cedarx-libs play video in linux is a problem(such as
pinkish issue on A20), is there a successful case? about pinkish
issue,some of the videos, some are not,I think this problem is caused
by the sort of problem frames,some software encoded output is the sort
of support frame, and some do not support, I use avidemux software to
convert avi video to mkv, use cedarx-libs play is normal, there is no
pinkish issue,but most mkv files have this problem,can you tell me how
to solve this problem?
Hi,
as a workaround for the pink video, you can try to use the android libs
via libhybris:
http://linux-sunxi.org/CedarX/libve#Using_libhybris_wrapped_Android_libraries
There are this known bugs in allwinner blobs. But they aren't removeable
because of the closed source. And Allwinner themselves does not seem to
be willing to fix them and provide new libs ...
Regards
On Saturday, October 5, 2013 12:38:37 AM UTC+8, Patrick Wood wrote:
I'm starting this thread to document what is currently known about
the A20's cedarx decoder so it's all in once place. Some of this
has appeared elsewhere, but as parts of running threads that may
not be easy to pull coherent information from.
I've spent some more time playing with the decoder using various
libraries and tools:
libvecore blobs from https://github.com/linux-sunxi/cedarx-libs
<https://github.com/linux-sunxi/cedarx-libs>:
./libcedarv/linux-armhf/libvecore/libvecore.so
./libcedarv/linux-armhf2/vdecoder/libve/libvecore.so
Android 4.1 blob from an A20 mk802 stick (libhybris)
cedrus jpeg decoder from https://github.com/jemk/cedrus
<https://github.com/jemk/cedrus>
The most important, and most mysterious thing is the need to
disable caching for the video data on the A20 in order to get any
of these to work. This is consistent, as even the jpeg decoder
produces garbled results if the dcache is enabled (and it bypasses
all the blobs) and occurs on on both the 3.3.0 and 3.4.xx kernels.
It's mysterious because the A20's Android kernel doesn't disable
caching, and videos play just fine with the same blob that fails
with libhybris (note that I'll use the term "fail" to mean
"produces garbled output"). This means that something different
is going on with Android.
None of the blobs above are calling ioctl to flush the cache, and
I don't think it's very likely that the higher level Android video
player code is making ioctls on /dev/cedar_dev. That means
there's probabaly something different in the Android linux
kernel's initialization.
Another observation is the A20's video decoder cannot operate at
500MHz, notwithstanding the sun7i_cedar.c high water limit. In
fact, it cannot run reliably at 408MHz (jpeg test fails about 10%
of the time, and all videos experience small pixelation
anomalies). The A10's decoder also fails at 408MHz (jpeg-test
fails 100% of the time). Both the A10 and A20's decoders work
fine at 384MHz (but note: only one sample of each chip was
tested). The 320MHz limit in sun4i_cedar.c actually seems
reasonable for both devices.
Only the Android blob calls ioctl(IOCTL_SET_VE_FREQ), requesting
180MHz for all videos, regardless of resolution or frame rate
(okay, I didn't try a 1FPS video, but 24 and 30FPS both get
180MHz). (jpeg-test also calls it, but that's under our control.)
On the A10, mali and cedarx share the pll4 clock, requring careful
selection of the pll4 clock rate; on the A20, they currently share
this clock, but it the cedarx module could use pll8 (new to the A20).
Pat
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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.
