shaggybaxter

Dear All, For reference, my background is networking and I have set up a test bench where we run SD/HD Mpeg2 and Mpeg4 TV/CCTV through wireless infrastructure and fibre/IP infrastructure. Tested MP's too along the way. We have measured different stream rates and error counts/types through an awful lot of wireless and fibre converter vendors, both IP and analogue. We learnt a lot about vendors and system performance, and interesting titbits accrued along the way, so if anyone has queries on fibre or wireless transmission I officially with the best intentions open the thread and hand over to you............

Hi Gents, A classic issue with fault finding fibre transmission is as discussed in another thread, Macrobending in SM transmission. Look at your wavelength/s of your converter. Check to see if the wavelength being attenuated out is at 1550nm. If so, what you are most likely experiencing is macrobending. A fibre cable kink in an underground joint or splice tray for example will show minimal loss at 1310nm (normally video wavelength) and huge loss at 1550nm (sometimes your PTZ data) This is known as macrobending. It is caused by over-bending on the fibre cable, and is always detected as high loss at 1550nm. (A macrobend is a lot of times a less than 60mm diameter bend in the cable, so look at fibre trays on either end in case someone has just crammed the tails in) To test, get a light source/power meter (or an OTDR) that can measure at 1310nm and 1550nm and measure the whole fibre at both wavelengths. If it is macrobending (common) you will see a huge loss at 1550nm. If you use an OTDR, it will give you the distance to fault, aka: the pressure point, or macrobend.

Hi, We have seen this problem with several vendors encoders for the last 2 years over wireless. We have had a fair degree of success with work arounds, so pls respond it the following doesn't help..... Multicast addressing for video/audio. One common trick is to set your video streams as unicast, as most IEEE compliant wireless devices (I am assuming that your 108mbps is turbo mode 802.11a/g....) adopt the "hidden node" mode and bandwidth throttle upon detection of multicast to 11 mbps best case, regardless of what the software tells you. The other issue is that multicast uses IGMP queriers to request video, not a good idea in point-point wireless. Encoder hangups However, the issue in our experience is always the encoder/decoder vendors operation on the network, most have hanging issues in a wireless Lan install. To tell if it has a problem, set the encoders SNMP trap output to report to a PC over the WLAN, and turn off the video stream for 24 hours (if you can!). If the SNMP traps stop at any time over the 24 hr period, you know it is not video stream/bandwidth related, but simple encoder hangs. Hammer your encoder vendor or swap brands. Out of interest, whilst I do not believe your issue is in this case is wireless related, video over wireless is 90% of the time not a bandwidth issue. It is usually the always-varying SNR of the wireless carrier and the lack of buffers in the Wireless design. A good rule of thumb is never use IEEE compliant radios, (even Cisco!!! ) but a dedicated ReadytoSend/Clear toSend wireless protocol. Pls respond if this isn't the right track...............

Hi CCTV-guru, With thanks, but what is this? 30fps? or 1fps? Clarity please, numbers can get awfully confusing. Your are even confusing yourself! (....my software is averaging 650Mbps at 720p.....) I would beg to differ, pixels mean a lot. If I have to send a digital signal only sampling 720 lines instead of 1500 lines, obviously this is more data. Look at the difference between HD and SD TV when we encode it, same argument. Comments?

Hi Vin_sys, One issue you need to be aware of is macrobending in the fibre. Too tight a bend in the fibre cable at any point in the cable is called macrobending (a radius of 30mm in a joint on SM fibre will macrobend). An unpleasant side effect is macrobending will pass 1310nm with minimal loss (atypical 1db), but heavily attenuate the 1550nm wavelength (atypical 10db). this means your video will work fine, but your RS data won't. If vadsys is correct and these converters use a 1550nm wavelength, get an OTDR trace of the fibre, could well be macrobending. What's the bet you have a massive attenuation spike somewhere in the cable? javascript:emoticon(':wink:')

it is wrong. MPEG4 and H.264 are variable bit rates dependant on scene. I can actually produce a HD image of 720p at 320Kbps average. --------------------------------------------------------------- At what frame rate ? some system use VBR some CBR right ? I can easily believe 720P at about 3.5-4.0 Mbps 30 frames because I have such product but 720P at 320Kbps and 30 frames I have problem plz explain THX --------------------------------------------------------- You can not measue these as a KB file size. Any product that does is not implementing the protocols properly and is only sending I frames, which is no different to sending JPG's 30X a second. Hi guys, This is pretty simple, anyone can make video small, you just lose quality. Do the sums: I set up the following: 1 x I-Frame ps at 4Cif at Mpeg4 on the test bench. (4cif = 704x576) I varied the compression ratio of 2 x vendors encoders from max to min. Set the system to CBR. I got an average of: - 20KB per frame with max compression. - 80KB per frame with least compression. Video looked like crap at 20KB frame size. Looked pretty good at 40KB. If I run at 30fps at 20KB I frames, (1 x IFrame and 24 P Frames a second), I get a measured bandwidth of 1.69Mbps. This is using a I/P Frame ratio of 250% bias for I frames, as per standard. Using I Frames at 80KB, it measures 6.9MBps (using Ixia). 320kbps at 30fps means each frame is (320kbps/8/30=KB). This means you are running an average frame size of 13KB. For 720P? How do you guys do it, cos I sure can't!