Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It will vary dramatically depending on the content of the source videos. I'll get to that in a bit. </p> <p>640x360 is not that large. 512kbps is very reasonable and arguably standard. Maybe 768kbps if you are really interested in quality.</p> <p>How is this possible? A simplified answer: There are a couple of techniques and facts about <a href="http://en.wikipedia.org/wiki/Video_compression" rel="noreferrer">video compression</a> that make this possible: </p> <ol> <li><strong>Not every video frame</strong> data structure in an common H.264 (or other CODECs for that matter) <strong>is a full image</strong>. Instead there are two types which are colloquially referred to as <ol> <li><strong>Key Frames</strong>: a full rendering of the entire video image</li> <li><strong>Intra-frames</strong>: a description of changes to the previous frame. These frames generally make up the vast majority (80%-99%) of frames in a video.</li> </ol></li> <li><strong>H.264 is "<em>lossy</em>"</strong>, as are many other CODECs. They do not reproduce a pixel-by-pixel, frame-by-frame exact duplicate of the original source video. <strong><em>Example</em></strong>: Lossy blocks: If all but one pixel in an area is the same color, the CODEC 'loses' the one pixel. So, instead of having to store information about every single pixel in a frame, the CODEC just says <em>"x1, y1 to x2, y2 are all color x"</em>. Very efficient. </li> </ol> <p>It is all wildly more complex than that, with zillions of different approaches, techniques and algorithms within specific CODECs and between CODECs to make this happen.</p> <p>So, back to the "It will vary dramatically depending on the content of the source videos" comment: The compression ratio you'll see, and the resulting quality, will depend significantly upon:</p> <ul> <li>the contents of the video</li> <li>your tolerance for artifacts (blocks, loss of color, loss of definition)</li> <li>the CODEC parameters you set, and how you set them</li> </ul> <p><strong><em>Example</strong>: A video of a door in a room (like a security camera) with one key frame every ten minutes is going to have an amazingly high compression ratio. My back-of-the-napkin calculations put that scenario at 15,000:1 compression.</em></p> <p>Since you are starting on a large video encoding project, I would recommend a couple of things to determine what your compression ratio is going to be:</p> <ul> <li>take a sample of the source videos you are going to encode. 100 or more being statistically relevant.</li> <li>encode them at various bit rates, with various parameters, to determine what resulting characteristics meets your needs</li> </ul> <p>Changing the parameters of the encoder to make the videos smaller can have other impacts too:</p> <ul> <li>higher play back CPU requirements</li> <li>player CODEC expectations. Not all H.264 encoded videos can be played back by all players</li> <li>longer encoding times</li> <li>various degrading of quality</li> </ul> <p>It's a big complicated subject. Good luck. My experienced <em>"thumb-to-the-wind"</em> test says you'll be more than happy with 512-768kbps for your project.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload