| 1.1, leap42 (ok), 10:16, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +11 +/– |
 а почему на Rust? заходим в репо, видим что 57% кода это язык ассемблера. а кроме этих двух ещё есть Shell и Python.
| | |
| |
| |
| 3.31, коржик (?), 13:24, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы построчно считаете? Сколько ассемблерных инструкций в одной строке раста?
| | |
| 3.57, Андрей (??), 15:48, 09/02/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
Интересно, сколько там rust-строк (безопасных), а сколько в unsafe-блоках.
| | |
|
| 2.6, proninyaroslav (ok), 10:48, 09/02/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Ну и что? На асме (20 файлов) вынесены только платформо-зависимые вещи вроде SSE инструкций, т.е те участки кода, которые критичны ко времени выполнения и должны быть эффективными. Остальные 111 файлов написаны на расте, т.е вся логика кодировщика.
| | |
| |
| 3.9, mommy (?), 11:24, 09/02/2020 [^] [^^] [^^^] [ответить]
| –5 +/– |
Тоесть асмный код эффективный а раст это мусор? Ну я так и знал
| | |
| |
| 4.17, Аноним (17), 12:07, 09/02/2020 [^] [^^] [^^^] [ответить]
| +15 +/– |
А раст "безопасный". Безопасно вызвать асм код это особое искусство!
| | |
| 4.26, proninyaroslav (ok), 12:30, 09/02/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
Асм эффективнее любого существующего языка. Конечно, в большинстве случаев компилятор сам умеет генерировать эффективный асм, но компилятор не всемогущ и не всегда предсказуем, особенно когда это касается спец-наборов инструкций типа SIMD/SSE/MMX. Их часто пишут вручную.
| | |
| |
| 5.39, A.Stahl (ok), 14:12, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Дык человек-то ещё менее всемогущ и предсказуем, особенно когда это касается спец-наборов инструкций типа SIMD/SSE/MMX.
| | |
| |
| 6.41, proninyaroslav (ok), 14:21, 09/02/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Дык человек-то ещё менее всемогущ и предсказуем, особенно когда это касается спец-наборов
> инструкций типа SIMD/SSE/MMX.
То есть вы хотите сказать что компилятор абсолютно всегда знает где применять SIMD, при этом не нарушая семантику программы, а программист, который знает с какими данными он работает и что хочет получить в итоге, используя SIMD, нет)? Ну тогда вы изобрели ИИ для компилятора, программисты в таком случае и не нужны (как и сами языки).
| | |
| |
| 7.76, Анонимиус (??), 19:17, 09/02/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
На самом деле вы недооцениваете компиляторы, и переоцениваете человека. Как правило компиляторы С/С++ при должной квалификации программиста генерируют довольно хороший код, а код, написанный на ассемблере человекм, далеко не всегда работает заметно быстрее сгенерированного
| | |
| |
| 8.115, VEG (ok), 11:31, 10/02/2020 [^] [^^] [^^^] [ответить] | +1 +/– |  Вы переоцениваете компиляторы В любом оптимизированном кодеке будет много ассем... текст свёрнут, показать | | |
|
| 7.104, виндотролль (ok), 03:47, 10/02/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Ну тогда вы изобрели ИИ для компилятора
Не обязательно ИИ. Обширный набор эвристик, теория отимизации графов и прочие умные штуки (в которых мало кто разбирается) справляются хорошо.
А если перенести компиляцию в финальное представление в рантайм (JIT), где у компилятора есть возможность "почувствовать" данные, то вообще удивительные вещи происходят.
| | |
| |
| 8.116, VEG (ok), 11:37, 10/02/2020 [^] [^^] [^^^] [ответить] | –1 +/– | Ага, именно поэтому все самые быстрые кодеки всегда на низкоуровневых C Rust с к... текст свёрнут, показать | | |
|
|
|
|
| 4.89, Аноним (89), 22:17, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
асмный код - это различная реализация одних и тех же процедур для разных платформ.
Отдельные реализации для ARM32, ARM64, x86_64. Соответственно, один бинарник использует только часть кода, который относится только к платформе этого бинарника
Код на Rust - один для всех платформ.
Конечно, если у вас есть 3 версии реализации одного и того же - это у вас будет занимать больше места.
Асмный код по кол-ву строк тоже больше места занимает зачастую, чем аналогичные операции на C/Rust/etc.
| | |
| 4.121, Аноним (121), 13:10, 10/02/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Покажите хотя бы один компилятор, который делает автоматическую оптимизацию в SIMD-инструкции?
(Нет, vector extensions, которые идентичны написанию на асме, не считаются).
| | |
|
| 3.87, Аноним (87), 20:34, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> На асме (20 файлов) ... должны быть эффективными. Остальные 111 файлов написаны на расте
Т.е. чтобы вызывать функции из 20-ти файлов на асме, требуется 111 неэффективных файлов на расте?!
| | |
|
| 2.32, Аноним (32), 13:31, 09/02/2020 [^] [^^] [^^^] [ответить]
| –4 +/– | |
>а почему на Rust? заходим в репо, видим что 57% кода это язык ассемблера.
А потому, что Rust он же безопасный и в указатели на нём низзя-низзя, моветон. Поэтому на ассемблере.
| | |
| 2.37, Аноним (37), 14:06, 09/02/2020 [^] [^^] [^^^] [ответить]
| +10 +/– | |
Забавно то, что в декодере dav1d, написанном на С, аналогичная картина.
Assembly 57.6%
C 41.4%
Other 1.0%
| | |
|
| |
| 2.5, leap42 (ok), 10:41, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
в Rust ничего плохого, просто проект в основном на ассемблере написан, а не на грибе (на нём видимо обвязка)
| | |
| 2.11, segesg (?), 11:27, 09/02/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
Вокруг раста слишком много хайпа, многие не понимают сильных сторон этого языка. Зато понимают что язык сложный (это правда), особенно после питона и джава(скрипта), вот и "критикуют".
| | |
| |
| 3.13, Аноним (4), 11:36, 09/02/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ну вообще, конечно, управление памятью без сборщика мусора всегда было мечтой низкоуровнего программирования. И пусть, конечно, от unsafe не избавиться, но по крайней мере всех скелетов может запереть там
| | |
| |
| 4.74, Аноним (74), 19:11, 09/02/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
В том, собственно, и смысл. На плюсах просто начать писать, но научиться писать на них нормальный надежный код - задача не одного года обучения. Семантика Rust по сути форсит ряд практик безопасной разработки на C/C++ по умолчанию. В итоге начать хоть что-то писать на Rust сложнее (потому что всякая дичь, которую человек может написать особенно после привычки к GC, просто не будет компилироваться), но вот начать писать на нем вменяемый код легче.
| | |
| |
| 5.83, proninyaroslav (ok), 20:22, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я имел ввиду что некоторые тоже хейтят C++ за свою сложность, но продолжают писать и изучать. В случае раста "неосилил" приравнивается к отказу использовать его, ибо не отправдал надежд, и яростно хейтить за это. Просто многие из мира языков со сборкой мусора (довольно большая часть аудитории, которая инетерсуется растом) не понимают что языки с ручным или полуавтоматическим управлением памятью априори сложны, и новый модный язык не будет проще старомодного.
| | |
|
|
|
| 2.28, нах. (?), 13:04, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | в самом rust может и ничего особенно плохого хотя лично мне идея кажется феерич... большой текст свёрнут, показать | | |
| |
| 3.46, Илья (??), 14:52, 09/02/2020 [^] [^^] [^^^] [ответить]
| +6 +/– | |
> ...хруст, ...мурзилой, ...адептами, ...хрустеры
Человек даже свой жаргон ненависти придумал. Читаю и радуюсь.
| | |
| |
| 4.47, нах. (?), 15:00, 09/02/2020 [^] [^^] [^^^] [ответить]
| –4 +/– | |
видимо, более сложные слова разбирать для тебя - задача невыполнимая, альтернативно-одаренный?
| | |
| 4.75, Аноним (74), 19:15, 09/02/2020 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> жаргон ненависти
Последствия любого упоминания Rust здесь мне напоминают двухминутку ненависти из 1984.
| | |
|
| 3.49, Аноним (4), 15:03, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Я, конечно, сам тоже скептик переписывания, но по-вашему никакого нового кода взамен существующего писать не надо, да?
> еще один бесполезный кодировщик бесполезного формата
Для вас бесполезного, а для кого-то может и нет, зачем же так категорично говорить
| | |
| |
| 4.52, нах. (?), 15:32, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | Если никакого _нового_ кода, не взамен существующего, не появилось на значительн... большой текст свёрнут, показать | | |
| |
| 5.64, Аноним (4), 16:57, 09/02/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Это не особо хорошо, да Хотя если честно, я все равно не пойму такой силы напа... большой текст свёрнут, показать | | |
| |
| 6.69, нах. (?), 17:24, 09/02/2020 [^] [^^] [^^^] [ответить] | –1 +/– | ну потому что задолбали уже всех белки-истерички, рассказывающие о том, как всем... большой текст свёрнут, показать | | |
| |
| 7.73, Аноним (74), 18:54, 09/02/2020 [^] [^^] [^^^] [ответить]
| +11 +/– | |
> ну потому что задолбали уже всех белки-истерички, рассказывающие о том, как всем настанет щщастье от переписывания на хруст. А щастья все нет и нет.
Как минимум, на opennet редко кто врывается и что-то рассказывает про Rust. Здесь просто потоки ненависти в сторону Rust и все. Выдумали себе "сектантов" и воюете с ними.
Rust не дает абсолютную безопасность. Я соглашусь, что это во многом маркетинговый лозунг. Но Rust дает семантику, благодаря которой ты думаешь о безопасности только тогда, когда об этом нужно думать (а это менее 1% времени разработки), а не постоянно. Помимо этого он исправляет гору накопившихся проблем других языков путем внедрения накопившихся достижений функциональных языков (нет null, нет наследования типов, нет эксепшенов, нарушающих поток управления, но есть алгебраические типы, трейты, бесплатные итераторы и т.д.). Плюс к этому вокруг языка складывается современная удобная экосистема (единая система сборки, легкость в создании документации, тесты из коробки, причем тестируются даже примеры кода в доке и т.д).
Никто не заставляет вас писать на Rust. Но хейтеры здесь почему-то выглядят как человек из той шутки: "я догнал вас только чтобы сказать, как вы мне безразличны". Пишут себе люди на Rust и пишут - вам какое дело? Если язык действительно плох, то пропадет и без вашей ненависти.
| | |
| 7.79, Аноним (4), 19:45, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
Как же нам тогда писать софт с меньшим числом досадных багов и уязвимостей? И какова судьба Си?
| | |
| |
| 8.81, Аноним (74), 19:56, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | Я достаточно изучил местную аудиторию, так что наверняка предложенные вам вариан... текст свёрнут, показать | | |
|
| 7.131, коржик (?), 20:10, 10/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Он метил в замены C++ - а там, в общем-то, никто не мешает писать правильно.
Как я не догадался?
> Но, по-моему, идея была в том, чтобы заменить не язык, а дорогих программистов на нем - дешевыми.
Конечно, если разработчик сможет абстрагироваться от мелких, но назойливых проблем, то у него будет больше времени на продукт? Это плохо?
| | |
| |
| 8.139, нах. (?), 10:32, 11/02/2020 [^] [^^] [^^^] [ответить] | –2 +/– | у него будет больше времени на тяп-ляп Это плохо Управление памятью не являетс... текст свёрнут, показать | | |
|
|
|
| 5.153, Obito (ok), 13:44, 22/03/2020 [^] [^^] [^^^] [ответить] | +/– |  Это какое же у вас железо то У меня вот например воспроизводит 1080р на i5-2520... большой текст свёрнут, показать | | |
|
|
| 3.86, proninyaroslav (ok), 20:31, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> ради _переписывания_ _уже_существующего_ кода
Это болезнь любого нового (или не очень) языка. Язык просто ищет применение, а те кто изучает его ищут на чём попрактиковаться, так как коммерческая сторона этим языком либо не заинтересована, либо только в процессе прощупывания. Бывают, конечно, и фанатики которые хотят что всё вокруг было написано на их любимом языке (JS в том числе).
Раст находится где то около процесса прощупывания и уже сейчас можно увидеть в т.ч brand new софт, который пилится гуглом, майкрософтом и некоторыми другими мелкими компаниями или сообществом.
| | |
| |
| 4.88, нах. (?), 22:16, 09/02/2020 [^] [^^] [^^^] [ответить] | +1 +/– | нет Это новоизобретение именно модных-современных язычков Повторяю _все_ что ... большой текст свёрнут, показать | | |
| |
| 5.93, proninyaroslav (ok), 22:36, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Ну, хоть и раст изначально разрабатывался без определённой прикладной цели, но через 2 года он всё таки попал под крыло мозиллы и применение было сразу найдено - как безопасную замену плюсам с уклоном в функциональное программирование и системой сборки/переиспользования кода из коробки. Думаю, это достаточный повод иметь данный язык, хотя бы как альтернативу монополии плюсов.
Тот же Го изначально разрабатывался в академическом кругу Plan 9 в виде языков Limbo и Newsqueak (причём они более развиты чем их наследник), но потом этот круг попал под крыло к гуглу, что дало шанс этим языкам в виде Го.
| | |
| 5.94, Аноним (74), 22:47, 09/02/2020 [^] [^^] [^^^] [ответить] | +2 +/– | Откуда вы это берете Если это действительно просто троллинг, то прямо слишком т... большой текст свёрнут, показать | | |
| |
| 6.114, нах. (?), 10:49, 10/02/2020 [^] [^^] [^^^] [ответить] | –1 +/– | дружище, мы эти сказочки про дело-небыстрое слушаем уже лет семь, кажется В это... большой текст свёрнут, показать | | |
| |
| 7.117, Аноним (117), 12:40, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | У гугла подход простой 1 Перекупить ключевых разрабов у других компаний напо... большой текст свёрнут, показать | | |
| |
| 8.120, нах. (?), 13:04, 10/02/2020 [^] [^^] [^^^] [ответить] | –1 +/– | почему нет-то Они не хотели работать затак Они хотели работать за мало бабла ... большой текст свёрнут, показать | | |
| |
| 9.125, Аноним (117), 14:07, 10/02/2020 [^] [^^] [^^^] [ответить] | +1 +/– | почему нет-то c Спорно Проекты на Rust нередко обходят по производительности... большой текст свёрнут, показать | | |
|
|
|
|
| 5.106, Аноним (4), 04:52, 10/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> так было с Си
А вот и нет, Юникс был в начале на асме написан. А уж потом придумали Си и переписали на Си, и оказалось эффективнее и надежнее
| | |
| |
| 6.108, нах. (?), 07:14, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | то что было написано на асме- было примитивным монитором, с тремя командами ls c... большой текст свёрнут, показать | | |
|
| 5.107, Аноним (4), 04:54, 10/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> И только поколение миленниалов додумалось до идеи "сперва изобретем нескучный язычок, потом начнем "искать применения", авось найдутся".
Как будто это просто очередной язычок, а про компайл-тайм гарантии безопасности вы забываете.
| | |
|
|
| 3.98, имя (ok), 00:20, 10/02/2020 [^] [^^] [^^^] [ответить] | +2 +/– |  Ага, особенно Страуструп, писавший инновационную и нанотехнологичную 8230 науч... большой текст свёрнут, показать | | |
| |
| 4.109, нах. (?), 07:29, 10/02/2020 [^] [^^] [^^^] [ответить] | –1 +/– | afair, cfront использовался для какой-то вполне осмысленной деятельности, пусть ... большой текст свёрнут, показать | | |
| |
| 5.122, имя (ok), 13:25, 10/02/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
> чтобы считать что от замены на хруст хоть что-то улучшилось, именно.
> А количество cve каждый месяц почему-то по прежнему не меняется.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+css
За два года всего два разрыва, и те не use-after-free, как раньше пачками находили, а логические ошибки. Но ты продолжай верить, что это всё было зря.
> Хромог и йож обходятся без хруста, и тормозят меньше.
Смешно пошутил! Спасибо, нет, даже за вычетом прожорливости по памяти до сих пор у blink-браузеров с этим полный провал. Но у меня и вкладок поболе пятидесяти будет.
> то еще какой хренью заниматься вместо работы?
Вот тут соглашусь, впрочем: больно смотреть на все эти бесполезные коммиты про WebVR, WebAR, WebGPU и прочие GamepadAPI.
| | |
| |
| 6.123, нах. (?), 13:49, 10/02/2020 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> За два года всего два разрыва,
А остальные не отнесли к css.
Я просто смотрю на release notes шерстяного с очередным "а эти двадцатьпятьштук - нас не
касаются//исправлены два года назад". Хватило одного программиста вместо сорока смузихлебов.
И да, вкладок у меня открыто сильно поболее пятидесяти - правда, у шерстяных, в отличие от некоторых, браузер не разучился их не загружать, пока не попросят.
А новая-модная мурзила на этом "старье" просто не работает. Никак.
| | |
|
|
|
|
|
| 1.12, Аноним (12), 11:30, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Истина всегда где-то рядом. Важен лишь продуктивный симбиоз для решения конкретной задачи, а не крайности. Слесарный молоток - отличный инструмент, но мясо лучше отбивать кухонным. Таков путь!
| | |
| 1.15, Аноним (15), 12:00, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я тут недавно выяснил, что для h264 минимальный битрейт порядка 10000kbps на 1080p, иначе получается сплошное мыло. Можно уменьшить, но на практике это так. Т.е все эти файлы — сплошной мусор. Стандартно рекомендуют что-то вроде 1080p : 4Mbps to 6Mbps, но это ни о чём, 6000 хватит разве что h265. Если ~2000 нужно только для 360p, эти значения очень занижены.
Впрочем, можно проще, crf выставить в 17 (для h264, дефолт 23), 18 примерно минимальным для хоть какого-то качества. Для h265 crf минимум 21 (дефолт 27). Иначе на файлы можно смотреть только с расстояния в 10 метров.
Это всё, кстати, подтверждается разного рода исследованиями в сети. Есть ли такие сравнения для сабжа? Кто-нибудь уже догадался прогнать файлы под каким-нибудь vmaf? Сравнить с h265, наконец?
| | |
| |
| 2.20, Аноним (17), 12:10, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Кто уже догадался что в качестве разных кодировщиков нет никакой разницы и не стал ничего проводить.
| | |
| |
| 3.24, Аноним (15), 12:18, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Я могу сказать, что на 360p h265 битрейт ~300kbps равен ~1000kbps h264. И h265~400kbps соотносится с h264~1500kbps (что-то в районе). Т.е. разница есть, и она очень велика и заметна невооружённым глазом.
пс. Чтобы получить достаточное качество на h265~300kbps ещё и придётся потвикать параметры, какие, я конечно же не скажу.
| | |
| |
| 4.29, нах. (?), 13:06, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> пс. Чтобы получить достаточное качество на h265~300kbps ещё и придётся потвикать параметры
а заниматься тем же самым для h264 тебе было не с руки, поэтому и получили что получили.
| | |
| |
| 5.30, Аноним (15), 13:17, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> пс. Чтобы получить достаточное качество на h265~300kbps ещё и придётся потвикать параметры
> а заниматься тем же самым для h264 тебе было не с руки,
> поэтому и получили что получили.
Визуально качество очень сильно отличается. Я твикал на предмет удобоваримой скорости кодирования и отсутствия специфических артефактов-глитчей, они особенно проявляются на низком битрейте. У h264 сразу лезут артефакты картинки без всяких глитчей. Визуальная разница между самыми медленными пресетами опять же есть и без всяких твиков.
| | |
| |
| 6.33, нах. (?), 13:34, 09/02/2020 [^] [^^] [^^^] [ответить] | +2 +/– | разница вполне может быть вызвана тем, что самый медленный пресет все равно тв... большой текст свёрнут, показать | | |
| |
| 7.36, Аноним (15), 14:06, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | Да не, x265 уделывает x264 целиком и полностью Особенно, на низком битрейте бр... большой текст свёрнут, показать | | |
| |
| 8.53, нах. (?), 15:39, 09/02/2020 [^] [^^] [^^^] [ответить] | –1 +/– | пресеты не особо менялись первые лет десять А дальше я перестал следить - полаг... большой текст свёрнут, показать | | |
| |
| |
| 10.90, нах. (?), 22:26, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | ее сканировать уже нечем, к сожалению Это тебе не нескучный язык приспособить к... большой текст свёрнут, показать | | |
|
|
|
| 7.141, Thony (?), 11:10, 11/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> P.S. отдельный вопрос - а где ты берешь несжатые исходники, на которых можно оценить какое-то там качество?
Кстати, на счет этого -- для Canon существует такой твик фирмвари Magic Latern, который позволяет записывать RAW Video, каждый отдельный кадр в сыром виде как он снят с матрицы. Чистота получающегося видео просто обалденная.
| | |
|
|
|
|
|
| 2.51, Ordu (ok), 15:29, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Это всё, кстати, подтверждается разного рода исследованиями в сети.
Можно ссылочки? Мне очень методики сравнения интересны, я не понимаю как это можно делать, и было бы круто узнать.
| | |
| |
| 3.61, Аноним (15), 16:27, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Есть метрики навроде VMAF и PSNR, гуглится на раз. Насчёт информации на русском языке не уверен.
| | |
| |
| 4.68, нах. (?), 17:17, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Есть метрики навроде VMAF и PSNR, гуглится на раз. Насчёт информации на
> русском языке не уверен.
отдельный вопрос, каково их отношение к видимому глазом качеству. Гуглится это с трудом, продраться через терминологию сложно, убедительности в этих документах не ощущается.
| | |
| |
| 5.72, Аноним (15), 18:42, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | Сравнивать визуальные артефакты различных кодеков равноценно нельзя, но степень ... большой текст свёрнут, показать | | |
| |
| 6.91, нах. (?), 22:29, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Сравнивать визуальные артефакты различных кодеков равноценно нельзя, но степень отличия от
> оригинала оценить вполне можно.
дык а кому она нужна, степень эта?
Если мы их глазом либо не видим, либо видим совсем не то что этот метод считает важным.
> С PSNR, насколько я помню, проблема в том, что он артефакты считает за "детали", потеря этих
> самых "деталей" иногда более предпочтительна.
о том и речь.
А продираться через детали математики - еще одна жизнь нужна :-(
| | |
| |
| 7.95, Аноним (15), 23:19, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | Ну поэтому я просто проверяю скриптом битрейт и параметры у файлов из интернета ... большой текст свёрнут, показать | | |
| |
| |
| 9.99, Аноним (15), 00:26, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | Да, просто пока что мне ещё не попадались хорошие файлы с удалённой инфой в инте... текст свёрнут, показать | | |
|
| 8.113, нах. (?), 10:22, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | чорт, даже интересно стало - что это такое ты смотришь, что можно не смотреть ес... текст свёрнут, показать | | |
| |
| 9.126, Аноним (15), 14:53, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | Вопрос, скорее, про хранение Затем, что лучше не было, стриминговые сайты гонят... большой текст свёрнут, показать | | |
|
|
|
|
| 5.77, Ordu (ok), 19:28, 09/02/2020 [^] [^^] [^^^] [ответить] | +/– | По ссылке 1 с википедии 2 , которая заодно третья ссылка в ddg при поиске по за... большой текст свёрнут, показать | | |
| |
| 6.92, нах. (?), 22:31, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
> То есть, я бы на месте video service operator ещё бы подумал, стоит ли обращать внимание на
> рекомендацию в пункте (c).
ну вот, еще до одного дошло, что верить никому нельзя.
imho, чем тратить недели на чтение первоисточников и разбирательства деталей, проще потратить (недели же) на пробные кодирования и ручной просмотр - если мы не нетфликс, и для себя это делаем, нас интересует не его выборка, а наша собственная.
| | |
| |
| 7.110, Ordu (ok), 09:44, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | Хахаха, лол Заменить выборку из 18 человек на выборку из 1 человека, это офиген... большой текст свёрнут, показать | | |
| |
| 8.112, нах. (?), 10:17, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | естественно Мы же для этого человека делаем, а не для тех восемнадцати Иначе м... текст свёрнут, показать | | |
| |
| 9.136, Ordu (ok), 22:21, 10/02/2020 [^] [^^] [^^^] [ответить] | +/– | Да, но и потратил я на это не несколько часов, а несколько минут Ему нужен комп... текст свёрнут, показать | | |
| |
| 10.138, нах. (?), 10:25, 11/02/2020 [^] [^^] [^^^] [ответить] | +/– | ему нужно денег, и желательно - побольше Если пипл хавает дерьмо с лопаты - то ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| |
| 3.151, Аноним (15), 21:36, 14/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Это больше похоже на правду, спасибо. То стриминговые стандарты, которых все придерживаются. Тот же гугл рекомендует что-то там двух/трёхкратный запас битрейта, ему ещё транскодировать в vp9. Проблема ещё и в том, что на 6-7.5 mbps можно получить вполне достойное качество, если не экономить на параметрах кодирования (и даже me=umh сойдёт, если он subme=10 вместо 3), но все экономят. У некоторых просто нет возможности делать медленный энкод, но на практике это ведь жадные торгаши, считающие каждую копейку за электричество и максимизирующие прибыль ценой катастрофического падения качества.
Ремукс Паразитов на пиратбее fullhd@~30mbps (его не было, когда я в прошлый раз хотел посмотреть этот фильм), выглядит вполне ничего для h264.
| | |
|
| 2.145, Аноним (145), 12:00, 11/02/2020 [^] [^^] [^^^] [ответить] | +2 +/– | Ну, это очень сильно зависит от исходника и что там в нём написано, его частоты ... большой текст свёрнут, показать | | |
| |
| 3.149, Аноним (149), 22:51, 11/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Анон, откуда такие познания в предмете? Что и кого почитать чтобы стать таким же как ты?
| | |
| 3.152, Аноним (15), 22:18, 14/02/2020 [^] [^^] [^^^] [ответить] | +/– | У x265 есть pmode его, вероятно, стоит выбрать вместо pme Проблема в том, что... большой текст свёрнут, показать | | |
|
|
| 1.27, vz_2 (?), 12:44, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Какой тут безопасный и оптимизирующий компилятор, если половина кода ассемблера, хотя последний трудно назвать языком. Бедные растаманы.
| | |
| 1.34, nelson (??), 13:44, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 >> Кодировщик написан на языке Rust и отличается от эталонного кодировщика libaom значительным увеличением скорости кодирования
на реализацию которого по сути забили - https://github.com/mozilla/aom
rav1e 0.3 наполовину на асме, но увеличение производительности произошло волшебным образом при реализации логики на растишке, ага
пиар растишки - это что-то за гранью. растишка к реализации видеокодеков имеет примерно такое же отношение как околомагазинный бухарик к самой растишке. для того, чтобы этот AV1 стал пригоден к использованию, необходима банальная аппаратная реализация наиболее ресурсоёмких частей алгоритма кодирования. ЯП реализации логики здесь вообще вторичен
всё это уже проходили во времена то первых, то ли вторых пней, когда на мат. платах распаивали микросхемы кодеков по причине того, что пеньки не тянули кодировку-раскодировку видео
| | |
| |
| 2.55, нах. (?), 15:48, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> на реализацию которого по сути забили - https://github.com/mozilla/aom
а чего реализовывать-то еще? Уже все реализовано, эталон ненужно создан.
> rav1e 0.3 наполовину на асме, но увеличение производительности произошло волшебным образом
> при реализации логики на растишке, ага
интересно, в ее компиляторе хотя бы те же оптимизации что всеми скопипащены у icc - есть, или там любую подобную хрень надо писать на ассемблере?
> того, чтобы этот AV1 стал пригоден к использованию, необходима банальная аппаратная
> реализация наиболее ресурсоёмких частей алгоритма кодирования. ЯП реализации логики здесь
она бесполезна. Ты не хочешь за нее платить.
> всё это уже проходили во времена то первых, то ли вторых пней,
> когда на мат. платах распаивали микросхемы кодеков по причине того, что
> пеньки не тянули кодировку-раскодировку видео
нет, по причине того, что не было нормальных кодеков. Как только появился divX - волшебным образом те же "пеньки" стали пригодны для кодирования без всяких волшебных микросхем.
Именно по этой причине никакой av1 не взлетит, да и 265 тоже маловероятно (ну там еще прибавилась человеческая тyпость и жадность, конечно - впрочем, av1 это они же в профиль) - уже существуют и используются кодеки, позволяющие обойтись без специализированных плат в массовом сегменте, и будет крайне трудно заставить людей заплатить за то, что им не нужно.
А немассовый не окупит специализированные чипы и тем более.
При этом закон Мура действовать перестал, производительность процессоров больше не удваивается за пару лет, поэтому шансов на светлое будущее тоже не предвидится.
| | |
| |
| 3.118, крок (?), 12:47, 10/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
Кодеки были просто дорого, но вот аппаратные ускрители мпег2 стали ненужны в п2 тк там уже был ммх и все работало програмно
| | |
| |
| 4.119, нах. (?), 12:57, 10/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
да нет, в том и прикол что mpeg2 отправился на свалку истории _раньше_ "аппаратных ускорителей". divx все испортил.
| | |
| |
| 5.124, artenox (?), 14:04, 10/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
MPEG2 и по сей день лучше DivX/XviD'ов. По крайней мере, на битрейтах, на которых их обычно используют.
| | |
| |
| 6.147, Аноним (147), 19:12, 11/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вам кажется. Не в последнюю очередь потому, что в MPEG-4 ASP пережимали в т.ч. и из MPEG-2, т.е. качество могло только упасть.
| | |
|
|
|
|
|
| 1.35, Аноним (35), 13:52, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
- AV1 - требует слишком больших затрат на вычисления, а результат? Надо сравнивать конечный итог - это отношение различия изображений исходного и перекодированного к размеру выходного файла. Если выяснится что различие, составляет 1-2% в пользу AV1, а скорость в 1000 раз в пользу H264 то смысла в AV1 нет.
| | |
| |
| 2.38, Аноним (15), 14:09, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ты не понял, h264 это вообще мусор. Нужен бесплатный конкурент h265, и они пытаются его сделать. Сегодня в вебе vp9 и это адок ещё тот — он хуже h264 (который при этом лучше конкурентов своего времени).
| | |
| |
| 3.42, Аноним (42), 14:23, 09/02/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Это ты не понял. Всё незапатентованное можно запатентовать задним числом. Всё не под монополией можно подогнать под монополию. Всё общественное можно приватизировать и передать организациям связанным с гнилобергами. На любой товар и даже не на товар можно ввести налог в пользу всяких мигалкиных. Любую деятельность можно внести в перечень лицензированных.
Думать что какой-то AV1, уступающий другим кодекам, и поэтому дотпоры до времени оказавшийся не нужным, иммунен против всего вышеперечисленного, просто наивно.
| | |
| |
| 4.44, Аноним (15), 14:31, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для AV1 передали свой патентный пул различные различные заинтересованные лица. Нельзя использовать алгоритмы mpeg, всё остальное можно. Всем заинтересованным в неуплате отчислений, вступившим в сговор, использование патентов участников лицензировано на "свободной" основе. Надо уже придумать что-то своё, а не пользоваться алгоритмами 100 летней давности.
| | |
|
|
| 2.80, Аноним (80), 19:46, 09/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> различие, составляет 1-2% в пользу AV1
При кодировании с использованием libaom выигрыш по объёму относительно x264 получается весьма значительным, порядка 50%. Вдобавок, не вполне корректно сравнивать голые цифры PSNR и SSIM: подобно тому, как визуальное качество H.264 на голову опередило H.263 за счёт применения деблокинга на стороне декодера, AV1 ещё на одну голову выше за счёт сглаживания линий (CDEF), что позволяет даже на низких битрейтах не портить надписи и прочие контуры, чем страдают все кодеки предыдущих поколений.
| | |
| 2.143, Аноним (143), 11:17, 11/02/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
C H26x проблема - оно покрыто лицензионными ограничениями вдоль и поперёк.
| | |
|
| 1.40, Аноним (42), 14:15, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>заметно опережает H.264
А что с h.265 и h.266 (патентасты идут лесом, в большинстве государств алгоритмы непатентуемы, а США и Япония - ССЗБ)?
| | |
| |
| 2.43, Аноним (15), 14:24, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Все норм железки делают в Японии. Сга — основной рынок, в том числе для Китая. Пол мира сотрудничает с Сга во всём. Куда деваться?
Если h266 будет принципиально и фактически превосходить av1 (пытающегося конкурировать с h265), то av1 окажется в роли сегодняшнего vp8.
| | |
| |
| 3.58, нах. (?), 15:52, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Все норм железки делают в Японии.
даже жаль, что их никто не покупает, да?
> Если h266 будет принципиально и фактически превосходить av1 (пытающегося конкурировать
> с h265), то av1 окажется в роли сегодняшнего vp8.
не окажется. Сегодняшний vp8 (в отличие от бесполезного 9, как раз "нашего ответа h265") - бытовой кодек. Доступен каждому васяну без дополнительных затрат, и будет воспроизводиться у любого другого васяна - тоже без дополнительных затрат.
| | |
| |
| 4.60, Аноним (15), 16:17, 09/02/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
"Бытовой" подразумевает в первую очередь бытовое применение. Т.е. h265 на сегодня _самый_ лучший и _самый_ бытовой на свете, а vp8/9 получили распространение только и исключительно от нежелания гугла платить роялти и способности того влиять на веб стандарты. И если предыдущая история mpeg по сей день нас чему-то учит, h266 ждёт такой же тотальный успех.
>никто не покупает
Вообще-то покупают, вон и память приличная до недавнего времени только заводами в Японии производилась, т.е. компоненты. И оптика, и аудио-аппаратура. В Китае просто дешевле и логистика уже построена, остальные производители понесли соответствующий урон с тех пор, как оказалось, что Китай не только мусор гнать способен.
| | |
| |
| 5.67, нах. (?), 17:15, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> "Бытовой" подразумевает в первую очередь бытовое применение.
берем любую "бытовую" видео-камеру - там-тадам - h264 либо в .mov, либо в .mp4
Без вариантов.
Берем не совсем бытовую не совсем видео, где, казалось бы, могут уже не экономить копеек: https://www.dpreview.com/reviews/panasonic-lumix-dc-s1h-review ($4k - такая вот бытовая техника) - опять h264 и очень опционально - 265 - и это модель которая только-только до прилавков добралась (хз кто ЭТО покупает), выберешь на год старше - будет только 264.
Потому что a) стандартные алгоритмы в стандартных корпусах b) а в общем-то и не надо никому ничего другого, и у всех уже есть софт для работы с h264.
Перспективы av1, непригодного ни для просмотра ни для монтажа без спецускорителей, которых еще и нет в природе - на этом фоне выглядят не то что туманно, а вообще никак.
> Вообще-то покупают, вон и память приличная до недавнего времени только заводами в Японии
> производилась, т.е. компоненты.
именно что "компоненты". И покупает их - китай. Провести вторичную отбраковку и распаять на модули - в Японии слишком дорого, результат никому окажется за те деньги не нужен.
Ну и как-то между делом постепенно выясняется, что и компоненты незачем возить из Японии, их китайцы из песка и сами способны гнать потоком. Качеством, как обычно, похуже, ценой на рупь дешевле, потребители довольны до усеру.
| | |
| |
| 6.154, Obito (ok), 13:58, 22/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Перспективы av1, непригодного ни для просмотра ни для монтажа без спецускорителей
Да что у вас за железо то? У меня спокойно работает 1080р 30 фпс на проце i5-2520m, 60 фпс уже не все видосы работают. С процом, поддерживающим AVX2, скорость декодирования на 50% больше. Плюс уже есть мобильные процы с аппаратным ускорением AV1, поддерживающие минимум 4к 30 кадров.
А зачем его использовать для монтажа вообще не понятно, экспортировать видео можно в любой другой формат. AV1 сделан для интернета, а не для того чтобы какой-то Вася свои ролики в него пережимал и выкладывал на ютуб или в соц сети. То есть av1 должен использоваться соц сетями и всеми, кто пережимает видео и youtube уже использует av1, нетфликс тоже говорит про av1.
Ни в каких камерах и фотоаппаратах av1 не нужен вообще, в камерах то h265 нормально не работает, а h264 заметно хуже чем можно получить с x264. У меня 2 телефона с разным железом, и у них с h265 хуже качество чем с h264 и это при одинаковом битрейте, не получается нормально реализовать h265 на таком железе.
Так что av1 - это узко специализированный кодек и нужен он только тем, кто имеет свои сайты с видео, другим он не нужен!
| | |
|
|
|
|
|
| |
| 2.70, нах. (?), 17:27, 09/02/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Че там, в огнелисе теперь будет нормальное гпу ускорение?
конечно нет. все деньги потрачены на чудо-кодек.
| | |
| 2.85, Аноним (42), 20:31, 09/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
Да, будет GPU-ускорение. Ненормальное, небезопасное, но если хотите пользоваться сайтами, то придётся им дать доступ к GPU.
| | |
| |
| 3.111, Аноним (87), 09:49, 10/02/2020 [^] [^^] [^^^] [ответить]
| +/– |
т.е. можно ещё лет 10 поспать, а потом они начнут останки FF на dust переписывать, изобретая AV100500, который в миллион раз медленнее x264, но жмёт на 0.001% сильнее.
| | |
|
|
| 1.142, Аноним (143), 11:16, 11/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Две строчки обвязки вокруг мнемоник ассемблера - но зато ОНОЖЕНАХРУСТЕ!!!111
| | |
| 1.150, Аноним (150), 22:54, 11/02/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Rust же ради безопасности, стоило ли так заморачиваться, что написать другу половину кода на самом небезопасном языке
| | |
|
