Mark Thompson (12021-02-20):
> I'm not entirely sure where this discussion was going, but I believe
> the original questions would have been simple to answer if anyone had
> bothered to read the documentation.
>
> Adding a file descriptor referring to something independent of libuv
> (such as an
On 19/02/2021 19:34, Kieran Kunhya wrote:
On Fri, 19 Feb 2021 at 19:04, Nicolas George wrote:
Kieran Kunhya (12021-02-19):
I don't have a strong opinion on either. But I think you can use
container_of on the fd.
Thanks. I find no trace of it in the docs:
On Fri, 19 Feb 2021 at 19:04, Nicolas George wrote:
> Kieran Kunhya (12021-02-19):
> > I don't have a strong opinion on either. But I think you can use
> > container_of on the fd.
>
> Thanks. I find no trace of it in the docs:
>
>
>
Kieran Kunhya (12021-02-19):
> I don't have a strong opinion on either. But I think you can use
> container_of on the fd.
Thanks. I find no trace of it in the docs:
http://docs.libuv.org/en/v1.x/search.html?q=container_of_keywords=yes=default
Can you be a little more precise?
The portability
On Fri, 19 Feb 2021 at 17:41, Nicolas George wrote:
> Lynne (12021-02-19):
> > You poll it in a busy loop in a thread in an event.
>
> Yeah. Events loop are supposed to avoid busy loops. So no.
>
> > Or you find a solution to use libuv's polling instead via a "hacker
> > solution".
>
> This is
Lynne (12021-02-19):
> You poll it in a busy loop in a thread in an event.
Yeah. Events loop are supposed to avoid busy loops. So no.
> Or you find a solution to use libuv's polling instead via a "hacker
> solution".
This is what I am asking: can you give a good solution with libuv? It
seems
Feb 19, 2021, 16:21 by geo...@nsup.org:
> Lynne (12021-02-19):
>
>> That's okay, I'd let it read and call events as they happen on the fds.
>>
>
> Pray tell me, how do you do that with a /dev/snd/pcmC0D0p in mmap mode?
>
You poll it in a busy loop in a thread in an event. Or you find a solution
Lynne (12021-02-19):
> That's okay, I'd let it read and call events as they happen on the fds.
Pray tell me, how do you do that with a /dev/snd/pcmC0D0p in mmap mode?
Sorry, but as promising as libuv looked, it is not generic enough for
our use case, unless I missed something big.
Regards,
--
Feb 19, 2021, 15:52 by geo...@nsup.org:
> Lynne (12021-02-19):
>
>> File descriptors are reference counted. So if something takes ownership
>> of an FD (completely reasonable, since it may want to clean up, seek, and
>> flush+close it afterwards), then you can just dup() it before giving
>> it to
Lynne (12021-02-19):
> File descriptors are reference counted. So if something takes ownership
> of an FD (completely reasonable, since it may want to clean up, seek, and
> flush+close it afterwards), then you can just dup() it before giving
> it to libuv.
You are completely misunderstanding the
Feb 19, 2021, 14:52 by geo...@nsup.org:
> Lynne (12021-02-19):
>
>> https://github.com/libuv/libuv/tree/v1.x/docs/code
>> Pipes, file descriptors, sockets, examples.
>> The docs are even searchable: http://docs.libuv.org/en/v1.x/index.html
>>
>
> I have found all this. Nothing allows to handle a
Lynne (12021-02-19):
> https://github.com/libuv/libuv/tree/v1.x/docs/code
> Pipes, file descriptors, sockets, examples.
> The docs are even searchable: http://docs.libuv.org/en/v1.x/index.html
I have found all this. Nothing allows to handle a foreign protocol
handled by existing code. It is even
Feb 19, 2021, 12:41 by geo...@nsup.org:
> Lynne (12021-02-19):
>
>> I found this document useful:
>> https://gist.github.com/andreybolonin/2413da76f088e2c5ab04df53f07659ea
>>
>
> Thanks. But I think this document makes it clear that what we, FFmpeg,
> need, is not libuv.
>
> In fact, after
Lynne (12021-02-19):
> I found this document useful:
> https://gist.github.com/andreybolonin/2413da76f088e2c5ab04df53f07659ea
Thanks. But I think this document makes it clear that what we, FFmpeg,
need, is not libuv.
In fact, after looking in the docs and in the source, I could not even
find how
Feb 18, 2021, 16:43 by geo...@nsup.org:
> Lynne (12021-02-17):
>
>> It's more actively developed by a large margin, and I generally
>>
>
> This is an interesting argument.
>
>> prefer its API and how it works internally.
>>
>
> Can you give more details? Which differences make you prefer it?
>
>
Mark Thompson (12021-02-18):
> I wrote the last packet a second ago and got a callback for
> writeability from the loop, but didn't have anything to write back
> then so I did nothing.
>
> Now I have a packet to write, but the event loop is sitting idle in its
> poll() call.
>
> You've said I'm
On 18/02/2021 21:44, Nicolas George wrote:
Mark Thompson (12021-02-18):
When is the callback for an output stream called? What if it doesn't
have a packet available to write right now, but will do later?
It will be called when data has been written, of course. If there is no
data to write,
Mark Thompson (12021-02-18):
> When is the callback for an output stream called? What if it doesn't
> have a packet available to write right now, but will do later?
It will be called when data has been written, of course. If there is no
data to write, the stream is just idle.
> I think this
On 18/02/2021 20:55, Nicolas George wrote:
Mark Thompson (12021-02-18):
If the existing remote-socket-only poll is sufficent (so no local
events), then I think I have misunderstood your original definition of
the event loop because I was expecting that other threads would be
able to interact
Mark Thompson (12021-02-18):
> If the existing remote-socket-only poll is sufficent (so no local
> events), then I think I have misunderstood your original definition of
> the event loop because I was expecting that other threads would be
> able to interact with it.
Threading is one of the goals,
On 18/02/2021 15:39, Nicolas George wrote:
Mark Thompson (12021-02-17):
I'm not sure you can avoid writing Windows code for this to work at
all, because I don't think poll() as we have now is sufficient to get
the functionality you want.
I'm sure I can avoid writing Windows code, because, as
Lynne (12021-02-17):
> It's more actively developed by a large margin, and I generally
This is an interesting argument.
> prefer its API and how it works internally.
Can you give more details? Which differences make you prefer it?
One of the things that I like about libev is that it makes
Mark Thompson (12021-02-17):
> I'm not sure you can avoid writing Windows code for this to work at
> all, because I don't think poll() as we have now is sufficient to get
> the functionality you want.
I'm sure I can avoid writing Windows code, because, as I have already
pointed, our current
On 17/02/2021 20:57, Nicolas George wrote:
Mark Thompson (12021-02-17):
I can see that this is all sensible stuff on Unix, but can you explain
a bit more of what your Windows implementation is going to look like?
I have no intention to write Windows code for this. Our current
protocols use
Feb 17, 2021, 15:38 by geo...@nsup.org:
> Lynne (12021-02-17):
>
>> I think I'd prefer an asynchronous library rather than libev.
>> So libuv?
>>
>
> I have on occasion straced node to debug things, and what I have
> observed is: I don't want to touch it even with a very long stick.
>
> Wan you
Mark Thompson (12021-02-17):
> I can see that this is all sensible stuff on Unix, but can you explain
> a bit more of what your Windows implementation is going to look like?
I have no intention to write Windows code for this. Our current
protocols use poll() internally, this event loop will do
On 01/02/2021 19:14, Nicolas George wrote:
Based on this discussion, I say that the need for an event loop is
confirmed.
I will now start discussing actual plans for going forward. Since the
coding work will be significant and not incremental, I want the outcome
of this discussion to be
Lynne (12021-02-17):
> I think I'd prefer an asynchronous library rather than libev.
> So libuv?
I have on occasion straced node to debug things, and what I have
observed is: I don't want to touch it even with a very long stick.
Wan you explain more precisely why you think libuv would be a
Feb 17, 2021, 12:47 by geo...@nsup.org:
> James Almer (12021-02-01):
>
>> I support the idea of it being a build option (Perhaps simply
>> --enable-libev, like any other external dep). There's a precedent of
>> external libraries being used as backend for certain features, with the most
>>
James Almer (12021-02-01):
> I support the idea of it being a build option (Perhaps simply
> --enable-libev, like any other external dep). There's a precedent of
> external libraries being used as backend for certain features, with the most
> prominent example being libsoxr as the resample engine
On 2/1/2021 4:14 PM, Nicolas George wrote:
1.3. Implement a libev wrapper.
Implement the callbacks of the event loop API with libev as
back-end.
Make it either an example or a build option. A build option would
have the benefit of more extensive testing.
I support the
Paul B Mahol (12021-02-01):
> Why event loop is needed for filters?
>
> libavcodec have frame threads and it does not need it.
libavcodec has its own scheduler. Duplicated code everywhere.
--
Nicolas George
signature.asc
Description: PGP signature
On Mon, Feb 1, 2021 at 8:14 PM Nicolas George wrote:
> Based on this discussion, I say that the need for an event loop is
> confirmed.
>
> I will now start discussing actual plans for going forward. Since the
> coding work will be significant and not incremental, I want the outcome
> of this
Based on this discussion, I say that the need for an event loop is
confirmed.
I will now start discussing actual plans for going forward. Since the
coding work will be significant and not incremental, I want the outcome
of this discussion to be binding: if we agree to do it a certain way,
then
Xiang Xiao (12021-01-04):
> Nicolas, thank you for bringing up this topic.
> My team is working on similar functionality: the event loop is the
> central point to integrate protocol, demux/mux, decoder/encoder, avfilter
> and avdevice to form a complete multimedia subsystem(like DirectShow or
>
Steven Liu (12021-01-05):
> > But as I said, I would be fine with libev the main,
> Is that mean I must enable libev if I use ffmpeg, or must enable libev
> if I use libav* API? Or do you mean I can configure by myself if I
> don’t want use third part lib in ffmpeg?
If you are referring to this
> 2021年1月4日 下午9:44，Nicolas George 写道：
>
> Kieran Kunhya (12021-01-02):
>> In my opinion we should use libev as the default and make it a submodule
>> (possibly as part of some sort of plugin system for event loops). This
>> allows us to use modern things such as io_uring as they come.
>
> I
Nicolas, thank you for bringing up this topic.
My team is working on similar functionality: the event loop is the
central point to integrate protocol, demux/mux, decoder/encoder, avfilter
and avdevice to form a complete multimedia subsystem(like DirectShow or
GStreamer). Without the builtin event
Kieran Kunhya (12021-01-02):
> In my opinion we should use libev as the default and make it a submodule
> (possibly as part of some sort of plugin system for event loops). This
> allows us to use modern things such as io_uring as they come.
I can be on board with that, since I like libev very
Peter Ross (12021-01-04):
> Majority of our demuxers and muxers assume a blocking model. Will they
> need to be rewritten (eventually) to use event-based i/o?
The way I see it, compatibility is ensured: the current API that reads
on protocol should still be supported, by creating a local loop and
On Thu, Dec 31, 2020 at 02:37:21PM +0100, Nicolas George wrote:
> This mail is about a project I have to make FFmpeg's API and
> infrastructure more convenient. For a common introduction, see this thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
>
> The API to access
On Sat, 2 Jan 2021 at 16:52, Nicolas George wrote:
> If we want FFmpeg to have good protocols as well as good codecs, it
> needs to have the infrastructure to make them possible. And for
> protocols, the infrastructure is mostly two things: crypto protocols and
> en event loop.
>
In my opinion
Anton Khirnov (12021-01-02):
> I don't see how that conclusion follows. If a protocol has multiple FDs,
> we design the API to allow exporting multiple FDs. Why would we
> absolutely need our own event loop?
The protocol exports multiple FDs... ok... and then what? How do you
make the protocol
Quoting Nicolas George (2021-01-02 12:28:30)
> Anton Khirnov (12021-01-01):
> > I do not think this is a good idea. There are enough event loops in the
> > world and making yet another one is not in scope for us. What we should
> > do instead is allow clean integration with existing event loops,
Kieran Kunhya (12020-12-31):
> This would be a good idea in general and bring FFmpeg into the early 21st
> century.
Thanks for the feedback.
> As I understand it the hard part is cross-platform event loops (does libev
> support windows now?)
AFAIK, it is hard to make something really optimized,
Anton Khirnov (12021-01-01):
> I do not think this is a good idea. There are enough event loops in the
> world and making yet another one is not in scope for us. What we should
> do instead is allow clean integration with existing event loops, mainly
> by exporting the underlying file descriptors
Quoting Nicolas George (2020-12-31 14:37:21)
> This mail is about a project I have to make FFmpeg's API and
> infrastructure more convenient. For a common introduction, see this thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
>
> The API to access our protocols, in
>
> I want to replace it with an event loop. That means that instead of reading
> on a protocol context, we would register a callback for when data is
> available, and then let the loop run.
>
This would be a good idea in general and bring FFmpeg into the early 21st
century.
As I understand it
This mail is about a project I have to make FFmpeg's API and
infrastructure more convenient. For a common introduction, see this thread:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
The API to access our protocols, in particular network protocols, is copied
from the Unix
49 matches
Mail list logo
