В целом HDR это действительно расширение динамического диапазона за счет увеличения количества бит на канал. Какая там уже заложена кривая яркости - дело вторичное.
Наоборот, повышение разрядности лишь сохраняет градиенты или помогает кодекам сжимать видео. А вот специальная гамма добавляет информацию о диапазоне яркости: либо потому что гамма привязана к абсолютной яркости (PQ), либо потому что гамма просто намекает, что пришло время переключиться в HDR-режим (HLG). Вроде так.
Нет. HLG предназначена для того, чтобы показывать изображения HDR на экранах SDR, да и то не на всех.
Если это сделать, получится выцветшая картинка - из-за того, что стандартный HDR (BT.2100) существует только в связке с WCG (широким цветовым охватом, по BT.2020). Возможно, между SDR-телевизорами и HDR-WCG-телевизорами должен был быть период SDR-WCG-телевизоров (тех самых "не всех") и контента. Но на практике ничего внятного не было[1][2].
За HLG стоит BBC, который, как пишут, сам на какую-либо обратную совместимость не полагается. Это полноценная HDR-гамма со своими особенностями, без PQ'шной абсолютности и, что ли, более приспособленная к использованию без дальнейшей обработки, чем разнообразные Log'и.
Гамма даёт субъективную равномерность (говорят "perceptually uniform"), линейная яркость даёт физическую равномерность. Иногда нужно первое (хранение, отображение), иногда второе (некоторые виды обработки). Костыльность возникает, если считать одно важнее другого.
Первой же картинкой вводите в заблуждение касаемо разницы sdr и hdr. Авторы картинки взяли обычное фото ...
Первая картинка не про отображение или захват, она лишь объясняет один из вариантов хранения HDR: "SDR-картинка + Gain Map" (Google Ultra HDR, ISO 21496-1) вместо телевизионного подхода с PQ или HLG, например.
Заблуждения возникают сами собой от размытости и широты термина. HDR-штука - штука с* ДД**, который шире обычного*** ДД.
* где именно этот ДД - зависит от контекста (захват, отображение, хранение, преобразование, метаданные, рендеринг) ** тот динамический диапазон, который про разрядность сигнала, здесь не считается *** что такое "обычный ДД" - зависит от контекста. ДД камеры в пределах 1 кадра (без брекетинга экспозиции); ДД, который гораздо ниже возможностей зрения; ДД sRGB-монитора...
Специалистов терминологическим адом не напугать, а потребители, мол, пусть себе потребляют.
Про форматы и накопители вы зря так, и ссылка на бразильский роман вместо отчёта ЮНЕСКО подтверждает. Вымирания декодеров RealAudio нет[1], вымирания декодеров H.264 и H.265 не будет (а если вдруг - то не будет заметной проблемой, потому что [2]), флеш-память стала доступна из-за массовости, а совершенное архивное хранилище массовым и, соответственно, дешёвым, вряд ли станет (сколько людей хотя было слышало про следующее серийное, более лучшее, поколение дисков после Blu-ray?).
На централизованных вебархивах и на Wikimedia Commons сейчас многое держится, да, это удивительные явления. Но немного уменьшить лояльность государств, немного замедлить снижение цен на накопители - и что тогда? А потом и за владельцами нод IPFS прийти, чтоб в американ/евро/японкомнадзоре не забывали регистрироваться. Нынешнее равновесие кажется очень шатким. (кажется, на хабре эта тема больше всего волнует @PereslavlFoto)
[1]
Например, аудиозаписи в формате RealAudio конца 1990-х сегодня почти невозможно воспроизвести из-за отсутствия рабочих декодеров. А прошло меньше 30 лет.
Если бы вы показали те гипотетические записи, вам бы их неравнодушные читатели насильно декодировали, ведь так реверсивная психология работает :)
[2]
но кодек H.264, на котором оно сжато, уже не поддерживается ни одним устройством
Для массового удаления поддержки надо найти мотив. Это будет антиутопия, в которой государства или корпорации уничтожают историю вместе со старыми декодерами, плеерами, текстами стандартов - проблема окажется не в H.264, а почти что в миропорядке.
Миграция данных в открытые форматы (AV1 вместо HEVC),
Всё-таки это только качество перекодированием ухудшать; там проблема не в сохранности относительно AV1 (а в 30-х годах ещё патенты истекут), а в нынешних патентных ограничениях, но они пользователями учитываются, иначе бы не пользовались (новых внезапных ограничений нет).
Если позаимствовать JPEG'овый контейнер, то, видимо, так можно упаковать 255/3 = 85 цветных кадров (там выделен 1 байт под Nf: Number of image components in frame).
Он предлагает E3, это i7-3770 с отключенным iGPU, включённой поддержкой ECC и подешевле. А вы про более серьёзную линейку E5, из которой ещё HEDT делали.
условные операторы, такие как If, else, switch — и особенно часто их используют новички, потому что их понимание и работа достаточно проста
многие отмечают, что последний оператор switch им приходилось видеть только на разнообразных олимпиадных задачках или школьных уроках
(а вы его используете, и насколько часто?).
Тем не менее, как бы там ни было, существует целый ряд иных подходов, который позволяет избавиться от этих операторов
можно отметить, что не нужно забывать главное — избавление от условных операторов не является самоцелью программирования
И к слову — как вы поступаете, чтобы уйти от ef-else?
Статья кажется провокацией с идеей, что "if и switch - это (почти) новый goto". Потому что в ней избегается вопрос: "в какой момент решение на if'ах становится лапшой и перестаёт справляться со сложностью". Без этого вопроса телега оказывается впереди лошади: решение есть, а проблемы нет.
Так вы сформулируйте мысль правильно: "не стоит работать напрямую с .VOB'ами, это часть внутренней структуры DVD, пусть с ней работают demuxer'ы".
Соглашусь из-за практичности - всё равно из DVD надо извлечь остальное помимо видеодорожки. (на реддите про современные демуксеры DVD; ffmpeg обзавёлся своим в прошлом году).
Но в принципе, если ограничиться видео - DGIndex работает с .VOB'ами (склеенными или нет), работает без такой проблемы, а "разрешение, фпс", конечно, в .VOB'ах есть.
не заложена. хотя бы потому, что существуют multi-angle dvds
Это скорее про разрезание, чем склеивание, и очень они условно существуют, разве что демонстрационный диск найти несложно.
Стандарт на MPEG-2 Video рассматривает тот Extension не только как рекомендацию по обрезке кадра
Видимо, здесь закралась ошибка
А всё-таки здесь ffmpeg прав, вина только на пиратах.
Неважные подробности
Стандарт хочет сказать: "если Sequence Display Extension присутствует, то тогда метаданные про Display AR (4/3) начинают относиться не к размеру битмапа (720x480), а к размеру, заданному в Extension (540x480)" - если как 4/3 отображается часть кадра 540x480, то полный кадр 720x480 отображается как 16/9, всё правильно.
Но как можно пользоваться этой фичей MPEG2 Video, если из-за необязательности её поддержки ("extension ... does not define the display process", "may be ignored by decoders that conform to this specification") отношение сторон на некоторых плеерах гарантированно будет искажено? Фича подразумевает, что зрители, которым не повезло, заметят неладное и воспользуются специальной кнопкой на пульте.
Позволит хранить на 2 копии видео меньше (видео-исходник -> PNG -> JPG -> видео-результат), уменьшит количество кода. Ещё как бонус - возможность накодить в скрипте realtime-сравнение. Отдавать в плеер чередующиеся кадры до/после или модель1/модель2, с поясняющими подписями, сравнивать покадровой перемоткой туда-сюда.
Вот тут я не уверен точно. Несколькими способами я получил фактическое разрешение 640x480. Тут получается, что оба 640x480 и 720x540 нестандартные разрешения, поэтому тем более сложно понять какое оно на самом деле.
Тут непросто осознать, что из-за концепции неквадратных пикселей приходится работать с тремя величинами (SAR, PAR, DAR) вместо одной (SAR или DAR, при квадратных пикселях это одно и то же).
В растре (aka битмапе) кадра на этом DVD находятся стандартные 720x480 отсчётов и 720/480 называют SAR (Storage Aspect Ratio).
В метаданных DVD где-то прописано желаемое отношение сторон на экране (Display AR), на DVD это либо 4/3 (как тут), либо 16/9.
720x480 надо как-то растянуть, чтобы получить 4/3. Как растянуть - говорит PAR, умозрительный неквадратный пиксель битмапа, удобная такая абстракция.
4/3 в виде 640x480 или 720x540 или 1280x960 - не важно, это разрешение существует только в процессе вывода DVD на экран. Или существует в новом файле (в DVD-рипе) после избавления от легаси в виде неквадратных пикселей.
Level 2
Книжка DVD Demystified говорит, что надо учитывать четвёртую величину - оверскан. PAR по книжке считается от величины (720-16)x480.
Level 3
Но кто сказал, что такое неудобное правило соблюдали все профессионалы в ходе DVD-авторинга?
Level 4
Но кто сказал, что его важно соблюдать? Величина ошибки слишком мала.
И цвета от ошибки в BT.601/709 тоже несильно уедут, кстати. И тоже нет гарантии, что профессионалы в поздних дисках учитывали BT.601/709.
И круглые объекты в кадре могут оказаться более надёжным эталоном при поиске идеально верного отношения сторон.
Я писал: "видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps".
MPEG-2 stream on DVDs is capable of storing the 24000 ÷ 1001 frames losslessly packing them into fields in 30 30000 ÷ 1001 interlaced stream using soft telecine flags [флаги repeat_first_field и top_field_first].
Это счастливая случайность, что они оказались прописаны, причём именно так.
У древних людей помимо неквадратных пикселей была ещё одна прогрессивная технология - цвета, зависящие от разрешения видео. При отсутствии этих метаданных видео низкого разрешения декодируется из YUV в RGB по одной формуле, а если разрешение увеличить хотя бы до 720p - то уже по другой формуле (так получилось). А метаданные могут отвалиться по пути или проигнорироваться плеером.
Поэтому лучше в увеличенном видео видео придерживаться HD-коэффициентов (в метаданных их можно указывать, можно не указывать) и убеждаться (в mpv, например), что красный с зелёным не поехали. Если апскейл в RGB, то должна получиться такая цепочка:
Проблема воспроизводится без объединения VOB'ов. Это ошибка в VTS_01_1.VOB.
По запросу "copy /b" "dgindex" OR "dgmpgdec" гугл должен был дать конкретику о том, почему нельзя, но он выдаёт обратное: "заложена ли возможность бинарной склейки в стандарт - Вроде как заложена".
Не хочу сильно задерживаться на этом, это история размером с отдельную статью, и надеюсь данный случай был редким исключением, поэтому нет смысла его описывать.
Фактор №1 - криво собранный пиратами DVD. В первый VOB добавили Sequence Display Extension, а в нём прописали 540x480 как размер активной части экрана[1]. Это число примерно означает, что видео 16:9 на старый 4:3-телевизор предпочтительнее впихивать с обрезкой краёв (pan&scan), чем с чёрными полосами сверху-снизу (letterbox)[2]. То есть от полного кадра 720x480 оставлять 540x480 посередине (это 0.75 от полного кадра: 16/9 * 0.75 = 4/3). Но здесь видео не 16:9 (поэтому Sequence Display Extension не нужен) и ЭЛТ-телевизоры к компьютерам подключать перестали - компьютерые плееры могут рисовать кадр целиком, игнорируя рекомендации из Extension.
Фактор №2 - кривизна ffmpeg. Они решили творить фигню, потому что в стандарте можно найти разрешение на это. "Garbage in - garbage out, проблема не на нашей стороне". Стандарт на MPEG-2 Video рассматривает тот Extension не только как рекомендацию по обрезке кадра, но и почему-то как основу для вычисления Pixel AR (aka Sample AR)[3]. Видимо, здесь закралась ошибка. Считаем по стандарту Pixel AR через Display AR и 540x480: (4/3) / (540/480) = 32/27, затем забываем, что Display AR = 4/3 (просто потому что) и пересчитываем Display AR на основе ошибочного Pixel AR и Storage AR, получаем 32/27 * 720/480 = 16:9, смело растягиваем видео до 16:9...
В показе 29.75 fps виноват в основном ffmpeg. С первыми 4 кадрами что-то не так и он по ним, видимо, решил, что тут переменный фреймрейт (сообщать об этом и показывать точное среднее значение он не захотел). Но если опустить эту ошибку, всё равно 30/1.001 fps - это бестолковое сообщение о том, как технически хранится видео на DVD (видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps). А MediaInfo здесь не ошибается.
говорят, что разрешение видео стандартное - 720x480, но если выгружать фреймы в этом разрешении, картинка становится растянута по горизонтали
Фактор №3 - незнакомство с древними технологиями. В SD-видео использовали неквадратные пиксели (Pixel AR != 1:1), так было удобнее оцифровывать аналоговое видео (в котором тоже была неквадратность - вертикальное разрешение прибито к стандарту разложения, а горизонтальное менялось). Кадр на самом деле 720x480 (Storage AR = 720/480 = 3/2), но с вытянутыми вверх пикселями (Pixel AR = 8/9) и физически на экране он должен иметь соотношение сторон Display AR = Storage AR *Pixel AR = 3/2 * 8/9 = 4/3 = 640/480 = 720/540. Лучше оквадрачивать кадр до 720x540 вместо 640x480, чтобы 11% горизонтального разрешения не терять.
С помощью ffmpeg распаковываем фильм по кадрам в формате PNG Итоговые файлы я обычно сохраняю в JPG
Эти этапы можно пропустить с помощью фреймсервера (avisynth или питоновский vapoursynth), это стандартный способ для "видео-в-видео". ffmpeg принимает на вход скрипты этих фреймсерверов (они открывают видео, на лету обрабатывают его и отдают ffmpeg'у, он кодирует), плееры разные их тоже открывают.
Они вообще известны саундтреками под NES. Или можно сказать, своей работой с ограничениями приставки? Если железо позволяет делать безупречный жирный бас (а в остальном... мало что позволяет), то надо его делать.
Слишком банально, в этой теории нет места для сдерживания прогресса и властей.
Ещё банальнее будет, если окажется, что подход с внешней HBM-памятью выгоднее. Cerebras почему-то не выпускает уменьшенные версии (с eDRAM вместо SRAM, чтобы сохранить приличный объём памяти, например) и не выглядит однозначным победителем за счёт своей технологии - без HBM никуда, а без этого MIMD все остальные обходятся, даже китайцы. Хотя могли бы носиться как с квантовыми компьютерами.
Наоборот, повышение разрядности лишь сохраняет градиенты или помогает кодекам сжимать видео. А вот специальная гамма добавляет информацию о диапазоне яркости: либо потому что гамма привязана к абсолютной яркости (PQ), либо потому что гамма просто намекает, что пришло время переключиться в HDR-режим (HLG). Вроде так.
Если это сделать, получится выцветшая картинка - из-за того, что стандартный HDR (BT.2100) существует только в связке с WCG (широким цветовым охватом, по BT.2020). Возможно, между SDR-телевизорами и HDR-WCG-телевизорами должен был быть период SDR-WCG-телевизоров (тех самых "не всех") и контента. Но на практике ничего внятного не было[1][2].
За HLG стоит BBC, который, как пишут, сам на какую-либо обратную совместимость не полагается. Это полноценная HDR-гамма со своими особенностями, без PQ'шной абсолютности и, что ли, более приспособленная к использованию без дальнейшей обработки, чем разнообразные Log'и.
Гамма даёт субъективную равномерность (говорят "perceptually uniform"), линейная яркость даёт физическую равномерность. Иногда нужно первое (хранение, отображение), иногда второе (некоторые виды обработки). Костыльность возникает, если считать одно важнее другого.
Первая картинка не про отображение или захват, она лишь объясняет один из вариантов хранения HDR: "SDR-картинка + Gain Map" (Google Ultra HDR, ISO 21496-1) вместо телевизионного подхода с PQ или HLG, например.
Заблуждения возникают сами собой от размытости и широты термина. HDR-штука - штука с* ДД**, который шире обычного*** ДД.
* где именно этот ДД - зависит от контекста (захват, отображение, хранение, преобразование, метаданные, рендеринг)
** тот динамический диапазон, который про разрядность сигнала, здесь не считается
*** что такое "обычный ДД" - зависит от контекста. ДД камеры в пределах 1 кадра (без брекетинга экспозиции); ДД, который гораздо ниже возможностей зрения; ДД sRGB-монитора...
Специалистов терминологическим адом не напугать, а потребители, мол, пусть себе потребляют.
Про форматы и накопители вы зря так,
и ссылка на бразильский роман вместо отчёта ЮНЕСКО подтверждает. Вымирания декодеров RealAudio нет[1], вымирания декодеров H.264 и H.265 не будет (а если вдруг - то не будет заметной проблемой, потому что [2]), флеш-память стала доступна из-за массовости, а совершенное архивное хранилище массовым и, соответственно, дешёвым, вряд ли станет (сколько людей хотя было слышало про следующее серийное, более лучшее, поколение дисков после Blu-ray?).На централизованных вебархивах и на Wikimedia Commons сейчас многое держится, да, это удивительные явления. Но немного уменьшить лояльность государств, немного замедлить снижение цен на накопители - и что тогда? А потом и за владельцами нод IPFS прийти, чтоб в американ/евро/японкомнадзоре не забывали регистрироваться. Нынешнее равновесие кажется очень шатким.
(кажется, на хабре эта тема больше всего волнует @PereslavlFoto)
[1]
Если бы вы показали те гипотетические записи, вам бы их неравнодушные читатели насильно декодировали, ведь так реверсивная психология работает :)
[2]
Для массового удаления поддержки надо найти мотив. Это будет антиутопия, в которой государства или корпорации уничтожают историю вместе со старыми декодерами, плеерами, текстами стандартов - проблема окажется не в H.264, а почти что в миропорядке.
Всё-таки это только качество перекодированием ухудшать; там проблема не в сохранности относительно AV1 (а в 30-х годах ещё патенты истекут), а в нынешних патентных ограничениях, но они пользователями учитываются, иначе бы не пользовались (новых внезапных ограничений нет).
Он есть, хаб "Ненормальное программирование".
Идея витает в воздухе?
2023: 3D-DCT can be applied for creating a video coder much simpler than those following MPEG-x/H.26x and with only slightly less performance. https://arxiv.org/abs/2304.00299
(или из 2017: A 3D-DCT video encoder...)
Если позаимствовать JPEG'овый контейнер, то, видимо, так можно упаковать 255/3 = 85 цветных кадров (там выделен 1 байт под Nf: Number of image components in frame).
Они у гугла никуда не делись.
inurl:,intitle:,site:,filetype:,"",OR,-Часто запросы такого формата помогают:
... filetype:pdf site:.cn.И конкретно эта материнка: https://ru.gecid.com/mboard/asus_p5kpl/
Он предлагает E3, это i7-3770 с отключенным iGPU, включённой поддержкой ECC и подешевле. А вы про более серьёзную линейку E5, из которой ещё HEDT делали.
Статья кажется провокацией с идеей, что "if и switch - это (почти) новый goto". Потому что в ней избегается вопрос: "в какой момент решение на if'ах становится лапшой и перестаёт справляться со сложностью". Без этого вопроса телега оказывается впереди лошади: решение есть, а проблемы нет.
Так вы сформулируйте мысль правильно: "не стоит работать напрямую с .VOB'ами, это часть внутренней структуры DVD, пусть с ней работают demuxer'ы".
Соглашусь из-за практичности - всё равно из DVD надо извлечь остальное помимо видеодорожки. (на реддите про современные демуксеры DVD; ffmpeg обзавёлся своим в прошлом году).
Но в принципе, если ограничиться видео - DGIndex работает с .VOB'ами (склеенными или нет), работает без такой проблемы, а "разрешение, фпс", конечно, в .VOB'ах есть.
Это скорее про разрезание, чем склеивание, и очень они условно существуют, разве что демонстрационный диск найти несложно.
А всё-таки здесь ffmpeg прав, вина только на пиратах.
Неважные подробности
Стандарт хочет сказать: "если Sequence Display Extension присутствует, то тогда метаданные про Display AR (4/3) начинают относиться не к размеру битмапа (720x480), а к размеру, заданному в Extension (540x480)" - если как 4/3 отображается часть кадра 540x480, то полный кадр 720x480 отображается как 16/9, всё правильно.
Но как можно пользоваться этой фичей MPEG2 Video, если из-за необязательности её поддержки ("extension ... does not define the display process", "may be ignored by decoders that conform to this specification") отношение сторон на некоторых плеерах гарантированно будет искажено? Фича подразумевает, что зрители, которым не повезло, заметят неладное и воспользуются специальной кнопкой на пульте.
Позволит хранить на 2 копии видео меньше (видео-исходник ->
PNG->JPG-> видео-результат), уменьшит количество кода. Ещё как бонус - возможность накодить в скрипте realtime-сравнение. Отдавать в плеер чередующиеся кадры до/после или модель1/модель2, с поясняющими подписями, сравнивать покадровой перемоткой туда-сюда.Тут непросто осознать, что из-за концепции неквадратных пикселей приходится работать с тремя величинами (SAR, PAR, DAR) вместо одной (SAR или DAR, при квадратных пикселях это одно и то же).
В растре (aka битмапе) кадра на этом DVD находятся стандартные 720x480 отсчётов и 720/480 называют SAR (Storage Aspect Ratio).
В метаданных DVD где-то прописано желаемое отношение сторон на экране (Display AR), на DVD это либо 4/3 (как тут), либо 16/9.
720x480 надо как-то растянуть, чтобы получить 4/3. Как растянуть - говорит PAR, умозрительный неквадратный пиксель битмапа, удобная такая абстракция.
4/3 в виде 640x480 или 720x540 или 1280x960 - не важно, это разрешение существует только в процессе вывода DVD на экран. Или существует в новом файле (в DVD-рипе) после избавления от легаси в виде неквадратных пикселей.
Level 2
Книжка DVD Demystified говорит, что надо учитывать четвёртую величину - оверскан. PAR по книжке считается от величины (720-16)x480.
Level 3
Но кто сказал, что такое неудобное правило соблюдали все профессионалы в ходе DVD-авторинга?
Level 4
Но кто сказал, что его важно соблюдать? Величина ошибки слишком мала.
И цвета от ошибки в BT.601/709 тоже несильно уедут, кстати. И тоже нет гарантии, что профессионалы в поздних дисках учитывали BT.601/709.
И круглые объекты в кадре могут оказаться более надёжным эталоном при поиске идеально верного отношения сторон.
Я писал: "видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps".
Вот википедия аккуратно слова подбирает:
MPEG-2 stream on DVDs is capable of storing the 24000 ÷ 1001 frames losslessly packing them into fields in
3030000 ÷ 1001 interlaced stream using soft telecine flags [флаги repeat_first_field и top_field_first].*Про piraty_fragment_hd.mkv на гуглодиске*
MediaInfo:
Matrix coefficients : BT.470 System B/GЭто счастливая случайность, что они оказались прописаны, причём именно так.
У древних людей помимо неквадратных пикселей была ещё одна прогрессивная технология - цвета, зависящие от разрешения видео. При отсутствии этих метаданных видео низкого разрешения декодируется из YUV в RGB по одной формуле, а если разрешение увеличить хотя бы до 720p - то уже по другой формуле (так получилось). А метаданные могут отвалиться по пути или проигнорироваться плеером.
Поэтому лучше в увеличенном видео видео придерживаться HD-коэффициентов (в метаданных их можно указывать, можно не указывать) и убеждаться (в mpv, например), что красный с зелёным не поехали. Если апскейл в RGB, то должна получиться такая цепочка:
[YUV] ---по-BT.601---> [RGB] ---апскейл---> [RGB] ---по-BT.709---> [YUV]Скрытый текст
Проблема воспроизводится без объединения VOB'ов. Это ошибка в VTS_01_1.VOB.
По запросу "copy /b" "dgindex" OR "dgmpgdec" гугл должен был дать конкретику о том, почему нельзя, но он выдаёт обратное: "заложена ли возможность бинарной склейки в стандарт - Вроде как заложена".
Говорят, что нельзя, но примеры поломок не приводят. Ниже написал, из-за чего тут на самом деле проблема (она в первом VOB'е).
*для тех, кто тоже распарсил не с первого раза*
...заметно лучше, чем 1080p с недостаточным битрейтом (как на ютубе).
Фактор №1 - криво собранный пиратами DVD. В первый VOB добавили Sequence Display Extension, а в нём прописали 540x480 как размер активной части экрана[1]. Это число примерно означает, что видео 16:9 на старый 4:3-телевизор предпочтительнее впихивать с обрезкой краёв (pan&scan), чем с чёрными полосами сверху-снизу (letterbox)[2]. То есть от полного кадра 720x480 оставлять 540x480 посередине (это 0.75 от полного кадра: 16/9 * 0.75 = 4/3). Но здесь видео не 16:9 (поэтому Sequence Display Extension не нужен) и ЭЛТ-телевизоры к компьютерам подключать перестали - компьютерые плееры могут рисовать кадр целиком, игнорируя рекомендации из Extension.
Фактор №2 - кривизна ffmpeg. Они решили творить фигню, потому что в стандарте можно найти разрешение на это. "Garbage in - garbage out, проблема не на нашей стороне". Стандарт на MPEG-2 Video рассматривает тот Extension не только как рекомендацию по обрезке кадра, но и почему-то как основу для вычисления Pixel AR (aka Sample AR)[3]. Видимо, здесь закралась ошибка. Считаем по стандарту Pixel AR через Display AR и 540x480: (4/3) / (540/480) = 32/27, затем забываем, что Display AR = 4/3 (просто потому что) и пересчитываем Display AR на основе ошибочного Pixel AR и Storage AR, получаем 32/27 * 720/480 = 16:9, смело растягиваем видео до 16:9...
В показе 29.75 fps виноват в основном ffmpeg. С первыми 4 кадрами что-то не так и он по ним, видимо, решил, что тут переменный фреймрейт (сообщать об этом и показывать точное среднее значение он не захотел). Но если опустить эту ошибку, всё равно 30/1.001 fps - это бестолковое сообщение о том, как технически хранится видео на DVD (видео тут прогрессивное 24/1.001 fps, но оно как бы лежит в контейнере чересстрочного с 30/1.001 fps). А MediaInfo здесь не ошибается.
Фактор №3 - незнакомство с древними технологиями. В SD-видео использовали неквадратные пиксели (Pixel AR != 1:1), так было удобнее оцифровывать аналоговое видео (в котором тоже была неквадратность - вертикальное разрешение прибито к стандарту разложения, а горизонтальное менялось). Кадр на самом деле 720x480 (Storage AR = 720/480 = 3/2), но с вытянутыми вверх пикселями (Pixel AR = 8/9) и физически на экране он должен иметь соотношение сторон Display AR = Storage AR * Pixel AR = 3/2 * 8/9 = 4/3 = 640/480 = 720/540. Лучше оквадрачивать кадр до 720x540 вместо 640x480, чтобы 11% горизонтального разрешения не терять.
Эти этапы можно пропустить с помощью фреймсервера (avisynth или питоновский vapoursynth), это стандартный способ для "видео-в-видео". ffmpeg принимает на вход скрипты этих фреймсерверов (они открывают видео, на лету обрабатывают его и отдают ffmpeg'у, он кодирует), плееры разные их тоже открывают.
Нейронки я в них не пробовал, но какие-то плагины есть:
https://github.com/Asd-g/avs-mlrt/blob/main/mlrt_ort/README.md
https://github.com/rlaphoenix/VSGAN/blob/master/vsgan/networks/swinir.py
https://github.com/HolyWu/vs-swinir
DVD в фреймсерверах правильнее всего открывать с помощью плагина D2V Source:
https://github.com/Asd-g/MPEG2DecPlus (avisynth)
https://github.com/dwbuiten/d2vsource (vapoursynth)
Он открывает файлы-индексы-для-группы-VOB'ов - .d2v, создаваемые через DGIndex (ещё какой-то D2V Witch есть): https://www.rationalqm.us/dgmpgdec/dgmpgdec.html
Индексация сторонней утилитой добавляет неудобства, но зато даёт надёжный случайный доступ и доп. информацию про DVD (в DGIndex: Tools -> Parse D2V).
Проблема с 29.97 fps у заведомо прогрессивного видео в DGIndex решается через Video -> Field Operation -> Forced Film перед созданием .d2v.
[1] Такое может показать этот софт: https://www.headbands.com/gspot/
[2] https://www.ee.columbia.edu/~eleft/e6880-Spring97/docs/is138182.pdf#page=68 ("display_horizontal_size and display_vertical_size together define...")
[3] https://www.ee.columbia.edu/~eleft/e6880-Spring97/docs/is138182.pdf#page=60 (формула отличается, потому что в стандарте SAR и DAR определены перевёрнутыми, чтобы было не скучно: 9:16, 3:4...; то есть там SAR = DAR x ... = 1/Non-Inverted-Pixel-aka-Sample-AR = 1/Non-Inverted-Display-AR x ...)
*продолжая оффтоп про NES*
Они вообще известны саундтреками под NES. Или можно сказать, своей работой с ограничениями приставки? Если железо позволяет делать безупречный жирный бас (а в остальном... мало что позволяет), то надо его делать.
Ещё 3 трека
Слишком банально, в этой теории нет места для сдерживания прогресса и властей.
Ещё банальнее будет, если окажется, что подход с внешней HBM-памятью выгоднее. Cerebras почему-то не выпускает уменьшенные версии (с eDRAM вместо SRAM, чтобы сохранить приличный объём памяти, например) и не выглядит однозначным победителем за счёт своей технологии - без HBM никуда, а без этого MIMD все остальные обходятся, даже китайцы. Хотя могли бы носиться как с квантовыми компьютерами.