Devin Heitmueller (12025-01-17): > It's an intrinsically difficult > problem. The data arrives on multiple sockets, leading to all sorts > of opportunities for timing behavior and reordering issues.
I will add something on top of that: The architecture of network protocols in FFmpeg is not adapted to protocols with multiple sockets at all. All such protocols we have implement their own half-assed event loop. To implement anything complex would require reworking the whole system to have protocols and demuxers work in an input-driven fashion around a global event loop. With threads or contexts to let current output-driven code run, it would be doable. But with the current do-nothing-ambitious governance, and with the sequels of the botched move to threads of fftools, it cannot happen. > That said, I don't necessarily think we should let "perfect be the > enemy of good" and outright reject a proposed implementation that has > been reported to work in many use cases. Thank you for writing the obvious. > It's a good starting point and can be improved over time. Ditto. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
