> Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами?Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать и вовремя отрендерить. Если у нас временной лаг на чтении, то это выльется в лаги на экране. Эти проблемы можно решать generic способом включая буферизацию на несколько секунд вперёд, но это приведёт к задержке в несколько секунд (что может быть существенно в каких-то сценариях использования), и к перерасходу памяти. ffmpeg идёт другим путём, он использует стратегии чтения наилучшим образом подходящие для носителя: если мы читаем с жёсткого диска, то достаточно иметь небольшой кеш упреждающего чтения, если мы читаем по сети, то... тут я чесслово не знаю какого масштаба усложнения начинаются, но если предполагать по максимуму, то надо договориться с передающей стороной о том, как много мы хотим читать вперёд, какого размера кусками, как долго ждать до повторной передачи куска, в случае отсутствия подтверждения о получении, надо получая эти куски правильно их переупорядочивать,... большую часть этого на себя берёт стек tcp/ip, но стеку ведь можно подсказать как лучше действовать в данной ситуации.
Но вообще может быть любопытной задачей создание какого-нибудь внятного API между декодером и reader'ом, которое позволило бы разнести их по разным адресным пространствам, сохранить гибкость системы при подстройке к конкретной ситуации, не потерять в производительности, и не столкнуться при этом с проблемой breaking changes в каждой минорной версии этого API. Если ты такой умный, как выглядишь, то займись этим -- разнеси код ffmpeg на два процесса и создай API между ними.
