handlerLogger's responseRecorder and handlerWriteTimeout's writeTimeoutWriter
both wrap http.ResponseWriter but implement neither http.Flusher nor Unwrap().
Any handler that flushes mid-response has that flush silently dropped, and its
output only reaches the client when the handler returns.
That defeats the stated purpose of writeTimeoutWriter, whose own comment says it
exists so one can "write long responses, splitted in chunks, without causing
timeouts": the deadline is reset per Write(), but nothing ever leaves the buffer
until the end.
Found while adding a server-sent-events endpoint: events written and flushed at
t=0.4s only reached the client at t=2.2s, when the handler returned.
Adding Flush() plus Unwrap() (so http.ResponseController can reach through) fixes
both. The new test drives a real listener through both wrappers and reads while
the handler is still blocked, so it fails on the current code by hitting the read
deadline.
webrtc.ConfigureNack() only wires up the NACK RTCP interceptor. pion
still needs an explicit RTX codec registered per media codec before it
can answer a publisher's retransmission offer with one, so
incomingVideoCodecs having none means NACK-triggered retransmission
can never actually happen for incoming video, no matter what the
publisher offers.
Fixes#5678
---------
Co-authored-by: aler9 <46489434+aler9@users.noreply.github.com>
When changing configuration in parallel by editing the configuration
file and calling the API, the server could get into a deadlock that
prevented any further action. This is fixed.
Reply with NetStream.Play.Failed or NetStream.Publish.Unauthorized when
a client is not authorized to play or publish. This makes clients like
OBS to stop recreating the connection in case of authentication
failures.
mDNS candidates sometimes require a large CPU portion, they are not
involved in any connectivity method mentioned in the documentation, they work in
local networks only.
It is now possible to define forward destinations for each path configuration. For each destination, the server will create a client that will forward the stream to the intended destination. Supported protocols are RTSP, RTMP, SRT. API and metrics have also been improved to allow monitoring the new forwarding system.
---------
Co-authored-by: aler9 <46489434+aler9@users.noreply.github.com>
Chrome sometimes sends empty packets, that are discarded by the server,
but the sequence number of following packets is not recomputed,
leading downstream packet loss detectors to emit errors. This is fixed.
When ingesting tracks with WebRTC, track order was randomized,
preventing multi-track always-available streams from working reliably,
since they require tracks to be ordered in a precise way.
WebRTC tracks are not ordered by MID, RID, trackID and streamID
respectively.
when a user had previously inserted credentials into a MediaMTX
instance through a browser, and AllowOrigins was set to a wildcard,
third-party websites visited by the user were allowed to read streams
without restrictions. This is now prevented by returning "*" in
Access-Control-Allow-Origins when AllowOrigins is a wildcard, a
behavior that prevents browsers from sharing credentials with
third-party websites.
Since #4866, hostnames in webrtcAdditionalHosts are resolved server-side via
net.LookupIP, and a resolution failure aborts the entire WHEP/WHIP session.
A single entry that can't be resolved on the server (e.g. air-gapped networks
without DNS, or a name that only resolves on the client) therefore takes down
all WebRTC playback, even when the other entries are valid.
Log a warning and skip the unresolvable entry instead of returning an error,
so the remaining valid candidates are still offered.
Signed-off-by: suMin <sumin77123@gmail.com>
Support PROXY protocol v1/v2 on RTMP, RTMPS, RTSP, and RTSPS TCP
listeners so real client IPs are visible when running behind L4 proxies
(nginx stream, HAProxy, AWS NLB).
---------
Co-authored-by: aler9 <46489434+aler9@users.noreply.github.com>
Media-over-QUIC is a streaming protocol built upon cutting edge
protocols (QUIC, HTTP3) and browser APIs (WebTransport, WebCodecs).
It's slightly faster than WebRTC, has an advanced data recovery
mechanism (placed at the frame level and not at the packet level), it
supports additional codecs (FLAC) and is less complicated to route.
