RPT & RTCP & RTSP
RTP(Real-time Transport Protocol),实时传输协议。
◆ RTCP(Real-time Transport Control Protocol),实时传输控制协议。
◆ RTSP(Real Time Streaming Protocol),实时流协议。
◆ RTMP(Real Time Messaging Protocol),实时消息传输协议。
◆ HLS(HTTP Live Streaming),苹果公司提出的基于HTTP的流媒体网络传输协议。
◆ HTTP-FLV,将RTMP等负载信息携带在HTTP协议之上的码流传输协议。
1.RTP、RTCP、RTSP的关系
RTP负责多媒体的传输,RTCP配合RTP做控制和流量统计, RTSP负责建立和控制会话
视频数据由RTP传输;视频质量由RTCP(RSVP)控制;视频控制由RTSP提供
物理层->数据链路层->网络层(IP,RSVP)->传输层(TCP;UDP,RTP(RTCP))
2.RTP(Real-time Transport Protocol),实时传输协议:
◆ RTP建立在UDP协议上;
◆ RTP不确保网络底层的可靠性,不提供按时发送机制或其他服务质量(QoS)保证;
◆ RTP不保证传送或防止无序传送;
◆ RTP提供时间标志,序列号以及其他能够保证在实时数据传输时处理时间的方法
3.RTCP(Real-time Transport Control Protocol),实时传输控制协议:
◆ RTP和RTCP是一起使用的;
◆ RTCP的主要功能是为RTP所提供的服务质量提供反馈,RTCP收集相关媒体连接的统计信息,例如:传输字节数,传输分组数,丢失分组数,时延抖动,单向和双向网络延迟等等;
◆ 网络应用程序可以利用RTCP所提供的信息试图提高服务质量,比如限制信息流量或改用压缩比较小的编解码器;
◆ RTCP本身不提供数据加密或身份认证,其伴生协议SRTCP(安全实时传输控制协议)则可用于此类用途
4.RTSP(Real Time Streaming Protocol),实时流协议:
◆ RTSP是一种双向实时数据传输协议;
◆ RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或RTP完成数据传输;
◆ RTSP主要用来控制具有实时特性的数据发送,比如:对流媒体提供诸如播放、暂停、快进等操作;
◆ RTSP负责定义具体的控制消息、操作方法、状态码等,但它本身并不传输数据,而是必须依赖于下层传输协议所提供的某些服务;
RTMP & HLS
1.RTMP(Real Time Messaging Protocol)
RTMP是Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。
◆ 应用层协议,依靠TCP保证可靠传输。
◆ 默认端口:1953,可能被防火墙屏蔽。
◆ 在流媒体/交互服务器之间进行音视频和数据通信。
2.HLS(HTTP Live Streaming)
HLS是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。
它的工作原理是把整个流分成一个个小的基于HTTP的TS文件来下载,每次只下载一些。当媒体流正在播放时,客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源,允许流媒体会话适应不同的数据速率。
HLS请求基本的HTTP报文,与实时传输协议(RTP)不同,HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。
HLS规范:
◆ 视频的封装格式是TS。
◆ 音视频采用H264编码和AAC编码。
◆ 除了TS视频文件本身,还定义了用来控制播放的m3u8索引文件。
对比RTMP,HLS和HTTP-FLV
流媒体协议分为:
◆ 推流协议
◆ 拉流播放协议
RTMP可以用在双端,HLS用在拉流端,HTTP-FLV用在拉流端。
我们先放一张表格从几个维度来对比下这三种协议。
| RTMP | HTTP-FLV | HLS | |
|---|---|---|---|
| 传输协议 | TCP | HTTP | HTTP |
| 视频封装格式 | flv | flv | ts |
| 延时 | 1-3秒 | 1-3秒 | 5-20秒 |
| Web支持 | H5需要使用插件 | H5中需要使用插件 | 支持H5 |
| 数据 | 连续流 | 连续流 | 切片文件 |
.RTMP & HTTP-FLV
◆ 这两个协议实际上传输的数据是一样的,数据都是flv文件的tag。
◆ RTMP:实时播放服务器的 FLV 文件或服务器转发的FLV数据,本地无 FLV 缓存文件,FLV保密性好。
◆ HTTP-FLV:将 FLV 下载到本地再播放,FLV保密性不好。
2.HLS & RTMP
◆ RTMP:采用1935端口,而非HTTP80端口,在某些网络环境下可能被屏蔽。
◆ RTMP:是一种有状态协议,需要为每一个播放视频流的客户端维护状态,服务器平滑扩展难度大。
◆ HLS:基于无状态HTTP协议,客户端只需要按顺序使用下载的TS文件就可,负载均衡如同普通的HTTP文件服务器负载均衡一样。
3.HTTP-FLV
HTTP-FLV 结合了 RTMP 和 HLS 的优点,易用(HTTP协议)低延时(flv)
4.为什么 RTPM 比 HLS 快
◆ HLS拉流:服务器音视频数据切片生成 TS 文件
◆ HLS拉流:客户端必须等待服务端至少生成一个 TS 文件,通常下载完两个媒体文件后才能保证不同分段音视频间的无缝连接。
◆ HLS一直在等切片数据,RTMP不需要切片
HLS 的方案模拟
推流端:RTMP 推送->联通成本70oms->采集编码封包1ooms-
媒体服务器:对flv 文件切片->输出ts->输出 m3u8
HLS拉流播放:Get m3u8->Get ts
HDRType
HDRType是用于标识视频HDR(高动态范围)类型的字段,主要用于视频转码和质量优化流程中。以下是关于HDRType的详细信息:
1 HDRType的识别与处理
HDR视频的类型可以通过工具如ffprobe检测,常见的HDR类型包括HLG、HDR10、HDR10 Plus等。根据检测结果,HDR视频会进入特定的转码流程,以确保视频质量和色彩表现。例如:
• HDR10视频会走HDR转码流程,最终呈现HDR效果。
• 非HDR视频(如SDR)则走非HDR转码流程,转码后无HDR效果
2 HDRType的修复与优化
在异步转码过程中,HDRType字段可能出现错误。例如,HDR视频的非HDR档位可能被错误标记为SDR,而实际应为SDR_PLUS。通过修复机制,可以更正这些错误,确保HDRType字段的准确性
3 HDRType在多路流视频中的应用
多路流视频可能包含不同的HDR类型。在转码时,需要确保选流结果与原片媒资的HDRType一致,以避免色彩不正确的问题
4 HDRType的映射与存储
HDRType字段可以通过代码映射完成,例如基于ffprobeInfo中的第一个视频流的HDRType进行映射。这种映射方式确保了HDRType字段的准确性和一致性
总结
HDRType是视频转码和质量优化中的关键字段,主要用于识别视频的HDR类型并决定转码流程。通过检测、修复和映射机制,可以确保HDRType字段的准确性,从而提升视频的质量和用户体验。
PSNR
(峰值信噪比)是一种衡量图像或视频质量的指标,通过比较原始信号与处理后信号之间的差异来评估失真程度。数值越高,表示质量损失越小。常用于图像压缩、视频编码等领域的质量评估。
常用命令
仅撤销 git add(未提交前)
如果文件已通过 git add 暂存但尚未提交,可以通过以下命令撤销
撤销所有暂存文件:
git reset HEAD – .
撤销已提交的 Commit(未推送前)
若已提交但未推送到远程仓库,可通过 git reset 撤销:
保留修改内容(暂存区):
git reset –soft HEAD^ # 回退到上一次提交前的状态
此命令撤销提交,但保留修改内容在暂存区,可重新提交
保留修改内容(工作区):
git reset –mixed HEAD^ # 默认模式,撤销提交和暂存
修改内容保留在工作区,可重新 git add 后提交
彻底回退(包括工作区)
git reset –hard HEAD^ # 强制回退,覆盖工作区修改(谨慎使用!)
此命令会覆盖所有未提交的修改,确保备份重要数据
扩展 Git 缓冲区大小
由于 FFmpeg 仓库包含大量二进制文件,增大 Git 的 HTTP 缓冲区可避免传输中断:
git config –global http.postBuffer 1572864000 # 设置 1.5GB 缓冲区
原理:缓冲区不足时,网络传输会中断并导致数据读取失败。此设置确保 Git 能处理大型数据包
合并指定文件夹下的所有log文件
find /指定/文件夹 -name “*.log” -type f -print0 | xargs -0 cat > test.txt
Audition修改为中文
1:在/Library/Application Support/Adobe/Audition/25.0/AMT的application.xml文件中,将en_US改为zh_CN
音视频检测
检测破音:
/usr/local/bin/ffmpeg -i a.mp4 -filter_complex ebur128 -f null -
查看输出的Peak和True peak值
/usr/local/bin/ffmpeg -i 5.mp4 -af astats=metadata=1:reset=1 -f null - 2>&1 | grep “Peak level”
理论范围【-32768,32767】
检测花屏:
/usr/local/bin/ffprobe -i 5.mp4 -v quiet -select_streams v:0 -show_entries frame=pict_type -of csv
I帧(每2秒一个)
检测卡顿:
/usr/local/bin/ffprobe -i 9.mp4 -v quiet -select_streams v:0 -show_entries frame=pkt_pts_time -of csv=p=0 > pts.txt
查看输出文件pts单调递增,间隔相同
播放视频:
/usr/local/bin/ffplay -i K.mp4
查看是否飘红:
/usr/local/bin/ffmpeg -i 2.mp4 -f null -
将当前视频提取原始无压缩音频
ffmpeg -y -i video.mp4 -f s16le -c:a pcm_s16le -ar 44100 -ac 2 origin_video.pcm
将无压缩音频进行反相处理
server_process –sample_rate=44100 –channel_num=2 –input=origin_video –output=reverse_origin_video.pcm –phase_detect_enable=1
主要测试框架
- JUnit 5 (Jupiter) - 主要测试框架
版本: 使用JUnit 5 (Jupiter)
配置: 在junit-platform.properties中配置了并行执行
主要注解:
@Test - 标记测试方法
@ParameterizedTest - 参数化测试
@BeforeEach / @AfterEach - 测试前后执行
@BeforeAll - 类级别的初始化
@ExtendWith - 扩展支持
@Tag - 测试标签分组
@Nested - 嵌套测试类
@Disabled - 禁用测试
@Timeout - 超时控制 - TestNG - 辅助测试框架
用途: 部分测试类使用TestNG
主要注解:
@Test - TestNG的测试方法标记
SoftAssert - 软断言,允许多个断言失败后继续执行 - KAT框架 - 自定义测试框架
自动化测试框架,提供了丰富的自定义注解:
KAT核心注解:
@Order(0) //保证按顺序执行
@KatTag(key=”env”,value=”staging”) //自定义,和kat平台关联,可通过tag筛选case执行
@KatScene - 测试场景描述
@KatScene(“视频转码”)
@KatScene(value = “基础特征CAPE”)
@KatDesc - 测试用例描述
@KatLevel - 测试优先级
@KatLevel(Level.P0) // P0为最高优先级
@KatDataProvider - 数据驱动测试
@KatDataProvider(path = {“input/MediaFeature/cape.json”})
@KatDataProvider(path = {“input/MediaFeature/cover.json”,
“input/MediaFeature/taskGroup.json”},
cartesianProduct = true)
@KatTest - KAT框架的测试方法标记
@KatGroup - 测试分组
自定义数据提供注解:
@Csv - CSV文件数据提供
@Csv(filePath = “data.csv”, delimiter = “,”, skipLines = 1)
@Lane - 测试通道标记
- Spring Test - 集成测试支持
用于Spring Boot应用的集成测试
提供依赖注入和上下文管理 - JUnit Pioneer - JUnit 5扩展
提供额外的测试功能和注解支持
测试配置特性
并行执行配置
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent
junit.jupiter.execution.parallel.mode.classes.default=same_thread
junit.jupiter.execution.parallel.config.strategy=dynamic
junit.jupiter.execution.parallel.config.fixed.parallelism=5
视频类型
- 按封装格式(容器)划分
格式 特点 常见用途 扩展名
MP4 通用性强,支持多轨道音视频+字幕 网络流媒体、移动设备 .mp4
AVI Windows系统原生,兼容性好 本地播放、存档 .avi
MKV Matrox开发,支持多语言/字幕轨道 高清影视存储、蓝光备份 .mkv
MOV/QT Apple QuickTime格式 macOS/iOS生态 .mov
FLV Flash视频格式,适合网页嵌入 早期网页视频 .flv
WebM Web优化,开源无专利费 HTML5网页视频 .webm
TS/M2TS MPEG传输流,用于电视广播/卫星信号 数字电视、直播流 .ts
WMV Microsoft推出,Windows Media Player 银光DVD、企业视频 .wmv - 按视频编码标准划分
编码名称 特点 典型场景
H.264/AVC 高压缩率,广泛兼容 网络视频、蓝光碟片
H.265/HEVC 相同画质下比H.264节省50%带宽 4K/8K超清视频、流媒体
MPEG-4 Part 2 DVD标准,逐渐被淘汰 DVD刻录
MPEG-4 ASP DiVX/XviD基于此编码 老式PC视频转换
ProRes Apple专业剪辑用中间码流 影视后期制作
DNxHD Blackmagic Designs的专业格式 电影级调色与特效处理
AV1 开源新一代编码,效率优于H.265 未来超高清视频传输
VP9 Google主导,YouTube常用 网页4K视频 - 按分辨率/帧率划分
类型 分辨率范围 帧率要求 应用场景
SD (标清) 720×576 (PAL) / 720×480 (NTSC) 25/30 fps 传统电视
HD (高清) 1280×720 (720p) 50/60 fps 流媒体、监控摄像头
Full HD (FHD) 1920×1080 (1080p) 50/60 fps 电视、手机录制
QHD (Quad HD) 2560×1440 60 fps 高端显示器
4K UHD 3840×2160 (4K) 50/60 fps 家庭影院、纪录片
8K 7680×4320 120 fps 实验性拍摄、VR内容
音频类型
- 按封装格式划分
格式 特点 常见用途 扩展名
MP3 有损压缩,普及度高 音乐下载、便携式播放器 .mp3
AAC 比MP3效率高,苹果设备默认 iTunes、Android音频 .aac
FLAC 无损压缩,保留原始音质 Hi-Res音乐收藏 .flac
ALAC Apple无损压缩,类似FLAC iOS/macOS无损音乐 .m4a
WAV PCM未压缩,音质最佳但体积大 专业录音、CD烧录 .wav
OGG Vorbis 开源免费,平衡音质与体积 独立音乐分发 .ogg
Opus 灵活动态调整比特率,适合网络电话 VoIP、视频会议 .opus
WMA Microsoft专有,支持DRM版权保护 Xbox游戏音效、Zune商店 .wma - 按音频编码标准划分
编码名称 特点 典型场景
MP3 (Layer III) 心理声学模型去除冗余数据 大众消费级音乐
AAC-LC 高级音频编码,低复杂度实现高音质 流媒体、广播
HE-AAC v2 AAC改进版,提升立体声效果 移动设备背景音
Dolby Digital 多声道环绕声(5.1/7.1),杜比认证 影院、家庭影院
DTS 竞争杜比的数字影院解决方案 高端蓝光原声大碟
PCM/WAV 脉冲编码调制,未经压缩的原始脉冲信号 专业录音棚母带处理
Ogg Vorbis Xiph.Org基金会维护的开源编码 Linux社区、自由软件项目
Opus Skype联合研发,适应宽带变化的自适应编码 WebRTC实时通信、播客 - 按声道配置划分
声道类型 描述 典型应用
Mono (单声道) 单一音频通道 语音备忘录、广播AM调频
Stereo (立体声) 左右双声道分离 绝大多数音乐、电影 - 1 Surround 5个全向扬声器+1个低音炮 家庭影院、游戏音效
- 1 Surround 7个全向扬声器+1个低音炮 沉浸式观影体验
Atmos (三维声场) 基于对象的全景声场技术 最新电影混音、VR音频
三、关键区别总结
维度 视频 音频
核心目标 视觉信息高效压缩与呈现 听觉保真度与数据量平衡
敏感度 对带宽敏感(尤其高清内容) 对延迟敏感(实时通话场景)
发展趋势 向H.265/AV1等新编码迁移 Opus成为实时通信主流编码
专业领域 影视工业使用ProRes/DNxHD中间码 录音棚采用PCM/DSD无损格式
四、实际应用示例
1 短视频上传:手机拍摄 → H.264编码的MP4文件 → 上传至抖音/B站。
2 音乐会直播:现场多机位采集 → H.265/HEVC编码 → RTMP推流至直播平台。
3 Hi-Fi音乐存储:CD抓轨为FLAC无损格式 → 存入NAS作为高品质库存。
4 智能音箱交互:麦克风采集 → Opus编码 → 云端NLP处理 → 合成语音回复。
ffmpeg案例详解
🌰 案例1:视频格式转换 + 压缩
需求:将 1080p MP4 转换为 720p WebM 格式,降低体积便于网页播放。
ffmpeg -i input.mp4
-c:v libvpx-vp9 # 使用VP9编码器(高效压缩)
-crf 30 # 质量控制因子(越低质量越好)
-b:v 0 # 动态码率控制
-c:a libopus # Opus音频编码
-ar 48000 # 采样率48kHz
output.webm
📌 关键点:-crf 比固定码率更适合网络传输。
🌰 案例2:提取音频轨道
需求:从视频文件中提取无损音频并保存为 FLAC 格式。
ffmpeg -i input.mov
-map a:0 # 仅映射第一条音频流
-c:a flac # 使用FLAC编码
-compression_level 8 # 最高压缩等级
audio_only.flac
📊 扩展:-map 参数可精确控制音视频流的选择。
🌰 案例3:批量处理图片转视频
需求:将目录下所有 JPG 图片合成为 25fps 的视频。
ffmpeg -framerate 25
-i image_%03d.jpg # 三位数字序号补零
-c:v libx264 -pix_fmt yuv420 output.mp4
⚠️ 注意:图片命名需按顺序编号(如 image_001.jpg, image_002.jpg)。
🌰 案例4:添加文字水印
需求:在视频右下角添加半透明文字水印。
ffmpeg -i input.mp4
-vf “drawtext=text=’Confidential’:fontfile=Arial.ttf:fontsize=24:fontcolor=white@0.5:x=(w-tw)/2:y=h-th-20”
output_watermarked.mp4
🎨 可调参数:x, y 控制位置,@0.5 表示50%透明度。
🌰 案例5:实时推流到RTMP服务器
需求:将摄像头实时画面推送到直播平台。
ffmpeg -f avfoundation -i “0:0” \ # macOS摄像头+麦克风
-c:v libx264 -preset veryfast # 快速编码
-f flv rtmp://live.example.com/streamkey
📱 移动端替代方案:Android/iOS 可通过 OBS Studio 间接推流。
五、进阶技巧
⚡️ 加速转码策略
• 硬件加速:优先使用显卡 NVENC/QuickSync/VAAPI:
Intel QuickSync (QSV)
• ffmpeg -i input.mp4 -c:v qsv_h264 -b:v 0 output.mp4
• 多线程优化:根据CPU核心数设置线程数:
ffmpeg -threads 8 -i input.mp4 …
📊 监控与调试
• 实时进度条:添加 -progress 参数;
• 详细日志:-report 生成统计报告;
• 抓包分析:结合 Wireshark 分析网络流问题。
六、常见问题解决
问题现象 解决方案
Invalid data found when processing input 文件损坏,尝试修复或重新下载
Could not find codec parameters 缺少编解码器,安装对应插件(如 libx265)
视频只有声音没有画面 检查 -pix_fmt 是否设置为 yuv420p(部分播放器不支持YUV422)
内存不足导致崩溃 降低分辨率或关闭不必要的滤镜,增加交换分区
ffplay 命令使用
ffplay 是 FFmpeg 套件中的一个轻量级媒体播放器,支持本地文件、网络流等多种格式的播放,并提供丰富的命令行选项控制播放效果
一、基本命令结构
ffplay [选项] 输入文件
输入文件:本地视频文件路径(如 test.mp4)或网络流 URL(如 rtmp://example.com/live)
选项:可选参数,用于控制播放行为
二、核心功能与命令示例
- 基础播放
ffplay test.mp4 # 播放当前目录下的视频本地文件播放:
ffplay -window_title “My Video” test.mp4 # 自定义窗口标题
网络流播放:
ffplay -window_title “RTMP Stream” rtmp://202.69.69.180:443/webcast/bshdlive-pc # 播放 RTMP 流
- 时间控制
ffplay -ss 10 test.mp4 # 从第 10 秒开始播放从指定时间开始播放:
限制播放时长:
ffplay -t 30 test.mp4 # 播放 30 秒后自动退出[5]
组合使用:
ffplay -ss 2 -t 10 test.mp4 # 从第 2 秒开始播放,持续 10 秒
- 音视频控制
ffplay -an test.mp4 # 禁用音频禁用音频/视频:
ffplay -vn test.mp4 # 禁用视频
ffplay -sn test.mp4 # 禁用字幕
切换音视频流(如 TS 流)
ffplay -vst 4 -ast 5 movie.ts # 播放视频流 4 和音频流 5
- 播放模式
ffplay -loop 2 test.mp4 # 循环播放 2 次(0 表示无限循环)循环播放
全屏模式
ffplay -fs test.mp4 # 全屏启动
静音
ffplay -M test.mp4 # 切换静音模式
- 高级播放控制
ffplay test.mp4 # 播放时按逐帧播放:S键逐帧前进
时间轴跳转
播放时按 ←/→ 跳 10 秒,↑/↓ 跳 1 分钟
退出播放:播放时按 Q 或 Esc 退出
三、格式与参数设置
- 原始视频格式播放
ffplay -f rawvideo -pixel_format yuv420p -video_size 720x480 output.yuv # 指定格式、分辨率YUV 数据播放:
RGB 数据播放:
ffplay -pixel_format rgb24 -video_size 1280x720 -framerate 60 rgb_data.rgb # 设置帧率
- 音频参数设置
ffplay -ar 44100 -ac 2 -f s16le audio.pcm # 设置采样率 44.1kHz、双声道、16 位有符号格式PCM 音频播放:
四、视频滤镜与调试
- 视频滤镜
ffplay -vf transpose=1 test.mp4 # 顺时针旋转 90 度旋转/翻转:ffplay -vf vflip test.mp4 # 垂直翻转
组合滤镜:
ffplay -vf vflip,transpose=1 test.mp4 # 先翻转再旋转
音频滤镜
变速播放:ffplay -af atempo=1.5 test.mp4 # 音频加速 1.5 倍
调试视图
显示宏块类型:ffplay -debug vis_mb_type test.mp4 # 分析视频编码特性
显示运动向量:
ffplay -vismv pf test.mp4 # 可视化运动估计信息
查看所有选项:ffplay -h
搜索格式支持:ffplay -formats
交互控制:
播放时按 F 切换全屏,0/9 调节音量
EBU R128
通过 -filter_complex ebur128),这是国际通用的音频响度标准化标准,常用于广播、流媒体和影视制作领域。其目标是统一不同内容的感知音量,避免忽大忽小的问题。
二、逐行数据解析
- 初始状态行
[Parsed_ebur128_0 @ 0x600001b58000] t: 73.5467 TARGET:-23 LUFS M: -9.0 S: -6.2 I: -9.6 LUFS LRA: 7.1 LU
| 字段 | 含义 | 您的数据 | 说明 |
|---|---|---|---|
| t: 73.5467 | 当前处理到的视频/音频时间点(秒) | 73.5467 | 表示分析已完成约73.5秒的内容 |
| TARGET:-23 | 预设的目标响度基准线(Target Level),默认值为-23 LUFS | -23 LUFS | 这是 EBU R128 推荐的长期平均目标值 |
| M: -9.0 | 瞬时峰值 **(Momentary Peak)**:短时间内的最大样本值 | -9.0 dBFS | 接近数字天花板(0 dBFS),说明存在短暂的高能量片段 |
| S: -6.2 | 短期响度 **(Short-term Loudness)**:1.5秒窗口内的平均值 | -6.2 LUFS | 反映快速变化的动态特性 |
| I: -9.6 | 积分响度 **(Integrated Loudness)**:整个片段的整体平均响度 | -9.6 LUFS | 最关键的全局响度指标,需尽量接近目标值 ±1~2 LUFS |
| LRA: 7.1 | 响度范围 **(Loudness Range, LRA)**:从最安静到最响亮部分的差异 | 7.1 LU | 数值越小表示动态越平稳;越大则起伏越剧烈 |
- 文件元信息
frame= 1840 fps=678 q=-0.0 Lsize=N/A time=00:01:13.60 bitrate=N/A speed=27.1x
video:963kB audio:13793kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
• 用途:描述输入文件的基本属性。
• 关键点:audio:13793kB:音频轨道占用存储空间较大,表明原始音频质量较高。
speed=27.1x:处理速度为实时速度的27倍,说明系统性能充足。
- 最终汇总报告
[Parsed_ebur128_0 @ 0x600001b58000] Summary:
Integrated loudness:
I: -9.6 LUFS
Threshold: -19.8 LUFS
Loudness range:
LRA: 7.1 LU
Threshold: -29.8 LUFS
LRA low: -13.4 LUFS
LRA high: -6.3 LUFS
(1) 集成响度 (Integrated Loudness)
| 指标 | 值 | 意义 |
|---|---|---|
| I: -9.6 LUFS | ✅ 主控指标 | 整个音频片段的平均响度。理想情况下应在 -23 ± 2 LUFS 范围内。 |
| Threshold: -19.8 LUFS | ⚠️ 警告阈值 | 若某时刻响度超过此值(即 > -19.8 LUFS),会被标记为潜在过载风险。 |
📌 注意:您的 I=-9.6 远高于目标值 -23,意味着整体音量偏大,可能需要降低增益。
(2) 响度范围 (Loudness Range, LRA)
| 指标 | 值 | 意义 |
|---|---|---|
| LRA: 7.1 LU | 📏 动态范围 | 全片最静音与最响部分的差距。推荐值通常 < 10 LU,您的数据符合要求。 |
| Threshold: -29.8 LUFS | ⏳ 下限阈值 | 低于此值的部分被视为过于安静(不影响主观听感)。 |
| LRA low: -13.4 LUFS | 🔊 最安静处 | 片段中最轻柔的部分响度。 |
| LRA high: -6.3 LUFS | 💥 最响亮处 | 片段中最强烈的部分响度。接近瞬时峰值 M=-9.0,显示局部突发能量较强。 |
三、实践建议
1 调整整体音量:
•当前 I=-9.6 显著高于目标 -23,建议使用 gain 过滤器整体衰减约 13~14 dB(例如 gain=-14)。
• 示例命令修正: ffmpeg -i input.mp4 -af “loudnorm=I=-23:TP=-1.5” output.mp4
✔️ loudnorm 会自动应用规范化算法,使 I 趋近于目标值。
2 控制动态范围:
•若希望缩小 LRA(减少强弱对比),可添加压缩器(Compressor):
• ffmpeg -i input.mp4 -af “compressor=threshold=-20:ratio=4:attack=30:release=200” output.mp4
• 👉 根据实际效果微调参数。
3 检查真峰值防止削波:
• 虽然当前 M=-9.0 未达数字上限(0 dBFS),但在降音量后需重新验证真峰值(True Peak):
• ffmpeg -i input.mp4 -af “ebur128=peak=true” -f null -
确保所有峰值留有足够的余量(至少 headroom > 1 dB)。
四、常见疑问解答
Q: 为什么 I 和 S 差距这么大? A: I 是全程平均,而 S 反映短时间波动。差距大说明音频存在明显的强弱变化(如对话+背景音乐切换)。
Q: LRA 多少算好? A: 一般建议 < 10 LU,您的 7.1 属于优秀水平,无需特别处理。
Q: Threshold 有什么用? A: 它定义了“安全区”边界。若任何时刻的响度超过 Threshold(如 -19.8),可能引发听众耳机/音箱的非线性失真。
五、总结
| 关键指标 | 当前值 | 理想范围 | 行动建议 |
|---|---|---|---|
| Integrated (I) | -9.6 LUFS | -23 ± 2 LUFS | 🔍 需大幅降低整体音量 |
| Short-term (S) | -6.2 LUFS | N/A (随内容变化) | ⸺ |
| Momentary Peak (M) | -9.0 dBFS | < -1 dBFS | ✔️ 暂无削波风险 |
| Loudness Range (LRA) | 7.1 LU | < 10 LU | 👍 动态控制良好 |
建议优先使用 loudnorm 进行自动化响度校正,再手动检查极端峰值。
FFmpeg命令解析与日志解释
命令行参数含义
/usr/local/bin/ffmpeg -y -i input.mp4 -f s16le -c:a pcm_s16le -ar 44100 -ac 2 output.pcm
参数 含义
-y 强制覆盖输出文件(无需手动确认)
-i input.mp4 指定输入文件(此处为 5191524645514187343… 视频)
-f s16le 输出格式为 16位有符号小端音频(无压缩 PCM)
-c:a pcm_s16le 音频编码为 PCM 原始格式(无压缩)
-ar 44100 音频采样率设为 44.1 kHz(CD 音质标准)
-ac 2 音频声道设为 立体声(双声道)
output.pcm 输出文件路径(直接写入 PCM 数据)
日志信息解释
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘…mp4’:
Duration: 00:00:30.12, start: 0.000000, bitrate: 534 kb/s
Stream #0:0: Video: hevc (hvc1), 720x1280, 20 fps
Stream #0:1: Audio: aac (HE-AAC), 44100 Hz, stereo
Duration: 视频总时长(约 30 秒)。
Stream #0:0: 视频流(HEVC 编码,720×1280 分辨率,20 帧/秒)。
Stream #0:1: 音频流(HE-AAC 编码,44.1 kHz 双声道)。
流映射信息
Stream mapping:
Stream #0:1 -> #0:0 (aac (native) -> pcm_s16le (native))
表示将输入文件的 音频流(AAC) 转换为输出文件的 PCM 原始音频。
输出流信息
Output #0, s16le, to ‘./output.pcm’:
Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
s16le: 16 位有符号小端音频(无压缩)。
1411 kb/s: 最终 PCM 文件的码率(与原始 AAC 的 48 kbps 相比显著增大)。
最终状态
size= 5176kB time=00:00:30.09 bitrate=1409.1kbits/s speed= 831x
video:0kB audio:5176kB … muxing overhead: 0.000000%
size=5176kB: 输出 PCM 文件大小(约 5.1 MB)。
bitrate=1409.1kbits/s: 实际码率(接近理论值 1411 kbps)。
video:0kB: 无视频输出(仅音频转换)。
muxing overhead: 0%: 无额外数据开销(纯 PCM 原始音频)。
关键结论
转换成功:FFmpeg 已将视频中的 AAC 音频解码为 未压缩的 PCM 原始音频(CD 质量)。
文件变大:PCM 格式无压缩(1411 kbps),而原始 AAC 为 48 kbps,因此文件从几百 KB 变为 5.1 MB。
无错误:日志显示完整转换流程(无 Error 或 fail 提示),说明命令执行正常
/usr/local/bin/ffmpeg_atlas -i 5.mp4 -af astats=metadata=1:reset=1 -f null - 2>&1
逐项解释
| 参数 | 含义 |
|---|---|
| -i [文件名].mp4 | ✅ 输入文件:指定待分析的 MP4 视频文件路径。 |
| -af astats=… | 📊 音频分析滤镜:调用 astats 过滤器进行音频统计分析,并设置以下子参数: - metadata=1 → 将统计结果存入输出流的元数据中; - reset=1 → 每次处理前重置统计状态(避免累积历史数据)。 |
| -f null - | 🚫 禁用输出文件:将所有数据直接输出到终端(- 表示标准输出)。 |
| 2>&1 | 🔗 合并错误与标准输出:将错误日志(stderr)重定向到标准输出(stdout),确保完整显示所有信息。 |
二、输出内容解析
- FFmpeg 环境信息
ffmpeg version atlas-6.0.15-52-g2379db6846 … (编译配置省略)
• 这是 自定义编译的 FFmpeg 版本(基于 Atlas 分支),与官方发行版可能存在功能差异。
• 核心库版本号表明其依赖的编解码器、过滤器等组件的版本。
\2. 输入文件信息
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘5226146068128139662_e4ab693f367a9448_5611_v7MidADv9.mp4’:
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2mp41
comment : …(复杂注释,含编码器标识符)
Duration: 00:01:13.61, start: 0.000000, bitrate: 682 kb/s
• 容器格式:MP4(兼容 ISO Base Media File Format)。
• 时长:1 分 13.61 秒。
• 总比特率:682 kb/s(包含视频和音频)。
- 流信息
视频流 (Stream #0:0)
Stream #0:0(und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, progressive), 576x1024 [SAR 1:1 DAR 9:16], 613 kb/s, 25 fps, 25 tbr, 1000k tbn, 25 tbc (default)
• 编码格式:HEVC (H.265),主配置文件(Main Profile)。
• 分辨率:576×1024(竖屏视频,宽高比 9:16)。
• 帧率:25 fps。
• 视频比特率:613 kb/s。
音频流 (Stream #0:1)
Stream #0:1(und): Audio: aac (HE-AAC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 63 kb/s (default)
• 编码格式:AAC(高级音频编码,HE-AAC 变体)。
• 采样率:44.1 kHz(CD 质量)。
• 声道数:立体声(Stereo)。
• 音频比特率:63 kb/s。
- 流映射与转换
Stream mapping:
Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native))
Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))
• 视频处理:保持原 HEVC 编码不变(wrapped_avframe 仅为包装器)。
• 音频处理:将 AAC 解码为 PCM 16 位小端格式(pcm_s16le),供后续分析使用。
- 音频统计分析结果(核心部分)
单声道统计(Channel 1 & 2)
以 左声道(Channel 1) 为例:
[Parsed_astats_0 @ …] Channel: 1
DC offset: -0.042105 // 直流偏移量(理论上应接近 0)
Min level: -0.581491 // 最小样本值(归一化到 [-1, 1])
Max level: 0.649421 // 最大样本值(未超过 0 dBFS,无削波风险)
Peak level dB: -3.749473 // 峰值电平(相对于满刻度 dBFS)
RMS level dB: -12.451097 // RMS 电平(反映平均能量)
Crest factor: 2.723210 // 波峰因数(峰值/RMS,衡量动态范围)
Dynamic range: 120.970985 // 动态范围(最大值与最小值的差异)
Zero crossings: 100 // 过零次数(反映低频含量)
关键指标解读:
| 指标 | 含义 | 本例数值 | 备注 |
|---|---|---|---|
| DC offset | 直流偏置(理想为 0) | -0.042 | 微小负偏移,通常可忽略 |
| Min level | 最小样本值(越小表示越安静) | -0.581 | 未接近 -1(无严重衰减) |
| Max level | 最大样本值(超过 0 表示削波风险) | 0.649 | 远低于 1,安全区间 |
| Peak level dB | 峰值电平(负值越大表示音量越低) | -3.75 dBFS | 较高峰值,但仍有足够余量(距 0 dBFS 还有 3.75 dB) |
| RMS level dB | RMS 电平(反映平均能量) | -12.45 dBFS | 较低平均值,适合长时间聆听 |
| Crest factor | 波峰因数(峰值/RMS,衡量瞬态能量) | 2.72 | 典型音乐信号范围(>2),说明存在明显的瞬态(如鼓点、打击乐) |
| Dynamic range | 动态范围(最大值与最小值的差异) | 120.97 | 较大的动态范围,符合音乐类内容的波动特性 |
| Zero crossings | 过零次数(反映低频丰富程度) | 100 | 适中,说明低频成分较多 |
双声道汇总(Overall)
[Parsed_astats_0 @ …] Overall
DC offset: -0.042105
Min level: -0.610948
Max level: 0.672596
RMS level dB: -12.297239
Crest factor: 2.723870
Number of samples: 2048 // 分析的样本总数
• 全局特性:综合两个声道的结果,整体动态范围和能量分布合理。
• 样本数:2048 个样本(约 46 毫秒,基于 44.1 kHz 采样率)。
三、总结与建议
音频质量评估
1 无削波风险:最大样本值仅 0.67,距离数字天花板(0 dBFS)有充足余量。
2 动态范围健康:动态范围约 120 dB,适合音乐或影视内容。
3 平均响度适中:RMS 电平约为 -12 dBFS,既不会过于响亮也不会过于安静。
4 瞬态表现良好:波峰因数 >2.7,说明保留了足够的瞬态细节(如乐器敲击声)。
潜在改进方向
• 响度标准化:若需符合广播标准(EBU R128),建议目标集成响度为 -23 LUFS,当前 RMS 电平偏低,可通过增益调整提升整体音量。
• 动态压缩:如需缩小动态范围(使强弱对比更平缓),可添加压缩器(Compressor)。
• 低频管理:过零次数较多,若需增强低音效果,可考虑均衡器(Equalizer)适当提升低频段。
四、常见问题解答
Q: 为什么有两个声道的单独统计? A: 输入音频为立体声(Stereo),astats 会分别分析左右声道,再提供全局汇总数据。
Q: metadata=1 有什么实际作用? A: 若保留输出文件(而非 -f null),统计结果会嵌入到输出文件的元数据中,便于后续工具读取。
Q: reset=1 的必要性是什么? A: 确保每次运行 astats 时从零开始统计,避免多次运行后的累计偏差。
Q: 如何保存这些统计结果? A: 移除 -f null 并指定输出文件(如 output.wav),统计结果将写入文件元数据。
一、命令行参数详解
/usr/local/bin/ffprobe_atlas -i a.mp4 -v quiet -select_streams v:0 -show_entries frame=pict_type -of csv
逐项解释
| 参数 | 含义 |
|---|---|
| -i [文件名].mp4 | ✅ 输入文件:指定待分析的 MP4 视频文件路径。 |
| -v quiet | 🔇 静默模式:仅输出必要信息,抑制无关日志(如编解码器初始化提示)。 |
| -select_streams v:0 | 🎯 选择视频流:v:0 表示选择第一个视频流(索引从 0 开始),忽略音频或其他流。 |
| -show_entries frame=pict_type | 🔍 显示特定字段:对选中的视频流,提取每一帧的 pict_type 属性(即帧类型)。 |
| -of csv | 📋 输出格式:将结果格式化为 CSV(逗号分隔值),便于后续处理或导入表格工具。 |
核心逻辑:遍历指定视频流的每一帧,提取其画面类型(如 I/P/B 帧),并以 CSV 格式输出。
二、输出内容解析
frame,B
frame,B
frame,B
…(多行重复)
字段含义
| 字段 | 含义 | 本例值 | 说明 |
|---|---|---|---|
| frame | 当前帧的序号(相对于视频流的总帧数)。 | N | 随播放顺序递增(如第 1 帧、第 2 帧…)。 |
| B | 帧类型标识符:B 表示双向预测帧(Bidirectional Predictive Frame)。 | B | 表明该帧使用了前后参考帧进行压缩(常见于视频编码中的 B 帧)。 |
关键概念:帧类型(Picture Type)
在视频编码中,帧分为以下三类:
1 I 帧(Intra Coded)
• ✔️ 特点:不依赖其他帧,独立编码(关键帧)。
• 📄 用途:随机访问的起点,常用于场景切换或章节点。
2 P 帧(Predictive Coded)
• ➡️ 特点:基于前一个 I 帧或 P 帧进行预测编码。
• ⚠️ 依赖:需参考前面的帧才能解码。
3 B 帧(Bidirectional Predictive Coded)
• ↔️ 特点:同时参考前后帧进行双向预测编码。
• 💡 优势:压缩效率最高,适合运动平滑的场景。
• ❗ 限制:解码顺序与显示顺序不同(需缓冲)。
为何全为 B 帧?
1 典型场景:
• 如果视频内容运动平缓且无突变(如幻灯片、静态镜头),编码器可能优先使用 B 帧以提高压缩率。
2 异常情况:
• ❌ 误判可能性:若视频实际包含 I/P 帧但未被正确识别,可能是以下原因:
▪ 容器元数据缺失(如 MP4 盒信息损坏)。
▪编码器未按标准写入帧类型标签。
▪使用的 ffprobe 版本存在兼容性问题(如旧版无法解析某些编码规范)。
3 验证建议:
•运行完整日志查看原始帧信息:
• ffprobe -i input.mp4 -select_streams v:0 -show_entries frame=all -of compact
• 检查是否有其他帧类型(如 I/P 帧)存在。
三、总结与建议
命令功能
该命令通过 ffprobe 提取视频流中每一帧的 画面类型(pict_type),并以 CSV 格式输出。适用于快速分析视频的帧结构(如检测是否存在 B 帧、验证编码策略)。
输出解读
• 全为 B 帧:可能表明视频采用高压缩率策略,或内容本身适合 B 帧编码。
• 需进一步验证:若怀疑结果不准确,建议检查视频元数据完整性或尝试其他工具(如 MediaInfo)交叉验证。
扩展应用
• 统计不同帧比例:可通过管道连接 grep 和 wc -l 统计各类帧数量。
• 定位关键帧:修改命令为 -show_entries frame=keyframe 可提取 I 帧位置。
四、常见问题解答
Q: 为什么没有看到 I/P 帧? A: 可能原因包括:
1 视频确实全由 B 帧组成(罕见但理论可行)。
2 编码器未正确标记帧类型(尝试更新 ffprobe 或更换工具)。
3 命令参数误过滤了其他帧(检查 -select_streams 是否正确)。
Q: 如何区分不同帧类型的性能影响? A: I 帧质量最高但占用空间大,B 帧压缩率高但解码复杂度更高。平衡三者比例可优化视频质量和文件大小。
Q: 能否直接获取时间戳而非帧序号? A: 可以!修改命令为 -show_entries frame=pkt_pts_time(需配合时间基计算实际时间)