Its documentation states that it is allocated/freed by the caller, but
it is declared as an AV_OPT_TYPE_STRING AVOption. Since
367732832f the AVOptions system frees
strings automatically. This can be considered an API break, since it
won't work when the caller doesn't use av_malloc() to allocate the
memory or wants to use the string after closing the codec.
Since there is not much value in this field being an AVOption, the best
solution is to remove it from the options table.
While these defines are not defined by the C standard they are
standardized as X/Open System Interfaces Extension. We use the
appropiate _XOPEN_SOURCE define to make them available. They
seem to be available on all FATE configs since the constants
are used in files where mathematics.h is not included.
Also use ff_neterrno() instead of errno directly (which doesn't work
on windows), for getting the error code.
Signed-off-by: Martin Storsjö <martin@martin.st>
getnameinfo doesn't set errno on failure, it returns an error code,
which should be handled by gai_strerror instead of the normal
strerror.
Signed-off-by: Martin Storsjö <martin@martin.st>
Rtmpt is effectively half duplex - the server can't return any
data unless we send a request (to which the server responds). If
we don't have any data to send currently, and the server didn't
return any data either, wait a little before doing the next request.
This avoids busy looping with idle posts with empty replies, while
waiting for more data from the server.
Signed-off-by: Martin Storsjö <martin@martin.st>
The check uses check_func_header, since this function is
conditionally available depending on the targeted MSVCRT
version.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add a new option 'rtmp_flush_interval' that allows specifying the
number of packets to write before sending it off as a HTTP request.
This is mostly relevant for RTMPT - for plain RTMP, it only controls
how often we check the socket for incoming packets, which shouldn't
affect the performance in any noticeable way.
Signed-off-by: Martin Storsjö <martin@martin.st>
This seems to be the correct mode to send, according to the
original RTSP RFC, and matches the method RECORD which is
sent later when starting to send data.
Darwin Streaming Server works fine with either of them.
Signed-off-by: Martin Storsjö <martin@martin.st>
