Я читал о сжатии видео. Я понимаю, что размеры «сырых» медиафайлов слишком велики для практического использования, поэтому их необходимо сжимать, но мне интересно, что происходит при воспроизведении видео.
Я имею в виду, все ли видео декодировано (распаковано) и сохранено где-то в памяти (это не кажется возможным) или отдельные кадры декодируются по одному, а затем забываются, так что, когда вы хотите воспроизвести часть видео, вы нужно еще раз расшифровать?
Вероятно, это очень нубский вопрос, потому что я один из них, поэтому буду признателен за любую информацию.
В большинстве распространенных схем сжатия нет соответствия 1::1 между кадрами «видео» и кадрами «файла» (или потока)**. Любой конкретный видеокадр может потребовать, чтобы содержимое нескольких файловых кадров стало полным видимым изображением. Таким образом, проигрыватель будет читать и буферизовать столько файловых кадров, сколько необходимо для восстановления рассматриваемого видеокадра. Плеер может буферизовать гораздо больше, но это не обязательно.
Например, если какой-то видеокадр оказывается P-кадром при кодировании в файле, игроку нужно будет оглянуться назад, чтобы найти предыдущий I-кадр, декодировать его, а затем применить различия, закодированные в промежуточных P-кадрах, чтобы получить полное результат.
** РЕДАКТИРОВАТЬ: Конечно, для каждого видеокадра существует файл кадра, но дело в том, что обычно вы не можете прочитать один кадр из файла и получить полный видеокадр: это верно только для I-кадров.
Идея состоит в том, чтобы иметь возможность передавать данные и воспроизводить их на простом устройстве (например, на «DVD-плеере»). Глупое устройство, как правило, будет использовать как можно меньше оборудования, поэтому наверняка у вас не будет достаточно памяти, чтобы распаковать весь фильм, а затем воспроизвести его. Кроме того, это займет целую вечность, чтобы начать. Концепция потоковой передачи означает, что вы хотите, чтобы данные воспроизводились по мере их поступления.
Насколько я понимаю, H.264 состоит в том, что у вас есть один кадр, называемый I-Frame, который вы можете распаковывать самостоятельно. По сути, это изображение JPEG в вашем файле фильма.
Следующие кадры будут P-кадрами, которые используют предыдущий кадр для создания нового кадра. Более или менее, если на вашем экране движется только персонаж, вам просто нужно стереть символ там, где он был, и визуализировать его таким, какой он есть сейчас. Остальная часть экрана может оставаться неизменной. В этом случае вы можете очень сильно сжать данные изображения этого одного кадра (т. е. I-кадр может иметь размер 250 КБ в фильме 4K, тогда как P-кадр может быть всего 2 КБ).
Кроме того, схема сжатия H.264 поддерживает B-кадры (двунаправленные). Это немного сложнее. Это означает, что кадр может быть распакован только после распаковки какого-то будущего кадра. Это означает, что устройство, распаковывающее кадры, должно иметь возможность кэшировать больше распакованных кадров, чем только последний I-кадр и последний P-кадр (и, насколько мне известно, P-кадры могут ссылаться на более старые P-кадры, чем тот, который был непосредственно перед этим). ).
Каждый декодер будет иметь ограничения на то, что он может сделать. Например, я использую Jetsons для создания встроенной системы, и они поддерживают только видео, сжатое в формате 4:2:0 (2 байта цветности на каждые 4 пикселя). Количество буферов, которые имеет декодер, и поддержка B-кадров — это другие функции, которые могут работать или не работать в зависимости от декодера.
Гьян