shmsink question

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

shmsink question

mattes

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
Reply | Threaded
Open this post in threaded view
|

Re: shmsink question

Olivier Crête-3
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
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: shmsink question

mattes
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
Reply | Threaded
Open this post in threaded view
|

Re: shmsink question

Olivier Crête-3
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