Progressive или Interlaced HEVC (H.265) видео?

Сейчас видео с прогрессивной развёрткой. Его, видимо, криво из чересстрочной конвертировали. Из-за этого нарушено соотношение сторон и частота 50 герц. Полуполя записали в отдельные кадры.

А с технической точки зрения, если в SPS указан interlaced и полуполя идут отдельными кадрами - это разве не есть черессточная развёртка? Или тут под прогрессивной развёрткой вы имеете ввиду именно внешний вид? (Вопрос, чтобы самому разобраться)

Да, действительно, полуполя идут отдельными кадрами. Это видно по ряби картинки. При этом проигрыватели видят этот файл, как прогрессивный 50Гц. Попытался скормить его монтажным программам, чтобы выставить чересстрочный режим вручную, но они его импортировать отказались ))

см ffprobe -show_frames

interlaced_frame=1
top_field_first=1

Мой ffprobe про interlace не слова зато выводит:

1920x540 [SAR 1:1 DAR 32:9], 50 fps

540 строк и в ffplay, и в vlc, и в gst-play-1.0. Ошибки есть, да, но не похоже, что они связаны с интерлейсингом.

в hevc нет стандарта на interlace, или небыло год назад, это нестанадртное кодирование

Что же я еще раньше кодировал с x.265? Кстати, у него при понижении квантования раньше полезли дефекты, чем с x.264.

Попытался скормить его монтажным программам, чтобы выставить чересстрочный режим вручную, но они его импортировать отказались ))

У ffmpeg есть фильтры, которые могут в обе стороны перетасовывать и принудительно помечать. Если программа умеет эти фильтры, то можно попробовать.

Хм, как-то странно получается: ffmpeg видит, что это кадры с чересстрочной развёрткой, но всё равно говорит о прогрессиве. У него есть ещё какие-то способы детектирования интерлейса?

Я был хотел написать что-то про «какой нынче год?», а потом внезапно нашел, что у достаточно современных форматов зомбовидения с высоким разрешением есть черезстрочность. Что есть полнейший рак, потому что уже очень давно повышение частоты кадром стало возможно благодаря повышению сжатия, а не черезстрочности. Это уже не говоря о том, что черезстрочность ухудшает цифровое сжатие, из-за чего даже при приведении к прогрессивной развертке нельзя просто схлопывать полуполя — нужно делать сглаживания, иначе кодек будет пытаться жать гребенку. Пути мудацких коммитетов неисповедимы, чо.

черезстрочность ухудшает цифровое сжатие

каким образом ? в черезстрочном режиме поля отдельно кодируются как кадры и хранят чередование чтобы при декодировании потока знать где верхнее а где нижнее поле чтобы собрать из них кадр и сделать деинтерлейсинг

в черезстрочном режиме поля отдельно кодируются как кадры и хранят чередование чтобы при декодировании потока знать где верхнее а где нижнее поле чтобы собрать из них кадр и сделать деинтерлейсинг

Да, раньше верхние и нижние поля кодировались отдельно. Ну то есть получалась картинка с размером изображения, где сверху идут сплошным рядом нечетные строки, а снизу — четные строки. За счет такой организации более-менее получалось сэкономить на движении на границе между полуполями.

Потом появился MBAFF — Macroblock Adaptive Frame Field. Эта штука в H.264 решает, какой кусок изображения будет сжиматься как перемежающиеся четные-нечетные поля (то есть, как они будут отрисованы на экране), а какой кусок будет кодироваться как два отдельных склеенных полуполя. В результате статичная картинка жмется так же эффективно, как при прогрессивной развертке, а динамичные части изображения разносятся для устранения гребенки. Только с таким подходом черезстрочное видео стало возможно эффективно жать, но зачем всё это усложнение было с самого начала?

очень тяжело отвадить кабельных операторов от интерлейса =(

Потом появился MBAFF — Macroblock Adaptive Frame Field. Эта штука в H.264 решает

[quote] HEVC was designed with the idea that progressive scan video would be used and no coding tools were added specifically for interlaced video. Interlace specific coding tools, such as MBAFF and PAFF, are not supported in HEVC. HEVC instead sends metadata that tells how the interlaced video was sent. Interlaced video may be sent either by coding each frame as a separate picture or by coding each field as a separate picture. For interlaced video HEVC can change between frame coding and field coding using Sequence Adaptive Frame Field (SAFF), which allows the coding mode to be changed for each video sequence. This allows interlaced video to be sent with HEVC without needing special interlaced decoding processes to be added to HEVC decoders [/quote]

в HEVC этого нет

Только с таким подходом черезстрочное видео стало возможно эффективно жать

где-то пруфцы можно почитать?

а динамичные части изображения разносятся для устранения гребенки

каким образом черезстрочка на уровне макроблоков устраняет гребенку?

где-то пруфцы можно почитать?

Не знаю.

каким образом черезстрочка на уровне макроблоков устраняет гребенку?

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

Гребенка отвратительно жмется цифровыми кодеками.

цифровые кодеки не жмут гребенку, у них на входе всегда прогресивная картинка

Если же отдельно жать четные и нечетные полуполя, то ты получаешь снижение разрешения в два раза по вертикали, что снижает способность кодека сжимать картинку

що? первых кодек жмет в два раза меньше информации - полукадр, а во вторых черезстрочка это в два раза больше полукадров, поэтому снижение разрешения(?) откуда, возможно у вас стреляет bob deinterlease, а он не является единственным способом деинтерлиза

изменяется структура гопа, в районе ключевого можно получить более мягкий пик за счет того, что i кодируется первый полукадр, второй уже p

цифровые кодеки не жмут гребенку, у них на входе всегда прогресивная картинка

Если ты объединишь два поля в один кадр так, как он будет отрисовываться на экране — ты получишь свою гребенку. Это один из двух простых способов скормить черезстрочную развертку в прогрессивном виде кодеку. Второй — поместить поля отдельно.

первых кодек жмет в два раза меньше информации - полукадр, а во вторых черезстрочка это в два раза больше полукадров, поэтому снижение разрешени

Пардон, ты в курсе за счет чего вообще видеокодеки достигают сжатия видеоинформации? Самый большой эффект достигается за счет сжатия именно на двух соседних пикселях. Но они разнесены в разные поля! И ты теряешь где-то так половину потенциального сжатия по вертикали.

изменяется структура гопа, в районе ключевого можно получить более мягкий пик за счет того, что i кодируется первый полукадр, второй уже p

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

Самый большой эффект достигается за счет сжатия именно на двух соседних пикселях

какие нафиг пиксели, если в кадре будут сиськи то ничего кроме них ты не увидишь больше - можно оставить только сиськи.

какие нафиг пиксели, если в кадре будут сиськи то ничего кроме них ты не увидишь больше - можно оставить только сиськи

Ну. А я тебе и пишу, как эти сиськи будут жаться. На пальцах это можно представить так: у тебя есть строка AAAAAABBBBBB, компрессор жмет ее как Ax6Bx6; теперь ты разнес нечетные и четные символы отдельно, компрессор тебе их сжал как Ax3Bx3Ax3Bx3 — ты получил в два раза больше объем той же инфы. Ферштейн?

Бесполезно смотреть, что там всякие программы говорят, надо самому смотреть.