Anton Khirnov (12021-01-02): > I don't see how that conclusion follows. If a protocol has multiple FDs, > we design the API to allow exporting multiple FDs. Why would we > absolutely need our own event loop?
The protocol exports multiple FDs... ok... and then what? How do you make the protocol work from ffmpeg.c? Or from any application that does not have its own event loop? How do you make the protocol's url_read() callback work? I do not know how extensive your experience with network programming is¹, but you need to realize that a protocol with several sockets needs an event loop, it cannot be implemented without. And since FFmpeg does not have a global, clean event loop, all protocols with multiple sockets end up re-implementing their own half-assed event loop in the url_read() callback. I think you do not realize that there are already at least four crappy event loops (rtpproto.c, rtsp.c, rtspenc.c, sapdec.c). What I am proposing is to have just one, not crappy. Written like this, I will add this: what made FFmpeg's success? What allowed FFmpeg to get the fastest VP9 decoder out there, for example? The fact that it already has all the infrastructure required by codecs: good FFTs, frame management, bistream readers, etc. If we want FFmpeg to have good protocols as well as good codecs, it needs to have the infrastructure to make them possible. And for protocols, the infrastructure is mostly two things: crypto protocols and en event loop. 1: Please consider enlightening us on this. If I can say so myself, I consider I am quite proficient at Unix network and system programming, except for fringe topics like multicast. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
