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

[Marton Balint]

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