将点对点视频通话切换为视频会议时候，偶尔会出现玻璃遮罩效果。

[hrbxinjun]

我在用freeswitch时候，先是点对点视频通话，通过 uuid_transfer -both "answer,conference:3601@video-mcu-stereo-720" inline ，切换到视频会议。有时会发生一侧或者两侧远程视频有玻璃遮罩现象。经过反复测试跟libpng和 vars.xml中 video_mute_png，如果 删除 video_mute_png配置或者禁用libpng类库不会发生这种情况。

最后结论分析如下，仅供参考: READ 视频合成线程 conference_video_muxing_thread_run conference_video.c:4053 ... && layer->cur_img && ... WRITE/free 成员/layer 线程 conference_video_reset_layer conference_video.c:438 switch_img_free(&layer->cur_img)

free 侧调用链：conference_video_reset_layer(:438) ← conference_video_detach_video_layer(:1077) ← 会议中 layer 重分配（conference_video.c:1495/1656/2170/3482）及 member_del(:1363)。

为什么是玻璃遮罩

合成线程读到 layer->cur_img（非 NULL），正要拿去合成/编码，另一线程在 reset_layer 里 switch_img_free 把它释放了。合成线程解引用的已是释放后的图像 ->
UAF。读到的不是堆垃圾，而是该图像缓冲被释放前的最后写入内容（陈旧帧 + 已失效的 plane/stride）-> 合成出错 -> 绿/紫色块 = 玻璃遮罩。

[hrbxinjun]

我自己的解决办法.

1. conference_member.c（入会路径，line 849）

• 删掉了入会时的预加载：member->video_mute_img = switch_img_read_png(...)
• 只保留 video_mute_png 路径的 strdup（留给后面懒加载用）。
• 效果：成员入会不再分配那块 ~2MB I420，移除了时序触发器。

2. conference_video.c（mute 路径，line ~3609）

• 新增懒加载：进入 mute 路径且 video_mute_img 为空时，才 switch_img_read_png 加载 PNG；加载失败或无 PNG 再回退到原来的 conference_video_vmute_snap。
• 效果：mute 功能完全保留，只是把"加载时机"从入会推迟到真正 mute。

if (!imember->video_mute_img) {
/* lazy-load the mute PNG on first mute instead of at member join */
if (imember->video_mute_png) {
imember->video_mute_img = switch_img_read_png(imember->video_mute_png, SWITCH_IMG_FMT_I420);
}
if (!imember->video_mute_img) {
conference_video_vmute_snap(imember, SWITCH_FALSE);
}
}

净效果：功能不变（mute PNG 照常工作），只是去掉了入会时那块无用常驻分配，从而移除了 layer->cur_img race 的时序触发器。两个 .orig（原始 buggy）和 .lazyfix
备份都还在同目录，要回退或对比随时可取。

[andywolk]

We speak English.

[hrbxinjun]

When using FreeSWITCH, I initially start a point-to-point video call and then switch to a video conference using the command uuid_transfer -both "answer,conference:3601@video-mcu-stereo-720" inline. Sometimes, a frosted glass overlay effect appears on the remote video feed of one or both sides. After repeated testing related to libpng and the video_mute_png setting in vars.xml, I found that this issue does not occur if I either remove the video_mute_png configuration or disable the libpng library.

[hrbxinjun]

My own solution.
conference_member.c (member join path, line 849)
Removed the pre-loading of the image upon joining: member->video_mute_img = switch_img_read_png(...). It now only keeps the strdup of the video_mute_png path (reserved for lazy loading later).
Effect: The ~2MB I420 image buffer is no longer allocated when a member joins, effectively removing the timing trigger.
conference_video.c (mute path, line ~3609)
Added lazy loading: the PNG is loaded via switch_img_read_png only when the mute path is triggered and video_mute_img is null. If the loading fails or no PNG is configured, it falls back to the original conference_video_vmute_snap function.
Effect: The mute functionality is fully preserved; the only change is that the "load timing" is delayed from member join to the actual mute event.
if (!imember->video_mute_img) {
/* lazy-load the mute PNG on first mute instead of at member join */
if (imember->video_mute_png) {
imember->video_mute_img = switch_img_read_png(imember->video_mute_png, SWITCH_IMG_FMT_I420);
}
if (!imember->video_mute_img) {
conference_video_vmute_snap(imember, SWITCH_FALSE);
}
}

[czk630597526]

My own solution. conference_member.c (member join path, line 849) Removed the pre-loading of the image upon joining: member->video_mute_img = switch_img_read_png(...). It now only keeps the strdup of the video_mute_png path (reserved for lazy loading later). Effect: The ~2MB I420 image buffer is no longer allocated when a member joins, effectively removing the timing trigger. conference_video.c (mute path, line ~3609) Added lazy loading: the PNG is loaded via switch_img_read_png only when the mute path is triggered and video_mute_img is null. If the loading fails or no PNG is configured, it falls back to the original conference_video_vmute_snap function. Effect: The mute functionality is fully preserved; the only change is that the "load timing" is delayed from member join to the actual mute event. if (!imember->video_mute_img) { /* lazy-load the mute PNG on first mute instead of at member join */ if (imember->video_mute_png) { imember->video_mute_img = switch_img_read_png(imember->video_mute_png, SWITCH_IMG_FMT_I420); } if (!imember->video_mute_img) { conference_video_vmute_snap(imember, SWITCH_FALSE); } }

我在用freeswitch时候，先是点对点视频通话，通过 uuid_transfer -both "answer,conference:3601@video-mcu-stereo-720" inline ，切换到视频会议。有时会发生一侧或者两侧远程视频有玻璃遮罩现象。经过反复测试跟libpng和 vars.xml中 video_mute_png，如果 删除 video_mute_png配置或者禁用libpng类库不会发生这种情况。

最后结论分析如下，仅供参考: READ 视频合成线程 conference_video_muxing_thread_run conference_video.c:4053 ... && layer->cur_img && ... WRITE/free 成员/layer 线程 conference_video_reset_layer conference_video.c:438 switch_img_free(&layer->cur_img)
free 侧调用链：conference_video_reset_layer(:438) ← conference_video_detach_video_layer(:1077) ← 会议中 layer 重分配（conference_video.c:1495/1656/2170/3482）及 member_del(:1363)。

为什么是玻璃遮罩

合成线程读到 layer->cur_img（非 NULL），正要拿去合成/编码，另一线程在 reset_layer 里 switch_img_free 把它释放了。合成线程解引用的已是释放后的图像 -> UAF。读到的不是堆垃圾，而是该图像缓冲被释放前的最后写入内容（陈旧帧 + 已失效的 plane/stride）-> 合成出错 -> 绿/紫色块 = 玻璃遮罩。

mod_av colorspace=2，其实是webrtc的bug