[Video] The HD setup proposal

Paul Wayper paulway at mabula.net
Sun Jun 23 19:46:59 EST 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/23/2013 07:35 AM, Tim Ansell wrote:
...
> 2) Does it produce compressed video?
> 
> 
> It produces both; * mjpeg compressed video - Best for capture from a
> continuous source such as a camera. * raw video - Best for capture of
> non-continuous or text heavy sources, such as a presenter's slides.
> 
> Both are full 1024x768 or 720p resolution (depending on if the input is
> DVI or HDMI).
> 
> The problem is that USB2.0 doesn't have enough bandwidth for raw video
> at 30fps, so if you want the higher frame rate you have to use the mjpeg 
> compression mode.

Why not use the onboard 1gig ethernet?  That at least doubles your
throughput (assuming you're pegging the 480mbit of USB 2.0).

It might also eliminate the need for a computer to receive the webcam stream
off USB.  Each device simply boots up as a small Linux computer (Digilent
says that it supports PetaLinux), DHCP's to get a local address, and makes
its streams available on assigned network ports, similar to a dvsource.  All
you need is a discovery protocol and you could have a self-configuring LCA
recording network.

Aside: one of the things I didn't get around to, although I did try, was to
set up the master and slave laptops with DHCP.  They still all have manually
assigned addresses, because we were looking at this during the conference
when we didn't want to disturb anything (enough was breaking anyway without
further encouragement).  The aim was for each system to get a DHCP address,
have an internal hostname, and from there have a script which would either
pull its config based on its hostname from a given source, or (better)
generate it in a script.  Some day.

> At the moment raw mode is about 10-15fps while the target for mjpeg mode
> is a full 30fps/25fps (but we only get around 20ish at the moment, but
> that is a software problem with our  JPEG encoder core we hope to solve
> rather than a hardware issue).
> 
> The jpeg compression quality is controlled via a setting.

What options do we have for other codecs?  I'm assuming it's a Simple Matter
of Progrmaming, within the limitations of the hardware.

I say this because, long ago, I remember seeing a webcam that someone had
built that implemented Theora compression in an FPGA.  The limitation was on
the memory bandwidth, since it had to store inter-frame data and re-use it,
but that was with DDR-333 memory.  It was capable of doing 60 frames a
second at 640x480, IIRC.

But as well as that, I wonder about a really simple compression system for a
presenter screen: save the first image as PNG, then store timing information
until the next image change.  Since we're primarily talking about digital
streams - HDMI, DVI and DisplayPort - there's no analogue noise to worry
about.  A 'fuzz' factor could be used to ignore minor variations when
dealing with analogue input.  A more robust implementation of this could
output MNG or APNG.

Anyone out there want to conduct some experiments with this?  Even just
storing the image in RGB-run-length compression might work and be really fast.

Hope this helps,

Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHGxBMACgkQu7W0U8VsXYLTogCgmm7lRnZfbhtioqYX9YMm+2LM
R/EAoLIZq6Pd9AuNKYK/NAUztr+zqsSr
=F1aw
-----END PGP SIGNATURE-----



More information about the Video mailing list