https://www.opennet.ru/openforum/vsluhforumID3/132037.html После десяти месяцев разработки доступен мультимедиа-пакет FFmpeg 6.1, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60093<br> https://www.opennet.ru/openforum/vsluhforumID3/132037.html#314 Sat, 25 Nov 2023 19:57:15 GMT &gt; man mpv <br>&gt; --audio-pitch-correction=&lt;yes&#124;no&gt; <br><br>Опции при запуске не катят -- нужно запустить трек и гоняя его взад-вперед менять скорость, не меняя высоту тона. <br>Скорость нужно менять в процессе воспроизведения, используя клавиатурные комбинации, поскольку запускается mplayet из терминала. <br>Может будет достаточно в полтора раза темп уменьшить, а может в два -- это станет известно только в процессе. <br> https://www.opennet.ru/openforum/vsluhforumID3/132037.html#313 Fri, 24 Nov 2023 19:13:27 GMT &gt; На чисто человеческом уровне - AV1 вообще совсем не "MPEG4". Вот как <br>&gt; его ни рассматривай, к MPEG не относится никак. Это может добавить <br>&gt; бардака и непоняток. Когда у вас вроде MP4 - но на <br>&gt; самом деле внутри нечто не имеющее отношения к MPEG это круто. <br>&gt; Или нет.<br><br>Если не знать о противостоянии "электротехников движущихся картинок" и "альянса за отсутствие отчислений", то ничего странного не видно.<br><br>&gt; Webm в этом плане - более логичен, там несколько кодеков от более <br>&gt; менее одних и тех же затейников. И никто не занимается стандартизацией <br>&gt; туда x264/5/6/whatever. В матрешку - можно. Но это не будет "webm". <br>&gt; Так что если проигрываемость конкретной матрешки там и тут полная лотерея, <br>&gt; с webm все куда более определенно.<br>&gt; ...<br>&gt; оно игралось на всех клиентах умеющих webm. Кому <br>&gt; нужно поддержку видео которое играется с шансами 50/50. И как при <br><br>Лотереи не может быть, H.264 поддерживался лучше VP8/VP9. Под этой новостью вспоминали про оживление старых компьютеров через форсирование в https://www.opennet.ru/openforum/vsluhforumID3/132037.html#312 Fri, 24 Nov 2023 18:10:36 GMT &gt; Мой пойнт: <br>&gt; 1) Исходник от этого лучше не стал и битов в нем столько <br>&gt; сколько было, столько есть.<br>&gt; 2) Единственный реальный профит с этого маневра - задействуется более точный code <br>&gt; path энкодера, где меньше ошибок округления и проч.<br><br>TL;DR:<br>1) Нет, дизеринг в исходнике симулировал (частично сохранял) дополнительные цвета, а мы дальше после перекодирования их частично сохранили теперь уже за счёт повышения разрядности.<br>2) Это легко можно попытаться доказать через сравнение --use-16bit-internal с 10-битным кодированием. Утверждать, что плавные градиенты не связаны с двумя дополнительными битами - это бред (совсем бред).<br><br>1) А сколько в нём было битов? Ты сам пишешь, что там как будто было больше 8 бит: "как будто 1-2 бита LSB местами просто профакались при процессинге", хотя 8 бит на месте (YUV-пипетка есть как минимум в AvsPmod). Я вот сижу специально слушаю 16-битный трек с пиковым уровнем -110 дБ, то есть тоже достаю откуда-то как минимум два бита динамического диапазона.<br>Дизеринг в исход https://www.opennet.ru/openforum/vsluhforumID3/132037.html#311 Fri, 24 Nov 2023 02:55:00 GMT &gt; То было единственное возможное объяснение, почему MP4 с новыми кодеками - это <br>&gt; плохо, когда WebM с ними - это хорошо.<br><br>На чисто человеческом уровне - AV1 вообще совсем не "MPEG4". Вот как его ни рассматривай, к MPEG не относится никак. Это может добавить бардака и непоняток. Когда у вас вроде MP4 - но на самом деле внутри нечто не имеющее отношения к MPEG это круто. Или нет.<br><br>Webm в этом плане - более логичен, там несколько кодеков от более менее одних и тех же затейников. И никто не занимается стандартизацией туда x264/5/6/whatever. В матрешку - можно. Но это не будет "webm". Так что если проигрываемость конкретной матрешки там и тут полная лотерея, с webm все куда более определенно.<br><br>В чем трабл? Допустим мы декодер. И вот нам на вход MP4. Это технически BMFF, распарсить то пожалста. Но вот что он еще и играться будет - ага, ща. С webm в этом плане на стороне плеера сильно проще. И это специально. Кому надо форма играемый у 50% клиентов?!<br><br>&gt; Не слишком я ценю идею ограничений. Запрет для веба на https://www.opennet.ru/openforum/vsluhforumID3/132037.html#310 Fri, 24 Nov 2023 02:16:13 GMT &gt; Непонятно, к чему этот ответ и ведь становится всё-таки. Технически мы сделали <br>&gt; то, что требуется энкодеру. Пустота в младших битах теперь-10-битного-исходника нас не <br>&gt; волнует, пока не видно бандинга. Энкодер к этой пустоте интереса тоже не испытывает.<br><br>Мой пойнт:<br>1) Исходник от этого лучше не стал и битов в нем столько сколько было, столько есть.<br>2) Единственный реальный профит с этого маневра - задействуется более точный code path энкодера, где меньше ошибок округления и проч.<br><br>&gt; Проблема в том, что первое объясняет, почему повышение разрядности в принципе работает.<br><br>Насколько я понял из их объяснений, предсказания становятся более точными. Кодек такого плана грубо говоря пытается максимально предугадать текущий кадр из предыдущих и может быть следующих кадров, а также референсов (сие специфично для AV1/VP9). А ошибка от предсказания кодируется и передается как текущий кадр. И чем там меньше - тем лучше сжатие будет, соответственно.<br><br>В этом смысле - у 265 вроде бы нет части продвинутых преди https://www.opennet.ru/openforum/vsluhforumID3/132037.html#308 Mon, 20 Nov 2023 10:52:36 GMT &gt; AV1 в WebM как единственный вариант тоже сгодится.<br><br>* тоже не сгодится<br> https://www.opennet.ru/openforum/vsluhforumID3/132037.html#307 Mon, 20 Nov 2023 10:50:44 GMT &gt; Это очень крутое и техническое обоснование за фичу.<br><br>То было единственное возможное объяснение, почему MP4 с новыми кодеками - это плохо, когда WebM с ними - это хорошо.<br><br>&gt; Как сказать? WEBM довольно жестко специфицирован <br><br>Не слишком я ценю идею ограничений. Запрет для веба навороченных функций матрёшки, наверное, был полезен. Но остальное - нет. <br>- H.264 был запрещён для продвижения VP8.<br>- Локально, вне браузера, можно проиграть всё, что декодирует ffmpeg.<br>- Все понимают, что в MP4 для веба не надо класть Dirac или H.265. AV1 в WebM как единственный вариант тоже сгодится.<br>- Что такое MP4-плеер?<br><br>VP8 права на жизнь не имеет. Чтобы в нём получить гарантированно правильные цвета, надо в конец видео добавить настроечную таблицу, наверное - гениальная спецификация.<br><br>&gt; Это для желающих странного - мувик становится жирным аки опеннетный тролль. Может <br>&gt; тогда RAW туда завернуть - и пусть эта тля подавится?<br><br>Это синтетический пример к =&gt;<br>&gt; * обратная совместимость в том смысле, в котором к ней можн https://www.opennet.ru/openforum/vsluhforumID3/132037.html#306 Mon, 20 Nov 2023 08:49:18 GMT &gt; Ну так вход при этом LBD и от декларации иного формата пикселей <br>&gt; он не становится HBD.<br><br>Непонятно, к чему этот ответ и ведь становится всё-таки. Технически мы сделали то, что требуется энкодеру. Пустота в младших битах теперь-10-битного-исходника нас не волнует, пока не видно бандинга. Энкодер к этой пустоте интереса тоже не испытывает.<br><br>&gt; На Doom9 вроде дали устраивающее меня объяснение<br>&gt; Но если энных предикторов нет - улучшать нечего.<br><br>Проблема в том, что первое объясняет, почему повышение разрядности в принципе работает.<br>А вывод про AV1 сделан уже тобой самостоятельно и, например, не объясняет, почему от повышения разрядности в H.265 пользы меньше, чем в H.264, несмотря на более продвинутое предсказание.<br>&gt; 8-bit h.265 has higher-precision motion vectors than 8-bit h.264, so that part of the reasoning doesn't apply to x265. - https://video.stackexchange.com/a/21595<br>&gt; Do we have any evidence that 8-bit sources encode better in 10-bit than 8-bit in AV1? While that was true for H.264, it was muc https://www.opennet.ru/openforum/vsluhforumID3/132037.html#305 Sat, 18 Nov 2023 17:40:55 GMT &gt; Это потому что вас проприетарии покусали.<br><br>Это очень крутое и техническое обоснование за фичу. А играть надо плеером с форматом ехешника от justine.lol видимо. Хотя там код 1 раз как раз.<br><br>&gt; Поэтому и сочетание в примере такое - AV1 в MP4, а не H.266 в MP4 или AV1/H.266 в MKV.<br><br>Это сочетание выделяется из толпы - встретились форматы разных standard body, при том конкурирующих. Не часто такое увидишь.<br><br>&gt; Представьте, что кто-то бы заявил о недостатке обратной совместимости в MKV из-за <br>&gt; поддержки ~любых новых кодеков.<br><br>Как сказать? WEBM довольно жестко специфицирован как subset матрешки в том числе и чтобы убавить такие проблемы. И таки качая webm сюрпризов сильно меньше, хоть и фич тоже.<br><br>&gt; Вы бы возразили, что это глупое требование, и что адекватная обратная<br>&gt; совместимость заключается в такой-то совместимости между 1-4 версиями<br>&gt; спецификации матрёшки и в способности плееров не падать при виде <br>&gt; незнакомых дорожек.<br><br>Вообще, именно поэтому и сделали webm как более специфицированный частный