[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Первые 100 сообщений]
Animapcha image [@] [?]
Тема   ( ответ в 136493)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM размером до 5000 кБ.
  • Ныне 3035 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 375
15371058284.jpg-(768.95KB, 850×1202, 1537105827687.jpg)
136493
No. 136493    
Предлагаю забанить ОПа
Развернуть все изображения
No. 136494    
Ты забанен. Прекрати постить.
No. 136495    
153710757954.webm-(3.79MB, 1280×720, ECHO 女児語で歌って踊ってみた【田?.webm)
136495
What the hell going on?
No. 136498    
153710815553.webm-(4.52MB, 1280×720, Тамплиеры! Тамплиеры! Содом.webm)
136498
На святое замахнулась их рука.
No. 136500    
153710823594.mp4-(0.98MB, 1920×1080, 1537108232895.mp4)
136500
キタ━━━(゚∀゚)━━━!!
No. 136502    
153710882729.jpg-(49.03KB, 1280×960, DltKZJvU0AAQY29_jpg:large.jpg)
136502
>>136501 Докладываю.
No. 136504    
153710900626.webm-(487.38KB, 1920×1080, Eromanga-sensei - editor's face.webm)
136504
>>136501

Анонс >>/dev/20636 был в 14:14 по московскому времени.
No. 136506    
153710941989.webm-(3.94MB, 1280×720, 1537109415301.webm)
136506
キタ━━━(゚∀゚)━━━!!
No. 136509    
153710997327.mp4-(973.05KB, 1920×1080, 1537109970982.mp4)
136509
>>136506
No. 136511    
153711170213.webm-(2.94MB, 480×360, 92e18659a06615a3f526f1e1b2bd3012.webm)
136511
Вебмы на моих Чиочанах? Это что же делается-то!
Это поэтому вчера удавалось заходить через раз и то не каждый? А когда Соус объявлял о новых фичах? Что-то я все проспал.
No. 136512    
15371123239.webm-(1.78MB, 1280×720, 1529175565206.webm)
136512
キタ━━━(゚∀゚)━━━!!
No. 136513    
153711558093.webm-(1.86MB, 640×480, a0b43f95f765aa1c63d9b9a3a45b23d0.webm)
136513
キタ━━━(゚∀゚)━━━!!
No. 136515    
153711671741.webm-(2.93MB, 512×384, 1451757862001.webm)
136515
キタ━━━(゚∀゚)━━━!!
No. 136517    
153712350625.webm-(4.88MB, 1920×1080, Спасибо за возможность вид?.webm)
136517
Спасибо администрации за внедрение возможности публикации видеозаписей.

Хотелось бы со временем и за пределами /b/ её увидеть включённою. Прежде всего анонсы аниме /a/ были бы для осеннего сезона более наглядны в форме видео.

>>136511

> Это поэтому вчера удавалось заходить через раз и то не каждый?

Нѣтъ.

> А когда Соус объявлял о новых фичах?

В видеозаписи https://www.twitch.tv/videos/310805212 на отметке 2:14:47 и далее.
No. 136518    
Иными словами, надеюсь, что упомянутые в реплике >>/d/1867 непредвиденные проблемы не возникнут.
No. 136522    
>>136517
Это же Мицгол! Скорее в машину.

https://www.youtube.com/watch?v=428IyxSfsls
No. 136525    
153713113466.webm-(4.76MB, 450×336, 1537131129882.webm)
136525
>>136515
No. 136526    
153713257474.jpg-(195.47KB, 550×600, mithgol.jpg)
136526
>>136517
No. 136527    
153713356786.webm-(1.47MB, 640×360, 1528557126642.webm)
136527
キタ━━━(゚∀゚)━━━!!
No. 136528    
>>136517
Текстовых посланий хватит.
No. 136530    
>>136517
Завидная борода.
No. 136532    
153714024497.png-(386.84KB, 400×400, 1537140243428.png)
136532
>>136530
Да разве это борода.
No. 136533    
153716378613.jpg-(72.70KB, 413×600, 1410220572.jpg)
136533
>>136493
>Предлагаю забанить ОПа
Это было смешно в первый раз, это было смешно в тридцать первый раз, но не в тридцать второй. Хватит.
No. 136548    
153717599760.webm-(3.27MB, 1920×1080, Isekai Maou to Shoukan Shoujo no Dorei Majutsu - n.webm)
136548
>>136533

Это фраза по умолчанию, генерируемая 410чаном всякий раз, когда ОП публикует картинку без сопровождающего её текста.

Если она не нравится, можно в /d/ эту фразу оспаривать обращением к администрации.
No. 136549    
153717620713.jpg-(80.39KB, 427×604, 1411047652.jpg)
136549
>>136548
Нет, это конкретный пассажир, который пытается юморить. Он еще постит этот смайлик キタ━━━(゚∀゚)━━━!! не в тему.
No. 136550    
153717812892.webm-(1.65MB, 1920×1080, Dagashi Kashi S2 - this is the famous HTML.webm)
136550
>>136549

Аналогично генерируется автоматически для пустого текста не у ОПа.

(Впрочем, если хочется поговорить с автосозданным кодом HTML, то кто я такой, чтобы мешать этому.)
No. 136551    
153717916429.jpg-(66.28KB, 430×604, 1409811540.jpg)
136551
>>136550
Знаешь, насилие, несправедливость и жестокость тоже автоматически генерируются в обществе, но это никого не оправдывает
No. 136585    
153721249648.jpg-(195.69KB, 1500×1125, Dlx-MAsU8AAscWv_jpg:large.jpg)
136585
>>136495 Интересно, ежели я эту лабуду повешу рингтоном на телефон, меня уволят из Big Fucking Corporation Obscene? Работаю в опенспейсе.
No. 136609    
>>136585
Ещё можно характерный возглас Танаки на СМС поставить.
No. 136616    
153728957253.webm-(1.15MB, 1150×396, с ней воспоминанья и рога.webm)
136616
http://410chan.org/b/arch/res/123808.html#124335
No. 136618    
>>136616
Напой еще вот это, пожалуйста:

Здесь птицы не поют,
Деревья не растут,
И только мы плечом к плечу
Врастаем в землю тут.
No. 136620    
153729293418.mp4-(4.44MB, 1064×842, 6.mp4)
136620
>>136525
No. 136624    
153729947933.webm-(3.99MB, 640×360, 1537299471178.webm)
136624
キタ━━━(゚∀゚)━━━!!
No. 136674    
153737652680.mp4-(4.74MB, 600×360, おジャ魔女あかり.mp4)
136674
Видео на Чиочане уже три дня назад как сделано, а первое видево тут только сейчас посчу пощу.
No. 136675    
153737819673.webm-(129.60KB, 1280×720, 歩美.webm)
136675
>>136674
Ваше видео не работает!
No. 136677    
>>136675
Бравзеры не могут в HEVC? Такая жалость. Больно быть web-illiterate.
No. 136679    
>>136677
Ты зачем обскурные кодеки используешь?
No. 136680    
>>136679
Из, кхм, обскурного тут только opus в mp4, его поддержка экспериментальна. А с libx265 что не так?
No. 136682    
В дополнение к >>136680.
…что не так, окромя того, что его не всё поддерживает. А в AVC и vp8 то видео в 5Mib с приемлемым качеством незапихаемо.
No. 136692    
Да что там браузеры, видюшку >>136674 даже http://www.cccp-project.net отказывается показать со звуком.
No. 136694    
153743142060.webm-(2.32MB, 1144×561, напел.webm)
136694
>>136618
No. 136695    
>>136694
Кисленько.
No. 136700    
153744434559.webm-(4.82MB, 1920×1080, кисленько.webm)
136700
>>136695
No. 136702    
15374507984.gif-(355.77KB, 480×270, 455t5.gif)
136702
>>136694
Это лучший кавер из тех что я слышал!
No. 136704    
153746341150.webm-(4.79MB, 600×360, おジャ魔女あかり.webm)
136704
>>136692
Use the mpv, Luke.

Пережал в VP9. Качество заметно хуже при движении и иногда несколько лучше при довольно статичной картинке. И ещё медленней кодирование в несколько раз. libx265 wins the battle. Но VP9 я в два прохода по среднему битрейту кодировалось и deadline best, libx265 же передавался CRF 34 и preset veryslow. Надо как-нибудь будет VP9, используя CRF прогнать. Предчувствую, libx265 всё равно лучше окажется.
No. 136706    
153746681337.mp4-(143.25KB, 408×226, woosh.mp4)
136706
>>136704
No. 136717    
153746939237.png-(128.28KB, 1280×720, StatCounter Browser Market Share Worldwide Monthly.png)
136717
>>136704

Во-первых, охотно верю, что VP9 уступает HEVC по возможностям. Тем не менее, использовать HEVC пока рано, так как поддержка невеликá.

Корпорация Microsoft (и её браузеры IE и Edge), согласно изложенному в нити https://answers.microsoft.com/en-us/insider/forum/insider_apps-insider_wmp/windows-10-hevc-playback-yes-or-no/3c1ab780-a6b2-4b77-ac0f-9faeefd4680d заявлению, поддерживает HEVC только при наличии аппаратной поддержки в компé.

Firefox и Chrome не показывают HEVC вовсе (не считая сообщений о том, что производителям некоторых моделей мобильников, оснащённых аппаратною поддержкою HEVC, довелось включить её и в мобильной версии Chrome).

Safari показывает HEVC только в системе macOS High Sierra или более новой, а iOS Safari — только в версии 11.2 или более новой.

И так как даже один только Chrome используют более половины пользователей WWW (график с сайта StatCounter прилагаю), то время HEVC ещё не пришло.

Во-вторых, если задаться вопросом о том, кто же со временем «wins the battle» (тогда, когда то время придёт), то тогда это будет, скорее всего, AV1. При сравнимом качестве VP9 и HEVC требуют битрейта больше (на несколько десятков процентов), чем AV1 (если верить изложенным по адресу http://compression.ru/video/codec_comparison/hevc_2017/MSU_HEVC_comparison_2017_P5_HQ_encoders.pdf данным из исследования МГУ имени М. В. Ломоносова). Поддержка в Chrome (с его-то половиною пользователей WWW) у AV1 есть уж, поддержка Firefox готовится в ночных сборках, а единственная проблема — дикие тормоза кодировщика и декодировщика (там уж не «медленней кодирование в несколько раз», а более чем на порядок), которых никто ещё толком не оптимизировал, потому что еле-еле сочинили proof of concept и пришли от того в необузданный восторг. Но это ничего: код открыт, так что со временем набегут оптимизаторы да оптимизируют.

В-третьих, попытка воткнуть 3 минуты 43 секунды всего-навсего в пять тыщщ килобайтов обречена на неудачу, качество такой видеозаписи пренепременно будет неприятным для глаз. (В своём стриме по адресу https://www.pscp.tv/w/1OyKAQYvyWnKb я упоминал, начиная от отметки 40:23, что считаю десять мегабайтов в минуту необходимым для хорошего качества, а пять мегабайтов в минуту — для ужé заметно не хорошего, пускай и приемлемого, качества.) Чтобы не обременять администрацию 410чана просьбами о хостинге более объёмистых файлов, в реплике >>/dev/20645 я предложил альтернативный вариант: публикатор сам заботится о хостинге своего видеофайла, а 410чан показывает его из P2P-распределённой файловой системы IPFS через гейт Cloudflare — но получил отказ >>/dev/20646 с формулировкой «тут имиджборд, а не файлообменник».

仕方がない。
No. 136731    
Тем временем, у ХимэХины новая песенка.
https://www.youtube.com/watch?v=DdqEdO4EOuU
No. 137173    
153816253136.mp4-(2.19MB, 1280×720, 埴生の宿vp9.mp4)
137173
>>136717
>wins the battle
Этот вопрос несколько сложнее. Мои опыт и эксперименты подсказывают, что эффективность кодирования при шаблонных preset’ах существенно зависит как от контента, в особенности от движения в нём, так и от желаемого качества при желаемом битрэйте.

Так libx264 заметно лучше сжимает [до 25% меньше конечный размер потока], чем libx265 и libvpx-vp9 при кодировании анимации или экранной стримоты в nearly lossless и lossless качестве, при разрешениях приблизительно равных или меньших 1280x720, при preset placebo или deadline best.

Где-то видел статеечку, где было описано примерно тоже: AVC-encoder’ы эффективнее при низких значениях CRF, в то время как HEVC-encoder’ы эффективнее при значениях значениях CRF высоких, и низких, а в особенности — крайне низких, для видео соответствующего контента и разрешения bitrate’ах. Проще говоря, одно и тоже видео эквивалентно низкого качества в HEVC может в полтора, а то и более, раза меньше весить, чем в AVC.

Полагаю, AV1 продолжит тенденцию улучшения эффективности сжатия при низком качестве и увеличит способности запихивать незапихаемое [видео с большим количеством движения и scenecut'ов длительностью 3 минуты 43 секунды всего-навсего в пять тыщщ килобайтов]. Если ему [AV1] будет суждено победить вообще во всех номинациях, то это будет классно.

Изачальные настройки libx265 вроде как имеют многие фичи [ассиметричные макроблоки, большее количество reference’ных кадров, etc.] отключенными даже при preset placebo. Включение этого всего приводит к лютому увеличению времени кодирования и паденииям программы, возможно, к увеличению эффективности сжатия. Побьёт ли AV1 HEVC_на_ultra’х — неизвестно.

Вот разница между VP9 с CRF 24, deadline best (прикреплённое видео) и libx264, level5.2, High 4:2:2, preset placebo (>>136775). Разумеется, для разных encoder’ов разные CRF подразумевают разное качество. Но подбирать сопоставимые по качеству CRF долго и сложно в конкретном случае.
No. 137349    
153843803414.mp4-(4.73MB, 640×360, 2.mp4)
137349
キタ━━━(゚∀゚)━━━!!
No. 137358    
153846524364.webm-(494.58KB, 1280×720, Unlimited Blade Works - aircraft warning lights.webm)
137358
Видюха >>137173 в видеопроигрывателе http://www.cccp-project.net отказывается работать, хотя Firefox показывает её превосходно.

С другой стороны, если использовать VP9, то отчего ж не в составе контейнера WebM (подмножества от контейнера Matroska).
No. 137433    
153857224767.mp4-(4.83MB, 480×360, FRUITS CANDY.mp4)
137433
>>137358
Оттого, что в .webm незапихаем изначальный аудиопоток, перекодирывать который не хотелось. Потому в .mp4 оно и закодированно.

CCCP, вестимо, очень строго оценивает корректность нахождения видеопотоков в контейнерах. Потому и не проигрывает.
No. 137670    
153888908953.webm-(2.88MB, 240×320, 14801.webm)
137670
キタ━━━(゚∀゚)━━━!!
No. 137932    
https://youtu.be/fxenYOQDXj4
No. 138851    
https://twitter.com/HimeTanaka_HH/status/1059747710838824960
В пятницу будет новый музыкальный видос, похоже.
No. 138868    
>>138851
https://youtu.be/mtb-qa8xvFU
No. 139139    
154283067747.jpg-(445.92KB, 850×1201, 1542830671818.jpg)
139139
キタ━━━(゚∀゚)━━━!!
No. 139519    
154474797857.gif-(2.63MB, 1920×1080, Sword Art Online - Kirito learns the truth.gif)
139519
>>136717

> Но это ничего: код открыт, так что со временем набегут оптимизаторы да оптимизируют.

И набежали, и оптимизируют — но не существующий код оптимизируют (по их мнению, горбатого могила исправит), а сочиняют собственные более шустрые кодировщик и декодировщик.

Группа VideoLAN (это которая видеопроигрыватель VLC сдѣлала) создаёт по адресу https://code.videolan.org/videolan/dav1d шустрый декодировщик. Во блогозаписи http://www.jbkempf.com/blog/post/2018/dav1d-toward-the-first-release о первом релизе его говорится, что тот быстро работает только на процессорах, поддерживающих AVX2. Поддержка более ранних форм аппаратного ускорения готовится в последующих релизах.

Более шустрый кодировщик сочиняется по адресу https://github.com/xiph/rav1e при поддержке Фонда Xiph.Org (это который аудиоформаты Vorbis и Opus и FLAC и затем ещё аудиовещальник Icecast поддерживает) на языке Rust. Пока что показывает многократный рост скорости видеокодирования, однако фиговатое качество видеорезультатов.
No. 139573    
>>139519
Это они для новых ресурсоёмких форматов декодировщик пишут?
Помню сколько в том же mpchc было декодеров видеопотока, но начал ими интересоваться когда попытался перетащить mpchc к себе на линукс, а там зелёная картинка вместо чёткого изображения. В итоге не один видео рендер не хотел работать приемлемо в пингвинах, пришлось удалить его. Пока большого разнообразия хороших видеоплееров не встречал в пингвинах.
No. 139578    
>>139573
>Это они для новых ресурсоёмких форматов декодировщик пишут?
Для нового и вычислительно тяжёлого AV1 пишут. Описанную в >>137173 он тенденцию повторяет, судя по статеечкам. Lossless у него (если верить информации по адресу https://www.texpion.com/2018/07/av1-vs-vp9-vs-avc-h264-vs-hevc-h265-1-lossless.html?m=1) и не lossless вовсе, и тот хуже (больше весит), чем то же видео, в AVC и HEVC ими закодированное. Печально это. Можно посмотреть, появилось ли что-либо интересное о AV1 у МГУ на эту тему.

Используй mpv же! Он может декодировать то, что MPC-HC нет, и делать это хорошо.
No. 139593    
154487787919.mp4-(569.49KB, 1920×1080, Eromanga-sensei - keyboard input 1.mp4)
139593
Тем временем по адресу https://forum.doom9.org/showthread.php?t=172550 обсуждение AV1 насчитывает теперь уж 1331 реплику.

Писучие, неутомимые люди.
No. 139594    
154488646254.png-(0.99MB, 1280×720, china.png)
139594
>>139593
>Писучие
Как чё скажешь иногда…
No. 139597    
>>139578
>и не lossless вовсе
Это вы о чём? Сам факт того что видео начали кодировать, перебирать и перезаписывать кадры это уже lossy compression. А время кодирования AV1 только подтверждает тот факт что видео кодируется с потерями. Вообще нужно самому взять не большое видео и попробовать перекодировать.
А что за формат pxz вот в этой таблице что по ссылке, это сырцы? Времени кодирование в AV1 занимает достаточно смотрю по таблице. Но кто сказал что если кодировщик сможет использовать все ядра процессора под полной нагрузкой, это даст прирост скорости? Сама по себе идея полной нагрузки процессора и всех ядер глупа. Такое мог придумать только гугл. Там же лослесс без потери качества и эта махина будет считать-пересчитывать бесконечно и записывать каждый кадр в AV1. Боюсь без нового метода подсчёта-записи кадров и алгоритма сжатия данных при кодировании эта технология не сможет набрать популярности. Нужен алгоритм для современного железа, который будет заниматься эффективно кодированием в разных потоках. У меня есть свои идеи и соображения по этому счёту, но делиться не спешу, вдруг у меня их сопрут, а меня лишат Нобелевской Премии по физике. Старое железо скорее всего забросят и не будут поддерживать, потому что это немного не то что нужно.
No. 139600    
15449199381.png-(1.41MB, 1280×720, mpv-shot0067.png)
139600
>>139597
Эх, чувствую bait, но всё же…

О том.
Назовём lossless [без потерь] такое кодирование с источника, при котором соответвтвующий результат декодирования бит-в-бит идентичен результату декодирования источника. Иначе таковое кодирование назовём lossy [с потерями]. Проблема с AV1 и заключается в том, что использованый теми людьми энкодер в lossless не может; он не может добиться результата абсолютно идентичного источнику. Мы не видим видим бесконечный PSNR.

>Сам факт того что видео начали кодировать, перебирать и перезаписывать кадры это уже lossy compression
Нет. Ни разу не. Ни коим образом не следует.

>А время кодирования AV1 только подтверждает тот факт что видео кодируется с потерями.
Опять же, нет. Скорее это наводит на мысли о высоких радиусах поиска движения, большом количестве разнообразных макроблоков, прочих фичах.
Можно сказать
ffmpeg -i in.mp4 -c:v libx264 -crf 0 -preset fast out.mp4
и это будет достаточно быстро и lossless (но весить будет много, скорее всего). Можно сказать
ffmpeg -i in.mp4 -c:v libx264 -crf 0 -preset placebo out.mp4
, и кодироваться будет долго, и всё же будет lossless. А ещё можно сказать
ffmpeg -i in.mp4 -c:v libx264 -crf 24 -preset placebo -x264-params "me_range=1024" out.mp4
, и кодироваться будет очень, очень и очень долго вследствие раздутого радиуса предсказания движения и алгоритма TESA, default’ного для placebo preset, но результат lossless не будет никогда, поскольку major quality [разница с источником/смотримость(психовизуальные оптимизации и прочее)] контроллер здесь — это CRF.

Также всё зависит от источника. При тех же алгоритмах, той же частоте кадров источника, том же разрешении источника, том же CRF (а возможно, и той же квантизации) на кадр в x264 какая-нибудь статичная картинка будет кодироваться в 15 раз быстрее, чем видео с большим количеством движения и scenecut’ов.

>Но кто сказал что если кодировщик сможет использовать все ядра процессора под полной нагрузкой, это даст прирост скорости?
Даст. По сравнению с тем, если бы кодировщик работал только на одном ядре одним потоком, очевидно же. Чем выше и эффективней распаралеливаемось — тем лучше. В особенности учитывая то, что значительно мощнее одно электронное ядрышко уже, наверное, не станет.

Одно дело, когда можно задействовать только 2 ядра i7, другое же дело, когда 56 ядер двух xeon’ов. Очевидно, что если задача хорошо распаралеливаема, то счастливый обладатель платиновых xeon’ов исполнит за 5 минут то, что обладатель i7 будет делать час. Чего разумеется не произойдёт, если задача распаралеливаема плохо. Поэтому, чем выше распаралеливаемость — тем лучше: можно увеличить скорость путём увеличения количества вычислительных единиц, можно в разы сократить время исполнения задачи, в ином же случае — нельзя.

>Боюсь без нового метода подсчёта-записи кадров и алгоритма сжатия данных при кодировании эта технология не сможет набрать популярности.
AV1 — открыт, за него не нужно компаниям (как за AVC некогда и HEVC) башлять патентообладателям деньги, а главное — он делает актуальную для многих задачу — эффективное по размеру видеокодирование в низком качестве — чуть ли не лучше всех. Хотя, лучше ли оно HEVC, в особенности, если дело касается среднего количества потерь и преодаления установленных на кодировщеке libx265 разработчиками ограничений, — не знаю. AV1, к тому же, поддерживает очень крупные макроблоки, что плюс для Ultra HD. Где-то видел, мол, Netflix, Youtube и прочие уже внедряют, Мицгол недавно писал, мол, в Firefox его поддержку добавят скоро (лучше бы поддержку HEVC добавили). А значит и остальные браузеры тоже не без поддержки останутся. Если крупные игроки начнут его и спользовать, то — хотя бы среди них — станет. Помешать может люто медленное кодирование.

И наверное помешает. Потому что оценивать кодировщики, мне кажется, следует не сколько по preset/эффективность(размер/качество), сколько по time/эффективность, и оценивают. Здесь в высоком и среднем качестве/сжатии иные более новые и эффективные стандарты проиграют AVC с треском. Отчего оно, в частности, повсеместно и используется до сих пор; и будет использоваться ещё, вследствие стабильности, времени/эффективности(размер/качество), всеобщей поддерживаемости и предсказуемости. Ещё следует помнить, что, скажем, CRF 24 у libvpx и libx264 — это ни разу не одинаковые значения PSNR и SSIM и ни разу не одинаковое визуальное качество.
No. 139601    
>Вообще нужно самому взять не большое видео и попробовать перекодировать.
Попробуйте же! Но обязательно почитайте, как и что на что влияет.

>У меня есть свои идеи и соображения по этому счёту, но делиться не спешу, вдруг у меня их сопрут, а меня лишат Нобелевской Премии по физике. Старое железо скорее всего забросят и не будут поддерживать, потому что это немного не то что нужно.
Очуществите их же! Но обязательно прочитайте детальнеёшие описания принципа работы существующих алгоритмов.

>>>139600
>и алгоритма TESA, default’ного для placebo preset
Здесь ошибка. дефолтно ESA.
No. 139602    
154492327328.png-(83.55KB, 256×256, firefox sinister.png)
139602
>>139600

> Мицгол недавно писал, мол, в Firefox его поддержку добавят скоро

И добавили в версии 58.

Но до сих пор она скрыта под флагом «media.av1.enabled» (надо true, по умолчанию поставлено false) на странице «about:config». Потому что тормозит.

Но обещают со временем прекращение тормозов, так как VideoLANовский движок https://code.videolan.org/videolan/dav1d всобачат внутрь Файерфокса. Когда он перестанет требовать AVX2 и начнёт поддерживать лишённые AVX2 процессоры, в том числе мобильные. (До этого времени в коде Файерфокса ведётся важная предварительная работа — например, можно посмотреть на упоминание dav1d в обосновании изменений, по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1512462 упоминаемых.)

> (лучше бы поддержку HEVC добавили)

А кто будет платить лицензионные отчисления за HEVC? — Фонд Мозиллы, что ли?

Ах-ха-ха-ха-ха!

> А значит, и остальные браузеры тоже не без поддержки останутся.

Chrome поддерживает AV1 (по умолчанию, без донастройки), начиная от версии 70. (С изменением соответствующего флага в настройках — поддерживал от версии 67.)

Но есть важный нюанс: мобильные версии Chrome и Firefox, по-видимому, пока что воздерживаются от поддержки AV1. (Ожидают появления версии dav1d для мобильников, возможно.)
No. 139604    
154492813760.png-(187.46KB, 985×715, hevc price.png)
139604
>>139602
http://www.mpegla.com/main/programs/HEVC/Documents/HEVCweb.pdf
До $25M (двадцати пяти миллионов усадолларами) в год. Н-да.
No. 139605    
154492958244.png-(34.48KB, 871×296, 2 percent.png)
139605
>>139604
https://assets.mozilla.net/annualreport/2017/mozilla-fdn-2017-fs-short-form-final-0927.pdf
Впрочем, если два процента от чистой прибыли — это $10M, то поддержку HEVC в Firefox’е они себе позволить наверняка могут.
No. 139617    
154498378291.gif-(97.30KB, 220×110, Mario_Kart_Race.gif)
139617
>>139601
>Но обязательно прочитайте детальнеёшие описания принципа работы существующих алгоритмов.
Но тогда это будет повторение уже того что было. Гораздо интереснее изобретать велосипед с нуля.
>56 ядер двух xeon’ов
Повесить всю систему, а с ней кучу других систем и сервисов, пока не закончиться перекодировка в AV1, как-то не очень идея.
Ни разу не пробовал ставить -crf 0 , такого наверное нет в AV1. В vp9 же значение 4 минимум, насколько помню. При перекодировке всё равно будет потеря качества по цветовой модели, незначительно в меньшую сторону. Значит нужно улучшить метод сжатия crf, пускай целое 0 и в процентах сотнях тысячных подсчитывается недостача качества вычисляется. Хотя и тут не уверен что удастся полностью сделать lossless. Раз работает как улитка декодер, то пускай ещё медленнее ползёт, ему это уже не навредит. Это скорей к его плюсам ещё плюс.
No. 139621    
154498960984.png-(2.22MB, 1920×1080, mpv-shot0240.png)
139621
>>139617
>Гораздо интереснее изобретать велосипед с нуля.
Правда, в таком случае вы рискуете собрать не велосипед, а нечто с 13 треугольными и 17 квадратными колёсами из антрацита, что будет работать хуже чем LZMA, Deflate и прочие алгоритмы сжатия общего назначения.

>При перекодировке всё равно будет потеря качества по цветовой модели, незначительно в меньшую сторону.
Нет.

>Повесить всю систему
Что мешает включить только 55 потоков/сделать low latency kernel/повысить nice у процесса, не понимаю. Слишком глупая придирка какая-то. Глупая намеренно при том, как и многое остальное.

CRF — не метод сжатия. Метод сжатия прежний. CRF в основном (в MPEG’окодерах) указывает вычислять квантизацию для каждого кадра такую, чтобы получилось для каждого кадра некоторое константное качество, соответствующее числу. В случае, если имеем 8 bit x264, то -crf 0 автоматически преобразуется в -cq 0 (константный квантизатор), B-frame’ы не используются, кое-что ещё также отключается за ненадобностью. У libvpx-vp9 и libx265 есть lossless mode напрямую. У используемой авторами того сравнения программы-кодировщика он также имеется, что вы бы увидели, читай вы его [сравнение] внимательней. Вот только у него [кодировщика] lossless не lossless, в отличие от.

>пускай целое 0 и в процентах сотнях тысячных подсчитывается недостача качества вычисляется
Expression is way too incoherent to be inter… Цумаранаи.
No. 139661    
154509881384.jpg-(32.64KB, 640×361, HEVC IP owners (courtesy of Jonatan Samuelsson fro.jpg)
139661
>>139605

В денежном смысле Фонд Мозиллы сможет себе позволить это, но зато не сможет позволить себе в моральном смысле такой отход от своей миссии построения открытого веба (отход был бы воспринят сторонниками как предательство: какой же это открытый веб, если создание и распространение видеоконтента не доступно для малоимущих и даже для среднезажиточных, так как потребует патентных отчислений или столкновения с перспективою суда за их неуплату).

Впрочем, по отношению к предшествующему абзацу читатель, не видящий полной картины, может задать вот какой вопрос: разве иллюстрация >>139604 не говорит нам, что MPEG LA не собирается требовать отчислений за создание и распространение видео HEVC, а только за продажу кодировщиков и декодировщиков? — ну то есть, конечно, для создания видео HEVC понадобится кодировщик, но всё же оплата его задумана MPEG LA как однократная, а не всякий раз при создании очередного видео, разве не так?

Так, да не так.

В июле нынешнего (2018) года по адресу http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Return-of-the-Codec-Wars-A-New-Hope-a-Streaming-Summer-Sequel-126339.aspx появился рассказ о том, что обладатели так называемой интеллектуальной собственности, имеющей отношение к HEVC, объединены не в один патентный пул (MPEG LA), а в три разных или почти разных (ещё HEVC Advance и Velos Media), а также включают десятка полтора организаций, в патентные пулы не входящих.

Там прилагалась ещё наглядная картинка (которую любезно предоставил Jonatan Samuelsson из Divideon), но она в настоящее время по адресу https://dzceab466r34n.cloudfront.net/Images/ArticleImages/InlineImages/116970-Codec-Wars-3-ORG.jpg не отображается (появляется сообщение «Access Denied»), так что для наглядности я прилагаю её копию из Архива Интернета.

И далее там рассказывалось, что позиции обладателей интеллектуальной собственности различны — грубо говоря, они различаются уровнем жадности.

Если патентный пул MPEG LA с самого начала решил не требовать content royalties (отчисления за создание и распространение видео HEVC), то пул HEVC Advance тянул-тянул да и пришёл к этому решению только недавно (в марте 2018 года), а участники патентного пула Velos Media вообще систематически отказывались и отказываются¹ обозначить свою позицию на протяжении пяти лет кряду, что автор статьи http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Return-of-the-Codec-Wars-A-New-Hope-a-Streaming-Summer-Sequel-126339.aspx истолковывает как указание на их намерение всё же получать content royalties: каждому понятно, что эта форма патентных отчислений — один из сильнейших возможных недостатков видеоформата, так что желающие избавить видеоформат от неё могли бы так и сделать, публично отказавшись от content royalties по примеру MPEG LA и HEVC Advance. (Может быть, они даже нарочно создают неясность, чтобы затем воспользоваться ею и начать сборы content royalties с принесения ритуальной жертвы, засудив да разорив для острастки первого же такого видеопроизводителя, который сочтёт их молчание знáком согласия и начнёт производство HEVC без уплаты отчислений им.)

Но даже если вам удалось прийти к выводу, что платить за видеоролики поштучно вам не придётся ни одному из трёх патентных пулов, то тогда желаю удачи в выяснении отдельной и независимой позиции BlackBerry, CISCO, Nokia, Huawei, Broadcom, Technicolor, Intel, InterDigital, Disney, Canon, Fraunhofer, NICT, KDDI, AT&T и Корпорации Microsoft по этому вопросу.

Ну или желаю удачи в молитвах о том, чтобы всё же пришёл наконец the Alliance for Open Media (AOMedia), и выкатил AV1, и тем закопал HEVC, потому что уровень жадности создателей видеоформата HEVC равносилен его мёртворождённости.

________

¹ Положение дел «отказывались и отказываются» относится к июлю 2018 года, когда статья http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Return-of-the-Codec-Wars-A-New-Hope-a-Streaming-Summer-Sequel-126339.aspx была опубликована. Если с тех пор положение дел изменилось, прошу сообщить.
No. 139687    
154515755538.jpg-(370.63KB, 739×907, 658d279526ba13dac505d57829de6c54.jpg)
139687
Мы теперь онеме? https://youtu.be/OIoZrftDKhc
No. 139690    
154515905214.webm-(1.44MB, 608×336, Ide_hakase.webm)
139690
Чиочан, загадай число от одного до трёх. А доктор Идо попробует отгадать!
No. 139695    
>>139687
Размахивать палками и разбираться в кодировании видео высокого качества, не соизмеримо. Хотя когда берешь в руки объект который не можешь придумать что же с ним делать и его практическое применение, придумываешь.
No. 139703    
15451976604.png-(2.18MB, 1920×1080, mpv-shot0001.png)
139703
キタ━━━(゚∀゚)━━━!!
No. 139704    
>>139690
Число загадано. Пускай отгадывает теперь.
No. 139705    
154521227441.png-(2.39MB, 1920×1080, vryt.png)
139705
>>139703

О, етить.
No. 139707    
Обувные различия — такие обувные.
No. 139709    
154524209892.jpg-(36.21KB, 394×780, 1451364948018.jpg)
139709
>>139690
Неправильный у вас доктор Идо. Вот правильный.
No. 139710    
>>139707
Вы только это замечаете? А разнопарные колготки у двух девочек, не замечаете? Это если они разнопарные... Различие имеет место быть, очень тонкая грань.
No. 139711    
>>139707
Клуб же по интересам. Кто дошёл, уже хорошо, тот и вхож.
No. 139712    
>>139703
Эта девочка внизу свалилась, потому что у неё иссякли силы, она выняла розу из зубов поставив обратно в вазу, и решила прилечь немного отдохнуть.
No. 139713    
154524372495.jpg-(32.00KB, 892×480, 3573584440989988227367.jpg)
139713
>>139705
Они не правильно используют стол и три стула.
No. 139714    
154524525971.png-(24.69KB, 211×202, fba521e01281430b58d354da40c0a71a.png)
139714
>>139709
У вас на картинке изображён шоумен, ведь у вашего доктора галстук и пояс соединены, стоит только дернуть за верёвочку и вся одежда которую мы видим спадёт.
No. 139715    
15452483578.jpg-(6.77KB, 244×207, aHR0cDovL2ltZzQuaWBn.jpg)
139715
По случаю праздника, можете меня пожалуйста научить как мне пустить субтитры поверх видеоряда в ффмпег? Читал инструкции в интернете и ничего не понял, в инструкции говорилось о том что субтитры накладываются с помощью тайминга, да ещё и одной коммандой, целым значением в сумме. Мне такой подход не понятен. Может есть простой вариант, такой же как с дополнительными аудио дорожками при переконвертации всего видеоряда? Чтобы субтитры были не в контейнере, а прямо на видеоряде снизу, вот это нужно. Спасибо.
No. 139716    
>>139715
-vf subtitles=sub.mkv
Возьмёт субтитры из контейнера.
-vf ass=sub.ass
Возьмёт внешние субтитры в формате ass
No. 139718    
>>139716
Спасибо, попробую.
No. 139722    
154527611574.mp4-(89.32KB, 1920×1080, Charlotte - grieving friends.mp4)
139722
>>139715

> Читал инструкции в интернете и ничего не понял

Догадываюсь, и небезосновательно, что это непонимание произошло оттого, что чтение надо было начинать не вообще «в Интернете», а в специальных местах его, употреблению FFmpeg посвящённых.

Первый пример: если начать чтение по адресу https://trac.ffmpeg.org/wiki/WikiStart в вики у FFmpeg, то тогда вскоре статья https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo отыскивается с исчерпывающими указаниями, и отыскивается недалёко (на расстоянии одного жмяка мышóю или тыка пальцем).

Второй пример: если начать чтение обсуждения >>/dev/17662 на 410чане, что тогда вскоре реплика >>/dev/18676 отыскивается с исчерпывающими указаниями, и отыскивается недалёко (достаточно страницу прокрутить).
No. 139723    
154527633795.png-(24.39KB, 211×202, suspicion.png)
139723
>>139714

Што.
No. 140860    
154745532464.png-(7.74KB, 90×50, faptcha_php.png)
140860
Неужели "Lemon" потерли? С какой стати?
No. 140862    
>>140860
Упоротая ютубная копирайтота.
No. 140890    
154749038034.jpg-(26.83KB, 720×480, 1190379.jpg)
140890
>>140860
>Lemon
Lemon Demon имеется в виду?
No. 140891    
154749060660.jpg-(575.17KB, 850×531, sample_d2a14267415d4179c613e501fe6c3b4a.jpg)
140891
>>140860
ШИТО?!
Слава Соусу, у него ничего не пропадет.
No. 141119    
154814131428.png-(15.70KB, 770×634, 1548062758220.png)
141119
>>136692
СССР всё. Совсем.
No. 141200    
154821763689.jpg-(110.02KB, 811×1144, морковка.jpg)
141200
Чем же теперь вместо CCCP пользоваться для просмотра аниме?
No. 141209    
>>141119
Ленин жив, ленин будет жить!
No. 141228    
>>141200
Я mpv [https://mpv.io/] использую. Можно MPC-HC [https://mpc-hc.org/] ещё.
No. 141235    
>>141228
Так в них как раз cccp-кодеки и зашиты, а их всё.
No. 141236    
>>141235
Это не значит, что всё резко перестанет работать.
МПЦ-ХЦ вообще не обновляется полтора года, но ни разу проблем с ним не было из-за этого.
39 сообщений пропущено. Показаны 100 первых сообщений.
Удалить сообщение []
Пароль  
[Mod]