А по какой причине так может быть? Что заставит браузер считать поддельный сертификат легитимным, кроме уязвимости или компрометации центра сертификации?
Злоумышленники используют поддельные SSL-сертификаты, чтобы обмануть браузер пользователя и заставить его считать веб-сайт, который подсовывает злоумышленник, легитимным.
Кадр можно выдрать с помощью того же ffmpeg (правда, у меня цвета немного гуляют почему-то, но оценить общее качество по шкале шакалов это не помешает)
Я везде просил профессионалов помочь мне со строкой для перекодирования.
И когда вас попросили озвучить конкретные требования, которым эта строка для перекодирования должна соответствовать, вы их озвучивать отказались. Неудивительно, что все мало-мальски компетентные профессионалы решили вас проигнорировать
В ветке ниже вы принципиально отказались формулировать какие-либо объективные и конкретные критерии сравнения кодеков, ограничившись абстрактными и субъективными «многовато» и «(не) вижу», так что я не вижу смысла что-либо делать, пока вы сами не прекратите свои словеса в небеса
Вы ж даже битрейт не указали, фиг знает что там у ffmpeg по умолчанию прописано
Сравнивать надо хотя бы или с одинаковым средним битрейтом (тогда предполагается, что новые кодеки будут качественнее), или с одинаковым качеством (тогда предполагается, что новые кодеки дадут меньший средний битрейт)
Ну и в любом случае повторное сжатие уже сжатого контента неизбежно приведёт к дальнейшему ухудшению качества независимо от кодека, для сравнения кодеков нужно брать изначально несжатый исходник
Зачем вы вообще открываете доступ к ним из интернета?
И что помешает злоумышленнику перехватить эти ключи и расшифровать всё?
Что-то уже вторая за сутки статья с автором который не понимает о чём пишет
А по какой причине так может быть? Что заставит браузер считать поддельный сертификат легитимным, кроме уязвимости или компрометации центра сертификации?
Ясно, автор не понимает о чём пишет
Это проблема менеджера паролей, который помещает пароль в заведомо небезопасное место, доступное потенциально недоверенным приложениям
До разработчиков API начинает доходить то, что веб-разработчики делали ещё 20 лет назад
И пароль автоматически отправляется в какой-нибудь забытый свёрнутый VNC-сеанс 🙃
И вот вы опять отказались озвучивать конкретные требования
Кадр можно выдрать с помощью того же ffmpeg (правда, у меня цвета немного гуляют почему-то, но оценить общее качество по шкале шакалов это не помешает)
Вам на всё это уже был дан ответ: просто ничего не делайте — и у вас останется исходник в максимально возможном качестве
Насколько меньший? Если 80 гигов сожмётся в 79.999 гигов — это устраивающий вас результат? Если нет, то почему?
И когда вас попросили озвучить конкретные требования, которым эта строка для перекодирования должна соответствовать, вы их озвучивать отказались. Неудивительно, что все мало-мальски компетентные профессионалы решили вас проигнорировать
А какой смысл брать I-фреймы, если зритель в основном видит P/B-фреймы, которых большинство?
В ветке ниже вы принципиально отказались формулировать какие-либо объективные и конкретные критерии сравнения кодеков, ограничившись абстрактными и субъективными «многовато» и «(не) вижу», так что я не вижу смысла что-либо делать, пока вы сами не прекратите свои словеса в небеса
Значит вы согласны в качестве такой цели взять исходник и потратить 80 гигов на свой любимый фильм.
Пока вы продолжаете предъявлять требования, которые противоречат друг другу — никакого конструктива у нас не получится
Значит вы согласны на ухудшение качества ради уменьшения размера (то есть битрейта).
Какова длительность этого любимого фильма и сколько конкретно для вас не «многовато»?
Тогда почему вы вообще что-то куда-то кодируете?
Просто ничего не делайте — и качество останется максимально возможным
Пресеты отвечают за скорость кодирования, один и тот же пресет даст абсолютно разные качества на разных битрейтах
Наличие 4К никак не отменяет того факта, что этот ваш фильм почти гарантированно является сильно сжатым (никто ж вам не даст настоящий исходник)
Вы ж даже битрейт не указали, фиг знает что там у ffmpeg по умолчанию прописано
Сравнивать надо хотя бы или с одинаковым средним битрейтом (тогда предполагается, что новые кодеки будут качественнее), или с одинаковым качеством (тогда предполагается, что новые кодеки дадут меньший средний битрейт)
Ну и в любом случае повторное сжатие уже сжатого контента неизбежно приведёт к дальнейшему ухудшению качества независимо от кодека, для сравнения кодеков нужно брать изначально несжатый исходник
TS вроде переписывают на Go, вдруг с ним получше будет
Ну и ждём добровольцев, которые перепишут LSP для остальных языков на Rust 🙃