Макетирование происходит не в тепличных условиях, когда есть несжатое видео и требуется сжать H.264 и H.265 и сравнить размеры. У большинства пользователей нет оборудования для создания такого видео, ограничившись видеокамерами в телефонах/фотоаппаратах или вообще получением видео из сторонних ресурсов. То есть, все имеющиеся видео у большинства людей мира - уже сжаты чем-то; и получение название кодека конкретного видео - великий белорусский рандом.

Также стоит отметить схожесть кодеков: внешнее и внутреннее предсказание. Закончилась эра, когда просто кадры сжимались с артефактами - и на этом всё. Между первым и третьим кадром сохраняется не второй кадр, а его сгенерированный аналог, - который может содержать как реальные данные (выкинуть всё лишнее, оставить разницу - и на основе первого кадра именно при проигрывании создавать второй), так и полностью сгенерированные. То есть, сжатое видео перестаёт содержать 100% именно снятой информации, изуродованной артефактами, - добавляется творчество кодека (и ИИ в будущем - если оно уже не наступило, судя по количеству фейковых фото и видео, к которым "забывают" подписать "арты нейросетей").

Пережимались видео в форматах AVI, MP4, H.264 - как попытка ещё освободить место на хостинге. Были взяты самые большие видео и 1 маленькое для кучи. Пережатие в H.265 показывает уменьшение размера файлов и в 7 раз - однако именно это и вызвало сомнения.

Используемая программа Xilisoft Video Converter Ultimate v.7.8.26 (2022) - исправила недостаток v.7.8.3 (2014): отсутствует торможение видео при старте (что приводило к рассинхрону звука и видео), ключ подходит тот же. Но программы ли баг или кодека: выбираемый битрейт при выставлении H.265 - намного меньше, чем у исходного видео (подмена числа без ведома пользователя). Да, при таком низком битрейте H.265 весит меньше H.264 с таким же заниженным битрейтом, - но получается, что H.265 выглядит хуже именно исходного H.264 (ореол артефактов у движущихся объектов). И этот ореол наблюдается у H.265, если H.264 перекодировать в H.264 и H.265 и сравнить их.

Уменьшение веса, но всё равно с серьёзной потерей качества, - уже неудача. Но проблемы на этом не заканчиваются. Частота кадров 25Гц - упала до ~12.5Гц (настолько сильно лагают движущиеся объекты). Похоже, алгоритм сбоит на Windows 7 (тупо игнорирует каждый второй кадр?), как в реалке, так и в виртуалке, - и обновление кодеков эту проблему не исправляет.

Тут уже бы и закончить. Резкое уменьшение возможности проигрывать видео на устаревших ОС (лучших, чем современные) - очень плохое решение. Это как переконвертировать ZIP-архивы в 7-Zip-архивы с максимальной компрессией: места освободится много - но все не-ИТ пользователи пойдут на хрен (выяснилось, что даже кандидатки наук могут не знать, что такое архиватор). Архивы будут не то, что не распакованы, - а даже не открыты.

Но появляется ещё 1 баг, при прокрутке видео. Алгоритмы предсказания сбиваются, и кадры из разных времён начинают наслаиваться друг на друга (иногда теряя и правильность расположения).

Из видео оценки вероятностей на шкуре Тодда Говарда - получаются такие странные кадры (которые продолжают быть искажёнными, даже после нажатия на play).

На Windows 10 также было протестировано:

- именно Xilisoft Video Converter Ultimate v.7.8.3 порождает задержку в начале видео. То есть, она нормально функционировала в Windows XP - но работает плохо в Windows 7 и новее;

- все баги кодека H.265 - воспроизвелись.

(добавлено 11.08.2025) Попробовал использовать H.265 для бросовых видео - результат тот же: выгоднее использовать H.264 с пониженным битрейтом.

(добавлено 14.09.2025) Задержка видео всё-таки имеется: заметно на длинных видео. Xilisoft Video Converter - отправляется в утиль. Значит, и пережатие в H.265 надо повторить другим софтом.

Пережатие видео без потери качества (не H.265) - было найдено.

(добавлено 14.10.2025) Программа HandBrake умеет кодировать аж в нескольких версиях H.265. Однако даже самая компактная из них, 12-битная, - получилась большая по размеру, чем кодирование на сайте выше, - опять неудача. Мало того, Windows 10 v.22H2 имеет устаревшую версию какого-то там API - и версия "NVEnc" не может быть реализована.

(добавлено 15.10.2025) Внезапно, HandBrake сжала 2.5-часовой фильм в 5 раз, используя "H.265 12-bit" ("Аванпост" - возможно, из-за большого количества тёмных сцен). Частота кадров и разрешение - одинаковые, не было замечено и усиленное размытие. Скорее всего, из-за устаревшего кодека Xvid. Надо поставить Windows 11 и потестить её детальнее.

Видео с H.265 этой программы - успешно производятся и на сайте, и на старых ОС.

Перекодировка из H.264 в H.265 - даёт всегда сильно увеличенный объём.

(добавлено 16.10.2025) Второе успешно сжатое 6-часовое видео, используя "H.265 12-bit" в Windows 10: с 1948МБ до 1074МБ. Уже в Windows 10 можно использовать данную программу для сжатия долгих фильмов. Надо поставить Windows 11 и потестить её детальнее (используя максимальный результат с "H.265 10-bit (NVEnc)"- и только потом оформить французскую HandBrake отдельным материалом.

(добавлено 02.12.2025) Попытка сжать видео для сайта с помощью HandBrake, используя кодек "H.264 10-bit", - завершилась провалом: "Video can't be played because the file is corrupt" на мобильных телефонах.

(добавлено 05.12.2025) Попытка сжать видео для сайта с помощью HandBrake, используя кодек "H.264", - завершилась успехом. С учётом того, что степень сжатия выше, чем у iLoveMP4.com, - пакетное сжатие видеофайлов, совместимых с браузерами, - достигнуто и решается в сторону HandBrake.

(добавлено 10.12.2025) У H.265 12-bit - замечено: искажение цветов (истинно чёрный - становится черноватым) и иногда странно выбирает FPS (при лимите 24 - сделал одному видео не 24 с 30, а 20). Возможно, есть интеллектуальный алгоритм, анализирующий избыточность частоты при текущих настройках сжатия. Искажение цветов - замечено только если 2 скрина из 2 разных видео объединить в 1 рисунок и пялиться на него.