omxplayer and 4K

[njk1961]

Is it possible to play a 4K UHD movie using rpi2 and omxplayer?

I tried many configurations without success

Thanks in advance,
N

[elatllat]

no;
viewtopic.php?f=38&t=100625

you can get X11 @ 15Hz(pi1) or 28Hz(pi2) though;
viewtopic.php?f=38&t=79330

[njk1961]

Thanks for your answer, elatllat

But if I can get X working at 28Hz, why omxplayer doesnt work?

[6by9]

Just because the video scaler can render to a 4k display, doesn't mean all the other hardware multimedia blocks can
The video decode block is limited to a max of 2048 pixels wide.
Technically it is limited to h264 level 4.1, and that specifies the max number of macroblocks per second and per frame. Whilst macroblocks per second can be ignored if you don't need real-time, macroblocks per frame can't.

[njk1961]

Thanks, 6by9. Now I got it.

I was also looking at 3D resolution, so this explains why Full SBS would be impossible, right?
I was wondering if this was a ffmpeg limitation...

N

[6by9]

I was also looking at 3D resolution, so this explains why Full SBS would be impossible, right?
I was wondering if this was a ffmpeg limitation...

Yes, Full 1080P SBS would be 3840x1080, so exceeding level 4.1.
There's actually a line buffer in the hardware that limits the width of any image to (I believe) 2048, so even though Full 720P SBS would be < level 4.1 at 2560x720, I don't believe it would actually work. Full 720P top/bottom might have a chance.

I wasn't aware that ffmpeg used the hardware acceleration, so that should probably work, but very slowly.

[njk1961]

Well, if X can handle 4K resolution, I wonder if it would be possible to configure an fb console with 3840x2160 and execute 4 omxplayer playing full HD videos simultaneously, despite performance problems.

Do you think this could work?

[6by9]

Well, if X can handle 4K resolution, I wonder if it would be possible to configure an fb console with 3840x2160 and execute 4 omxplayer playing full HD videos simultaneously, despite performance problems.

It should run 4 instances, but they'll all be at <25% speed as the hardware block can do a little over 1080P30, and there will be some overhead in multiplexing streams.

[AndyD]

Well, if X can handle 4K resolution, I wonder if it would be possible to configure an fb console with 3840x2160 and execute 4 omxplayer playing full HD videos simultaneously, despite performance problems.

It should run 4 instances, but they'll all be at <25% speed as the hardware block can do a little over 1080P30, and there will be some overhead in multiplexing streams.

It appears that if you run four instances of omxplayer, the fourth one get the error message (e.g. this thread ... viewtopic.php?f=66&t=111197#p764365)

Code: Select all

tvservice-client: Failed to connect to TV service: -1

From memory I don't think this was a memory split problem. I have just confirmed this on a B+ I have at hand.

[njk1961]

I dont have a 4K tv at this moment to test, but RPI handled up to 7 omxplayers playing simultaneosly Full HD video in HDMI mode 32 (1920x1080@24)

I first tried 4 (2x2) omxplayers instances, no problem at all (despite the fact they were about 50% slower, as 6by9 had predicted)

nohup omxplayer --win 0,0,959,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 960,0,1919,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,540,959,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 960,540,1919,1079 bbb_sunflower_1080p_30fps_normal.mp4 &


Then I tried 6 (2x3) tiles:

nohup omxplayer --win 0,0,639,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,0,1279,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,0,1919,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,540,639,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,540,1279,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,540,1919,1079 bbb_sunflower_1080p_30fps_normal.mp4 &


When I tried 9 (3x3), the message AndyD mentioned appeared while trying to execute 8th tile

nohup omxplayer --win 0,0,639,359 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,0,1279,359 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,0,1919,359 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,360,639,719 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,360,1279,719 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,360,1919,719 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,720,639,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,720,1279,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,720,1919,1079 bbb_sunflower_1080p_30fps_normal.mp4 &


CPU was 96% idle
I am running a RPI 2 (Raspbian Jessie Lite image) with GPU_MEM=256
I have compiled omxplayer from the last commit on github (5-dec-2015)

overclocking wont help in this case.

Do you have any idea to get a better performance, or I am expecting too much from the GPU?

N

[AndyD]

Glad to hear you got them working. I wonder what I have been doing wrong.

[gkreidl]

I can easily display four SD videos without any problems, but as soon as I display more than one 1080p video I get periodic blanking of the whole display. And the videos are also running too slow.
So everything beyond one 1080p30 (or 1080p60 with an overclocked GPU) video is not possible with the RPi GPU.

[jamesh]

I dont have a 4K tv at this moment to test, but RPI handled up to 7 omxplayers playing simultaneosly Full HD video in HDMI mode 32 (1920x1080@24)

I first tried 4 (2x2) omxplayers instances, no problem at all (despite the fact they were about 50% slower, as 6by9 had predicted)

nohup omxplayer --win 0,0,959,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 960,0,1919,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,540,959,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 960,540,1919,1079 bbb_sunflower_1080p_30fps_normal.mp4 &


Then I tried 6 (2x3) tiles:

nohup omxplayer --win 0,0,639,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,0,1279,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,0,1919,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,540,639,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,540,1279,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,540,1919,1079 bbb_sunflower_1080p_30fps_normal.mp4 &


When I tried 9 (3x3), the message AndyD mentioned appeared while trying to execute 8th tile

nohup omxplayer --win 0,0,639,359 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,0,1279,359 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,0,1919,359 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,360,639,719 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,360,1279,719 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,360,1919,719 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 0,720,639,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 640,720,1279,1079 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer --win 1280,720,1919,1079 bbb_sunflower_1080p_30fps_normal.mp4 &


CPU was 96% idle
I am running a RPI 2 (Raspbian Jessie Lite image) with GPU_MEM=256
I have compiled omxplayer from the last commit on github (5-dec-2015)

overclocking wont help in this case.

Do you have any idea to get a better performance, or I am expecting too much from the GPU?

N

That surprising. I wonder if you can do that with different files? I would expect it to run out of bandwidth after two or three HD streams.

[6by9]

Well, if X can handle 4K resolution, I wonder if it would be possible to configure an fb console with 3840x2160 and execute 4 omxplayer playing full HD videos simultaneously, despite performance problems.

It should run 4 instances, but they'll all be at <25% speed as the hardware block can do a little over 1080P30, and there will be some overhead in multiplexing streams.

It appears that if you run four instances of omxplayer, the fourth one get the error message (e.g. this thread ... viewtopic.php?f=66&t=111197#p764365)

Code: Select all

tvservice-client: Failed to connect to TV service: -1

From memory I don't think this was a memory split problem. I have just confirmed this on a B+ I have at hand.

There are a limited number of client slots for the IPC to the GPU (known as VCHIQ). That limit is 4.
I don't believe you actually need to link into tvservice for your application, so a mod to omxplayer to remove whatever it does with tvservice should solve your problem. Memory says that calls to bcm_host_init also consume a slot, but I may be wrong there.

[6by9]

I dont have a 4K tv at this moment to test, but RPI handled up to 7 omxplayers playing simultaneosly Full HD video in HDMI mode 32 (1920x1080@24)

You may get slightly different results on an genuine 4k TV. The video scaler runs in real time and normally outputs directly to the HDMI pixel bitstream (not to memory). 4k will be running faster, so less time to compose everything.

I first tried 4 (2x2) omxplayers instances, no problem at all (despite the fact they were about 50% slower, as 6by9 had predicted)
<snip>
CPU was 96% idle
I am running a RPI 2 (Raspbian Jessie Lite image) with GPU_MEM=256
I have compiled omxplayer from the last commit on github (5-dec-2015)

overclocking wont help in this case.

Do you have any idea to get a better performance, or I am expecting too much from the GPU?

N

That surprising. I wonder if you can do that with different files? I would expect it to run out of bandwidth after two or three HD streams.

Failing on 8th video - again sounds like running out of VCHIQ service slots. I do have a vague recollection of the number being increased recently, which main explain why Andy saw it at 4 whilst you get 8.

ARM CPU load will be minimal as it is only doing the file access (probably cached as you're playing the same file each time), and container demuxing.
You're probably on the edge with only 256MB of GPU memory, but it depends on how many reference frames each file needs. "sudo vcdbg reloc" will tell you how much is in use/free whilst that lot is running.
As long as you don't want realtime decoding, there should be nothing beyond memory limiting the number of simultaneous decodes. Rendering them may hit limits of the output side (the display goes nasty and tears it you exceed the limit and the control code hasn't limited things appropriately). Even memory bandwidth will be heavily hit on 8 decodes at 1080P. Each frame is ~3MB, so each one you render is 71MBytes/s just for rendering @24fps. 9 being rendered is 640Mbytes/s. If decode can throw out 1080P60 with overclock (never tried it myself), that's another 178Mbytes/s. It adds up fast when dealing with raw video frames!

edit: there are options for GPU and sdram overclocking. Those may get a little more, but may compromise stability.

[gkreidl]

CPU idle at 96% looks also strange. I get between 20% and 28% CPU for just one 1080p video. Demuxing and audio decoding needs some resources.

[njk1961]

Made some more tests. I will try to answer all suggestions/comments in this post.

I was just trying to stress the GPU, I am not planning to run 9 full HD videos. 4 omxplayer with 480p or even 720p works perfectly here, without lags.

When I said I could run 7 omxplayer, the result was very, very slow, obviously.

Sorry for the long post.

N
--------------------------------------------
jamesh,

I downloaded 3 other full HD video and could play them simultaneously. I will try with more videos later, no disk space now.


nohup omxplayer -w --win 0,0,959,539 bbb_sunflower_1080p_30fps_normal.mp4 &
nohup omxplayer -w --win 960,0,1919,539 Gravity-1080.mp4 &
nohup omxplayer -w --win 0,540,959,1079 Guardians_Of_The_Galaxy-1080.mp4&
nohup omxplayer -w --win 960,540,1919,1079 MonsterUniversity-1080.mp4 &

$ omxplayer -i Guardians_Of_The_Galaxy-1080.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Guardians_Of_The_Galaxy-1080.mp4':
Metadata:
major_brand : isom
minor_version : 1
compatible_brands: isomavc1
creation_time : 2014-02-21 01:00:47
Duration: 00:02:33.47, start: 0.000000, bitrate: 2225 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 2102 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)
Metadata:
creation_time : 2014-02-21 01:00:04
handler_name : GPAC ISO Video Handler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 121 kb/s (default)
Metadata:
creation_time : 2014-02-21 01:00:50
handler_name : GPAC ISO Audio Handler
have a nice day ;)

$ omxplayer -i Gravity-1080.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Gravity-1080.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
creation_time : 2013-05-10 21:20:51
encoder : Lavf53.32.100
Duration: 00:01:34.23, start: 0.000000, bitrate: 2151 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 2022 kb/s, 23.98 fps, 23.98 tbr, 2997 tbn, 47.95 tbc (default)
Metadata:
creation_time : 2013-05-10 21:20:51
handler_name : VideoHandler
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 124 kb/s (default)
Metadata:
creation_time : 2013-05-10 21:20:51
handler_name : SoundHandler
have a nice day ;)

$ omxplayer -i MonsterUniversity-1080.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'MonsterUniversity-1080.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
creation_time : 2012-06-06 23:22:16
encoder : Lavf53.32.100
Duration: 00:01:08.62, start: 0.000000, bitrate: 2130 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 1998 kb/s, 23.98 fps, 23.98 tbr, 2997 tbn, 47.95 tbc (default)
Metadata:
creation_time : 2012-06-06 23:22:16
handler_name : VideoHandler
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default)
Metadata:
creation_time : 2012-06-06 23:22:16
handler_name : SoundHandler
have a nice day ;)

$ omxplayer -i bbb_sunflower_1080p_30fps_normal.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bbb_sunflower_1080p_30fps_normal.mp4':
Metadata:
major_brand : isom
minor_version : 1
compatible_brands: isomavc1
creation_time : 2013-12-16 17:44:39
title : Big Buck Bunny, Sunflower version
artist : Blender Foundation 2008, Janus Bager Kristensen 2013
comment : Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
genre : Animation
composer : Sacha Goedegebure
Duration: 00:10:34.53, start: 0.000000, bitrate: 3481 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 2998 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)
Metadata:
creation_time : 2013-12-16 17:44:39
handler_name : GPAC ISO Video Handler
Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo, s16p, 160 kb/s (default)
Metadata:
creation_time : 2013-12-16 17:44:42
handler_name : GPAC ISO Audio Handler
Stream #0:2(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side), fltp, 320 kb/s (default)
Metadata:
creation_time : 2013-12-16 17:44:42
handler_name : GPAC ISO Audio Handler
Side data:
audio service type: main
have a nice day ;)


---------------------------------------------

6by9:

I was thinking exactly like you said, I expect that it will run smoothly in 4K. Do you have any suggestions on how to tweak the GPU and SDRAM?


vcdbg while running 7 omxplayers

sudo vcdbg reloc

Relocatable heap version 4 found at 0x2f000000
total space allocated is 236M, with 236M relocatable, 0 legacy and 0 offline
0 legacy blocks of size 2359296

free list at 0x3bdfb380
1.6M free memory in 11 free block(s)
largest free block is 1.6M bytes

0x2f000000: free 1.6M
...
...


---------------------

gkreidl:

top output while running 7 omxplayers with same video

top - 13:24:11 up 12 min, 1 user, load average: 0.09, 0.19, 0.14
Tasks: 99 total, 1 running, 98 sleeping, 0 stopped, 0 zombie
%Cpu0 : 3.4 us, 2.0 sy, 0.0 ni, 94.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 5.2 us, 0.3 sy, 0.0 ni, 94.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 2.0 us, 2.7 sy, 0.0 ni, 95.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 2.4 us, 2.0 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 753228 total, 346844 used, 406384 free, 10380 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 124872 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1032 pi 20 0 142672 38496 14012 S 3.6 5.1 0:15.67 omxplayer.bin
1066 pi 20 0 141692 37636 14104 S 3.6 5.0 0:15.19 omxplayer.bin
1069 pi 20 0 141536 37816 14140 S 3.6 5.0 0:15.22 omxplayer.bin
1029 pi 20 0 150924 38916 14388 S 3.3 5.2 0:15.86 omxplayer.bin
989 pi 20 0 150272 38380 14320 S 2.3 5.1 0:16.64 omxplayer.bin
994 pi 20 0 151176 39432 14520 S 2.0 5.2 0:16.29 omxplayer.bin
1096 pi 20 0 142596 38644 14244 S 1.7 5.1 0:14.45 omxplayer.bin
1204 pi 20 0 5092 2512 2144 R 1.0 0.3 0:00.16 top
43 root 1 -19 0 0 0 S 0.7 0.0 0:05.05 VCHIQ-0
7 root 20 0 0 0 0 S 0.3 0.0 0:00.15 rcu_preempt

[6by9]

I was thinking exactly like you said, I expect that it will run smoothly in 4K. Do you have any suggestions on how to tweak the GPU and SDRAM?

Sorry, I have never played with overclocking - I'm too used to trying to keep everything vanilla so that it always works on the lowest common denominator.
A quick Google brings up a load of hits for suggested settings - just make sure you get one for the Pi2. http://linuxonflash.blogspot.ie/2015/02 ... mance.html looks pretty comprehensive, but that is not an endorsement by me!

vcdbg while running 7 omxplayers

sudo vcdbg reloc

Relocatable heap version 4 found at 0x2f000000
total space allocated is 236M, with 236M relocatable, 0 legacy and 0 offline
0 legacy blocks of size 2359296

free list at 0x3bdfb380
1.6M free memory in 11 free block(s)
largest free block is 1.6M bytes

0x2f000000: free 1.6M
...
...

That is probably your reason for the 8th one failing - 1.6M of heap left isn't enough. Increase your GPU memory allocation and you may be able to cram a few more in
There is a second heap that can be shown with "sudo vcdbg malloc". There are no controls over the size of that, but normally it is sufficient as it should never have to store any image buffers.