Можете ли вы написать видеофайл с неупорядоченными (входными) кадрами?

Поскольку мы предполагаем, что PTS и DTS могут быть разными, я предполагаю, что вы хотите иметь дело с форматом, который содержит B-кадры как часть межкадрового формата, такого как H.264 (AVC) или аналогичный. Межкадровый формат сжимает различия между кадрами, а не весь кадр. Таким образом, обычно кадр P зависит от предыдущих кадров, а кадры B зависят от предыдущих и будущих кадров. Таким образом, вы не можете изменить порядок кодирования или передачи. Таким образом, невозможно кодировать несколько кадров параллельно, поскольку вам нужны ранее закодированные кадры для кодирования текущего кадра.

Если у вас есть сценарий VOD (не в прямом эфире), вы можете разделить входные данные на группы кадров (GOP) и кодировать несколько GOP параллельно.

Предположим, длина вашей GOP (настройка кодировщика) равна 10, и вы хотите запустить 3 параллельных кодирования. Затем вы можете параллельно закодировать кадры 0–9, 10–19 и 20–29, а затем повторно объединить фрагменты.

Если вас волнует, правильно ли воспроизводится/декодируется полученное видео, то нет, вы не можете писать не по порядку, как говорит Маркус.

Но точное кодирование/декодирование — не единственная проблема. Даже если вы использовали формат кадров внутрикадрового сжатия, такой как MJPEG, проигрыватели обрабатывают и выводят декодированный контент в том порядке, в котором он предоставляется декодером. Порядок декодирования каждого пакета и порядок представления не всегда совпадают, это правда, но, например, в ffmpeg/libav, когда вы вызываете avcodec_decode_video2, контекст сохраняет свое состояние по мере декодирования большего количества пакетов; как только данных будет достаточно для полных кадров, он предоставит их вам в том порядке, в котором вы должны их воспроизвести. Он не имеет ни малейшего представления или беспокойства о том, что в будущем могут появиться кадры, которые должны были отображаться раньше, чем тот, который он вам дает.

После декодирования кадры попадут в очередь воспроизведения. На этом этапе игрока обычно не волнует абсолютный PTS; для видео он будет использовать разницу PTS между текущим кадром и следующим кадром исключительно для определения того, как долго удерживать текущий кадр. Он не способен заглянуть вперед не больше, чем декодер (а если и умеет, то, конечно, не так далеко), чтобы увидеть, есть ли кадры, поступающие с более ранним PTS. А что касается аудио, он может полностью игнорировать PTS после начала воспроизведения и синхронизации видео и звука — или, если он действительно просматривает PTS, это будет исключительно для обработки пробела в дорожке. В любом случае, если игрок позже получит PTS, более ранний, чем текущий кадр, я ожидаю, что он либо отбросит его, либо выдаст ошибку из-за целочисленного переполнения.

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

К вашему сведению, источник медиаплеера VLC демонстрирует почти все, что нужно знать о воспроизведении видео и ffmpeg/libav, и является моделью для изучения, если вы хотите знать, как работают плееры.

Если вам вообще нужен совет по производительности, вы можете и должны кодировать каждую дорожку в отдельном потоке с собственной очередью вывода, регулируя одну или другую, если она слишком сильно опережает другую, а третий поток записи выполняет всю работу. чередовать при записи на диск. Вы также можете сделать обратное на стороне чтения, всего 6 потоков. Но вам все равно придется делать это линейно по отношению к каждой дорожке; обойти это невозможно, если вы хотите, чтобы игра корректно воспроизводилась в любом стандартном проигрывателе.