Video Production Stack Exchange is a question and answer site for engineers, producers, editors, and enthusiasts spanning the fields of video, and media creation. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to transmit this video stream over satellite. So far, I have been able to send 1 fps, 320x240 with no problem. However, when I raise it to 640x480, the picture comes in once every few minutes and that's about it. Bandwidth is not an issue - we are using ~192 kbps and up. Any ideas?

share|improve this question

That's something thats going to differ a fair bit based on picture complexity, implementation quality, profile used, etc. But going to low shouldn't cause the picture to stop, just fill with compression artifacts.

Often, video completely stopping means you've had transfer issues. If you remove the satellite link, does the video freeze still occur? Cheap satellite links (i.e., those costing less than $1000/mbit/mo) are notorious for dropping, reordering, and delaying packets. If the freezes occur without the satellite link, I'd guess your cameras have a deficient H.264 implementation, or at least one not designed for 1FPS.

Your camera's H.264 implementation may be taking 192kbps as 192kbps average, with a buffer of X bytes. So on the first frame it may generate a lot more than 192kbit, expecting to make it up later (buffer size may be assumed to be 1 megabyte or even larger). And then, the satellite link is pegged for a few seconds as it transmits that "buffered" amount.

Lowering framerate on H.264 doesn't save nearly as much bandwidth as you'd expect, due to there being large differences between each frame. But it degrades visual quality at least as much as you expect. So its often a bad trade-off. Also, various H.264 options can increase compression, but result in multi-frame decode delays. At 1FPS, that is really noticeable.

At 1FPS, who knows how often your camera is generating keyframes.

I'd suggest sending some data encoded with X264 (or ffmpeg, which uses it). See if that works. Its probably a better implementation than your cameras feature. It also lets you tweak buffer sizes (you probably want a low one, unless you're buffering on the receiving end).

share|improve this answer

The correct answer unfortunately is that there is no correct answer.

The need for bitrate really depends on the actual implementation. For example there can be anything from 20% to 40% difference in bit rate requirement between best and worst H.264 encoders.

Also, it grossly depends on what acceptable quality - do you really want broadcast quality or you don't mind blockiness than bit rate requirement can be drastic.

As a rough estimate - Very good hardware encoders can do good D1 resolution @ 25 FPS at 1 to 1.2 Mbps. Now if you reduce frame rate to 1 FPS the bit rate won't go down by 25 time low though. Since must of the resultant compression is due to temporal redundancy. So best bet is to have something around 1/4th of bit rate from above. So good encoder should be able to do your job below 200 to 300 kbps. Though, this all depends on actual encoder.

share|improve this answer
We are using H.264 cameras. What do you mean by hardware encoder? Will I need an encoder if the cameras encode themselves? Also, 200 to 300 kbps seems extremely high. Are you sure I can't get by on 64 kbps? – Wheater Mar 16 '12 at 13:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.