Hi, Thank you for your reply,now I use android libs via libhybris and no pink video,But I have another question:I render the video use https://github.com/linux-sunxi/cedarx-libs/tree/master/libcedarv/linux-armhf/sample/render ,and the subtitles will shake,how to solve this problem?
BR 2014-12-12 16:49 GMT+08:00 Andreas Baierl <[email protected]>: > 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: >> ./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. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "linux-sunxi" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/linux-sunxi/pUpDunHdUgA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [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.
