I feeding gstreamer via the shm interface from my custom app. the file shmpipe.h outlines shortly how to interact on the server side (acting like a sink/server). * First, create a writer with sp_writer_create() * And selectes() on the socket from sp_get_fd() * If the socket is closed or there are errors from any function, the app * should call sp_close() and assume the writer is dead * The server calls sp_writer_accept_client() when there is something to read * from the server fd * It then needs to select() on the socket from sp_writer_get_client_fd() * If it gets an error on that socket, it call sp_writer_close_client(). * If there is something to read, it calls sp_writer_recv(). * * The writer allocates buffers with sp_writer_alloc_block(), * writes something in the buffer (retrieved with sp_writer_block_get_buf(), * then calls sp_writer_send_buf() to send the buffer or a subsection to * the other side. When it is done with the block, it calls * sp_writer_free_block(). * If alloc fails, then the server must wait for events from the clients before * trying again. One thing that's not clear to me: Do I have to call sp_writer_alloc_block() for every single frame I pass on to sp_writer_send_buf()? Or is sp_writer_alloc_block() simply done once only at startup? mattes _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Wed, 2011-12-07 at 14:49 -0800, mattes wrote:
> I feeding gstreamer via the shm interface from my custom app. > the file shmpipe.h outlines shortly how to interact on the server side > (acting like a sink/server). > > * First, create a writer with sp_writer_create() > * And selectes() on the socket from sp_get_fd() > * If the socket is closed or there are errors from any function, the app > * should call sp_close() and assume the writer is dead > * The server calls sp_writer_accept_client() when there is something to read > * from the server fd > * It then needs to select() on the socket from sp_writer_get_client_fd() > * If it gets an error on that socket, it call sp_writer_close_client(). > * If there is something to read, it calls sp_writer_recv(). > * > * The writer allocates buffers with sp_writer_alloc_block(), > * writes something in the buffer (retrieved with sp_writer_block_get_buf(), > * then calls sp_writer_send_buf() to send the buffer or a subsection to > * the other side. When it is done with the block, it calls > * sp_writer_free_block(). > * If alloc fails, then the server must wait for events from the clients before > * trying again. > > > One thing that's not clear to me: Do I have to call sp_writer_alloc_block() > for every single frame I pass on to sp_writer_send_buf()? > Or is sp_writer_alloc_block() simply done once only at startup? should also know that you can send only a part of a block, you don't have to send the whole block. But you should not modify the content of a block after doing a send (as it is shared memory). The trivial case is alloc_block();get_buf();memcpy();send_buf();free_block(); -- Olivier Crête [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (205 bytes) Download Attachment |
In reply to this post by mattes
>On Wed, 2011-12-07 at 14:49 -0800, mattes wrote:
>> I feeding gstreamer via the shm interface from my custom app. >> the file shmpipe.h outlines shortly how to interact on the server side >> (acting like a sink/server). >> >> * First, create a writer with sp_writer_create() >> * And selectes() on the socket from sp_get_fd() >> * If the socket is closed or there are errors from any function, the app >> * should call sp_close() and assume the writer is dead >> * The server calls sp_writer_accept_client() when there is something to read >> * from the server fd >> * It then needs to select() on the socket from sp_writer_get_client_fd() >> * If it gets an error on that socket, it call sp_writer_close_client(). >> * If there is something to read, it calls sp_writer_recv(). >> * >> * The writer allocates buffers with sp_writer_alloc_block(), >> * writes something in the buffer (retrieved with sp_writer_block_get_buf(), >> * then calls sp_writer_send_buf() to send the buffer or a subsection to >> * the other side. When it is done with the block, it calls >> * sp_writer_free_block(). >> * If alloc fails, then the server must wait for events from the clients before >> * trying again. >> >> >> One thing that's not clear to me: Do I have to call sp_writer_alloc_block() >> for every single frame I pass on to sp_writer_send_buf()? >> Or is sp_writer_alloc_block() simply done once only at startup? > >For every frame you want to send, you should allocate a new block. You >should also know that you can send only a part of a block, you don't >have to send the whole block. But you should not modify the content of a >block after doing a send (as it is shared memory). The trivial case is >alloc_block();get_buf();memcpy();send_buf();free_block(); > >-- >Olivier Cr?te thanks for the info, I implemented it as you said. One first thing I noticed was that alloc_block() returns NULL once in a while. It seems that a block is not immediately available after free_block(). Does this mean the block is still in use by the consumer(client)? I then increased the shared memory size for sp_writer_create() to 10* of my frame size and now I rarely see alloc_block() failing. Is there magic number for the SHM memory size (set by sp_writer_create()) ? How many blocks/frames should fit the SHM memory to have a fluent frame flow, when doing video encoding? mattes _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Thu, 2011-12-08 at 15:06 -0800, mattes wrote:
> > thanks for the info, I implemented it as you said. > One first thing I noticed was that alloc_block() returns NULL once in > a while. > It seems that a block is not immediately available after free_block(). > Does this mean the block is still in use by the consumer(client)? Exactly, yes. > Is there magic number for the SHM memory size (set by > sp_writer_create()) ? > How many blocks/frames should fit the SHM memory to have a fluent > frame flow, > when doing video encoding? There isn't a magic number as it really depends on your application etc. Normally, one 2 frames should be enough. It will block your writer side regularly, but that just means it will allow the kernel to schedule the receiver side. Obviously, you can buffer up more in the shared memory, but that does increase the latency if you have a live pipeline, but it will probably reduce the number of times the kernel has to reschedule in a non-live case so it will increase throughput.. So it really is the traditional throughput vs latency problem. -- Olivier Crête [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (205 bytes) Download Attachment |
Free forum by Nabble | Edit this page |