Оптимальный путь тракта и кодирования в AVC

Здесь обсуждаются любые продукты компании СофтЛаб-НСК для телевизионного вещания (Форвард Т, Форвард ТС, Форвард Голкипер, Форвард Рефери, Форвард Офис, Форвард Инжест)

Модераторы: Людмила, PR, vd, Даниленко Сергей

Ответить
Boyler
Сообщения: 80
Зарегистрирован: 30 май 2006 19:51
Откуда: Мурманск

Оптимальный путь тракта и кодирования в AVC

Сообщение Boyler »

Здравствуйте!
1. Контент от агрегатора приходит в MPEG-2 (.mpg). Ставил в чистом виде - иногда воспроизведение подвисает. Да и места занимает много (поток в 9000 кбит/с). Перекодирую в H.264/AVC с потоком 4000 кбит/с прогресив.
2. Если у меня на воспроизведение идет источник из файлов в прогрессиве, что ставить на выходе в IP? Интерлейс нужен? К операторам уходит только IP, аналог не уходит никуда, кроме моего контроля на мониторы.
3. Что лучше ставить на источник в графе для передачи в IP: аналоговый выход с платы или VRT-выход с виртуальной платы? Плата FD322. Внешнего источника (аналоговые входы на плату) нет, только файлы с сервера.
Вопрос только в сокращении цепочек преобразований сигнала/файлов/пакетов.
Спасибо за консультацию.
vd
Сообщения: 2311
Зарегистрирован: 05 мар 2003 19:21

Сообщение vd »

Контент от агрегатора приходит в MPEG-2 (.mpg). Ставил в чистом виде - иногда воспроизведение подвисает. Да и места занимает много (поток в 9000 кбит/с). Перекодирую в H.264/AVC с потоком 4000 кбит/с прогресив.
Не берусь подсказать по пунктам 2 и 3, могу сказать про подвисания и перекодирование файлов MPEG2.

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

Дело в том, что бывают не совсем корректные MPEG2-файлы. Например, если они получены в результате захвата аналогового видео с некачественного источника (видеокассета, сигнал с помехами с потерей синхронизации). Или, например, если это поток, записанный прямо со спутника без перекодирования. Там тоже бывают помехи (из-за плохой погоды сигнал со спутника, бывает, портится), в результате получается "битый" файл, который может даже вполне нормально воспроизводиться в каком-то программном плеере, но в нашем ПО такие файлы могут воспроизводиться с проблемами. У нас для декодирования по умолчанию используется декодер от компании Elecard - на нашей практике бывало, что какие-то "битые" файлы их декодер может плохо воспроизводить. Но и другие декодеры от этого не застрахованы, особенно, если повреждены не сами видеоданные, а пакеты с временем в кадрах.

Для "лечения" таких файлов может помочь, действительно, их полное перекодирования. Но можно попробовать просто видео и звук "разобрать" на отдельные элементарные потоки, и затем просто смикшировать обратно. Это позволяет, например, программа TMPGEnc. После перемикширования получается корректный файл с правильно проставленными временами в кадрах, и он потом воспроизводится нормально. Правда, 100% гарантии нет, это может и не помочь. Но зато при таком подходе нет полного перекодирования - не теряется исходное качество видео, и это гораздо быстрее, чем перекодирование, да еще и в AVC.

По поводу второго пункта могу сказать только то, что если вы воспроизводите файлы с прогрессивным видео, то не имеет никакого значения, ставите ли вы на выходе интерлейс или нет. Если видео действительно прогрессивное, то в кадрах будут полукадры, не смещенные относительно друг друга по времени, и все равно, какие настройки будут в выходном кодере - интерлейс или прогрессив.

Но тут важно еще то, чем и как Вы перекодируете исходные MPEG2-файлы, и какие они сами. Если исходные файлы интерлейсные, то как Вы получаете из них AVC с прогрессивом? При кодировании включаете принудительный деинтерлейс? А зачем? Можно интерлейсные файлы оставлять интерлейсными, на качестве воспроизведения это не скажется, если поля не перепутаны.

Тут важно еще вот что. Если исходные файлы NTSC, т.е. 29.97 кадров/сек, а на выходе PAL, то будут проблемы при воспроизведении.

В общем, здесь довольно много вопросов возникает. Если хотите разобраться с подвисаниями файлов, то, повторюсь, нам такие файлы нужны для анализа. По этому поводу лучше напишите письмо на forward@softlab.tv - там расскажут, что еще нужно прислать, помимо самих файлов. По остальным вопросам там тоже лучше расскажут, чем здесь, т.к. наверняка потребуется от Вас дополнительная информация, которую лучше прислать письмом.
Boyler
Сообщения: 80
Зарегистрирован: 30 май 2006 19:51
Откуда: Мурманск

Сообщение Boyler »

ОК, спасибо за советы. Обращусь в техподдержку.
Игорь Таранцев
Сообщения: 493
Зарегистрирован: 04 янв 2004 12:45
Откуда: СофтЛаб-НСК

Сообщение Игорь Таранцев »

Очень НЕ рекомендую менять формат кадра без особой неоходимости. В том числе перекодировать в прогрессив исходно чересстрочное видео. При этом гарантированно теряется качество картинки и очень сильно. Это имеет смысл делать только для того, чтобы привести формат видео к выходному формату. Менять формат с 50P на 25P тоже не нужно.
То, что Вы отдаете IP ничего не меняет с точки зрения формата кадра. Главное, в каком формате (на каком устрйостве) смотрят Ваше видео зрители. Если это ТВ стандартного разрешения, то видео обязано быть чересстрочным. Если это показ только через интернет в окне браузера, то можно передавать и прогрессивоне видео. Либо это может быть формат 720P50 (1280х720 50 кадров в секунду, без полей). Соответственно, именно в таком формате и должна работать плата. Очевидно, что плата FD322 может работать только с сигналами ПАЛ или НТСЦ. Если Вы работаете, например, с ПАЛ, то можно кодировать в IP выход платы FD300. Иначе нужно создавать виртуальную плату нужного формата.
Boyler
Сообщения: 80
Зарегистрирован: 30 май 2006 19:51
Откуда: Мурманск

Сообщение Boyler »

ОК, понял вашу мысль. Сейчас уже сложно будет попробовать отловить, на каких именно файлах (от какого поставщика) были затыки про воспроизведении MPEG-2, т.к. всё перевожу в MPEG-4, рисковать эфиром совсем не интересно. ;)
Попутно, чтоб не плодить лишних веток, такой вопрос. При кодировании IPOut/AVC возникает задержка в 3,5 сек примерно. Далее возникает задержка при передаче потока в Москву и распределении до операторов (примерно 30 сек). Кто как борется с этим делом?
Самое простое - выстраивать расписание с учетом на эту задержку (в среднем запускать контент на 30-35 сек раньше, чем реальное время). Может есть способ заставить опорные (системные) часы идти с отклонением в -35 сек постоянно? Сейчас синхронизируюсь в "ноль" по Интернете (не средствами Windows). Может есть у кого наработки по этому вопросу?
vd
Сообщения: 2311
Зарегистрирован: 05 мар 2003 19:21

Сообщение vd »

А как конечные зрители узнают, что вообще была какая-то задержка? Особенно при вещании файлов с диска в расписании, а не проходящего видео?
Самое простое - выстраивать расписание с учетом на эту задержку (в среднем запускать контент на 30-35 сек раньше, чем реальное время).
Что такое "реальное время"? Откуда оно берется? Вы знаете, что какой-то файл должен выйти в эфир, допустим, в 12:00, и хотите, чтобы на другом конце зритель увидел его начало в это же время? А зачем?
Boyler
Сообщения: 80
Зарегистрирован: 30 май 2006 19:51
Откуда: Мурманск

Сообщение Boyler »

Например, Новости должны выйти в 12:00 или сериал начало в 16:00. Многие IPTV операторы берут программу передачи и публикуют её сопутствующим сервисом на STB. Вечерний прайм кино в 21:00. 30 сек конечно не критично для кино и сериала, нро для новостей ... как-то не очень гуд. )
Реальное время в данном случае - это синхронизированное через Интернет время от NTP-серверов для моего часового пояса.
vd
Сообщения: 2311
Зарегистрирован: 05 мар 2003 19:21

Сообщение vd »

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

А если серьезно, то предусмотреть и просчитать все задержки в цифровом ТВ вряд ли возможно. А также гарантировать то, что через полгода не изменится маршрут прохождения потока, и задержка не станет другой.

Я вспоминаю, как дома смотрел открытие олимпиады в Сочи. Обнаружил две трансляции: одна на сайте 1tv.ru, другая в youtube. Было видно, что между ними задержка секунд 15 - более чем заметно. И событие, вроде, не рядовое для нашей страны. Тем не менее, не слышал про упоминания в сети про этот факт.
Boyler
Сообщения: 80
Зарегистрирован: 30 май 2006 19:51
Откуда: Мурманск

Сообщение Boyler »

Жалоб не слышал, а вот самому неприятно. ))))
Ответить