mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-11-03 09:01:54 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
pipewire/doc/design.txt

373 lines
15 KiB
Text
Raw Normal View History

doc: add simple design doc
2015-08-21 11:46:29 +02:00
Pinos
-----
The idea is to make a DBus service where you can provide
and consume media to/from.
Some of the requirements are:
- must be efficient for raw video using fd passing
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
- must be able to provide/consume/process media from any process
doc: add simple design doc
2015-08-21 11:46:29 +02:00
- streaming media only (no seeking)
- policy to restrict access to devices and streams
Although an initial goal, the design is not limited to raw video
only and should be able to handle compressed video and other
streamable media as well.
The design is in some part inspired by pulseaudio, hence its original
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
name. Increasinly we also seem to add functionality of jack.
doc: add simple design doc
2015-08-21 11:46:29 +02:00
Introduce the concept of a Node Make an object for a processing node. Implement a sink node. Make it possible to implement Sink and Source interfaces to provide input/output from the node. Improve pinosdepay to track fds and handle format changes.
2016-05-05 13:31:18 +02:00
Objects
-------
Daemon1: the main pinos daemon
/org/pinos/server
Client1: a connected client, the result object from call
Daemon1.ConnectClient
/org/pinos/client*
Device1: a physical device on the machine, devices can provide
processing nodes
/org/pinos/device*
Node1: a processing node, this can be a source, sink or transform
element.
/org/pinos/node*
Port1: a port on a Node1, ports can be input or output ports
/org/pinos/node*/port*
reintroduce channels Bring back the channel object. Making a node and port on the client side was rather awkward because of the async nature of many methods. It feels better to have a specific communication channel object to interface with a server side port. Use port activate/deactivate to start/stop streams Remove links from the ports. We let other objects install a callback on the port to receive and route buffers.
2016-07-20 17:29:34 +02:00
Channel1: a communication channel between a client and port
/org/pinos/client/channel*
rework: make client and server nodes work on making nodes and ports on the client.
2016-05-12 17:03:28 +02:00
Link1: a link between 2 ports
/org/pinos/link*
Introduce the concept of a Node Make an object for a processing node. Implement a sink node. Make it possible to implement Sink and Source interfaces to provide input/output from the node. Improve pinosdepay to track fds and handle format changes.
2016-05-05 13:31:18 +02:00
doc: add simple design doc
2015-08-21 11:46:29 +02:00
DBus protocol
-------------
The main daemon is registered on the session bus with name: org.pinos
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
Various Node1 objects are registered in the server based on the available
sources or sinks of content. Source1 has properties and has format descriptions of
doc: add simple design doc
2015-08-21 11:46:29 +02:00
what it can provide.
First a client needs to register with pinos by calling
org.pinos.Daemon1.ConnectClient(). This creates a new Client1 object that
the client must use for further communication.
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
A client can then do org.pinos.Client1.CreateChannel() to create a
new Channel to retrieve/send data from/to a node. It can specify a node/port
explicitly or let the server choose a port. The client must provide a list
doc: add simple design doc
2015-08-21 11:46:29 +02:00
of formats it can handle along with extra properties that can help with
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
selecting an appropriate port.
doc: add simple design doc
2015-08-21 11:46:29 +02:00
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
A client can then call org.pinos.Channel1.Start() to negotiate the final
doc: add simple design doc
2015-08-21 11:46:29 +02:00
media format and start the data transfer. A new fd is returned to the client
along with the negotiated format and properties.
All further media transport is then performed on the fd. The client will read
from the fd to get data and metadata from the server. The wire format is
generic and extensible and allows for inline serialized events such as
property changes and format changes.
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
fd management
-------------
Pinos shares data between clients by using fd passing. Sometimes the memory
referenced by the fd needs to be reused. It is important that all pinos
clients lost their reference to the fd before it can be reused.
What follows are some scenarios of how the lifecycle of the fds are
managed.
* server side
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
v4l2src pinossocketsink
| |
| |
make buffer |--------->|
| | (1)
| | (2) ----->
| | (3)
|... | ...
| |
| | (4) <-----
|<---------|
(1) pinossocketsink generates the pinos message from the v4l2 input
buffer. It is assumed in the next steps that the sink
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
receives fd-memory from v4l2src and that the memory is only
freed again when no clients are looking at the fd.
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
(2) pinossocketsink sends the buffer to N Pinos clients
(3) for each client that is sent a buffer, pinossocketsink uses the
fdmanager object to map the fd-index that was
add more debug statements
2016-04-11 15:26:15 +02:00
sent, to the buffer and client. The buffer is reffed and kept
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
alive for as long as the client is using the buffer.
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
(4) when a message is received from a client, pinossocketsink
parses the message and instructs the fdmanager to release
add more debug statements
2016-04-11 15:26:15 +02:00
the fd-index again. When all clients release the fd, the buffer
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
will be unreffed and v4l2src can reuse the memory.
* client consumer
pinossrc xvimagesink
| |
-------> (1)|------------------->| (2)
| |
| (3) |
|<-------------------|
<------- (4)| |
| |
(1) pinossrc receives a buffer from Pinos and wraps the fd with data
in an fd-memory. It remembers the fd-index as qdata on the memory.
It has a special DestroyNotify on the qdata.
(2) xvimagesink renders the buffer and frees the buffer.
(3) freeing the buffer causes the qdata DestoyNotify to be called.
(4) pinossrc constructs a release-fd message and sends it to Pinos
* client producer
videotestsrc pinossink
| |
(1)|------------------->|
| | (2) ----->
| |
| (4) | (3) <-----
|<-------------------|
(1) videotestsrc produces a buffer
(2) pinossink makes a PinosBuffer from the input buffer. It will also
keep the buffer in a hash table indexed by the fd-index.
(3) pinossink receives an fd-release message from Pinos. It removes
the fd-index from the hashtable and
the hashtable and the buffer is unreffed
(4) the fd is returned to videotestsrc for reuse.
* client producer, server side
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
socketsrc pinossocketsink
| |
------> (1) | (2)|
|----------->|
| | (3) -------->
| | ....
| (4)|
| | ....
| |
| (6)| (5) <--------
<------- (7)|<-----------|
| |
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
(1) pinos buffer arrives from a client. socketsrc wraps the
fd
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
(2) pinossocketsink sets a weak-ref on the buffer to know when it is
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
freed.
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
(3) pinossocketsink sends the buffer to the clients
(4) for each buffer that is sent, the sink uses the fdmanager to map the
fd-index to a buffer and a client. it keeps a ref on the buffer
(5) release-fd is received from a client
(6) pinossocketsink removes the fd-index from the fdmanager. If all
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
clients released the fd, the buffer will be freeds, triggering
the DestroyNotify. This will then trigger an event with a release-fd
message to the source.
Remove vfunc from port Update docs Remove virtual functions from port, we don't want this to be changed.
2016-05-09 12:16:04 +02:00
(7) the source sends the release-fd message to Pinos
docs: update design docs Update design docs with some info about how the lifecycle of fds are managed.
2015-12-04 16:39:29 +01:00
add more debug statements
2016-04-11 15:26:15 +02:00
* client remove
When a client disconnects from pinos, it must have released all fd-indexes
that it received. Pinos will force a release and will reuse the fd-indexes
when the client disconnects.
doc: add simple design doc
2015-08-21 11:46:29 +02:00
Wire
----
Fixed header
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rework how clients connect. Add buffer flags. The idea is to make it possible to easily check when a buffer contains control information that we need to parse to update the port fields. Make the client create remote nodes and ports and set up proxies for them. Make a port base class implementing most of the logic to pass buffers locally and remotely. Remove most code from stream.c, it's now in the port. Make a portsink and portsrc that can write and read to/from any port. We use these in the server to send and receive data. Rework format negotiation. The final format is now sent in-line before the data. The server will select a format on output ports.
2016-05-17 09:38:30 +02:00
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
doc updates
2015-09-30 13:00:14 +02:00
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version : 4 bytes : message version
Rework how clients connect. Add buffer flags. The idea is to make it possible to easily check when a buffer contains control information that we need to parse to update the port fields. Make the client create remote nodes and ports and set up proxies for them. Make a port base class implementing most of the logic to pass buffers locally and remotely. Remove most code from stream.c, it's now in the port. Make a portsink and portsrc that can write and read to/from any port. We use these in the server to send and receive data. Rework format negotiation. The final format is now sent in-line before the data. The server will select a format on output ports.
2016-05-17 09:38:30 +02:00
Flags : 4 bytes : extra flags
doc updates
2015-09-30 13:00:14 +02:00
Length : 4 bytes : total message length
doc: add simple design doc
2015-08-21 11:46:29 +02:00
Followed by 1 or more type-length-data sections
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
doc: add simple design doc
2015-08-21 11:46:29 +02:00
<type> : 1 byte
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
<length> : variable length, 7 bits, high bit is continuation marker
Rework the wire protocol Send a command stream over the socket. Implement a new buffer object that holds the data and commands. Make iterator and builders to parse and construct buffers. Rework gstreamer elements to use new API for creating and parsing buffers. Add _release_buffer to notify a stream when we are done processing the buffer. This will eventually go all the way to the server and will allow us to do more complicated buffer management.
2015-08-24 16:41:04 +02:00
<data> : <length> bytes, see below for contents based on <type>
doc: add simple design doc
2015-08-21 11:46:29 +02:00
Types:
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
1: continuation section
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
Rest of the commands can be found in the shared memory region at
@offset and @size. A shared memory region is negotiated when the client
connects to the server.
<offset> : 8 bytes : offset
<size> : 8 bytes : size
2: header
More work on wire protocol Make separate payload for the header. Make release-fd payloads capture_buffer -> peek_buffer to avoid a copy remove release-buffer, we really need to release each fd in the buffer separately. provide_buffer -> send_buffer so that we can also use this to send the release-fd messages. in pinossrc, send back release-fd messages when the fd is no longer in use.
2015-08-31 16:47:32 +02:00
Header for payload
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PTS ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DTS-offset ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More work on wire protocol Make separate payload for the header. Make release-fd payloads capture_buffer -> peek_buffer to avoid a copy remove release-buffer, we really need to release each fd in the buffer separately. provide_buffer -> send_buffer so that we can also use this to send the release-fd messages. in pinossrc, send back release-fd messages when the fd is no longer in use.
2015-08-31 16:47:32 +02:00
<flags> : 4 bytes : buffer flags
<seq> : 4 bytes : sequence number
<pts> : 8 bytes : presentation time
<dts-offset> : 8 bytes : dts-offset
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
3: fd-payload section
Rework the wire protocol Send a command stream over the socket. Implement a new buffer object that holds the data and commands. Make iterator and builders to parse and construct buffers. Rework gstreamer elements to use new API for creating and parsing buffers. Add _release_buffer to notify a stream when we are done processing the buffer. This will eventually go all the way to the server and will allow us to do more complicated buffer management.
2015-08-24 16:41:04 +02:00
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
Used to send a block of data between client and server. The type of fd and
the possible operations on it are negotiated when the client connects.
Rework buffer API a little Use BufferIter and BufferBuilder instead of Packet* Make separate method to set the header so you can set it later and not only at builder init time. Add method to clear the builder if you want to abort. Add method to add fd to builder instead of in _add_fd_payload. This would make it easier to add multiple fd-payloads using data from the same fd. Pass PinosPacketFDPayload to add_fd_payload to make it symetric with the parsing code. We should be able to get the size from the VERSION passed when the builder was made. Add ideas about releasing the fds back to the server.
2015-08-26 12:46:28 +02:00
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| size ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fd-index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More work on wire protocol Make separate payload for the header. Make release-fd payloads capture_buffer -> peek_buffer to avoid a copy remove release-buffer, we really need to release each fd in the buffer separately. provide_buffer -> send_buffer so that we can also use this to send the release-fd messages. in pinossrc, send back release-fd messages when the fd is no longer in use.
2015-08-31 16:47:32 +02:00
<id> : 4 bytes : id of the fd-payload
<offset> : 8 bytes : offset
<size> : 8 bytes : size
<fd-index> : 4 bytes : index of fd
Rework the wire protocol Send a command stream over the socket. Implement a new buffer object that holds the data and commands. Make iterator and builders to parse and construct buffers. Rework gstreamer elements to use new API for creating and parsing buffers. Add _release_buffer to notify a stream when we are done processing the buffer. This will eventually go all the way to the server and will allow us to do more complicated buffer management.
2015-08-24 16:41:04 +02:00
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
4: release fd-payload
Rework buffer API a little Use BufferIter and BufferBuilder instead of Packet* Make separate method to set the header so you can set it later and not only at builder init time. Add method to clear the builder if you want to abort. Add method to add fd to builder instead of in _add_fd_payload. This would make it easier to add multiple fd-payloads using data from the same fd. Pass PinosPacketFDPayload to add_fd_payload to make it symetric with the parsing code. We should be able to get the size from the VERSION passed when the builder was made. Add ideas about releasing the fds back to the server.
2015-08-26 12:46:28 +02:00
Release a fd-payload with <id>
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More work on wire protocol Make separate payload for the header. Make release-fd payloads capture_buffer -> peek_buffer to avoid a copy remove release-buffer, we really need to release each fd in the buffer separately. provide_buffer -> send_buffer so that we can also use this to send the release-fd messages. in pinossrc, send back release-fd messages when the fd is no longer in use.
2015-08-31 16:47:32 +02:00
<id> : 4 bytes : the id number of the released fd-payload
doc: add simple design doc
2015-08-21 11:46:29 +02:00
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
5: format change
Perform an in-band format change. The following data blocks will be in this
new format.
doc: add simple design doc
2015-08-21 11:46:29 +02:00
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id | format ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More work on wire protocol Make separate payload for the header. Make release-fd payloads capture_buffer -> peek_buffer to avoid a copy remove release-buffer, we really need to release each fd in the buffer separately. provide_buffer -> send_buffer so that we can also use this to send the release-fd messages. in pinossrc, send back release-fd messages when the fd is no longer in use.
2015-08-31 16:47:32 +02:00
<format-id> : 1 byte : format id
<format> : 0-terminated : contains serialized format
doc: add simple design doc
2015-08-21 11:46:29 +02:00
add continuation packet Add continuation type packet that would make it possible to send commands using a piece of shared memory.
2015-08-31 17:10:44 +02:00
6: property changes
Notify a property change.
doc: add simple design doc
2015-08-21 11:46:29 +02:00
doc updates
2015-09-30 13:00:14 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key .... .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
doc: add simple design doc
2015-08-21 11:46:29 +02:00
<key> : 0-terminated : key
<value> : 0-terminated : value
doc updates
2015-09-30 13:00:14 +02:00
... : more key/values to fill length, 0 key or
message length is end
doc: add simple design doc
2015-08-21 11:46:29 +02:00
add refresh message Add a new refresh message to request a keyframe from the pinos server. pinospay: pass the refresh-request message upstream pinossink: turn refresh-request messages into events pinossrc: turn a keyframe event into a refresh-request message
2016-04-13 13:04:32 +02:00
7: refresh request
doc: add simple design doc
2015-08-21 11:46:29 +02:00
add refresh message Add a new refresh message to request a keyframe from the pinos server. pinospay: pass the refresh-request message upstream pinossink: turn refresh-request messages into events pinossrc: turn a keyframe event into a refresh-request message
2016-04-13 13:04:32 +02:00
Request a new refresh point
doc: add simple design doc
2015-08-21 11:46:29 +02:00
add refresh message Add a new refresh message to request a keyframe from the pinos server. pinospay: pass the refresh-request message upstream pinossink: turn refresh-request messages into events pinossrc: turn a keyframe event into a refresh-request message
2016-04-13 13:04:32 +02:00
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| request-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PTS ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<last-id> : the last seen id
<request-type> : the type of request
0 = keyframe
1 = keyframe+full headers
<PTS> : the timestamp when the refresh should be,
0 for as soon as possible
Reference in a new issue Copy permalink