<div dir="ltr">On 23 June 2013 19:46, Paul Wayper <span dir="ltr"><<a href="mailto:paulway@mabula.net" target="_blank">paulway@mabula.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>On 06/23/2013 07:35 AM, Tim Ansell wrote:<br>
...<br>
<div class="im">> 2) Does it produce compressed video?<br>
><br>
><br>
> It produces both; * mjpeg compressed video - Best for capture from a<br>
> continuous source such as a camera. * raw video - Best for capture of<br>
> non-continuous or text heavy sources, such as a presenter's slides.<br>
><br>
> Both are full 1024x768 or 720p resolution (depending on if the input is<br>
> DVI or HDMI).<br>
><br>
> The problem is that USB2.0 doesn't have enough bandwidth for raw video<br>
> at 30fps, so if you want the higher frame rate you have to use the mjpeg<br>
> compression mode.<br>
<br>
</div>Why not use the onboard 1gig ethernet? That at least doubles your<br>
throughput (assuming you're pegging the 480mbit of USB 2.0).<br></blockquote><div><br></div><div>For raw video, even 1gbit is probably too slow - see <a href="https://github.com/timvideos/HDMI2USB/wiki/Resolutions">https://github.com/timvideos/HDMI2USB/wiki/Resolutions</a></div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><div>Lastly, we hope that consumers who use Windows can use the device for their own capturing needs too.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It might also eliminate the need for a computer to receive the webcam stream<br>
off USB. Each device simply boots up as a small Linux computer (Digilent<br>
says that it supports PetaLinux), DHCP's to get a local address, and makes<br>
its streams available on assigned network ports, similar to a dvsource. All<br>
you need is a discovery protocol and you could have a self-configuring LCA<br>
recording network.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Aside: one of the things I didn't get around to, although I did try, was to<br>
set up the master and slave laptops with DHCP. They still all have manually<br>
assigned addresses, because we were looking at this during the conference<br>
when we didn't want to disturb anything (enough was breaking anyway without<br>
further encouragement). The aim was for each system to get a DHCP address,<br>
have an internal hostname, and from there have a script which would either<br>
pull its config based on its hostname from a given source, or (better)<br>
generate it in a script. Some day.<br></blockquote><div><br></div><div>Eventually we'll get to that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> At the moment raw mode is about 10-15fps while the target for mjpeg mode<br>
> is a full 30fps/25fps (but we only get around 20ish at the moment, but<br>
> that is a software problem with our JPEG encoder core we hope to solve<br>
> rather than a hardware issue).<br>
><br>
> The jpeg compression quality is controlled via a setting.<br>
<br>
</div>What options do we have for other codecs? I'm assuming it's a Simple Matter<br>
of Progrmaming, within the limitations of the hardware.<br></blockquote><div><br></div><div>It is a simple matter of programming and figuring out if you have enough gates in the FPGA. </div><div><br></div><div>mjpeg has quite a few nice properties which make it ideal for this use case;</div>
<div> * frames are independent - you lose one frame you just go onto the next</div><div> * easy to implement in hardware</div><div> * well understood</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I say this because, long ago, I remember seeing a webcam that someone had<br>
built that implemented Theora compression in an FPGA. The limitation was on<br>
the memory bandwidth, since it had to store inter-frame data and re-use it,<br>
but that was with DDR-333 memory. It was capable of doing 60 frames a<br>
second at 640x480, IIRC.<br></blockquote><div><br></div><div>60fps at 640x480 is pretty pathetic.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
But as well as that, I wonder about a really simple compression system for a<br>
presenter screen: save the first image as PNG, then store timing information<br>
until the next image change. Since we're primarily talking about digital<br>
streams - HDMI, DVI and DisplayPort - there's no analogue noise to worry<br>
about. A 'fuzz' factor could be used to ignore minor variations when<br>
dealing with analogue input. A more robust implementation of this could<br>
output MNG or APNG.<br></blockquote><div><br></div><div>MNG is dead. Only FireFox supports APNG. Web-P (which has animation) is just supported by Chrome.</div><div><br></div><div>MJPEG is very common and used everywhere.</div>
<div><br></div><div>Tim</div></div></div></div>