А что в этом плохого, зачем для такой задачи писать/отлаживать/поддерживать из библиотек свой велосипед (причем совсем не простой, когда нужно сделать конфигурируемыми пару десятков параметров), если утилита ffmpeg с этим прекрасно справляется?
Другое дело, что почему-то некоторые сервисы не задумались о запуске ffmpeg в песочнице с урезанием всего, что явно не нужно (хотя бы доступа в сеть).

И я вообще не уверен, что использование библиотек вместо утилиты ffmpeg тут бы помогло, утилита ведь точно так же использует эти самые библиотеки, в которых точно так же могут быть уязвимости. Если говорить про пример с m3u8, то делать черный список форматов, которые не конвертировать — плохая идея, можно что-то не учесть, аналогично и с белым списком — не учтешь особенностей каждого из нескольких сотен вариантов, может где-то есть неявная возможность обращения к сети например.

На мой взгляд, именно изолированние любой обработки пользовательских данных — это то решение, которое необходимо *в первую очередь*, которое, кстати, помогло бы в данном случае.

Насколько я знаю оно в начале шлёт DHCP INFORM и требует опцию 252, и только если ответа нет или опции в ответе нет то начинается брожение где попало.

В реальности все не так хорошо с DHCP 252:
— в firefox это не поддерживается нигде.
— в Windows 7 это поддерживает только IE — см. DHCP WPAD findproxyforurl.com/browser-support

Про поддержку этой опции современными браузерами сказано верно, например в последних на момент исследования Firefox и Chrome эта dhcp опция не учитывалась