search

info-beamer / tools

Useful tools when working with info-beamer on the Pi
https://info-beamer.com/
33 stars 11 forks source link

Garbled image on omxplayer grid output #5

Open ephestione opened 7 years ago

ephestione commented 7 years ago

Hello and thank you for this extremely straightforward utility, now if only there was something that did the same thing but saved a video stream instead... but I digress ;) (if you know how to capture the HDMI output to video though, please do tell!)

I am using a setup where a combination of screen and omxplayer (as per this article) are showing a 2x2 grid of RTSP videos from 3 cameras, so the bottom right rectangle is dark. My cameras are Xiaomi XiaoYi Ants, and they output a 720p video which I can choose to be low or high bandwith (higher or lower compression).

They always display fine on the FullHD monitor the raspi is attached to (wifi allowing); if I use screenshot to grab the screen when all of them are on low quality, or just one is on high quality, the captured image is fine, but when I have 2 or all 3 streams in high quality, artefacts appear that do not show on screen, like the attached image clipboard01

(the date on top left is added from the original JPEG saved by screenshot by a PHP code with GD module, and the big white rectangles with red outline are crops I made for privacy reasons)

Do you have any idea about what might be going on? Altering compression ratio doesn't seem to change anything.

dividuum commented 7 years ago

Wierd. Haven't had that problem before. Can you paste the output of vcgencmd dispmanx_list?

dividuum commented 7 years ago

(Offtopic: The Pi isn't fast enough for HDMI capture of its own output. If you want an inexpensive solution you might use the LKV373. I've use it to capture the videos on the info-beamer page)

ephestione commented 7 years ago

Thank you for the fast reply (and for the pointer about the video capture!), here is my output for the command you pasted:

display:2 format:YUV_UV transform:0 layer:0 src:0,0,640,360 dst:960,0,960,540 cost:683 lbm:10240
display:2 format:YUV_UV transform:0 layer:0 src:0,0,640,360 dst:0,540,960,540 cost:683 lbm:10240
display:2 format:YUV_UV transform:0 layer:0 src:0,0,1280,720 dst:0,0,960,540 cost:1145 lbm:15360
dividuum commented 7 years ago

Nothing to see there, I guess. Can you try using raspi2png instead and see if that works despite using the same dispmanx API?

Are you using the latest firmware? (vcgencmd version)

ephestione commented 7 years ago

About the version:

Aug  8 2017 12:01:57
Copyright (c) 2012 Broadcom
version 196063438d7bb0769861c86f948ae653727adb7e (clean) (release)

And well, checked just now and raspi2png has the exact same artefacts I see on screenshot... might be something with video buffers or whatnot, since the output I pasted before was for the 1high+2low quality videos, while for all high quality videos the "cost" value is 1145 for all of them. Also, when there are two high quality videos and no low quality one (rtsp of that camera is temporarily off) I get no artefacts. As soon as the thirs stream, in low quality, appears, the artefacts start again, just like there is "too much stuff" on screen for the raspi to handle (?)

ephestione commented 7 years ago

I have no knowledge of the workings for this tool, but, in an analogy to what works in PHP, if you try and do a file_get_contents on a very large file, you may very well get a "not enough memory" error, while if you use buffers and read that same file progressivey with fread there is no such error. Probably it is possible to do the same with screenshot?

dividuum commented 7 years ago

If you do that, you'd probably snapshot across different frames which results in tearing.

I'd suggest you report this problem to the official pi issue tracker. I don't see any obvious ticket reporting the same problem.

ephestione commented 7 years ago

Elementary, Watson :) Will do, as a matter of fact I am doing that now and also linking this thread.

ephestione commented 7 years ago

Off Topic I know, but since I suspect you know more than you let show, and still regarding the "capture raspi's own hdmi output" question... for now I've managed by creating a screenshot every second, and running ffmpeg every two minutes to create an H264 video of those shots. Pretty simple, 80°C on the raspi for a few but it works out pretty well. I don't need 30fps HDMI capture, 2-3fps would be enough, and I think it would still be easier on the cpu (and especially on the SD card) than running screenshot every second to compress to jpeg -> move all files every two minutes to separate folder -> run ffmpeg to create video -> delete temp files. Would you have an idea about how to set ffmpeg to "latch" onto the full HDMI screen? Using the framebuffer device doesn't help.