Чтоб использовать узоры Байера (расхваливаемые мною в предыдущем сообщении) при перекодировании нѣкоторой видеоцитаты в формат GIF, достаточно вызвать FFmpeg одной командою:
ffmpeg -hide_banner -i цитата.mkv -an -sn -lavfi "scale=-1:высота:flags=lanczos,split[src1][src2];[src1]palettegen[plt];[src2][plt]paletteuse=dither=bayer:bayer_scale=0" итог.gif
(В эту команду вмѣсто «цитата.mkv» надо подставить настоящее имя файла, содержащего исходное видео, а слово «высота» замѣнить числом пикселов, из которых будет состоять желаемая высота кадров GIF.)
Замѣтьте, что форма моей команды чуть проще, чѣмъ въ примѣрѣ от автора обзора «High quality GIF with FFmpeg», удумавшего класть палитру в файл PNG во врéменном каталоге.
Я обычно подаю такую команду много раз: сперва ≈двоичным поиском ищу ту высоту кадра, при которой файл впритирку помѣщается именно в тот предѣлъ объёма, в который приходится умѣщать его (примѣры: 40 мегабайтов в sn/ на Абучане, 25 мегабайтов на FastPic, 20 мегабайтов на Nowere, 10 мегабайтов на imgbox, 5000 kB на 410чанѣ), а затѣмъ пробую наращивать высоту кадра на один пиксел ещё минимум восемь раз (для провѣрки: не выйдет ли сжатие LZW болѣе эффективным для какого-нибудь другого взаимного расположения границ кадра и границ байеровских узоров, как раз блоками 8×8 пикселов рисующихся? — не раз и не два я видѣлъ, как с ростом высоты кадра объём файла GIF возрастает не линейно, а рѣзкими и малопредсказуемыми рывками вперёд-назад).
В том же обзоре «High quality GIF with FFmpeg» показано, какую форму принимают команды для FFmpeg в том случае, когда в формат GIF сохраняют видеофайл не цѣликомъ, а только нѣкоторую часть его.
Автор обзора также повѣдалъ (въ подраздѣлѣ «Better palettes»), что тогда же (в марте 2015 г.) он разсматривалъ и возможность дальнѣйшаго роста качества анимации за счёт придания каждому кадру новой палитры (а не одной общей палитры на весь GIF), для чего достаточно было бы прибавить 768 байтов к каждому кадру (дополнительно тратилось бы по 18432 байта на секунду такого видео, в котором 24 кадра в секунду), но столкнулся с какою-то такою погрѣшностью, силою которой яркость замерцала, перемѣняясь от кадра к кадру.
Сейчас, попробовав передать видеофильтру palettegen параметр stats_mode=single и видеофильтру paletteuse параметр new=1, я наглядно убедился: эта погрѣшность сохраняется и доныне, то есть болѣе семи лѣтъ кряду.
Но не долго — менѣе двухъ лѣтъ! — оставалась она наиболѣе досадною проблемою качества файлов GIF, создаваемых в FFmpeg. В октябре 2017 года исправление совсѣмъ другой проблемы (убивавшей прозрачность при преобразовании в GIF такого файла, который до этого содержал ужé прозрачные пикселы) достигли такими измѣненіями исходного кода, от которых неожиданно нарушилось формирование байеровских узоров именно в том случае, в котором они занимают всю площадь кадра («bayer_scale=0», как было въ моёмъ примѣрѣ записано выше). Но болѣе года никто въ мірѣ не замѣчалъ совершившейся поломки (или, быть может, не удосуживался повѣдать о ней разработчикам FFmpeg?), и только в декабре 2018 года один пользователь обнаружил и сообщил, что в этом частном случае вмѣсто байеровских узоров в FFmpeg создаётся мусор.
Этим пользователем был я.
Вы можете сейчас открыть страницу «Change in bayer dithering output in paletteuse» в багтрекере FFmpeg и увидать там, что изложение проблемы завершалося словами «Reported by user Mithgol», а затѣмъ увидать ещё, что годы ожидания исправления этой проблемы закончилися в феврале 2022 года: в код FFmpeg были внесены поправки, починившие байеровский узор.
Чего ж я замѣчаю это улучшение FFmpeg не ранѣе, чѣмъ через два месяца? По трём причинам:
① Я догадался сберечь копию FFmpeg версии 3.4.2 (ещё до поломки) и пользовался ею всякий раз, когда нужны были узоры Байера.
② Ещё въ апрѣлѣ 2020 года я упомянул и начал осваивать утилиту gifski, способную в случае нужды сохранять GIF ещё меньшего объёма (но и меньшего качества) и подбирающую новую палитру для каждого кадра.
③ В недавних новостях FFmpeg мнѣ интереснее появление поддержки для JPEG XL и для неанимированных AVIF.
ffmpeg -hide_banner -i цитата.mkv -an -sn -lavfi "scale=-1:высота:flags=lanczos,split[src1][src2];[src1]palettegen[plt];[src2][plt]paletteuse=dither=bayer:bayer_scale=0" итог.gif
(В эту команду вмѣсто «цитата.mkv» надо подставить настоящее имя файла, содержащего исходное видео, а слово «высота» замѣнить числом пикселов, из которых будет состоять желаемая высота кадров GIF.)
Замѣтьте, что форма моей команды чуть проще, чѣмъ въ примѣрѣ от автора обзора «High quality GIF with FFmpeg», удумавшего класть палитру в файл PNG во врéменном каталоге.
Я обычно подаю такую команду много раз: сперва ≈двоичным поиском ищу ту высоту кадра, при которой файл впритирку помѣщается именно в тот предѣлъ объёма, в который приходится умѣщать его (примѣры: 40 мегабайтов в sn/ на Абучане, 25 мегабайтов на FastPic, 20 мегабайтов на Nowere, 10 мегабайтов на imgbox, 5000 kB на 410чанѣ), а затѣмъ пробую наращивать высоту кадра на один пиксел ещё минимум восемь раз (для провѣрки: не выйдет ли сжатие LZW болѣе эффективным для какого-нибудь другого взаимного расположения границ кадра и границ байеровских узоров, как раз блоками 8×8 пикселов рисующихся? — не раз и не два я видѣлъ, как с ростом высоты кадра объём файла GIF возрастает не линейно, а рѣзкими и малопредсказуемыми рывками вперёд-назад).
В том же обзоре «High quality GIF with FFmpeg» показано, какую форму принимают команды для FFmpeg в том случае, когда в формат GIF сохраняют видеофайл не цѣликомъ, а только нѣкоторую часть его.
Автор обзора также повѣдалъ (въ подраздѣлѣ «Better palettes»), что тогда же (в марте 2015 г.) он разсматривалъ и возможность дальнѣйшаго роста качества анимации за счёт придания каждому кадру новой палитры (а не одной общей палитры на весь GIF), для чего достаточно было бы прибавить 768 байтов к каждому кадру (дополнительно тратилось бы по 18432 байта на секунду такого видео, в котором 24 кадра в секунду), но столкнулся с какою-то такою погрѣшностью, силою которой яркость замерцала, перемѣняясь от кадра к кадру.
Сейчас, попробовав передать видеофильтру palettegen параметр stats_mode=single и видеофильтру paletteuse параметр new=1, я наглядно убедился: эта погрѣшность сохраняется и доныне, то есть болѣе семи лѣтъ кряду.
Но не долго — менѣе двухъ лѣтъ! — оставалась она наиболѣе досадною проблемою качества файлов GIF, создаваемых в FFmpeg. В октябре 2017 года исправление совсѣмъ другой проблемы (убивавшей прозрачность при преобразовании в GIF такого файла, который до этого содержал ужé прозрачные пикселы) достигли такими измѣненіями исходного кода, от которых неожиданно нарушилось формирование байеровских узоров именно в том случае, в котором они занимают всю площадь кадра («bayer_scale=0», как было въ моёмъ примѣрѣ записано выше). Но болѣе года никто въ мірѣ не замѣчалъ совершившейся поломки (или, быть может, не удосуживался повѣдать о ней разработчикам FFmpeg?), и только в декабре 2018 года один пользователь обнаружил и сообщил, что в этом частном случае вмѣсто байеровских узоров в FFmpeg создаётся мусор.
Этим пользователем был я.
Вы можете сейчас открыть страницу «Change in bayer dithering output in paletteuse» в багтрекере FFmpeg и увидать там, что изложение проблемы завершалося словами «Reported by user Mithgol», а затѣмъ увидать ещё, что годы ожидания исправления этой проблемы закончилися в феврале 2022 года: в код FFmpeg были внесены поправки, починившие байеровский узор.
Чего ж я замѣчаю это улучшение FFmpeg не ранѣе, чѣмъ через два месяца? По трём причинам:
① Я догадался сберечь копию FFmpeg версии 3.4.2 (ещё до поломки) и пользовался ею всякий раз, когда нужны были узоры Байера.
② Ещё въ апрѣлѣ 2020 года я упомянул и начал осваивать утилиту gifski, способную в случае нужды сохранять GIF ещё меньшего объёма (но и меньшего качества) и подбирающую новую палитру для каждого кадра.
③ В недавних новостях FFmpeg мнѣ интереснее появление поддержки для JPEG XL и для неанимированных AVIF.