Стандарт SD канала для PAL, это 720х576 или 704х576, 25 кадров/сек, с пропорциями 4:3 или 16:9. Если цифры другие, значит, не правильно работает видео рендер, либо такой поставщик каналов.

Размер кадра у 16:9 каналов тоже 720х576. У европейского PAL по стандарту 576 горизонтальных строк, все, другого не дано. Если делать скриншот 16:9 канала в программе просмотра, то скриншот получается 1024х576, если скринить 4:3 канал, получаем скрин 768х576. Грамотно пояснить это я не берусь, но примерно понимаю, почему так, тут все зависит от видео рендера, он подгоняет ширину кадра (а не высоту!), чтобы картинка потом пропорционально, по всем четырем сторонам, растянулась без искажения геометрии.

Народ, но в инете все же есть, что такое стандрат SDTV и, что такое такое европейский стандарт PAL, не надо брать цифры с потолка.


Вам на скринить в ProgDVB 4:3 и 16:9 SD каналов со спутника, чтобы вы убедились, что ProgDVB скринить умеет, что скриншот 16:9 канала получается 1024х576 при реальном размере кадра 720х576?

704х576 4:3 - скрин 768х576
720х576 4:3 - скрин 768х576
720х576 16:9 - скрин 1024х576

Для h.264 список допустимых аспектов гораздо шире, чем для MPEG-2. У нас DVB-T/T2 каналы вещаются в h.264 со стандартными для этого кодека аспектами 20:11 и 15:11.

Я впервые вижу такие странные, необычные аспекты, особенно для телевиденья. Это же для каких таких экранов/телевизоров/мониторов такие пропорции? Аспект не зависит от размера кадра и наоборот, у кадра 720х576 может 4:3 аспект, так и 100:1, да какой угодно. Размер кадра SD PAL канала по стандарту 720х576/704х576, по такому стандарту и вещают телестудии каналов. Все, что выше 720х576, это какая-та ересь, проще говоря, аскейп, для каких это целей делается, мне не понятно.

У нас на Украине тоже T2 в H.264, довелось пощупать поток, благо все стандарты соблюдены, ни каких аскейпов и странных пропорций. Вот сейчас со спутника смотрю SD H.264 канал - 720х576 16:9 и 4:3.

Запишите, желательно в TS (хочу пощупать "сырой" поток) файл, плиз, канал 15:11 800х576 и 20:11 1056х576, интересно просто глянуть на это чудо в перьях.

А выше никто и не делает.

H.264/AVC MP@L3.0 720x576, 50i, 20:11
H.264/AVC MP@L3.0 720x576, 50i, 15:11

Фрагмент транспортного потока: http://rusfolder.com/38265115

Ну такие аспеткы просто не свойственны для телевиденья, есть телевизоры (не мониторы) 4:3 и 16:9, других просто не встречал. Все равно пропорции картинки 15:11 и 20:11 будут вписываться в пропорции физического 4:3 и 16:9 экрана (15:11->4:3 и 20:11->16:9), что повлияет на геометрию картинки, например, все будет вытянуто по высоте. Не правильно это как-то, не правильно.

Скажите, BeholdTV умеет писать DVB поток, как транспортный поток, в TS файл? Поток пишется, как есть или его что-то кодит, какой-то энкодер? Меня просто распирает глянуть кусочек записанного транспортного DVB потока с характеристиками 720x576 15:11 и 720x576 20:11, особенно хочется глянуть на лица людей в кадре.

SDTV
PAL
DVB-T2

Никакая телестудия в мире не будет вещать свой контент с аспектом картинки 15:11 и 20:11, а вот какой-то провайдер уже все что угодно может сделать с картинкой, вплоть до того, что подать ее с экзотическим или просто выдуманным аспектом.

Что-то и гугл молчит по поводу аспектов 15:11 и 20:11.

ALF

Вы записали что ли весь мультиплекс (или как это называется?) в один файл (контейнер)? Надо было записать только один/два канал/а. Я изучил все 10 видео потоков при помощи MediaInfo, на некоторых каналах аспект 4:3, на некоторых 16:9, ни какими 15:11 и 20:11 и не пахнет, и не будет пахнуть. Показываю инфо для "Первый канал" (Video #1) и "Россия 1" (Video #2):

Все стандартно, как для SDTV PAL. И забыл сказать, что нет разницы, чем пожат поток/видео.

В обычном режиме MediaInfo округляет аспекты до привычных всем 16:9 и 4:3.
Включите расширенный режим (Debug->Advanced mode) и среди всего прочего в списке параметров потока появится:


, где 1.818 и 1.364 - это уже точные значения аспектов, т.е. 20:11 и 15:11 с точностью до третьего знака после запятой.

Согласен, но dvbviewer так и скринит, я думаю что это правильно.


А вот это неправильно, бехолдер у меня аналог скринит в 720х576, никаких 768х576, с этим порядок, а вот цифровые каналы почему-то 800х576 - на скринах соответственно получаются растянутые рожи. И возможно это именно из-за черных полос сверху и внизу, которые есть только в бехолдере. И неясен вопрос с 1024 (1056 в моем случае), откуда этот апскейл?


А каким образом прогдвб умеет скринить? В вкладках просто такого не нашел, какие-нибудь сочетания клавиш?

Правильно так и так. У каждой программы по-своему, кто скринит реальный размер кадра, а кто-то скринит размер кадра, который выводит видео рендер, у каждой программы бывает свой видео рендер или системный. Тут спорный вопрос, как надо скринить, скринить реальный размер кадра или скринить размер кадра, который вывел видео рендер, потому что видео рендер выводит картинку уже с адаптированной пропорцией.


Да правильно все тут, правильно. Почему Бехолдер скринит 720х576, я пояснить не могу, но будьте уверены, что на экране мы видим картинку, которая предварительно была растянута видео рендером до 768х576, почему так, я пояснил ниже.


И тут полный порядок. Видео рендер растягивает ширину, чтобы адаптировать картинку к соотношению 4:3. Если смотреть телевизионный кадр 720х576 в оригинале, то, если я не ошибаюсь, это 5:4, по бокам будут черные поля. На телевизоре мы всегда смотрим слегка растянутую картинку по ширине, это делает телевизор, а в нашем случае, это видео рендер, картинка растягивается по ширине до 768 точек, чтобы в итоге получилась пропорция 4:3. Посчитайте сами: 576 (высоту) делим на 3 и умножаем на 4, получим 768 (ширину). Телевизионнный кадр 720х576 это изначально 5:4.


Это аналогичный случай, что описан выше. Телевизор, в нашем случае видео рендер, пытается адаптировать размер кадра 720х576 под аспект 16:9 путем растягивания картинки по ширине до 1024 точек, чтобы кадр стал с правильными пропорциями, в нашем слуе это 16:9. Снова считаем: 576 (высоту) делим на 9 и умножаем на 16, получаем 1024 (ширину).

Забыл упомянуть, что вся эта чехарда тесно связана с квадратными и не квадратным пикселями (Pixel Aspect Ratio).

Формат 4х3 это 720х576 или 768х576?
Соотношение сторон (Aspect Ratio) и разрешение кадра
Квадратные и неквадратные пикселы (хорошая статья, жалко, что на английском)
О "квадратных" пикселах, аспекте 5:4 и 4:3.
Квадратные пикселы

Вышеуказанные ссылки хорошо поясняют, почему 720 растягивается до 768. так что все правильно, читаем и вникаем.


А вот это уже точно не правильно. То есть при просмотре вы видите черные поля сверху и снизу, а скриншот получается 800х576 ? Если так, что видео рендер выводит картинку с не правильной пропорцией (это подтверждает скриншот), потом все это дело пытается влезть в 4:3 экран/область, из-за чего появляется черные поля сверху и снизу, если бы не было этих полей, вы бы смотрели вытянутые рожи (как на скрине). Почему такое поведение, мне бы тоже хотелось услышать ответ от разработчиков. Я такую "красоту" не хотел бы у себя видеть.

Запомните еще раз, сркиншот, это результат того, что показал видео рендер, такой метод скринования, на мой взгляд, является правильным, нежели реальный размер кадра, но это спорный вопрос. Если ваш скрин получается не правильного размера (геометрия/пропорция), согласно размера кадра, это означает, что видео рендер выводит не правильную пропорцию кадра, что-то ему сообщает не правильный аспект.


Файл - Сделать снимок, или F12.

boss911
Открываем документацию ISO/IEC 14496-10 (H.264/AVC), ищем описание aspect_ratio_idc.

Первый канал кодирует:
aspect_ratio_idc = Extended_SAR (0xFF)
sar_width = 11520
sar_height = 6336
Наименьший общий делитель (GCD) = 576, итого аспект 20:11.

Канал 5 (Петербург) кодирует:
aspect_ratio_idc = Extended_SAR (0xFF)
sar_width = 8640
sar_height = 6336
Наименьший общий делитель (GCD) = 576, итого аспект 15:11.

Это все также прекрасно видно на выходном пине декодера. Рендерер отрисовывает именно такой аспект. Никто сам тут ничего не выдумывает. Так что задавайте вопросы головному узлу, который занимается кодированием каналов федерального пакета.

Также вы удивитесь, когда увидите в таблице
"Table E-1 – Meaning of sample aspect ratio indicator"
отсутствие 16:9 как такового. Это фиксированная таблица SAR, когда aspect_ratio_idc != Extended_SAR.

Кстати а почему нет действия на видеоокне LClick+Колесо?
Вроде же комбинация ни с чем не конфликтует… Но не реализовали…
А хотелось бы например зум кадра на неё вешать.

И вообще обращаю внимание разработчиков что для мышей в винде уже много лет стандартизировано 5 кнопок, а не 3. VK_XBUTTON1, MK_XBUTTON1 и т.п.
Можно какие-нибудь действия сделать на доп.кнопка+колесо. Вместо Ctrl+колесо.

BTVSoft

Мда уж, как много я не знаю и не понимаю, точнее каша в голове от этого всего (SAR, DAR, PAR и в придачу еще GCD нарисовался).

Хорошо, тогда поясните мне такое. Я взял выложенный тут транспортный поток из DVB-T2, прогнал его через TS Reader в ProgDVB, таким образом, я с эмулировал у себя (российские) DVB-T2 каналы. При просмотре канала (все H.264/AVC), размер кадра определяется как 720х576, 4:3/16:9 (в зависимости от канала). Тут жаловались, что в BeholdTV при просмотре есть черные полосы сверху и снизу, это из-за специфических аспектов 15:11/20:11 ? Тогда почему в ProfDVB (выше и DVBViewer упоминался) картинка выводится на всю область экрана/окна, ни каких черных полей, как для 4:3, так и для 16:9 ?

Попробовал сделать скриншот 4:3 и 16:9 канала (я их так называю), получил размеры 792х576 и 1048х576, соответственно. Вот тут я и крепко удивился, впервые с таким сталкиваюсь, ибо неоднократно скринил SD H.264/AVC каналы со спутника и украинского DVB-T (второй версии тогда еще не было), получал 768х576/1024х576 (аналогично с MPEG2).

И снова не понятка. Тут говорилось, что BeholdTV делает скриншоты этих каналов с размером 800х576/1056х576, а в ProgDVB 792х576/1048х576, из-за чего эта разница в 8 пикселей? Или это разное поведение видео рендера (у меня VMR-9 Renderless), тогда кто прав? Подключил математику:

Мне кажется, да и математика подтверждает, что 792х576/1048х576 больше соответствует 15:11/20:11, нежели 800х576/1056х576. Или я не правильно считаю?

Если говорить о кадре 720х576 с аспектом 15:11, то 792 и 800 это производные от 785.45 значения, округлённые в большую сторону до кратности 8 и 16. То же самое и для аспекта 20:11. Округление осуществляется связкой декодер/рендерер и зависит от программно/аппаратных особенностей видеосистемы.

Support, так будут ли устранены растягивание скринов цифры до 800х576 и черные полосы при просмотре? Общий скрин, сверху аналог, на нижнем присутствуют как раз те полосы