I know there exist also 2-3 threads about RK3288, but my intention is explizit to talk about the hw-acceleration, so I open this new thread...
At freaktab I wrote this post:
Quote:I tested 'Man of Steel' MKV (many action and dynamic) no a/v-receiver at 1080P@60Hz
Code:
File size : 20.0 GiB
Duration : 2h 23mn
Overall bit rate : 20.0 Mbps
Writing library : libebml v1.3.0 + libmatroska v1.4.1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 23mn
Bit rate : 17.9 Mbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.485
Stream size : 17.5 GiB (87%)
Writing library : x264 core 133 r2334 a3ac64b
Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=1.20:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
Audio #1
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 2h 23mn
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel count : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 655 MiB (3%)
Language : German
Default : Yes
Forced : Yes
skips:12 drops:12 PC:1
not so bad, but sometimes some micro-stutters AND what I'm wondering in is, that I get the same video quality with or without hw-acceleration (with the cpu-usage is 10-30% and without it is 30-80%)...
I also check it with '14-(Helix)-xbmc-20140911-7f2a4b1-master-armeabi-v7a' but the same video quality as SPMC...
The same file tested with 'Video' (no audio), 'Video Player' (no audio) and 'MX Player Pro v1.7.31' (I started them via ES File Explorer) is crisper! Not much, but I can see it. And it seams that the colours are also a little bit better.
I only have a short look at it, but it seams micro-stutter free...
and today this supplement:
Quote:I checked the same file at MINIX X8-H with latest minix xbmc (also by koying like the SPMC) and the same MX and get the same quality at both BUT also like the quality at SPMC at the R89... which means, in my eyes, the RK3288 with the right player wins AMD I hope, kodi will be able to support better hw-acceleration...
(I hope I'm right with the minix xbmc and koying)
And because of "...I hope, kodi will be able to support better hw-acceleration..." I open this thread here at this forum (I think a better place to discuss it as at freaktab
)
.
i will check asap how many drops with nuc
I think it NEED a new thread, because to talk about hw-acceleration without hw-relation is in my eyes really senseless...
But of cause every one who means/want to talk about MediaCodec or libstagefright is welcome to do so at the other threads...
(2014-09-15, 12:10)no_spam_for_me Wrote: [ -> ]I think it NEED a new thread, because to talk about hw-acceleration without hw-relation is in my eyes really senseless...
But of cause every one who means/want to talk about MediaCodec or libstagefright is welcome to do so at the other threads...
I don't think you really understand the technical dependencies here for Android.
XBMC/Kodi for Android uses MediaCodec and/or libstagefright API for hardware accelerated video playback on all Rockchip's SoC.
MediaCodec and/or libstagefright API are they only way for hardware accelerated video playback on any Rockchip's SoC.
You can not get hw-acceleration on RK3288 for Android without either using MediaCodec or libstagefright.
If you want to talk about hw-acceleration on RK3288 for Android then you are talking about MediaCodec and/or libstagefright API.
Why do you think those threads are pinned stickys in the Android forum?
Trust me here, you want to do is ask your initial question in the threads about MediaCodec or libstagefright depending what you use.
If you are having problems with hw-acceleration on RK3288 for Android then that problem is with MediaCodec or libstagefright API.
Regardless this belong in the Android subforum and not the hardware forum.
enlightening... thank you..
If it is only a question of the API, I have to ask, why work the stock player and MX at the system better than xbmc with hw using e.g. the libstagefright API AND why work xbmc with hw (also e.g via libstagefright API) at other systems better, if it is only a question of the API?
Maybe I, maybe you, I don't know which of us don't really understand the technical dependencies...
(2014-09-16, 02:22)no_spam_for_me Wrote: [ -> ]If it is only a question of the API, I have to ask, why work the stock player and MX at the system better than xbmc with hw using e.g. the libstagefright API AND why work xbmc with hw (also e.g via libstagefright API) at other systems better, if it is only a question of the API?
Of course it not only a question of the API.
Saying that the problem can only be with the API would be like saying a problem in computer to computer communication can only be related to the network-infrastructure and could not be an issue on the server-side or the client-side. With this analogy MediaCodec/libstagefright API being the network-infrastructure, the server-side being RK3288's codecs/firmware/hardware, and client-side being XBMC/Kodi's media player code.
It is of course much more complicated than that, just see
http://forum.xbmc.org/showthread.php?tid=203521&page=7
Quote:That industry standard API is called OpenMAX IL (Integration Layer), which is an open standard developed by the Khronos Group.
http://en.wikipedia.org/wiki/OpenMAX
https://www.khronos.org/openmax
So what the SoC manufacturers must do is just write low-level codecs implemented according to the OpenMAX IL component standard, and in theory multimedia applications like XBMC/Kodi will then be able to use that hardware codec implementation via OpenMAX IL's high-level API. Note though that OpenMAX IL does not have a standard API at this stage, so the codec libraries are custom implementations, and all these custom codec libraries are need to be supplied by the SoC provider such as Rockchip, Allwinner, Broadcom, Freescale, Samsung, etc. and even Nvidia, which most already supports OpenMAX IL on ARM or MIPS.
http://elinux.org/images/5/52/Elc2011_garcia.pdf
https://developer.qualcomm.com/blog/medi...comparison
http://processors.wiki.ti.com/index.php/...ment_Guide
That codec library for OpenMAX can be binary only so that way the SoC manufacturers can hide their secret sauce if they want, as even if kernel code is open source the codec library for OpenMAX can still be closed source. So this is comparable to Nvidia's VDPAU and AMD's XvBA.
Example 1 for Android: https://source.android.com/devices/media.html
I was just trying to simplify it for you just to try to get you to understand that the everything related to hardware video decoding on the XBMC/Kodi-side for RK3288 on Android is still only discussed today in
http://forum.xbmc.org/showthread.php?tid=175626 and
http://forum.xbmc.org/showthread.php?tid=168268
The main points I was trying to get get across was that this discussion does not belong in the hardware subforum and should instead be in the Android subforum, and that the discussion about this have been consolidated there into those two threads.
Anyway I'm giving up on this thread now as it sounds to me that you just don't want to listen and help us help you.
There's already a PR pending to add H.265 support to both the Libstagefright and MediaCodec API's, see
https://github.com/xbmc/xbmc/pull/5374, so RK3288 should be fully supported once that's in.