最近测试北京联通 IPTV 时发现一个问题：部分直播频道疑似在平台侧被错误反交错成了 25p ，导致运动画面不够流畅，尤其是体育、新闻滚动字幕、横向摇摄镜头会比较明显。
这个问题不是播放器本身造成的。即使用运营商机顶盒观看，如果前端流已经把 50i 处理成 25p ，后面的机顶盒、电视机或播放器也无法恢复已经丢失的 50Hz 运动信息。
中国大陆传统电视直播频道很多都是 50i ，也就是每秒 50 场、25 帧的隔行扫描信号。正确处理方式一般应该是在 IPTV/RTP 组播流中原样透传 50i ，保留 interlaced 标记和 field_order 信息，让电视机、机顶盒或播放器端去做反交错。这样最终可以保持 50Hz 级别的运动流畅度。
如果平台侧提前把 50i 反交错成 25p ，虽然看起来还是 25fps ，但每秒 50 个时间采样只剩 25 个，时域信息丢了一半，运动画面自然会卡顿、不顺滑。即使平台侧必须反交错，也应该输出 50p/50Hz ，而不是 25p 。
正常透传 50i 的频道，例如 CCTV-1 高清，ffprobe 结果类似：
{
"format_name": "mpegts",
"video": {
"codec_name": "h264",
"width": 1920,
"height": 1080,
"pix_fmt": "yuv420p",
"field_order": "tt",
"r_frame_rate": "50/1",
"avg_frame_rate": "25/1",
"time_base": "1/90000"
}
}
这里 field_order = tt 表示隔行扫描，avg_frame_rate = 25/1 表示每秒 25 帧，r_frame_rate = 50/1 反映流中存在 50Hz 的场/显示节奏信息。这类结果说明基本是在透传 1080i50 原始电视信号。
异常的 25p 情况则通常类似：
{
"format_name": "mpegts",
"video": {
"codec_name": "h264",
"width": 1920,
"height": 1080,
"pix_fmt": "yuv420p",
"field_order": "progressive",
"r_frame_rate": "25/1",
"avg_frame_rate": "25/1",
"time_base": "1/90000"
}
}
这说明视频已经变成 progressive 25p 。对于原本应为 50i 的直播电视频道，这会丢失一半运动信息。
我这边扫描到疑似有问题的频道包括：
CCTV-5 高清
CCTV-8 高清
聚鲨环球精选
BRTV 北京卫视高清
BRTV 文艺高清
BRTV 纪实科教高清
BRTV 影视高清
BRTV 财经高清
BRTV 体育休闲高清
BRTV 生活高清
BRTV 卡酷少儿高清
BRTV 新闻高清
家有购物精选
优购物
萌宠 TV
淘 Baby
淘剧场
淘电影
淘娱乐
家有购物
聚鲨环球
睛彩竞技
睛彩篮球
睛彩青少
睛彩广场舞
BRTV 北京卫视
BRTV 文艺
BRTV 纪实科教
BRTV 影视
BRTV 财经
BRTV 生活
BRTV 卡酷少儿
BRTV 新闻
BTV 国际频道
山东教育
四川卫视
广西卫视
陕西卫视
山西卫视
内蒙古卫视
厦门卫视
CETV2
CETV4
收视指南
热播剧场
经典电影
魅力时尚
少儿动画
重温经典
城市剧场
军旅剧场
古装剧场
音乐现场
地理
美妆
美人
精选
解密
军事
国学
戏曲
早教
动画
好学生
鉴赏
墨宝
光影
台球
爱生活
高网
足球
武侠剧场
喜剧影院
动作影院
家庭影院
星影
不过北京联通 IPTV 并不是整体处理能力有问题。扫描结果里也有很多频道是正确 50i 透传的，特别是央视高清频道中，CCTV-1 、2 、3 、4 、6 、7 、9 、10 、11 、12 、13 、14 、15 、16 、17 、CCTV-5+ 等都是正常的 interlaced + 50Hz field rate。
这里 CCTV-5+ 很适合作为对比：CCTV-5+ 高清目前是正常 50i 透传，而 CCTV-5 高清疑似被处理成了 25p 。两者都是体育相关频道，CCTV-5+ 正常透传说明平台侧并不是不能正确处理体育频道的 50i 信号，而是部分频道链路或参数可能配置不一致。
我个人认为，至少优先修正 CCTV-5 高清会明显改善体育节目观看体验。体育内容对时间分辨率非常敏感，50i/50Hz 和 25p 的观感差异比普通电视剧、综艺更容易被看出来。
测试方法也比较简单：电脑网口接到光猫 IPTV 口，确保能收到 IPTV 组播流，然后用 FFmpeg 包里的 ffprobe 检测。
FFmpeg 下载地址：
https://www.ffmpeg.org/download.html
以北京卫视高清为例，组播地址是：
rtp://239.3.1.241:8000
测试命令：
ffprobe \
-v error \
-select_streams v:0 \
-show_entries format=format_name:stream=codec_name,width,height,pix_fmt,field_order,r_frame_rate,avg_frame_rate,time_base \
-of json \
"rtp://239.3.1.241:8000?localaddr=本机 IP 地址&overrun_nonfatal=1&fifo_size=50000000"
其中 本机 IP 地址 替换成电脑连接 IPTV 口后获得的网卡 IP ，例如：
ffprobe \
-v error \
-select_streams v:0 \
-show_entries format=format_name:stream=codec_name,width,height,pix_fmt,field_order,r_frame_rate,avg_frame_rate,time_base \
-of json \
"rtp://239.3.1.241:8000?localaddr=192.168.1.100&overrun_nonfatal=1&fifo_size=50000000"
几个可用于对比的组播地址：
CCTV-5+：rtp://239.3.1.130:8004
北京卫视高清：rtp://239.3.1.241:8000
北京卫视 4K SDR：rtp://239.3.1.22:8001
北京卫视 4K HDR：rtp://239.3.1.118:8001
北京卫视标清：rtp://239.3.1.225:8000
CCTV4K 超高清：rtp://239.3.1.245:2000
另外，CCTV 4K 超高清可能还存在 HDR/SDR 元数据配置问题。这个和前面 50i 被处理成 25p 不是同一类问题，但也值得一并反馈。
网上也有人讨论过北京联通 IPTV 里的 4K 源问题：
https://gist.github.com/sdhzdmzzl/93cf74947770066743fff7c7f4fc5820
CCTV4K 超高清的组播地址为：
rtp://239.3.1.245:2000
我本地探测到的 CCTV4K 超高清结果比较可疑，类似：
{
"codec_name": "hevc",
"width": 3840,
"height": 2160,
"pix_fmt": "yuv420p10le",
"color_range": "tv",
"color_space": "bt2020nc",
"color_transfer": "reserved",
"color_primaries": "bt2020",
"r_frame_rate": "50/1",
"avg_frame_rate": "50/1"
}
也就是说，它确实是 4K 、HEVC 、10bit 、BT.2020 、50fps ，但 color_transfer 显示为 reserved。这个字段既不是 SDR 常见的 bt709，也不是 HDR 常见的 smpte2084/PQ 或 arib-std-b67/HLG。实际观感也更像 SDR ，或者至少不是一个能被终端稳定识别为 HDR 的规范信号。
建议北京联通平台侧也检查一下 CCTV4K 的 HDR/SDR 信令：
如果实际是 SDR ，应正确标记 SDR 的传递函数；如果实际是 HDR ，应正确标记 HLG 或 PQ ，并保证内容、元数据、EPG/频道标识一致；不要出现“看起来像 HDR 元数据，但实际不能触发 HDR 或按 SDR 显示”的混合状态。
北京卫视 4K 这边似乎已经区分了 SDR 25 帧和 HDR 50 帧版本，例如：
HDR：rtp://239.3.1.118:8001
SDR：rtp://239.3.1.22:8001
所以 4K/HDR/SDR 这套信令在平台侧应该是可以正确配置的。CCTV4K 建议也按同样思路排查。
最后总结一下建议：
建议北京联通相关 IPTV 平台侧排查这些频道的转码、复用、封装或转发配置，重点看是不是把原始 50i 信号反交错成了 25p ，或者错误标记成 progressive 。
比较理想的修复方式是：对原始 50i 电视信号，在 RTP 组播流中原样透传 50i ，保持正确的 field_order、interlaced 标记和 50Hz 场率信息，让机顶盒或电视机端处理。现在已经有不少频道是正确透传 50i 的，直接参考那些正常频道的处理链路即可。
如果平台侧确实必须反交错，也应该输出 50p/50Hz ，而不是 25p 。
B 站有个视频详细讲解了这种反交错错误： https://www.bilibili.com/video/BV11n4y1o7bJ
（帖子同时发到了 https://tieba.baidu.com/p/10830130071 ， 如果有能联系到北京联通 IPTV 或平台维护相关工作人员的网友，麻烦帮忙转发一下，十分感谢）
1
Select Language