[FFmpeg-devel] [PATCH 3/3] Non-blocking protocol: TCP
Sun Feb 6 09:52:50 CET 2011
L'octidi 18 pluvi?se, an CCXIX, Martin Storsj? a ?crit?:
> As Nicolas said, all of these read UDP packets. There, url_read() either
> returns one packet, or no data at all, there's nothing inbetween.
... if the buffer is big enough (which seems the case here). If I remember
correctly, recv on a UDP socket with a buffer smaller than the packet will,
by default, truncate the packet to the size of the buffer and discard the
This behaviour would be disastrous with code that expect a stream-like
interface and use url_read_complete. Except that most of the time, the
pseudo-stream would have been muxed and emitted the same way, which means
that protocol packet boundaries will most of the time coincide with content
packet boundaries. But not always.
I still thinking about it.
> Btw, it might be handy to be able to switch between blocking and
> nonblocking mode on URLContexts after creation, too.
Indeed. In fact, when protocols depends on other protocols (like HTTP
depends on TCP), switching from blocking (for the header / connection) to
non-blocking (for the payload) will be necessary.
> As far as I can see
> from the patches, this wouldn't be much harder than adding a function that
> sets/clears that bit in h->flags.
That is currently true, and probably will stay true for the protocols I
know. Still, the setting function is a better solution for long-term API
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel