gstreamer/gst/tcp/README
Thomas Vander Stichele 7524f806cd gst/tcp/: make multifdsink properly deal with streamheader:
Original commit message from CVS:
* gst/tcp/README:
* gst/tcp/gstmultifdsink.c: (gst_multi_fd_sink_init),
(gst_multi_fd_sink_remove_client_link),
(gst_multi_fd_sink_client_queue_caps),
(gst_multi_fd_sink_client_queue_buffer),
(gst_multi_fd_sink_handle_client_write),
(gst_multi_fd_sink_render):
* gst/tcp/gstmultifdsink.h:
make multifdsink properly deal with streamheader:
- streamheader is taken from caps
- buffers marked with IN_CAPS are not sent
- streamheaders are sent, on connection, from the caps of the
buffer where the client gets positioned to
- further streamheader changes are done every time the client
will receive a buffer with different caps
* tests/check/elements/multifdsink.c: (GST_START_TEST),
(gst_multifdsink_create_streamheader):
add tests for this
2006-06-02 16:26:54 +00:00

50 lines
1.7 KiB
Text

This part of the documentation is for the new tcp elements:
- tcpclientsrc
- tcpclientsink
- tcpserversrc
- tcpserversink
TESTS
-----
Use these tests to test functionality of the various tcp plugins
* server: nc -l -p 3000
client: nc localhost 3000
everything you type in the server is shown on the client
everything you type in the client is shown on the server
* server: nc -l -p 3000
client: gst-launch tcpclientsrc protocol=none port=3000 ! fdsink fd=2
everything you type in the server is shown on the client
* server: nc -l -p 3000
client: gst-launch fdsrc fd=1 ! tcpclientsink protocol=none port=3000
everything you type in the client is shown on the server
* server: gst-launch tcpserversrc protocol=none port=3000 ! fdsink fd=2
client: gst-launch fdsrc fd=1 ! tcpclientsink protocol=none port=3000
TODO
----
- implement DNS resolution
multifdsink
-----------
- operation:
- client fd gets added when "add" signal gets emitted on multifdsink
- signal handler creates a GstTCPClient structure, adds it to ->clients,
and adds the fd to ->fd_hash, then emits client-added
- client
- when a buffer comes in:
- the _render vmethod puts the buffer on the global queue
- and increases bytes_to_serve
- (currently it sets streamheaders, but since this is treated globally
this is wrong - clients can be at different positions in the stream)
- when a client issues a write (ie requests data):
- when using GDP, if no caps sent yet, send caps first, then set caps_sent
- if streamheader buffers, and we haven't sent yet to this client,
send current streamheader buffers, then set streamheader_sent
- send out buffers