On Wed, 28 Aug 2019, Andriy Gelman wrote:
> > + h->is_streamed = 1;
> > +
> > + av_strstart(uri, "zmq:", &uri);
> > +
> > + /*publish during write*/
> > + if (h->flags & AVIO_FLAG_WRITE) {
> > + s->socket = zmq_socket(s->context, ZMQ_PUB);
> > + if (!s->socket) {
> > + av_log(h, AV_LOG_ERROR, "Error occured during zmq_socket():
%s\n", zmq_strerror(errno));
zmq_errno() instead of errno? Same goes for all similar cases.
The documentation says to use zmq_errno() on non-POSIX systems.
But also suggests:
"Users not experiencing issues with retrieving the correct value of errno should
not use this function and should instead access the errno variable directly."
On IRC J_Darnley pointed out that ffmpeg.c includes errno.h without any checks.
It seems reasonable to assume that errno is available.
That does not matter, because ffmpeg uses errno for checking errors
when ffmpeg.c calls the standard C library, not when a linked
library calls the standard C library.
I am no expert in this area, but as far as I understood it from the docs
of zmq_errno() the problem is not the "availability" of errno but that
multiple C runtimes might be in use an you might not get the errno of the
C runtime libzmq is using but the errno of the C runtime your application
is using.
Here are some more deails I found:
https://grokbase.com/t/zeromq/zeromq-dev/1087reyava/portability-of-0mq-api
So zmq_errno() still feels safer and more portable.
> > +static int ff_zmq_write(URLContext *h, const unsigned char *buf, int size)
> > +{
> > + int ret;
> > + ZMQContext *s = h->priv_data;
> > +
> > + ret = zmq_send(s->socket, buf, size, ZMQ_DONTWAIT);
I can see that you are using non-blocking mode. A polling with timeout
approach is preferred, see how tcp or unix does it.
I used polling in the initial patch, but I switched to non-blocking because I
thought it was a cleaner solution. I'll revert to polling with a timeout in the
next version.
Polling returns immediately when data is available. For the non-blocking
approach the code falls back to 1ms (which can easily be 10ms on Win32) sleeps
after a few retries. This severely can hurt performance, that is why the
polling approach is preferred.
Thanks,
Marton
_______________________________________________
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".
