Issues when decoding H264 streams with weighted P-frame prediction about cedarx-libs

[ssvb]

Spent a bit of time investigating the same issue. I wish I could find your bugreport earlier :) Added a link here from http://linux-sunxi.org/CedarXVideoRenderingChart

[wolfgar]

I reported this issue here, on http://linux-sunxi.org/CedarXVideoRenderingChart and on http://forum.xbmc.org/showthread.php?tid=126995&pid=1234463#pid1234463 6 months ago
And you are the first person to care ;-)
Anyway avoiding P-frame is not the solution. The solution would be to have a working cedarx library as we know the hw is OK...

[ssvb]

Well, not enough details (x264 has a bit different name for this encoding option) and a broken mediafire link for the sample itself introduced a bit of a challenge :)

Yes, the hardware is OK. However unless Allwinner provides an updated linux blob, we don't have many options. Trying to somehow use the android blob in linux (via libhybris?) is one of the things to test.

[wolfgar]

Sorry for the broken link : Of course it was valid when I submitted the issue...
(I fear details don't explain the lack of interest : I reported this issue pointing the root cause 6 months ago at 3 different places and nobody asked for details you know...)
Anyway you are right : the buggy binary blob prevents to fix properly the issue and, on my side, I moved to another platform with open source VPU decoding...
I fully agree with you : libhybris could be an interesting way to investigate as a workaround...

[rellla]

Because weighted_pred_flag is set in PPS, is it possible that init_data isn't set up the right way in the different linux ports?

[ssvb]

@rellla It looks like the PPS data gets properly passed to libvecore library. For example, testing cedarx vlc with the two files obtained via "x264 --weightp 0 -o testfile-good.mkv sintel_trailer-1080p.mp4" and "x264 -o testfile-bad.mkv sintel_trailer-1080p.mp4" shows that init_data pointer is set to a chunk of 43 bytes in both cases, with only one bit of difference (weighted_pred_flag):
0000000: 01 64 00 28 ff e1 00 1a 67 64 00 28 ac d9 40 78 .d.(....gd.(..@x 0000010: 02 27 e5 84 00 00 03 00 04 00 00 03 00 c0 3c 60 .'............<
-0000020: c6 58 01 00 06 68 eb e3 cb 22 c0 .X...h...".
+0000020: c6 58 01 00 06 68 eb a3 cb 22 c0 .X...h...".
`
And init_data buffer is not a meaningless garbage for libvecore in this case because overwriting it totally breaks decoding. So it still looks like the provided libvecore library blob is buggy.

[ssvb]

Android libraries loaded via libhybris are not affected by this bug. Verified with the blobs from allwinner-dev-team/android_external_cedarx@ef36cd7

The tested blobs are (sha1 sums):
b8b72d566e201007adee9beeef1578bd40c669b1 libcedarv_adapter.so 42c1e3fd8b5ffd25c8f2d016290dbf9d4d90c8c0 libcedarv_base.so d1a33914ba8c4ca2f86541f2caa4a1b98ef83035 libcedarxosal.so 358a1111e6c4de8752d9bb0633503ef1fd4492c3 libve.so

[ssvb]

Added some libhybris usage instructions - http://linux-sunxi.org/CedarX/libve

[wolfgar]

That is a very good news !
Thanks a lot for testing and sharing...

[ravageralpha]

Great news !!!

Is it possible port to XBMC on Linux with framebuffer ?

[techn]

@addison: It has been already done. http://linux-sunxi.org/XBMC .