RTMP is FLV based, so RTMP is best performance on output FLV. (Just write, without modification)
As I think, In Low-latency scenario, RTMP=>FLV=>fMP4 has overhead. How about RTMP directly push fMP4 to CDN?

Structure of fMP4

ISOBMFF is documented as [ISO/IEC 14496-12].
Mandatory structure is ftyp and moov, that can be found in [Table 1 — Box types, structure, and cross-reference (Informative)].
Fragment need pair of moof and mdat.
ftyp and moov is commonly grouping and saying initial segment.
moof and mdat contain real video/audio data contain.
moof has offset of data that pointed mdat’s payload.
tfhd in the moof has base-data-offset that used to calculate data offset.
tfhd has a flag named default‐base‐is‐moof, that means base-data-offset = 0 meaning moof box’s start offset.

Current status

Basic fMP4 segment generation and HLS metadata creation work
Stream by ffmpeg -re -i <filename> -vcodec copy -acodec copy -f flv rtmp://<address>:<port>/<app>/<stream key> works well
Stream by OBS have a problem, no sound playable. OBS’s setting is correct that I checked by Recording.
- Maybe need to check AudioSpecificConfig related? Currently just skipped.

I pivoted from RTMP=>FLV to RTMP=>fMP4, due to it seems overhead, no benefit, to minimize implementation range.
Write ISOBMFF I/O library that specifically support playable fragmented mp4, that support ftyp, moov and moof.
Currently has some unknown bugs, like non playable audio in specific scenario.