> On Apr 24, 2024, at 1:46 PM, Flavio Alves > <flavio.al...@vitalintelligencedata.com> wrote: > > My first implementation uses the approach you mentioned. I implemented it > using x264 and it worked fine. > > But my requirement is to use the Nvidia Jetson Nano hardware encoder. Nvidia > provides an API to handle the encoder. This API uses threads for the encoder > and select() for V4L communication. On my implementation, when I executed > everything, the Live555 worked fine and the Encoder thread got stuck, because > the use of the select() is also blocking.
I’m not sure I see the problem here. Suppose you have two threads - one for your encoder (that uses your Nvidia API), and another for the server (that uses the LIVE555 API). Both threads are event-driven (using “select()”). Set up your encoder thread to call “select()” (and thus block) on your input socket (for your encoder), to call a handler function whenever there’s new data (presumably, an encoded NAL unit) available to read on this socket. This handler function would call “triggerEvent()” (the only LIVE555 function that can be called by a non-LIVE555 thread), to signal the LIVE555 thread of the availability of new data. In other words, both threads are blocking, but only until an event occurs - which the thread should then handle. The other possibility is to use just a single (LIVE555) thread, and do all event handling using LIVE555. You could handle events on your encoder socket by calling (the LIVE555 function) “setBackgroundHandling()” (you can see several examples of this in the “liveMedia” directory. In this case, you would not call “select()” at all (because the LIVE555 event loop already does that for you). But I don’t know anything about your "Nvidia Jetson multimedia API”. so I might be completely wrong here… Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
