Оптимальный путь тракта и кодирования в AVC
Модераторы: Людмила, PR, vd, Даниленко Сергей
-
- Сообщения: 80
- Зарегистрирован: 30 май 2006 19:51
- Откуда: Мурманск
Оптимальный путь тракта и кодирования в AVC
Здравствуйте!
1. Контент от агрегатора приходит в MPEG-2 (.mpg). Ставил в чистом виде - иногда воспроизведение подвисает. Да и места занимает много (поток в 9000 кбит/с). Перекодирую в H.264/AVC с потоком 4000 кбит/с прогресив.
2. Если у меня на воспроизведение идет источник из файлов в прогрессиве, что ставить на выходе в IP? Интерлейс нужен? К операторам уходит только IP, аналог не уходит никуда, кроме моего контроля на мониторы.
3. Что лучше ставить на источник в графе для передачи в IP: аналоговый выход с платы или VRT-выход с виртуальной платы? Плата FD322. Внешнего источника (аналоговые входы на плату) нет, только файлы с сервера.
Вопрос только в сокращении цепочек преобразований сигнала/файлов/пакетов.
Спасибо за консультацию.
1. Контент от агрегатора приходит в MPEG-2 (.mpg). Ставил в чистом виде - иногда воспроизведение подвисает. Да и места занимает много (поток в 9000 кбит/с). Перекодирую в H.264/AVC с потоком 4000 кбит/с прогресив.
2. Если у меня на воспроизведение идет источник из файлов в прогрессиве, что ставить на выходе в IP? Интерлейс нужен? К операторам уходит только IP, аналог не уходит никуда, кроме моего контроля на мониторы.
3. Что лучше ставить на источник в графе для передачи в IP: аналоговый выход с платы или VRT-выход с виртуальной платы? Плата FD322. Внешнего источника (аналоговые входы на плату) нет, только файлы с сервера.
Вопрос только в сокращении цепочек преобразований сигнала/файлов/пакетов.
Спасибо за консультацию.
-
- Сообщения: 2311
- Зарегистрирован: 05 мар 2003 19:21
Не берусь подсказать по пунктам 2 и 3, могу сказать про подвисания и перекодирование файлов MPEG2.Контент от агрегатора приходит в MPEG-2 (.mpg). Ставил в чистом виде - иногда воспроизведение подвисает. Да и места занимает много (поток в 9000 кбит/с). Перекодирую в H.264/AVC с потоком 4000 кбит/с прогресив.
Лучше всего, если вы примеры таких подвисающих файлов пришлете нам для изучения. Также пригодятся лог-файлы, записанные во время таких подвисаний. Если напишете письмо в нашу техподдержку, вам лучше объяснят, какие файлы нужны.
Дело в том, что бывают не совсем корректные MPEG2-файлы. Например, если они получены в результате захвата аналогового видео с некачественного источника (видеокассета, сигнал с помехами с потерей синхронизации). Или, например, если это поток, записанный прямо со спутника без перекодирования. Там тоже бывают помехи (из-за плохой погоды сигнал со спутника, бывает, портится), в результате получается "битый" файл, который может даже вполне нормально воспроизводиться в каком-то программном плеере, но в нашем ПО такие файлы могут воспроизводиться с проблемами. У нас для декодирования по умолчанию используется декодер от компании Elecard - на нашей практике бывало, что какие-то "битые" файлы их декодер может плохо воспроизводить. Но и другие декодеры от этого не застрахованы, особенно, если повреждены не сами видеоданные, а пакеты с временем в кадрах.
Для "лечения" таких файлов может помочь, действительно, их полное перекодирования. Но можно попробовать просто видео и звук "разобрать" на отдельные элементарные потоки, и затем просто смикшировать обратно. Это позволяет, например, программа TMPGEnc. После перемикширования получается корректный файл с правильно проставленными временами в кадрах, и он потом воспроизводится нормально. Правда, 100% гарантии нет, это может и не помочь. Но зато при таком подходе нет полного перекодирования - не теряется исходное качество видео, и это гораздо быстрее, чем перекодирование, да еще и в AVC.
По поводу второго пункта могу сказать только то, что если вы воспроизводите файлы с прогрессивным видео, то не имеет никакого значения, ставите ли вы на выходе интерлейс или нет. Если видео действительно прогрессивное, то в кадрах будут полукадры, не смещенные относительно друг друга по времени, и все равно, какие настройки будут в выходном кодере - интерлейс или прогрессив.
Но тут важно еще то, чем и как Вы перекодируете исходные MPEG2-файлы, и какие они сами. Если исходные файлы интерлейсные, то как Вы получаете из них AVC с прогрессивом? При кодировании включаете принудительный деинтерлейс? А зачем? Можно интерлейсные файлы оставлять интерлейсными, на качестве воспроизведения это не скажется, если поля не перепутаны.
Тут важно еще вот что. Если исходные файлы NTSC, т.е. 29.97 кадров/сек, а на выходе PAL, то будут проблемы при воспроизведении.
В общем, здесь довольно много вопросов возникает. Если хотите разобраться с подвисаниями файлов, то, повторюсь, нам такие файлы нужны для анализа. По этому поводу лучше напишите письмо на forward@softlab.tv - там расскажут, что еще нужно прислать, помимо самих файлов. По остальным вопросам там тоже лучше расскажут, чем здесь, т.к. наверняка потребуется от Вас дополнительная информация, которую лучше прислать письмом.
-
- Сообщения: 80
- Зарегистрирован: 30 май 2006 19:51
- Откуда: Мурманск
-
- Сообщения: 493
- Зарегистрирован: 04 янв 2004 12:45
- Откуда: СофтЛаб-НСК
Очень НЕ рекомендую менять формат кадра без особой неоходимости. В том числе перекодировать в прогрессив исходно чересстрочное видео. При этом гарантированно теряется качество картинки и очень сильно. Это имеет смысл делать только для того, чтобы привести формат видео к выходному формату. Менять формат с 50P на 25P тоже не нужно.
То, что Вы отдаете IP ничего не меняет с точки зрения формата кадра. Главное, в каком формате (на каком устрйостве) смотрят Ваше видео зрители. Если это ТВ стандартного разрешения, то видео обязано быть чересстрочным. Если это показ только через интернет в окне браузера, то можно передавать и прогрессивоне видео. Либо это может быть формат 720P50 (1280х720 50 кадров в секунду, без полей). Соответственно, именно в таком формате и должна работать плата. Очевидно, что плата FD322 может работать только с сигналами ПАЛ или НТСЦ. Если Вы работаете, например, с ПАЛ, то можно кодировать в IP выход платы FD300. Иначе нужно создавать виртуальную плату нужного формата.
То, что Вы отдаете IP ничего не меняет с точки зрения формата кадра. Главное, в каком формате (на каком устрйостве) смотрят Ваше видео зрители. Если это ТВ стандартного разрешения, то видео обязано быть чересстрочным. Если это показ только через интернет в окне браузера, то можно передавать и прогрессивоне видео. Либо это может быть формат 720P50 (1280х720 50 кадров в секунду, без полей). Соответственно, именно в таком формате и должна работать плата. Очевидно, что плата FD322 может работать только с сигналами ПАЛ или НТСЦ. Если Вы работаете, например, с ПАЛ, то можно кодировать в IP выход платы FD300. Иначе нужно создавать виртуальную плату нужного формата.
-
- Сообщения: 80
- Зарегистрирован: 30 май 2006 19:51
- Откуда: Мурманск
ОК, понял вашу мысль. Сейчас уже сложно будет попробовать отловить, на каких именно файлах (от какого поставщика) были затыки про воспроизведении MPEG-2, т.к. всё перевожу в MPEG-4, рисковать эфиром совсем не интересно.
Попутно, чтоб не плодить лишних веток, такой вопрос. При кодировании IPOut/AVC возникает задержка в 3,5 сек примерно. Далее возникает задержка при передаче потока в Москву и распределении до операторов (примерно 30 сек). Кто как борется с этим делом?
Самое простое - выстраивать расписание с учетом на эту задержку (в среднем запускать контент на 30-35 сек раньше, чем реальное время). Может есть способ заставить опорные (системные) часы идти с отклонением в -35 сек постоянно? Сейчас синхронизируюсь в "ноль" по Интернете (не средствами Windows). Может есть у кого наработки по этому вопросу?
Попутно, чтоб не плодить лишних веток, такой вопрос. При кодировании IPOut/AVC возникает задержка в 3,5 сек примерно. Далее возникает задержка при передаче потока в Москву и распределении до операторов (примерно 30 сек). Кто как борется с этим делом?
Самое простое - выстраивать расписание с учетом на эту задержку (в среднем запускать контент на 30-35 сек раньше, чем реальное время). Может есть способ заставить опорные (системные) часы идти с отклонением в -35 сек постоянно? Сейчас синхронизируюсь в "ноль" по Интернете (не средствами Windows). Может есть у кого наработки по этому вопросу?
-
- Сообщения: 2311
- Зарегистрирован: 05 мар 2003 19:21
А как конечные зрители узнают, что вообще была какая-то задержка? Особенно при вещании файлов с диска в расписании, а не проходящего видео?
Что такое "реальное время"? Откуда оно берется? Вы знаете, что какой-то файл должен выйти в эфир, допустим, в 12:00, и хотите, чтобы на другом конце зритель увидел его начало в это же время? А зачем?Самое простое - выстраивать расписание с учетом на эту задержку (в среднем запускать контент на 30-35 сек раньше, чем реальное время).
-
- Сообщения: 80
- Зарегистрирован: 30 май 2006 19:51
- Откуда: Мурманск
Например, Новости должны выйти в 12:00 или сериал начало в 16:00. Многие IPTV операторы берут программу передачи и публикуют её сопутствующим сервисом на STB. Вечерний прайм кино в 21:00. 30 сек конечно не критично для кино и сериала, нро для новостей ... как-то не очень гуд. )
Реальное время в данном случае - это синхронизированное через Интернет время от NTP-серверов для моего часового пояса.
Реальное время в данном случае - это синхронизированное через Интернет время от NTP-серверов для моего часового пояса.
-
- Сообщения: 2311
- Зарегистрирован: 05 мар 2003 19:21
Я извиняюсь, если вопрос дурацкий: хоть раз в жизни слышали от кого-нибудь жалобу на то, что он в момент запуска новостей проверял время старта с секундомером и обнаружил, что они стартовали на полминуты позже положенного по программе телепередач? Даже если захочется по компьютерным часам что-то проверить, они обычно секунды не показывают, и синхронизованы зачастую непонятно к чему.
А если серьезно, то предусмотреть и просчитать все задержки в цифровом ТВ вряд ли возможно. А также гарантировать то, что через полгода не изменится маршрут прохождения потока, и задержка не станет другой.
Я вспоминаю, как дома смотрел открытие олимпиады в Сочи. Обнаружил две трансляции: одна на сайте 1tv.ru, другая в youtube. Было видно, что между ними задержка секунд 15 - более чем заметно. И событие, вроде, не рядовое для нашей страны. Тем не менее, не слышал про упоминания в сети про этот факт.
А если серьезно, то предусмотреть и просчитать все задержки в цифровом ТВ вряд ли возможно. А также гарантировать то, что через полгода не изменится маршрут прохождения потока, и задержка не станет другой.
Я вспоминаю, как дома смотрел открытие олимпиады в Сочи. Обнаружил две трансляции: одна на сайте 1tv.ru, другая в youtube. Было видно, что между ними задержка секунд 15 - более чем заметно. И событие, вроде, не рядовое для нашей страны. Тем не менее, не слышал про упоминания в сети про этот факт.
-
- Сообщения: 80
- Зарегистрирован: 30 май 2006 19:51
- Откуда: Мурманск