A20 CedarX experience

[Patrick Wood]

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

[jons...@gmail.com]

On Fri, Oct 4, 2013 at 12:38 PM, Patrick Wood <patric...@gmail.com> 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 asked Allwinner for a armhf build of the h264 encoder a few days
ago. I also asked them to update their examples to work on recent
kernels. The mail got forwarded around to a few people, not sure what
will happen.

Is there an armhf build of the h264 encoder? I couldn't find one anywhere.

Did Allwinner design Cedarx or did the license it?

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Jon Smirl
jons...@gmail.com

[Hans de Goede]

Hi,

On 10/04/2013 06:38 PM, 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.

You likely need to allocate the memory buffers used for the video
in and output as dma_coherent memory.

Regards,

Hans

[Patrick Wood]

On Friday, October 4, 2013 1:15:24 PM UTC-4, Jon Smirl wrote:

On Fri, Oct 4, 2013 at 12:38 PM, Patrick Wood <patric...@gmail.com> 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.

Did Allwinner design Cedarx or did the license it?

According to this:  http://linux-sunxi.org/Used_IP_cores, the cedarx core might be licensed from Synopsis.  I don't know what he based this conjecture on.

Pat

[Patrick Wood]

Hans,

Is this behavior different for the A10 and A20?  Because only the A20 seems to have this problem with the dcache.

Pat

[jons...@gmail.com]

If it was Allwinner developed IP we'd have a better chance at getting
the source code for it.

[Patrick Wood]

On Friday, October 4, 2013 6:29:32 PM UTC-4, Jon Smirl wrote:

On Fri, Oct 4, 2013 at 3:15 PM, Patrick Wood <patric...@gmail.com> wrote:
>
> On Friday, October 4, 2013 1:15:24 PM UTC-4, Jon Smirl wrote:
>>
>> On Fri, Oct 4, 2013 at 12:38 PM, Patrick Wood <patric...@gmail.com> 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.
>>
>>
>> Did Allwinner design Cedarx or did the license it?
>
>
> According to this:  http://linux-sunxi.org/Used_IP_cores, the cedarx core
> might be licensed from Synopsis.  I don't know what he based this conjecture
> on.

If it was Allwinner developed IP we'd have a better chance at getting
the source code for it.

Touche! 

[Patrick Wood]

On Friday, October 4, 2013 12:38:37 PM UTC-4, 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.  

Update: a recent commit to the jpeg-test and mpeg-test code in cedrus fixes the problem with the A20.  It was fixed by flushing the video buffer dcache via the  IOCTL_FLUSH_CACHE ioctl call prior to starting the decode (for each frame in the mpeg decoder).  While this tells us a bit about what's causing the garbled output elsewhere, it doesn't help us fix it for any of the video players, as none of the blobs makes this call, and libvdpau still seems to be a ways off.  I'm wondering whether I was wrong, and Allwinner modified some of the higher level code to flush the dcache between frames.  I don't have an instrumented Android kernel to see what sequence of calls they're making into the sun7i cedarx driver, however.

[Andreas Öman]

On Fri, Oct 4, 2013 at 9:16 PM, Patrick Wood <patric...@gmail.com> wrote:

Hans,

Is this behavior different for the A10 and A20?  Because only the A20 seems to have this problem with the dcache.

I've seen the same cache coherency issue on A10 when I used my own memory allocator for buffering packets in

the /dev/cedar mapped memory. My guess is just that when using the default "helper" libraries AW ship on top of libve.so 

those cache issues are not visible because of different cache structure on the A10 CPU.

For my player I've always needed to either flush cache or map it cache coherent in order for it to work correctly.

 

[Patrick Wood]

Thanks. That's a very interesting datapoint  I am thinking that instead of  pgprot_noncached, the cedarx driver should set the mmap data region pgprot_dmacoherent for both the A10 and A20.  What do you all think?

Pat

[Patrick Wood]

On Friday, October 4, 2013 2:15:06 PM UTC-4, Hans de Goede wrote:

This memory isn't allocated by the driver; it's passed into cedardev_mmap().

Which brings me to a question:  The memory allocated in ./drivers/media/video/videobuf-dma-contig.c when RESERVE_VE_MEM isn't defined comes from dma_alloc_coherent(); however, when RESERVE_VE_MEM is defined (and it currently is), the memory comes from the ve_start/ve_end region reserved in arch/arm/plat-sunxi/core.c via memblock_reserve() as specified by the "sunxi_ve_mem_reserve kernel" argument.  Shouldn't this memory be set dma coherent?  Could this be the reason android behaves differently from linux on the A20?

Pat

Regards,

Hans

[jons...@gmail.com]

I'm messing around trying to get a H264 encoder app to build, and I noticed this....

decode_api.c in several places

if(data_info->privateDataLen <= bufsize0) {

mem_cpy(buf0, data_info->privateData, bufsize0);

cedarx_cache_op(buf0, (buf0 + bufsize0), 1); //flush cache

}

if(data_info->uSize0 <= bufsize0) {

mem_cpy(buf0, data_info->pData0, bufsize0);

cedarx_cache_op(buf0, (buf0 + bufsize0), 1); //flush cache

}

else 

{

mem_cpy(buf0, data_info->pData0, bufsize0);

cedarx_cache_op(buf0, (buf0 + bufsize0), 1);

mem_cpy(buf1, data_info->pData0 + bufsize0, bufsize1);

cedarx_cache_op(buf1, (buf1 + bufsize1), 1);

}

cedarv_osal_linux.c

void cedarx_cache_op(long start, long end, int flag) { #ifdef USE_ION_MEM_ALLOCATOR ion_flush_cache(start, end - start + 1); #elif USE_SUNXI_MEM_ALLOCATOR sunxi_flush_cache(start, end - start + 1); #else cedarv_cache_range cr; cr.start = start; cr.end = end; if((unsigned long)(end - start) > 1024*1024*64) { LOGE("flush cache fail, range error!"); return; } //LOGV("flush start: 0x%x 0x%x len:%d",start, end, end-start); ioctl(cedarv_osal_ctx->fd, IOCTL_FLUSH_CACHE, &cr); #endif }

--
Jon Smirl
jons...@gmail.com

[Patrick Wood]

A patch to fix this problem with libcedarx was posted here: https://github.com/jemk/libcedarx.  The recent sunxi cedar merge of sun[457]i requires it to display videos properly on the A20.

Pat

[Patrick Wood]

On Sunday, October 6, 2013 3:02:57 PM UTC-4, Patrick Wood wrote:

On Friday, October 4, 2013 12:38:37 PM UTC-4, 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.  

Update: a recent commit to the jpeg-test and mpeg-test code in cedrus fixes the problem with the A20.  It was fixed by flushing the video buffer dcache via the  IOCTL_FLUSH_CACHE ioctl call prior to starting the decode (for each frame in the mpeg decoder).  While this tells us a bit about what's causing the garbled output elsewhere, it doesn't help us fix it for any of the video players, as none of the blobs makes this call, and libvdpau still seems to be a ways off.  I'm wondering whether I was wrong, and Allwinner modified some of the higher level code to flush the dcache between frames.  I don't have an instrumented Android kernel to see what sequence of calls they're making into the sun7i cedarx driver, however.

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.

Update2: a patch to libcedarx (https://github.com/jemk/libcedarx/commit/64e53faa404ccd2f5d728218c92214c3b914fa7f) now makes it call ioctl to flush the cache; this seems to fix the differences we've seen between the A10 and A20 decoders.

[lyc....@gmail.com]

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?

[Andreas Baierl]

Am 12.12.2014 07:46, schrieb lyc....@gmail.com:

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 linux-sunxi...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[achun liu]

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

--
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 linux-sunxi...@googlegroups.com.

[lyc....@gmail.com]

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.

[achun liu]

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.

--