Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Это файл /var/www/reinfo.php.
Задача в кроне на выполнение этого файла:
0,2,4,6,8,10,13,15,17,19,21,23,25,27,29, 31,33,35-36,38,40,42,44,46,48,50,52,54,56,58 * * * * php /var/www/reinfo.php
Никогда не понимал зачем нужны 10часовые версии.
Для тех кто не осилил loop в плеере?
Но самое печальное что современные кодеки до сих пор не научились сжимать такие вот последовательности. То есть для них нет разницы - десяток фильмов или повторяющийся с небольшим интервалом набор кадров.
Очевидно, для этого надо пересмотреть весь поток. Найти схожести, потом как-то закодировать.
Представляю себе, ffmpeg смотрит сериал про Хауса, и те серии, которые ему понравились, кодирует лучше.
> Для тех кто не осилил loop в плеере?
А на ютубе он есть?
> Но самое печальное что современные кодеки до сих пор не научились сжимать такие вот последовательности.
Ну дык lookahead на две минуты для кодека будет непосильной ношей...
Lookahead будет непосильной задачей для кодера, а не для декодера. Т. е. искать одинаковые сцены в имеющемся фильме, чтобы его сжать, непосильный труд. А для создания десятичасовой версии циклы расставляются вручную, а декодеру останется только сделать seek на нужный кадр.
> декодеру останется только сделать seek на нужный кадр
Ага. Сделать seek в http потоке. Т.е. с неплохой вероятностью скачать все это заново, если старые кадры дропались для экономии памяти/диска...
>Lookahead будет непосильной задачей для кодера, а не для декодера.
Это задача для программиста энкодера. Чтобы не получить квадратную питушню, для любителей exhaustive search.
А для этого существует алгоритмика. Нам ведь не нужно искать все дубликаты кадров, нам нужно только найти хотя бы одно совпадение, ведь повторяющаяся последовательность не меньше пары секунд (100-200 кадров в определённом порядке).
Или сериалов с одинаковым опенингом.
Вообще я изначально думал почему такую фичу не сделали в аудио (припевы, тындц-тындц в электронщине).
Там ведь объемы данных на порядок меньше, чем в видео.
А не слишком ли дофига получится Фурье и всяческих аудио-хешей?
Кроме того, это если только чистый какой-нибудь транс кодировать, а припевы могут различаться исполнением. Даже в том же трансе чуть-чуть частота изменилась - и всё, алгоритм сосёт лесом.
>чуть-чуть частота изменилась - и всё, алгоритм сосёт лесом.
Подход стандартный: мы ссылаемся на предсказание похожего семпла, а кодируем дифф. Компенсация движения кстати так и работает.
Вообще центральная идея всех современных кодеков - prediction+residual.
И если техника огрубления(квантование) остатков после DCT и энтропийного сжатия арифметическим кодером практически неизменна, то новые способы приближённого предсказания собственно и улучшают сжатие.
> повторяющийся с небольшим интервалом набор кадров
Вроде бы в мпег4 можно описать такую структуру, там же формат довольно навороченный, со всякими объектами, иерархиями и прочей херотой. Но придется ее генерить самому программно, а не обычной процедурой сжатия.
>> повторяющийся с небольшим интервалом набор кадров
>Вроде бы в мпег4 можно описать такую структуру
Вроде бы еще в формате GIF можно было описать такое.
А ваще забавно...
Да и вообще - зачем этому скрипту крон, он и сам неплохо справится...
Прям как название игры или фильма 😉
Для тех кто не осилил loop в плеере?
Но самое печальное что современные кодеки до сих пор не научились сжимать такие вот последовательности. То есть для них нет разницы - десяток фильмов или повторяющийся с небольшим интервалом набор кадров.
Представляю себе, ffmpeg смотрит сериал про Хауса, и те серии, которые ему понравились, кодирует лучше.
2pass encoding очень популярен.
Нихера. Даже Иемпель-Зив умудряется жать в один проход.
А на ютубе он есть?
> Но самое печальное что современные кодеки до сих пор не научились сжимать такие вот последовательности.
Ну дык lookahead на две минуты для кодека будет непосильной ношей...
Спасибо, кэп. Но где я написал про декодер?!
Ага. Сделать seek в http потоке. Т.е. с неплохой вероятностью скачать все это заново, если старые кадры дропались для экономии памяти/диска...
Это задача для программиста энкодера. Чтобы не получить квадратную питушню, для любителей exhaustive search.
А для этого существует алгоритмика. Нам ведь не нужно искать все дубликаты кадров, нам нужно только найти хотя бы одно совпадение, ведь повторяющаяся последовательность не меньше пары секунд (100-200 кадров в определённом порядке).
Вообще я изначально думал почему такую фичу не сделали в аудио (припевы, тындц-тындц в электронщине).
Там ведь объемы данных на порядок меньше, чем в видео.
P.S. Ну правда ее руками составляли из модулей, а не кодек детектировал...
Почти всю музыку составляют руками из нот и семплов (и ртом озвучивают)
Кроме того, это если только чистый какой-нибудь транс кодировать, а припевы могут различаться исполнением. Даже в том же трансе чуть-чуть частота изменилась - и всё, алгоритм сосёт лесом.
Подход стандартный: мы ссылаемся на предсказание похожего семпла, а кодируем дифф. Компенсация движения кстати так и работает.
Вообще центральная идея всех современных кодеков - prediction+residual.
И если техника огрубления(квантование) остатков после DCT и энтропийного сжатия арифметическим кодером практически неизменна, то новые способы приближённого предсказания собственно и улучшают сжатие.
Вроде бы в мпег4 можно описать такую структуру, там же формат довольно навороченный, со всякими объектами, иерархиями и прочей херотой. Но придется ее генерить самому программно, а не обычной процедурой сжатия.
>Вроде бы в мпег4 можно описать такую структуру
Вроде бы еще в формате GIF можно было описать такое.