RTMP publishing fails with "invalid body size"/"invalid message type: 255"

[pannal]

Which version are you using?

1.10.0

Which operating system are you using?

Linux amd64 Docker

Describe how to replicate the issue

1. start the server
2. publish with FFMPEG -c:v h264_vaapi -b:v 14M -rc_mode CBR -map 0:0 -map 0:1 -c:a aac -b:a 128k -v verbose -f mpegts rtmp://ip:port/path
3. stream starts but closes after a few seconds and FFmpeg receives a broken pipe

This happens with either h264_vaapi hevc_vaapi and libx264.

Server logs

mediamtx  | 2024/12/03 13:43:37 INF [RTMP] [conn xxxxxxx:41666] is publishing to path 'panni', 2 tracks (H264, MPEG-4 Audio)
mediamtx  | 2024/12/03 13:43:37 DEB [path panni] destroyed: not in use
mediamtx  | 2024/12/03 13:43:37 INF [RTMP] [conn xxxxxxx:41666] closed: invalid body size
mediamtx  | 2024/12/03 13:43:59 INF [RTMP] [conn xxxxxxx:43598] opened

mediamtx  | 2024/12/03 13:44:33 INF [RTMP] [conn xxxxxxx:56878] opened
mediamtx  | 2024/12/03 13:44:33 DEB [path panni] created
mediamtx  | 2024/12/03 13:44:33 DEB [path panni] destroyed: not in use
mediamtx  | 2024/12/03 13:44:33 INF [RTMP] [conn xxxxxxx:56878] closed: invalid message type: 255

Network dump

No response

[pannal]

Using flv instead of mpegts works. Then requesting the stream via HLS fails hard, though:

mediamtx  | 2024/12/03 13:53:46 INF [RTMP] [conn xxxxxxx:47054] is publishing to path 'panni', 2 tracks (H264, MPEG-4 Audio)
mediamtx  | 2024/12/03 13:54:02 DEB [HLS] [conn xxxxxxx:8680] [c->s] GET /panni/index.m3u8 HTTP/1.1
mediamtx  | Host: hostname:8888
mediamtx  | Accept: */*
mediamtx  | Connection: close
mediamtx  | Icy-Metadata: 1
mediamtx  | Range: bytes=0-
mediamtx  | User-Agent: Lavf/61.7.100
mediamtx  |
mediamtx  |
mediamtx  |
mediamtx  | 2024/12/03 13:54:02 INF [HLS] [muxer panni] created (requested by xxxxxxx:8680)
mediamtx  | 2024/12/03 13:54:02 INF [HLS] [muxer panni] is converting into HLS, 2 tracks (H264, MPEG-4 Audio)
mediamtx  | 2024/12/03 13:54:05 WAR [HLS] [muxer panni] part duration changed from 201ms to 220ms - this will cause an error in iOS clients
mediamtx  | 2024/12/03 13:54:05 WAR [HLS] [muxer panni] part duration changed from 220ms to 222ms - this will cause an error in iOS clients
mediamtx  | 2024/12/03 13:54:06 DEB [HLS] [conn xxxxxxx:8680] [s->c] HTTP/1.1 500 Internal Server Error
mediamtx  | Access-Control-Allow-Credentials: true
mediamtx  | Access-Control-Allow-Origin: *
mediamtx  | Server: mediamtx
mediamtx  |
mediamtx  |
mediamtx  |
mediamtx  |
mediamtx  | 2024/12/03 13:54:06 INF [HLS] [muxer panni] destroyed: muxer error: unable to extract DTS: DTS is greater than PTS

[aler9]

Thanks for reporting the RTMP issue, this is fixed by #4018.
Regarding the HLS issue, it's unrelated, open another issue and provide a network dump or a way to replicate.

[pannal]

Awesome, thank you.

Instead of immediately opening another issue: is it possible to remux ERTMP containing AV1 to mpegts/HTTP-FLV with this software, already?

If not, I'll open a ticket for this. Thanks!

[aler9]

is it possible to remux ERTMP containing AV1 to mpegts/HTTP-FLV with this software, already?

AV1 cannot be muxed into MPEG-TS since the specification to do it is currently not implemented by any player, therefore implementing it inside the server would be useless. It can be muxed into fMP4 though, so you can mux AV1 into HLS+fMP4.

[pannal]

It is, though :)

xqq/mpegts.js@07b5766

Edit: I guess mpegts.js uses the draft.

[aler9]

@pannal glad to hear that something is moving in the right direction, unfortunately FFmpeg, GStreamer and VLC are still missing this ability. We can evaluate the situation again in some months.

Anyway, when player support improves, we will add the ability to carry AV1 tracks with SRT+MPEG-TS, not with HTTP+MPEG-TS. We already support shipping AV1 to browsers through HLS+fMP4 and through WebRTC, and HTTP or FLV have no advantages over them.

[pannal]

Awesome, thank you. I think focusing on SRT as a protocol for delivering AV1 is fine - why ignore the Enhanced RTMP V2 spec, though? Or am I misunderstanding here.

[aler9]

We already support shipping AV1 with enhanced RTMP :D I know that the specification was recently updated and we are missing the last bits but they will be added.

[pannal]

Ah. Well, if you're talking about HTTP-FLV/MPEGTS for for example mpegts.js, I'd make a strong argument for AV1 here as well, simply for ease of use. Having to implement hls.js besides mpegts.js might be a hassle for the users. Additionally, sub-1-second live-streaming is still an advantage of HTTP-FLV/MPEGTS over HLS-LL to my knowledge.

Edit: Also why wouldn't you, if you internally already handle AV1 in MPEGTS? Or, again, am I misunderstanding your point?
Edit 2: Wait, you're not, ERTMP uses FLV, not MPEGTS

[pannal]

Sorry, I'm a little confused now :D

[github-actions]

This issue is mentioned in release v1.11.0 🚀
Check out the entire changelog by clicking here