Потребность в транскодировании видео

Сегодня технологии сжатия цифрового видео важны практически во всех типах видеоприложений. Значимость таких параметров как сжатие и совместимость данных еще более возрастает из-за усиливающейся тенденции к конвергенции средств коммуникации.
К наиболее известным приложениям в области цифрового видео относятся DVD, телевидение высокой четкости (HDTV), видеотелефония/обеспечение телеконференций и, с недавних пор, видеонаблюдение. Каждая из этих технологий имеет свою историю развития, соответственно, в каждой из них существуют собственные алгоритмы сжатия.
Транскодирование играет две важные роли. Во-первых, оно обеспечивает коммуникации между существующими и вновь появляющимися устройствами. Например, многие существующие системы видеоконференций основаны на стандарте кодирования видеоданных H.263. Более новые системы видеоконференций используют базовый профиль H.264/AVC. Таким образом, для обеспечения коммуникации между этими системами необходимо транскодирование видео в реальном времени. Во-вторых, информационные сети, в особенности Интернет, имеют ограниченную пропускную способность при передаче видео. Так, большинство видеофильмов в настоящее время хранится на дисках DVD в формате MPEG2. Ограничения на пропускную способность в сервисах видео по запросу и потокового видео по IP-сетям требуют преобразования этих видеоданных в формат с большей степенью сжатия. Это достигается путем транскодирования видео в режиме реального времени перед передачей. В целом, в результате транскодирования высвобождается до 50% пропускной способности сети без потери качества видео.
Транскодирование в видеоконференциях

Итак, одно из применений транскодирования – системы видеоконференций. Рассмотрим типичную схему транскодирования, применяемую в таких системах (рис.1). Один сигнальный процессор (DSP2) декодирует входной видеопоток и генерирует восстановленный видеокадр, который передается на другой цифровой сигнальный процессор (в данном примере это DSP1) через последовательный интерфейс RapidIO (sRIO). DSP1 кодирует восстановленный видеокадр в нужный формат. Обычно на одной стороне видеоконференции используется оборудование на базе стандарта H.263, тогда как другая сторона использует оборудование на базе стандарта H.264.
Хост-процессор, управляющий сетевым трафиком, взаимодействует с несколькими цифровыми сигнальными процессорами (в данном случае с четырьмя) через соединение по шине PCI.
Ключевая особенность взаимодействия процессоров в этом примере – это их соединение через интерфейс sRIO. Поскольку данные, передаваемые между цифровыми сигнальными процессорами, представляют собой несжатое видео, как правило, с частотой 30 кадров/с, то требования к пропускной способности линии связи между устройствами очень высоки.
Если взять видео в стандартном разрешении NTSC (720 на 480 пикселов) YUV 4:2:0, то размер каждого кадра составит 720×480×1,5 = 518400 байт. Соответственно, при частоте 30 кадров в секунду пропускная способность линии должна составлять примерно 124 Мбит/с.
Выбор интерфейса sRIO диктуют требования к скорости передачи видеоданных и поддержке гибкой структуры коммутации. sRIO поддерживает три скорости передачи данных: 1,24 Гбит/с, 2,5 Гбит/с и 3,125 Гбит/с. В данном интерфейсе применяется технология SerDes для восстановления тактовой синхронизации по потоку данных и используется кодирование 8-b/10-b. Эта спецификация последовательного интерфейса поддерживает порты с одной линией (1X) и с четырьмя линиями (4X). Физический уровень интерфейса sRIO определяет механизм квитирования, который применяют при установлении связи между устройствами, а также порядок обнаружения ошибок, основанный на циклическом избыточном коде. Физический уровень интерфейса устанавливает и приоритет пакетов, используемый при маршрутизации в пределах коммутирующей матрицы.
Чтобы в полной мере воспользоваться преимуществами пропускной способности sRIO, процессоры должны иметь эти интерфейсы. Такие процессоры предлагает компания Texas Instruments. Например, сигнальный процессор TMS320C6455 снабжен встроенным интерфейсом sRIO, который обеспечивает четыре одновременных соединения и имеет пиковую скорость передачи данных 20 Гбит/с в обе стороны.
Процессор TMS320C6455

Помимо интерфейса sRIO процессор C6455 имеет дополнительный набор важных функций, которые делают его идеальным устройством для транскодирования. Эти функциональные особенности можно объединить в четыре основных блока.
Наличие большого числа высокоскоростных интерфейсов ввода-вывода. Разработчики систем используют различные решения, поэтому цифровой сигнальный процессор для приложений обработки видеоданных должен предусматривать порты ввода-вывода для соединения модулей системы на уровне плат. Как было сказано ранее, в C6455 имеется встроенный порт sRIO для связи между устройствами.
Другие варианты ввода-вывода в C6455 – это контроллер обращения к среде Ethernet (Ethernet Media Access Controller, EMAC) со скоростью 1 Гбит/с, 32-битный контроллер памяти с удвоенной скоростью обмена данными (DDR2-500), а также 66-МГц шина для подключения периферийных устройств (PCI). Встроенный интерфейс ATM (UTOPIA 2) позволяет задействовать процессор C6455 в инфраструктуре телекоммуникаций.
Эффективное перемещение данных внутри микросхемы. Однокристальная архитектура для эффективного перемещения данных – одно из главных преимуществ процессора C6455 по сравнению с его предшественниками. В приложениях обработки видеоданных цифровые сигнальные процессоры работают в качестве ведомых устройств хост-процессора. Следовательно, для них важны высокая пропускная способность, малая задержка и возможность параллельной передачи данных между ведущими и ведомыми устройствами. Данные требования определили архитектуру устройства: периферийные устройства, внутренняя память и ядро процессора взаимодействуют между собой через эффективный коммутатор (switched central resource – SCR) процессора C6455.
Также важна оптимальная организация потока данных. Ее удалось улучшить за счет применения шин памяти с разрядностью 256 бит и внутреннего прямого доступа к памяти (internal direct memory access, IDMA). IDMA обеспечивает перемещение данных в фоновом режиме между двумя уровнями внутренней памяти, а также к шине периферийных устройств и обратно.
Большой объем внутрикристальной памяти. Внутрикристальная статическая оперативная память SRAM работает намного быстрее, чем динамическая внешняя память SDRAM, а ее объем намного меньше ввиду высокой стоимости изготовления. Для типовых приложений в области видео внутрикристальная память служит, главным образом, двум целям: 1) хранит часто используемые код и данные, 2) загружает/выгружает временные данные до и после обработки. Как правило, чем больше объем доступной внутрикристальной памяти, тем выше производительность приложения. В цифровом сигнальном процессоре C6455 размещено целых два мегабайта статической оперативной памяти.
Совместимость программного обеспечения (ПО). Обратная совместимость ПО важна, поскольку множество программ для видеоприложений было разработано задолго до широкого применения транскодирования. Чтобы использовать существующее ПО на новых процессорах, целесообразно повышать производительность DSP не путем изменения его набора команд, а за счет архитектуры ядра процессора. В процессоре C6455 реализованы два архитектурных новшества. Первое связано с введением циклического буфера, потенциально повышающего эффективность программной конвейеризации обработки кода с короткими циклами. Второе – применение 16-разрядных версий изначально 32-разрядных команд, что значительно уменьшает размер программного кода и, таким образом, снижает коэффициент "непопаданий" при обращениях к кэш-памяти.
Прототип системы транскодирования

Транскодирование необходимо также для передачи данных с DVD-дисков по IP-сети, например в обучающей системе компании, в приложениях видео по запросу и широковещательной трансляции видео. В этом случае исходным видеоформатом является MPEG2, а в качестве целевого формата используется в основном WMV9. Отметим, что возможность программирования цифровых сигнальных процессоров позволяет легко поддерживать практически любую комбинацию исходного/целевого видеоформата.
Для транскодирования видеоданных нужно решить множество технических вопросов, таких как преобразование формата, уменьшение битрейта видеопотока и его временного и пространственного разрешения. Поэтому были разработаны различные схемы интеллектуального транскодирования видеоданных. Их главный принцип – в максимально возможном повторном использовании информации, которая содержится во входном видеопотоке.
В данном разделе рассматривается прототип системы транскодирования видео, который пригоден для любых схем транскодирования благодаря использованию архитектуры, основанной на гибкой инфраструктуре аппаратного/программного обеспечения. Чтобы удовлетворить различным целевым сценариям транскодирования видео, выбрана простейшая схема транскодирования, в которой видеопоток полностью декодируется, а затем кодируется повторно в соответствии с новыми ограничениями.
Поток данных в системе начинается на левой стороне схемы (рис.2), со сжатого в формате MPEG2 видеофайла, который хранится на жестком диске, и заканчивается на плоскопанельном дисплее, где видео воспроизводится программой Windows Media Player. В этом демонстрационном варианте видео имеет стандартное разрешение NTSC (720 на 480 пикселов) и транскодируется со скоростью 30 кадров в секунду.
Модуль приемника потока, работающий на DSP1, буферизует поток MPEG2 и организует входные данные для модуля декодера MPEG2. Управление операцией приема данных производится с использованием библиотеки средств разработки сетей (Network Development Kit, NDK) компании TI, которая по существу представляет собой стек TCP/IP. Модуль формирователя пакетов ASF, работающий на процессоре DSP2, формирует пакеты в формате ASF из данных, сжатых в модуле WMV9. В DSP2 также присутствует http-сервер на базе NDK, который обрабатывает запросы на передачу потока от программы Windows Media Player и передает в нее пакеты ASF. Windows Media Player декодирует пакеты ASF и показывает видео на экране.
Одним из наиболее интересных и сложных аспектов передачи потока данных является взаимодействие двух цифровых сигнальных процессоров через интерфейс sRIO. При передаче каждого видеокадра происходит следующее. После того, как DSP1 завершит передачу видеокадра, он посылает пакет данных, который в спецификации протокола sRIO называется DOORBELL. Пакет DOORBELL генерирует системное прерывание в процессоре DSP2, уведомляющее о наличии кадра. В ответ DSP2 запускает процесс кодирования в формат WMV9. Завершив кодирование кадра, DSP2 посылает пакет DOORBELL процессору DSP1. При этом в DSP1 генерируется прерывание, чтобы сообщить о готовности процессора DSP1 продолжить передачу следующего кадра. На практике используется схема буферов с попеременным переключением, чтобы операции кодирования/декодирования и передачи данных выполнялись параллельно.
Блок графического пользовательского интерфейса (GUI) обеспечивает встроенные в систему функции управления и мониторинга. Активность канала связи sRIO и каналов связи Gigabit MAC (GMAC) отображается в реальном времени. При передаче по каналу связи потока данных MPEG-2 средняя скорость передачи составляет 8 Мбит/с, что характерно для кодирования при стандартном разрешении с частотой 30 кадров в секунду. При передаче по каналу связи пакетов ASF средняя скорость передачи составляет 4 Мбит/с. Это показывает, что формат WMV9 способен освободить приблизительно 50% полосы пропускания, обеспечивая сходное качество видео. Для канала связи с интерфейсом sRIO средняя скорость передачи данных составляет 124 Мбит/с.

Таким образом, возможности цифрового сигнального процессора C6455 компании TI в сочетании с интерфейсом sRIO, а также демонстрация описанного прототипа системы транскодирования на основе процессоров C6455 свидетельствуют, что сложная задача передачи видео в IP-сетях может быть успешно решена и в настоящее время, и в будущем.

Рис. 2 Характеристики индивидуального потока с многоканальной потоковой передачей

Несмотря на то что декомпрессия и компрессия предъявляют жесткие требования к производительности компьютера и всё это умножается на большое число каналов, возможности обработки данных, которые еще несколько лет назад были экзотикой, сегодня доступны в современном аппаратном обеспечении и по разумным ценам. Кроме того, специализированные энкодеры систем CCTV снижают производительную нагрузку процессов транскодирования, что делает такие энкодеры практичными и экономически целесообразными, так как дополнительные расходы на аппаратное оборудование для транскодирования компенсируются за счет экономии затрат на хранение и передачу данных, а также использование камер более дешевых моделей.

Преимущества транскодирования
Какие преимущества привносит транскодирование в непосредственное использование потоков видеоданных камер? Когда транскодирование целесообразно, а когда – нет? Давайте более подробно рассмотрим некоторые вопросы.

Использование IP-камер формата JPEG
IP-камеры, использующие технологию сжатия Motion-JPEG, все еще широко используются, существует широкий диапазон дешевых камер с высоким качеством изображения. Однако ахиллесовой пятой таких моделей является относительно низкая эффективность процесса сжатия JPEG. По сравнению с более современными процессами, например H.264, такая камера производит во много раз больше данных и, следовательно, затраты на хранение и передачу данных возрастают в четыре раза и более.
Но если вы используете процесс транскодирования для конвертации JPEG, например в формат H.264, тогда JPEG-камеры можно эксплуатировать в системах CCTV за ту же стоимость, как и камеры, которые непосредственно генерируют изображение в формате H.264. Более низкая стоимость камеры компенсирует затраты на приобретение аппаратного оборудования для транскодирования. Транскодирование в формат H.264 непосредственно снижает требования к хранению или, если посмотреть на это с другой стороны, в равной степени увеличивает длительность записи. При этом коэффициент повышения эффективности может быть равен 4 и более.

Свободно варьируемая многоканальная потоковая передача
Различным пользователям систем CCTV требуются различные свойства видеоматериалов. Всем нужны независимые каналы для просмотра и записи в реальном масштабе времени. По экономическим причинам, несмотря на то что при отсутствии событий канал часто работает с низкой частотой кадров и низким качеством изображения, оба показателя автоматически повышаются в случае возникновения события. Тем не менее для трансляции в реальном масштабе времени совершенно очевидно требуется видеоизображение с высокой частотой кадров. Если необходимо решение этого конфликта задач без компромиссов, тогда исходное изображение нужно отделить от второго независимого видеоканала той же камеры. Именно поэтому многие камеры могут поддерживать функцию потоковой передачи изображения как минимум по двум каналам. Однако ограничения вычислительных возможностей ведут к взаимозависимости двух потоков. В результате пользователь получает либо низкую частоту кадров в двухканальном режиме, либо такая опция недоступна при высоком разрешении камеры. Даже высокотехнологичные камеры, которые отличаются высококачественной двухканальной функцией, достигают своего потолка, когда требуется работа более чем с двумя потоками (рис. 2).
Технология транскодирования позволяет вне зависимости от типа камеры создавать свободно изменяемое число видеоканалов по каждому каналу камеры. Это обеспечивает идеальные параметры изображения в соответствии с предполагаемыми областями применения.

Гибкое управление потоком данных без задержек
Многие IP-камеры имеют очень ограниченные возможности изменения свойств потока видеоданных. Таким образом, разрешение, качество и частота кадров могут регулироваться только несколькими крупными интервалами. Кроме того, часто переключение режимов параметров качества занимает много времени: секунду и более. В таких случаях от повышения качества изображения и частоты кадров в случае возникновения события мало толка, так как слишком много времени проходит между собственно сигналом тревоги и изменением качества изображения, вследствие чего существенная часть важной информации теряется. Иногда эту проблему удается решить за счет постоянной эксплуатации системы при высоком качестве изображения, в котором нет необходимости, что ведет к увеличению расходов.
Транскодирование активирует все параметры, позволяющие регулировать получаемое видеоизображение с небольшим шагом регулировки вне зависимости от камеры. При оптимальной регулировке транскодера переключение может занимать минимальное количество времени. Таким образом, в описанной выше ситуации тревоги может быть обеспечено высокое качество изображения без задержек (рис. 3).

Со спутника видео передается либо в кодеке MPEG-2, либо в H.264 (он же AVC или MPEG-4 part10). Как правило для простоты MPEG-4 part 10 сокращают до MPEG-4, но тут важно не спутать с MPEG-4 part 2, который совершенно никак не совместим и не похож на H.264 и использовался в старых IP камерах.

Аудио передается в MPEG audio layer 2 (сокращенное mp2), либо в ac3 (a/52).

Причём важно понимать, что сегодня H264 как правило сжимается с intra-refresh, т.е. в видео потоке нет опорных кадров (IDR или keyframe). Такой метод сжатия позволяет сгладить скачки битрейта.

В результате ни один из передаваемых со спутника вариантов аудио или видео не проигрывается на айфоне. В браузере проигрывается только H264.

При передаче через интернет как правило можно смело сжимать видео из mpeg2 в h264 с трехкратным снижением трафика.

При передаче HD каналов через интернет сегодня приходится сжимать поток в несколько разных качеств: от HD с максимальным качеством до стандартного SD для компенсации перегруженных каналов.

В итоге видео со спутника для предоставления качественного OTT сервиса надо транскодировать в другие кодеки и качества.

Важно не путать транскодирование с перепаковкой. Транскодирование - крайне ресурсоёмкая операция, включающая в себя:

• распаковку потока до кодированного видео/аудио
• декодирование до сырого видео/аудио
• изменение размеров и прочих параметров
• кодирование обратно
• упаковка в транспорт для потока

Упаковка и распаковка относительно легкие операции, стриминговый сервер может обрабатывать до 1000 каналов на одном компьютере. Транскодировать на одном компьютере можно от 1 до 30 каналов в зависимости от размера и мощности компьютера.

Для транскодирования можно использовать специализированные выделенные устройства, центральный процессор или видеоплату: внешнюю или встроенную в процессор.

Специализированные устройства мы рассматривать не будем, потому что в своей массе это либо компьютер с какой-то программой, либо крайне дорогостоящее и очень специализированное оборудование, или же либо попросту необоснованно дорогое устройство, реализуемое исключительно за счёт маркетинговых усилий компании производителя и не позволяющее достигнуть сколь-либо значимых результатов.

H.264

Для обработки видео на CPU существует несколько разных программ, но по большому счёту на сегодняшний день существует лишь две библиотеки, которые имеет смысл использовать для сжатия в кодек H.264 на CPU: это бесплатная libx264 и платная MainConcept. Всё остальное либо хуже, либо сильно хуже, причём как по выходному результату, так и по использованию ресурсов.

Практика работы с MainConcept в этой статье рассматриваться не будет, будет упомянута только libx264

Кодек H.264 является стандартом де-факто на сегодняшний день для видео, потому что он поддерживается во всех современных устройствах, за исключением разве что некоторых устройств от Google.

Альтернатив ему практически нет. Сегодня появился и развивается H.265, у него уже есть большая поддержка, но пока что работа с ним - это инвестиции в будущее.

Кодеки от Google: VP8 и VP9 являются больше желанием гугла перетянуть одеяло на себя, нежели чем-то реально полезным. Результирующее качество хуже, поддержки аппаратного декодирования нет, а следовательно растет цена устройства.

При кодировании видео надо понимать, что приходится балансировать между такими параметрами:

• задержка внутри энкодера в кадрах
• использование CPU (сколько миллисекунд требуется на сжатие одного кадра)
• выходное качество картинки (насколько пиксельная и какие цвета)
• выходной битрейт

Для всех видов эфира абсолютно критичным является использование CPU. Если настройки энкодера требуют полной загрузки CPU или больше, то видео не будет успевать кодироваться в реальном времени и следовательно потоковость видео пропадет.

Для VOD такого жесткого ограничения нет и фильм длиной в час вполне можно кодировать три часа, если хочется понизить битрейт. При этом для эфирного видео обычно всё таки стараются использовать не всю мощность процессора, что бы обрабатывать на одном компьютере не 4 канала, а 10.

Что касается задержки внутри энкодера, то она критична для видеоконференций, но совершенно некритична для IPTV. Даже 5 секунд задержки при вещании телевидения не меняют качество сервиса.

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

Понимание этой сложной взаимосвязи нужно для того, что бы лучше воспринимать заверения о том, что «наш энкодер самый лучший энкодер в мире». Сравнивать приходится минимум по 4-м параметрам, но в итоге всё сводится к тому: сколько денег стоит разово и в месяц транскодирование одного канала с желаемым качеством и выходным битрейтом.

Flussonic Media Server для транскодирования

Отдельным пакетом к Flussonic Media Server идет транскодер .

Flussonic Media Server может декодировать видео из UDP/HTTP MPEG-TS, RTMP источников и кодировать его в несколько качеств и размеров.

Эта возможность становится нужна, когда возникает необходимость показывать видео не только на приставках, но и на планшетах: там выбор доступных кодеков существенно меньше, чем на приставке.

Важно отметить, что для того, что бы видео игралось на айфоне, надо даже H264 со спутника транскодировать, потому что как правило на спутнике для плавного битрейта используется intra-refresh режим кодирования, создающий видео, которое не играется на айфоне.

Flussonic Media Server удобнее чем VLC или другие варианты для организации транскодирования, потому что управляется одним конфигурационным файлом и автоматически следит за состоянием транскодирования. VLC же требует написания большого количества мониторинговых скриптов для отслеживания состояния транскодирования.

Следующая важная возможность Flussonic Media Server для транскодирования - автоматическая перебалансировка потоков при падении одного из серверов. Если один из 20 транскодеров ночью сломается, то остальные транскодеры можно настроить на автоматический захват потоков для транскодирования, причём стример сам заберет потоки с резервных транскодеров.

Транскодирование означает конвертацию файла, закодированного одним методом, с использованием другого метода. Транскодироваеие может быть выполнено из lossless в losslessб из lossless в lossy, из lossy в lossy, а также из lossy в lossless.

Для транскодирования используется конвертор, например foobar2000 .

Lossy -> lossy

Каждый раз, когда выполняется кодирование lossy кодером, качество ухудшается. Также никак нельзя вернуть былое качество, даже если вы закодируете MP3 128 кбит/с в MP3 320 кбит/с (или в любой другой формат с высоким качеством).

По этой причине транскодирование между lossy форматами крайне не рекомендуется. Качество результирующего файла всего будет хуже, что у файла-источника. Тем не менее, поводы для такой оерации могут быть следующие:

• Понижение битрейта или преобразование в другой формат для использования с портативными плеерами, в сулчае с которыми качество может не слишком заботить.
• Экономия места на жестком диске. Несжатые данные с Audio CD имеют битрейт 1411 кбит/с (605 МБ/час); lossless кодеры позволяют уменьшить поток в среднем до 700 кбит/с (300 МБ/час). Lossy кодеры, вроде Vorbis, MPC и AAC как правило обеспечивают прозрачное звучание на битрейтах в районе 150-170 кбит/с (69 МБ/час). Для MP3 (в случае использования LAME), прозрачность обычно достигается при битрейте ~192 кбит/с (82 МБ/час). Для большой музыкальной коллекции в таких случаях экономия относительно lossless сжатия может быть значительной.

Lossless -> lossless

В отличие от вышеупомянутого lossy транскодирования, в данном случае качество не теряется . Таким образом, вы можете выполнять преобразование из одного lossless формата в другой столько раз, сколько вам понадобится (например, чтобы увеличить степень сжатия или обеспечить совместимость с определенными программами/устройствами).

Lossless -> lossy

Архивирование музыки в lossless сохраняет возможность дальнейшего перекодирования музыки в другой lossy формат (например, в случае появления новых версий кодеров). К примеру, если на данный момент lossy формат X прозрачен на 192 кбит/с, а через три года появится формат Y, который будет прозрачен на 128 кбит/с - едва ли в этом случае транскодирования X@192 kbps в Y@128 kbps даст приемлемый результат, в отличие от кодирования из lossless. Это объясняется тем, что для формата X, так как он кодирован с потерями, некоторая информаци, расцененная как не критичная, удаляется, в то время как по мнению кодера Y она вполне модет оказаться важной. В результате этого кодирование Y будет значительно искаженным.

Если вы кодируете в lossy из lossless источника, настоятельно рекомендуется сохранять оригинальный lossless файл . В таком случае, если результаты кодирования окажутся неудовлетворительными, можно перекодировать материал заново.

Обратите внимание: некоторые конвертеры имеют опцию автоудаления файлов-источников. Проверяйте, чтоб она была отключена.

Lossy -> lossless

Довольно часто люди думают, что могут улучшить качество звука путем транскодирования lossy в lossless (например, MP3 во FLAC). Фактически, преобразование lossy в lossless является абсурдом, потому что как только материал прошел lossy кодирование, по определению, потери уже произошли, и они необратимы. Так что, хотя вы можете выполнять преобразование из lossy формата в lossless (что, кстати, происходит во время проигрывания lossy файла), звук при этом не меняется, т. е. меняется фактически только формат его хранения.

Если вам когда-то придется выполнять такое конвертирование, вы должны указать lossy происхождение в имени файла (а также, желательно, в тегах), чтобы все, кто использовал этот файл, сразу же видели, что он получен не из оригинального (lossless) источника.

В каких случаях используется транскодирование lossless в lossy:

1. Архивация аудио, источником которого является устаревший или проприетарный lossy формат, без потерь качества.
2. Редактирование аудио, которое не может быть изменено непосредственно в виде lossy.
3. Как промежуточный формат для кодирования lossy -> lossy.

Чтобы отсеять контент, выдаваемый за оригинальный lossless, пользователи и администраторы файлообменных сервисов часто используют спектральный анализ или специальные программы. Также этими способами пользуются покупатели компакт-дисков, чтобы выяснить, не было ли выполнено кодирование с потерями в процессе создания и дистрибуции материала (что порой действительно имеет место).

Информация от спонсора

Remeshkov.ru: интернет-магазин ремешков для часов. Здес Вы можете приобрести ремешок для часов от ведущих мировых производителей (Longines, Omega, Corum и др.). Также на сайте магазина можно узнать, как измерить ремешок для часов.

Бесплатные антивирусы