[科技新知] ccHDtv study

What is ccHDtv?

Closed Circuit HD TV (ccHDtv) is a newly developed solution for transmitting full HD digital video in a surveillance system. The core concept of ccHDtv is to deliver high definition video using digital TV (DTV) transmission. With ccHDtv, high definition digital video can be transmitted easily over coaxial cables, twisted pairs, or simply over the air. Multiple 1080p30 and 1080p60 video streams can be easily transmitted using ccHDtv over a single 3C2V/RG59 cable up to a length of 500 meters without any repeater.

In the world of analog TV, The composite video baseband signal (CVBS) is the most commonly used signal format. Its popularity, ease of use, and robustness have made it an integral part of our lives. CVBS is in fact a de facto signal standard for analog video surveillance systems. As we bid farewell to analog TV with worldwide analog switch-off (ASO) and move on to the age of digital TV, digital technologies, such as DVB-T, ISDB-T, and ATSC, became popular and indispensable much like CVBS in the analog age. ccHDtv leverages the extremely robust AV transmission capability of DTV to easily and seamlessly upgrade an analog cctv surveillance system to digital full HD. It is expected ccHDtv to become a de facto standard for digital video surveillance systems in the future.

ccHDtv is a novel technique pioneered by ITE Tech. Inc., ITE has devoted much resource into the development and promotion of ccHDtv solutions. ITE has developed key enabling products, reference system designs, and applications for ccHDtv . These products and applications enable seamless and friendly transition of video surveillance systems from analog to digital, be it all-new digital installations or upgrades from existing analog installations.

Core Technology: COFDM Transmitter / Receiver

More information on wiki: http://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing

Features of ccHDtv

• Reuse existing coaxial cable deployment without any upgrade for cables or connecters.
• Same system planning, deployment and debugging processes as used in traditional CCTV.
• Any iDTV set with DVB-T feature is able to receive ccHDtv signal without an HD DVR.
• Return channels are supported
  • Full duplex communication
  • HD DVR is able to support PTZ control, camera configuration, I/O settings, return audio and remote firmware update.
• Eavesdropping Prevention
  • Support encrypted signals in case of privacy consideration, so only authorized HD DVR can receive and
    decode it.
• No frame drops and real-time delivery
• Quasi-zero latency and quasi-real time preview for 9x, 16x, 32x...
• Long distance transmission
  • 3c2v/RG-59 up to 500M+ w/o repeater
  • 5c2v/RG-6 up to 1000M+ w/o repeater
  • Digital repeater for infinite extender
• High capacity/bandwidth
  • Multiple full HD camera video streams are able to be transmitted over a single coaxial cable.

ccHDtv Full HD Surveillance System

Devices in ccHDtv

Star Topology Deployment

• Exactly the same deployment as the traditional CCTV system
• The coaxial cable and connecter are the same. Actually, the cable medium requirement for DTV CAM is much less than analog cameras

Bus Topology Deployment

• Similar to cable TV deployment (multiple DTV CAM’s running on a single cable)
• Using same coaxial cables, connecters, mixers and amplifiers.
• ccHDtv is very robust and it’s not sensitive to cable network quality variation.
• Ring or multi-path connection is allowed in ccHDtv cable network which enables failure safe feature.

Ring Topology Deployment – Failure-Safe (Redundant) Cable Deployment

• Ring and multi-path connection are allowed in ccHDtv cable network which enables failure-safe (redundancy) feature
• Worst Recover time < 500ms

The above content is from ccHDtv alliance website.

http://www.cchdtv.com.tw/en/intro.php

More FAQ: http://www.cchdtv.com.tw/en/faq/index.php

Specification check points:

• Full duplex communication is supported.(two-way audio and control)
• Multiple stream is support. The max data rate per channel is 32Mbps.
• Wireless transmission is support.(depends on how you understand the regulations. so far ccHDtv suggest not to do so)
• Power on cable is supported. (Both AC/DC power)
• Crypto is support.

Pros compare to HDcctv

• The media is compressed. That means the ccHDtv could have much longer distance than HDcctv.
• ccHDtv supports bus, star topology. The installation is much easier than HDcctv. Besides, the cable cost is also much lower.
• ccHDtv support multiple stream transmission but HDcctv could not.
• ccHDtv support crypto but HDcctv is hard to support.
• ccHDtv use the television standard, the back-end support is much better than HDcctv.

Cons compare to HDcctv.

• None. Maybe the media is compressed.

Pros compare to IP camera

• Ethernet network bandwidth is very limited, and even worse when there are multiple IP CAM’s in the network. To save network bandwidth, IP CAM’s video is encoded with a lower bit rate or less frame rate. Beside, there are frequent frame drops due to overloading bus traffic.
• Each DTV CAM has its own proprietary data channel (up to 32 Mbps), and the guarantee of no frame drop. DTV CAM’s video can be encoded with a higher bit rate and higher frame rate. So the video quality is almost quasi-equivalent to lossless compression mechanism.
• The latency is much stable than IP. What IP can define is the best case.

Cons compare to IP camera

• Theoretically, more than 120 DTV CAMs. Practically, 32~48 cameras are recommended to minimize the adjacent channel (ACI), 2x and 3x inference. That means this solution is much suitable for small/middle projects. However, it could still co-work with IP network by gateway.

The topology show case in the Secutech booth

To make the conclusion:

• We could not see the large replace from original infrastructure to IP system. Only new and big system definitely implement IP system.
• ccHDtv create a much simpler way for traditional VGA system upgrade to HD system.
• ccHDtv can co-existence with IP system.
• IP's NVR system can leverage to support DTV camera. That means, DTV camera is almost an IP camera except the interface.
• ccHDtv use the TV standard and technical. It's robust.

So, in my point of view. This is dangerous to IP camera and it can much slow down the replacement from IP camera.

[工作點滴] wireless module development newbie

I've started collecting the information around the end of 2010 because the wireless technology advanced to much higher bandwidth for multimedia streaming.
There are two conditions of the development that I thought.
1. To develop the whole wireless part by ourselves.
2. To buy the module directly from the supplier.
But some important factors that make me just 'collect information' at that moment.
For 1, the expense is very horrible.
- We have to pay chip vendor for NRE.
- We are new to be the player and we have no credit to the chip vendor.
- We have no equipment and we have to invest a lot to do it.
- There are lots of tasks need for the regulation.
To sum up, this is a money game for surveillance company and we see no market at that moment.
For 2, we could leverage a lot tasks to supplier but we still have to prepare equipment to verify the whole system and get the experience of the regulation. However, the module cost and performance ratio could not meet our requirement. It is quite challenge for me to persuade my boss to do it.
So what I can do is just keep attention on wireless technology.
Until now, I have the chance to do the development finally.
Although I'm newbie for wireless, it's not too hard to enter this area. The reason is the technology become much mature and we can make it work even we do not know much about wireless. So, let's just do it.
The module I use is based on Atheros AR6103 and AR6003. The driver of these two chips are similar.
The documents I study is are mainly from Atheros. I also reference the IEEE specification and search on Google.

The equipment and wireless module board

- Power meter is Agilent E4416A EPM-P single channel power meter.

  This equipment can only measure the power from the wireless module from 50MHz~6GHz.

  We could not know the power is generated om which frequency.

- Attenuator to avoid the large power.

- The AR6003 module board

- To connect the module board to evaluation board and power meter.

- Without power output.

- With power output.

If we want to know the power is contribute from which frequency channel and band. We need Spectrum Analyzer to check further. But for quick check the driver is working or not, this is already enough. 

The tools from Atheros 'athtestcmd'.

Atheros test tool 'athtestcmd': We have to insmod the driver with parameter 'testmode=1' or we could not use this command.

  '-i device': example, '-i eth1', '-i wlan0'.

  '--tx frame': Continuous modulated Tx, AIFS(arbitration interframe space) can be set with the option --aifsn.

  '--tx tx99': Continuous modulated Tx, AIFS is fixed to 0.

  '--tx tx100': Continuous modulated but unframed Tx.

  '--tx off': Disable continuous Tx.

  '--tx freq': Channel frequency in MHz, but this frequency does not mean center frequency.

               See: http://en.wikipedia.org/wiki/List_of_WLAN_channels

  '--txrate <rate index>': Reference as below.

  '--txpwr': tx power.

  '--txantenna': 1 for antenna 1, 2 for antenna 2, 0 is auto. default is auto.

  '--txpktsz': tx packet size.

  '--txpattern': Tx frame bits pattern. The pattern of PN7/PN9/PN15 stands for pseudo noise code of length 2^7/2^9/2^15 bits.

                 Because the length of PN15 is large than max packet size, it's sent by 4 continuous packets.

                 The '--txpktsz' option is ignored when setting pattern to PN15.

  '--ani': Enable ANI. The ANI is disabled if this option is not specified.

  '--scrambleroff': When set, the frames cannot be sniffered.

  '--aifsn': AIFS slots number. For '--tx frame' mode only.

  '--shortguard': Short guard interval 400ns, the guard interval is 800ns if this option is not specified.

  '--mode': the --tx

  '--setlongpreamble': 

   

  '--numpackets': the total number of the packet.

Please make sure you use the correct board data from the supplier and replace it in the driver.

More task like the porting the driver for specific SoC interface, driver hacking, script setup tool and configuration application like wpa_supplicant...etc, these will be discuss later.

  

[雜七雜八] Growth road

I found an interesting comic that made by Gavin Aung Than. The philosophy is suitable for every creative work.http://zenpencils.com/comic/90-ira-glass-advice-for-beginners/

[雜七雜八] Bitcoin build on Ubuntu 12.04

I started to pay attention on the Bitcoin that is from a news that discussed why bitcoin become strengthening. After weeks study and observation, I thought the bitcoin could be one of the real monetary in future.

More links are as following.

Bitcoin official site -> http://bitcoin.org/en/

Bitcoin wiki -> http://en.wikipedia.org/wiki/Bitcoin

Bitcoin howto in Chinese -> http://saving.cc/bitcoin/

The following article is quite earlier in Taiwan's news and it is also interesting.

http://techorange.com/2011/05/22/bitcoin-p2p-curenncy-dangerous/

Two years later today, the bitcoin's currency rush to 1BT:90USD because of the crisis of Cyprus.

We can understand the nature of the monetary and the pros/cons of the bitcoin from those articles. So I need not to talk more. What I wanna do is to study and share from the source code.

The code is managed by git and host on github and we can get it by git client tool.

The link -> https://github.com/bitcoin/bitcoin

The code structure of the bitcoin.


We can get the information in the README.md.

Build bitcoin on Ubuntu 12.04

# sudo apt-get install libboost-all-dev

Go https://launchpad.net/~bitcoin/+archive/bitcoin

We have to use the ppa to install the package we need.

# sudo add-apt-repository ppa:bitcoin/bitcoin

If the error occur, we have to reinstall the ca-certificates package.

# sudo apt-get install --reinstall ca-certificates

If we add the repository successfully, we can see following information.

# sudo apt-get update

Then we could install the db4.8 package on Ubuntu 12.04

# sudo apt-get install libdb4.8-dev

# sudo apt-get install libdb4.8++-dev

The default enable the USE_UNPN compile flag, and we have to install the upnp package.

# sudo apt-get install libminiupnpc-dev

Go bitcoin/src folder and make the bitcoin package.

# make -f makefile.unix

The 'bitcoind' is generated and we can start using the tool.

# ./bitcoind --help

Done!

[科技新知] Panasonic color spliter sensor

There is a new sensor structure that introduce by Panasonic to replace color filter by color splitter. This kind of sensor remove general color filter and add the color deflector before the diode. The conventional color filter would cause 50%~70% light loss and new sensor reduce lots of the light loss. The following pictures show how it works.

The device can also be manufactured using current semiconductor fabrication processes. It doesn't use special materials or processes. It's a great news to bring this sensor to realization.

  

The comparison between the color splitter sensor and color filter sensor.

Panasonic demo with only two-deflector method but various combinations are possible.That means, it could be adjusted by different application.

Although it could provide much better sensitivity, I still have some question about it.

- Would the resolution be sacrificed?

- The diode of different pixel is not balanced, is there any side-effect occurred?

- Would it be much more complicated for the image processing processor supported?

Anyway, I'm still interesting with this sensor and I'll keep eye on it.

[工作點滴] rtmps in rtmpdump with hardware engine development

Evostream server's configuration for rtmps test

Add the following content in the acceptors part in config.lua.

This is for Win7 configuration and remember that we have to use double '\' instead of single for path.

The cipherSuite parameter, we could reference http://www.openssl.org/docs/apps/ciphers.html#CIPHER_SUITE_NAMES

RTMP library

The library is main from rtmpdump. The webpage is http://rtmpdump.mplayerhq.hu.

The libssl library - SSLv23 method is used in the RTMPdump.

- SSLv23 method

  A TLS/SSL connection established with these methods will understand the SSLv2, SSLv3, and TLSv1 protocol.

  A client will send out SSLv2 client hello messages and will indicate that it also understands SSLv3 and TLSv1.

  A server will understand SSLv2, SSLv3, and TLSv1 client hello messages.

  This is the best choice when compatibility is a concern.

- SSLv23 related files in the openssl/ssl/ folder

  * s23_clnt.c

  * s23_lib.c

    the ssl23_connect() function handle the hello message between client and server.

    the client's related method will be created according to the server's hello message.

    we can look into the ssl23_get_server_hello() function for more detailed.

    we can compare with the network packet by Wireshark. We use the TLSv1_client_method().

  * s23_meth.c

  * s23_pkt.c

  * s23_srvr.c

  * ssl_locl.h -> the marco and function were defined in this header file.

    

- the client hello information by Wireshark.

  - the server hello information by Wireshark.

- According the Wireshark packet, let's dig into TLSv1_client_method() function.

  * the TLSv1_client_method() define in the t1_clnt.c file.

  * the TLS method is define in the ssl_locl.h file.

- TLSv1_enc_data(), this is a SSL3_ENC_METHOD structure define in ssl_locl.h and instantiate in t1_lib.c.

- ENGINE_setup_bsd_cryptodev(), this should be called to enable the 'cryptodev' engine support.

- ENGINE_load_builtin_engines is related to OPENSSL_NO_HW and it is define in crypto/opensslconf.h.

  However, this is not called to load the cryptodev by default.

- we have to add the ENGINE_setup_bsd_cryptodev() in rtmp library.

cryptodev-linux package http://cryptodev-linux.org/index.html

- cryptodev, call iotcl() in cryptodev-linux/ioctl.c to access the crypto hardware engine.

  * CIOCGSESSION: to do crypto_create_session()->crypto_cipher_init()->crypto_alloc_ablkcipher().

  * CIOCCRYPT: the crypto_run() is in the cryptodev-linux/main.c.

  

  * crypto_run()->__crypto_run_zc() or __crypto_run_std()->hash_n_crypt(), this function would call directly to kernel crypto driver.

  * cryptodev_cipher_encrypt() is in the cryptlib.c. The function ablkcipher_request_set_crypt()

    and crypto_ablkcipher_encrypt() are in kernel.

Kernel crypto driver support

- crypto algorithm structure

- Asynchronous block cipher algorithm structue.

- Synchronous block cipher.

- crypto TFM(transform) structure

    * asynchronous block cipher transform structure

  * synchronous block cipher transform structure

- The cryptodev-linux is using the asynchronous block cipher method. We can create a kernel driver.

  There are example in the linux/drivers/crypto/ folder.

I assume that the kernel driver we create is abc_crypto.ko. We can insmod both the abc_crypto.ko and cryptodev.ko. Then the rtmp library support the rtmps through OpenSSL with hardware crypto engine.