Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTMP publishing fails with Dahua cameras #769

Closed
1 task done
daveisfera opened this issue Jan 13, 2022 · 32 comments · Fixed by #2298
Closed
1 task done

RTMP publishing fails with Dahua cameras #769

daveisfera opened this issue Jan 13, 2022 · 32 comments · Fixed by #2298
Labels
bug Something isn't working rtmp

Comments

@daveisfera
Copy link

Which version are you using?

v0.17.13

Which operating system are you using?

  • 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
Copy link
Member

aler9 commented Jan 25, 2022

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?

@aler9 aler9 added the bug Something isn't working label Jan 25, 2022
@daveisfera
Copy link
Author

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

@aler9
Copy link
Member

aler9 commented Jan 27, 2022

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

@aler9
Copy link
Member

aler9 commented Feb 12, 2022

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

@daveisfera
Copy link
Author

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
Copy link
Member

aler9 commented Feb 15, 2022

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

@daveisfera
Copy link
Author

dahua.log

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

@aler9
Copy link
Member

aler9 commented Apr 18, 2022

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]

@aler9 aler9 changed the title RTMP push fails when no audio RTMP publishing fails with Dahua cameras Apr 18, 2022
@daveisfera
Copy link
Author

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
Copy link
Member

aler9 commented Apr 21, 2022

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
Copy link
Author

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
Copy link
Member

aler9 commented Jun 11, 2022

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:
#928 (comment)

@daveisfera
Copy link
Author

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)

@daveisfera
Copy link
Author

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

@aler9
Copy link
Member

aler9 commented Jun 23, 2022

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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

aler9 commented Jul 2, 2022

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
Copy link
Author

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
Copy link
Member

aler9 commented Jul 4, 2022

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
Copy link
Author

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

@aler9
Copy link
Member

aler9 commented Jul 5, 2022

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.

@aler9 aler9 added the rtmp label Jan 22, 2023
@jquiroga-arg
Copy link

jquiroga-arg commented Jun 27, 2023

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
Copy link

rudyryk commented Aug 31, 2023

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
Copy link
Member

aler9 commented Aug 31, 2023

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
Copy link

rudyryk commented Sep 1, 2023

@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
Copy link

rudyryk commented Sep 1, 2023

@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
Copy link
Member

aler9 commented Sep 1, 2023

@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
Copy link

rudyryk commented Sep 4, 2023

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

@aler9
Copy link
Member

aler9 commented Sep 5, 2023

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.

Copy link
Contributor

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.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working rtmp
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants