I. Обзор
В этой статье в основном представлены некоторые проблемы в процессе воспроизведения аудио и видео, а также методы оптимизации для конкретных проблем.
2. Знакомство с нештатными ситуациями и причинами
- Заикание, недостаточная пропускная способность восходящей или нисходящей сети для воспроизведения, недостаточная производительность устройства, проблема с отметкой времени видеопотока
- Размытый экран, возможно размытие или мозаика всего изображения, неправильная настройка параметров sps/pps, потеря P-кадра или сбой декодирования, что приводит к частичному размытию изображения на экране.
- Зеленый экран, сбой или ошибка сбора данных sps/pps, некоторые необработанные изображения заполнены черным цветом, некоторые — зеленым, а некоторые — предыдущим кадром. Если параметры видео изменены, а информация SPS&PPS об окончании декодирования не обновляется вовремя, изображение не может нормально воспроизводиться, что, в свою очередь, приводит к появлению зеленого экрана.
- Пропуск отражается в прерывистости аудио или видео во время воспроизведения —> то есть в прерывистости меток времени. В основном из-за управления буфером, синхронизации аудио и видео, некоторых активных стратегий пропуска кадров или узких мест в производительности.
- Недопустимое перетаскивание, позиция поиска недопустима, позиция поиска рассчитана неправильно (ошибка индикатора выполнения, ошибка временной метки или неправильная продолжительность всего видеофайла)
- Слишком большая ошибка перетаскивания, слишком большая GOP
- Черный экран, звук есть, но картинка черная.
- Скорость нарезки ненормальная (переключение в режиме инкогнито), что в целом показывает, что она не может быть отрендерена, или экран размыт, или трансляция пропущена, или экран черный. На самом деле некоторая информация выставляется некорректно/не сбрасывается при переключении между разными потоками кода.
- Отсечь ток, кроме установки порога отсечки и переподключения при превышении порога, хорошего способа не придумал. Но при реализации переподключения нужно разобраться со многими деталями.
- Аудио и видео не синхронизированы, и алгоритм синхронизации не обрабатывается должным образом, что приводит к большой разнице между отметкой времени аудио и отметкой времени видео. Но есть и физическая асинхронность между звуком и изображением, например, источник звука находится слишком далеко от микрофона, а скорость звука намного меньше скорости света (не слишком далеко от микрофона). Или модуль обработки звука в процессе приобретения слишком долго (нет возможности).
- Аномальные звуки, такие как изменение голоса, шум, эхо, разрывы звука, эти явления. Прежде всего, помимо неправильной обработки таких модулей, как шумоподавление, эхоподавление, автоматическое усиление и передискретизация, также могут быть ошибки в кодеке и параметрах рендеринга сбора или воспроизведения.
- Воспроизведение не удается по ряду причин. Ошибка входа в поток распространения, ошибка возврата внутреннего интерфейса воспроизведения, сбой бизнес-уровня для создания контейнера воспроизведения, ошибка создания проигрывателя, ошибка состояния потока, недопустимый URL-адрес воспроизведения и ошибка разрешения DNS. все ошибки, связанные с бизнесом (сторонними организациями). На уровне воспроизведения к ошибкам, которые могут привести к сбою воспроизведения, относятся сбой подключения к узлу CDN, ошибка чтения пакета, ошибка декодирования, прерывание сети на стороне проигрывателя, простой или высокая нагрузка сервера потоковой передачи, прерывание исходного потока и т. д.В реальных промышленных сценариях мы обычно считаем, что ошибки, которые могут быть устранены в течение порогового времени, не считаются сбоями воспроизведения.
- Длительное время первого кадра, время инициализации проигрывателя, время внутреннего интерфейса, время анализа DNS, планирование узла cdn, время анализа метаданных, время инициализации декодера и пороговое значение буфера для очереди воспроизведения, чтобы начать отправку данных в средство визуализации, и все это будет результат в первом кадре.слишком длинный.
- Задержка большая, в основном из-за трудоемкого кодирования конца захвата, затрат времени на восходящую линию передачи (если это tcp, будет механизм подтверждения и повторной передачи, что займет больше времени), отнимающее много времени транскодирование, отнимающее много времени распространение на узел cdn и отнимающее много времени нисходящее соединение.
- Совокупная задержка обычно относится к восходящей или нисходящей передаче с использованием протокола потоковой передачи мультимедиа на основе протокола TCP.Из-за сетевого дрожания и механизма повторной передачи TCP задержка будет продолжать накапливаться и увеличиваться.
- Когда мобильный телефон горячий, это чаще происходит на стороне захвата, а также при высокой скорости передачи данных на стороне воспроизведения. На самом деле, загрузка процессора слишком высока или использование памяти слишком велико.Панорамные и VR-сцены также могут иметь высокую загрузку видеокарты. Например, конструкция буфера неразумна, данные часто копируются, временная сложность алгоритма слишком высока, кодирование и декодирование слишком зависят от вычислений ЦП, объем данных рендеринга слишком велик, вычисление преобразования в процесс рендеринга слишком велик, алгоритм кодирования не соответствует конфигурации машины, есть некоторые слишком высокая точность данных.
- Воспроизведение записанного видео происходит ненормально, обычно из-за неправильной настройки параметров кодирования аудио и видео во время записи или ненормальной временной метки.
- При воспроизведении заставки часто происходит переключение между стабильным изображением и объединенным изображением, что дает пользователю ощущение дрожания изображения.
3. Метод оптимизации
Для каждого исключения или точки оптимизации решите и оптимизируйте один за другим:
1. Катон
- Оптимизация восходящего потока для устранения зависаний исходного потока. Например, оптимизация конфигурации производительности конечного устройства потоковой передачи, оптимизация производительности конечного устройства потоковой передачи, жесткое кодирование и выбор ближайшего узла CDN для границы потоковой передачи.
- Буферизация дрожания, балансировка заиканий и задержек.
- Загрузите оптимизацию ссылок, выберите более близкие и лучшие пограничные узлы CDN.
- Для пользователей с серьезными зависаниями воспроизведения или когда нагрузка CDN слишком высока, серверная часть прямой трансляции отправляет сообщение, чтобы заставить клиента снизить скорость передачи данных. Сам клиент также может принудительно снизить битрейт после обнаружения продолжительных зависаний.
- Сторона воспроизведения использует жесткое декодирование для оптимизации производительности декодирования.
- Нижний уровень оценивает изменения в сети, восстанавливает соединение с CDN и выполняет переключение инкогнито (переключение каналов).
- Выбор и комбинация протокола TCP и протокола UDP. Протокол TCP надежен, но при нестабильной работе сети будет выполняться много повторных передач, что приведет к более серьезным перегрузкам. Протокол UDP лучше адаптируется к джиттеру сети, но могут быть проблемы с неупорядоченными пакетами и отбрасыванием пакетов.
- Следует учитывать переменные скорости передачи данных, такие как платформы транскодирования и проигрыватели, которые могут поддерживать адаптивную потоковую передачу с истинной скоростью передачи данных. В противном случае также может быть принято компромиссное решение: клиент оценивает изменения в сети, а нижний уровень проигрывателя устанавливает соединение с кодовым потоком низкого разрешения CDN, получает данные низкого разрешения, декодирует их и отдает на верхний. слой для рендеринга (реализация поддельного многоуровневого кодирования). После восстановления сети переключитесь обратно на исходный поток. Таким образом, нет необходимости вносить серьезные изменения в протокол или методы транскодирования и декодирования, но это может увеличить нагрузку на CDN, а логика загрузки, декодирования и синхронизации SDK воспроизведения будет более сложной.
- Многоуровневое кодирование сложно реализовать в сценариях прямых трансляций, но его тоже стоит учитывать при воспроизведении по запросу. Основная причина в том, что требования к алгоритмам транскодирования и декодирования различны.
- Вставьте поддельные данные, например, вставьте несколько плавных звуковых кадров и вставьте кадры, когда изменения изображения малы. Сложно реализовать.В первую очередь нужно судить о пороге выполнения вставки кадров по времени.Иначе опыт будет плохой,или вставлять кадры будет поздно.Необходимо рассмотреть модификацию метка времени и синхронизация аудио и видео, чтобы определить, какие точки вставлять аудиокадры и какие точки.Вы можете вставлять видеокадры, как переключаться после того, как ссылка для загрузки вернется в нормальное состояние, и снова откалибровать метку времени. Эта часть может относиться к тому, как вставлять кадры для сигнала на дальнем конце, когда сигнал на дальнем конце не синхронизирован с сигналом на ближнем конце во время подавления эха.
- Проблема беспорядка меток времени (например, откат меток времени видео), в этом случае, если вы непосредственно следуете строгой стратегии синхронизации аудио и видео, некоторые кадры видео могут быть напрямую отброшены и не отрендерены, поэтому изображение будет поставлено на паузу (зависнет). ) до тех пор, пока временные метки не вернутся в нормальное состояние. В это время вы можете увеличить буфер и настроить временную метку так, чтобы она монотонно увеличивалась.
2. Хуапин
- Для мозаики, вызванной низким битрейтом, нет другого пути, кроме как согласовать текущее разрешение с подходящим битрейтом.
- Узкое место в производительности видеокарты, оптимизация логики кода модуля рендеринга, например панорамы и воспроизведения VR, может быть обновлена локально
- Получение информации о декодировании sps/pps невозможно или неверно.В случае масштабируемого кодирования или многопоточности, если разрешение и другие данные изменяются, но не обновляются вовремя, экран может быть размытым (некоторые модели отображаются как зеленый экран). Модификация информации о декодировании в основном происходит от службы транскодирования (например, в flv по умолчанию только заголовок видео, загружаемый в начале воспроизведения, имеет информацию sps/pps. Если информация о кодировании изменяется в середине, видео заголовок не будет отправлен повторно по умолчанию. ), я чувствую, что если сервер просто перекодирует вместо перекодирования, легко может возникнуть такая проблема.Если сервер выполняет перекодирование, он может добавить AVCDecorderConfigurationRecord, когда исходный поток переключает информацию о декодировании .
- Некоторые эталонные кадры потеряны.Возможно, захват/проигрыватель имеет политику потери кадров и ссылаются на отброшенные кадры.Также возможно, что принимающий буфер SO_SNDBUF сервера потокового мультимедиа слишком мал, и некоторые кадры, полученные при дрожание сети восстанавливается, отбрасываются, и на эти кадры ссылаются, что приводит к частичному размытию экрана. В сценарии UDP, конечно, также возможно, что ненадежность передачи приводит к потере пакетов.
- Параметры инициализации декодера или логические ошибки обработки вызывают сбой декодирования, и делается ссылка на кадр, который не удалось декодировать. Неверные параметры инициализации кодировщика на стороне потоковой передачи также вызывают исключения кодирования.
- Совместимость хард-кодов и хард-кодов некоторых моделей андроидов недостаточна.Когда кодирование/декодирование ненормальное, это не обнаруживается.Это можно установить только исходя из исторического опыта.Черный список
- Параметры, переданные модулю рендеринга, не являются фактическими параметрами, это ошибка.
- При перетаскивании или сбросе параметров декодера очередь декодирования не очищается
3. Зеленый экран
- В случае сбоя или ошибки при получении информации о декодировании sps/pps может появиться зеленый экран. (засветить экран)
- Во время жесткого декодирования ios videotoolbox не может проанализировать кадр, который разделен на несколько единиц NALU, поскольку жесткий декодер ios считает такой кадр неполным. Плеер может скопировать все данные в нескольких NALU этого кадра (см. формат nalu в H264) в AVPacket перед отправкой в videotoolbox, а затем подключить его к videotoolbox. Примечание. Когда на стороне сбора данных включена функция mutli-slice, некоторые видеокадры в исходном потоке будут разделены на несколько фрагментов и сохранены в разных NALU, поэтому возникает эта проблема.
4. Пропустить
- Из-за управления буфером на стороне сервера и узких мест в производительности, если буфер заполнен и сервер потоковой передачи не может обработать данные в буфере, он отбрасывает некоторые данные в исходном потоке, что приводит к пропускам на стороне игрока. Если операции чтения и записи на жестком диске не успевают за данными, обрабатываемыми ЦП во время видео или живого воспроизведения и записи, некоторые кадры могут быть отброшены напрямую, что приведет к пропуску.
- Если использование ЦП проигрывателем слишком велико, например, слишком высокая скорость использования или слишком высокая частота доступа, возникает узкое место в производительности, и некоторые данные могут быть напрямую отброшены.
- Из-за синхронизации аудио и видео, если происходит откат метки времени, плеер по умолчанию напрямую отбрасывает кадры в процессе отката. Или, если временные метки аудио и видео слишком сильно различаются, некоторые кадры также могут быть пропущены для синхронизации эталонных часов.
- Стратегия активного пропуска кадров приводит к принятию стратегии пропуска кадров, чтобы сбалансировать скорость/задержку кодека/передачи по сети/воспроизведения, что может привести к пропуску, например постоянному отбрасыванию аудиокадров с ключевыми звуковыми сигналами или постоянному отбрасыванию видеокадров. Наиболее очевидным является отбрасывание GOP.
- Ненадежная передача UDP приводит к нарушению порядка и потере пакетов.Если пришел кадр, соответствующий внешнему эталонному тактовому сигналу, промежуточный кадр будет отброшен. Механизм UCCP можно разработать, обращаясь к TCP для проверки последовательности пакетов, и, подобно SRT, клиент активно отправляет запрос NACK для повторной передачи.
5. Перетаскивание недопустимо
Реализация поиска в ffmpeg может относиться к файлу в прошлой частиhow to seek in mp4/mkv/ts/flv. [Примечание: личный опыт перетаскивания в FLV без списка ключевых кадров будет очень медленным, очень медленным, очень медленным. ] Обычно поиск представляет собой индикатор выполнения, отображаемый пользователем, перетаскивающим внешний интерфейс.Верхний уровень проигрывателя вычисляет seekTime=(позиция индикатора выполнения/общая длина индикатора выполнения) * общая продолжительность видео, а затем передает его ядру воспроизведения. Если seekTime не соответствует фактической общей продолжительности видео, поиск будет недействительным, что обычно не является проблемой без ошибок. При поиске вперед, поскольку данные не буферизуются, если скорость загрузки слишком низкая и данные не буферизировались в течение определенного периода времени, также можно запустить механизм перезапуска внутри проигрывателя, чтобы отменить этот поиск.
6. Ошибка перетаскивания слишком велика
Принцип поиска состоит в том, чтобы найти кадр I, ближайший к позиции seekTime. GOP=n*fps, чем больше значение n, тем дальше seekTime от фактической точки позиционирования (в среднем). [Обратите внимание, что очередь буфера декодирования должна быть очищена после операции поиска]
Если общая длина видео велика, то необходимость в точном поиске не очень актуальна, пока GOP не слишком велика. Если общая продолжительность видео небольшая или экран часто переключается (например, во время занятий спортом на открытом воздухе), может потребоваться точный поиск.
Вы можете сначала найти предыдущий I-кадр seekTime, декодировать I-кадр и данные после него и поместить их в очередь воспроизведения, пока не появится кадр, которому принадлежит временная метка seekTime. (Может показаться, что поиск занимает слишком много времени, но в целом это нормально, потому что GOP не нужно задавать особенно большим в этом сценарии)
7. Черный экран
- Если в исходном потоке нет изображения, возможно, стороне потоковой передачи не удалось захватить изображение или произошла ошибка кодирования.Вы можете добавить логику обнаружения в модуль кодирования.
- Если декодирование постоянно дает сбой, проигрыватель может не поддерживать определенный формат, что требует улучшения механизма обратного вызова для уведомления верхнего уровня о сбое декодирования. Нижний уровень может попытаться сбросить декодер самостоятельно или восстановить соединение.
- Некоторые форматы кодирования и инкапсуляции push-end не являются стандартными, что также является проблемой исходного потока.
- Бизнес-уровень стримингового конца переключает режим чистого аудиопотока/аудио- и видеопотока, если это сначала чистый аудиопоток, а потом он нарезается на аудио- и видеопоток, потому что плеер не будет переинициализировать декодер по умолчанию, это вызовет черный экран на стороне игрока. . Можно увеличить определение того, есть ли в плеере новый формат кадра, и добавить логику повторной инициализации декодера при воспроизведении. Или сервер отправляет уведомление.
8. Ненормальная скорость резки
Вообще то не рендерится, или экран размыт, или трансляция пропускается, или черный экран и тому подобное. На самом деле некоторая информация выставляется некорректно/не сбрасывается при переключении между разными потоками кода.
9. Отключить
Прерывание потока неизбежно повлияет на качество воспроизведения, поэтому мы можем только восстановить его как можно быстрее и обеспечить нормальное воспроизведение после восстановления.
- Циклическая настройка обнаружения прерывания потока (для различных ситуаций, таких как прерывание исходного потока или ссылка на загрузку плеера)
- Закройте исходное потоковое соединение, очистите некоторые ненужные данные и закройте avformat.
- Повторно открыть поток и получить данные декодирования аудио и видео.
- Восстановите потоковое соединение и начните чтение аудио- и видеоданных.
- Во время этого процесса find_stream_info сбрасывает параметры декодирования, что может привести к удвоению скорости воспроизведения после восстановления и т. д. Лучше всего оставить исходные параметры декодирования без изменений. Конкретный принцип неизвестен
10. Аудио и видео не синхронизированы
Ссылаться наПринцип и реализация аудио и видео синхронизации
11. Ненормальный звук
- Для части предварительной обработки звука вы можете использовать модуль обработки звука webrtc, который намного лучше, чем speex, и увеличение громкости sdk приемлемо. Ссылка на ссылку:подавление шума эхоподавление ремикс Обнаружение тишины
- Кодек, частота дискретизации и параметры рендеринга захвата или воспроизведения неверны. Инженерная реализация должна обратить внимание на решение этих проблем.
- Если звук прерывается из-за пропуска, обратитесь к разделу обработки пропуска.
- Прерывистый звук или изменение высоты тона, вызванные потерей кадров, в основном вызваны неправильной настройкой стратегии потери кадров. Например, если частота потери кадров высока, у вас будет одна остановка. Если вы одновременно отбросите много аудиокадров, связанных во временном ряду, у вас будет опыт пропуска. Если вы не потеряете звук и только при потере видео звук может измениться Алгоритмы изменения высоты тона, такие как WSOLA.
12. Не удалось сыграть
- Поскольку причин сбоя воспроизведения может быть много, самое главное — это безупречность сбора лога.
- Для ошибок, связанных с бизнесом верхнего уровня (третья сторона), соответствующие стороны модифицируются посредством анализа журнала.
- Если соединение с узлом CDN не удается, вы можете попробовать разрешить DNS, чтобы вернуть несколько IP-адресов.После того, как клиенту не удастся повторить попытку с определенным IP-адресом, он использует другие IP-адреса для установления соединения.
- Ошибка чтения пакета, если это не AVERROR_EOF, пакет обычно отбрасывается напрямую, но высокая частота или непрерывная ошибка чтения пакета серьезно повлияют на качество воспроизведения пользователя и заставят пользователя покинуть живую комнату в ненормальном состоянии воспроизведения (это вид из нас Считается, что воспроизведение не удается), когда ошибка чтения пакета накапливает определенное количество, соединение может быть восстановлено, чтобы предотвратить невозможность возобновления нормального воспроизведения. Повторно подключитесь напрямую при возникновении ошибки AVERROR_EOF.
- Ошибка декодирования, общая ошибка декодирования будет отражена как исключение рендеринга, пожалуйста, обратитесь к чтению ошибки пакета для метода обработки
- Прерывание сети на стороне воспроизведения фактически частично перекрывает предыдущую ошибку чтения пакета, и все еще есть переподключение по тайм-ауту.Увеличьте период тайм-аута и измените стратегию переподключения канала при достижении порога.
- Когда сервер потоковой передачи не работает или нагрузка слишком высока, отчеты журнала можно использовать только для анализа после смерти. В основном за счет мониторинга самой службы потоковой передачи для достижения стабильности всего кластера.
- Если исходный поток прерван, это может быть связано с тем, что потоковая сторона отключена аварийно или восходящая линия связи прервана.Вы можете выполнить некоторую обработку ошибок на стороне потоковой передачи.
13. Длительное время первого кадра
- Предустановленный формат воспроизведения, если URL-адрес уже содержит некоторые параметры декодирования аудио и видео, вы можете предварительно настроить iformat, чтобы начать декодирование заранее.
- Предварительное разрешение DNS, бизнес-уровень может отправить запрос на сервер планирования во время инициализации проигрывателя.
- Оптимизация расписания CDN, оптимизация ссылок для скачивания
- Парсинг метаданных flv упрощается, потому что аудио и видео теги flv уже содержат много информации, а верхний слой также может предустановить некоторую информацию при инициализации плеера, так что вы можете парсить метаданные во время чтения_frame без ожидания.
- Оптимизация ожидания и синхронизации во время процесса запуска воспроизведения, например, уменьшение длины очереди буфера пакетов, отсутствие ожидания (запуск при подготовке) во время процесса подготовки и принудительное обновление
14. Большая задержка (прямой эфир)
- Сеть на стороне захвата является адаптивной, и кадры отбрасываются, когда сетевая среда крайне плохая Требования к конструкции высоки, и необходимо учитывать влияние на непрерывность данных исходного потока. По поводу потери кадров на стороне захвата и на стороне воспроизведения можно написать отдельную статью. Если отбрасывается I-кадр, необходимо отбрасывать всю группу G. Если отбрасывается P-кадр, рассматривается последний P-кадр в GOP, а B-кадр может быть отброшен напрямую. Примечание. Конец захвата в приложении веб-трансляции обычно не кодирует B-кадры.
- Оптимизация производительности кодирования и оптимизация логики кода в конце сбора для уменьшения задержки кодирования, вы можете установить несколько срезов
- Конец сбора использует более высокий протокол реального времени, такой как RTP или пользовательский UDP.
- В конце захвата используется VBR с переменной скоростью передачи данных.Когда изображение изменяется меньше или пропускной способности сети недостаточно, скорость передачи данных уменьшается, а в другое время поддерживается или увеличивается скорость передачи данных.
- Оптимизация планирования узла CDN платформы транскодирования гарантирует, что время соединения с терминалом сбора будет как можно короче, а передача по сети будет эффективной и стабильной.
- Платформа транскодирования оптимизирует производительность транскодирования, уменьшает задержку, вызванную декодированием и повторным кодированием, и разделяет задачи с различными требованиями к реальному времени и коэффициенту сжатия.
- Оптимизация планирования узлов загрузки, оптимизация производительности и нагрузки после распространения CDN
- Сеть адаптируется к стороне воспроизведения и теряет кадры, подобно стратегии потери кадров на стороне захвата. Как правило, после отбрасывания аудиокадра сравнивают метку времени с видеокадром и аудиокадром, а затем выбирают номер отброшенного P-кадра на основе предпосылки нормального декодирования и рендеринга. Если разрешение и другая информация, необходимая для декодирования, известны, вы можете рассмотреть вопрос об отбрасывании кадра перед непосредственным декодированием (если кадр будет удален до декодирования, неправильная работа приведет к пропуску и размытию/зеленому экрану)
- При воспроизведении с удвоенной скоростью на стороне воспроизведения звук будет изменять высоту тона, и его необходимо обрабатывать без изменения высоты тона.
- Оптимизация производительности декодирования на стороне воспроизведения
- Буфер джиттера воспроизведения (для достижения баланса с заиканием)
- Сторона воспроизведения использует более высокий протокол реального времени.
- Сторона воспроизведения использует переменную скорость передачи данных
- Сторона воспроизведения использует многоуровневый поток кодирования.
15. Суммарная задержка (Live)
- Плавный сброс кадров и быстрый сброс кадров
16. Телефон нагревается
На данный момент записано:
- Использование ЦП слишком велико, в основном из-за слишком высокой сложности вычислений, слишком высокой точности данных, алгоритм требует высокой конфигурации машины, это очень распространено в программном редактировании, есть много операций, таких как матричное преобразование, и это очень часто встречается в панорамах
- Частота использования ЦП слишком высока, количество ядер мало, а переключение потоков происходит очень часто. На моделях с меньшим количеством ядер однопоточное декодирование иногда более эффективно, чем многопоточное.
- Высокое использование памяти, неразумная конструкция буферной очереди, частая репликация данных и т. д.
- Скорость использования видеокарты слишком высока, например, сверхчеткая или панорама/VR и т. д., скорость использования видеокарты слишком высока, что может снизить частоту обновления некоторых изображений.
17. Ненормальное воспроизведение записанного видео
- Калибровать, когда написано pts
- Некоторая ключевая информация о декодировании не может быть неправильно записана
18. Заставка
Я никогда не сталкивался с этой частью.В информации в Интернете упоминалось, что это относится к слиянию видеоизображений, или какие-то картинки по умолчанию добавляются в плеер, когда плеер зависает, вызывая дрожание экрана (то есть заставку). При синтезе изображений, или добавлении логотипов, или вставке кадров в очередь воспроизведения следует обращать внимание на плавность переходов.
4. Обнаружение и мониторинг
- Отчет журнала игрока
- Реализуйте полный мониторинг потоковой передачи, транскодирования, распространения, загрузки и воспроизведения для streamid.