I Love Frontend
С уходом Flash и ростом доли мобильных устройств все большую популярность приобретает html5 видео. В одной из статей мы даже рассказывали о том, как повысить скорость вашего сайта заменив GIF анимации html5 видеороликами. Тем не менее, видео файлы также требуют некоторых оптимизаций, которые необходимо выполнить для того, чтоб эффективно использовать их на сайте. Наиболее важным шагом оптимизации можно назвать оптимизацию видео контента к потоковому воспроизведению на сайте. Без такой оптимизации воспроизведение видео может быть задержано на сотни миллисекунд и мегабайты трафика ваших пользователей будут потрачены впустую из-за безуспешных попыток воспроизвести ролик. В этой статье я расскажу вам, как оптимизировать ваши видео файлы для потокового воспроиведения видео.
Как работает потоковое воспроизведение MP4
Как говорилось в одной из статей HTML5 видео стало кроссбраузерной альтернативой воспроизведению видео через Flash. В 2016 году H.264 кодированое видео в контейнере MP4 (которое дальше будем называть MP4 видео) превратилось в стандартный формат для онлайн видео на сайтах. Потому, когда мы говорим об оптимизации HTML5 видео, то имеем ввиду то, как оптимизировать MP4 видео для быстрого воспроизведения. И дальше мы будем говорить о структуре mp4 файла и том, как работает потоковое видео.
MP4 файлы состоят из блоков данных, именуемых атомами. Есть атомы, которые содержат в себе данные о субтитрах и разделах, есть атомы, содержащие непосредстенно видео и аудио данные. Мета-данные о том, где искать аудио и видео атомы, как воспроизводить видео, размере кадров, битрейте, это все хранится в специальном атоме под названием Moov . Вы можете представить Moov , как своего рода оглавление файла MP4.
При воспроизведении видео плеер (программа для воспроизведения видео) сначала просматривает MP4 файл, находит в нем атом Moov , а затем использует его для того, чтоб найти начало аудио и видео данных и начать воспроизводить их. К сожалению, атомы могут присутствовать в файле в производльном порядке, потому плеер не может заранее знать где находится Moov . Если у вас уже есть все содержимое видеофайла, то плеер может отыскать его. Однако, есть и другой вариант, когда у вас нет всего файла, например, потоковое HTML5 видео. Вся суть потокового видео состоит в том, что вы можете начать его просмотр без необходимости ожидания его полной загрузки.
Для воспроизведения потокового видео ваш браузер запрашивает файл и по мере его получения ищет в нем атом Moov . Если атом Moov не найден в начале файла браузер должен либо загрузить весь файл, чтоб найти этот атом, или начать загружать небольшие части видео-файла, начиная с самого конца файла, в попытке найти Moov .
Такие поиски Moov атома приводят к временным задержкам и расходованию трафика. К сожалению, видео не может быть воспроизведено до тех пор, пока не будет найдет этот самый Moov атом. На скриншоте ниже мы можем видеть запросы браузера к серверу в попытках воспроизвести неоптимизированный MP4 файл как HTML5 видео:
Вы можете видеть, как браузер делает три запроса прежде чем он может начать воспроиводить видео. В первом запросе браузер загружет первые 552Кб видео при помощи HTTP range request. Мы можем судить об этом по коду ответа 206 Partial Content и просматривая заголовки запросов. Однако, атома Moov еще не существует, так что браузер не может начать воспроизведение видео. Затем, браузер запрашивает 21Кб с конца файла используя еще один запрос диапазона данных. В результате полученных данных он находит Moov атом, который сообщает ему каким образом запускать воспроизведение видео и аудио потоков. И наконец, браузер делает третий и последний запрос, для того, чтобы получить содержимое аудио и видео потока. После чего браузер может начать воспроизведение данных. Этот процесс требует около половины мегабайта полосы пропускания канала и откладывает воспроизведение на 210мс. И все только потому, что браузер не может найти атом Moov .
Это может усугубиться, если вы не настроили на своем сервере поддержку запросов HTTP range request. Браузер не сможет загружать файл частями и будет вынужден скачать весь файл для того чтоб найти в нем атом Moov . Это еще одна весомая причина оптимизировать свой сайт для поддержки потокового видео.
Идеальный способ подготовить MP4 файл для потокового воспроизведения HTML5 видео это организовать MP4 файл таким образом, чтоб атом Moov находился в самом его начале. Таким образом, браузер может избежать загрузки всего файла или попыток скачать другие части файла в поисках Moov . Скриншот с запросами для воспроизведения оптимизированного потокового видео представлен ниже:
Видео с Moov атомом в начале файла будет загружаться и проигрываться быстрее, в результате повышая удобство пользования вашим сайтом.
Оптимизация MP4 для быстрой потоковой передачи
Мы уже увидели, что для оптимизации HTML5 видео необходимо реогранизовать атомы MP4 файла таким образом, чтоб атом Moov находился в самом начале. Как же нам это сделать? Большинство программ кодирования видео имеют опцию “оптимизировать для web” или “оптимизировать для потокового воспроизведения”, которые как раз и сделают за нас эту самую оптимизацию. Вы должны следить за настройками кодирования видео, чтоб быть уверенными в том, что получите оптимизированный файл. Например, на рисунке ниже мы видим open source видео кодер Handbrake, который имеет опцию “Web Optimized” в своих настройках. Эта настройка и перемещает атом Moov в начало файла.
Это решает проблему если вы создаете MP4 файл из оригинального исходного видео, но, что, если у вас уже есть mp4 файл?
Вы можете преобразовывать сущестующие видео файлы, чтоб оптимизировать его для потокового воспроизведения. Видеокодер с открытым исходным кодом FFMpeg может реогранизовать сруктуру существующего MP4 файла и размещать Moov в начале файла. В отличие от полного перекодирования файла такой процесс требует меньше ресурсов процессора, так как трансформация файла является более простой операцией. Ниже приведен пример команды для оптимизации файла input.mp4 при помощи утилиты FFMpeg. В результате мы получаем оптимизированный файл output.mp4:
Параметр -movflags faststart как раз и сообщает видеокодеру FFMpeg о том, что необходимо изменить порядок атомов таким образом, чтоб атом Moov оказался в самом начале файла. Также мы использовали опцию copy для того, чтоб FFMpeg скопировал аудио и видео данные, вместо их повторного перекодирования.
Для клиентов сервиса Rigor мы добавили еще один пункт в наш чеклист анализа производительности Zoompf, цель которого обнаружение неоптимизированных для воспроизведения HTML5 файлов MP4 видео. Если просто хотите проверить ваш сайт, вы можете воспользоваться нашим бесплатным сервисом.
Выводы
Если вы конвертируете ваши анимированные GIF в MP4 видео или уже имеете множество MP4 видео роликов, вы можете сделать загрузку и воспроизведение этих роликов быстрее, если проведете оптимизаицю структуры файлов. Изменив порядок атомов и переместив Moov в самое начало файла позволяет браузеу избежать отправки дополнительных HTTP запросов для поиска Moov . Это позволит брузеру мгновенно начать воспроизведение потокового видео. Вы можете настроить эту опцию при первоначальном декодировании файла. Если у вас уже есть существующий файл, то вы можете использовать программу FFMpeg для того, чтоб изенить порядок следования атомов в фйле MP4 без модификации его содержимого.
Understanding the MPEG-4 moov atom: Pseudo-Streaming in Mp4
This article is targeted to anyone who is looking to deliver Mp4 videos over internet. It provides technical details about the metadata that can hamper good encoding and delivery, causing poor playback performance.
An atom is a self-contained data unit containing information about the video file. The moov atom, aka movie atom, defines the timescale, duration, and display characteristics of the movie, as well as sub-atoms containing information for each track in the movie. The optimal location of the moov atom depends on the selected delivery method. This article explains the details around moov atom, and how to properly place it for Mp4 streaming over HTTP.
There are two major methods for video delivery in current age of ‘cord-cutters’, ‘cord-nevers’, short-videos and binged-watched content: progressive download and chunked streaming. Regardless of the method you choose, the experience for viewers is very similar. Your choice depends on your budget, the player you are using, and the type of content e.g. short user-generated videos Vs movies (I will not be talking about the ‘level of content protection needed’ in this article). In this article I will explain the importance of moov atom structure from the perspective of progressive download of Mp4 videos.
Progressive Download
The progressive download method downloads and caches video on the viewer’s device. A short period of time is required to buffer and cache the beginning of the media file before it starts playing. Your player can calculate an appropriate buffer time based on the rate the data is being received and the total length of the video. Once the video has been cached, subsequent viewing does not require any buffering. Generally you would use a content delivery network (CDN) using the standard HTTP protocol to deliver these videos. While this method is efficient when used through CDN for delivery, there is yet another detail to be considered to make the whole playback experience smooth for your end user, called pseudo-streaming which is still progressive download but with a twist.
Pseudo-Streaming
So, what is pseudo-streaming? It is simply a video that can play while it’s being downloaded i.e. it can start playing even before its completely downloaded.
So, in essence the ‘progressive download method used for a video that can play faster’, hence this has to do with your content packaging/ encoding.
Stream packaging is the process of making a multiplexed media file. Also known as muxing, this procedure combines multiple elements that enable control of the distribution delivery process into a single file. Some of these elements are represented in self-contained atoms.
An atom is a basic data unit that contains a header and a data field.
The header contains referencing metadata that describes how to find, process, and access the contents of the data field, which may include (but is not limited to) the following components:
Video frames, Audio samples, Interleaving AV data, Captioning data, Chapter index, Title, Poster, User data, Various technical metadata: codec, timescale, version, preferred playback rate, preferred playback volume, movie duration, etc.
What’s important for pseudo-streaming is that the file metadata (the moov atom) should be at the start of the file rather than at the end. Usually this is an option set when encoding the file (called quick start or fast start).
The moov atom
In an MPEG-4-compliant container, every movie contains a moov atom. Normally, a movie atom contains a movie header atom (an mvhd atom) that defines the timescale and duration information for the entire movie, as well as its display characteristics. The movie atom also contains one track atom (a trak atom) for each track in the movie. Each track atom contains one or more media atoms (an mdia atom) along with other atoms that define other track and movie characteristics.
In this tree-like hierarchy, the moov atom acts an index of the video data. It is here that the MPEG-4 muxer stores information about the file to enable the viewer to play and scrub the file. The file will not start to play until the player can access this index.
Unless specified otherwise, the moov atom is normally stored at the end of the file in on-demand (VoD) content, after all of the information describing the file has been generated. Depending on the type of on demand delivery method selected-progressive download, streaming, or local playback-the location will need to move either to the end or to the beginning of the file.
Since our use case is progressive download or streaming over HTTP, the moov atom will have to be moved to the beginning of the file. This ensures that the required movie information is downloaded first, enabling playback to start right away. If the moov atom is located at the end of the file, it forces the download of the entire file first before it will start playback.
The placement of the moov atom is specified in various software packages through settings such as “progressive download,” “fast start,” “use streaming mode,” or similar options. Software packages such as MP4creator or AtomicParsley enable you to analyze the location of the moov atom in your encoded files. And if you are using ffmpeg, you can do something like
ffmpeg -v trace -i videofile.mp4 2>&1 | grep -e 'mdat' -e 'moov'
This will produce an output like,
[mov,mp4,m4a,3gp,3g2,mj2 @ 000000000036ca40] type:'mdat' parent:'root' sz: 62740 48 65044 [mov,mp4,m4a,3gp,3g2,mj2 @ 000000000036ca40] type:'moov' parent:'root' sz: 2264 62788 65044
Since moov appears second, it is at the end of the file in this example and hence would require moving to start in the interest of the streaming playback experience.
Some tools enable relocation of the moov atom to the beginning of the file’s structure through post processing of the compressed MPEG-4 (MP4) file. One such tool is MP4Creator, mentioned earlier, and another is MP4 FastStart. The best way to handle the moov atom location, however, is to set it during the compression and muxing portion of the encoding process. This minimizes the probability of the moov atom inadvertently being placed at the end.
Importance of moov atom Location
As explained earlier, positioning the moov atom at the beginning of the file structure expedites the playback experience and access to the data payload for decoding and presentation by the player. In case of progressive download, the moov atom data must be received before playback can begin.
Another important reason for having the moov atom at the beginning relates to the file, player, and CDN relationship in streaming. When the user requests a video asset, player requests a “range” at the beginning of the file to get the metadata. If metadata is stored at the end of the file, it then requests a range at the end of the file where metadata is stored, and then it requests the file from the beginning again. Since range requests can overlap, this process of back-and-forth requests may cause rebuffering. This is especially true if the user is watching video randomly or in small segments instead of the entire video from start to finish. Therefore, always encoding or muxing files with the moov atom at the beginning is recommended to avoid rebuffering caused by moov atom location.
Finding moov atom Location and Placing it Properly
Now let’s talk about a scenario where you already have video archive and want to check if it is ‘fit’ to be streamed over HTTP as progressive download.
There are many references and tools that you can use to handle moov atom. In this example I am going to use mediainfo — a lib readily available or downloadable on Linux systems.
Use the following command to check if media is streamable, which would produce an output like the screenshot below (Figure 2):
find .-name "*.m*" -type f | (while read FN; do echo "$FN:$(mediainfo"—Inform=General;IsStreamable: %IsStreamable%" "$FN")"; done)
If files show IsStreamable: No , you can either re-encode or use a utility to move the moov atom.
- Re-encoding takes much longer than using a utility to move the Moov Atom so here’s how we will do it:
- Create new video files with correct config:
for FILE in `find . -type f ` ; do NEWFILE=`echo “$FILE” | sed ‘s/.mp4/_NEW.mp4/g’` ; qt-faststart “$FILE” $NEWFILE ; done
- New files will have ‘_NEW’ in the name
2. Validation: Reverse grep to find old file list: ls | grep -v ‘_NEW’
- If you have other files in the same folder, use the -E in grep and add more extension in search that you want to exclude from reverse-search e.g.:ls | grep -vE ‘_NEW|.jpg|.png|other name/ext in your folder’
3. Delete old Mp4 files, leaving new Mp4s:
for FILE in `ls | grep -v ‘_NEW’` ; do rm $FILE ; done
4. Rename new Mp4s and remove ‘_NEW’ from the name
for FILE in `find . -type f ` ; do NEWFILE=`echo “$FILE” | sed ‘s/_NEW.mp4/.mp4/g’` ; mv “$FILE” $NEWFILE ; done
If you check for the IsStreamable status now, it should show ‘Yes’:
Hope this article helped you to start with your Mp4 delivery workflow quickly.
PS: If you liked the article, please support it with claps ��. Cheers
Предотвращение крашей в медиаконтейнерах
Данная статья предназначена для тех, кто заинтересован в сохранении воспроизводимости своих записей на случай внезапного системного сбоя. Далее будут описаны харатктерные особенности целых и поврежденных файлов, записанных в нескольких наиболее известных форматах как MP4, MOV, MKV, FLV, рассмотрены особенности изменений в структуре файлов при различных условиях записи.
Целые
Данная группа файлов была записана в штатных условиях без угрозы внезапной остановки записи.
Можно заметить, что файл состоит из четырех атомов корневого уровня ftyp, free, mdat, moov, в соответствии со структурой описанной в официальной спецификации формата медиаконтейнера MP4.
Все величины в таблице представлены в байтах. В первом столбце отображено начало блока памяти для каждого атома, во втором — размер данных занимаемых атомом. Таким образом, расположение каждого следующего атома в памяти складывается из размеров всех предыдущих атомов.
Рис. 1 Структура стандартного MP4 файла
Содержимое moov атома имеет особо важное значение для воспроизведения видеоматериала, так как именно в этом месте находится описание информации о том как файл должен быть расшифрован. Для расшифровки файла, чтобы его воспроизвести необходимо установить однозначное соответствие между данными и способами их чтения. Поэтому необходимо знать количество потоков, какой формат данных содержат потоки, какие кодеки совместимы для декодирования. Следует обратить внимание на расположение moov атома в памяти файла. Обычно он расположен в конце файла, что не всегда полезно и безопасно при записи. По этой причине не рекомендуется вести запись в MP4 из-за угрозы получения невоспроизводимого файла в результате внезапного прекращения записи. Такая ситуация возможна при системных сбоях, потере питания и в случае непредвиденного завершения процесса записывающего ПО.
Метаданные извлекаются с помощью ffprobe следующим образом.
ffprobe -hide_banner video.mp4 2> mp4.txt
Рис. 2 Метаданные стандартного MP4 файла
В структуре MOV нет особых различий со структурой MP4, файл все также состоит из четырех атомов корневого уровня, но вместе атома free используется атом wide равный ему по размеру. В таких атомах содержится информация о неиспользуемом пространстве памяти. Узнать подробнее про формат медиаконтейнера MOV можно в официальной спецификации формата медиаконтейнера MOV.
Рис. 3 Структура стандартного MOV файла
В MOV по аналогии с MP4 все метаданные находятся в moov атоме в конце файла.
Метаданные извлекаются с помощью ffprobe следующим образом.
ffprobe -hide_banner video.mov 2> mov.txt
Рис. 4 Метаданные стандартного MOV файла
Структура MKV уже была описана ранее в официальной спецификации формата медиаконтейнера MKV. Основное отличие от прошлых двух контейнерных форматов в том, что данные по умолчанию записываются небольшими фрагментами, вместо одного общего блока информации в случае с mdat для MP4 и MOV. Такая особенность позволяет избавиться от проблемы критического повреждения файлов в случае внезапного прекращения записи, так как метаданные содержатся в каждом отдельном фрагменте.
Метаданные извлекаются с помощью ffprobe следующим образом.
ffprobe -hide_banner video.mkv 2> mkv.txt
Рис. 5 Метаданные MKV файла
Структура MKV уже была описана ранее в официальной спецификации формата медиаконтейнера FLV. В хранении информации используется идентичный способ с MKV. Видео располагается в памяти фрагментами, но содержимое атомов отличается.
Метаданные извлекаются с помощью ffprobe следующим образом.
ffprobe -hide_banner video.flv 2> flv.txt
Рис. 6 Метаданные FLV файла
Поврежденные
Если запись была внезапно прервана есть довольно большая вероятность получить невоспроизводимый файл на выходе.
Рис. 7 Ошибка воспроизведения MP4 файла
Подробнее узнать причину ошибки можно узнать посмотрев логи через ffprobe в консоли
ffprobe -v error video.mp4 2> mp4_error.txt
Лог ошибки выглядит следующим образом для файла
Рис. 8 Лог ошибки для video.mp4
По ошибке “moov atom not found” можно понять, что метаинформацию извлечь не получится, так как не найден moov атом. Дело в том, что запись закончилась раньше, чем планировалось и moov атом физически не был записан в память. Последний доступный атом в данном случае будет mdat.
Рис. 9 Структура поврежденного MP4 файла
Соответственно, если попробовать достать любую метаинформацию файла, то вывод будет пустой
ffprobe -hide_banner video.mp4 2> mp4.txt
Рис. 10 Метаданные поврежденного MP4 файла
В MOV файлах будет наблюдаться похожая ситуация, но как и в прошлый раз разница будет только в названии и размере некоторых корневых атомов структуры. Сам файл воспроизводиться не будет.
ffprobe -v error video.mov 2> mov_error.txt
Рис. 11 Лог ошибки для video.mov
Moov атом здесь не наблюдается, как и в MP4, что не позволяет извлечь метаинформацию
Рис. 12 Структура поврежденного MOV файла
ffprobe -hide_banner video.mov 2> mov.txt
Рис. 13 Метаданные поврежденного MOV файла
Записанный в условиях внезапной остановки записи MKV файл пострадает меньше по сравнению с MP4 или MOV. Его можно будет воспроизвести, но нельзя перемотать и узнать продолжительность в некоторых плеерах. В этом можно убедиться после извлечения метаданных. Значению поля Duaration соответствует N/A, это значит, что оно не было определено. Также отсутствуют значения длительности для видео и аудио потоков и битрейт.
Рис. 14 Метаданные поврежденного MKV файла
Вывод метаданных для поврежденного MKV файла будет сопровождаться сообщением об преждевременном окончании файла, но в данном случае это повлияет лишь на последний фрагмент в течение записи которого была прервана запись.
Рис. 15 Лог ошибки для video.mkv
Поврежденный FLV файл воспроизводится, но так же не имеет определенного значения длины, записанного в поле Duration, как и поврежденный MKV файл, тем не менее информация о начальной отметке времени осталась. Что касается битрейта, то его все также нет. Дело в том, что значения полей Duration и Bitrate вычисляются в самом конце, а не пересчитываются каждый раз после окончания записи каждого отдельного фрагмента, так как это спровоцировало бы дополнительную нагрузку на систему.
Рис. 16 Метаданные поврежденного FLV файла
Вывод поломанного FLV файла содержит несколько больше информации о повреждениях. Видно на каком именно пакете прервалась запись и к какому потоку он относился. В данном случае проблема была обнаружена в момент декодирования пакета в потоке видео с dts = 9734. Более вероятно возникновение ошибки именно в видео потоке, так как обычно объем видеоданных занимает в разы больше места, чем аудио, соответственно и времени на его расшифровку тратится пропорционально больше.
DTS (decoding time stamp) — время декодирования опорного кадра, который требуется для отображения текущего в базовых единицах. Может совпадать с PTS (presentation time stamp) если текущий кадр опорный. Как правило базовая единица задается в виде дроби с числом тактов в числителе и частотой тактового генератора в знаменателе. В итоге в процессе расшифровки декодировщик не может получить доступ к объекту в памяти, потому что его не существует и выполнение чтения заканчивается ошибкой.
Рис. 17 Лог ошибки для video.flv
Записанные с предварительными настройками
Предварительно настроенная запись отличается от обычной, тем что в качестве дополнительной настройки используется параметр faststart, который помогает предотвратить проблему критического повреждения MP4 и MOV файлов путем перемещения moov атома в начало файла. Для MKV и FLV данный параметр не имеет большого смысла, так как в их структуре отсутствует отдельный атом с общими метаданными, как moov.
Рис. 18 Настройки записи в OBS
Теперь подверженный повреждению файл в условиях внезапной остановки записи удалось оставить воспроизводимым и читаемым. На изображении снизу можно изучить структуру полученного после записи файла. На этот раз moov атом был записан в начале файла после ftyp. Раньше он располагался в самом конце после атома mdat.
Рис. 19 Структура записанного MP4 файла
Метаданные вновь читаются, причем значения для полей duration и bitrate определены, несмотря на то, что запись была прервана внезапно.
Рис. 20 Метаданные записанного MP4 файла
В структуре MOV файла произошли изменения в порядке записи корневых атомов, как и в MP4. Moov атом остался неповрежденным и расположен в начале файла. Воспроизведение файла не нарушено.
Рис. 21 Структура записанного MOV файла
Дополнительно убедиться в целостности файла можно после извлечения метаданных
Рис. 22 Метаданные записанного MOV файла
Для MKV файлов особого эффекта параметр “faststart” не имеет, файл имеет повреждения, полученные в результате внезапной остановки записи.
Рис. 23 Метаданные записанного MKV файла
Файл возможно воспроизвести, но как и в прошлый раз без значений длительности и битрейта. Вывод метаданных сопровождается ошибкой.
Рис. 24 Лог ошибки для video.mkv
Никаких особых изменений в лучшую сторону для flv файла использованный параметр не дал. Все старые проблемы остались.
Рис. 25 Метаданные записанного FLV файла
Длительность в результате записи осталась нулевой, битрейт неизвестен, тем не менее файл воспроизводится.
Рис. 26 Лог ошибки для video.flv
Фрагментированные
Еще один вариант предварительной настройки записи, который позволяет добиться фрагментированной записи в файл вместо хранения всей информации в едином атоме.
empty_moov приведет к фрагментации вывода на 100%; без этого первый фрагмент будет мультиплексирован, как короткий фильм (с использованием moov), за которым следуют остальные медиафайлы во фрагментах
frag_keyframe вызывает фрагментированный вывод
Использовав дополнительные параметры, удалось сохранить воспроизводимость файла в условиях внезапной остановки записи. В структуре файла наблюдаются заметные изменения. Moov атом расположен в начале файла, далее следует последовательность из двух повторяющихся практически до конца атомов moof и mdat. В этих двух атомах содержится вся необходимая информация о каждом отдельном фрагменте видео. Moof атом — аналог moov для фрагмента записи, mdat — атом содержащий потоки. Завершается файл атомом mfra.
Рис. 28 Структура фрагментированного MP4 файла
C извлечением метаданных нет особых в данном случае. В метаданных присутствует длительность, тем не менее в некоторых плеерах отсутствует возможность перемотки и не отображается длительность.
Рис. 29 Метаданные фрагментированного MP4 файла
Что касается структуры MOV файла, то она так же сильно изменена и больше напоминает структуру MKV или FLV файлов из-за последовательности фрагментов, записанных в атомы moof и mdat.
Рис. 29 Структура фрагментированного MOV файла
Повреждений метаданных в данном случае не наблюдается.
Рис. 30 Метаданные фрагментированного MOV файла
Особого эффекта или изменений в худшую или лучшую сторону не наблюдается.
Особого эффекта или изменений в худшую или лучшую сторону не наблюдается.
Дополнительная информация
Мультиплексирование в obs осуществляется при помощи ffmpeg, соответственно все указанные в данном примере настройки имели бы следующий вид:
ffmpeg -i input <encoding parameters> -movflags +frag_keyframe+empty_moov out.[mp4/mov]
Пример создания фрагментированного MP4 файла (fMP4) из стандартного MP4 файла
ffmpeg -i video.mp4 -g 52 -c:a aac -c:v libx264 -f mp4 -movflags frag_keyframe+empty_moov fragmented_video.mp4
Альтернативный вариант предварительной настройки записи, который позволяет добиться фрагментированной записи в файл вместо хранения всей информации в едином атоме.
empty_moov приведет к фрагментации вывода на 100%; без этого первый фрагмент будет мультиплексирован, как короткий фильм (с использованием moov), за которым следуют остальные медиафайлы во фрагментах
separate_moof инициирует создание отдельного атома moof (фрагмента видео) для каждого потока. Обычно пакеты для всех потоков записываются в moof atom (что немного эффективнее), но с этой установленной опцией мультиплексор записывает одну пару moof/mdat для каждой потоков, что упрощает разделение дорожек.
frag_keyframe вызывает фрагментированный вывод
omit_tfhd_offset отменяет запись абсолютного значения base_data_offset в атомах tfhd. Это позволяет избежать привязки фрагментов к абсолютным позициям байтов в файле/потоках.
Следующие настройки позволяют создавать фрагментированный MP4 (fMP4), который вы сможете просмотреть во время преобразования. Однако для просмотра будут доступны только фрагменты, полностью закодированные на момент запуска файла. Чтобы просмотреть фрагменты, закодированные после этой точки, вам придется перезагрузить источник просмотра.
Рис. 32 Структура фрагментированного MP4 файла
Аналогично прошлому примеру с фрагментацией файл состоит из последовательности атомов корневого уровня mdat и moof и имеет moov атом вначале.
Рис. 33 Метаданные полученного MP4 файла
Таким образом, данный способ наравне с предыдущим позволяет избежать повреждения метаданных файла в условиях внезапного прекращения записи, что фактически гарантирует возможность дальнейшего воспроизведения файла.
Эти настройки также применимы в случае с MOV файлами и на выходе дают сравнимый результат
Рис. 34 Структура фрагментированного MOV файла
Как результат здесь так же сохраненные метаданные и нормальная воспроизводимость файла
Рис. 35 Метаданные полученного MOV файла
Особого эффекта или изменений в худшую или лучшую сторону не наблюдается.
Особого эффекта или изменений в худшую или лучшую сторону не наблюдается.
Дополнительная информация
Мультиплексирование в obs осуществляется при помощи ffmpeg, соответственно все указанные в данном примере настройки имели бы следующий вид:
ffmpeg -i input <encoding parameters> -movflags +frag_keyframe+separate_moof+omit_tfhd_offset+empty_moov out.[mp4/mov]
Вывод
Чтобы уменьшить вероятность утраты доступа к записанным видеофайлам лучше задуматься сразу над тем, как избежать негативных последствий при возникновении аппаратных или системных проблем на записывающем устройстве. Сделать это можно, выбрав один из более отказоустойчивых форматов записи, как MKV/FLV или, если выходной формат принципиально важен, то воспользоваться одним из методов предотвращения крашей в MP4/MOV из статьи. Восстанавливать убитый файл, гораздо труднее и не всегда возможно. Для тех, кто уже столкнулся с этой проблемой и еще ищет решения возможно будет полезна следующая статья, посвященная теме восстановления MP4/MOV файлов.
Рекомендуемые настройки кодирования на YouTube
Достаточно важным показателем качество видео на YouTube являются именно настройки кодирования. Как раз их мы и рассмотрим ниже.
К счастью, на сегодняшний день, YouTube умеет сам перекодировать видео в автоматическом режиме. Существует несколько рекомендуемых настроек: MP4, AAC-LC, H.264, частота кадров, а также разрешение и соотношение сторон видео.
Но, обо все по порядку.
Настройки контейнера MP4
Есть всего две рекомендуемые настройки для MP4:
- Чтобы видео было обработано корректно, не применяйте монтажные листы.
- Для ускорения запуска видео, размещайте элементы moov atom в самое начало.
AAC-LC – аудиокодек
Для правильного воспроизведения, необходимо указывать:
- Используйте каналы 5.1 + стерео или просто стерео.
- Дискретизация должна быть 48 или 96 кГц.
Настройки видеокодека H.264
У данного видеокодека настроек уже больше, но они не менее важны и их стоит знать.
- Не чересстрочная, а прогрессивная развертка.
- Используйте высокий профиль.
- В-кадры, должны быть последовательны.
- Включите GOP – это закрытая группа изображений.
- Кодирование CABAC – двоичное арифметическое контекстно-адаптивное.
- Битрейты не ограничены.
- Применяйте следующую цветовую субдискретизацию – 4:2:0.
Частота кадров в видео
Частота кадров вашего видео не должна отличаться от той, которая была установлена после кодирования.
Стандартными частотами являются: 24, 25, 30, 48, 50 и другие значения в секундах.
Разрешение и соотношение сторон вашего видео
Здесь нужно помнить, что YouTube имеет соотношение сторон 16:9 – его и нужно придерживаться. Но, если у вас видео содержит другое соотношение, в этом нет ничего страшного. Проигрыватель будет автоматически подстраиваться.
Запись и кодирование видео
Посмотрите видео о том, как правильно записывать и кодировать свой ролик.