linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Tomasz Borowczyk <tomboro88@gmail.com>
Cc: linux-media@vger.kernel.org
Subject: Re: cx231xx with 3 grabbers
Date: Sat, 18 May 2019 08:04:08 -0300	[thread overview]
Message-ID: <20190518080408.40b3822f@coco.lan> (raw)
In-Reply-To: <CAM+RvBRhG_Am=eGKog8a-rDAULrkNjKpbH+C+bqOk=wx5gXLJQ@mail.gmail.com>

Tomasz,

Please don't top-post. Makes very confusing to for people to follow
the discussions on mailing lists.


Em Sat, 18 May 2019 12:12:11 +0200
Tomasz Borowczyk <tomboro88@gmail.com> escreveu:

> wt., 14 maj 2019, 14:05 użytkownik Mauro Carvalho Chehab <
> mchehab+samsung@kernel.org> napisał:  
> 
> > Em Tue, 14 May 2019 00:18:31 +0200
> > Tomasz Borowczyk <tomboro88@gmail.com> escreveu:
> >  
> > > Hello linux-media.
> > >
> > > I use cx231xx driver with my August Vgb100 USB video grabber. It works
> > > great. It automatically detects my device and I can watch the video
> > > from analog camera on my Raspberry Pi, and I am very happy about how
> > > it works.
> > >
> > > But there is a catch. I want to connect 3 such cameras to my Raspberry
> > > Pi. When there are connected 2 of them, I can watch video from both of
> > > them without problems. When there are connected 3 adapters, I can
> > > watch the video from all three cameras, but the picture from one of
> > > them is flickering and blurring between blue screen and the correct
> > > data. And no matter in what order I connect them to the Raspberry, the
> > > problem exists always on the same adapter.
> > > The same problem exists when I connect the cameras to my laptop
> > > running Raspbian desktop.
> > > This could suggest that the one adapter is a little defective, but it
> > > works okay when there are connected only two adapters, or when it is
> > > the only connected. Also when I disconnect it and connect again to USB
> > > port, I can see correct image. But when I start to play picture from
> > > another camera, and then go back to the "defective" one, it flickers
> > > again. How can I find the reason of the problem?  
> >
> > The problem is related to the maximum bandwidth that an USB 2.0
> > provides. Most audio and video devices like cameras use an type of
> > USB package, called ISOC, with allows reserving bandwidth for them.
> > It actually reserves a number of USB slots. The maximum is 980 slots
> > per second, if I'm not mistaken.
> >
> > The actual number of allocated slots depends on the resolution,
> > format, package size, number of frames per second, etc.
> >
> > I don't have the numbers for cx231xx, but, with em28xx, a 640x480,
> > 16 bits per pixel, 30 frames per second video uses about 60% of
> > the available USB 2.0 bandwidth. So, even two cameras at full
> > res can be too much.
> >
> > I guess you can consider your self lucky to be able of having
> > two cameras working :-)
> >
> > If you need more than that, you'll need to use a machine with
> > multiple USB buses and connect each camera on a different
> > bus.
> >
> > Thanks,
> > Mauro
> >  
> Hello Mauro.
> Thank you for your quick reply. On Raspberry model B (1 core 700MHz) I can
> only watch 2 cameras with the resolution of 320x240 pixels. When I try to
> watch a single camera with full resolution, Raspberry hangs.

On Raspbian's Kernel, the USB driver uses an special high 
priority interrupt that takes precedence of everything else. I did some
tests in the past with that: the USB controller on RPi has only half of
the buffers than the same USB controller have on other similar hardware.
With that, the number of pending transfers is reduced. So, one came with 
a hack to make the USB interrupts to take precedence of everything else,
as otherwise it won't sustain USB 2.0 speeds.

Upstream didn't accept such change, and keeps using normal interrupts,
with is a lot safer, but it limits the USB maximum sustained transfer
rate.

> That's why I
> tried to run Raspbian on my laptop - just to check, if a stronger machine
> (Raspberry pi 3 for example) would be able to play it. On laptop I can
> watch a single camera at full resolution. I didn't try if I can watch more
> of them at once at full reslution, but you are right, at full resolution a
> single camera would consume almost all usb 2.0 bandwidth, and I didn't
> think about it beforehand. Just happy with result, I installed zoneminder
> on the laptop machine. 

Most laptops use a single USB bus shared on all their ports. This is
easy to verify: the lsusb command shows on what bus a device is connected.
If you can place the 3 cameras on different buses, it may work there
(or if you have an USB 3.0 hub and connect the hub to an USB 3.0 port,
and the cameras on it, it might work as well).

> Zoneminder allowed me to watch all three cameras,
> but only at 320x240 px. And on one of them the picture was defective, as I
> wrote on my earlier e-mail.

It is probably reducing the frame rate as well.

> Then I started more tests and it turned out,
> that when I have connected 3 grabbers, I can't see the correct picture
> always from this single grabber, even if I watch only this one at
> 320x240px. 320x240px needs less than one fourth bandwidth of the full
> resolution picture bandwidth, so I think, it should work if I play a single
> camera at once. But it looks like I'm wrong.

Not quite true. Remember: the real issue is the number of USB frames
that are allocated per second, and not the frame size. The USB spec
defines the maximum number of frames per second and says that ISOC can
only allocate 80% of it. If I'm not mistaken, that gives 960 frames per
second.

It doesn't matter if each frame has 4K bytes or 4 bytes.

On most devices, reducing the resolution also reduces the size of the
frames. It may or may not reduce the number of frames.

It also depends on USB alternate settings. On cx231xx, part of the
logic is at cx231xx_set_video_alternate(). Depending on the width
size, it switches from alternate settings  1, 2 or 3, with affects
the maximum data size the chipset will accept.

> 
> Nevertheless, it looks like that if I want to grab video from all of them
> at full resolution, I would need a single Raspberry Pi 3 per camera, but I
> must test it.

Yeah, either that or maybe some hat that would provide extra USB buses.

I suspect, however, that the USB hats you'll find will have just a single
USB bus with multiple USB 2.0 ports sharing the same bus. So you probably
can connect only a single camera there.

Without taking into account the limited speed and features of the CPU
found on RPi3, probably the only solution for using 3 cameras on a single
RPi3 would be:

	- 1 RPi Camera module using the special camera connector;
	- 1 USB camera to a RPi USB port;
	- 1 USB hat;
	- 1 USB camera connected to the USB hat.

I suspect, however, that its CPU won't have enough power to deal with the
amount of data transfers generated by such configuration and may hang
the RPi and probably corrupt the disk image.

Thanks,
Mauro

  parent reply	other threads:[~2019-05-18 11:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13 22:18 cx231xx with 3 grabbers Tomasz Borowczyk
2019-05-14 12:05 ` Mauro Carvalho Chehab
2019-05-18 10:20   ` Tomasz Borowczyk
     [not found]   ` <CAM+RvBRhG_Am=eGKog8a-rDAULrkNjKpbH+C+bqOk=wx5gXLJQ@mail.gmail.com>
2019-05-18 11:04     ` Mauro Carvalho Chehab [this message]
2019-05-19  9:43       ` Tomasz Borowczyk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190518080408.40b3822f@coco.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=tomboro88@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).