You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Claude: Backport #4742 to 7.0: answer the stream video codec. v7.0.162
Backports #4742 (`c52c0f9a9`) to the SRS 7.0 release branch. Fixes#4738.
Playing an H.265 stream over WebRTC without ?vcodec= answered H.264 and
delivered no video. SrsRtcSource::init_for_play_before_publishing creates
one placeholder track per codec, H.264 first, and negotiate_play_capability
fell back to the first one whenever the client asked for no codec. A
non-WebRTC publisher keeps those placeholder tracks, and the RTMP-to-RTC
bridge builds RTP on the track of the codec it detects in the sequence
header, so the player subscribed to the H.264 SSRC while every packet
arrived on the H.265 one and SrsRtcPlayStream::send_packet dropped all of
them.
The rule is now the same for H.264, H.265 and AV1. Before publishing the
codec of the stream is unknown, so the client decides and any codec it asks
for is allowed. While publishing the stream decides: asking for no codec
answers the codec of the stream, and asking for a different one is refused,
because SRS never transcodes for WebRTC and that client could only ever get
a black picture. SrsRtcRtpBuilder::initialize_video_track records the codec
it selected on the source as bridge_video_codec_, which publish_video_codec
returns, and on_unpublish clears it so the next player may choose again. For
a WebRTC publisher, whose negotiated tracks replace the placeholders, the
single remaining track description is the codec of the stream.
Refuse a player with no matching track instead of answering audio only. The
previous code left track_descs empty and built an answer without video, so
the client waited for a track that never arrived; it now returns an SDP
exchange error naming the codec. This also makes a VP9 request before
publishing an error rather than silent audio.
Add an AV1 placeholder track for play before publishing, so that a client
can negotiate the codec that only a WebRTC publisher can produce.
Inject the collaborators these paths reach: ISrsRtcSSRCGenerator is a new
interface over SrsRtcSSRCGenerator, and SrsRtcSource and
SrsRtcPlayerNegotiator now hold config, statistic, shared timer and
generator pointers instead of reaching for the globals. ISrsAppConfig gains
the five RTC getters the bridge uses. Without this the negotiation path
cannot be exercised in a unit test.
Cover the matrix in srs_utest_workflow_rtc_conn.cpp with MockRtcPlayScenario:
play before publishing, an H.264 and an H.265 stream from the bridge, an AV1
stream from a WebRTC publisher, and an H.264-only client asking for an H.265
stream. The bridge cases assert the answered SSRC is the one the bridge
sends with, which is what the reported failure got wrong.
The source and test changes apply unchanged from 8.0. The version bump and
changelog entry are the 7.0 ones, and the skills issue record in #4742 does
not exist on this branch, so it is not backported.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
0 commit comments