Fwd: Cheap HDMI capture devices

[Tim Ansell]

Hi guys,

This looks really cool! It appears this device is very different to the normal HDMI over CAT5 devices which don't use IP or even Ethernet, this device encodes the video as MJPEG and sends it over IP. The blog URL gives you loads of information about how this is all done.

PS This device would also be super horrible if you wanted to use it for actually extending HDMI signals!

Tim

---------- Forwarded message ----------
From: Michael Still <mi...@stillhq.com>
Date: 26 January 2014 12:02
Subject: Cheap HDMI capture devices
To: Tim Ansell <mit...@mithis.com>, Paul Wayper <pau...@mabula.net>


Have you guys seen this yet?

http://danman.eu/blog/?p=110

Which is this device:
http://www.ebay.com.au/itm/2013-New-HDMI-TCP-IP-Extender-100-120-meters-Over-Cat5-Cat6-1080P-for-HD-STB-DV-/131034362578?pt=AU_Television_Accessories&hash=item1e8241b2d2&_uhb=1

For $90 AUD you get a device which takes a HDMI stream and delivers it
as a MJPEG stream and an audio stream over TCP. You only really need
the sender side for conference AV, but the other side could be
recycled for conference announcement screens.

Michael

--
Rackspace Australia

[Tim Ansell]

I have purchased two. Economy shipping means it will be ~2 weeks before I get them.

Tim

On 28 January 2014 08:15, Ryan Verner <ry...@nextdayvideo.com.au> wrote:

Conversely, the fact MJPEG isn't inter-frame makes it extremely suitable for our use-case of on the fly mixing without requiring huge computational power; a big reason DV is used currently.

Tim, looks interesting, you ordering a set of these to play with?

Mikal - nice find, thanks!

On Sun, Jan 26, 2014 at 9:43 PM, Michael Borthwick <m...@michaelborthwick.com.au> wrote:

On 26/01/2014, at 5:21 PM, Tim Ansell wrote:

Hi guys,

This looks really cool! It appears this device is very different to the normal HDMI over CAT5 devices which don't use IP or even Ethernet, this device encodes the video as MJPEG and sends it over IP. The blog URL gives you loads of information about how this is all done.

M-JPEG - hmmm I'm channelling a Radius VideoVision Studio Card in a PowerMac 8100 circa 1995 with a stack of daisy-chained 2GB SCSI drives each the size of a shoebox



Michael Borthwick Consulting Pty. Ltd.
GPO Box 1950, 380 Bourke Street, Melbourne Australia 3001
Level 1, 384 Bridge Road, Richmond
Mobile Ph: + 61 418 345 800
http://www.michaelborthwick.com.au

[Andrew Cooks]

On 26 January 2014 14:21, Tim Ansell <mit...@mithis.com> wrote:
> Hi guys,
>
> This looks really cool! It appears this device is very different to the
> normal HDMI over CAT5 devices which don't use IP or even Ethernet, this
> device encodes the video as MJPEG and sends it over IP. The blog URL gives
> you loads of information about how this is all done.

The info on the blog is really great! It seems they've opted for zero
configuration in the IP code, which makes things much simpler in the
device.

Unfortunately, the image quality seems a bit suspect. I wonder if it's
the HDMI output that's low-res (even though the datasheet says it
supports 1080p@30Hz [1]) or if they're mangling the images in the
processor due to some limitation (I couldn't find a datasheet for it).
But why output 1080p@18Hz? Why not 720p at input rate?

1. http://en.honestar.com/product/datasheet/ITE/IT6604%20Datasheet%20v0%207%20.pdf

> PS This device would also be super horrible if you wanted to use it for
> actually extending HDMI signals!

Can you explain a bit more? The worst thing I can see is that it
requires external power.

Cheers,
a.

[Tim Ansell]

On 28 January 2014 17:21, Andrew Cooks <acooks@gmail.com> wrote:

On 26 January 2014 14:21, Tim Ansell <mit...@mithis.com> wrote:
> Hi guys,
>
> This looks really cool! It appears this device is very different to the
> normal HDMI over CAT5 devices which don't use IP or even Ethernet,

The "normal" HDMI over CAT5 devices are just using the cables as know quality copper. They also generally require 2 sets of CAT5 cable for 1080p quality.

> this device encodes the video as MJPEG and sends it over IP. The blog URL gives
> you loads of information about how this is all done.

The info on the blog is really great! It seems they've opted for zero
configuration in the IP code, which makes things much simpler in the
device.

"zero configuration" in the automagically config system, or "zero configuration" as in NO configuration (this one I think).

BTW, I just saw "Thank you Chinese engineers! Because of wrong length in IP header (1044) I have to listen on raw socket!"

Unfortunately, the image quality seems a bit suspect.

Probably better them [HDMI -> VGA -> Twinpact -> DV] though...

 

I wonder if it's
the HDMI output that's low-res (even though the datasheet says it
supports 1080p@30Hz [1]) or if they're mangling the images in the
processor due to some limitation (I couldn't find a datasheet for it).

It's probably a bandwidth issue, see below.

But why output 1080p@18Hz? Why not 720p at input rate?

1. http://en.honestar.com/product/datasheet/ITE/IT6604%20Datasheet%20v0%207%20.pdf

Bandwidth is a *huge* issue for HDMI on CAT5.

1080p -- 1920×1080@24 fps -- 1920*1080*24*12/1e6 ~= 597 Mbit/sec -- MJPEG is going to compress to ~20% of that, or ~119.4 Mbit/sec.

https://github.com/timvideos/HDMI2USB/wiki/Resolutions

It's unclear what speed the Ethernet interface on this device is. If it is a 100Mbits then the "Transmitter was streaming 1080p@18fps with 90Mbps bitrate." makes a lot of sense.

> PS This device would also be super horrible if you wanted to use it for
> actually extending HDMI signals!

Can you explain a bit more? The worst thing I can see is that it
requires external power.

The conversion from HDMI->MJPEG->HDMI seems fraught with danger. 

As you mentioned their are quality issues. For example, using MJPEG they are introducing video JPEG artifacts if they are not doing lossless compression.

------

Just a FYI, there where some stuff in the comments about accessing the serial port.

Boot sequence:0123456

*************************************************

* Initializeing MM *

*************************************************

Start:0×00100000 End:0×00280000, Size:0×00180000(1536K), Pages:384

TF680 FW Verion: Tx_v1.07_C904 ITE 152MHz IR LAN_MODULE

FW Release Date: Nov 2 2012, 11:04:55

TF680 MAC: 00:0B:78:

TF680 IP: 192.168.168.55

All of Tasks Created

[taifa Debug Console]

(c)2010 taifatech inc. All rights reserved.

**Type ‘help’ for more details; ‘exit’ to quit**

TFCMD> help

reg : Read/Write reg. of taifa device

sys : Do some system set

spi : Read/Write SPI device

osd : Read/Write SPI device

gpio : GPIO port Read/Write

mdio : Read/Write mdio device

i2c : Read/Write i2c device

hdmi : Read/Write HdmiTx device

hdmi : Read/Write HdmiRX device

dbg : Debug message level

ch : Audio buffer control

i2cm : Read/Write i2c device with multi register address

edid : EDID Read/Write

3 : Do EP9x53 controller Task

i2s : T/R audio by I2S mode

l2 : Set L2 routing table.

l4 : Set L4 routing table.

sdram : External SDRAM Test

cap : Capturer fskp, CRC, bypassSD, shsize, svsize

ver : Debug Console Version Information

av : select Tx/Rx format

q : video quality toggle

q : show stack status

fps : show/off fps for test

inband : inband packet test

TFCMD>

TFCMD>

OtoM TFVEP is disconnected !!!

Tim

[Andrew Cooks]

On 28 January 2014 15:09, Tim Ansell <mit...@mithis.com> wrote:

> On 28 January 2014 17:21, Andrew Cooks <aco...@gmail.com> wrote:
>>
>> The info on the blog is really great! It seems they've opted for zero
>> configuration in the IP code, which makes things much simpler in the
>> device.
>
> "zero configuration" in the automagically config system, or "zero
> configuration" as in NO configuration (this one I think).

Yeah, I can see that wasn't very clear. I meant that the user cannot
change anything, but I don't know if it's using hard-coded IP
addresses or apipa or whatnot.

> BTW, I just saw "Thank you Chinese engineers! Because of wrong length in IP
> header (1044) I have to listen on raw socket!"

Yes, that sucks, but we can work around that in software ;-)

>>
>> I wonder if it's
>> the HDMI output that's low-res (even though the datasheet says it
>> supports 1080p@30Hz [1]) or if they're mangling the images in the
>> processor due to some limitation (I couldn't find a datasheet for it).
>
>
> It's probably a bandwidth issue, see below.
>
>> But why output 1080p@18Hz? Why not 720p at input rate?
>>
>> 1.
>> http://en.honestar.com/product/datasheet/ITE/IT6604%20Datasheet%20v0%207%20.pdf
>
>
> Bandwidth is a *huge* issue for HDMI on CAT5.
>
> 1080p -- 1920×1080@24 fps -- 1920*1080*24*12/1e6 ~= 597 Mbit/sec -- MJPEG is
> going to compress to ~20% of that, or ~119.4 Mbit/sec.
> https://github.com/timvideos/HDMI2USB/wiki/Resolutions
>
> It's unclear what speed the Ethernet interface on this device is. If it is a
> 100Mbits then the "Transmitter was streaming 1080p@18fps with 90Mbps
> bitrate." makes a lot of sense.

From the serial port output, I see the device is a taifatech TF-680
that can only do 10/100Mbps on the Ethernet MAC [1]. But it still
doesn't make sense to do anything at 1080 after the input has been
degraded. They're mangling the Ethernet frames such that only their
device (or custom software) can decode the stream, so shoving 1080
MJPEG frames that only contain 720 (or less) worth of resolution down
a pipe that cannot take it is...uh...not smart. If they want to
maintain the illusion of 1080 resolution from end-to-end, then the
decoder should scale it.

720p -- 1280×720@24 fps -- 1280*720*24*12/1e6 ~= 265 Mbps
Or at 30fps, ~330Mbps

MJPEG @ 24 fps: 265 *0.2 = 53 Mbps
MJPEG @ 30 fps: ~66 Mbps

Besides the 100Mbps Ethernet bottleneck, the processor, running at
~160MHz and 32-bit wide, seems like it would struggle to handle 1080
throughput as well. So, I maintain that 720p@24fps would provide a
better user experience than fake 1080@18fps and still fit within the
restrictions of their silicon.

Of course if we're thinking about implementing something similar on
the Atlys board, we have Gbit Ethernet, but I don't know if the
Spartan 6 could handle 1080p@24fps either.

1. http://www.taifatech.com/files/TF-680_Product_Brief_04.pdf

Regards,

a.

[Tim Ansell]

From the serial port output, I see the device is a taifatech TF-680

that can only do 10/100Mbps on the Ethernet MAC [1].

1. http://www.taifatech.com/files/TF-680_Product_Brief_04.pdf

You should comment on the blog post with the above. 

 

But it still
doesn't make sense to do anything at 1080 after the input has been
degraded. They're mangling the Ethernet frames such that only their
device (or custom software) can decode the stream, so shoving 1080
MJPEG frames that only contain 720 (or less) worth of resolution down
a pipe that cannot take it is...uh...not smart. If they want to
maintain the illusion of 1080 resolution from end-to-end, then the
decoder should scale it.

 

They aren't even sending the right size IP header, what do you expect :P

My bet is that they aren't even touching the stuff in software and instead just DMA it directly around.

 

720p -- 1280×720@24 fps -- 1280*720*24*12/1e6 ~= 265 Mbps
Or at 30fps, ~330Mbps

MJPEG @ 24 fps: 265 *0.2 = 53 Mbps
MJPEG @ 30 fps: ~66 Mbps

Yeah, your maths looks good to me :)

Besides the 100Mbps Ethernet bottleneck, the processor, running at
~160MHz and 32-bit wide, seems like it would struggle to handle 1080
throughput as well. So, I maintain that 720p@24fps would provide a
better user experience than fake 1080@18fps and still fit within the
restrictions of their silicon.

If it's not doing any processing then it would probably be fine.

 

Of course if we're thinking about implementing something similar on
the Atlys board, we have Gbit Ethernet, but I don't know if the
Spartan 6 could handle 1080p@24fps either.

There are a bunch of people using the Spartan 6 with 1080p@24fps fine. It's mainly about how many gates you have to spend.

I'd really like to see someone work on doing Gbit Ethernet with the GTP connectors, but that requires us to finish a board first.

Tim