[Video] The HD setup proposal

[Tim Ansell]

On 23 June 2013 19:46, Paul Wayper <paulway at mabula.net> wrote:

> -----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).
>

For raw video, even 1gbit is probably too slow - see
https://github.com/timvideos/HDMI2USB/wiki/Resolutions

Ethernet is way more complicated, either you go with a custom protocol on
top of raw ethernet and hence have to write complicated drivers or you
implement TCP/IP. The Ethernet chip is much more expensive than the USB
chip. There is also no standard for this.

A Linux computer is way more powerful than we could ever do in hardware,
they already exist and are ubiquitous (R-Pi, Beaglebone, Intel Laptop,
etc), hence we don't really want to reinvent that wheel.

Lastly, we hope that consumers who use Windows can use the device for their
own capturing needs too.

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.
>

There is thought about adding something like a R-Pi to a HDMI2USB into one
box and getting the above. Weather that ends up as a little plastic box or
a portable rack of some sort is still up in the air.


> 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.
>

Eventually we'll get to that.


> > 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.
>

It is a simple matter of programming and figuring out if you have enough
gates in the FPGA.

mjpeg has quite a few nice properties which make it ideal for this use case;
 * frames are independent - you lose one frame you just go onto the next
 * easy to implement in hardware
 * well understood


> 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.
>

60fps at 640x480 is pretty pathetic.


> 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.
>

MNG is dead. Only FireFox supports APNG. Web-P (which has animation) is
just supported by Chrome.

MJPEG is very common and used everywhere.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.org.au/pipermail/video/attachments/20130624/05230895/attachment.htm