Как вы определили, « видео » - это, как правило, аудио и видео. Они обычно не собираются вместе, а существуют как отдельные объекты - в вашем случае H.264 и AAC.
Одним из вариантов действительно является наличие двух отдельных файлов на диске, которые вы воспроизводите независимо - именно так часто распространяется контент Digital Cinema .
Это даст такой же опыт для конечного пользователя, но возникнет ряд проблем:
- Есть два файла, которые должны обрабатываться как один " объект " ... Потерять одно или другое, и средства массовой информации непригодны
- Синхронизация аудио / видео может легко потерпеть неудачу, при этом одна будет опережать другую ... если вы не решите это осторожно и явно (например, с использованием временных кодов)
Для решения этих проблем вы можете объединить два (или более) потока в один поток ... ввести понятие « Контейнер ». В этом контексте термин несколько синонимичен с " Mux " или " Multiplexer ".
Можно утверждать, что « мультиплексор » - это логический блок (код), который занимается разделением или объединением потоков, а « формат контейнера » - это способ подготовки и форматирования данных для хранения или передачи.
На более фундаментальном уровне электроники, мультиплексор будет просто помещать один сигнал в линию передачи за один раз.
Существует множество разных контейнеров, которые имеют разные характеристики и преимущества. Ключевые особенности контейнера включают в себя:
- Несколько потоков
- Несколько аудиопотоков - например, языки, аудио, комментарии, каналы (стерео и объемный звук) и т.д.
- Один или несколько видеопотоков - например, точки зрения
- Субтитры
- Метаданные, например: глава, сцена, имя исполнителя / дорожки и т.д.
- Аудио / видео синхронизация
- Индексирование - для облегчения поиска, удивительно сложная тема!
Однако часто также возможно хранить любые произвольные двоичные данные в другом потоке внутри контейнера. Например, Matroska - это невероятно открытый формат, который может поддерживать практически все.
Когда вы говорите, что у вас есть файл .mp4 , вы на самом деле можете не ссылаться на формат контейнера - как правило, если вы можете получить правильное приложение для обработки данных, то оно будет понимать, на что оно смотрит, и обрабатывать его соответствующим образом.
Причина, по которой это все еще работает:
- Поскольку вы используете систему Unix, а тип файла определяется с помощью « Magic » - это указывает, какое приложение использовать для его обработки, а не расширение файла.
- Поскольку вы используете Windows,
.mp4 определяет, какое приложение использовать для обработки файла - VLC (например) впоследствии игнорирует расширение и правильно определяет, что на самом деле ... это файл TS.
- Попробуйте переименовать его
.ts и посмотрите, что получится
- Это смесь между Windows, использующей расширения файлов, и VLC, использующей более волшебную технику для идентификации данных.
Что значит мукс?
Что делается путем мультиплексирования / мультиплексирования видеоданных?
Надеюсь, я в значительной степени рассмотрел это выше.
Причина, по которой вам нужно указать параметр --sout '#http{mux=...}' заключается в том, что VLC будет демультиплексировать файл перед его подготовкой к потоковой передаче. Некоторые форматы контейнеров плохо поддерживают потоковую передачу (например, AVI), поэтому это имеет смысл - теперь у вас есть возможность использовать более подходящий контейнер. Транспортный поток является хорошим кандидатом, и он хорошо понимает, что многие устройства (например, телевизоры) смогут справиться с этим.
Полный конвейер, вероятно, выглядит примерно так:
Что мультиплексор делает с этим?
Мультиплексор отделяет интересные потоки от общего потока и передает их в собственные конвейеры декодирования и рендеринга.
Это просто изменение формата контейнера?
Если вы ссылаетесь на параметр --sout '#http{mux=...}' , тогда да (извините, за мою первоначальную ошибку)... Как упомянуто выше, файл будет в формате ... но этот формат не обязательно хорошо транслируется. Это позволит вам изменить контейнер для облегчения потоковой передачи или набор функций конкретного устройства.
Почему я могу использовать flv-muxing или ts-muxing, и мое видео в любом случае передается без проблем?
Поскольку это изменяет формат контейнера между сервером и клиентом, а не формат контейнера, который сервер использует для чтения исходного файла.
Почему я могу изменить имя файла с mp4 на ts?
Поскольку магия просматривает данные в файле, чтобы установить, что это такое - в системах Unix расширение файла - это просто подсказка для людей, которые могут использовать.
Как я могу проверить фактический формат контейнера файла?
Используйте file утилиту - она использует магию для идентификации (отпечатка пальца) файла и сообщает вам, что это лучшее предположение. Например, этот файл использует контейнер QuickTime :
$ file big_buck_bunny_720p_h264.mov
big_buck_bunny_720p_h264.mov: ISO Media, Apple QuickTime movie, Apple QuickTime (.MOV/QT)
Если вы хотите знать больше, чем просто то, как содержатся данные - например, какие потоки находятся в файле или какие кодеки используются, - вам нужно проверить файл с помощью VLC, GStreamer, FFmpeg или другого инструмента. Например, у него есть три потока:
- Видео - h.264, 1280x720
- Информация о временном коде
- Аудио - AAC, 48 кГц, 5.1-канальный объемный звук
$ ffprobe big_buck_bunny_720p_h264.mov
ffprobe version 2.8.14-0ubuntu0.16.04.1 Copyright (c) 2007-2018 the FFmpeg developers
---8<--- snip --->8---
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'big_buck_bunny_720p_h264.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
creation_time : 2008-05-27 18:36:22
timecode : 00:00:00:00
Duration: 00:09:56.46, start: 0.000000, bitrate: 5589 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720, 5146 kb/s, 2 4 fps, 24 tbr, 2400 tbn, 4800 tbc (default)
Metadata:
creation_time : 2008-05-27 18:36:22
handler_name : Apple Alias Data Handler
encoder : H.264
Stream #0:1(eng): Data: none (tmcd / 0x64636D74) (default)
Metadata:
creation_time : 2008-05-27 18:36:22
handler_name : Apple Alias Data Handler
timecode : 00:00:00:00
Stream #0:2(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 437 kb/s (default)
Metadata:
creation_time : 2008-05-27 18:36:22
handler_name : Apple Alias Data Handler
Почему необходимо мультиплексировать файл для потоковой передачи через VLC?
Я думаю, что я уже рассмотрел это, но просто чтобы прояснить ... это допускает гибкость. Операции demux / mux довольно легки (по сравнению с полным декодированием), поэтому, конечно, это не проблема.
Если бы вы попытались обслужить файл AVI без повторного смешивания, у вас возникли бы значительные проблемы при попытке декодировать его на клиенте (скорее всего, он вообще не работал бы).
Точно так же, если вы нацелены на устройство, которое может только демультиплексировать транспортный поток, то повторное смешивание из MP4 в TS позволит декодировать мультимедиа не на этом устройстве.
