DJI Osmo Action 4: Audio track not set up (RTMP)

[ThisIsntTheWay]

Which version are you using?

v1.9.0

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

When starting an RTMP stream with the DJI Osmo Action 4, a lot of times MediaMTX will immediately terminate the stream as the audio track is not set up but an audio packet is received.

When configuring a live stream, the DJI app offers the following options:

• Resolution
  • 480p (smooth)
  • 720p (HD)
  • 1080p (UHD)
• Streaming Quality
  • Auto
  • Smooth
  • HD
• EIS (Stabilization)
  • Off
  • Various modes of "Rocksteady"

Pretty much any configuration will result in this error, but from experience setting 1080p/HD will, most of the time, result in MediaMTX actually setting up an audio track and the stream actually working.
Curiously, once one successful attempt has been made, relaunching the livestream with a different configuration will work as well.

The camera is running with the following firmware versions:

Firmware: 01.04.07.10
Camera Firmare: 10.04.00.10

(Not sure why there's two)

Describe how to replicate the issue

1. Start server
2. Initiate RTMP live stream on camera
3. MediaMTX recognizes a connection but won't set up an audio track
4. The stream terminates

Did you attach the server logs?

yes (Excerpts)

Instance of a failed stream:

INF [RTMP] [conn 172.18.0.1:34254] opened
INF [RTMP] [conn 172.18.0.1:34242] is publishing to path 'glide', 1 track (H264)
INF [RTMP] [conn 172.18.0.1:34242] closed: received an audio packet, but track is not set up

Instance of a successful stream:

INF [RTMP] [conn 172.18.0.1:47558] opened
INF [RTMP] [conn 172.18.0.1:47558] is publishing to path 'glide', 2 tracks (H264, MPEG-4 Audio)

Did you attach a network dump?

Attached are multiple dumps, mostly failed ones and with different quality configurations.
A dump of a successful stream has also been attached.

I'm not sure if there's actually any meaningful difference between the failed dumps, but I attached them nonetheless.
dumps.zip

[NoahFetz]

Can confirm, experiencing the same issue

[aler9]

Hello, in #4088 (included in v1.11.0) the RTMP track detection mechanism was rewritten from scratch, and bugs like this one should be definitively fixed. Please test the last release and let me know whether the issue is solved. Otherwise provide logs and network dumps (again).

[ThisIsntTheWay]

Thanks for the info.
Using version 1.11.0, streaming still doesn't work but is reporting a different error this time.
Downgrading to version 1.10.0 I was lucky to getting it to to work once, before the usual audio track thing reoccurred.

The camera has been running with the same firmware, although I did receive a prompt to update to V01.06.0410.
With this new firmware, streams to version 1.11.0 still failed.

Network dumps are available here.

# Failure - 1.11.0
❯ docker run --rm -it -p 1935:1935 bluenviron/mediamtx:1.11.0
2025/01/05 13:59:32 INF MediaMTX v1.11.0
2025/01/05 13:59:32 INF configuration loaded from /mediamtx.yml
2025/01/05 13:59:32 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2025/01/05 13:59:32 INF [RTMP] listener opened on :1935
2025/01/05 13:59:32 INF [HLS] listener opened on :8888
2025/01/05 13:59:32 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2025/01/05 13:59:32 INF [SRT] listener opened on :8890 (UDP)
2025/01/05 13:59:37 INF [RTMP] [conn 172.17.0.1:36772] opened
2025/01/05 13:59:38 INF [RTMP] [conn 172.17.0.1:36772] closed: video track 0 already setupped
2025/01/05 13:59:38 INF [RTMP] [conn 172.17.0.1:43490] opened
2025/01/05 13:59:39 INF [RTMP] [conn 172.17.0.1:43490] closed: EOF

# Success - 1.10.0
❯ docker run --rm -it -p 1935:1935 bluenviron/mediamtx:1.10.0
2025/01/05 14:05:05 INF MediaMTX v1.10.0
2025/01/05 14:05:05 INF configuration loaded from /mediamtx.yml
2025/01/05 14:05:05 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2025/01/05 14:05:05 INF [RTMP] listener opened on :1935
2025/01/05 14:05:05 INF [HLS] listener opened on :8888
2025/01/05 14:05:05 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2025/01/05 14:05:05 INF [SRT] listener opened on :8890 (UDP)
2025/01/05 14:05:26 INF [RTMP] [conn 172.17.0.1:42160] opened
2025/01/05 14:05:28 INF [RTMP] [conn 172.17.0.1:42160] is publishing to path 's', 2 tracks (H264, MPEG-4 Audio)
2025/01/05 14:05:37 INF [RTMP] [conn 172.17.0.1:42160] closed: EOF # Manually terminated

This was done using the following stream settings, but any configuration fails (on 1.11):

• Resolution: 720p
• Quality: Auto
• Stabilization: RockSteady

[aler9]

@ThisIsntTheWay thanks for the feedback, please test this nightly release and let me know if the issue is fixed (click on "artifacts", "binaries"):

https://github.com/bluenviron/mediamtx/actions/runs/12632899660

[ThisIsntTheWay]

@aler9 Much appreciated!
I can confirm that using v1.11.0-4-7e58edfd now results in much more reliable streams.
Subsequent attempts with different streaming configurations also worked without issues.

[github-actions]

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