Proposal: Use fragment identifier in RTMP URI to name a stream to play or publish

[zenomt]

Section 7.2.1.1 of the RTMP Spec misleadingly implies that the (incompletely described) interpretation by Adobe Media Server of the tcUrl property of the connect command's Command Object has a fixed form for the path component of the URI. it is incorrect that the path of a generic RTMP URI must have exactly two segments.

Adobe Media Server itself accepts any number of segments in the path component. it happens to treat the first segment as the name of an application (and the subdirectory where to find its configuration and media files), and the second and subsequent segments (with their slashes) together as the name of an instance of that application. regardless, this is an implementation-specific behavior of Adobe Media Server. other servers might not even have "applications" or "instances", or might treat the entire path (and the optional query component of the URI) as identifying a more abstract "resource" within the server.

some clients, like VLC, assume that the path component has exactly two segments, and use any subsequent path components (including their slashes) of a given RTMP URI as the name of a stream to play, rewriting the given URI to only have the first two segments before setting tcUrl and app. this interpretation and behavior is not consistent with the generic syntax and semantics for URIs, and it is not interoperable with all possible servers, or even with Adobe Media Server's possible behavior.

i propose that a portion of the fragment identifier (Section 3.5 of RFC 3986) (the part that comes after the #) of an RTMP-family URI (rtmp:, rtmps:, rtmpe:, rtmfp:, ...) should be used to identify a stream name to play (or publish, according to context) at an RTMP server resource. specifically, it should be the portion of the fragment identifier up to the first ? character, if any, with the portion after the first ? reserved for key+value pairs or flags that might otherwise affect the client's behavior. note RFC 3986's description of what the fragment identifier is for:

The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.

since a connection to an RTMP server doesn't itself have a "representation" or a "media type" (in the sense of RFC 3986), and in fact dereferencing an RTMP URI isn't a "retrieval" operation but is instead a "connect" operation, the semantics of the fragment identifier are unconstrained according to Section 3.5 of RFC 3986. within the context of an RTMP connection (and especially with a client expecting to publish or play one stream), the most likely and logical "secondary resource" one might mean would be the stream.

examples:

(1) rtmp://server.example/three/part/path#BigBuckBunny
(2) rtmp://[2001:db8:1::2]:50002/something?else#BigBuckBunny?TBD=3&aFlag

both examples specify a stream named BigBuckBunny. (1) has a path with three segments. (2) has a path with one segment, a query component for the server, and additional not-yet-defined client parameters (a value for imaginary client parameter TBD and an imaginary flag). in both cases, the fragment identifier would not be sent to the server in the tcUrl or app properties:

#	tcUrl	app
1	rtmp://server.example/three/part/path	three/part/path
2	rtmp://[2001:db8:1::2]:50002/something?else	something

if the Enhanced RTMP community thinks this is a good idea, i think a future revision of the Enhanced RTMP Spec should specify this behavior for clients to adopt.

EDIT 2023-07-16: my proposal is revised later in this thread such that the entire fragment identifier identifies a secondary resource of the server (like a stream name to play or publish), and no portion of the fragment identifier is reserved for parameters to be interpreted by the client. the meaning any portions of the fragment identifier (such as portions after the first ? if any) belong to the server, not to the client.

[veovera]

This is a really thoughtful writeup! We are currently working on E-RTMP (aka Enhanced RTMP) V2. We will look at the above closer when we are editing that part of the spec:)

[zenomt]

i have modified my tcpublish and tcconn tools to follow this proposal.

[zenomt]

on reflection i think it might be better to make a separate document specifically for the RTMP family URIs syntax and semantics, especially for updating the IANA scheme registry (currently rtmp and rtmfp are registered there).

(EDIT: removed URI syntax ABNF)

i will work on this document this week.

[zenomt]

i think there's a good argument for not reserving a portion of the fragment identifier "for key+value pairs or flags that might otherwise affect the client's behavior"; in other words, the client shouldn't separate out the portion before the first ? in the fragment or interpret any portions of the fragment beyond "it's a stream name". instead the whole fragment identifier should be passed to the server as the stream name in a play or publish, since the fragment is for identifying a "secondary resource".

i'm going to think about this more, but input would be appreciated.

[zenomt]

i will work on this document this week.

here is a first draft: https://github.com/zenomt/rtmp-errata-addenda/blob/main/rtmp-uris.md

community input is requested, particularly in formalizing the userinfo and fragment usage, before i ask IANA to update the scheme registry.

[zenomt]

i've made some tweaks to the RTMP URIs draft for readability, and identified places where URI percent-decoding should be performed.

[zenomt]

i think there's a good argument for not reserving a portion of the fragment identifier "for key+value pairs or flags that might otherwise affect the client's behavior" [...] i'm going to think about this more, but input would be appreciated.

i thought about this more and i'm convinced the client shouldn't interpret any parts of the fragment, and instead should use it in its entirety to the server to identify the "secondary resource" according to the server.

in that spirit, i've adjusted my implementations to treat the entire fragment portion as the name of the stream to be sent to a play or publish RPC. i also adjusted my server to interpret items after the first ? of the stream name as parameters/arguments to the play or publish. i think this is more in the spirit of URIs and "resources" and which party is the naming authority.

examples of parameters my server understands: for play, adjusting the queue lifetimes (transmission deadlines) for video and audio frames, whether to expire the previous GOP early when starting a new GOP, and whether to send frame timestamps "as-is" exactly as the publisher gave, or translated to start at 0 (as Adobe Media Server does); for publish the "publish priority" (used for preempting/overriding another publish of the same stream) can be adjusted. previously for my server these were set with a non-standard second RPC argument after the stream name; that meant only specially coded clients could set those parameters. including them in the stream name as a "query" means any client (like FFmpeg) that passes in an opaque stream name can be used to set these parameters.