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
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
