LINUX.ORG.RU

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

 , , ,


0

2

Добрый день! Я очень поверхностно знаком с HEVC, но насколько знаю информация об интерлейсинге передается в SPS во флагах general_progressive_source_flag и general_interlaced_source_flag. Так вот, есть видео у которого general_progressive_source_flag = 0 и general_interlaced_source_flag = 1. Инструмент gstreamer gst-discoverer-1.0 говорит о том, что видео имеет интерлейсинг (он определяет его наличие по SPS). Однако ffprobe утверждает, что видео прогрессивное. Подскажите пожалуйста - в чем может быть дело?

Само видео можно скачать по ссылке: https://cloud.mail.ru/public/5613/2n2PR2nu2


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

anonymous ()
Ответ на: комментарий от anonymous

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

dgrig ()
Ответ на: комментарий от dgrig

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

anonymous ()
Ответ на: комментарий от anonymous

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

1920x540 [SAR 1:1 DAR 32:9], 50 fps
И ещё много ругается на ошибки в файле. Может у меня версия старая. А как видео выглядит в ffplay? С нормальными пропорциями или 540 строк?

anonymous ()
Ответ на: комментарий от anonymous

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

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

boowai ★★★★ ()
Ответ на: комментарий от anonymous

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

dgrig ()

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

byko3y ★★ ()
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от byko3y

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

Потом появился 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 этого нет

anonymous ()
Ответ на: комментарий от byko3y

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Не знаю.

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

byko3y ★★ ()