35 个包去了哪里:用日志和 Wireshark 追踪 AirPlay 音频丢包
深夜日志里的数字 35 一次 AirPlay 音频调试快结束时,日志里突然出现了这样一行: audio UDP receive queue overflow session=8 dropped_total=35 会话关闭时,它又留下了一份“结案统计”: audio_packets=35191 ... audio_kernel_drops=35 control…
Tags
深夜日志里的数字 35 一次 AirPlay 音频调试快结束时,日志里突然出现了这样一行: audio UDP receive queue overflow session=8 dropped_total=35 会话关闭时,它又留下了一份“结案统计”: audio_packets=35191 ... audio_kernel_drops=35 control…
背景 在调试 AirPlay 投屏接收端时,最容易遇到一个反直觉现象:接收端日志里明明已经收到了 SETUP、RECORD、SET_PARAMETER 等 RTSP 请求,但 Wireshark 里使用下面的``rtsp`显示过滤器却是空的: 这很容易让人怀疑: 是不是根本没有抓到 RTSP? 是不是 AirPlay 使用的不是标准 RTSP? 日志中为什…