| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Instead of caching all the data from the previous keyframe till right now and
sending it to the client in a burst, since latency is important, we instead wait
for the next keyframe before sending buffers to the clients. This will lead to
a delay of upto 128 frames before the stream starts.
The keyframe distance and hence the delay can be tweaked by setting the
"keyframe-max-dist" property on vp8enc in src/encode.c:create_webm_profile()
|
|
|
|
Store non-keyframe buffers sent to fakesink, and push them to all new clients
|
|
This is very spammy when we get content-length encoding PUT streams
|
|
Pointed out in a review by slomo
|
|
|
|
Now we also support Content-Length + Content-Range persistent HTTP connections
for stream data. If no further data is received before `server_timeout`, we
assume the stream has been closed.
This is used by souphttpclientsink for sending streams.
|
|
|
|
If no chunks are written to a client for 10 seconds, we end that stream and
clean it up. This is currently happening due to a bug, but might happen due to
bad/slow clients as well.
Instead of handling EOS from null samples, handle EOS through the signal
handler. This is a more reliable way of handling EOS, and also works when the
whole pipeline is torn down because the PUT stream ended.
|
|
We can only pull a new sample and write it out if the previous one has been
written, otherwise we get a segfault in SoupMessage.
|
|
|
|
|
