如何用 ffmpeg 找到损坏的视频 50 块钱悬赏答案

ffmpeg -xerror -i filename.mkv -f null -

「 yt-dlp 如何开启日志」的角度，以第一个视频为例：

$ yt-dlp "" > log.txt 2>&1

成功时：

$ cat log.txt
[youtube] olOzlESoEh0: Downloading webpage
[youtube] olOzlESoEh0: Downloading android player API JSON
[info] olOzlESoEh0: Downloading 1 format(s): 248+251
[download] Destination: 220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].f248.webm
[download] 100% of 28.26MiB in 00:01 at 25.82MiB/s
[download] Destination: 220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].f251.webm
[download] 100% of 1.75MiB in 00:00 at 14.48MiB/s
[Merger] Merging formats into "220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].webm"
Deleting original file 220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].f251.webm (pass -k to keep)
Deleting original file 220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].f248.webm (pass -k to keep)

失败时：

$ cat log.txt
[youtube] olOzlESoEh0: Downloading webpage
[youtube] olOzlESoEh0: Downloading android player API JSON
[info] olOzlESoEh0: Downloading 1 format(s): 248+251
[download] Destination: 220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].f248.webm
[download] 100% of 28.26MiB in 00:01 at 17.19MiB/s
[download] Destination: 220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].f251.webm
[download] 100% of 1.75MiB in 00:00 at 5.02MiB/s
[Merger] Merging formats into "220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam [olOzlESoEh0].webm"
ERROR: Postprocessing: Press [q] to stop, [?] for help

@Valyrian 我测试了一下，h264 的视频错误发现了，但是 vp9 的并没有发现，也就是下面链接这个视频
https://drive.google.com/file/d/1Z_kWFZp4YP5q16CixMv_RmlIWIXFTrzb/view?usp=sharing

数一下时间和总帧数对比一下吧

https://stackoverflow.com/questions/2017843/fetch-frame-count-with-ffmpeg
https://superuser.com/questions/650291/how-to-get-video-duration-in-seconds

你这个视频是 30fps 但 60 秒只有 947 帧

$ ffmpeg -i 우주소녀\ 루다\ 부탁해-宽度 720-码率 897.992-编码 vp9-频道名\(지구젤리\)-网页地址 flh-q3MpgVg.mkv
ffmpeg version 5.1 Copyright (c) 2000-2022 the FFmpeg developers
built with Apple clang version 13.1.6 (clang-1316.0.21.2.5)
configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/5.1 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-neon
libavutil 57. 28.100 / 57. 28.100
libavcodec 59. 37.100 / 59. 37.100
libavformat 59. 27.100 / 59. 27.100
libavdevice 59. 7.100 / 59. 7.100
libavfilter 8. 44.100 / 8. 44.100
libswscale 6. 7.100 / 6. 7.100
libswresample 4. 7.100 / 4. 7.100
libpostproc 56. 6.100 / 56. 6.100
Input #0, matroska,webm, from '우주소녀 루다 부탁해-宽度 720-码率 897.992-编码 vp9-频道名(지구젤리)-网页地址 flh-q3MpgVg.mkv':
Metadata:
ENCODER : Lavf59.16.100
Duration: 00:01:00.07, start: 0.000000, bitrate: 594 kb/s
Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, smpte170m/bt470bg/bt709), 720x1228, SAR 1:1 DAR 180:307, 30 fps, 30 tbr, 1k tbn (default)
Metadata:
DURATION : 00:00:59.999000000
Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default)
Metadata:
HANDLER_NAME : ISO Media file produced by Google Inc.
VENDOR_ID : [0][0][0][0]
DURATION : 00:01:00.070000000
At least one output file must be specified

$ ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 우주소녀\ 루다\ 부탁해-宽度 720-码率 897.992-编码 vp9-频道名\(지구젤리\)-网页地址 flh-q3MpgVg.mkv
60.070000

$ ffprobe -v error -select_streams v:0 -count_packets -show_entries stream=nb_read_packets -of csv=p=0 우주소녀\ 루다\ 부탁해-宽度 720-码率 897.992-编 码 vp9-频道名\(지구젤리\)-网页地址 flh-q3MpgVg.mkv
947

@Valyrian 意思是只能通过间接证据推敲视频有没有损坏吗？因为我视频非常的多，用这种方法估计不太现实，ffmpeg 能不能自动分析到错误的帧并且反馈？慢点没关系

@1054850490 这个也可以自动化的，一条命令变成三条命令而已

@Valyrian 好吧这个间接方法对我来说应该没什么用了，要写一个逻辑判断对我来说还是很难做到的，我昵称就是我的 id ，加我拿悬赏吧

@Valyrian 我 id 就是我 qq 账号

要是大段的数据丢失，那可能还能通过媒体流的帧率、总长之类的来推测。
如果只是中间一小段、甚至一两帧损坏，那这种粗粒度的推测就没效果。
要彻底检测，就必须要把每一帧都检查，用 ffplay 加速解码播放，或者用 ffmpeg 选最小的分辨率最快的编码进行转码，整个过程 loglevel 全开，然后在 stderr 里面匹配关键词。

@ungrown 是呀，刚才那个方法不通用，有一个 h264 的视频帧数和原本差不了几帧，很难判断有没有问题，我在想，这些损坏的视频，他们有没有明显的特征？间接证据的方法太难用了

@1054850490 “有一个 h264 的视频帧数和原本差不了几帧”，这个视频能不能发出来看看。如果楼主能追加悬赏得话，我可以写一个 Powershell+FFmpeg 批处理脚本，筛选出所有错误视频。

@acreti
https://drive.google.com/file/d/1TDbxYD0vri0D8aIJ6a1OSY2abE9tc6Lk/view?usp=sharing

就是这个链接的视频，ffmpeg 读取帧数为“2985”，potplayer 读取为“3145”，而我把秒数*帧数的话是“3120”，由于帧速率后面是小数点，我四舍五入当 30 帧了，但是由于视频时长不确定，如果碰到视频时长更长，而且只损坏几帧的话，很容易就当误差范围了，所以我听听你的方法，如果可行的话倒是可以加酬劳，不可行的话就不用浪费太多时间了

@1054850490 你这种情况属于时间戳上丢失了视频帧，如图： https://imgur.com/a/3GKa3nr ，这个视频实际帧数量 2372 帧。脚本代码：ls *.mkv,*.mp4 -Recurse | % {ffmpeg -v 8 -stats -hwaccel cuda -i $_ -fps_mode cfr -f null - 2>Temp.txt; $S=gc Temp.txt -Tail 1; if($S.Contains('dup')){echo $_.FullName$S`n; mv $_ D:\}}

1. 确保 FFmpeg.exe 已在环境变量中，在包含视频的上级目录下 Shift+右键，此处打开 powershell ，运行命令后将筛选文件夹中所有视频。无所谓 h264 、vp9 ，即使只丢失一帧，也能挑出来
2. 脚本只检索了 mkv 和 MP4 ，若有其他后缀的视频，自行添加
3. 默认移出错误视频到 D 盘根目录，可自行更改
4. 运行后会输出错误视频信息和丢失帧数量，如：dup=773
5. 默认开启 N 卡的 cuda 硬件加速，提升解码筛选速度，我这里的筛选速度是视频时长的十几倍，你可以先找个比较长的视频测试下硬解（ ffmpeg -v 8 -stats -hwaccel cuda -i [input] -fps_mode cfr -f null -）和软解（ ffmpeg -v 8 -stats -i [input] -fps_mode cfr -f null -）哪个快一点

@acreti 写错了“速度是视频时长的十几倍”，应为“所需时间是视频时长的十几分之一”

@acreti 请稍等哈，我还在做更多的实验来验证这个可行性

@1054850490 过程中有什么问题，随时问我。毕竟每个人的运行环境都不一样，我这里运行正常。这是我能找到的最快的筛选方案了，而 FFprobe 数帧数量的方法要花费大概 4 倍时间。

@acreti 有个疑问，如果视频本身就是缺帧的，我怎么知道他原本的多少帧的？难道帧数在视频里本身就有记录？然后用 ffmpeg 去遍历帧的看有没有帧错误

@1054850490 原本多少帧，要对比完好无损的原视频。类似于一把梳子，缺了几个针，但基座还在，就是丢帧。帧数量不记录，帧数 FPS 会记录。没有帧错误这么一说，解码 B 帧时要参考后面的帧，但后面的时间戳上没有对应的视频帧，所以解码到此处时出现画面错误，既然后面时间戳上没有视频帧，就会一直显示这个错误画面。不太会解释，不知道你看懂了没有，可以先 Google 一下 I 、P 、B 帧是什么。

@acreti #18 我印象里，ffmpeg 在转码这种损坏的视频时，日志输出里面会有带颜色的警告消息，提示哪里哪里有问题。
但是我印象不深，因为我遇到的这类情况，数量极少，时间久远。
但如果确实如此的话，就可以通过从输出日志里搜索关键词来进行判断。

@1054850490 #10 细节处理肯定不会通用的，但正确的思路、模式是能够泛用的。我实践了一下，发现还是卓有成效的，但并不是每个有问题的视频都会输出类似的错误日志、都会输出相同的关键词，需要针对不同类型的损坏添加特征集，一遍一遍地筛查。但毫无疑问，这个过程肯定是自动化的，是比人工快得多的。

首先作为演示，我们需要一个视频作为对照组，为表诚意，当然得选择“同类型”的视频啦，好在我的收藏里是有这类视频的，虽然只有唯一一个：
[직캠_Fancam] 150520 밤비노(BAMBINO) (은솔) 댄스공연 Intro @ 건양대 [nljhfXCcXlE][pharkil 2015].mp4
https://anonfiles.com/D262Hc6dy4/_Fancam_150520_BAMBINO_Intro_nljhfXCcXlE_pharkil_2015_mp4

那么，先用`ffplay -i filename`来播放它，好的，播放正常，播放过程中可以左右 seek 跳转快进快退，都没问题。不过在播放到结尾的时候，画面并没有消失，ffplay 程序也没有退出，底部状态那一行还在飞速变化，我们看看它显示的什么：
91.23 A-V: -7.910 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
91.23 是当前播放位置，其实已经是视频结束了，这个视频就这么长，所以这个数值尽管在跳动，但其实不变了。
A-V 这个数值，看字面意思，莫非是音频轨和视频轨之间的差值？好像是这样的，播放过程中，这个值是一个在 0 附近跳动的微小数值，体现了音画之间的同步差值。但等到播放结束之后，音频肯定停了，但画面还在跑（虽然只有黑屏），于是这个值开始在负轴上一路狂奔，朝着负无穷勇往直前。
这个时候，如果再按右键进行快进，那么自然是“异常”的，虽然程序不会退出，但是会打印红色的错误信息“error while seeking”，嘛，说得通，毕竟后面已经没了，播放结束了。
那么，如果是加速播放呢，用命令`ffplay -i filename -vf "setpts=0.1*PTS"`，跟刚才差不多。唯一不同是，播放过程之中，A-V 就开始往负轴跑，毕竟音画不同步了，这个命令只调快了画面。顺便，setpts=0.1*PTS 按理来说应该是 10 倍速播放，但结果显然不是，只有 2 倍多一点，我不知道为什么，先不管。
那么，如果换用 ffmpeg 转码呢，自然也是没问题的，因为这个视频本身没问题嘛，所以转码过程没任何不良消息。顺便一提，我这台笔记本显卡是 RTX 3050 Ti ，30 系显卡的硬件转码真的是又好又快啊，我用 ffmpeg 自带的 nvenc 编码器，转码倍速能到 20x ，即使不缩小输出画面尺寸也能有 18x 。

好了，对照组完毕，现在来看看实验组样品。

220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam-宽度 1920-码率 4445.735-编码 avc1.640028-频道名(전람회)-网页地址 olOzlESoEh0.[origin].mkv
出门口的这个视频。
这个视频问题明显，所以输出日志中的错误消息也很明显，一大串的类似下面截取的消息：
[NULL @ 000002e318718d40] missing picture in access unit with size 276
[h264 @ 000002e318771000] Invalid NAL unit size (0 > 5688).
[h264 @ 000002e318771000] Error splitting the input into NAL units.
[NULL @ 000002e318718d40] Invalid NAL unit size (0 > 36089).
[NULL @ 000002e318718d40] missing picture in access unit with size 36093
[h264 @ 000002e3187aec00] Invalid NAL unit size (0 > 7954).
[h264 @ 000002e3187aec00] Error splitting the input into NAL units.
[NULL @ 000002e318718d40] Invalid NAL unit size (0 > 5930).
[NULL @ 000002e318718d40] missing picture in access unit with size 5934
[h264 @ 000002e3187af0c0] Invalid NAL unit size (0 > 21100).
[h264 @ 000002e3187af0c0] Error splitting the input into NAL units.
[NULL @ 000002e318718d40] Invalid NAL unit size (0 > 19469).
[NULL @ 000002e318718d40] missing picture in access unit with size 19473
真的是一大串，不停地刷屏。你看，这种特征明显，关键字固定的错误最好找了对不对？ ffplay 和 ffmpeg 跑都是这样的错误，好了，这个类型的损坏视频算是搞定了。

우주소녀 루다 부탁해-宽度 720-码率 897.992-编码 vp9-频道名(지구젤리)-网页地址 flh-q3MpgVg.[origin].mkv
舞台上白色短裙的这个视频。
这个视频特征不明显。ffmpeg 转码（目标容器格式维持原格式，mkv ）的时候，一共蹦出来三行警告：
[matroska @ 000001745e3eae40] Invalid DTS: 15100 PTS: 10133 in output stream 0:0, replacing by guess
[matroska @ 000001745e3eae40] Invalid DTS: 25233 PTS: 17700 in output stream 0:0, replacing by guess
[matroska @ 000001745e3eae40] Invalid DTS: 45500 PTS: 35267 in output stream 0:0, replacing by guess
但如果转成 mp4 的话，则完全没提示任何错误警告，仿佛没事一样。
那么如果用 ffplay 来播放呢，也没输出错误警告。
好吧，这种缺帧的视频我们就认怂换个思路，老老实实比对实际帧数和理论帧数吧。

@ungrown 由于前面已经有人回复了，但是回答得很详细，可以给你 30 悬赏，我的昵称前加“go”就是我的微信号，加我拿一下悬赏

@acreti 可以加一下我的微信，我的昵称前加“go”，我可以追加悬赏

我怀疑自己会不会要你的悬赏，我甚至怀疑另一个人是不是冲着你的悬赏才来分享方法的。
但在此之前，我更在意的是，他的那个方法，能不能适用于所有损坏的视频。

@ungrown 来拿悬赏吧，没事的，这是你应得的

@1054850490 #24 我只想知道，计算对比帧数的方法，能不能广泛用于各种视频损坏。

BTW 没人应得什么，没什么东西是谁应得的，任何人，所有人，无一例外。

@ungrown 我还在验证，我在测试的时候发现有些视频也少了几帧，但是播放起来一点事也没有，我还在纳闷成因是什么

@ungrown
这是一个完全损坏的视频，目前也不知道成因
https://drive.google.com/file/d/1FqWz5MZkdCoO-z0SRvhMPJc7DkVpfsrq/view?usp=sharing

--------------------------
这是一个缺少了 43 帧的视频，但是播放起来也没事
https://drive.google.com/file/d/1rhL9vVxAlSG8oENfuEkigZTTi33kblSs/view?usp=sharing

它缺的那几帧如果不是连续的二十分散再各处的话，人眼很难看出来的

@ungrown 这倒是，但是还有很多只是缺少 3 帧左右的，一般一个 m3u8 也不止这几帧，我还很纳闷这到底是怎么丢的，
我现在是用 yt-dlp+arid2+ffmpeg 合成来下载的，至于损坏视频是近些时间才发现的，但是用了上面老兄的方法排除的视频，我发现从年初开始就有了，六月初进行了一次系统重装，ffmpeg 又更新到最新版本了，但是六月之后也出现了损坏视频的情况，我还是得发帖到 yt-dlp 社区看看有没有人类似的情况

@1054850490 #29
我没有用 yt-dlp ，我用的 youtube-dl ，我其实有点想用 dlp 的，但是我已经在原版的基础上魔改了几个提取器的 class ，比如 iwara 的，我又严重依赖这些改动，用着又没啥毛病，我又懒，所以我就没换 dlp 。

我的 youtube-dl 的配置文件：
--cookies ~/.config/youtube-dl/cookies.youtube.txt
-o "%(title)s [%(extractor)s %(id)s][%(uploader)s].%(ext)s"
--yes-playlist
--fragment-retries infinite
-icw
--external-downloader aria2c
--external-downloader-args "-x10 -s10 -k 1M"
-f (299/137)[height<=?1080][fps<=60]+(m4a/aac)/bestvideo+bestaudio/best
#--socket-timeout 30
#-R infinite

我用自己写的 tg bot 辅助下载，把 url 往 bot 聊天里面一扔就不管了，所以那一大堆下载的视频我并没有挨个仔细检查过。但就我确实打开观看过的那些视频来说，我没有发现肉眼可见的损坏，也许也少了几帧，那这种我肯定是不在乎的。
然后我从油管下载的时候，从来没走过 hls 协议，没看到 m3u8 相关的信息，基本全是 dash mp4 流，一个视频流一个音频流，全是 aria2c 下载的，可能跟我限定了媒体格式有关，就是这行配置`-f (299/137)[height<=?1080][fps<=60]+(m4a/aac)/bestvideo+bestaudio/best`。
从 p 站下的视频倒是经常走 hls ，然后偏偏 aria2 不支持 hls 嘛，然后它就分段下载，哎哟我去那个龟速我就日了，前几天我刚刚研究了这个事情，给 p 站 url 开了一个处理分支加了一点参数，`-f [format_id!*=hls]`，把带 hls 标记的媒体流给排除掉了，终于又可以通过 aria2c 秒速下载了。
hls 真的是坏东西，对下载而言，我个人觉得。

@ungrown 我算是研究清楚了，我那个视频损坏常发生于磁盘满的情况下，因为 arin2 是分段下载，不是 ts ，是私有的后缀，列如这里有 1 、2 、3 、4 、5 ，五个片段，aria2 下载完成了其中的 1245 ，虽然 3 也创建了，但是因为中间磁盘满了，下载并不完全，但是依旧发生了合成，就会出现中间缺少帧数的情况，如同下图中的情况



中间缺失的就是因为下载过程中下载不完全，却依旧发生了合成导致的结果，我目前还在开着日志尝试捕捉更多信息，但是目前也不知道怎么会发生合成的，我不知道你了不了解 m3u8 ，我不知道如果其中一个 ts ，直接用一个“毫无意义”的程序，比如用一个 exe 程序，改名为其中一个 ts 片段不知道会不会依旧合成

@1054850490 #31
还有服务端的原因。
我后来看自己下载的视频，也遇到了几个，要么是特别长的，要么是下载过程中有过中断重试的（回忆可能不准）。都是 invalid NAL unit 的错误，我用这个关键词搜了一下，github 上有人说这是服务端问题，也就是有时候油管抽风给的某些格式的流切片就有问题，我也懒得验证，只能不置可否。