closed: received a video packet, but track is not set up

[hotwinters]

Which version are you using?

1.9

Which operating system are you using?

Linux amd64 standard

Describe how to replicate the issue

1. start the server
2. publish with gliveT80 rtmp
3. read with

Server logs

closed: received a video packet, but track is not set up，Sometimes it succeeds, using nginx-rtmp will definitely succeed

Network dump

No response

[aler9]

Hello, this compatibility issue can be solved if you provide a network dump, that can be generated in this way:

• Download wireshark (https://www.wireshark.org/)
• Start capturing on the interface used for exchanging packets
  • If the server and the external hardware or software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card.
• Start the server and replicate the issue
• Stop capturing, save the result in .pcap format
• Attach

[aler9]

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).

[hotwinters]

@aler9 hi,Sorry for not noticing the message. When I was live streaming to mediamtx on some streaming devices, I found that the reason why the track could not be set was due to time timeout. When the first video packet arrived, the timestamp of the packet was set to 0, and the timestamp of the second video packet was set to the current live time, which caused mediamtx to timeout. So I changed it to the system time for analysis timeout verification before. I don't know if this is correct, but it is feasible