RTSP Client sometimes doesn't send video (stream 0) packets to the client

[renjith.t]

Hello All,

Its not an issue with the GET_PARAMETERS Request.
GET_PARAMETERS request is sent by the client, it is also received and
processed further by the rtsp server.

We took time to analyze this issue, and below is our observation

- gst_rtsp_watch_write_serialized_messages :- function writes the stream on
to the socket.
- If the messages to be sent to the clients is in big numbers, then some
messages are not sent to the client, this function adds the pending messages
to the client's watch and allocates the  dispatcher
(gst_rtsp_source_dispatch_write) for sending those pending messages, and
sets a sequence no in the last message.
- when gst_rtsp_source_dispatch_write is invoked, it is responsible to send
those pending messages to the client. when all messages are sent
successfully, the callback for message_sent is called, which in-turn will
reset the sequence number.


*Now the problem arises in the below situation* (it occurs when the number
of TCP clients for a single shared stream is huge - I reproduced this issue
with 10-15 TCP Clients (5-7 clients per PC) with resolution of 2048 X 1536 @
25fps H.264 Codec )

- gst_rtsp_watch_write_serialized_messages  was not able to write the
messages completely
- It added the pending messages to the client's watch & assigned the
dispatcher for it.
- the above was done for all the 5-6 clients in the same pc
- now the dispatcher came in into action
- dispatcher took clients one by one and started to send the messages from
the client's watch
- before the dispatcher could start sending messages to the last client,
next message for that client was scheduled to be sent through
gst_rtsp_watch_write_serialized_messages (*I believe it is a case of context
switching* )
- now send_tcp_message of rtsp-stream.c came into action.
- it tried to send message to the client, from check_transport_backlog where
it failed
- on failing it removed the transport of the client. using update_transport
- hence no video was displayed on the client side since then.
- after that the dispatcher came into picture once again and delivered the
message to the client
- it was only after the transport was removed, the client's object received
the message sent notification for the sequence which was set earlier

On a trial basis, i stopped the removing the transport, it worked fine with
15-20 clients for around 15 hrs

Other observation i came across was
- every time the dispatcher was called from the same thread (even for
different clients of different streams)
- the same thread was also used to send messages to the other clients also.


Any help or solution to this problem is heartily welcomed.
Best Regards



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/