Hi,
I am a new owner of the Raspberry Pi 2 and has just installed OSMC yesterday and updated. I noticed that in the System Information section, it only shows that I have 733 MB of total memory despite the Pi 2 having a gig (Raspbian’s task manager, for instance, shows 927 MB of total memory). I was just wondering if this is expected behavior or if there is something wrong with my installation.
It does not seem to affect video playback or anything, but it is annoying if it can’t use all of the available RAM that is there if it ever needs to. I do notice that the videos I play (local H264 720p .mkv files) has much more artifacts than if I play them through WMP/MPC without any filters on Windows, but is this just hardware limitations or is there some setting that affects the quality of the video being played back? Please let me know if there is any way to improve this.
Screenshots:
OSMC: http://imgur.com/a/MWsSb
WMP/MPC: http://imgur.com/a/6jts7
Any feedback is appreciated. Thanks!
256MB is allocated to the GPU with OSMC on Pi 2.
Because only 64MB is allocated to the GPU on Raspbian
Sam
1 Like
This is an example of the memory split on my 512mb pi
14:43:22 1338.369385 T:3023462960 NOTICE: Raspberry PI firmware version: Aug 3 2015 14:56:05
Copyright (c) 2012 Broadcom
version 4b51d81eb0068a875b336f4cc2c468cbdd06d0c5 (clean) (release)
14:43:22 1338.369751 T:3023462960 NOTICE: ARM mem: 368MB GPU mem: 144MB MPG2:0 WVC1:0
Your 1GB Pi 2 has a similar split, with about 256mb dedicated to the GPU. This is expected. Really as far as artifact, seeing the mediainfo on the files that demonstrate the issue, some setup info as described in my support request sticky, and accompanying debug logs would be necessary to determine the issue.
1 Like
Thanks for the clarification in regards to the memory. That makes perfect sense. Some setup info:
Device: Raspberry Pi 2 B
Installation media: MicroSD (SanDisk Ultra 32 GB Class 10)
Connection: Wifi
Power Supply Type: Part of the Vilros package
Power specs: 5v===2000mA
Peripherals: All USB devices are on a powered USB hub (Plugable 4 port hub)
Storage Device (incl. Network Sharing Protocol): Local/USB
OSMC version:July 2015 2015.07-1
XBMC version: Kodi RC1
Codecs: N/A
Audio/Video Output: HDMI
Overclocked: No (tried turbo mode but made no noticeable difference)
Config.txt Extras: N/A
Link to Logs: http://paste.osmc.io/huqanahiqu
I’m not entirely sure how long I was supposed to let the video run when logging, so I just logged the first few seconds of the video in the beginning (which corresponds to the reproduction of the first screenshot of the video I posted). Let me know if you need any more info or a more detailed way to log this. I uploaded all the logs as I am not sure which are helpful to you.
Below is the mediainfo on the file that I used for the test, but the issue isn’t limited to this file. The file is located on the microSD card (local) when played back on OSMC. The mediainfo text below is generated from my Windows machine (as it was easier to obtain and use mediainfo there than through OSMC).
General
Unique ID : 188494771600400028246958043586054597587 (0x8DCEC5C27745F0A8ABE6016E0DB82BD3)
Complete name : D:\Ein\Desktop\Code Geass\(Hi10)_Code_Geass_R1_-_01_(BD_720p)_(OZC-EZ8).mkv
Format : Matroska
Format version : Version 2
File size : 135 MiB
Duration : 24mn 8s
Overall bit rate : 783 Kbps
Encoded date : UTC 2012-07-03 16:38:16
Writing application : mkvmerge v4.9.1 ('Ich will') built on Jul 11 2011 23:53:15
Writing library : libebml v1.2.1 + libmatroska v1.1.1
Attachements : APANRG.TTF / FLAMENN.TTF / Gabrielle.ttf / ITCKabelStd-Medium_0.otf / LEVIBRUSH.TTF / LLCHARLO.TTF / PALETTEN.TTF / Quirkus B.ttf / Quirkus BI.ttf / Quirkus I.ttf / Quirkus.ttf / segoepr.ttf / segoeprb.ttf / simpbdo.ttf / simpo.ttf
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L5
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 8s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Writing library : x264 core 125 r2200 999b753
Encoding settings : cabac=1 / ref=16 / deblock=1:1:2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 24mn 8s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Default : Yes
Forced : No
Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : English Subtitles
Language : English
Default : Yes
Forced : No
Menu
00:00:00.000 : :Prologue
00:01:42.102 : :Opening Credits
00:03:12.192 : :Part 1
00:13:11.791 : :Part 2
00:22:37.356 : :Ending Credits
Thanks for all the help. I appreciate it.
Out of spec for Raspberry Pi I’m afraid. Plus it’s 10-bit.
Sam
1 Like
Thanks for the clarification! I figure it was a hardware limitation. I’m actually surprised the Pi played both of the test videos I tested on it without any hitches outside of the artifacts since both test videos are 10-bit 720p videos. Playback was smooth and in-sync and skips/seeking work perfectly fine. I could’ve sworn I saw a blurb somewhere about the Pi 2 being way too weak for 10-bit.
Is there a listed “recommended” specs for video files for OSMC?
Pretty crude but there are some here;
Some more comprehensive info here;
http://kodi.wiki/view/Raspberry_Pi_FAQ#Formats
1 Like
10 bit encodings are unsuitable for any hardware decoder. So any device that relies on hardware decoding will struggle to play a 10 bit file unless the CPU is fast enough to do all the decoding in software.
A Pi 1 definitely cannot, a Pi 2 might be able to manage on 720p material, especially if you have updated to Isengard which now supports multi-threaded software decode when falling back automatically from hardware decoding.
(In Helix you had to manually disable hardware decoding to allow multi-threaded software decode - otherwise 3 of the Pi 2’s 4 cores would not be utilised)
Yep, I do have a Pi 2 and have updated to Isengard. Interestingly, I just tested multiple different 10-bit (High 10@L5.0) 1080p H.264 mkv files that I had lying around (for science!) and it’s playing perfectly fine like the 720p vids in my initial testing. Playback is smooth and in-sync, even after fast forwards and seeking. Like the 720p vid, the only problem is artifacts in certain scenes, but it’s usually not bad at all, definitely watchable (from what I’ve seen over a sample of ~7 videos, the artifacts aren’t worse then the screenshot that I’ve already posted and only occur briefly in certain scenes), although obviously not ideal.
Maybe my vids aren’t the highest spec 10-bit 1080p vids, but it seems the Pi 2 can mostly handle them. In fact, when the vid is playing, if I go to System Info or enable debugging, it shows it is barely using the CPU and memory. Not sure if this is a bug in display though. As mentioned, my Pi 2 isn’t even overclocked either, although I tried doing this without seeing any differences.
The Pi just feeds 10-bit h.264 through its 8-bit h.264 hw decoder.
In a 10-bit h.264 file most macroblocks are encoded as 8-bit blocks so they actually decode correctly.
You can see the 10-bit blocks as the blocks with artefacts. They are typically quite rare, but due to frames being used as references to subsequent frames the effects of the artifact can last a few seconds (the corruption spreads out until the next keyframe).
You can disable omxplayer and mmal and you will get perfect software decode. However even a Pi2 won’t handle 720p. I suspect around SD may work.
1 Like
Thanks for the info. This is all good stuff. For science, I disabled both omxplayer and mmal, and again, to my surprise, both of the 720p video including the one I posted the mediainfo of above plays! There is a tiny lag in transitioning scenes and I suspect animation heavy/higher bitrate scenes will be out of the question, but otherwise it actually plays fine and without the artifacts to boot! (the video does catch up and make up for the laggy parts so it only lags on those scenes) Attempts to seek/fast forward will freeze the video and I have to quit with X, but pausing and resuming seems to work ok, so if your 10 bit video isn’t too action intensive, it may actually run! 1080p 10 bit without acceleration is out of the question though, the audio is fine, but the video runs like a slideshow.