Предлагаемый коэффициент сжатия с H.264?

Ответ 1

В довольно интересном документе под названием H.264 Primer простая формула дается как подсказка для вычисления битрейта "идеального" выходного файла, исходя из характеристик видео:

[ширина изображения] x [высота изображения] x [частота кадров] x [ранг движения] x 0,07 = [желаемый битрейт]

где ширина и высота изображения выражены в пикселях, а ранг движения представляет собой целое число от 1 до 4, 1 - низкое движение, 2 - движение среды, а 4 - высокое движение (движение - это количество данных изображения, меняется между кадрами, см. связанный документ для получения дополнительной информации).

Так, например, если мы возьмем 1280x720 видео с частотой 24 FPS, со средним движением (фильм с медленными движениями камеры, не так много изменений в сцене...), ожидаемый идеальный битрейт будет:

1280 x 720 x 24 x 2 x 0,07 = 3,096,576 bps = > приблизительно 3000 кбит/с

Это чисто намек, и, на мой взгляд, единственный способ точно найти идеальный битрейт - это пробная ошибка:)

Ответ 2

Он будет сильно отличаться в зависимости от содержимого исходных видео. Я доберусь до этого немного.

640x360 не так уж и велика. 512 Кбит/с очень разумно и, возможно, стандартно. Может быть, 768 кбит/с, если вы действительно заинтересованы в качестве.

Как это возможно? Упрощенный ответ: Существует несколько методов и фактов о сжатии видео, которые делают это возможным:

• Не вся структура видеокадра в общем H.264 (или другие кодеки, если на то пошло) - это полное изображение. Вместо этого существуют два типа, которые в обычном порядке называются
  • Ключевые фреймы: полный рендеринг всего видеоизображения
  • Внутри кадра: описание изменений предыдущего кадра. Эти кадры обычно составляют подавляющее большинство (80% -99%) кадров в видео.
• H.264 является "потерянным" , как и многие другие кодеки. Они не воспроизводят поэтапный, поэтапный точный дубликат исходного исходного видео. Пример: Блоки Lossy: если все, кроме одного пикселя в области, имеют один и тот же цвет, CODEC "теряет" один пиксель. Таким образом, вместо того, чтобы хранить информацию о каждом пикселе в кадре, CODEC просто говорит: "x1, y1 - x2, y2 - весь цвет x". Очень эффективный.

Все это намного сложнее, чем это, с использованием различных подходов, методов и алгоритмов в рамках определенных кодеков и между CODEC, чтобы это произошло.

Итак, вернемся к разделу "Это сильно изменится в зависимости от содержимого исходного видео". Коэффициент сжатия, который вы увидите, и результирующее качество, будут в значительной степени зависеть от:

• содержимое видео
• ваш толерантность к артефактам (блоки, потеря цвета, потеря определения)
• параметры CODEC, которые вы установили, и способы их установки

Пример. Видео с дверью в комнате (например, камерой безопасности) с одним ключевым кадром каждые десять минут будет иметь удивительно высокую степень сжатия. В моих расчетах на основе салфеток этот сценарий был применен при сжатии 15 000: 1.

Поскольку вы начинаете с большого проекта кодирования видео, я бы порекомендовал пару вещей, чтобы определить, какова будет ваша степень сжатия:

• возьмите образец исходных видео, которые вы собираетесь кодировать. 100 или более являются статистически релевантными.
• закодировать их с различными скоростями передачи данных с различными параметрами, чтобы определить, какие итоговые характеристики соответствуют вашим потребностям.

Изменение параметров кодировщика для уменьшения размера видео может также иметь другие последствия:

• более высокие требования к процессору.
• ожидания игроков CODEC. Не все видео, закодированные в формате H.264, могут воспроизводиться всеми игроками.
• более длительное время кодирования
• различное качество

Это очень сложный вопрос. Удачи. Мой опытный тест "большой палец к ветру" говорит, что вы будете более чем счастливы с 512-768 кбит/с для своего проекта.

Ответ 3

Compression Ratio Rules of Thumb
Compression ratios to maintain excellent quality:
– 10:1 for general images using JPEG
– 30:1 for general video using H.263 and MPEG-2
– 50:1 for general video using H.264 / MPEG-4 AVC

из http://www.kanecomputing.co.uk/pdfs/compression_ratio_rules_of_thumb.pdf

Ответ 4

Не забывайте нормальное воспроизведение. MPEG будет использовать только YUV 4: 2: 0. В 8-битной глубине цвета каждый пиксель стоит всего 16 бит (или 64 бит каждые 4 пикселя). Пожалуйста, только RAW файл с камеры будет использовать 16-битную глубину, и он должен стоить миллионы долларов США. Средний уровень DVR для видео может обеспечить только 12-14 бит! И никто не будет использовать H.264 для хранения RAW. H.264 предназначен для конечного продукта.

В 640x360/24p YUV4: 2: 0 битрейт будет стоить:

  640x360x24x(8+4+4)/8 = 10.5MB/s

Для 500 Кбит/с сжатие будет только 172: 1. Это нормально

Для исключения YUV4: 2: 0, читайте:
http://en.wikipedia.org/wiki/Chroma_subsampling

Ответ 5

Просто поделитесь своими знаниями по кодированию с средой H264

Что касается коэффициента 450-512 кбит/с, лучше всего использовать H264 с High 5.0 или High 7.0. Хорошо, я могу предложить вам, чтобы получить хорошее соотношение в балансе с лучшим качеством, ключ, который действительно имеет значение для него, - это играть с размером разрешения.  Результат разрешения видео = 3/4 * Разрешение для исходного/исходного видео

H264 имеет тенденцию потерять детали больше, если вы не сжимаете кадр в меньшем разрешении.