diff options
Diffstat (limited to 'files/ru/web/media/formats/webrtc_codecs/index.html')
| -rw-r--r-- | files/ru/web/media/formats/webrtc_codecs/index.html | 50 |
1 files changed, 25 insertions, 25 deletions
diff --git a/files/ru/web/media/formats/webrtc_codecs/index.html b/files/ru/web/media/formats/webrtc_codecs/index.html index b7c15b90d1..b8fab2ec49 100644 --- a/files/ru/web/media/formats/webrtc_codecs/index.html +++ b/files/ru/web/media/formats/webrtc_codecs/index.html @@ -14,7 +14,7 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <p>WebRTC использует объект типа {{domxref("MediaStreamTrack")}} для представления каждого трека, передающегося между узлами соединения без использования контейнера или объекта типа {{domxref("MediaStream")}} , объединяющего треки. Какие кодеки могут быть в этих треках, спецификацией WebRTC не определяется. Однако, {{RFC(7742)}} определяет, что все браузеры, поддерживающие WebRTC, должны поддерживать <a href="/en-US/docs/Web/Media/Formats/Video_codecs#VP8">VP8</a> и <a href="/en-US/docs/Web/Media/Formats/Video_codecs#AVC_(H.264)">H.264</a> ограниченный базовый профиль для видео; и {{RFC(7874)}} , определяющая, что браузеры должны поддерживать, по меньшей мере, кодеки <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Opus">Opus</a> и <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#G.711">G.711</a> форматов PCMA и PCMU.</p> -<p>Эти две спецификации определяют свойства, которые должны поддерживаться каждым кодеком, а так же определенные функции для удобства использования, к примеру, функция эхоподавления. В этом руководстве происходит обзор кодеков, поддержка которых обязательна браузерам для реализации WebRTC, а так же иные (не обязательные) кодеки, поддерживаемые отдельными или всеми браузерами,.</p> +<p>Эти две спецификации определяют свойства, которые должны поддерживаться каждым кодеком, а так же определённые функции для удобства использования, к примеру, функция эхоподавления. В этом руководстве происходит обзор кодеков, поддержка которых обязательна браузерам для реализации WebRTC, а так же иные (не обязательные) кодеки, поддерживаемые отдельными или всеми браузерами,.</p> <p>Хоть сжатие всегда и необходимо при работе со средствами массовой информации в Интернете, оно имеет дополнительное значение при проведении видеоконференций, чтобы участники могли общаться без задержек и перерывов. Второстепенное значение имеет необходимость синхронизации видео и звука, чтобы движения и любая вспомогательная информация (например, слайды или проекция) были представлены одновременно с соответствующим звуком</p> @@ -24,7 +24,7 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <p>Если {{Glossary ("SDP")}} специально не указывает иное, веб-браузер, принимающий видеопоток WebRTC, должен иметь возможность обрабатывать видео со скоростью не менее 20 кадров в секунду при минимальном разрешении 320 пикселей в ширину и 240 пикселей в высоту. Рекомендуется, чтобы видео кодировалось с частотой кадров и размером не ниже этого, поскольку это, по сути, нижняя граница того, что WebRTC обычно должен обрабатывать.</p> -<p>SDP поддерживает независимый от кодеков способ указания предпочтительных разрешений видео ({{RFC (6236)}}). Это делается путем отправки <code>a=imageattr</code> атрибута SDP для указания максимально допустимого разрешения. Однако отправителю не требуется поддерживать этот механизм, поэтому вы должны быть готовы получать носители с другим разрешением, чем вы запрашивали. Помимо этого простого запроса максимального разрешения, определенные кодеки могут предлагать дополнительные способы запроса конкретных конфигураций мультимедиа.</p> +<p>SDP поддерживает независимый от кодеков способ указания предпочтительных разрешений видео ({{RFC (6236)}}). Это делается путём отправки <code>a=imageattr</code> атрибута SDP для указания максимально допустимого разрешения. Однако отправителю не требуется поддерживать этот механизм, поэтому вы должны быть готовы получать носители с другим разрешением, чем вы запрашивали. Помимо этого простого запроса максимального разрешения, определённые кодеки могут предлагать дополнительные способы запроса конкретных конфигураций мультимедиа.</p> <h2 id="Поддерживаемые_видео_кодеки">Поддерживаемые видео кодеки</h2> @@ -103,11 +103,11 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <p>Поддержка профиля AVC Constrained Baseline (<code>CB</code>) требуется во всех полностью совместимых реализациях WebRTC. <code>CB</code> является подмножеством основного профиля и специально разработан для приложений с низкой сложностью и малой задержкой, таких как мобильное видео и видеоконференции, а также для платформ с более низкими возможностями обработки видео..</p> -<p>Наш <a href="/en-US/docs/Web/Media/Formats/Video_codecs#AVC_(H.264)">обзор AVC</a> и его функциональности найдете в основном руководстве по видеокодекам.</p> +<p>Наш <a href="/en-US/docs/Web/Media/Formats/Video_codecs#AVC_(H.264)">обзор AVC</a> и его функциональности найдёте в основном руководстве по видеокодекам.</p> <h4 id="Требования_поддержки_специальных_параметров">Требования поддержки специальных параметров</h4> -<p>AVC предлагает широкий спектр параметров для управления дополнительными значениями. Чтобы повысить надежность совместного использования мультимедиа WebRTC на нескольких платформах и в разных браузерах, необходимо, чтобы конечные точки WebRTC, поддерживающие AVC, обрабатывали определенные параметры определенным образом. Иногда это просто означает, что параметр должен (или не должен) поддерживаться. Иногда это означает, что необходимо указать конкретное значение для параметра или разрешить определенный набор значений. А иногда требования более сложны.</p> +<p>AVC предлагает широкий спектр параметров для управления дополнительными значениями. Чтобы повысить надёжность совместного использования мультимедиа WebRTC на нескольких платформах и в разных браузерах, необходимо, чтобы конечные точки WebRTC, поддерживающие AVC, обрабатывали определённые параметры определённым образом. Иногда это просто означает, что параметр должен (или не должен) поддерживаться. Иногда это означает, что необходимо указать конкретное значение для параметра или разрешить определённый набор значений. А иногда требования более сложны.</p> <h5 id="Полезные_но_необязательные_параметры">Полезные, но необязательные параметры</h5> @@ -115,9 +115,9 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <dl> <dt><code>max-br</code></dt> - <dd>Если параметр определен и поддерживается , он определяет максимальную скорость передачи видеоданных в единицах 1,000 bps (бит в секунду) для VCL и 1,200 bps (бит в секунду) для NAL. Подробности на <a href="https://tools.ietf.org/html/rfc6184#page-47">странице 47 спецификации RFC 6184</a>.</dd> + <dd>Если параметр определён и поддерживается , он определяет максимальную скорость передачи видеоданных в единицах 1,000 bps (бит в секунду) для VCL и 1,200 bps (бит в секунду) для NAL. Подробности на <a href="https://tools.ietf.org/html/rfc6184#page-47">странице 47 спецификации RFC 6184</a>.</dd> <dt><code>max-cpb</code></dt> - <dd>Если параметр определен и поддерживается, он определяет максимальный размер буфера, кодируемых данных. Немного усложненный параметр, размер которого может варьироваться. Смотрим на <a href="https://tools.ietf.org/html/rfc6184#page-45">страницу 45 спецификации RFC 6184</a> о подробностях.</dd> + <dd>Если параметр определён и поддерживается, он определяет максимальный размер буфера, кодируемых данных. Немного усложнённый параметр, размер которого может варьироваться. Смотрим на <a href="https://tools.ietf.org/html/rfc6184#page-45">страницу 45 спецификации RFC 6184</a> о подробностях.</dd> <dt><code>max-dpb</code></dt> <dd>Определяет максимальный размер буфера декодированных данных, выраженных в единицах 8/3 макроблоков. Подробности в спецификации <a href="https://tools.ietf.org/html/rfc6184#page-46">RFC 6184, страница 46</a>.</dd> <dt><code>max-fs</code></dt> @@ -128,7 +128,7 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <dd>Определяет максимальную скорость обработки статических макроблоков в секунду (используя гипотетическое предположение, что все макроблоки являются статическими макроблоками).</dd> </dl> -<h5 id="Параметры_с_определенными_требованиями">Параметры с определенными требованиями</h5> +<h5 id="Параметры_с_определёнными_требованиями">Параметры с определёнными требованиями</h5> <p>Эти параметры являются необязательными, но имеют специальные требования при их использовании.</p> @@ -229,7 +229,7 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <p><a id="other-audio-foot-2" name="other-audio-foot-2">[2]</a> The <strong>{{interwiki("wikipedia", "Internet Speech Audio Codec")}}</strong> (<strong>iSAC</strong>) - другой кодек, разработанный Global IP Solutions, теперь принадлежащий Google, открывший его код. Используется Google Talk, QQ, и другими клиентами быстрых сообщений, специально спроектированный для голосовых сообщений, упакованных в поток RTP. Пока не является обязательной поддерживаемым кодеком. Поддерживается Safari и Chrome. Не поддерживается Firefox и Edge.</p> -<p><strong>{{interwiki("wikipedia", "Comfort noise")}}</strong> (<strong>CN</strong>) - комфортный шум. Является формой искусственного фонового шума, использующегося для заполнения пробелов в передаче, вместо использования полной тишины. Помогает избежать вибрационных эффектов, возникающих, когда голосовая активация или подобная функциональность вызывает временное приостановление потока, известная как прерывистая передача (Discontinuous Transmission (DTX)). В спецификации {{RFC(3389)}}, метод предлагает использовать определенное заполнение в беззвучных промежутках.</p> +<p><strong>{{interwiki("wikipedia", "Comfort noise")}}</strong> (<strong>CN</strong>) - комфортный шум. Является формой искусственного фонового шума, использующегося для заполнения пробелов в передаче, вместо использования полной тишины. Помогает избежать вибрационных эффектов, возникающих, когда голосовая активация или подобная функциональность вызывает временное приостановление потока, известная как прерывистая передача (Discontinuous Transmission (DTX)). В спецификации {{RFC(3389)}}, метод предлагает использовать определённое заполнение в беззвучных промежутках.</p> <p>Комфортный шум используется с G.711 и может потенциально использоваться с другими кодеками, которые не имеют встроенной функции CN. Кодек Opus, к примеру, имеет собственную реализацию CN, поэтому использование RFC 3389 CN с кодеком Opus не рекомендуется.</p> @@ -237,11 +237,11 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <h3 id="Кодек_Opus">Кодек Opus</h3> -<p>Формат Opus, определенный в {{RFC (6716)}}), является основным форматом для аудио в WebRTC. Формат полезной нагрузки RTP для Opus находится в {{RFC (7587)}}. Можете найти подробную информацию об Opus и его возможностях, а также о том, как другие API могут поддерживать Opus, в <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Opus">соответствующей секции</a> нашего <a href="/en-US/docs/Web/Media/Formats/Audio_codecs">руководства по аудиокодекам, использующимся в web</a>.</p> +<p>Формат Opus, определённый в {{RFC (6716)}}), является основным форматом для аудио в WebRTC. Формат полезной нагрузки RTP для Opus находится в {{RFC (7587)}}. Можете найти подробную информацию об Opus и его возможностях, а также о том, как другие API могут поддерживать Opus, в <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Opus">соответствующей секции</a> нашего <a href="/en-US/docs/Web/Media/Formats/Audio_codecs">руководства по аудиокодекам, использующимся в web</a>.</p> <p>Должны поддерживаться оба режима : речь и обычное аудио. Масштабируемость и гибкость Opus полезна при работе с аудио, имеющим различную степень сложности. Поддержка внутриполосных стереосигналов позволяет поддерживать стереозвук без усложнения процесса демультиплексирования.</p> -<p>Весь диапазон битрейтов, поддерживаемых Opus (от 6 кбит / с до 510 кбит / с), поддерживается в WebRTC, причем скорость битов можно динамически изменять. Более высокие битовые скорости передачи обычно улучшают качество..</p> +<p>Весь диапазон битрейтов, поддерживаемых Opus (от 6 кбит / с до 510 кбит / с), поддерживается в WebRTC, причём скорость битов можно динамически изменять. Более высокие битовые скорости передачи обычно улучшают качество..</p> <h4 id="Рекомендации_по_скорости_передачи_данных_bit_rate">Рекомендации по скорости передачи данных (bit rate)</h4> @@ -282,7 +282,7 @@ original_slug: Web/Media/Formats/WebRTC_кодеки <h3 id="Кодек_G.711">Кодек G.711</h3> -<p>G.711 определяет формат для звука с импульсной кодовой модуляцией (PCM) в виде серии 8-битных целочисленных выборок, взятых с частотой дискретизации 8000 Гц, что дает скорость передачи данных 64 кбит / с. И в {{interwiki("wikipedia", "M-law", "µ-law")}} , и в {{interwiki("wikipedia", "A-law")}} разрешена кодировка.</p> +<p>G.711 определяет формат для звука с импульсной кодовой модуляцией (PCM) в виде серии 8-битных целочисленных выборок, взятых с частотой дискретизации 8000 Гц, что даёт скорость передачи данных 64 кбит / с. И в {{interwiki("wikipedia", "M-law", "µ-law")}} , и в {{interwiki("wikipedia", "A-law")}} разрешена кодировка.</p> <p>G.711 <a href="https://www.itu.int/rec/T-REC-G.711-198811-I/en">определяется ITU</a> , а его формат нагрузки в {{RFC(3551, "4.5.14")}}.</p> @@ -323,11 +323,11 @@ peerConnection.addEventListener("icegatheringstatechange", (event) => { <p>Обработчик события <code>icegatheringstatechange</code> установлен; в нем мы отслеживаем тип события <code>complete</code> завершения сборки кандидатов ICE, указывающее что сборка кандидатов завершена. Метод {{domxref("RTCPeerConnection.getSenders()")}} вызывается для получения списка всех объектов {{domxref("RTCRtpSender")}} , использующихся в соединении.</p> -<p>Имея это в виду, мы просматриваем список отправителей и ищем первого, чей {{domxref ("MediaStreamTrack")}} указывает, что тип {{domxref ("MediaStreamTrack.track", "track")}} в своем свойстве {{domxref("MediaStreamTrack.kind", "kind")}} содержит значение <code>video</code>, указывающее, что данные являются видеоданными. Затем вызывается метод отправителя {{domxref("RTCRtpSender.getParameters", "getParameters()")}} , и значением свойства {{domxref("RTCRtpParameters.codecs", "codecs")}} возвращаемого объекта {{domxref("RTCRtpSendParameters")}} , инициализируем переменную <code>codecList</code>.</p> +<p>Имея это в виду, мы просматриваем список отправителей и ищем первого, чей {{domxref ("MediaStreamTrack")}} указывает, что тип {{domxref ("MediaStreamTrack.track", "track")}} в своём свойстве {{domxref("MediaStreamTrack.kind", "kind")}} содержит значение <code>video</code>, указывающее, что данные являются видеоданными. Затем вызывается метод отправителя {{domxref("RTCRtpSender.getParameters", "getParameters()")}} , и значением свойства {{domxref("RTCRtpParameters.codecs", "codecs")}} возвращаемого объекта {{domxref("RTCRtpSendParameters")}} , инициализируем переменную <code>codecList</code>.</p> <p>Если видеотрек не найден, устанавливаем <code>codecList</code> в <code>null</code>.</p> -<p>При возврате, <code>codecList </code>либо <code>null</code> , указывающий на то, что видеодорожки не были найдены, либо это массив {{domxref ("RTCRtpCodecParameters")}} объектов, каждый из которых описывает одну разрешенную конфигурацию кодека. Особое значение в этих объектах имеет свойство {{domxref ("RTCRtpCodecParameters.payloadType", "payloadType")}}, которое является однобайтовым значением, однозначно идентифицирующим описанную конфигурацию.</p> +<p>При возврате, <code>codecList </code>либо <code>null</code> , указывающий на то, что видеодорожки не были найдены, либо это массив {{domxref ("RTCRtpCodecParameters")}} объектов, каждый из которых описывает одну разрешённую конфигурацию кодека. Особое значение в этих объектах имеет свойство {{domxref ("RTCRtpCodecParameters.payloadType", "payloadType")}}, которое является однобайтовым значением, однозначно идентифицирующим описанную конфигурацию.</p> <div class="blockIndicator note"> <p><strong>Примечание :</strong> Два метода получения списков кодеков, показанные здесь, используют разные типы вывода в своих списках кодеков. Помните об этом при использовании результатов</p> @@ -356,17 +356,17 @@ peerConnection.addEventListener("icegatheringstatechange", (event) => { } </pre> -<p>В этом примере функция <code>changeVideoCodec()</code> принимает в параметр MIME тип предпочтительного к использованию кодека. Код начинается с получения списка объектов приемо-передатчиков объекта соединения {{domxref("RTCPeerConnection")}}.</p> +<p>В этом примере функция <code>changeVideoCodec()</code> принимает в параметр MIME тип предпочтительного к использованию кодека. Код начинается с получения списка объектов приёмо-передатчиков объекта соединения {{domxref("RTCPeerConnection")}}.</p> -<p>Затем, для каждого приемо-передатчика анализируем тип медиа свойства {{domxref("RTCRtpSender")}}'s track's {{domxref("MediaStreamTrack.kind", "kind")}}. Так же получаем список поддерживаемых браузером кодеков стороны отправки и получения <code>video</code>, используя статический метод <code>getCapabilities()</code> обоих классов {{domxref("RTCRtpSender")}} и {{domxref("RTCRtpReceiver")}}.</p> +<p>Затем, для каждого приёмо-передатчика анализируем тип медиа свойства {{domxref("RTCRtpSender")}}'s track's {{domxref("MediaStreamTrack.kind", "kind")}}. Так же получаем список поддерживаемых браузером кодеков стороны отправки и получения <code>video</code>, используя статический метод <code>getCapabilities()</code> обоих классов {{domxref("RTCRtpSender")}} и {{domxref("RTCRtpReceiver")}}.</p> <p>Если тип медиаданных является типом <code>video</code>, вызываем метод <code>preferCodec()</code> для обоих взаимодействующих сторон списков кодеков, который реорганизует список кодеков необходимым образом (смотри ниже).</p> <p>И наконец, вызываем метод {{domxref("RTCRtpTransceiver.setCodecPreferences", "setCodecPreferences()")}} объекта {{domxref("RTCRtpTransceiver")}} для определения того, что использование кодеков обеих сторон разрешено, в указанном порядке.</p> -<p>Это выполняется для каждого объекта приемо-передатчика объекта соединения <code>RTCPeerConnection</code>; как только все приемо-передатчики обновили списки предпочитаемых кодеков, вызывается обработчик события {{domxref("RTCPeerConnection.onnegotiationneeded", "onnegotiationneeded")}} , который создает новый объект предложения, обновляет объект локального описания сессии, отправляет предложение удаленному узлу, и так далее, запуская согласование соединения .</p> +<p>Это выполняется для каждого объекта приёмо-передатчика объекта соединения <code>RTCPeerConnection</code>; как только все приёмо-передатчики обновили списки предпочитаемых кодеков, вызывается обработчик события {{domxref("RTCPeerConnection.onnegotiationneeded", "onnegotiationneeded")}} , который создаёт новый объект предложения, обновляет объект локального описания сессии, отправляет предложение удалённому узлу, и так далее, запуская согласование соединения .</p> -<p>Функция <code>preferCodec()</code> вызываемая приведенным выше кодом, действует так, чтобы переместить указанный кодек в верхнюю часть списка (для приоритета во время согласования):</p> +<p>Функция <code>preferCodec()</code> вызываемая приведённым выше кодом, действует так, чтобы переместить указанный кодек в верхнюю часть списка (для приоритета во время согласования):</p> <pre class="brush: js notranslate">function preferCodec(codecs, mimeType) { let otherCodecs = []; @@ -384,11 +384,11 @@ peerConnection.addEventListener("icegatheringstatechange", (event) => { return sortedCodecs.concat(otherCodecs); }</pre> -<p>Этот код просто разбивает список кодеков на два массива: один, содержащий кодеки, чей MIME тип совпадает с тем, который указан в параметре <code>mimeType</code> , другой же содержит остальные кодеки. Как только список разделен, они объединяются вместе с записями, соответствующими заданному <code>mimeType</code> следующими вначале, за которыми следуют остальные записи кодеков. Затем этот список возвращается вызывающему коду.</p> +<p>Этот код просто разбивает список кодеков на два массива: один, содержащий кодеки, чей MIME тип совпадает с тем, который указан в параметре <code>mimeType</code> , другой же содержит остальные кодеки. Как только список разделён, они объединяются вместе с записями, соответствующими заданному <code>mimeType</code> следующими вначале, за которыми следуют остальные записи кодеков. Затем этот список возвращается вызывающему коду.</p> <h2 id="Кодеки_по_умолчанию">Кодеки по умолчанию</h2> -<p>Если не определенно иное, кодеки по умолчанию (предпочтительные кодеки), запрашиваемые браузерными реализациями WebRTC, перечислены ниже</p> +<p>Если не определённо иное, кодеки по умолчанию (предпочтительные кодеки), запрашиваемые браузерными реализациями WebRTC, перечислены ниже</p> <table class="standard-table"> <caption> @@ -433,13 +433,13 @@ peerConnection.addEventListener("icegatheringstatechange", (event) => { <h2 id="Правильный_выбор_кодеков">Правильный выбор кодеков</h2> -<p>Перед выбором кодека, который не является обязательным (VP8 или AVC для видео и Opus или PCM для аудио), следует серьезно рассмотреть потенциальные недостатки: в особенности, если предполагается, что эти кодеки не широко доступны на всех устройствах, поддерживающих WebRTC.</p> +<p>Перед выбором кодека, который не является обязательным (VP8 или AVC для видео и Opus или PCM для аудио), следует серьёзно рассмотреть потенциальные недостатки: в особенности, если предполагается, что эти кодеки не широко доступны на всех устройствах, поддерживающих WebRTC.</p> <p>Если вы предпочитаете кодек, отличный от обязательных, вы должны по крайней мере разрешить откат к одному из обязательных кодеков, если поддержка для кодека, который вы предпочитаете, окажется недоступна.</p> <h3 id="Аудио">Аудио</h3> -<p>В целом, если кодек доступен и звук, который вы хотите отправить, имеет частоту дискретизации более 8 кГц, вам следует настоятельно рекомендовать использовать Opus в качестве основного кодека. Для голосовых соединений в стесненной среде использование G.711 с частотой дискретизации 8 кГц может обеспечить приемлемое качество для разговора, но обычно вы будете использовать G.711 в качестве запасного варианта, поскольку есть другие более эффективные варианты, чей звук лучше, такие как Опус в своем узкополосном режиме .</p> +<p>В целом, если кодек доступен и звук, который вы хотите отправить, имеет частоту дискретизации более 8 кГц, вам следует настоятельно рекомендовать использовать Opus в качестве основного кодека. Для голосовых соединений в стеснённой среде использование G.711 с частотой дискретизации 8 кГц может обеспечить приемлемое качество для разговора, но обычно вы будете использовать G.711 в качестве запасного варианта, поскольку есть другие более эффективные варианты, чей звук лучше, такие как Опус в своём узкополосном режиме .</p> <h3 id="Видео">Видео</h3> @@ -447,7 +447,7 @@ peerConnection.addEventListener("icegatheringstatechange", (event) => { <h4 id="Условия_лицензирования">Условия лицензирования</h4> -<p>Прежде чем выбрать видеокодек, убедитесь, что вы знаете о любых лицензионных требованиях к выбранному вами кодеку; можете найти информацию о возможных проблемах лицензирования в нашем основном <a href="/en-US/docs/Web/Media/Formats/Video_codecs">руководстве по видеокодекам, используемым в web</a>. Из двух обязательных кодеков для видео - VP8 и AVC / H.264 - только VP8 полностью свободен от лицензионных требований. Если выбираете AVC, убедитесь, что вы знаете о любых возможных сборах, которые вам, возможно, придется заплатить; владельцы патентов обычно говорят, что большинству типичных разработчиков веб-сайтов не нужно беспокоиться об оплате лицензионных сборов, которые, как правило, больше ориентированы на разработчиков программного обеспечения для кодирования и декодирования.</p> +<p>Прежде чем выбрать видеокодек, убедитесь, что вы знаете о любых лицензионных требованиях к выбранному вами кодеку; можете найти информацию о возможных проблемах лицензирования в нашем основном <a href="/en-US/docs/Web/Media/Formats/Video_codecs">руководстве по видеокодекам, используемым в web</a>. Из двух обязательных кодеков для видео - VP8 и AVC / H.264 - только VP8 полностью свободен от лицензионных требований. Если выбираете AVC, убедитесь, что вы знаете о любых возможных сборах, которые вам, возможно, придётся заплатить; владельцы патентов обычно говорят, что большинству типичных разработчиков веб-сайтов не нужно беспокоиться об оплате лицензионных сборов, которые, как правило, больше ориентированы на разработчиков программного обеспечения для кодирования и декодирования.</p> <div class="blockIndicator warning"> <p><strong>Внимание :</strong> Информация здесь не является юридической консультацией! Обязательно убедитесь в возможности ответственности, прежде чем принимать какие-либо окончательные решения, если существует вероятность возникновения проблем с лицензированием.</p> @@ -455,19 +455,19 @@ peerConnection.addEventListener("icegatheringstatechange", (event) => { <h4 id="Энергопотребление_и_срок_службы_батареи">Энергопотребление и срок службы батареи</h4> -<p>Еще один фактор, который следует учитывать, особенно на мобильных платформах, - это влияние кодека на время автономной работы. Если кодек обрабатывается аппаратно на данной платформе, он, вероятно, позволит значительно увеличить срок службы батареи и уменьшить выработку тепла.</p> +<p>Ещё один фактор, который следует учитывать, особенно на мобильных платформах, - это влияние кодека на время автономной работы. Если кодек обрабатывается аппаратно на данной платформе, он, вероятно, позволит значительно увеличить срок службы батареи и уменьшить выработку тепла.</p> <p>Например, Safari для iOS и iPadOS представила WebRTC с AVC в качестве единственного поддерживаемого видеокодека. Преимущество AVC на iOS и iPadOS заключается в возможности кодирования и декодирования на аппаратном уровне.Safari 12.1 представил поддержку VP8 в IRC, что улучшает взаимодействие, но за дополнительную плату - VP8 не имеет аппаратной поддержки на устройствах iOS, поэтому его использование приводит к увеличению нагрузки на процессор и сокращению срока службы батареи.</p> <h4 id="Производительность">Производительность</h4> -<p>К счастью, VP8 и AVC работают одинаково с точки зрения конечного пользователя и одинаково адекватны для использования в видеоконференцсвязи и других решениях WebRTC. Окончательное решение остается за разработчиком. Какой бы вариант вы ни выбрали, обязательно прочитайте информацию, представленную в этой статье, о любых конкретных проблемах конфигурации, с которыми вам, возможно, придется столкнуться для этого кодека.</p> +<p>К счастью, VP8 и AVC работают одинаково с точки зрения конечного пользователя и одинаково адекватны для использования в видеоконференцсвязи и других решениях WebRTC. Окончательное решение остаётся за разработчиком. Какой бы вариант вы ни выбрали, обязательно прочитайте информацию, представленную в этой статье, о любых конкретных проблемах конфигурации, с которыми вам, возможно, придётся столкнуться для этого кодека.</p> <p>Имейте в виду, что выбор кодека, которого нет в списке обязательных кодеков, может привести к риску выбора кодека, который не поддерживается браузером, который предпочитают ваши пользователи. Прочтите <a href="/en-US/docs/Web/Media/Formats/Support_issues">Решение проблем медиаподдержки в веб контенте</a> , чтобы узнать больше о том, как предлагать поддержку предпочитаемых кодеков, но при этом использовать браузеры, которые не поддерживают этот кодек.</p> <h2 id="Последствия_для_безопасности">Последствия для безопасности</h2> -<p>При выборе и настройке кодеков возникают интересные потенциальные проблемы безопасности. Видео WebRTC защищено с помощью Datagram Transport Layer Security ({{Glossary("DTLS")}}), но для мотивированной стороны теоретически возможно вывести величину изменения, которое происходит от кадра к кадру при использовании кодеков с переменной скоростью передачи (VBR), путем мониторинга скорости потока и ее изменения во времени.Это может потенциально позволить злоумышленнику сделать вывод о содержании потока, учитывая приливы и отливы скорости передачи.</p> +<p>При выборе и настройке кодеков возникают интересные потенциальные проблемы безопасности. Видео WebRTC защищено с помощью Datagram Transport Layer Security ({{Glossary("DTLS")}}), но для мотивированной стороны теоретически возможно вывести величину изменения, которое происходит от кадра к кадру при использовании кодеков с переменной скоростью передачи (VBR), путём мониторинга скорости потока и её изменения во времени.Это может потенциально позволить злоумышленнику сделать вывод о содержании потока, учитывая приливы и отливы скорости передачи.</p> <p>Подробнее о безопасности при использовании AVC в WebRTC см. {{RFC(6184, "RTP Payload Format for H.264 Video: Security Considerations", 9)}}.</p> |