Комментарии 71
Почему-то на огрызке ни VP9 ни AV1 не показывает. И браузер вроде обновлен
Там же пишут о возможных причинах:
Hence they didn't support VP9 to push everyone to HEVC, so they make money from HEVC licensing
А HEVC это упомянутый в статье H.265
Ну, в принципе, можно и в H.265 дополнительно кодировать по той же схеме, которая показана в статье. Но актуально это будет, вероятно, только для яблока.
Samsung так же за HEVC
Про длительность кодирования тактично умолчим?)
Хотел бы я быть таким веб-разработчиком...) С момента отправки моего комментария ffmpeg на моём i5-4210U накодировал всего 7 секунд av1-видео
Да, скопипастил команды из поста без изменений (кроме имён файлов) — speed=0.00321x :)
Правда, я не обнаружил ссылки на обрезанный оригинал, а обрезать самому лень, так что в качестве оригинала пришлось взять то же самое av1-видео из поста — возможно, это повлияло на чистоту эксперимента, хотя не думаю
В будущем появятся аппаратные решения для кодирования/ декодирования.
В будущем, это вы про 10-20 лет говорите? Когда появятся энтропийно оптимальные кодеки и будет активно развиваться квантовое сжатие? Шучу, но частично)
Всё таки даже x264 не кодируется аппаратно так же хорошо, как на CPU: на том же битрейте качество довольно сильно проседает. В будущем AV1 либо заменят на нейросетевые аналоги с теоретическим восстановлением сигнала, что сведёт крайне сложную математику к не менее сложной, но намного более типичной. Ну или же на GPU подвезут тройную точность, во что я правда совершенно не верю с учётом совеременной тенденции к максимальной экономии: скорее мы увидим 4-битовые операции, чем 96 и тем более 128 битовые.
Сколько контента люди, которые собственно создают контент, могут нормально экспортировать с VP9/AV1 кодеком? А сколько с H.265?Собственно «весь» — в обоих случаях. Создание контента — недешёвая процедура.
Если же вы о тех, кто захватывает и пережимает всякие Blu-Ray… ну если у них возникнут проблемы — я не думаю что хоть кто-то из участников консорциума, разрабатывающего AV1 обидится…
А видя с какой скоростью идёт поддержка даже H265, у меня есть большие сомнения, что AV1 будет какой-бы то ни было альтернативой в ближайшие лет так 5, а то и все 10.Что значит «идёт поддержка даже H265»? Нет этой поддержки — и не будет. Не потому что, что это сложно сделать, а потому что это нафиг никому не надо: продажа железяки с H265-энкодером это такое минное поле из патентов, что никто, кроме, по большому счёту, Apple просто не рискует туда заходить.
AV1, собственно, и начали создавать потому что стало понятно, что H265 никуда не взлетит…
Новые интелы могут кодировать в VP9.
Даже некоторые мобильные процессоры поддерживают encoding VP9.
И если вы не знаете, Nvidia и Intel руководящие члены aom, значит они участвуют в разработке av1, значит аппаратная поддержка может появиться быстрее чем у того же H265.
Дополнение
Я даже не знаю зачем делать экспорт сразу в h264 или h265, если можно сделать экспорт в кодек без потерь и потом нормально закодировать.
С моими видосами выходило что premier pro экспортирует в h264 с качеством примерно как у x264 veryfast, но при этом делает это в 2 раза медленнее.
Соответственно смысла экспортировать в h264 нет никакого.
H265 я даже не смотрел так-как premier pro экспортирует в него очень долго по сравнению с x265.
А NVENC он конечно хорош, но только когда нет ограничений по битрейту и можно спокойно поставить битрейт на 20-30% выше.
Если к моменту релизаА к моменту какого релиза? Релиз AV1 был больше года назад. Какой ещё релиз будет?
зачем мне сначала создавать файл гигов на 30, а потом его кодировать ещё раз?Чтобы сильнее сжать, сами же говорите про лимиты на vimeo.
А теперь представьте, что ваше очень «долго» будет длится в несколько тысяч! раз дольшеНе в несколько тысяч раз! В коментарии ниже написано что в 658.5 раз дольше чем VP9.
Ну и к тому же не обязательно использовать libaom, есть rav1e который кодирует в 5-8 раз быстрее. Вот и выходит что дольше всего в 130-82 раза. А rav1e сейчас только версии 0.1, возможно он станет ещё в 2-4 раза быстрее к версии 1.0
Если поддержки этого добра нет в софте (даже не говоря про железное ускорение) – для видео индустрии этого, считай, не существует.Что-то гуглу это никак не мешает. Конечно если вы выкладываете видео на ютуб, vimeo или ещё куда-то, то вам в принципе фиолетово какой кодек использовать(а ютубу пофиг даже на битрейт видео). А если у вас свой сайт и вы оплачиваете трафик, то сожмёте даже если это в 100 раз дольше.
Я повторюсь, в среде тех, кто делает видео контент, или его монтируетТак то кодек и не для них делался. Этот кодек первоначально для потокового видео, а уже потом остальных до которых он дойдёт как только появятся аппаратные реализации.
никто не станет использовать никакие libaom, rav1e или что-то ещё с труднопроизносимыми названиями, что вызывается командой из терминалаА я считаю, что если человек может написать сайт, то разобраться с несколькими командами не составит труда. Ведь в статье ни слова не говорится про вашу среду «тех кто делает контент или монтирует». Статья для разработчиков сайтов.
Если нет поддержки в софте в первую очередьТак это и есть софт, да это не софт для монтажа, но всё равно же софт.
в вашем варианте кодирование будет медленнее в ~100 раз чем уже довольно медленноеЯ как-то совсем забыл про STV-AV1 от интела. Я сам не тестировал так-как нет подходящего процессора, но он может кодировать со скоростью 5.7 кадров в секуду на i9 9900k это уже сейчас примерно в 8 раз быстрее чем rav1e и примерно в 13 раз медленнее чем vp9.
Кто в здравом уме будет такое делать?Да хотя бы тот же гугл. Он же как-то перешёл на VP9 который в ~10 раз медленнее чем h264. И сейчас так же начал переходить на av1.
вот вы заливаете видео на ютуб, скажем, а они теперь решили этот ваш новомодный кодек использоватьВот только они уже несколько месяцев используют этот кодек, правда пока максимум в 720р, но всё равно. И это никак не повлияло на скорость появления видео на ютубе. Просто av1 появляется через несколько дней, а до этого используется h264 и vp9. Можете зайти на эту страницу и принудительно включить его. Но сейчас в av1 в основном видео с самыми большими числами просмотров.
Стоит оно того?Раз гугл использует сразу 3 кодека, то думаю считает что это стоит того.
когда открытость идёт в разрез с производительностью, да ещё в таких пропорциях, это не имеет никакого смыслаА что бы изменилось если бы кодек был проприетарный? Тогда он вообще был бы не нужен никому. Если вам нужно быстро, то для вас уже сейчас существуют h264 и h265 с аппаратными реализациями. Те кому это нужно, будут кодировать в av1. В любом случае наличие этого кодека лучше чем его отсутствие.
Nvidia и Intel руководящие члены aom, значит они участвуют в разработке av1, значит аппаратная поддержка может появиться быстрее чем у того же H265.
Интел обещает декодер только к концу 2020 года (в Gen 12 / Xe), а про энкодер пока даже не заикаются.
Действительно, всего-то в 5870 раз медленнее x264.
P.S. Хотя в моем динозавровом мире GIF используется для простенькой анимации, читай — анимированные смайлики или просто баннеры, вставлять в таких случаях видео — какой-то неадекват, имхо. Но для всяких новомодных «лендингов» с большим видео в топе, наверное, имеет смысл.
Заменяем сжатые без потерь изображения на lossy-видео и радуемся. Мне кажется, изначально проблема изначально не столько в бедном формате, сколько в его применении
Там на одной необходимости загнать картинку в 256 цветов потерь больше, чем от любого, самого ужасного, видеокодека.
Всегда был. Количество цветов — это не потери, сами значения кодируются LZW. Просто во времена его создания (а это 87й год, на секунду) не знали, что кому-то потребуется больше)
Сжатие же реального, существующего, источника — теряет информацию. Причём много. И даже GifSki лишь уменьшает эти потери.
То, что изначально рисовалось в 16-64-256 цветах (смайлики, например) — можно в GIF и оставить… Там это уместно вполне.
Простите мне мою неученость и ошибку на целых два года. Прошу не казнить, а помиловать :(
То, что люди тру колор в гифки запихивают, является проблемой не формата, а людей. Сама же спецификация описывает кодирование 256-цветных изображений без потерь, определение вида сжатия строгое и не подлежит обсуждению. Иначе спустя несколько лет окажется, что и PNG данные теряет, потому что 64-битный цвет в него не запихнуть "без потерь"
Иначе спустя несколько лет окажется, что и PNG данные теряет, потому что 64-битный цвет в него не запихнуть «без потерь»Не окажется. В PNG изначально предусмотрен 64-битный формат (16 бит RGB плюс альфа-канал).
Что, правда? Не знал. Ну окей, тогда через еще большее число лет при использовании N-битного цвета, где N > 64, суть особо не меняется
Да не перестанет. Сама спецификация не ущемляет цветовую палитру, она просто не знает, что существует другая. А то так можно и JPEG назвать алгоритмом со сжатием без потерь, потому что на глаз с хорошей таблицей квантования и большим разрешением потери не заметны
Однако же: вы можете разводить любую демагогию на тему «алгоритмов» и «спецификаций», но от этого GIF-артефакты с КДПВ этой статьи никуда не пропадут. А раз артефакты имеются — то это уже не «сжатые без потерь изображения», извините.
И да — спецификация предусматривает наличие в палитре 256 цветов. Чего для тех изображений, которые мы хотим показывать — не хватает…
А то так можно и JPEG назвать алгоритмом со сжатием без потерь, потому что на глаз с хорошей таблицей квантования и большим разрешением потери не заметныНу если это JPEG2000 — то вполне. Но речь не об этом. Речь о том, что в вашем исходном сообщении вы не говорить про «алгоритмы» и «форматы». И потому оно является враньём.
И я даже понимаю почему: если бы вы туда втащили «алгоритмы» и «форматы» (перешли от формата, сжимающего без потерь к форматам, сжимающим с форматами) — то эмоциональный эффект был бы утерян: ну да, был формат, теоретически, без потерь, теперь, теоретически, с потерями… ну и что? Картинка-то объективно стала меньше артефактов содержать…
Чего для тех изображений, которые мы хотим показывать — не хватает…
Ну раз не хватает, то чего формат винить? В том самом первом комментарии (в котором ничего не найти и вообще нипонятна) написал, что проблема в людях, которые зачем-то видео запихивают в гифки. Давайте их же в APNG заводить и говорить, какой он плохой, весит много. И призывать переходить с APNG на AV1 (???)
стала меньше артефактов содержать
Артефакты — это искажения, сделанные кодеком. Так как он у гифок не делает ни одной операции, потенциально приводящей к потере качества (в отличие от этих наших джипегов), то он физически не может привести к их появлению
Говоря проще — сколько бы раз мы гифку не перекодировали, мы на выходе будем получать одно и то же изображение. А какой-нибудь джипег с каждым разом будет деградировать все больше и больше, создавая артефакты, потому что в процессе перевода сырого изображения в сжатую форму совершаются те самые операции с потерей данных
Определения видов сжатий были придуманы не мной и не сегодня, зачем с ними спорить?
Хорошо если есть исходник, тогда качество будет лучше, но сжимать гиф в видео вообще плохая затея.
А гиф с дезирингом видеокодек вообще нормально не сожмёт.
При желании dither-инг можно убрать undither-ингом. Изображение становится ближе к исходному, и лучше сжимается в видео.
Ну а если у пользователя совсем старый девайс или навигатор, который видео не поддерживает вообще (что крайте маловероятно с H264), то он просто увидит GIFВот бы кто подсказал, как с современными девайсами так сделать. А то уже выбешивают сайты, которые под видом GIF отдают MP4.
Лично мне очень не нравится, когда у меня отнимают возможность свободно делать с контентом что угодно — в первую очередь сохранять себе на диск.
Да и в любом случае можно глянуть исходник в HTML и скачать видео по ссылке.
Чтобы это исправить используют т.н. HTTP Live Streaming. Плюсы: видео заранее порезано на части по несколько секунд (причем в разных качествах для разных сетей — от быстрых, до очень медленных), которые передаются браузеру в виде плейлиста со ссылками на все куски. Клиент может быстро переходить к нужному участку видео, получить возможность выбора дополнительных аудиодорожек, которые реализованы таким же образом, экономит трафик, поставив видео на паузу (грузится, скажем, 30 секунд, после чего буферизация новых «кусков» прекращается) и еще много плюсов как для мобильных клиентов, так и для соседей по дому, которые так же хотят смотреть стримы на твиче и видео в YouTube. Но минус такого решения, конечно, в том, что чтобы скачать такое видео, нужно выкачать все куски (часто отдельно — и для видео, и для аудио) и «сшить» их вместе, скажем, с помощью ffmpeg. Однако к большинству браузеров существует туча плагинов, которые умеют перехватывать HLS-трафик, к примеру, и сшивать видео в один файл на диске.
выкачать все куски (часто отдельно — и для видео, и для аудио) и «сшить» их вместе, скажем, с помощью ffmpeg
Достаточно дать ffmpeg ссылочку на плейлист и он сам скачает и склеет.
Вроде так:
ffmpeg -i https://example.org/stream.m3u8 -c copy out.mkv
Современное же видео это, кроме псевдо стриминга из обычного mp4 файла еще и
DASH
HLS
WEBRTS
Которые не получиться просто взять и сохранить в файл.
upd: нужно приучить себя обновлять страницу перед отправкой комментария — выше ответили более развернуто.
Единственная большая проблема это прозрачность. VP9(8) не работают в Сафари, к сожалению ( а айфон — наше всё ). Это решается только хитрым методом
Там, куда мы направляемся, нам не понадобятся GIFы!
Github давно зовут, но к сожалению пока не идёт что-то. :(
Очень круто! Вообще поражает скорость разработки и принятия решений во многих проектах сейчас.
Меня интересует вопрос: если я могу сейчас с условного сайта скачать GIFку и легко прикрепить на другом сайте или отправить в вк, то что делать с этим видео? Как будут реализованы такие возможности? Потому что на сайтах которые заменяют гифки на видео это превращается в гемморой
В жизни большинство вещей имеют свои плюсы и минусы. Когда вы заменяете GIF на видео, минусов чаще всего найти не получится.
К чему было это писать, если в комментариях расписали предостаточно минусов:
- Очень медленное кодирование.
- Отсутствие аппаратной и даже программной поддержки.
- Видео нельзя просто сохранить или копировать.
Обратите внимание, что в процитированном предложении говорится про видео в целом, а не конкретно про AV1.
- H.264 легко кодируется в реалтайме, libx264 достаточно оптимизирован.
- Аппаратная поддержка H.264 встроена чуть ли не в каждую кофеварку.
- В любом нормальном браузере есть пункт меню про сохранение видеофайла.
А еще мобильные браузеры идут к тому чтобы выключить автовоспроизведение даже для видео без звука…
Как веб-разработчик, вы хотите минимизировать вещи, которые пользователям нужно скачать, чтобы сайт загружался быстро. По той же причине вы минимизируете JavaScript, оптимизируйте PNG, JPEG, а иногда и конвертируете JPEG в WebP
Судя по большиству сайтов в интернетах веб-разработчики делают строго противоположное…
На Хабре продолжают выкладывать 4к-фотографии в PNG.
Ни VP9, ни AV1 не работает.
Остаёмся с «тёплым, ламповым» GIF.
Вы лет этак через 10 заглядывайте, тогда может у будет актуально… :)))
Пришло время заменить GIF на AV1 видео