v1.3.4

The SRT gateway probed only the audio channel layout, so an H.265 push was admitted as first order and then died at earshot's muxer, with the reason reaching nobody but a container log. The gateway now probes the video codec as well and refuses what it cannot carry, and the refusal arrives as a sentence on the player page the pusher is already watching. An unresolved probe falls back to the previous behaviour rather than refusing.

H.265 is carried end to end. The MP4 codec tag differs per codec and cannot be deferred to ffmpeg, so the direct listener port now encodes the video codec alongside the track count and the gateway dials the matching one. H.264 keeps ports 9100 and 9101 unchanged, so a version-skewed deployment loses H.265 rather than breaking H.264.

Carrying H.265 is not the same as it playing. A browser without an HEVC decoder reports no support, the player drops the video track, and the viewer gets no picture while the clock advances and every check reports healthy. This stack passes video through and cannot transcode a fallback rung, so a guest pushing H.265 narrows the audience for that session.

The silent stereo keep-alive AdaptationSet ships on every live path, asserted by the pipeline test with the codec the effective FFMPEG_FLAGS implies. docs/IOS-SAFARI.md is corrected: measured on an iPhone Xs, the track does not stop iOS suspending a backgrounded element, since iOS restricts background playback by media type. It makes the session resumable instead, the Now Playing entry producing sound rather than silence. On macOS it prevents the loss outright, unchanged.