2017-05-24, 10:45
I would like to open a new thread for my latest measurements as I changed the methodology quite a bit. Results are a bit more scientific now… hopefully… The measurement took quite some time to execute and calculate results. So hopefully the numbers are of interest to anybody...
Hardware:
Device: Sony BRAVIA 2015
SoC: MediaTek MT5890 (2x ARM Cortex A17 @ 1GHz, ARM Mali T624 MP2, 1.5GB RAM) (no speed-stepping)
OS: Android TV 6.0.1 (Linux kernel 3.10.79)
Video:
TransportStream sample with H.264 [email protected] 720p50 video (5-6mbps) and AC3 audio (via Passthrough if possible) played from an USB pen drive.
Methodology:
CPU usgage has been measured via top command with a resolution of 1s:
From 100 measurements, the average and maximum has been calculated for user- and kernelspace activity, plus the most demanding processes separately as well.
The device has been rebooted before moving to the new player. The measurement was started after all startup processes have finished work.
Results:
Kodi 18.0-bfeb2e9 (2017-07-17) - MediaCodec Surface (AMCS)
Recent builds reduced CPU usage by over 5% (3-4% on Kodi itself, 2-3% on surfaceflinger).
Problem with MediaCodec Surface is that for some videos there is a severe stutter every few seconds, seemingly dropping a hand full of frames every time (PlayerDebug OSD does not count any drops or skips though). If you play the same video over and over again, those stutters are always at exactly the same positions, see this thread. There is nothing fancy about the provided sample, only being 720p25.
You can easily break video timings by just producing some background load, like it is for example the case directly after a full boot with some maintenance tasks creating load for quite some time, resulting in juddery playback inside Kodi. At least the stock video apps do not suffer from this issue.
Kodi 18.0-bfeb2e9 (2017-07-17) - MediaCodec (AMC/EGL)
The 720p50 sample already suffers from stuttering in non-Surface mode on the weak MediaTek SoC. According to PlayerDebug OSD, frames are frequently being skipped in bursts. When overlaying menu OSDs, there are even frequent stalls, resulting in a still image with subsequent playback restart. So non-Surface mode has gotten worse with latest vpupdates (VideoBuffer concept) changes.
CPU usage is at 50% on average but can easily go above 80%. Going beyond 720p25 is a no-no in non-Surface mode. The problematic 720p25 video runs smoothly though. So the timing seems to be better in non-Surface mode. Higher resolution/framerate content is not feasible anymore though. AMCS mode is therefore a must on Sony/Philips Android TV sets.
SPMC 17.4-RC1-3295bca (2017-07-02) - MediaCodec Surface (AMCS)
With SPMC17 being based on Kodi Krypton, video player uses quite a bit more CPU compared to latest Leia nightlies.
Interesting thing is that problematic samples do not suffer from the jerky playback anymore despite SPMC using AMCS mode. Keep in mind that this has also been a problem with SPMC in previous versions (e.g. 16.7.0) and all recent Kodi releases (16/17), and is still present in latest Kodi 18 Leia nightlies.
VLC - MediaCodec Surface
The problematic video shows the same symptoms as when played inside Kodi with MediaCodec Surface being engaged.
The decoder can be switched to IOMX (libstagefright?) and between Surface and non-Surface modes. Neither does any mode allow screencaps to be taken nor do they fix the problematic videos. So I assume that playback always defaults to MediaCodec Surface.
Video (libstagefright?) - stock player app
All processes involved with playback stay well under 1% (e.g. surfaceflinger). The Video app might not be using MediaCodec, but most probably libstagefright instead. But it at least seems to be using Surface as it is not possible to take screencaps of the playing video. Also CPU usage suggests that.
The problematic videos play smoothly inside the Video app despite the supposed Surface usage.
MX Player - HW mode (MediaCodec Surface)
Interesting part about MX Player is that most CPU is consumed by the mediaserver process. MX Player process hardly consumes any CPU.
Screencaps are not possible (=Surface). Problematic videos also stutter when played via MX Player.
MX Player - HW+ mode (libstagefright?)
Screencaps are possible, so this is most probably a non-Surface mode. This one uses way less resources compared to Kodi though. Problematic videos play smoothly inside MX Player after engaging HW+ mode.
Hardware:
Device: Sony BRAVIA 2015
SoC: MediaTek MT5890 (2x ARM Cortex A17 @ 1GHz, ARM Mali T624 MP2, 1.5GB RAM) (no speed-stepping)
OS: Android TV 6.0.1 (Linux kernel 3.10.79)
Video:
TransportStream sample with H.264 [email protected] 720p50 video (5-6mbps) and AC3 audio (via Passthrough if possible) played from an USB pen drive.
Methodology:
CPU usgage has been measured via top command with a resolution of 1s:
Code:
top -n 100 -d 1The device has been rebooted before moving to the new player. The measurement was started after all startup processes have finished work.
Results:
Kodi 18.0-bfeb2e9 (2017-07-17) - MediaCodec Surface (AMCS)
Code:
User: 9% (peak: 22%)
System: 14% (peak: 23%)Code:
org.xbmc.kodi 9% (peak: 14%)
/system/bin/surfaceflinger 4% (peak: 5%)
/system/bin/mediaserver 2% (peak: 2%)Recent builds reduced CPU usage by over 5% (3-4% on Kodi itself, 2-3% on surfaceflinger).
Problem with MediaCodec Surface is that for some videos there is a severe stutter every few seconds, seemingly dropping a hand full of frames every time (PlayerDebug OSD does not count any drops or skips though). If you play the same video over and over again, those stutters are always at exactly the same positions, see this thread. There is nothing fancy about the provided sample, only being 720p25.
You can easily break video timings by just producing some background load, like it is for example the case directly after a full boot with some maintenance tasks creating load for quite some time, resulting in juddery playback inside Kodi. At least the stock video apps do not suffer from this issue.
Kodi 18.0-bfeb2e9 (2017-07-17) - MediaCodec (AMC/EGL)
Code:
User: 27% (peak: 45%)
System: 36% (peak: 49%)Code:
org.xbmc.kodi 28% (peak: 36%)
/system/bin/mediaserver 12% (peak: 14%)
/system/bin/surfaceflinger 7% (peak: 9%)The 720p50 sample already suffers from stuttering in non-Surface mode on the weak MediaTek SoC. According to PlayerDebug OSD, frames are frequently being skipped in bursts. When overlaying menu OSDs, there are even frequent stalls, resulting in a still image with subsequent playback restart. So non-Surface mode has gotten worse with latest vpupdates (VideoBuffer concept) changes.
CPU usage is at 50% on average but can easily go above 80%. Going beyond 720p25 is a no-no in non-Surface mode. The problematic 720p25 video runs smoothly though. So the timing seems to be better in non-Surface mode. Higher resolution/framerate content is not feasible anymore though. AMCS mode is therefore a must on Sony/Philips Android TV sets.
SPMC 17.4-RC1-3295bca (2017-07-02) - MediaCodec Surface (AMCS)
Code:
User: 15% (peak: 25%)
System: 17% (peak: 21%)Code:
org.xbmc.kodi 15% (peak: 21%)
/system/bin/surfaceflinger 7% (peak: 8%)
/system/bin/mediaserver 2% (peak: 3%)With SPMC17 being based on Kodi Krypton, video player uses quite a bit more CPU compared to latest Leia nightlies.
Interesting thing is that problematic samples do not suffer from the jerky playback anymore despite SPMC using AMCS mode. Keep in mind that this has also been a problem with SPMC in previous versions (e.g. 16.7.0) and all recent Kodi releases (16/17), and is still present in latest Kodi 18 Leia nightlies.
VLC - MediaCodec Surface
Code:
User: 12% (peak: 27%)
System: 19% (peak: 36%)Code:
org.videolan.vlc 10% (peak: 17%)
/system/bin/surfaceflinger 3% (peak: 4%)The problematic video shows the same symptoms as when played inside Kodi with MediaCodec Surface being engaged.
The decoder can be switched to IOMX (libstagefright?) and between Surface and non-Surface modes. Neither does any mode allow screencaps to be taken nor do they fix the problematic videos. So I assume that playback always defaults to MediaCodec Surface.
Video (libstagefright?) - stock player app
Code:
User: 1% (peak: 9%)
System: 4% (peak: 15%)All processes involved with playback stay well under 1% (e.g. surfaceflinger). The Video app might not be using MediaCodec, but most probably libstagefright instead. But it at least seems to be using Surface as it is not possible to take screencaps of the playing video. Also CPU usage suggests that.
The problematic videos play smoothly inside the Video app despite the supposed Surface usage.
MX Player - HW mode (MediaCodec Surface)
Code:
User: 5% (peak: 12%)
System: 5% (peak: 18%)Code:
/system/bin/mediaserver 6% (peak: 8%)
/system/bin/surfaceflinger 2% (peak: 3%)Interesting part about MX Player is that most CPU is consumed by the mediaserver process. MX Player process hardly consumes any CPU.
Screencaps are not possible (=Surface). Problematic videos also stutter when played via MX Player.
MX Player - HW+ mode (libstagefright?)
Code:
User: 7% (peak: 17%)
System: 20% (peak: 34%)Code:
/system/bin/mediaserver 7% (peak: 9%)
/system/bin/surfaceflinger 7% (peak: 7%)
com.mxtech.videoplayer.ad 4% (peak: 7%)Screencaps are possible, so this is most probably a non-Surface mode. This one uses way less resources compared to Kodi though. Problematic videos play smoothly inside MX Player after engaging HW+ mode.