在mediasoup（webrtc）--》rtp---》zlm，前面60秒会出现蓝屏或模糊情况，重新观看rtmp也会出现 about zlmediakit

[ouxiand]

'packetization-mode': 1,
'profile-level-id': '42e032',
'level-asymmetry-allowed': 1 感觉这块配置和zlm对不上

[xiongguangjie]

在ZLM服务器上，抓包分析吧。ZLM的日志呢？是否有丢包的打印

[ouxiand]

2024-06-04 14:57:09.224 W [MediaServer] [66570-event poller 3] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:57:12.591 W [MediaServer] [66570-event poller 3] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:57:15.892 W [MediaServer] [66570-event poller 3] MediaSink.cpp:169 emitAllTrackReady | Track not ready for a long time, ignored: H264
2024-06-04 14:57:33.892 I [MediaServer] [66570-event poller 0] MultiMediaSourceMuxer.cpp:561 onAllTrackReady | stream: rtp://defaultVhost/rtp/294826D8 , codec info: mpeg4-generic[8000/1/16] H264[640/360/0]
2024-06-04 14:57:38.261 W [MediaServer] [66570-event poller 2] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:57:41.625 W [MediaServer] [66570-event poller 2] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:57:44.924 W [MediaServer] [66570-event poller 2] MediaSink.cpp:169 emitAllTrackReady | Track not ready for a long time, ignored: H264
2024-06-04 14:58:08.259 W [MediaServer] [66570-event poller 1] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:58:11.623 W [MediaServer] [66570-event poller 1] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:58:14.892 W [MediaServer] [66570-event poller 1] MediaSink.cpp:169 emitAllTrackReady | Track not ready for a long time, ignored: H264
2024-06-04 14:58:38.261 W [MediaServer] [66570-event poller 7] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:58:41.625 W [MediaServer] [66570-event poller 7] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:58:44.924 W [MediaServer] [66570-event poller 7] MediaSink.cpp:169 emitAllTrackReady | Track not ready for a long time, ignored: H264
2024-06-04 14:59:08.260 W [MediaServer] [66570-event poller 5] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:59:11.622 W [MediaServer] [66570-event poller 5] MediaSink.cpp:60 operator() | Cached frame of unready track(H264) is too much, now cleared
2024-06-04 14:59:11.662 I [MediaServer] [66570-event poller 5] MultiMediaSourceMuxer.cpp:561 onAllTrackReady | stream: rtp://defaultVhost/rtp/1C4DDFA7 , codec info: mpeg4-generic[8000/1/16] H264[640/360/0]
2024-06-04_00.log

[ouxiand]

本机的mediasoup和本地的zlm 不存在网络情况

[xiongguangjie]

1，你这个是h264 一直不发sps/pps 过来导致h264 等了6.7秒才收到sps/pps/I帧
2，这个你升级下内核吧（4.x及其以上），影响ZLM的性能

[xia-chu]

本机的mediasoup和本地的zlm 不存在网络情况

如果丢包了 zlm会打印丢包日志。
如果没丢包日志，那么可能是时间戳有问题，或者mediasoup本身丢包了 他把破损的帧重新打包成rtp了 所以seq是连续的

[xia-chu]

抱歉 我好像把这个issue和另外一个搞混了。 你这个问题应该就是sps pps idr缺失的问题，也就是mediasoup并没有第一次发gop给zlm。 你应该设置下mediasoup的gop间隔，让他大概2秒发一个pli关键帧请求rtcp。

[ouxiand]

请问下zlm的rtcp端口也是10000吗？ 还是10001？

[xiongguangjie]

请问下zlm的rtcp端口也是10000吗？ 还是10001？

单端口模式不支持rtcp

[xia-chu]

请问下zlm的rtcp端口也是10000吗？ 还是10001？

这个跟zlm没关系 现在的问题是你js端推流到mediasoup gop 60秒才一个 太大了 需要mediasoup主动发pli(rtcp)给浏览器 浏览器才会生成关键帧

[xia-chu]

看看mediasoup有没有这个配置和设计

[ouxiand]

@xia-chu @xiongguangjie 二位大佬 ，现在我把方式换成 mediasoup（webrtc）--》rtp-----》ffmpeg（rtp->rtmp） ---》zlm（rtmp）,不会再出现蓝屏现象， 但是重新观看rtmp会出现模糊情况
ffmegp脚本
ffmpeg -reorder_queue_size 0 -thread_queue_size 1024 -protocol_whitelist "file,udp,rtp,pipe,rtcp,tcp" -i v.sdp -vcodec copy -fflags +genpts -r 30 -g 0 -b:v 2M -maxrate 2M -bufsize 1M -f flv -y rtmp://127.0.0.1:1935/live/123

ffmpeg日志：
[out#0/flv @ 0x7eac680] Codec AVOption g (set the group of picture (GOP) size) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
[out#0/flv @ 0x7eac680] Codec AVOption maxrate (maximum bitrate (in bits/s). Used for VBV together with bufsize.) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
[out#0/flv @ 0x7eac680] Codec AVOption bufsize (set ratecontrol buffer size (in bits)) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
[out#0/flv @ 0x7eac680] Codec AVOption b (set bitrate (in bits/s)) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Output #0, flv, to 'rtmp://127.0.0.1:1935/live/123':
Metadata:
title : ffmpeg
encoder : Lavf61.1.100
Stream #0:0: Video: h264 (Constrained Baseline) ([7][0][0][0] / 0x0007), yuv420p(progressive), 320x180, q=2-31, 2000 kb/s, 62.50 tbr, 1k tbn
Press [q] to stop, [?] for help
[flv @ 0x7d7a7c0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
size= 1412KiB time=00:00:51.48 bitrate= 224.7kbits/s speed=1.02x

zlm日志（看起来没特别的日志）：
2024-06-05_00.log

请问是ffmep推流脚本的Timestamps 存在问题吗？

[ouxiand]

第二台机器打开rtmp观看 还是会出现蓝屏 60秒后正常 抓包序号看起来是正常

[ouxiand]

[ouxiand]

[ouxiand]

[ouxiand]

原因定位是h264格式问题 再转码就可以了 感谢大佬们