SunnyKim

We are Ubiqmicro. As said, H.264 does not specify the bit stream syntax when splitting UHD sized video into 4 Ch X 1080P, as no hardware chip can handle UHD video in one shot in real time, as far as I know. We are designing our own CoDec, capable of 4 Ch X 1080P in H.264 format. We will be using our own syntax, just as others. Therefore, non compatible, when decoded by many nvr softwares out there. So we have to provide our own software for decoding and displaying correctly. I do not know S2 but S5, and S7 from Ambarella. If S2 is the older version, then no way you can come up with any marketable products.

Good to know, Lee Tracey. It is possible to make UHD x 30 FPS in real time. The chip set that we are currently designing is capable of doing that, too. I would announce it at the time the chip set would be released to the market.

Please allow me to add my 2 cents. Compressing UHD video of 30FPS or 60 FPS into H.264 format is OK with software. But actually, H.264 did not anticipate the real life - difficulty of UHD size video compression on hardware chip set. But in a new H.265, it becomes possible. H.265 opens the way how to. It allows to split the UHD into 4 pieces of HD 1080P, by specifying bit stream syntax. So parallel processing becomes possible. So does hardwired logic(chip). So would be any soft-wares claiming H.265. Current UHD compression with H.264 chip may be being done, by splitting into 4 X 1080P. The compressed files may be merged in their own way, whatever, incompatible with H.264 standard. Because H.264 did not specify how to do. And decoding and displaying in their own way. As a result, no other soft-wares can not handle how to. This may explain the fact that for UHD cameras only 6 FPS become available in market, because they probably use a hardware chip that can compress 1080P X 30FPS. Probably some guys with a graphic card + powerful CPU, could do that. But the market is not that good,yet, so we do not have any near plans to jump into development. In my old threads, you can see that we have a software Engine to decode 128Ch X HD1080P X 30FPS, in realtime, with nVidia Graphic cards. We have sold only a few copies, so far. I do not want to start H.265 decoding project at this moment. If anyone has interested in doing business with our current decoding Engine, please let me know.

If there is only one cable line and the camera claims "HD-SDI", then we have to believe that it should be outputting HD_SDI signal, by default. The video size can be 720P, or 1080P. And the quality of video depends largely on the lens quality.

HD-SDI signal from camera is completely different from the conventional TV (NTSC/PAL) signal. But both uses the same cable. HD-SDI is formatted/transmitted in their own standard. So is needed a special HD_SDI receiver to change into a standard video format and then to feed HDMI TX cable. The solution is... Buy a HD_SDI DVR with HDMI ouput capability.

Buy a USB-DVR that takes input of NTSC/PAL which is camera's output, or DVR's TV out. The displaying video quality is not bad, because it is in CIF size or D1 size. Good enough to manage camera's. There are bunch of them on the internet.

ak357, We are designing chip sets for CCTV applications. 4 months ago, we bought HD-CVI camera and examined its output signal. So we learned how they did it. But we are planning not to jump into developing this kinds of chip set for the time being. In stead, we are focusing on CoDec chipsets. Sometime later, you will see some cameras or DVRs carrying our chipsets.

Gentlemen, We are designing a chip set(System On Chip) for IP Camera application. That does H.264 compression and sends the compressed bit stream via network line. We are considering to implement a Fish Eye feature as a hardwired logic inside the chip. But I am not quite sure of what kinds of applications are really needed in the real fields of end-user side. 1. Do you need a single compressed stream for the whole warped video? Then NVR side is to de-compress the stream, de-warp the video, and display the videos, say 4 sections or two sections in Picture in Picture Mode that end user wants to see? In this case, Our job is simply to compress the warped video scene and sending the bit stream to NVR. It is job for NVR to de-compress and de-warp the video. 2. Do we have to de-warp the video in 2 or 4 video scenes that a user has specified before compressing the warped video? Then we compress each de-warped video scene in a separate bit stream file and sending to NVR via network cable? Our compression engine is to compress either in 2 ways, as below. 1. the entire warped video and at the same time, additional two de-warped video in real-time compression, say 30FPS each. 2. four different compressed bit streams for four de-warped video scenes. Which one above do you like to have? We really like to hear voices (demands) from real application fields. We really appreciate if you suggest what should be needed or what you like to have.

jibin, Why not? You can try with any kinds splitters(multiplexer), which is nothing but a voltage divider. And HD-CVI is based on Amplitude Modulation, just as conventional NTSC/PAL signal.

You may not use solid state device for CCTV recording. Not much storage space and short life span.

CCTV has to work 7days, 24 hours all year long. I think everybody should appreciate only if it lasts only two years, when compared to more expansive TV set, or PCs from giant manufacturers.

I have never done this. But you may try. The TVOut(Cvbs) signal out of your DVR box is the same as output signal as vcr out or dvd player. If the direct TV box allows an external video input from a VCR and carries TV out port, then video path gets cleared. You may need to change each TV's base station to channel 2 or channel 3, when you need to watch the video from cameras. But as the TVs of each room do not have any link to or control over your DVR set, they can not move around camera channel.

geordie, Good decision. You only need to buy a new DVR. Now about U$40~70. In old days, it might be more than 100K, at least, with its features being offered now.

Yoseph, I tried to search for tkc3107 to get hints on DVR type. But nothing googled up. BTW, as you bought 1080P, one concern could be on cabling issue, if the camera is not for HD-SDI type. HD-CVI of 1080P may not be available on the market, yet. But if it is for IP camera, you have to also install Cat5E type, LAN cable, POE, and NVR, kinds of things for IP camera system.

It seems to me that baluns may work better for hd-sdi system than hd-cvi. Is there any other guy who actually tested the both systems with some popular baluns? We would appreciate his report very much, if he can kindly share his test result with our members here.

GMA, The Video Capture Card with PCI Express Interface can do the job. You can get them on the internet. If you can wait for 2 months, you can buy ours on internet.

Pixel Bandwidth should exclude the bandwidth of color components. As you may know, we designed chip sets for analog video decoder.We are selling those chip sets and cards for video PC capture cards. If you like to test them, I can send you one free.

How have you been doing, ak357 As to analog TV signal, whether PAL or NTSC, the total video pixel bandwidth is to be limited around 3 Mega Hertz. Much smaller than we have thought. That means 1200 TVL (horizontal resolution) analog camera would not do much good. Resolution-wise, 650 TVL is good enough to represent 960H. But image processing tech keeps being improved. 1200TVL may be better than old 650 TVL, in this sense. That's what I said in above.

The number of video lines is fixed as 576, for PAL standard. 1200 TVL would not do much as long as they are for analog camera(PAL or NTSC). You better get Good Lens, or Good Focus, or and adding one more camera in case you may have missed the target.

HD-CVI is from Daihua and HD-TVI is from HikVision. They are based on the same category of technology, an extension of traditional TV signal (PAL , NTSC). They just added number of pixels per line and increased the number of lines, so carrying much higher frequency component than PAL or NTSC. The fact is that they both suffer high frequency loss or video sync signal loss, a lot more than PAL or NTSC, if used on a regular cable. They may need a very good quality cable for a longer distance,say, 50 meter above. Another issue is that you have to buy HD-CVI camera and HD-CVI DVR as a pair set, for compatibility. Daihua does not sell receiver chipset for DVR on the open market. HD-TVI from Hikvision would do the same. The both party do not compromise each other. They both aim to monopolize the CCTV market. Nightmare for the end customers or middle players, in the end. Both technology is not matured yet but would not be at all, but I keep watching how they would go. HD-SDI is designed for broad casting studio. The technology is based on SerDes using Giga hertz carrier. CCTV industry just adopts the chip sets for sending HD video data from HD camera. It also suffers video loss, in case over 100 meter, on a regular cable, because of its inherent high frequency component. HD-IP sends video stream file after compressing the HD video data on a LAN cable. Just as in internet, a bit loss in transit could result in video loss 2 or 3 sec duration. Another shortcoming comes for a rather long time delay, because the compressed bit stream should be buffered and decompressed for being displayed.

Cat6 is for IP camera. Coax is for analog, HD-SDI, HD-CVI, kinds, and all old types of cable TV.

1 bit, TVL is quite confusing term. TVL is number of vertical lines discernible on a horizontal line. That states a horizontal resolution. Please note that video image needs be band limited and transformed before being sent as a TV signal. TV signal is quite bandwidth limited so 650 TVL is good enough to cover up to 960H- horizontal resolution camera. As sensor and its image processing technology gets advanced every year, the higher TVL would be good, in general. As long as you like your video quality, that's good. No cheatings, whatever.

Farzad, I tested on a cheap unbranded cable of 100 meter with DVRs for analog cameras, there have been not much trouble in capturing of video image. RG59 demands a more tighter specificaton. So would be no troubles.

I'd better buy two, in stead of one expensive one, just in case one fails to read the number correctly.

I do not think it is the problem from Hi3518 Chipset, itself. It could be from the bad components of the board or the soft wares on it. As said, in China, even chipset providers can not tell who sold the products and who designed the board and its soft wares. It would be a good thing for local distributors to understand exactly what their suppliers can do or can not do, before importing the products for their local customers. Of course, not for a guy to buy directly from China or internet. That's why I recommended products from Taiwan or Korea. Though a bit more expensive, these makers are at least trying to track out what caused the problems and trying to prevent not to happen again. That's the way how they can compete and survive in the market.