RTMP publishing fails with Dahua cameras

[daveisfera]

Which version are you using?

v0.17.13

Which operating system are you using?

• [X] macOS amd64 Docker

Describe the issue

Sending an RTMP stream from a camera with no audio and it's failing with this error:

2022/01/13 03:57:37 INF [RTMP] [conn 172.17.0.1:64268] closed (stream doesn't contain tracks with supported codecs (H264 or AAC))

Describe how to replicate the issue

1. start the server
2. publish with a camera that supports RTMP but no audio
3. observer above error

Did you attach a network dump?

yes (made the extension .log because it was on the list of approved extension and seemed like the "best" option)

no_audio.log

[aler9]

Hello, the problem here is that the camera sends a metadata packet that doesn't contain the video codec ID, therefore the server doesn't detect its video track. What is the model of the camera?

[daveisfera]

It's been a while since I ran this test, but I'm pretty sure it was a Dahua camera

[aler9]

This is linked to #386 - the RTMP metadata parser must be improved to support these non-standard clients.

[aler9]

I developed a patch to fix this issue; please try this nightly release and let me know if it works: [link removed]

[daveisfera]

Got the Dahua camera back out and it's now outputting the following:

2022/02/15 02:08:29 INF [RTMP] [conn 172.17.0.1:61324] opened
2022/02/15 02:08:29 INF [RTMP] [conn 172.17.0.1:61324] closed (invalid metadata)

[aler9]

Hello, data from your network dump was copy-pasted into unit tests, therefore something must have changed. Please provided another network dump.

[daveisfera]

dahua.log

I've attached a capture from the Dahua camera that is showing this issue when connecting.

[aler9]

Thanks for the pcap, i've developed another fix but this time i'm not merging it into the main branch until we're sure that it works.

Please try the attached release (or alternatively the "dahua" branch) and let me know if it works: [link removed]

[daveisfera]

This is the output when running with this commit:

2022/04/20 20:15:25 INF [RTMP] [conn 172.17.0.1:56478] opened
2022/04/20 20:15:26 INF [RTMP] [conn 172.17.0.1:56478] closed (EOF)

[aler9]

Hi, EOF means that the camera closed the connection.

Are you sure that the camera is publishing something? It switched from sending this metadata (no_audio.log):

flvio.AMFMap{
    {
        K: "width",
        V: float64(2688),
    },
    {
        K: "height",
        V: float64(1520),
    },
    {
        K: "framerate",
        V: float64(0o25),
    },
}

to sending this metadata (dahua.log):

null

That's why i'm asking.

Furthermore, logs with logLevel: debug and / or network dumps can be useful.

I know that this is taking time but there is no way to fix communication with a device unless... owning the device.

[daveisfera]

The camera streams video when I connect it to an RTMP input in MediaLive, so it can send video and I believe it is doing so (or at least trying to do so) when I point it as rtsp-simple-server

[aler9]

Hello, the RTMP metadata parsing mechanism was updated once again to support DJI drones - please try this nightly release, it may solve this issue too: https://github.com/aler9/rtsp-simple-server/issues/928#issuecomment-1150288247

[daveisfera]

Still disconnects with this output:

2022/06/13 20:49:56 INF [RTMP] [conn 172.17.0.1:64268] opened
2022/06/13 20:49:56 INF [RTMP] [conn 172.17.0.1:64268] closed (invalid metadata)

[aler9]

please try again with this new release:

rtsp-simple-server_v0.19.1-18-gf41e595_darwin_amd64.tar.gz rtsp-simple-server_v0.19.1-18-gf41e595_linux_amd64.tar.gz rtsp-simple-server_v0.19.1-18-gf41e595_linux_arm64v8.tar.gz rtsp-simple-server_v0.19.1-18-gf41e595_linux_armv6.tar.gz rtsp-simple-server_v0.19.1-18-gf41e595_linux_armv7.tar.gz rtsp-simple-server_v0.19.1-18-gf41e595_windows_amd64.zip

[daveisfera]

I tried that release and the most recent commits, but still have the same error.

[aler9]

what's the error reported in the logs when using the release linked in the previous post? null metadatas should be supported, so the error message shouldn't be "invalid metadata".

[daveisfera]

It's the same output as before:

2022/06/24 03:34:39 INF [RTMP] [conn 172.17.0.1:62286] opened
2022/06/24 03:34:39 INF [RTMP] [conn 172.17.0.1:62286] closed (invalid metadata)

[daveisfera]

I just pulled the latest changes and tried again and this is the line that's returning the error: https://github.com/aler9/rtsp-simple-server/blob/fb5aa7bbf23f89b3754157b4b8f3aa3788d7ae20/internal/rtmp/conn.go#L129

[aler9]

Hello, please be aware that i'm posting releases compiled from the dahua branch, therefore the right line is this one:

https://github.com/aler9/rtsp-simple-server/blob/680b52508e0631fedb53411dc3dd82103531373c/internal/rtmp/conn.go#L136

Anyway i don't have enough data to solve the issue. If i had the camera this would be solved in 5 mins, but since this is not the case, i have to rely on your dumps, but i already inserted the content of your dumps into unit tests, therefore i don't know what else to do. If you still want to solve this issue, please provide another network dump.

[daveisfera]

Oh sorry, I didn't realize that it was a branch. I just saw the version number in the builds and assumed it was from there. I did a build from the branch and this is now the output that I see:

2022/07/03 17:22:47 INF [RTMP] [conn 172.17.0.1:58042] opened
2022/07/03 17:22:48 INF [RTMP] [conn 172.17.0.1:58042] closed (EOF)

[aler9]

After the camera sends the metadata with "null" payload, it closes the connection to the server with no reason. I don't know what else to do.

[daveisfera]

Thanks for the effort. I'll take a look at the branch and see if I can get it working.

[aler9]

If you're a little familiar with Golang, in my opinion you have all the means to get this issue fixed. You can then send a pull request, and it will be merged.

[jquiroga-arg]

Hi @aler9 thanks for the effort, we really appreciate your work... Please any one can update status of Dahua Rtmp push to RTSPSimpleServer? I can help maybe with YouTube handshake network dump on a working escenario.

[rudyryk]

I'm also having issues with Dahua camera and it's 100% reproducuble. What info would be useful?

I've enabled a debug logging, but it's not very detailed:

2023/08/31 12:57:39 INF MediaMTX v1.0.1
2023/08/31 12:57:39 DEB path manager created
2023/08/31 12:57:39 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2023/08/31 12:57:39 INF [RTMP] listener opened on :1935
2023/08/31 12:57:39 INF [SRT] listener opened on :8890 (UDP)
2023/08/31 12:57:39 INF [API] listener opened on 0.0.0.0:9997
2023/08/31 13:00:47 DEB [API] [conn 172.20.0.1:59918] GET /v2/paths/list
2023/08/31 13:00:54 INF [RTMP] [conn 172.10.11.51:38186] opened
2023/08/31 13:00:54 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] created
2023/08/31 13:00:54 INF [RTMP] [conn 172.10.11.51:38186] is publishing to path 'rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy', 1 track (MPEG-4 Audio)
2023/08/31 13:00:58 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] destroyed (not in use)
2023/08/31 13:00:58 INF [RTMP] [conn 172.10.11.51:38186] closed (received a video packet, but track is not set up)
2023/08/31 13:01:03 INF [RTMP] [conn 172.10.11.51:38190] opened
2023/08/31 13:01:03 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] created
2023/08/31 13:01:04 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] destroyed (not in use)
2023/08/31 13:01:04 INF [RTMP] [conn 172.10.11.51:38190] closed (unexpected video packet)
2023/08/31 13:01:09 INF [RTMP] [conn 172.10.11.51:38192] opened
2023/08/31 13:01:09 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] created
2023/08/31 13:01:10 INF [RTMP] [conn 172.10.11.51:38192] is publishing to path 'rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy', 1 track (MPEG-4 Audio)
2023/08/31 13:01:11 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] destroyed (not in use)
2023/08/31 13:01:11 INF [RTMP] [conn 172.10.11.51:38192] closed (received a video packet, but track is not set up)
2023/08/31 13:01:16 INF [RTMP] [conn 172.10.11.51:38196] opened
2023/08/31 13:01:16 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] created
2023/08/31 13:01:17 INF [RTMP] [conn 172.10.11.51:38196] is publishing to path 'rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy', 1 track (MPEG-4 Audio)
2023/08/31 13:01:20 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] destroyed (not in use)
2023/08/31 13:01:20 INF [RTMP] [conn 172.10.11.51:38196] closed (received a video packet, but track is not set up)
2023/08/31 13:01:25 INF [RTMP] [conn 172.10.11.51:38198] opened
2023/08/31 13:01:26 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] created
2023/08/31 13:01:26 DEB [path rtmp/yOp8uJbHcfrzTtV7tbS98M7J6O0efivy] destroyed (not in use)
2023/08/31 13:01:26 INF [RTMP] [conn 172.10.11.51:38198] closed (unexpected video packet)
...

[aler9]

Hello @rudyryk , open a dedicated issue and provide a network dump of communication between the camera and the server. Instructions are shown when you open an issue.

This issue is too old and may be unrelated from your specific problen.

[rudyryk]

@aler9 I see, thank you! I'll try to push RTMP from my local Dahua camera. My guess is that it's some specific/incomplete protocol implementation on Dahua cameras. They work with Nginx-RTMP but when pushing to MediaMTX we get only audio track, while video track seems to be dropped by the server.

Hello, the problem here is that the camera sends a metadata packet that doesn't contain the video codec ID, therefore the server doesn't detect its video track. What is the model of the camera?

Looks like this is exactly what's happening.

Could you also please check email?

[rudyryk]

@aler9 Is it possible btw to get some dump or details on actually received data on the server side from MediaMTX? It's not always easy to get physical access to devices.

[aler9]

@rudyryk yes, open an issue and attach a network dump. The network dump contains exactly what the server sees, and i will put it into a camera simulator in order to replicate the issue.

[rudyryk]

@aler9 Thanks, I've opened a separate issue #2289 with network dump attached.