Lines Matching full:per

287 	LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
381 (quantization) tables, and you'll get to something like 512kB per frame for
400 704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
401 3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
402 1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
403 output becomes 512 bits per block. Actually 510, but 512 is simpler to use
406 Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
407 becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
408 here, so we don't need to do any fancy corrections for bits-per-pixel or such
409 things. 101376 bytes per field.
411 d1 video contains two fields per frame. Those sum up to 202752 bytes per
421 leaves 65536 bytes for each field. Using 3168 blocks per field, we get
422 20.68686868... available bytes per block; 165 bits. We can't allow the
423 request for 256 bits per block when there's only 165 bits available! The -q50
427 This gives us a data rate of 165 bits per block, which, times 3168, sums up
428 to 65340 bytes per field, out of the allowed 65536. The current driver has
431 a safe bet. Personally, I think I would have lowered requested-bits-per-block
432 by one, or something like that.) We can't use 165 bits per block, but have to
434 per block, the equivalence of -q24. With 128kB buffers, you can't use greater