search

bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
11.64k stars 1.47k forks source link

RTMP publishing fails with Dahua cameras #769

Closed daveisfera closed 1 year ago

daveisfera commented 2 years ago

Which version are you using?

v0.17.13

Which operating system are you using?

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 commented 2 years ago

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 commented 2 years ago

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

aler9 commented 2 years ago

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

aler9 commented 2 years ago

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

daveisfera commented 2 years ago

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 commented 2 years ago

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

daveisfera commented 2 years ago

dahua.log

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

aler9 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

aler9 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

aler9 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

aler9 commented 1 year ago

This is supposedly fixed with #2298, which was developed from data provided in #2289, which is very similar to the data attached here. If the bug persists, feel free to open another issue.

github-actions[bot] commented 6 months ago

This issue is being locked automatically because it has been closed for more than 6 months. Please open a new issue in case you encounter a similar problem.