librtmp2 0.13.0

Changed

• Breaking (Rust API, not part of the extern "C" surface):
  AuthorizationResult::Pending now carries the integrator's request_id, and
  complete_publish_authorization / complete_play_authorization (on both
  Conn and Server) take it. A completion therefore resolves only the request
  it was issued for: a decision for a request the connection has already
  discarded -- its stream torn down or replaced, or the opposite role granted in
  the meantime -- is ignored instead of being applied to whichever request holds
  the slot by then. The id must be unique per connection and role; a request
  reusing an id the connection already answered is denied, because its
  completion could not be told apart from the one still owed for the earlier
  request.
• The pending-authorization slot is no longer kept occupied by a tombstone after
  a teardown or after the opposite role is granted. The freed slot is usable by
  the next request immediately, so such an event no longer costs a new publish
  or play request a full pending-auth timeout before it can be decided.
• The publish-side media/route gates consult only a pending publish decision,
  and the player-side gates only a pending play decision. A play request
  awaiting a decision no longer stops an already-authorized publisher's relay
  (and vice versa); a republish awaiting a decision still stops that publisher's
  media, as before.

Removed

• The internal withdrawn tombstone mechanism on pending authorizations, which
  request ids replace.

Benchmarks

Measured automatically for this release on a CI runner; the machine is described below. Raw data: bench-results-v0.13.0.json.

• Measured: 2026-10-13 23:52:09 UTC · 77bcd8d · crate version 0.13.0 · workflow run
• CPU: AMD EPYC 7763 64-Core Processor · 4 vCPUs
• RAM: 15.6 GiB
• System: Linux 6.17.0-1022-azure x86_64 · rustc 1.99.0 · GitHub-hosted ubuntu24 (image 20261004.327.1)
• Noise: shared CI VM — CPU model, neighbouring load and the runner image change between runs, so treat absolute numbers as indicative.
• Comparable vs release v0.12.0: ✅ same CPU model, vCPU count, rustc and runner image; shared-VM noise of a few percent remains

protocol

Benchmark	Time	Throughput	vs release v0.12.0
amf0_build_connect	218 ns	—	⚪ −0.7 %
chunk/write_read_roundtrip	6.84 µs	~571 MiB/s	🔴 +16.0 %
flv/audio_tag_aac	1.25 ns	—	⚪ +0.6 %
flv/video_tag_h264	1.25 ns	—	⚪ −0.0 %
fourcc_to_video_codec_avc1	2.50 ns	—	⚪ +0.2 %
server_read_c1	1.06 µs	—	⚪ −0.1 %

relay

Benchmark	Time	Throughput	vs release v0.12.0
relay/publish_to_player/100	97.3 ms	~1028 elem/s	⚪ +0.3 %
relay/publish_to_player/500	98.8 ms	~5058 elem/s	⚪ −1.5 %

🟢 faster · 🔴 slower · ⚪ within the noise band (5–25 % depending on how comparable the two environments are, plus both runs' Criterion confidence intervals). Lower time is better.