The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимости в реализации JPEG XL из состава FFmpeg, opennews (??), 30-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


14. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –3 +/
Сообщение от Аноним (3), 30-Янв-24, 15:24 
После недавней истории с mp4 я окончательно убеждён, что ffmpeg занимаются совершенно неадекватные люди. Могут ли абсолютно невменяемые сумасшедшие (почитайте комментарии на багтрекере) писать качественный код?
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

21. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от poop (?), 30-Янв-24, 15:45 
ссылку
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от Аноним (3), 30-Янв-24, 15:51 
https://github.com/yt-dlp/yt-dlp/issues/8641

но насколько я понял всё серьёзнее и все ветки сломаны минорным обновлением, файлы битые и gpac не помог.

Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +1 +/
Сообщение от Аноним (66), 30-Янв-24, 20:08 
ffmpeg это не про качественный код, это про код, который умеет кучу всего [но с багами]. Прошу отнестись с пониманием, философски.
Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от Аноним (71), 30-Янв-24, 23:05 
И заменить нечем?
Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от Аноним (66), 31-Янв-24, 19:04 
Глобально - нет, местами - можно. Понимаешь, ffmpeg - это большое дерево кода для мукса/демукса разных контейнеров, кодирования/декодирования разных аудио и видео кодеков, вагон и тележка фильтров для трансформаций, преобразований, наложения и т.п. Где-то мощней gpac (mp4box в первую очередь), где-то MKVToolNix, что-то приятней кодировать отдельными кодеками типа lame, oggenc, x264 и т.п, обработка видео и наложение фильтров интересней в условном avisynth/vapoursynth, а может сведение футажа в nle типа DaVinci Resolve.
Но где у ffmpeg нет конкуретов в принципе - это как библиотека для сторонних приложений (видеоплееров в первую очередь). Заиметь поддержку сотни форматов, демукс контейнеров, декодирование аудио и видео, причём при всех обосрамсах, которые случаются с ffmpeg регулярно, это дорогого стоит. Ну и самое важное, что открытая модель разработки в случаи с ffmpeg реально играет сильно в плюс - регулярные багрепорты (в т.ч. регрессии), куча готовых заклинаний на том же stackoverflow и т.п.
Ответить | Правка | Наверх | Cообщить модератору

126. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от Аноним (-), 01-Фев-24, 11:14 
> Где-то мощней gpac (mp4box в первую очередь), где-то MKVToolNix, что-то приятней
> кодировать отдельными кодеками типа lame, oggenc, x264 и т.п, обработка видео
> и наложение фильтров интересней в условном avisynth/vapoursynth, а может сведение футажа
> в nle типа DaVinci Resolve.

Однако ffmpeg имеет забойное преимущество перед вон теми: на входе может быть любое что жрет ffmpeg. Попробуйте голым x264 закодировать заставку от геруев в формате bink video. А, что, лыжи резко встали на асфальт? Ffmpeg же еще и не такое суперкомбо прожует.

Т.е. в принципе его можно юзать как унивесальный "any to any" конвертер. До кучи. Ну почти. Даже для не совсем видео (e.g. audio или картинки) нехило катит. Хотите пачку .png кадров в видик? Или наоборот, разобрать в стопочку картинок? Или вот - в apng анимаху? Легко.

> Но где у ffmpeg нет конкуретов в принципе - это как библиотека
> для сторонних приложений (видеоплееров в первую очередь).

Как универсальный конвертор/ремуксер, простые операции с сегментами/времянками, добавить-убрать трек, отпроцессить технические дефекты и проч - тоже в общем то катит.

При том как транскодер он на самом деле может все то же что x264, AV1 кодеры, или кто там - ибо в современных кодеках обучен сабмитить параметры key-value либе, это ничем от родной морды либы не отличается. Кроме того что этот фронтэнд жрет дофига форматов на вход.

> случаются с ffmpeg регулярно, это дорогого стоит.

Ну так остальные не смогли даже так. И при том числе форматов и их сложности фейлы будут у кого угодно. Тем более что спеки на MP4 контейнеры это вообще весьма забавная штука.

> в плюс - регулярные багрепорты (в т.ч. регрессии), куча готовых заклинаний
> на том же stackoverflow и т.п.

Ну вон у тех господ какие-то фейлы с этим вышли, хотя патч тривиальный. А кривой таки походу гугол.

Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +2 +/
Сообщение от Аноним (85), 31-Янв-24, 02:17 
> но насколько я понял

Кажется, ты ничего не понял.

> gpac не помог

А по *твоей* ссылке написано, что помог: "A workaround I found is to use mp4box".

> файлы битые

Битые файлы отдал ютуб, их скормили ffmpeg'у, он отказался их есть ("error reading header") и ничего не поломал, т.к. он не меняет файлы in-place.

> сломали поддержку вполне валидных mp4

(не буду отвечать на все 10 твоих сообщений)
Это ложь, судя по исправлению с "Ignoring duplicate FTYP" по твоей ссылке. Стандарт про этот Box говорит "Quantity: Exactly one".

> *претензия в целом к встроенным (де)муксерам*

Я не вижу проблемы муксить отдельным инструментом (mkvtoolnix, в моём случае), потому помимо не всегда хороших муксеров в ffmpeg есть куча незаменимых инструментов. То есть незаменимых конвейерами gstreamer'а... то есть gst-launch-1.0. Либо потому что там нет нужного, либо потому что оно не задокументировано, либо потому что там адъ. Ему надо отдать должное за поддержку некоторых старых видеоформатов, за стриминг, но он не заменяет ffmpeg.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

92. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/
Сообщение от Аноним (-), 31-Янв-24, 03:56 
>> файлы битые
> Битые файлы отдал ютуб, их скормили ffmpeg'у, он отказался их есть ("error
> reading header") и ничего не поломал, т.к. он не меняет файлы in-place.

Т.е. битые файлы выдал ютуб - а хомячок предъявил ффмпегу? О времена, о нравы!

>> сломали поддержку вполне валидных mp4
> (не буду отвечать на все 10 твоих сообщений)

Модераторы, может, грохнете того придурка Аноним(3) - он был агрессивен но технически оказался полностью некомпетентен.

> Стандарт про этот Box говорит "Quantity: Exactly one".

Прикольно вы того анона его же оружием то. Ширкаррррно.

> То есть незаменимых конвейерами gstreamer'а... то есть gst-launch-1.0. Либо потому что
> там нет нужного, либо потому что оно не задокументировано, либо потому
> что там адъ.

Конвееры gstreamer - это жесть и адъ на земле. Делано инопланетянами для инопланетян. Если кому ffmpeg казался творением ящерок, gstreamer иноплаенетянин среди инопланетян.

Ответить | Правка | Наверх | Cообщить модератору

102. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/
Сообщение от Аноним (3), 31-Янв-24, 09:35 
Ну фантазируешь, видно. Файлы не битые. 20 лет было нормально собирать dash в файл, а тут стало не нормально. Ну прекрасно, что сказать.

Какие незаменимые инструменты ffmpeg ты сейчас назовёшь? Явно не кривые фильтры и никчёмные деинтерлейсеры. Программный скалер? Так тоже цветовые пространства вечно портил, искажает картинку с кучей гличей.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

107. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от Аноним (-), 31-Янв-24, 11:01 
> Ну фантазируешь, видно. Файлы не битые. 20 лет было нормально собирать dash
> в файл, а тут стало не нормально. Ну прекрасно, что сказать.

Представляешь, чувак! В онлайн сервисе владелец сервиса может в любой момент что угодно поменять со своей стороны - и ты выкусишь огурца!

Если ты не в курсе как эта штука с чанками сделана (MSE, Media Streaming Extension): JS кормит декодер браузера чанками. Где он их возьмет, как и в каком это формате будет - там вообще не регламентировано! То-есть предложен DASH, предложены некие форматы, но делать именно так - ничто имплементеров не обязывает. И если они скажем сделают самопальный формат чанков, а то и пошифруют их слегонца неочевидным ключом или там еще какая пакость - ну вот и думай что с этим блобом теперь делать, даже если ты его и ухватил. Полное решение - плеер вендора запустить. Он то знает как это до видика доделывать. Заодно и рекламу, вот, покажет.

И если гугол решил приколоться и начал выгружать "немного нестандартный" формат - это вполне может быть и вот именно их инициатива. И даже - по именно нагибанию вон тех даунлоадеров. Они изредка по@бывают автоматические даунлоадеры. У vlc например так в какой-то момент отвалился ютуб - но если ему подпихнуть апдейченый lua-скрипт из найтли версии, где определение урлы поправили на новую версию плеера ютубы - все опять работает.

> Какие незаменимые инструменты ffmpeg ты сейчас назовёшь? Явно не кривые фильтры и
> никчёмные деинтерлейсеры.

Это такой швейцарский нож с 120 лезвий что даже сложно все перечислить.
1) Продвинутого транскодирования. Он умеет выгружать всякие продвинутости как параметры кодеков для 264/AV1/etc как модное нынче "key-value api" современных кодеков.
2) Кривыми фильтрами я лично смог вытянуть несколько темных, шумных видео на которых изначально было не видно - нихрена. Но продвинутый пайплайн по мотивам "darktable" - сделал нечто достаточно смотрябельное.
3) Батч-транскодирование. В том числе с продвинутостями и/или в режиме fire and forget. Скажем я забацал себе скрипт который смотрит поворот камеры и кодирует сразу с поворотом - чтоб при декодировании проц не грузить этим постоянно.
4) Когда у знакомых хомяков сдох NTFS - и профукались все имена файлов (но их все равно вытащил photorec) - я вернул 600К файлов одупляемые имена по тегам камеры. Опять же пустил простой скриптик лукапать теги ffprobe'ом. Спасибо камерам за метаданные. Через 10 минут оно не только получило имена "как с камеры", но и по месяцам в диры было распихано, ибо 600К файлов в одной дире - не очень удобно. В линухе в принципе пашет, но в винде такая иерархия - не загрузится даже до послезавтра. Там уже при 100 000 - 150 000 файлов ждать задолбаешься. Но для этого - вот - ffprobe нужен был.
5) Им можно сделать даже что-то странное. Скажем анимированый gif/apng/webp из короткого клипа. Или мувик - из пачки картинок. Или деконструировать мувик в пачку картинок.

> Программный скалер? Так тоже цветовые пространства вечно портил,
> искажает картинку с кучей гличей.

Сейчас бы с большинством матерьяла в LBD/YUV422 каком за цветовые пространства еще эстетствовать. Мсье, вы пижон. Кодируете небось сугубо 4:4:4/HDR/не менее 10 битов и 4К? И все это вот прям gstreamer'ом? А он так умеет вообще? У него ж все минимально продвинутые кодеки или отсутствуют или BAD. Ну вот такой фэйспалмовый фреймворк.

Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +1 +/
Сообщение от Аноньимъ (ok), 31-Янв-24, 02:27 
> I am running openSUSE Tumbleweed on snapshot dated 20231121.

Опенсуса в репах тащит особую сборку ffmpeg из которой вырезано всё с "патентными проблемами".

Проиграть простое mp4 видео - проблема.
Ставишь кодек циски ииии видео идёт рывками, рассинхрон со звуком, краши.

Онлайн радио с aac потоком - проиграть невозможно.

Так что я не знаю какое отношение баг по ссылке имеет к ffmpeg вообще.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

91. Скрыто модератором  –3 +/
Сообщение от Аноним (-), 31-Янв-24, 03:52 
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от Аноним (3), 31-Янв-24, 10:17 
У меня самосборный ffmpeg, но это ровно тот же баг в ffmpeg. И по упоминаниям в обсуждении он же.
Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

108. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/
Сообщение от Аноним (-), 31-Янв-24, 11:49 
> У меня самосборный ffmpeg, но это ровно тот же баг в ffmpeg.
> И по упоминаниям в обсуждении он же.

Судя по обсуждению на гитхабе как я понимаю эту историю:
1) Отгружаемый гуглей в какой-то специфичной ситуации чанк - таки нарушает спеки стандарта. И это косяк не ffmpeg а именно гугли. А то что оно работало - результат laxed отношения к стандарту. Т.е. все строго наоборот относительно того что вы тут вопили.
2) ffmpeg запилил более строгое соответствие стандарту в какой-то момент - ибо fuzzer на это ругался.
3) После обнаружения что это ведет к траблам - ffmpeg сделали как вариант работы с строгим комплайнсом стандарту, так и laxed. А что еще они могут на своей стороне сделать?

По моему - you're wrong on so many levels... а самый кривой в этой истории гугол, отгружающий нестандартный чанк, не? Хотя на специальный слом даунлоадеров не похоже, просто совпало забавно.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру