Hi, How to run allwinner encoder/decoder at the same time?I try to run a decoding demo, then run a encoding demo, encoding demo will encode error, the decoding demo will be blocked.I run on A20 linux.
BR, Lyric. 2015-02-28 16:33 GMT+08:00 <[email protected]>: > hi, > > I modified a a20 encoder demo, but the output file have green noise, who > knows what reason? source code and encode file them in Annex. > > On Saturday, October 5, 2013 at 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 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.
