Добавлено: Thu Apr 09, 2009 1:10 am Заголовок сообщения: Этот многоликий Mpeg-2
Ситуация такая - вещаем с сетевых дисков. Я знаю, это не рекомендуют авторы программы, но суть не в этом. Такова технология у меня и сменить вряд-ли что-то получится. В принципе все устойчиво работает, при воспроизведении видео загрузка 100 Мбитной сетки порядка 5-10%. но заметил странную особенность "зачитки" программой мпег-2 файлов (с другими не работаем пока - может там лучше). Видимо у программы есть какой-то внутренний кеш-буфер, куда помещается поток воспроизводимого файла (причем поток зачитывается НЕ равномерно с опережением, а так: за несколько секунд перед концом вопроизводимого клипа чтение данных прекращается (видимо идет только чтение данных этого клипа из буфера, а из следующего клипа в это время ничего не берется, и зачитка следующего клипа начинается только тогда, когда до него доходит очередь в плейлисте. В этот момент возникает пиковая нагрузка на сеть (или у кого-то на дисковую подсистему) и пока кеш-буфер не заполнится чем-то - на экран ничего не выводится (висит стоп-кадр конца предыдущего клипа).
Жаль картинку с графиком загрузки сети сюда вставить нельзя. Ну алгоритмы работы конечно дело разработчиков, может когда-то и сделают более оптимально. Но дело не в этом - тут вот возникает самое интересное: некоторые mpeg-2 файлы начинают воспроизводится практически сразу после зачитки первых килобйт в кеш и задержки практически нет, а некоторым файлам нужно по 5-30 секунд чтобы зачитать достаточно большой кусок, и только потом начинают воспроизводиться. Битрейт у всех постоянный, потоки не сильно отличаются. Формат звука вреде как одинаковый. Интересно - может кто-то уже сталкивался с подобным. Особенно интересно услышать, может что скажут разработчики - они ж точно знают "что под капотом"
Добавлено: Thu Apr 09, 2009 10:45 am Заголовок сообщения:
Вообще, для вещания с сетевых ресурсов желательна жесткая 100% буферизация. Т.е. видеосервер сам должен заранее "подкачивать" на свой диск файлы, указанные в плейлисте, скажем, на ближайшие 3-4 часа, и хранить их там до окончания воспроизведения этих файлов. Потом стирать...
Что бы это сделать надо ставить доплнительные плату,
типа Matrox,стоимость минимальная от 4000$ и выше.
Многие себе это могут позволить?
Непонятно, зачем для буферизации ставить дорогую плату? Достаточно написать подпрограмму, просматривающую плейлист на несколько часов вперед и подкачивающую файлы, которые по плейлисту расположены на сетевых ресурсах, на локальный рейд в буфер, а после выхода файлов в эфир, стирающую подкачанные ранее файлы, если их нет в плейлисте дальше. При подготовке к выходу блока проверяется, есть ли файл локально, если есть - выдается локальная копия. Если вдруг нету, или файл в сети изменился (можно проверить просто по атрибутам) - выдается сетевая копия.
Сейчас для сервера не имеет значения, локальный файл или в сети, он считает - что все локальные.
Автору можно порекомендовать использовать гигабитную сеть.
Зачем тогда используют монтажные платы? Можно на обычном компе работать. Это снимает нагрузку на комп и получаешь реал тайм, что не сможешь без платы.
А по сети, нужно отключать антивирус, все защиты, в том числе и XP, процессор покручете, памяти и когда вещаете именно с сетевого райда еще он называется NAS, во первых Raid какой? пользователей сколько?,
диски по скорости? Ну и сеть?
Коллеги, давайте говорить конструктивно и не разводить флейм. Каждый работает как умеет. У нас свое вещание 18 часов в сутки. Свои программы, архив фильмов, клипов, рекламы -все на сетевых серверах. Переписывать на вещающий комп нет смысла, хотя, конечно можно, но слишком много головной боли, а главное зачем? Содержимое сетевого сервера программно дублируется ( т.е один основной, один резервный) кодирование видео ведется автоматически софтовыми кодерами на основном сервере под ХР Pro, куда монтажные сливают готовые передачи по сетке в DV, резервный под FreeBSD. Подключается вещающий комп к дискам основного, если надо - есть ярлык "Подключить резервный" - к резервному. Весь народ по чтению работает с резервным (нет ограничение на количество подключений) Все собственные разработки, все работает, все устраивает. Вопрос же не в этом - вопрос в другом - почему одни МПЕГ-2 файлы прекрасно читаются по сети сразу и без задержек, а одним нужно что-то кешировать. Сегодня пробовал просто прогнать без пересчета то что тормозило через мой любимый MORGAN MPEG VIDEO WIZARD. Тормозить перестало. Сравниваю исходный и перегнанный файлы, ищу различия. Я думаю, что проблему можно решить много проще, без всяких внешних кодеров и копирований- надо только покопать мозгами. Пока обнаружил, что в исходном файле присутствует флаг "Constraint System Parametеr Stream". Копаю дальше...
Вот буферизация и снимает нагрузку на компьютер и сеть во время воспроизведения. Потому что копирование будет идти в фоновом режиме, с низким приоритетом, ну и программист может предусмотреть копирование во время простоя. Антивирус вы и так запретили ставить, а чем фоновое копирование отличается от копирования ручного в плане загрузки процессора? Ничем абсолютно. Займет пару процентов ресурсов процессора.
Если вещать именно с сетевого рейда, то буферизация и не нужна будет. Тем более, для MPEG2. Естесственно, тогда нужна сетка гигабитная и пользователей минимум. Но автор и не поднимает вопрос о сетевом рейде.
На самом деле, вопрос с буферизацией интересен и без сети, потому что папка с видеофайлами - это помойка, где копится все, что вышло уже. А при наличии буферизации можно использовать быстрый но маленький рейд и большой одиночный медленный диск под накопление файлов.
Я вам про Фому, Вы мне про Ерему...
Дело в том что потоки мпег-2 мпег-4 мизерные и с ними вполне справляется и 100 мегабитная сетка, и обычные саташные диски без рейда. Надо только подобрать правильные параметры кодирования, чтбы DiGi их нормально в списке воспроизводил.
Сравниваю исходный и перегнанный файлы, ищу различия. Я думаю, что проблему можно решить много проще, без всяких внешних кодеров и копирований- надо только покопать мозгами. Пока обнаружил, что в исходном файле присутствует флаг "Constraint System Parametеr Stream". Копаю дальше...
Это интересная тема, сообщайте что удастся найти.
Что касается сети - насколько я помню, в любой программе для работы с потоком DV и выше по сети, обязательным требованием была гигабитная сеть. Источников точно сейчас не вспомню, но видел такую информацию на разных сайтах.
Гигабитная сеть конечно хорошо. Для DV у которого поток в 3,5 Mбайт/сек. и 100 Мегабитной достаточно (у сотки максимум 8-10 Мегабайт/секунду - более чем двойной запас) Вещать из Премьера можно, проверено. А монтировать, конечно с сетевого диска по сотке невозможно - для нескольких потоков не хватает скорости.
Я между эфирным компьютером и архивом (по совместительству рабочая станция одного из монтажников) проложил оптику, вставил гигабитные сетевые платы. Возможно, это решит и вашу ситуацию.
Для сто мегабитной сети это не более чем теоретическая цифра. Реальные данные ощутимо ниже. А расчетную нагузку нужно брать опираясь на пиковые моменты и учитывая при этом другую сетевую активность, которая так же не избежна в реальных условиях. Отсюда и рекомендуемая гигабитная сеть.
Проблему решил c mpeg-2 - поменял на кодирующем сервере кодер с Canopus-а на mencoder. Убил двух зайцев - файлы по сети значительно лучше читаются и кодер в лицензии не нуждается. Пока так будет, а в перcепективе может на mpeg-4 перейдем.
Проблему решил c mpeg-2 - поменял на кодирующем сервере кодер с Canopus-а на mencoder.
У нас с вами есть что-то похожее в организации вещания. Мы тоже вещаем по сети с файл-сервера (Win-server), правда дублирующего сервера у нас нет, но на основном стоит внешний SCSI-массив в рейде 51 уровня. А вот к сетке я подошел посерьезней, эфирные машинки с коммутатором - 1 Гбит. А коммутатор с сервером транком 3Гбит. Дело в том, что монтажки у нас работают с этим же файл сервером, конечно они монтируют на своих локальных дисках. Но, мало ли. Кто-то может случайно "сунуть" в проект материал прямо с сервера. Вот из чего я исходил.
Проблем с задержками воспроизведения нет вообще никаких.
А у меня в серверах по 3 гигабитных сетевухи и в конторе 3 подсети-
1:сервера между собой гигабитной сеткой через гигабитный комутатор обычный (ди-линк) для синхронизации данных между собой.
2: ответственные машины типа монтажек, студий и передатчика - по сотке к гигабитному комутатору (16 соток+2Гигабитных порта), который гигабиткой к серверам
3:Все остальные машины (редактора, руководство, журналисты и т.п.) по сотке к комутаторам на этажах или в отделах, и дальше к гигабитному комутатору (16 соток+2Гигабитных порта), который гигабиткой серверам. Так что все достаточно серьезно
А мы по стоимости прикинули - дешевле и надежнее дублировать сервера, чем дорогие рейды покупать. И рулить стандартами вещания (сжатием и т.п.) на сервере много проще чем объяснять монтажникам параметры кодирования и все такое. Архивы хотим хранить - это сотни часов материала. Решение бюджетное и более устойчивое к любым аппаратным сбоям и можно процессорные мощности для кодирования файлов еще использовать, и винты апгрейтнуть потом проще. На дублирующих серверах везде операционка FreeBSD, 8 винтов под данные и два системных, стоимость их порядка 2000 долларов каждый.
Программное обеспечение, конечно, сложнее чем под винду настроить, но главное начать - а там само идет.. Вообще как опыт показывает - чем решение аппаратно проще - тем оно надежнее.
Вы можете начинать темы Вы можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Для DV у которого поток в 3,5 Mбайт/сек. и 100 Мегабитной достаточно (у сотки максимум 8-10 Мегабайт/секунду - более чем двойной запас) Вещать из Премьера можно, проверено. А монтировать, конечно с сетевого диска по сотке невозможно - для нескольких потоков не хватает скорости.