Honestly, RTMP is a workhorse that powers most live video ingest today; its not bad, its just mostly frozen in time. Some issues that came immediately to mind are:
- It was developed to support flash; if anyone is sending metadata about the data streams are probably serializing flash objects, which is truly an experience when writing go.
- The supported codecs are limited and the spec provides no generic way to extend it. If you want h264 and aac, RTMP is great. If you want any codec developed after that, you need to either reach for another protocol or use a non-standard extension to RTMP whose support across different providers is flaky.
- Its TCP under the hood and that locks you to a fixed reliability/performance tradeoff.
- The 'spec' is a document released by Adobe which is not particularly great, falling pretty far short of what we'd expect out of the IETF or similar. Its overly detailed in some areas and woefully under detailed in others.
- RTMP isn't particularly tune-able; if you want to tradeoff latency for quality or similar, you're exploring the dark depths of the protocol.
None of these are damning but, as an aggregate, they go a long way to encouraging new protocols to be developed which avoid these issues.
> What problems do you have with "maintaining an RTMP stack" does any of these newer protocols alleviate? What do you mean exactly by RTMP stack so I can be sure I understand you correctly?
Maintaining an RTMP stack, at least for me, means making sure your implementation of underspecified RTMP works with other, third party implementations of underspecified RTMP. Some implementations are great(ffmpeg and OBS) whereas some will send you timestamps that oscillate between the correct time and 3 billion seconds in the future; or, they'll send you exactly 3 packets at the start of the connection with timestamps far off in the future. More subtly, some providers want you to send a packet when you're closing the connection and others just want to go away and get angry if you send them a 'goodbye' packet.