search

zenomt / rtmfp-cpp

Secure Real-Time Media Flow Protocol (RTMFP) Library in C++
https://www.rfc-editor.org/rfc/rfc7016.html
MIT License
36 stars 8 forks source link

Received wrong RTMP packet #19

Closed doanquocnam closed 2 weeks ago

doanquocnam commented 2 weeks ago

Sometimes, RTMP player stops playing, I try to use ffplay to play an RTMP url from server and it dumps the error message: RTMP packet size mismatch 52249 != 10815/1

At the first time, I think that maybe there is some wrong from the network, internet. But when I make a overload test, using many tccon to connect to server at the same time this error often occurs , the ffplay rtmp player hangs up and shows the message: "RTMP packet size mismatch xxxx != yyyyy1"

zenomt commented 2 weeks ago

since this seems to happen during overload, i suspect this is being caused by RTMP messages exceeding their transmission deadlines and being abandoned by the server midway through transmission.

to see if the problem is related to this, you can effectively disable partial message expiration by running tcserver like this

$ ./tcserver -F inf ...other-args...

(this sets the "finish by margin", the time after starting to send a message by which it must finish, to infinity). let me know if the problem still happens with that setting. if it stops happening, that will help tell me where look. it's possible that ffplay doesn't understand the "Abort Message" protocol control message, which would trip it up in this way. i'd need to check ffplay source code to see for sure. it's also possible that i made a mistake in implementing that, but i've had correct interoperation with other software in the past and i haven't changed that code since.

note too that you can change the queue lifetime and expiration behavior on a per-stream basis with "query parameters" on the stream name. for example

streamName?finishByMargin=inf

see https://github.com/zenomt/rtmfp-cpp/blob/main/test/tcserver.md#adjusting-real-time-treatment-for-stream-playback for more information about adjusting those parameters per-stream, including limits.

zenomt commented 2 weeks ago

a workaround to your problem would be to have tcserver listen for "rtmp-simple" instead of "rtmp". "rtmp-simple" doesn't break messages into multiple chunks and always uses RTMP chunk type 0 for every message. to listen for "rtmp-simple", use -s instead of -b for your RTMP listen address.

zenomt commented 2 weeks ago

reading the FFmpeg source code, it appears that they do not handle the Abort Message protocol control message properly. if that message is received during the initial startup, the connection will just fail with an "unknown error". however, if that message arrives during normal operation after starting up, it's just ignored (if you have verbose logging enabled, it'll say "Unknown packet type received 0x02"). if that message is ignored, the chunk stream will be out of sync, and the next message to start would almost certainly trigger a "packet size mismatch".

in other words, FFmpeg does not completely implement RTMP. tcserver can accommodate this buggy client behavior by listening with "rtmp-simple" (-s addr:port) instead of "rtmp" (-b addr:port).

doanquocnam commented 2 weeks ago

@zenomt many thanks! I will try

zenomt commented 2 weeks ago

if this explains and works around your problem, please close this Issue. :)

doanquocnam commented 2 weeks ago

if this explains and works around your problem, please close this Issue. :)

I ran tcserver with rtmp-simple mode, and then took a overload test, and those issues have no longer happened. Thanks for your discussions! And this issue close now!

Many thanks!