|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
11-Май-13 19:57
(12 лет 6 месяцев назад)
Xpюша писал(а):
59249369Если кодировались полями - RFF выставлять нельзя и pulldown поэтому невозможен! Ну и как при этом в CCE кодировать в NTSC с установками по умолчанию?
В чем проблема-то, из-за чего беспокойство? Казалось бы, простые, стандартные вещи.
|
|
|
|
Mikky72
Стаж: 18 лет 7 месяцев Сообщений: 8498
|
Mikky72 ·
11-Май-13 21:54
(спустя 1 час 57 мин., ред. 11-Май-13 21:54)
tartak
Просто Хрюша писал, что если делать в NTSC софт-телесин (прогрессивно-закодированные кадры + флаги пуллдауна), то DVD-плеер (в отличие от софтового декодирования через DGIndex с Honor pulldown flags, при котором спокойно генерируются смешанные кадры с гребенкой) не сможет сгенерировать "смешанные кадры" (так как "буфера не хватит") из полей соседних (я так и не очень в это поверил), а будет всегда вставлять исключительно полные копии предыдущих кадров, из-за чего на телевизоре будет неприятно "спотыкающаяся" картинка. А значит надо кодировать NTSC полями (интерлейсно) + флаги. А теперь выяснил, что если кадры закодированы полями, то невозможно вставить флаг RFF, а значит софт-телесин невозможен и, получается, что при кодировании полями (например TFF) CCE будет делать хард-телесин, вставляя реальные дополнительные "смешанные кадры" (а хард-телесин - это неэкономное использование битрейта)...
Я то (не имея DVD-плеера) чисто умозрительно считаю, что при софт-телесине DVD-плеер таки сумеет сам сделать "смешанные" кадры для вывода 29,97 (предполагается, что ни плеер, ни телевизор 24p не поддерживают) и картинка на телевизоре так дергаться не будет. Вам как жителю NTSC региона ответ на этот вопрос, вероятно, известен...
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
11-Май-13 22:29
(спустя 34 мин., ред. 11-Май-13 22:29)
Многие решения в MPEG2 и DVD были приняты из желания минимизировать необходимые аппаратные ресурсы (как производительность микросхем, так и объём необходимой памяти, причём борьба шла буквально за байты).
В частности, я считал, что декодер оперирует тремя буферами для декодированных кадров: двумя для опорных кадров (I- и P-) и одним для текущего кадра.
Если поток NTSC закодирован полями - для pulldown этого хватает: пока повторно выводится, скажем, нижнее поле первого B-кадра (из двух), в другую половину буфера декодируется верхнее поле следующего B-кадра, которое и будет выводиться следом за тем нижним.
Но если поток закодирован кадрами, то в той же ситуации при повторном выводе нижнего поля одного кадра - следующий кадр декодировать просто некуда, буфер ещё занят. А когда поле выведено и пора выводить поле следующего кадра - на декодирование просто не остаётся времени.
Ситуацию можно было бы разрулить, используя не более одного B-кадра подряд, но такого ограничения в NTSC нет.
Получается, что создатели стандарта таки раскошелились на второй буфер. Совершенно непонятно зачем.
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
12-Май-13 03:59
(спустя 5 часов)
Знаете, я и сам изредка заморачиваюсь абстрактными вещами, но чтобы настолько? Думать об абстрактных буферах и о том, как оно было, когда еще ничего не было - увольте. Достоверно известно, что был доисторический период, когда телесин реально означал хард телесин. Но уже очень много лет как разумно работающие плееры вообще перестали обращать на флаги. Иначе они просто не пройдут стандартный набор тестов.
Объясните, в чем может быть хоть какая-нибудь польза от размышлений на эту тему, и мы ей займемся.
|
|
|
|
Mikky72
Стаж: 18 лет 7 месяцев Сообщений: 8498
|
Mikky72 ·
12-Май-13 06:34
(спустя 2 часа 35 мин., ред. 12-Май-13 06:34)
tartak
Ну, сами по себе эти "буферы" мало интересны. Больше интересует, какой же вид телесина получается, если, например, выбирать в Carbon Coder в разделе Target настройки "For DVD" (а значит жестко зафиксированное Interlaced) + TFF + "23,976->29,97(3:2 pulldown)" (вроде бы как раз получается софттелесин). Т.е. как же можно получить софттелесин, если в случае интерлейсно закодированных кадров нельзя ставить флаг RFF?
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
12-Май-13 09:20
(спустя 2 часа 46 мин.)
Mikky72
Логично предположить, что кодер по заданному "23.976 + пуллдаун" игнорирует прочие установки и вместе с требуемыми в кадрах TFF/RFF форсирует флаги, при которых стандартный пуллдаун возможен:
progressive_sequence=0
progressive_frame=1
Если он поступит иначе, то ему придется обмануть пользователя, задавшего частоту кадров 23.976 при шаблоне DVD.
То, что действие RFF запрещено при progressive_frame=0 (+ progressive_sequence=0) логично тем, что если видео и по содержанию чересстрочное, повторение первого поля с целью растяжки бесполезно. Это нарушит последовательность фаз движения: если при прогрессивном видео одна и та же фаза длится 3 поля, то здесь повторённое поле соответствует моменту, предшествующему фазе ранее выводимого второго поля кадра.
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
12-Май-13 09:54
(спустя 34 мин., ред. 12-Май-13 10:32)
Areyou писал(а):
59260827если видео и по содержанию чересстрочное, повторение первого поля с целью растяжки бесполезно
Но такое видео (с телекамеры) растяжки и не требует - оно уже снято с нужной частотой кадров.
А закодированное полями прогрессивное видео растягивать можно было бы безнаказанно.
Areyou писал(а):
59260827То, что действие RFF запрещено при progressive_frame=0 (+ progressive_sequence=0) логично тем
Ограничение-то можно было поставить именно по признаку "кадры прогрессивные - чересстрочные" (флаг "progressive_frame"). Но поставили почему-то по признаку "кодирование полями - кадрами" (флаг "picture_structure").
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
12-Май-13 10:17
(спустя 22 мин.)
Естественным образом, реальность будет такова: progressive_sequence = 0 (или не выставлен вообще, не помню), picture_structure = frame (всегда так на реальном dvd), progressive_frame = 1. Будут выставлены t_f_f и r_f_f в последовательности, полагающейся для 3:2. Софт телесин. Нормальный плеер (в отличие от флагового) будет игнорировать t_f_f и r_f_f; вместо флагов он будет смотреть на саму каденцию, то есть на материал.
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
12-Май-13 11:04
(спустя 46 мин., ред. 12-Май-13 11:04)
Xpюша писал(а):
59261151Но такое видео (с телекамеры) растяжки и не требует
Такая потребность существует при переводе паловских ТВ записей в NTSC, хотя прямой вставкой повторных полей этого и не сделать. Нечто похожее (с сохранением всех имеющихся фаз движения и повторением некоторых фаз в виде полей - но не тех "первых", а через боб-деинтерлейс и пересборку кадров), иногда делается на промышленных дисках. Из того, что попадалось на трекере - промо-DVD Fogerty 'Revival' (там таким способом переведён фрагмент фестиваля Glastonbury, снимавшегося BBC). В отличие от более накатанных вариантов с блендами (BD Dire Straits Alchemy, BD Amy Winehouse и др. NTSC из PAL ТВ источников), которые разбираются только в прогрессив, из такого варианта восстанавливаются все поля PAL (не считая потерь 25 - > 24.75).
Xpюша писал(а):
59261151Ограничение-то можно было поставить именно по признаку "кадры прогрессивные - чересстрочные" (флаг "progressive_frame").
Так и сделано (формально флаг существует, но обязан быть или читаться 0):
If progressive_sequence is equal to 0 and progressive_frame is equal to 0, repeat_first_field shall be zero, and the output of the decoding process corresponding to this reconstructed frame consists of two fields.
При кодировании полями (field_picture) просто нет понятия "поля, выводимого из кадра (как единицы хранения) первым", поэтому нельзя и повторить "первое" в том же смысле поле. Да и этот вариант крайне редкий (один только диск видел). Это по чисто формальной структуре (безотносительно порядка обхода блоков в кодере и пр.)
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
12-Май-13 11:06
(спустя 2 мин.)
Xpюша
Каденция есть всегда. Она на выходе декодера, который просто следует флагам (и стоит копейку). Все остальное, в том числе и телесин, делает деинтерлейсер (вещь дорогая, если работает хорошо). На реальном диске, каденция часто сбита, флаги неверны, а значит на выходе декодера мы уже не имеем воссозданных прогрессивных кадров. Этим займется деинтерлейсер - в случае прогрессивного источника (не того, что пошел в кодирование, а то, как оно было изначально снято) его задача перетасовать поля на выходе декодера правильным образом (касательное отношение к деинтерлейсу, что часто вводит в заблуждение) - в том числе и понять, что он имеет дело с фильмом.
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
12-Май-13 11:23
(спустя 17 мин., ред. 12-Май-13 11:24)
Areyou писал(а):
59261716При кодировании полями (field_picture) просто нет понятия "поля, выводимого из кадра (как единицы хранения) первым"
Как это "нет"? А значения поля "picture_structure" TFF и BFF что указывают?
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
12-Май-13 12:05
(спустя 42 мин., ред. 12-Май-13 12:05)
Xpюша
Да, действительно, формально флаг RFF есть, но тоже не влияет
( in a field picture it shall be set to zero and does not
affect the decoding process.)
Как и флаг TFF, кстати:
In a field picture top_field_first shall have the value ‘0’, and the only field output by the decoding process is the decoded field picture.
Xpюша писал(а):
59262229А значения поля "picture_structure" TFF и BFF что указывают?
Для одинокого поля - верхнее оно геометрически или нижнее (порядок следования - по факту).
01=field_picture (top field)
10=field_picture (bottom field)
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
12-Май-13 14:39
(спустя 2 часа 34 мин., ред. 12-Май-13 14:39)
Areyou писал(а):
59262309Да, действительно, формально флаг RFF есть, но тоже не влияет
[...]
Как и флаг TFF, кстати:
Но я же не о них, а о "picture_structure":
Areyou писал(а):
59262309Для одинокого поля - верхнее оно геометрически или нижнее (порядок следования - по факту).
01=field_picture (top field)
10=field_picture (bottom field)
- вот эти значения и именуют обычно "TFF" и "BFF". А отдельный флаг "top_field_first" именуют либо полностью, либо (как tartak) "t_f_f".
И в моём представлении (пока сейчас не начали копать) структура потока NTSC с pulldown была такой: кадры "progressive_frame = 1" закодированы полями и идут примерно в следующей последовательности: {TFF}{TFF+RFF}{BFF}{BFF+RFF}{TFF}{TFF+RFF}... Это логично и очень удобно для декодирования с минимальными аппаратными затратами.
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
12-Май-13 18:59
(спустя 4 часа)
Xpюша писал(а):
59262229Как это "нет"? А значения поля "picture_structure" TFF и BFF что указывают?
Опять не имеет отношения к теме. Что они указывают, следует прямо из смысла слов. Но мы же DVD тут занимаемся, а на DVD этих значений вы не увидите:
tartak писал(а):
59261427picture_structure = frame (всегда так на реальном dvd)
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
12-Май-13 20:22
(спустя 1 час 23 мин., ред. 12-Май-13 20:23)
tartak писал(а):
59268861Опять не имеет отношения к теме.
Смотря к какой. Это же был ответ на вполне конкретные слова.
tartak писал(а):
59268861Но мы же DVD тут занимаемся, а на DVD этих значений вы не увидите:
tartak писал(а):
picture_structure = frame (всегда так на реальном dvd)
Только если речь об NTSC с pulldown. Потому как в других случаях - видел, и не раз.
Касательно же "NTSC с pulldown" - сказано было:
Xpюша писал(а):
59264993в моём представлении (пока сейчас не начали копать) структура потока ... была такой
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
12-Май-13 20:59
(спустя 37 мин.)
Xpюша писал(а):
59264993- вот эти значения и именуют обычно "TFF" и "BFF"
В таблице-справке по полю 'picture_structure' TFF или BFF не упоминаются (поле флага TFF имеет 1 бит, здесь - два бита и смысл другой). TFF отдельно прописывается для любого варианта picture_structure, но реальный смысл имеет только для третьего возможного её значения (=11) - frame picture*, который, как уже не раз сегодня упоминали, почти исключительно для DVD и применяется. Progressive_frame=0 или 1 - всё это имеет место в рамках кодирования последовательностью кадров (frame picture). В случае полей (field picture) кодированное изображение необходимо опознавать как верхнее, либо как нижнее поле - они не приписаны конкретному кадру. Отсюда два разных значения picture_structure (01 для верхнего и 10 для нижнего). Кстати, и кодер mpeg2 с возможностью организовать field picture ещё поискать нужно.
* ещё раз процитирую о флаге TFF из H.262 (1995E, c. 52):
скрытый текст
In a field picture top_field_first shall have the value ‘0’, and the only field output by the decoding process is the decoded field picture.
In a frame picture top_field_first being set to ‘1’ indicates that the top field of the reconstructed frame is the first field output by the decoding process. top_field_first being set to ‘0’ indicates that the bottom field of the reconstructed frame is the first field output by decoding process.
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
12-Май-13 22:28
(спустя 1 час 28 мин., ред. 12-Май-13 23:22)
Areyou писал(а):
59270771В таблице-справке по полю 'picture_structure' TFF или BFF не упоминаются
Почти. В стандарте (который на прошлой странице уже цитировался) значения называются:
Цитата:
00 Reserved
01 Top Field
10 Bottom Field
11 Frame picture
Но смысл-то у "Top Field" и "Bottom Field" именно этот - указывают, какое поле в потоке лежит первым. И во многих программах (в том числе и кодировщике, которым я чаще всего пользуюсь), для них используются абревиатуры "TFF"/"BFF" (а то и полностью: "Top Field First" / "Bottom Field First").
Areyou писал(а):
59270771только для третьего возможного её значения (=11) - frame picture*, который, как уже не раз сегодня упоминали, почти исключительно для DVD и применяется.
В случае PAL - отнюдь. Кодируют как угодно, благо разницы при просмотре нет.
Areyou писал(а):
59270771Кстати, и кодер mpeg2 с возможностью организовать field picture ещё поискать нужно.
Я пользуюсь "инженерным вариантом" Mainconcept encoder, встроенным в EditStudio 6 - там это без труда (в основных параметров сжатия присутствует).
Причём по умолчанию стоит "TFF", и на "Frame" нужно переставлять руками.
А Mainconcept encoder (причём в гораздо менее управляемом варианте) встроен почти во все полу- и профессиональные видеоредакторы.
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
12-Май-13 23:47
(спустя 1 час 19 мин.)
Xpюша писал(а):
59272173значения называются:
Цитата:
00 Reserved
01 Top Field
10 Bottom Field
11 Frame picture
Здесь просто определены три варианта структуры изображения (picture_structure):
frame picture и два варианта field picture (верхнее или нижнее поле). Нет упоминания о "первом" (first), поскольку при field picture последовательность полей в потоке однозначно определена напр. временным кодом, а вот "высотность" отвязанного от кадра поля (top/bottom) метить приходится, иначе при воспроизведении кадр правильно не составить. Т.е. буквальный смысл здесь записанного "то, что поступило на декодер в данный момент - его верхним показывать или нижним?" С флагом TFF эти параметры не связаны, он есть в другом поле, а в случаях, не относящихся к frame picture (11), игнорируется (формально, и обнуляться должен). Я ничего не имею против field picture, но не прижилось это, видел только на диске: https://rutr.life/forum/viewtopic.php?t=2409738
(если в DGIndex просмотреть, в поле Frame structure 'Fields', на прочих дисках - 'Frame')
Xpюша писал(а):
59272173В случае PAL - отнюдь. Кодируют как угодно, благо разницы при просмотре нет.
Строго говоря, "Progressive_frame = 1" можно использовать и "picture_structure != frame picture". Стандарт такое сочетание не рекомендует, но и не запрещает.
Вы случаем не отождествляете вариант field picture с чересстрочной кодировкой?
Для неё вариант field picture не требуется, поскольку
When progressive_sequence is set to ‘0’ the coded video sequence may contain both frame-pictures and field-pictures, and frame-picture may be progressive or interlaced frames.
Кодировать прогрессивное видео как чересстрочное (безотносительно временных структур, о которых сейчас речь), разумеется, можно, но это чуть хуже, как и при многих видах редактирования разделённых полей (если что-то пространственно меняется, то через строку), хотя разница заметна разве что на стоп-кадрах.
|
|
|
|
Mikky72
Стаж: 18 лет 7 месяцев Сообщений: 8498
|
Mikky72 ·
13-Май-13 01:14
(спустя 1 час 27 мин., ред. 13-Май-13 01:14)
Areyou писал(а):
59273301кодировать прогрессивное видео как чересстрочное... можно
Вот об этом то и речь... "можно" с намеком на "не нужно". А вот создатели СС и ССЕ, похоже придерживаются альтернативного подхода - "нужно для DVD" и как раз таки запрятывают варианты прогрессивного кодирования как можно тщательней - при этом софтины позиционируются явно не "для чайников", от которых надо всё прятать. А вопрос остается открытым:
[*]1) Как в ССЕ однозначно настроить именно вариант кодирования (frame type) прогрессивного видео?
[*]2) Какой из этих вариантов кодирования (полными кадрами и полями) лучше подходит для софт-телесин?
[*]3) Если там как-то можно однозначно обеспечить гарантированное прогрессивное кодирование (frame type = progressive) прогрессивного видео (frame struct = frame), то надо ли его описывать и настоятельно рекомендовать в инструкции по получению видеодорожки для DVD (NTSC, PAL)?
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
13-Май-13 04:39
(спустя 3 часа, ред. 13-Май-13 04:39)
Xpюша писал(а):
59270165
tartak писал(а):
59268861Но мы же DVD тут занимаемся, а на DVD этих значений вы не увидите:
tartak писал(а):
picture_structure = frame (всегда так на реальном dvd)
Только если речь об NTSC с pulldown. Потому как в других случаях - видел, и не раз.
Я нисколько не сомневаюсь, что видели. Стандарт это в принципе допускает. Поэтому вполне можно представить, что кто-нибудь сварганит такое дома. Или даже "студия" (с пропиской на кухне ее президента) сделает. Не увидите на реальном DVD, выпущенном реальной студией. Просто по той причине, что там для тестирования стоит стена плееров кучи марок и годов, которые все должны этот DVD играть нормально. И скорей всего там найдется достаточно старый, который ничего, кроме picture_structure = frame, играть не будет. А посему ничего другого никогда реально и не выпускалось. Если у меня и есть 1% сомнения на этот счет, так разве что для "супербит". Где-то у меня был такой диск, один на несколько тысяч, можно глянуть на нем флаги.
Areyou писал(а):
59270771В таблице-справке по полю 'picture_structure' TFF или BFF не упоминаются
Совершенно верно. Там есть TF и BF, а это не то, что TFF/BFF. Но людей смущает, например:
Xpюша писал(а):
59272173Но смысл-то у "Top Field" и "Bottom Field" именно этот - указывают, какое поле в потоке лежит первым.
Нет у них такого смысла. Они значат только то, что написано - каким именно является данное поле.
Areyou писал(а):
59273301Вы случаем не отождествляете вариант field picture с чересстрочной кодировкой?
Да, у меня тоже такое впечатление: недоразумения на последних 2-х страницах связаны именно с таким отождествлением.
Mikky72 писал(а):
59273742А вот создатели СС и ССЕ, похоже придерживаются альтернативного подхода - "нужно для DVD" и как раз таки запрятывают варианты прогрессивного кодирования как можно тщательней
Нет, все это на самом виду. Просто некритическое использование одного и того же слова "прогрессивный" для самых разных вещей приводит к недоразумениям.
Mikky72 писал(а):
592737421) Как в ССЕ однозначно настроить именно вариант кодирования (frame type) прогрессивного видео?
2) Какой из этих вариантов кодирования (полными кадрами и полями) лучше подходит для софт-телесин?
3) Если там как-то можно однозначно обеспечить гарантированное прогрессивное кодирование (frame type = progressive) прогрессивного видео (frame struct = frame), то надо ли его описывать и настоятельно рекомендовать в инструкции по получению видеодорожки для DVD (NTSC, PAL)?
1) Никак. Всегда будет picture_structure = frame. Карбон по-моему позволяет и поле (но только не для телесина, конечно), но это крайне не рекомендуется и никогда не используется для ДВД (реальных, см. выше)
2) Все эти вещи решаются ССЕ автоматом и правильно, как только вы задали сам факт телесина. Хранится кадром, с разделением на поля.
3) Самоцитирование:
tartak писал(а):
59261427Естественным образом, реальность будет такова: progressive_sequence = 0 (или не выставлен вообще, не помню), picture_structure = frame (всегда так на реальном dvd), progressive_frame = 1. Будут выставлены t_f_f и r_f_f в последовательности, полагающейся для 3:2. Софт телесин. Нормальный плеер (в отличие от флагового) будет игнорировать t_f_f и r_f_f; вместо флагов он будет смотреть на саму каденцию, то есть на материал.
Все это автоматом, без вариантов. Я не вижу, чтобы тип картинки в установках картинки как-то влиял на флаги. Хотя не сомневаюсь, что если выставить там "прогрессив" (или авто) для прогрессивного источника, то эффективность кодирования слегка увеличится.
Таким образом, все происходит автоматически и правильно, достаточно задать "пулдаун". Дискуссия эта - чисто академическая. Технология DVD-Video давно и полностью устоялась, и постепенно уходит в прошлое. Вот уже и хороший "чисто ДВД" плеер купить стало невозможно. Приходится блу-рей плеер покупать, даже если смотреть только ДВД.
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
13-Май-13 06:27
(спустя 1 час 48 мин., ред. 13-Май-13 06:44)
Areyou писал(а):
59273301Здесь просто определены три варианта структуры изображения (picture_structure):
frame picture и два варианта field picture (верхнее или нижнее поле).
То есть, "Top Field" в заголовке означает, что данный кадр (MPEG-овская структура) содержит только одно поле - верхнее? Но ведь это не так. Кадр всегда содержит полное (по высоте) изображение! Даже если поток чересстрочный (с телекамеры), то каждый кадр всё равно содержит два поля. А "picture_structure = top field (или bottom field)" в заголовке кадра сообщает, какое из полей идёт первым.
Areyou писал(а):
59273301Нет упоминания о "первом" (first), поскольку при field picture последовательность полей в потоке однозначно определена напр. временным кодом
Но у полей нет меток времени. Их даже у кадров нет. Метка времени одна на всю GOP.
Areyou писал(а):
59273301Вы случаем не отождествляете вариант field picture с чересстрочной кодировкой?
Можно сказать, что отождествляю. Потому что "field picture" - это кадр, закодированный полями. А такой способ кодирования и есть "череcстрочная кодировка". Вот чересcтрочная последовательность кадров - это да, совсем другое.
Areyou писал(а):
59273301frame-picture may be progressive or interlaced frames.
Ага. А немного в другом месте этот же стандарт кодировать interlaced frames как frame-picture настоятельно не рекомендует 
Areyou писал(а):
59273301Кодировать прогрессивное видео как чересстрочное (безотносительно временных структур, о которых сейчас речь), разумеется, можно, но это чуть хуже
Что я и писал несколько раз на предыдущей странице.
Mikky72 писал(а):
592737421) Как в ССЕ однозначно настроить именно вариант кодирования (frame type) прогрессивного видео?
До сих пор описанный мной метод не подводил.
Mikky72 писал(а):
592737422) Какой из этих вариантов кодирования (полными кадрами и полями) лучше подходит для софт-телесин?
Если верить стандарту MPEG2 - для этого разрешается использовать только кодирование кадрами.
tartak писал(а):
59274643И скорей всего там найдется достаточно старый, который ничего, кроме picture_structure = frame, играть не будет.
То есть, снятое телекамерой этот проигрыватель показать не способен?
tartak писал(а):
59274643
Xpюша писал(а):
Но смысл-то у "Top Field" и "Bottom Field" именно этот - указывают, какое поле в потоке лежит первым.
Нет у них такого смысла. Они значат только то, что написано - каким именно является данное поле.
А это ничего, что данная метка находится не в заголовке поля (у них нет заголовков), а в заголовке кадра (содержащего оба поля)?
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
13-Май-13 08:17
(спустя 1 час 49 мин., ред. 13-Май-13 08:17)
Xpюша писал(а):
59274907Но у полей нет меток времени. Их даже у кадров нет.
Это условно - в любом случае есть сила, заставляющая либо кадры (случай frame picture), либо поля (случай field picture) поступать на декодер в строго определённом порядке. В первом случае на выход поля поступают в очерёдности, заданной флагом TFF, во втором - в том порядке, в котором пришли на вход.
Xpюша писал(а):
59274907А это ничего, что данная метка находится не в заголовке поля (у них нет заголовков), а в заголовке кадра (содержащего оба поля)?
В случае field picture - в расширении picture coding extension (c.31) данного варианта picture, кадра (frame picture) в этой альтернативе нет. В этом смысле варианты frame picture и field picture равноправны и распознаются по тому самому полю picture_structure. При чересстрочном варианте frame picture (progressive_frame=0) поля не имеют собственного расширения.
Xpюша писал(а):
59274907То есть, "Top Field" в заголовке означает, что данный кадр (MPEG-овская структура) содержит только одно поле - верхнее?
Нет, это означает, что данное поле (field picture) принадлежит последовательности, не организованной в кадры, и при воспроизведении использовано оно может быть только как верхнее.
|
|
|
|
Лунный_кот
Стаж: 15 лет 2 месяца Сообщений: 173
|
Лунный_кот ·
13-Май-13 09:34
(спустя 1 час 17 мин., ред. 13-Май-13 09:34)
Так как получить-то frame-picture в прогрессиве? И где нужно снять или поставить "галку", чтобы получить тот самый желанный "no fiels", ибо в настройках CCE SP3 окно "Offset line" должно же стоять "0" или "1", а, значит, будут и поля? Получить чересстрочный-то прогрессив получилось по написанному...
tartak писал(а):
Технология DVD-Video давно и полностью устоялась, и постепенно уходит в прошлое..
Разброс населенных пунктов в России велик, окутать всё проводами коммуникаций (DSL или FTTP) тяжеловато - обычно пользуются беспроводной связью, что мобильно, но не дает высокой скорости передачи данных при использовании сети. На днях уеду в населенный пункт, где скорость приема сети составляет 7 кб в сек, при такой скорости скачивания обычный BD я качал бы там 10 лет - я уже прошлую поездку посчитал это. Там при слове "блу-рей" у местных жителей начинается историка - они никогда о нём там не слышали и уж тем более не видели. Но разговор ведется не о людях, а том, что DVD еще долго будут - я лично кодирую что-то для себя как раз из BD в DVD-9 и при выборе смотреть DVD-9-castom (из BD-диска) или BD-диск (resize из DVD) выбираю первый вариант, и он далеко не худший, ибо звук на BD есть и в LPCM вот такого качества...
... да и не всегда в лицензии он переваливает планку в АС3 640 кб/сек.
tartak писал(а):
Вот уже и хороший "чисто ДВД" плеер купить стало невозможно. .
Как и BD достойного качества - наличие этого трекера тому подтверждение.
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
13-Май-13 09:44
(спустя 9 мин., ред. 13-Май-13 09:44)
Xpюша писал(а):
59274907
tartak писал(а):
59274643И скорей всего там найдется достаточно старый, который ничего, кроме picture_structure = frame, играть не будет.
То есть, снятое телекамерой этот проигрыватель показать не способен?
Разумеется способен. И уже стало совершенно ясно, что вы отождествляете picture_structure = frame с прогрессивом, а соответственно picture_structure <> frame с интерлейсом. И мы никуда дальше не продвинемся, пока вы не примете простую истину: на реальных DVD, picture_structure = frame всегда. Это не имеет никакого отношения ни к интерлейсу, ни к прогрессиву. И фраза
Xpюша писал(а):
59274907Можно сказать, что отождествляю. Потому что "field picture" - это кадр, закодированный полями. А такой способ кодирования и есть "череcстрочная кодировка". Вот чересcтрочная последовательность кадров - это да, совсем другое.
просто не несет смысла, вообще никакого. Не обижайтесь, право. Понять, что стандарт имеет в виду, на основе всего лишь того, как слова звучат, просто невозможно. Посмотрите на поток на реальных DVD, на флаги. Почитайте пояснения к стандарту, а главное пояснения к практике создания и тестирования DVD, которая имеет большое значение, чем сам стандарт. "DVD Demystified". "DVD Benchmark". Старожилы тут помнят, что даже такие зубры, как Графт и прочие светила с дум9 попадали впросак, читая стандарт. Хотя бы знаменитый спор про цветовой стандарт DVD, 601 или 709. Когда наконец выяснилось, что стандарт говорит: "определяется практикой индустрии". И пришлось зубрам спрашивать ребят с завода 
По-любому, словопрение это - чисто академическое. Как будет на практике с телесином - см. выше, но и это знать совершенно необязательно, чтобы им пользоваться.
Лунный_кот писал(а):
59275425
tartak писал(а):
Вот уже и хороший "чисто ДВД" плеер купить стало невозможно. .
Как и BD достойного качества - наличие этого трекера тому подтверждение.
Трекер подтверждает, что блу-рей потрясающего качества купить можно, многие тут и раздаются. Дефицит в определенной местности, это уже отдельный вопрос. И разумеется, у людей скопились огромные коллекции DVD, а блурики только еще начинаются и старой классики на них чрезвычайно мало. Поэтому и приходится покупать блу-рей плеер для двд (если старый двд плеер сдох, скажем) - двд плееры разумного качества уже не купишь новые.
|
|
|
|
Xpюша
Стаж: 16 лет 4 месяца Сообщений: 3635
|
Xpюша ·
13-Май-13 12:18
(спустя 2 часа 34 мин., ред. 13-Май-13 12:18)
Areyou писал(а):
59275209Это условно - в любом случае есть сила, заставляющая либо кадры (случай frame picture), либо поля (случай field picture) поступать на декодер в строго определённом порядке.
А теперь представим: декодер (телевизора) только что включили и на вход его поступает самое первое поле. Куда его выводить?
А ещё набор кадров передачи мог быть "сшит" из фрагментов, закодированных в разное время разными людьми - без заботы о сохранении одинаковой очерёдности полей.
А ещё, поскольку это телевещание, кадры, закодированные разом (для одной передачи), могут внезапно кончиться, и начаться кадры другой передачи.
А ещё зритель может внезапно переключить канал, да не на телевизоре, а на внешнем (спутниковом, кабельном, эфирном) приёмнике...
Нет, обсуждаемая часть заголовка - не условность. Без её постоянного учёта декодеру обойтись никак нельзя.
Лунный_кот писал(а):
59275425Так как получить-то frame-picture в прогрессиве?
https://rutr.life/forum/viewtopic.php?p=59235549#59235549
----
Вынужден откланяться: через полтора часа поезд.
|
|
|
|
Mikky72
Стаж: 18 лет 7 месяцев Сообщений: 8498
|
Mikky72 ·
13-Май-13 14:13
(спустя 1 час 54 мин., ред. 13-Май-13 14:13)
tartak писал(а):
592746431) Никак. Всегда будет picture_structure = frame. Карбон по-моему позволяет и поле (но только не для телесина, конечно), но это крайне не рекомендуется и никогда не используется для ДВД (реальных, см. выше)
Вы не поняли вопроса. Я спрашивал не про picture structure (в терминологии DGIndex это Frame Struct), а про frame type!
Повторяю картинку из первого поста:
При том, что всегда picture structure = frame могут быть различные frame type (Interlaced или Progressive).
Как настроить однозначно этот момент в кодировщике и главное - нужно ли?
Создатели Карбона, например, в пресете для DVD вариант progressive исключили, но можно через "финт ушами" (выбор Generic MPEG2) к нему добраться. ССЕ также при выставлении галки progresive выдает Picture struct = Frame, но Frame type = Interlaced, а получить тут Picture structure = Frame при Frame type = Progressive, похоже, тоже можно через "финт ушами" (см. "метод Хрюши").
При этом Areyou намекает, что для Picture struct = Frame вариант Frame type = Interlaced недостаточно хорош и лучше использовать Frame type = Progressive (т.е. его "академическая" точка зрения не совпадает с "де факто" программ кодирования видеодорожек "для DVD" и практикой заводских DVD R1).
Вот и вопрос (совершенно прикладной, а не академический) - надо ли описывать и рекомендовать "финтить ушами" В ИНСТРУКЦИИ в целях борьбы за "самый полный прогрессив" (Picture structure = Frame при Frame type = Progressive) или оставить инструкции как есть (на данный момент по инструкциям получим Picture structure = Frame при Frame type = Interlaced)?
На данный момент есть 3 позиции:
1) моя - не стоит, так как я разбираюсь хуже, чем создатели CC и ССЕ, а они в пресете для DVD выдают именно Frame type = Interlaced
2) Хрюши - не стоит, так как иначе картинка при пуллдауне будет дергаться на "классических" плеерах (только его "запинали ногами" за эти "буферы", хотя и не сказали "в защиту" самого Frame type = Progressive)
3) Тартака - "не вижу смысла в этой борьбе за прогрессив (Frame type = Progressive) - DVD от рождения подразумевает интерлейс"
4) А-ю - "Frame type = Interlaced можно, конечно, но качественней Frame type = Progressive "
Чисто "демократически" в президенты проходит вариант "да ну его (Frame type = Progressive) подальше..." 
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
13-Май-13 21:05
(спустя 6 часов)
Xpюша
В аналоговой ТВ синхро-структуре есть понятие первого поля кадра (в PAL кадр формально начинается с верхнего поля) и это действительно, полезно для коммутации синхронных источников. По структуре синхросмеси аппаратно легко распознать четные и нечётные поля, поэтому верхние и нижние не путаются (независимо от того, с какого поля начать показ). Соответственно, вывести на приёмник такой системы записанную последовательность полей, имеющих чередующиеся метки Top/Bottom, можно безошибочно. Я слишком сильно выразился о вольной природе этих полей (на самом деле им предписано существовать парами и следовать в порядке показа), но такого понятия, как " общий заголовок кадра" действительно нет. Обязательное расширение после заголовка picture принадлежит либо полю, либо кадру (picture - обобщающее понятие). При field picture принадлежность пары полей конкретному кадру можно определить напр. по положению sequence header (он не может располагаться между полями пары, относящимися к общему кадру). Есть ограничения по организации GOP и направленности ссылок предсказания. При этом в варианте field picture ссылки возможны только между полями, а при чересстрочной frame picture дополнительно возможны ссылки кадрового типа. В этом отношении второй вариант универсальнее. Первый предпочтительнее для сжатия при быстром движении, и при появлении стандарта mpeg2 предполагалось чередовать эти варианты в зависимости от текущего содержания материала. Реально получил распространение frame picture. А заложенное когда-то в стандарте решил, видимо в своей борьбе с CCE, реанимировать Canopus (возможно, и его клоны тоже - не смотрел, в Mainconcept не нашёл, в CCE точно нет этого). Но вот что пишут распространители канопуса о совместимости с плеерами:
* MPEG-2 PICTURE STRUCTURE AUTOMATIC AND ALWAYS FIELD ENCODED FILES:
Files encoded with the Picture Structure set to "Automatic" or "Always
Field Structure," while often providing increased compression efficiency,
may not properly decode in all MPEG-2 software or hardware players. Use
care when using automatic or field picture structures in MPEG-2 output.
http://canopus.vo.llnwd.net/o2/unsecure/DL/ProCoder_2.0/documentation/Readme_E_PC20402.txt
На видеохелпе один человек божился, что ранее по работе пользовался DVD Спецификацией и видел, что это запрещено, другие клянутся, что от приличной фирмы DVD с этим попадались. Но тенденция такова, что field picture (или FPP - field per picture, как это иногда называют) дело редкое.
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
13-Май-13 23:20
(спустя 2 часа 14 мин.)
Mikky72 писал(а):
59278049Чисто "демократически" в президенты проходит вариант "да ну его (Frame type = Progressive) подальше..."
Золотые слова! Но не могу удержаться: как мы все знаем, самые лучшие "демократические" решения - это когда выбора нет
В ССЕ никакого выбора на этот счет реально нет. Там есть куча возможностей для реального улучшения картинки, все эти фильтры и их параметры. Сидят компрессионисты, хорошо оплачиваемые, и подбирают параметры, к каждому куску записи - свои. Их совершенно не интересуют эти флаги, все их и так знают, и за борьбу с практикой работы отрасли никто вам не заплатит. Я бы предположил, что именно поэтому топовые инструменты типа ССЕ не дают контроля над тем, что отрасль не интересует (хотя нас, любителей - интересует иногда, как видно из этой дискуссии). Возможно вы захотите поставить вопрос так: можно ли сделать все против правил, найти потайную дверь, и получить нечто, что вам хочется? Хотя бы это и не имело отношения к практике, но вот кто-то сказал, что будет лучше, и вам хочется... Ну, попробуйте в Карбоне с generic mpeg-2 поиграть, потом посмотрите, что Philips Verifier скажет. Но и Verifier всего лишь смотрит на соблюдение стандарта, а не на соответствие практике и совместимость с реальными плеерами (к тому же в нем немало своих проблем, из-за которых muxman раньше так страдал). Короче, вы бы хотели устроить переворот ради некой абстрактной идеи? Сильно сомневаюсь.
Конкретно про Frame Type в DGIndex. Это флаг progressive_frame в мпег-2. Как я уже неоднократно говорил, сделайте телесин в NTSC, у вас скорей всего будет progressive_frame = 1, причем независимо от типа картинки, который вы можете выставить в picture settings. Кодируйте тот же исходник в PAL, легко получите progressive_frame = 0, опять независимо от типа картинки в picture settings. Всегда ли так будет? Не знаю, никогда не отслеживал, считаю, что не имеет значения - иначе ССЕ дал бы мне решить. ССЕ принимает решения о типе кодировки вплоть до макроблока, что уж там говорить о полях и кадрах. "Интерлейсная" кодировка реально можно быть прогрессивной на более низком уровне, если он так решит. Сломать защиту ССЕ и раздать его, и самому использовать - это было мне интересно. Ломать его работу и разбираться, как он внутри принимает решения - увольте.
Areyou писал(а):
59284732один человек божился, что ранее по работе пользовался DVD Спецификацией и видел, что это запрещено, другие клянутся, что от приличной фирмы DVD с этим попадались.
Трудно представить, чтобы это было напрямую запрещено, поскольку Verifier это пропустит. Также трудно поверить, чтобы это попалось на DVD от приличной фирмы - это бы означало, что они забили на совместимость.
|
|
|
|
Areyou
Стаж: 16 лет 11 месяцев Сообщений: 1724
|
Areyou ·
14-Май-13 07:44
(спустя 8 часов)
tartak писал(а):
59286974Кодируйте тот же исходник в PAL, легко получите progressive_frame = 0, опять независимо от типа картинки в picture settings.
В CCE точно от этого зависит - если при PAL поставить Progressive Frame (я ставлю и zigzag, хотя кодер при этом и сам обязуется его выбрать), то DGIndex для Frame Type покажет Progressive. В руководствах SP-SP3 такие настройки напрямую рекомендуют. Только что проверил в SP 2.70; без этого пишет Interlaced. И видимо, CCE всегда применяет progressive_sequence=0 (если в DGIndex это Sequence: 'Field/Frame'). В SP3 есть какие-то чудеса с сохранением файла настроек для picture ( Хрюша упоминал), видимо, это требуется для вступления настроек в силу (в старом SP такого нет).
|
|
|
|
tartak
Стаж: 19 лет 8 месяцев Сообщений: 2546
|
tartak ·
14-Май-13 09:17
(спустя 1 час 33 мин.)
Да, а ведь действительно, Хрюша был прав насчет SP3. В SP2 я еще проверял результаты, и тип картинки выставлял, но с PAL'ом дело имел мало и совсем позабыл, какое там получалось значение progressive_frame. А мануал SP3 лень было по-новой штудировать, ничего особенно не поменялось. Увидел сейчас, что от типа картинки ничего вроде не меняется, и решил, что так было всегда. В NTSC же получается progressive_frame = 1 по умолчанию при телесине, как и должно бы быть. Попал впросак.
А ведь на стр. 26 мануала все написано, просто в голову взять сложно, что они сделали такой патологический способ выбора установок. Теперь я начинаю подозревать, что куча народа даже не подозревает, что там происходит. Суда по всему, в SP3, все, что делается в окне picture settings, вообще никуда не идет напрямую, это всего лишь способ задать набор установок. Но они ни к чему не будут применены, пока вы не щелкните (двойным) на сегменте (они зовут его маркером) в списке маркеров (второе поле слева), поставите галочку на Picture, а потом выберете набор из списка, который задали перед этим в Picture Settings. Набор и его имя потеряются, если SP3 закрыть, но все можно сохранить в файл (Save внизу, в отличие от Save наверху в окне Picture Settings). То есть получается, что все фильтры, и все прочее, что там задается, это никуда не идет, пока не проделаешь эту процедуру! М-да, это точно надо в инструкцию.
|
|
|
|
