> Что означает "Продолжительность кадров", если только звук?

Звук в таких кодеках группируется в пакеты. Поскольку данные сжаты, неким логически законченным целым является не просто отсчет влобовую как в PCM-кодировании, а группа данных, обеспечивающая более-менее корректное декодирование.

То-есть, два байта оторванные от контекста могут иметь какой-то смысл как 16-битный отсчет, или 1 сэмпл сигнала. Но с точки зрения кодека с потерями - два байта никакого физического смысла сами по себе не несут и их нельзя однозначно декодировать во что-то внятное. Минимальным корректно декодируемым юнитом является пакет. Ну или кадр. Как ни назови.

Как правило кодек с потерями пилит входной поток на равные куски (хотя иногда и переменной длины) и жмет с потерями поблочно, при том каждый пакет независим от остальных и порция данных на входе вызвает порцию данных на выходе. Что позволяет работать в каналах с потерями пакетов без жутких искажений, например. Как и просто обеспечивает предсказуемую латентность. Подумайте о том что если компрессор в среднем получает 100 байтов на вход и отдает 20 на выход, вопрос о том а что будет если подать на вхол вот столько байтов и получится ли на выходе нечто что может правильно разобрать декодер - совсем не тривиальный. А для VoIP например плохо когда есть непредвиденная задержка неизвестной величины, никак не ограниченная. Пакетизация решает эту проблему, оговаривая worst case для латентности.

Кроме того, пакетизация позволяет БЫСТРО скипнуть вон те полчаса аудио которые ни на что не влияют и начать декодировать трек с 30m:15s как того хотел юзер. Не декодируя все аудио до этого момента но при этом получив корректный звук. Если бы это был непрерывный поток, такой фокус не прокатил бы - для восстановления состояния декодера хоть немного зависящего от контекста пришлось бы декодить вообще все. Все полчаса и 15 секунд. Ну а юзер бы радостно перся по поводу того что перемотка жрет проц в полку целую минуту, пока проц декодирует аудио в турбо-режиме, спуская отдекодированное в унитаз :)