Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>Your camera's H.264 implementation may be taking 192kbps as 192kbps <em>average</em>, 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.</p>
  
  <p>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.</p>
  
  <p>At 1FPS, who knows how often your camera is generating keyframes. </p>
  
  <p>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).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2012-03-21T18:27:02.463Z
Answers.LastActivityDate: 2012-03-21T18:27:02.463Z
Answers.UserDisplayName: derobert
Answers.Body: <p>The correct answer <em>unfortunately</em> is that there is no correct answer. </p>
  
  <p>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. </p>
  
  <p>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. </p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2012-03-16T13:27:51.127Z
Answers.Text: 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?
Answers.UserDisplayName: Wheater
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2012-03-15T19:57:16.947Z
Answers.LastActivityDate: 2012-03-15T19:57:16.947Z
Answers.UserDisplayName: Dipan Mehta
Body: <p>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? </p>
  
Tags: <live>
Title: H.264, 1 FPS, 640x480 Resolution - What bit rate should I be using?
UserDisplayName: Wheater
ThreadText: # H.264, 1 FPS, 640x480 Resolution - What bit rate should I be using?
  
  (Asked by: username_0 on 2012-03-15)
  
  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?
  
  **Tags:** live
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2012-03-21. Score: 1
  
  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).
  
  
  ---
  
  ### Answer by username_2 on 2012-03-15. Score: 0
  
  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.
  
  > **Comments:**
  > **username_0**: 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?  
  
  ---
  
  