мне в своё время метод Замяткина как-то не очень подошёл, хотя по общим моментам согласен. Многие очень долго выбирают метод, авторов, начинают и тут же бросают, или начинают ходить на групповые курсы и там сидеть как в школе, ничего не делая за пределами класса, после чего засчитывают всё это потраченное время как за время, которое у них ушло на изучение английского, хотя на самом деле как следует они им не занимались и пары десятков часов. Если много читать, много слушать, и постоянно писать и пытаться говорить, то неизбежно повышается языковой уровень. В самом начале, после чтения двукратно пары разных учебников по английскому (не школьных) и какого-то сборника из нескольких сотен учебных текстов, мне очень сильно помогли книги по методу И. Франка, прочитал их штук 30 наверное, быстро набирая вокабуляр и привыкание к более сложным конструкциям предложений
предпочитаю простоту, потому Caddy, но собранный с модулями caddy-ipinfo-free и caddy-l4 (L4 заодно добавляю на всякий случай, хотя уже не использую функционал).
помимо смены порта так же политика обязательного обновления пароля каждые N времени считается устаревшей - если доступ по паролям, то лучше постоянный хороший пароль по памяти, нежели высокие риски того, что пароль начнут писать в Избранном в чатах или вообще на бумаге (passkey, otp, менеджер паролей и прочее известны, можете не поднимать эту тему слишком далеко)
искал среди подобных решений, для бесплатного использования небольшой организацией, из готовых к использованию NocoDB действительно подходит лучше всего, но из-за лицензии и ряда функций, доступных по подписке, опасаюсь возможного "enshittification" в ближайшем будущем.
Из перспективных и по-настоящему свободных, но к сожалению пока не готовых решений, выделяется Mathesar,
так понимаю, у них прицел на то, что для web ресурсов IP выделенный для многих пользователей и не нужен, будут давать поддомен, либо своё доменное имя можно будет привязать через DNS.
Среди множества причин такого положения дел возможным является ещё и слишком сильное психологическое ассоциированние данных на своём компьютере со своей личной головой - некое ложное подобие secondbrain, когда то, что полезно (и нередко даже необходимо) прочитать наш ленивый мозг воспринимает как тяжёлую задачу, от которой надо увильнуть, и потому поощряет закладки - "ты молодец, теперь это почти как часть наших знаний, можно сказать даже усвоено, ты ведь приложил усилие" :)
не совсем так, если оценивать соотношение масштабов человечества к производимому эффекту, то на данный момент он является наверное самым главным источником уменьшения энтропии в пределах своего проживания. На втором месте по соотношению будет жизнь как таковая в целом. Но опять же, такие оценки будут, если смотреть только локально в пределах планеты, а в рамках солнечной системы источником уменьшенной энтропии, который собственно и используется затем жизнью на планете, будет Солнце, а всё прочее в системе тогда в оценках станет тем, кто энтропию создаёт - работа (как физический термин) возможна в пределах перехода меньшей энтропии к большей.
хм, и где же самое интересное? тянет на довольно неплохую, но первую часть цикла статей скорее.
в bcachefs чрезвычайно важным отличительным функционалом является способ организации пулов хранения из многих разнообразных накопителей (там оно отличается от ssd кеша для пулов из жёстких дисков в zfs)
ещё очень интересным является вопрос возможности так организовать например работу простого массива из двух накопителей, чтобы какая-то область функционировала на уровне схожим с raid0, а другая - raid1, притом это не жёстко зафиксировано по объему (ещё со времён mdadm делать такое фиксированно банально через отдельные разделы можно было, конечно скорее для дома). btrfs например к сожалению так не умеет, хотя возможно, что архитектура позволяет реализовать, zfs тоже не умеет (zpool может только состоять из vdev собранных по разному, это плохая практика). Когда-то пробегал глазами по документации bcachefs и не помню отчего именно, но сложилось впечатление, что тут это возможно (потенциально хотя бы).
AV1 как формат сам по себе умеет и в HDR10+ и в DolbyVision, svt-av1 как заявлено, поддерживает HDR10+, но на практике реализации пока не нашёл, надежда на dovi_tool и hdr10plus_tool. Я ошибся, говоря, что AV1 кодировал в HDR10+, это проделывал с кодеком x265 (вроде), только в HDR10 (которое обычно идёт отдельным "слоем" рядом с материалом в DolbyVision)
небольшое исправление/дополнение к первому пункту, нашёл в истории bash использованную команду, matrix-coefficients был равен 9, была включена поддержка hdr, и указаны параметры mastering-display исходя из оригинала (в интернете лежит скрипт ffmpeghdr.py чтобы получить строку параметров для x265 и svt-av1):
Кодирование видеопотока (crf 18 из-за стремления сохранить максимум качества, обычно в AV1 кодирую от 20 до 28, сравнивал разницу между 18 и 19, она есть. Желательно preset делать равным 3, но у меня не очень мощный процессор, обошелся 4):
Извлёк сначала звуковую дорожку через MKVToolNix (хотя можно было и сразу), она была в 5.1(side), поэтому произвел манипуляции с порядком каналов (но тут мог и ошибиться)
Копирую видео из полученного файла на шаге 1, аудио из шага 2 и забрал субтитры из оригинального файла, сконвертировав их в формат webvtt, на выходе медиафайл в контейнере webm
через VLC сделал скриншоты в PNG, на дифчекере из-за разницы разрешений сведение до отражения отличий показывало ломаную картину. Скрин со сжатого в AV1 видео был в разрешении 2560х1439 почему-то, а скриншот с оригинального видео пришлось изменить до 2560х1440 ровно. В итоге нижняя полоска при сведении в один пиксель толщиной как разницу показывает, самый край зубов у актера, и совсем немножко на линиях между шарфом-повязкой и шеей. Нарочно подобрал кадр, где близко лицо и одежда полная деталей, там человек близко в кадре укутан чем-то, напоминающим кучу марлевых повязок, длинные растрепанные волосы.
Со слайдером я вижу ту разницу, которую говорил, в 4К было разумеется побольше деталей, которые неизбежно подрастерялись, но незначительно, при изменении размера кадра в меньшую сторону
оригинальный 3840х2160 справа, сжатый 2560х1072 слева
разница между 2560х1440 измененным скрином оригинала и 2560х1439 скрина сжатого видео
хм, а где ссылка на материалы для сравнения? недавно Дюну. Часть 1 сжал в AV1, исходник сугубо видеовидеопоток BD 4K h256 весил более 60ГБ, конвертировал в 2560 по горизонтали, сохранив HDR10+, видеопоток вышел 1.1ГБ, отличия вижу только из-за разницы в разрешении, все малейшие детали во всех сценах сохранились, ИИ из 1ГБ сможет воссоздать настолько то, что в H265 весит в 30-50 раз больше? если да, поздравляю с удачей, но всё равно не нужно, если классический способ достаточен.
у CWWK интереснее есть модель с 4x2.5Gbit, крупнее конечно размером, но пассивный теплоотвод не пример лучше и плата расширения 1хPCI-E x4 -> 4xPCI-E x1, плюс плата, которая из разъема под модуль WiFi делает ещё один m.2 PCI-E (реально вмещает 5 шт m.2 nvme 2280)
читая заголовок, сразу подумал, что конечно будет список, в котором победит handbrake, но статья с одной стороны приятно удивила вещами, о которых не знал, но внезапно ничего не написала про самый известный GUI на ffmpeg :)
мне в своё время метод Замяткина как-то не очень подошёл, хотя по общим моментам согласен. Многие очень долго выбирают метод, авторов, начинают и тут же бросают, или начинают ходить на групповые курсы и там сидеть как в школе, ничего не делая за пределами класса, после чего засчитывают всё это потраченное время как за время, которое у них ушло на изучение английского, хотя на самом деле как следует они им не занимались и пары десятков часов. Если много читать, много слушать, и постоянно писать и пытаться говорить, то неизбежно повышается языковой уровень. В самом начале, после чтения двукратно пары разных учебников по английскому (не школьных) и какого-то сборника из нескольких сотен учебных текстов, мне очень сильно помогли книги по методу И. Франка, прочитал их штук 30 наверное, быстро набирая вокабуляр и привыкание к более сложным конструкциям предложений
предпочитаю простоту, потому Caddy, но собранный с модулями caddy-ipinfo-free и caddy-l4 (L4 заодно добавляю на всякий случай, хотя уже не использую функционал).
помимо смены порта так же политика обязательного обновления пароля каждые N времени считается устаревшей - если доступ по паролям, то лучше постоянный хороший пароль по памяти, нежели высокие риски того, что пароль начнут писать в Избранном в чатах или вообще на бумаге (passkey, otp, менеджер паролей и прочее известны, можете не поднимать эту тему слишком далеко)
искал среди подобных решений, для бесплатного использования небольшой организацией, из готовых к использованию NocoDB действительно подходит лучше всего, но из-за лицензии и ряда функций, доступных по подписке, опасаюсь возможного "enshittification" в ближайшем будущем.
Из перспективных и по-настоящему свободных, но к сожалению пока не готовых решений, выделяется Mathesar,
так понимаю, у них прицел на то, что для web ресурсов IP выделенный для многих пользователей и не нужен, будут давать поддомен, либо своё доменное имя можно будет привязать через DNS.
Среди множества причин такого положения дел возможным является ещё и слишком сильное психологическое ассоциированние данных на своём компьютере со своей личной головой - некое ложное подобие secondbrain, когда то, что полезно (и нередко даже необходимо) прочитать наш ленивый мозг воспринимает как тяжёлую задачу, от которой надо увильнуть, и потому поощряет закладки - "ты молодец, теперь это почти как часть наших знаний, можно сказать даже усвоено, ты ведь приложил усилие" :)
не совсем так, если оценивать соотношение масштабов человечества к производимому эффекту, то на данный момент он является наверное самым главным источником уменьшения энтропии в пределах своего проживания. На втором месте по соотношению будет жизнь как таковая в целом. Но опять же, такие оценки будут, если смотреть только локально в пределах планеты, а в рамках солнечной системы источником уменьшенной энтропии, который собственно и используется затем жизнью на планете, будет Солнце, а всё прочее в системе тогда в оценках станет тем, кто энтропию создаёт - работа (как физический термин) возможна в пределах перехода меньшей энтропии к большей.
в смысле проблему питания, уже встроен ИБП можно сказать :D
хм, и где же самое интересное? тянет на довольно неплохую, но первую часть цикла статей скорее.
в bcachefs чрезвычайно важным отличительным функционалом является способ организации пулов хранения из многих разнообразных накопителей (там оно отличается от ssd кеша для пулов из жёстких дисков в zfs)
ещё очень интересным является вопрос возможности так организовать например работу простого массива из двух накопителей, чтобы какая-то область функционировала на уровне схожим с raid0, а другая - raid1, притом это не жёстко зафиксировано по объему (ещё со времён mdadm делать такое фиксированно банально через отдельные разделы можно было, конечно скорее для дома). btrfs например к сожалению так не умеет, хотя возможно, что архитектура позволяет реализовать, zfs тоже не умеет (zpool может только состоять из vdev собранных по разному, это плохая практика). Когда-то пробегал глазами по документации bcachefs и не помню отчего именно, но сложилось впечатление, что тут это возможно (потенциально хотя бы).
таможня примерные расценки знает и при большом расхождении от ожидаемой цены может получить выписку об оплате из банка
AV1 как формат сам по себе умеет и в HDR10+ и в DolbyVision, svt-av1 как заявлено, поддерживает HDR10+, но на практике реализации пока не нашёл, надежда на dovi_tool и hdr10plus_tool. Я ошибся, говоря, что AV1 кодировал в HDR10+, это проделывал с кодеком x265 (вроде), только в HDR10 (которое обычно идёт отдельным "слоем" рядом с материалом в DolbyVision)
небольшое исправление/дополнение к первому пункту, нашёл в истории bash использованную команду, matrix-coefficients был равен 9, была включена поддержка hdr, и указаны параметры mastering-display исходя из оригинала (в интернете лежит скрипт ffmpeghdr.py чтобы получить строку параметров для x265 и svt-av1):
:enable-hdr=1:matrix-coefficients=10:mastering-display=G(0.265,0.69)B(0.15,0.06)R(0.68,0.32)WP(0.3127,0.329)L(4000.0,0.005):content-light=1804,501Примерно так, точно не вспомню:
Кодирование видеопотока (crf 18 из-за стремления сохранить максимум качества, обычно в AV1 кодирую от 20 до 28, сравнивал разницу между 18 и 19, она есть. Желательно preset делать равным 3, но у меня не очень мощный процессор, обошелся 4):
nice -n 15 ffmpeg -i Дюна.2021.Hybrid.UHD.Blu-Ray.Remux.2160p.mkv -vf scale=2560:1072 -c:v libsvtav1 -crf 18 -preset 4 -g 120 -svtav1-params tune=0:film-grain-denoise=0:film-grain=10:enable-overlays=1:scd=1:scm=2:transfer-characteristics=16:matrix-coefficients=10:color-primaries=9 -pix_fmt yuv420p10le -an Dune_crf18_preset4_g120_grain10.mkvИзвлёк сначала звуковую дорожку через MKVToolNix (хотя можно было и сразу), она была в 5.1(side), поэтому произвел манипуляции с порядком каналов (но тут мог и ошибиться)
nice -n 15 ffmpeg -i Dune-eac3.ac3 -c:a libopus -filter:a "channelmap=FL-FL|FR-FR|FC-FC|LFE-LFE|SL-BL|SR-BR:5.1" -ac 6 -b:a 192K Dune-opus-6c-192.opusКопирую видео из полученного файла на шаге 1, аудио из шага 2 и забрал субтитры из оригинального файла, сконвертировав их в формат webvtt, на выходе медиафайл в контейнере webm
nice -n 15 ffmpeg -i Dune_crf18_preset4_g120_grain10.mkv -i Dune-opus-6c-192.opus -i Дюна.2021.Hybrid.UHD.Blu-Ray.Remux.2160p.mkv -map 0:v -c:v copy -map 1:a -c:a copy -map 2:10 -c:s webvtt Dune_av1.webmЕдинственное, можно было бы приподнять гамму сразу, очень темный фильм в оригинале кажется стал чуточку ещё темнее, притом без потери деталей.
через VLC сделал скриншоты в PNG, на дифчекере из-за разницы разрешений сведение до отражения отличий показывало ломаную картину. Скрин со сжатого в AV1 видео был в разрешении 2560х1439 почему-то, а скриншот с оригинального видео пришлось изменить до 2560х1440 ровно. В итоге нижняя полоска при сведении в один пиксель толщиной как разницу показывает, самый край зубов у актера, и совсем немножко на линиях между шарфом-повязкой и шеей. Нарочно подобрал кадр, где близко лицо и одежда полная деталей, там человек близко в кадре укутан чем-то, напоминающим кучу марлевых повязок, длинные растрепанные волосы.
Со слайдером я вижу ту разницу, которую говорил, в 4К было разумеется побольше деталей, которые неизбежно подрастерялись, но незначительно, при изменении размера кадра в меньшую сторону
хм, а где ссылка на материалы для сравнения? недавно Дюну. Часть 1 сжал в AV1, исходник сугубо видеовидеопоток BD 4K h256 весил более 60ГБ, конвертировал в 2560 по горизонтали, сохранив HDR10+, видеопоток вышел 1.1ГБ, отличия вижу только из-за разницы в разрешении, все малейшие детали во всех сценах сохранились, ИИ из 1ГБ сможет воссоздать настолько то, что в H265 весит в 30-50 раз больше? если да, поздравляю с удачей, но всё равно не нужно, если классический способ достаточен.
очевидно, что ради эргономики (здоровья) и скорости работы.
у CWWK интереснее есть модель с 4x2.5Gbit, крупнее конечно размером, но пассивный теплоотвод не пример лучше и плата расширения 1хPCI-E x4 -> 4xPCI-E x1, плюс плата, которая из разъема под модуль WiFi делает ещё один m.2 PCI-E (реально вмещает 5 шт m.2 nvme 2280)
читая заголовок, сразу подумал, что конечно будет список, в котором победит handbrake, но статья с одной стороны приятно удивила вещами, о которых не знал, но внезапно ничего не написала про самый известный GUI на ffmpeg :)
на самом деле не так страшно, они конечно не имеют огромных ресурсов, но ядро (включая 6.5) берут у Каноникал
а вы пробовали тест слепой?