На домашнем роутере файерволл тоже включён производителем "из коробки".
TP-Link продаёт или продавал с выключенным[1][2][3].
____
Ещё такие рассуждения про файрвол встретили одобрение на /r/ipv6: "For typical end user devices (modern windows, macos, android, ios) yes there's little point having a network level firewall blocking inbound traffic these days ... In fact an inbound firewall will be more of a nuisance especially with IPv6".
Или на HN: "blocking incoming connections by default is a bad habit and needs to stop".
Если выбрать противоположную точку зрения, то получится ерунда, согласно которой сторонники IPv6 отрицают отказобезопасность NAT по каким-то личным психологическим мотивам (а так они просто не считают NAT отказобезопасным, потому что не считают угрозой открытие соединений извне).
Поправка: разница в максимальных яркостях там не 200%, а целые 500%. Двести - это величина в гамма-скорректированном пространстве, для сравнения с нитами в характеристиках экранов надо отменить гамму: (200%/100%)^(2.2~2.4) ~= 500%. Если эти x5 сравнивать с 300 нитами, получится 1500 нит - идеал с точки зрения VESA (у них нет сертификатов выше DisplayHDR 1400). 1000%-с-гаммой не получить - это уже десятки тысяч нит.
Насыщенностью заката не обязательно так жертвовать.
Далее возникает вопрос — как его отобразить ...
Наводит на мысль, что есть одна конечная цель - однажды достичь вывода реального ДД в неизменном виде. Но возможность не потерять детали на фотографии и иметь запас для обработки... или HDR-рендеринг и его эффекты вроде адаптации зрения - это штуки, ценные сами по себе.
Но этот HDR имеет к настоящему такое же отношение, как доширак к итальянской пасте в мишленовском ресторане.
Наверное, его можно описать как "художественный эффект, который заставляет локальный контраст доминировать над глобальным (в т.ч. с помощью unsharp mask)".
В целом 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" гугл должен был дать конкретику о том, почему нельзя, но он выдаёт обратное: "заложена ли возможность бинарной склейки в стандарт - Вроде как заложена".
TP-Link продаёт или продавал с выключенным[1][2][3].
____
Ещё такие рассуждения про файрвол встретили одобрение на /r/ipv6: "For typical end user devices (modern windows, macos, android, ios) yes there's little point having a network level firewall blocking inbound traffic these days ... In fact an inbound firewall will be more of a nuisance especially with IPv6".
Или на HN: "blocking incoming connections by default is a bad habit and needs to stop".
Если выбрать противоположную точку зрения, то получится ерунда, согласно которой сторонники IPv6 отрицают отказобезопасность NAT по каким-то личным психологическим мотивам (а так они просто не считают NAT отказобезопасным, потому что не считают угрозой открытие соединений извне).
Всегда удивляло, что на HN (обсуждение там) в таких случаях вытаскивают из шкафа язык APL.
Поправка: разница в максимальных яркостях там не 200%, а целые 500%. Двести - это величина в гамма-скорректированном пространстве, для сравнения с нитами в характеристиках экранов надо отменить гамму:
(200%/100%)^(2.2~2.4) ~= 500%. Если эти x5 сравнивать с 300 нитами, получится 1500 нит - идеал с точки зрения VESA (у них нет сертификатов выше DisplayHDR 1400). 1000%-с-гаммой не получить - это уже десятки тысяч нит.Насыщенностью заката не обязательно так жертвовать.
Наводит на мысль, что есть одна конечная цель - однажды достичь вывода реального ДД в неизменном виде. Но возможность не потерять детали на фотографии и иметь запас для обработки... или HDR-рендеринг и его эффекты вроде адаптации зрения - это штуки, ценные сами по себе.
Наверное, его можно описать как "художественный эффект, который заставляет локальный контраст доминировать над глобальным (в т.ч. с помощью unsharp mask)".
Наоборот, повышение разрядности лишь сохраняет градиенты или помогает кодекам сжимать видео. А вот специальная гамма добавляет информацию о диапазоне яркости: либо потому что гамма привязана к абсолютной яркости (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 с недостаточным битрейтом (как на ютубе).