2x 4k video in a grid

Hi,

I have 2 4k screens next to each other. I want them to show one video of 7680x2160. But I cannot upload a video due to a limit on 4k. Splitting into 2 videos of 4k results in files larger than 750MB and that is also a limit
How can we achieve this?

Kind regards

1 Like

How big are those files now? Maybe raising the limit yet again is viable.

Note that a single Pi will never be able to decode two 4K videos at the same time.

1 Like

To explain my setup further, I have 2x 4k displays with 2x Pi4’s. There are setup next to each other, horizontal (so no rotation), in a grid of 1 row x 2 columns.
Ultimately I want to show a video of 7680x2160 (2x 4k). How can I achieve this?

A video in 4k 60fps or even larger 2x4k will easily pass several GB’s, depending on the length. Maybe it is better to host the video locally and create something like a stream from it to the Pi’s.

But basically starting with a small video of 7680x2160 seems not to be possible at the moment.

It tried with a smaller video, but same aspect ratio of 2048x576 with all available wall packages. But that won’t play… Package ‘Media on freely arranged screens’ show only some flickering, and the package ‘Video Wall Image/Video Player’ shows nothing. Simple PNG file works well.

1 Like

The only way this might work at the moment is if you split the huge video into two 4K videos and then use a single setup for each Pi/display. You could use the HD Image/Video player and activate the [x] synced playback feature. As long as all setups have playlists with the exact same total duration, they will play in sync.

Steaming won’t work with synced playback. And right now there’s no package that supports playing videos/images from (for example) files on an attached USB stick. So the only way is to upload them as assets. How long are those videos? Multiple GB sounds massive and the current way assets are uploaded will probably limit what can be reasonable uploaded.

All video wall packages work by decoding the complete video and then showing only the relevant part on the screen. Even the Pi4 cannot decode 7680x2160, so it’s impossible to use the normal video wall players. You have to manually pre-split the videos to keep it manageable.

Very surprised by that. Can you link the setup so I might take a look?

1 Like

Will try that! Splitting into two is no problem, synced playing is the golden tip! Now we have only to solve the size part. I will let you know shortly.

I have a video of 6 minutes, exporting it with Premiere as 4K, 25fps, H.264 results in a file of 1,09GB. H.265 results in ~350MB for 6 minutes. So the current 750MB limit will be reached at roughly 15 minutes (depending on content of course and frame rate). What is best strategy for longer video’s? Separate on time? Or raising the limit?

1 Like

Basically this works. Now I have an issue that a monitor freezes. Not sure if this is related to synced playback or something else. How can I investigate?
I can take screenshots from the info-beamer console, telemetry is reported etc. Only the display shows one image (from the video).

Consistently? So is that reproducable, even after restarting? Does it stop as the start of the video? What happens if you assign that setup to the other Pi? Does it work there?

1 Like

I assigned it to another setup, nothing happens, assigned it back to the original setup, again nothing.
Now rebooted the device, the video is playing. It took some time for both devices to get in sync.

I will monitor what happens tomorrow!

1 Like

Ok, the same device is frozen now (again) on a different position in the video. Not at start or stop, just somewhere in the middle.
The device itself is still responsive, I can login via the webconsole as root etc.

1 Like

I guess the whole H265 is not 100% there yet. I’ll try to reproduce the problem locally tomorrow.

1 Like

The size in bytes (ls -la) is exactly the same as the original I created on my pc and the asset on the device. The sha265sum is also the same.
The creation date of the asset on the device is april 24, so it is a cached version and not downloaded this morning.

1 Like

Sorry, I’m not sure I’m following.

On the device (Pi4) there is the asset, named asset-641141fe65cea90adf13781a5495ec96-wallleft1.mp4. Locally on my PC I have the file WallLeft1.mp4, that is the original which is uploaded as asset to the info-beamer website.
Both files have the same size and same content (verified by the sha256 hash).
So conclusion the whole video is downloaded to the device (100%).

I responded to your suggestion about the ‘whole H265 is not 100% there yet’.

1 Like

Ah. Understood.

Sorry, I should have worded that better: “I guess the H265 decoder support isn’t 100% working yet”. Apologies for the confusion.

1 Like

Ok. But - to be complete, - friday the same video on the same device and setup played several times from begin to end.

1 Like

Rebooted the device and it is frozen again. Seems to be consistently within a few minutes.

1 Like

The left device is freezing. Now updated the playlist with the video for the right side, but with that video the device is also frozen.

1 Like

I tested the wallleft1 video and see that the video seems stuck at around 1:40 min into the video. I then tried to play it on VLC on a desktop machine and it seems that the scene is just frozen there until around around 2:15 when it transitions to another scene. Is that expected?

1 Like

At 2:15 there is a photo till 2:50. My VLC plays the video correctly from start to end.

1 Like

I cannot reproduce the issue yet on a local Pi4. I tried both the stable as well as the testing release of the OS and both played the video in a loop for 5 hours now. So I guess at least in theory it should work. Some differences I potentially see compared to your installation:

  • Can you switch to 1920x1080 display resolution temporarily and check if it works then?
  • Can you turn off synced playback and check if the videos at least loop using that setting?
  • If the video gets stuck, can you open a root terminal or ssh into the device and run pkill -usr2 info-beamer? This will cycle through the log level, in that case from 3 to 4. A logread -f should then output plenty of lines related to video decoding, if and only if the decoder is still doing something. If the log doesn’t contain lots of lines with [mmal hdr], the decoder is likely not running.
  • If it gets stuck, can you run sv i /service/info-beamer to restart the info-beamer process? Does that result in the playback working from then on?
1 Like