Mark Thompson (12021-02-18): > If the existing remote-socket-only poll is sufficent (so no local > events), then I think I have misunderstood your original definition of > the event loop because I was expecting that other threads would be > able to interact with it.
Threading is one of the goals, but not the main one. If it is available
on Unix only until somebody writes a little Windows code or unless one
use the external library, that is not an issue.
> Would it be possible to add an example what you intend API use to
> actually look like to your design summary? (In loose pseudocode.)
loop = create_event_loop()
vid_st = create_rtp_stream(...)
aud_st = create_rtp_stream(...)
attach_to_loop(loop, vid_st)
attach_to_loop(loop, aud_st)
connect_callback(vid_st, video_callback)
connect_callback(aud_st, video_callback)
run_loop(loop)
> libev does not implement enough Windows support to be used generally,
> though it is sufficient if you know the event loop will never want to
> interact with anything which is not a socket (it hacks up self-pipes
> by connecting TCP sockets to random ports on localhost).
If it works...
> I believe that libuv and libevent both implement it properly
That would be an argument for it. I am waiting for Lynne answer to my
request for details.
> (Note in particular that this means essentially everything dealing
> with sockets has to be delegated to the event library so that it can
> deal with asynchronous calls internally, especially send()/recv()
> calls.)
Using non-standard IO code and tying to the library is completely out of
the question.
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".
