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?
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: > ./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 > > 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]. For more options, visit https://groups.google.com/d/optout.
