на динамической картинке всегда будут пики и провалы. это нормально.

Я по себе. У меня поток плавал, сколько я не жал, критичного в этом нет ничего, для сети спасает QoS, если надо.

Спасибо, читаю man.
Если решение которое я описал ниже, не поможет мне, я, возможно, использую Ваше.

Я сейчас решил использовать
ffmpeg ... | buffer | ffmpeg -acodec copy ...

у he-aac - да

а транспорт как понимаю hls?

если hls - то решаешь не ты, а нарезчик hls

Мне кажется Вы невнимательны.

Я же сказал входной поток hls.

я для уточнения

мне интересно как ты себе представляешь постоянную загрузку, если а) подготовка нового сегмента происходит когда наберется внутренний буфер нарезчика, б) ffmpeg имеет свой буфер в N сегментов и подкачивает новые сегменты только по его опустошению (и не обязательно в реалтайме)

hls не для реалтайма

У меня не real time, ни в какой мере.

у меня не то что правильная логика, у меня CDN на базе HLS для многотысячных стримов и я знаю как с этим работает. Если получается удерживать длину сегмента такой, чтоб новый сегмент качался ровно тогда, когда кончается буфер, то потребление трафика будет +- константно. НО - это очень хорошо для live (+-5 секунд), потому что минимизирует задержку. Если идет раздача статического контента или же задержка не важна, то малейший пролаг в сети даст пролаг, т.к. внутренний буфер плеера кончится раньше, чем приедет новый сегмент. Потому неконстантная загрузка - это хорошо

хорошо что набивается.

сытый playback буфер - это хорошо

Я не понимаю в чем проблема рваного потребления трафика

Но какая?

с искуственным ограничением - нет

у меня были ровно противоположные задачи х)

С ограничением скорости - не могу. Я не делал никогда ограничение трафика ffmpeg-у. Более того, непонятно зачем искуственно ограничивать скорость получения/отдачи нового чанка.