23 replies to this topic

[Dean]

I don't have Vu+ receiver yet but I am considering several VU+ models and I need fast frame grabbing (at least 10fps, not counting saving the file to disk) to achieve some functionality I need. So I would appreciate if I could get answer to some of these questions:

 

1) Are SE/SE2 receivers even supported? Grepping the source code for 7429 gives me no results.

 

2) How reliable is frame grabbing for VU+ Solo, Solo2, Duo2, etc and what is the frame rate (not counting time it takes to save the file to disk)? Looking at the code pointer is set to predetermined memory position and it is read directly from there. What implications does this have for reliability of the frame grabbing? Do you often  get partial frames, or two frames mixed into one?

 

2) If you have Vu+ Solo 4k what is your experience? Unlike for most other VU+ receivers for this one video is captured by reading from "/dev/dvb/adapter0/video0".

 

Here is the relevant code:

 

https://github.com/O...2027d1cca448109

 

What implications does this have for speed and reliability of the frame grabbing?

 

Also unfortunately resolution is always set to 1920x1080, and this hasn't changed to this day. Is there at least a way to detect SD capture? For example are pixels outside of the SD resolution crop always black?

 

Thanks in advance

[Dean]

I would appreciate if I could get answer to any of these questions. Since likely very few people have experience with all these receivers please answer any question you know the answer to, even if it is just one. The same question applies to enigmalight plugin as well, because it is using aio-grab code for capturing current frame.

Edited by Dean, 9 June 2016 - 00:56.

[mx3L]

Hi, I have vusolosev2

 

1.) Yes, grab utility works

2.) I just did a few tests and there looks to be no problems.

 

Here are some tests, maybe you have better idea how to test it:

 

100.sh

#!/bin/bash
for i in `seq 1 100` ; do $@ ; done

grabbing SD video only, 100 times as fast as possible:

root@vusolose:~# time ./100.sh grab -v -q
real    0m 11.00s
user    0m 8.00s
sys     0m 1.54s

grabbing HD video only, 100 times as fast as possible:

root@vusolose:~# time ./100.sh grab -v -q
real    0m 32.65s
user    0m 37.49s
sys     0m 5.70s

If you grab only video, resolution of resulting picture is same as video's, so SD video -> SD picture.

Edited by mx3L, 9 June 2016 - 06:45.

[Erik Slagter]

The frame grabbing is implemented by a very crude "peeking from memory" method that has been completely reverse-engineered. No official, open, documentation exists on this subject. So, yes, it seems to work, but zero guarantees. For one you will have tearing because there is no synchronisation with the vsync at all. And afaik none of the SoC's are fast enough to read the frame buffer in real time. Maybe the VU+ Solo4k's ARM processor, but rather not count on it.

[Dean]

Thanks to both!

 

I am not worried about tearing but only 3 fps for HD channel is a bit slow for what I wanted to do. Writing the file to disk is likely the bottleneck but hard to tell how much faster it would be without it.

 

Can someone with 4k please perform the same test? Would really appreciate it.

Edited by Dean, 11 June 2016 - 16:58.

[athoik]

UHD
 

root@vusolo4k:/var/volatile/tmp# time ./100.sh grab -v -q
real    0m 11.81s
user    0m 1.53s
sys     0m 6.25s

FHD

root@vusolo4k:/var/volatile/tmp# time ./100.sh grab -v -q
real 0m 11.00s
user 0m 0.76s
sys 0m 6.79s

Edited by athoik, 11 June 2016 - 17:09.

[Dean]

Wow that was fast!  Thanks a lot. 4k is significantly faster there.

 

To eliminate writing to disk part from the benchmark do you guys mind deleting lines 638 to 768 in grab's main file and then recompiling it? Or alternatively just download the code from this post.

 

Attached Files

•  aio-grab-master.zip   39.7KB   8 downloads

[MiLo]

It writes to RAM anyway... It can also write to stdout by the way, so you can use the resulting image directly.

I built a grab library for the amBX plugin a few years ago, based on aio-grab code, which was intended to be called from a plugin or so, and it's much faster because it doesn't need to allocate/deallocate resources on each call. Should still be on sourgeforge.

[Pr2]

athoik can you please check the resolution of the grabbed UHD image?  Because when I grab here I only have a 1920x1080 image and not a real UHD grab.

[athoik]

I guess it will always be 1920x1080 when grabbing video.
 

	if (stb_type == BRCM7366ARM)
	{
		int fd_video = open("/dev/dvb/adapter0/video0", O_RDONLY);
		if (fd_video < 0)
		{
			fprintf(stderr, "could not open /dev/dvb/adapter0/video0");
			return;
		}

		ssize_t r = read(fd_video, video, 1920 * 1080 * 3);
		close(fd_video);
		*xres = 1920;
		*yres = 1080;
		return;
}

Although grabbing from videoX device seems better way to me.

Attached Files

•  screenshot.zip   2.43MB   11 downloads

[Dean]

It writes to RAM anyway... It can also write to stdout by the way, so you can use the resulting image directly.

I built a grab library for the amBX plugin a few years ago, based on aio-grab code, which was intended to be called from a plugin or so, and it's much faster because it doesn't need to allocate/deallocate resources on each call. Should still be on sourgeforge.

 

You're right. And my goal is to write a plugin as well. Do you recall aprox. how many frames you could grab per second? And on what hardware.

Edited by Dean, 11 June 2016 - 20:49.

[Dean]

I guess it will always be 1920x1080 when grabbing video.
 

	if (stb_type == BRCM7366ARM)
	{
		int fd_video = open("/dev/dvb/adapter0/video0", O_RDONLY);
		if (fd_video < 0)
		{
			fprintf(stderr, "could not open /dev/dvb/adapter0/video0");
			return;
		}

		ssize_t r = read(fd_video, video, 1920 * 1080 * 3);
		close(fd_video);
		*xres = 1920;
		*yres = 1080;
		return;
}

Although grabbing from videoX device seems better way to me.

 

 

Yeah resolution is hardcoded for Solo 4k unlike for some other receivers.

[Dean]

I am really interested if 4k is  grabbing framebuffers faster or perhaps athoik just has a faster hard drive. It seems that accessing the video buffer directly has a potential of being faster despite overall hardware being slower.

 

Also does anyone know if it would be be possible to grab only part of the frame with Solo 4k? With other VU+ receivers that is easy since you have a pointer. On 4k one would need to use lseek/fseek, assuming stream supports that.

 

My end goal is to write a plugin that removes static parts of the video to avoid image retention/burn-in on OLED and plasma TVs. I need it for my personal use but I'll of course also share it with everyone else.

Edited by Dean, 11 June 2016 - 21:15.

[Dean]

It writes to RAM anyway... It can also write to stdout by the way, so you can use the resulting image directly.

I built a grab library for the amBX plugin a few years ago, based on aio-grab code, which was intended to be called from a plugin or so, and it's much faster because it doesn't need to allocate/deallocate resources on each call. Should still be on sourgeforge.

 

By the way allocation and deallocation shouldn't be that much of a bottle neck, malloc is probably reusing the same buffer. Writing to HDD should be a big bottle neck though, HDD and even SSD are many times slower than RAM. athoik do you have SSD by any chance?

[athoik]

It writes screenshot to /tmp (ram). So much faster than SSD.

[malakudi]

VU+ Solo2, HD and SD

 

root@vusolo2:~# date ; for i in {1..100} ; do grab -v -q -s >/dev/null ; done ; date

Sun Jun 12 00:06:03 EEST 2016

Sun Jun 12 00:06:42 EEST 2016

root@vusolo2:~# date ; for i in {1..100} ; do grab -v -q -s >/dev/null ; done ; date

Sun Jun 12 00:08:35 EEST 2016

Sun Jun 12 00:08:46 EEST 2016

 

39 seconds for HD, 11 for SD

[WanWizard]

That doesn't really work here:

root@et10000:~# date ; for i in {1..100} ; do grab -v -q -s >/dev/null ; done ; date
Sat Jun 11 22:15:30 IST 2016
Sat Jun 11 22:15:30 IST 2016
root@et10000:~# date ; for i in {1..100} ; do grab -v -q -s >/dev/null ; done ; date
Sat Jun 11 22:16:17 IST 2016
Sat Jun 11 22:16:17 IST 2016

either that, or it's lightning fast (first SD, second HD)

[Dean]

It writes screenshot to /tmp (ram). So much faster than SSD.

 

Is /tmp using ram by default?

[betacentauri]

Yes, it's by default a tmpfs filesystem.

[malakudi]

@WanWizard: You need to have bash installed as default shell (which I have). With busybox sh use:

 

date ; for i in `seq 1 100` ; do grab -v -q -s > /dev/null  ; done ; date

 

edit:

 

Edision OS Mini

49 seconds for HD

14 seconds for SD

Edited by malakudi, 12 June 2016 - 13:07.