tanenbaum_seti_all.pages (525408), страница 206
Текст из файла (страница 206)
Единственная серьезная проблема заключается в том, что вся запись должна быть предварительно передана по сети. Если музыкальный файл занимает 4 Мбайт (типичный размер аудиофайла с песней в формате МР3) и передается при помощи модема со скоростью 56 Кбит/с, пользователь будет наслаждаться тишиной в течение почти 10 минут, прежде чем услышит музыку. Далеко не все меломаны приходят от этого в восторг. К тому же не стоит забывать, что после окончания данной песни следующую можно будет услышать также только через 10 минут.
Как обойти эту проблему, не внося изменений в работу браузера7 Музыкальные сайты пришли к следующей схеме. Файл, связанный гиперссылкой с названием песни, на самом деле является не музыкальным, а метафайлом. Метафайл обычно очень короткий, в типичной ситуации ои состоит всего лишь из одной текстовой строки, которая выглядит примерно так: ггзр: I/1оеюаэ01о-зегтегИоп0-0025.арЗ Получив такой однострочный файл, браузер записывает его во временный файл, запускает в качестве вспомогательного приложения проигрыватель и передает ему, как обычно, имя временного файла.
Проигрыватель видит, что временный файл содержит 1)К1.. Он соединяется с сервером)оез-аийо-зегэег и запрашивает песню. Вы, должно быть, уже заметили, что браузер не принимает участия в этом процессе. В большинстве случаев сервер, указанный в метафайле, не совпадает с веб-сервером, содержащим ссылку на метафайл. Более того, обычно это даже не НТТР- сервер, а специализированный мультимедийный сервер. В приведенном примере этот сервер использует протокол КТО, это становится понятно при взгляде на ссылку — она начинается с названия схемы, гор. КТЯР описан в КРС 2326. Проигрыватель мультимедиа решает следующие 4 основные задачи: 1.
Управление интерфейсом пользователя. 2. Обработка ошибок передачи. 3. Распаковка сжатых аудиоданных. 4. Устранение флуктуации (джиттера). Большинство современных программ для воспроизведения мультимедиа имеют привлекательный интерфейс. Часто внешний вид панелей управления (оболочек) можно менять. Как мы уже сказали, в задачи проигрывателя входит общение с пользователем. Вторая его задача — обработка ошибок. При передаче музыки в реальном времени редко используется протокол ТСР, так как ошибки и повторные передачи могут приводить к недопустимо долгим паузам.
Вместо этого передача осуществляется по протоколу типа КТР, который мы изучали в главе 6. Подобно большинству протоколов реального времени, КТР работает поверх 1Л)Р, то есть Мультимедиа 769 Этот пакет содержит 220 нечетных отсчетов Этот пакет содержит 220 четных отсчетов "ю1 иаЙ Пакет 0 1 2 4 5 0 5 10 15 20 25 30 Время, мс — — ~ Рис. 7.20. Когда пакеты содержат чередующиеся отсчеты, потеря пакета уменьшает частоту следования отсчетов, но нв приводит к возникновению паузы Третья зздача программы-проигрывателя заключается в декодировании сжатых аудиоданных. Несмотря на высокую требуемую интенсивность вычислений, применяемый метод довольно очевиден.
Четвертая задача — устранение флуктуации (джиттера), бича всех систем реального времени. Все системы воспроизведения потокового аудио перед началом пакеты могут теряться по пути. Проблему потерянных пакетов решает проигрыватель. Иногда для упрощения обработки ошибок при передаче музыки применяется принцип чередования. Например, пакет может содержать 220 стереоотсчетов, каждый из которых содержит пару 16-разрядных чисел.
Этого вполне достаточно для 5 мс звучания музыки. Однако протокол может посылать в одном пакете все нечетные отсчеты для 10 мс звучания, а в следующем — все четные отсчеты для того же интервала. Таким образом, потеря одного пакета не приведет к возникновению паузы длиной 5 мс, вместо этого будет потерян каждый второй отсчет 10-миллисекундного интервала. Эта утрата может быть восполнена, если проигрыватель произведет интерполяцию, используя предыдущий и следующий отсчеты (относительно каждого потерянного). Таким образом, примерные значения будут восстановлены. Принцип чередования, используемый для восстановления ошибок, показан на рис. 7.29. Здесь видно, что каждый пакет содержит чередующиеся отсчеты для 10-миллисекундного интервала.
В результате потери пакета 3 (см, рисунок) не возникает паузы, а только лишь на некоторое время снижается частота следования отсчетов. Утерянные значения путем интерполяции могут быть восстановлены; зто обеспечит непрерывность звучания, Данная конкретная схема работает только с несжатыми отсчетами, однако она показывает, как при помощи хитрого алгоритма кодирования превращать потерянные пакеты не в раздражающие паузы, а в непрерывные интервалы с пониженным качеством. Между тем в йгС 3119 описан метод, позволяющий применять аналогичную процедуру к сжатым аудиоданным. 770 Глава 7.
Прикладной уровень проигрывания буферизируют около 10-15 с звучания, как показано на рис. 7.30. В идеале — сервер должен продолжать заполнять буфер со скоростью, необходимой для проигрывателя, однако в реальности это может и не происходить, поэтому всегда полезно иметь постоянную обратную связь. Существуют два способа постоянного поддержания буфера в заполненном состоянии. При использовании выталкивающего сервера (ри11 зегуег) проигрыватель отправляет запросы на получение нового блока всегда, когда в буфере есть свободное место.
Цель этого метода состоит в том, чтобы загружать в буфер как можно больше данных. Клиентская машина Сервер Нижний Верхний предел предел Рис. 7.30. Проигрыватель буферизирует входные денные, принимаемые с мультимедийного сервера, и воспроизводит содержимое буфера, а изданные, поступающие напрямую из сети Недостатком выталкивающего сервера является наличие необязательных запросов данных, Серверу известно, что он отослал весь файл, так почему же проигрыватель продолжает что-то запрашивать? По этой причине данный метод используется редко. При использовании проталкивающего сервера проигрыватель отправляет запрос РЕАЛ (Воспроизведен1те), и сервер просто отправляет ему данные.
При этом возможны два варианта: либо сервер мультимедиа работает со скоростью воспроизведения, либо он работает с более высокой скоростью, В обоих случаях некоторое количество данных буферизируется перед началом проигрывания. Если сервер работает со скоростью воспроизведения, то посылаемые им данные добавляются в конец буфера, а проигрыватель извлекает данные из начала буфера. Пока все работает без сбоев, объем данных, хранимых в буфере, остается постоянным во времени. Это очень простая схема — здесь не требуется пересылать управляющие сообщения в каких-либо направлениях.
Еше один вариант схемы проталкивания основан на том, что сервер выдает данные быстрее, чем реально требуется проигрывателю. Преимуществом является то, что при отсутствии гарантий стабильной скорости сервер имеет возможность наверстать упущенное из-за задержки время. Однако есть опасность переполнения буфера, возникающая вследствие того, что данные «потребляются» медленнее, чем выдаются (а это, в свою очередь, необходимо для устранения возможных пауз при воспроизведении). Решением этой проблемы является установка проигрывателем нижнего и верхнего пределов заполнения буфера. Суть в том, что сервер выдает данные Мультимвдиа 771 лишь до тех пор, пока буфер не заполнится до верхнего предела.
После этого проигрыватель просит сервер приостановить передачу. Поскольку данные будут продолжать прибывать в течение времени передачи запроса приостановки, расстояние между верхним пределом н концом буфера должно быть больше некоторого Х вЂ” количества данных, которые успеют передаться за этот промежуток времени.
Х соответствует задержкам в канале, возникающим вследствие ограниченной пропускной способности. После приостановки сервера буфер начнет опустошаться. Когда количество данных в пем достигнет нижнего предела, проигрыватель попросит сервер мультимедиа возобновить передачу. Нижний предел должен быть установлен таким образом, чтобы буфер не опустошался полностью. Для работы по методу проталкивающего сервера проигрыватель должен осуществлять удаленное управление сервером.
Это обеспечивается протоколом КТБР, предоставляющим соответству1ощнй механизм управления. Он определен в КГС 2326. Протокол не предназначен для управления потоком данных, для этого обычно применяется КТР. Основные команды ИТАР приведены в табл. 7,17, Таблица 7.17. Команды ЙТЗР, посылаемые проигрывателем на сервер Двйотвив сервера Команда ЭЕЗСР!ВЕ ЗЕТОР РГАУ ПЕСОПО РАОЗЕ ТЕАП ВОУУМ Перечисляет параметры мультимедийных данных Устанавливает логическое совдинвнив мажду проигрывателем и сервером Начинает отправлять данные клиенту Начинает прием данных от кливнта Приостанавливавт передачу данных Удаляет логическое соединение Интернет-радио Как только стало возможным передавать потоковое аудио через Интернет, коммерческие радиостанции задумались о том, как бы организовать вещание в Сети (параллельно с вещанием в эфире).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
