[FFmpeg-devel] [PATCH v3] libavformat: Add ZeroMQ as a protocol option

[Andriy Gelman]

On Thu, 29. Aug 02:28, Marton Balint wrote:
> 
> 
> 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.

ok, I misunderstood the problem. I'll use zmq_errno()   

> 
> > > > > +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.

That's very good to know. 

Thanks, 
Andriy