On 18/02/2021 20:55, Nicolas George wrote:
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)
The callback for an input stream is called when you receive something, sure.
When is the callback for an output stream called? What if it doesn't have a
packet available to write right now, but will do later?
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.
I think this means that integration with most external libraries (and
non-network things) will not be possible, then.
- Mark
_______________________________________________
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".
