为什么 ffmpeg 在将所有请求的帧添加到剪辑之前退出?

为什么 ffmpeg 在将所有请求的帧添加到剪辑之前退出?

我在使用 ffmpeg 从安全摄像头收集 .jpg 文件并制作 .avi 文件时遇到了问题。摄像头会以最快的速度定期以 FTP 方式传输帧,一天内会累积大约 16000 到 20000 帧。晚上,当我的 Hughesnet 数据上限放宽时,我使用 cron 作业将这些帧连接成一个 avi 文件,可以在早上保存/扫描。

典型的文件名可能是: FrontDeer_20230218-101637.jpg其中
FrontDeer是相机名称,
20230218是日期,
101637是时间。

ls -l Front\*18-\*.jpg | wc -l gives a count of 16284 files.

我制作视频的失败尝试如下:

ffmpeg -pattern_type glob -i 'Front\*18-\*.jpg' -s 800x600 -v verbose Ftest2.avi

它始终停止在编码 2354 帧的位置。

ffmpeg 的详细输出以以下内容结束:

No more output streams to write to, finishing.
frame= 2534 fps= 24 q=8.8 Lsize=    8122kB time=00:05:16.75 bitrate= 210.1kbits/s
video:8056kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.821897%
Input file #0 (Front\*18-\*.jpg):
  Input stream #0:0 (video): 2534 packets read (128534848 bytes); 2534 frames decoded;
  Total: 2534 packets (128534848 bytes) demuxed
Output file #0 (Ftest2.avi):
  Output stream #0:0 (video): 2534 frames encoded; 2534 packets muxed (8249089 bytes);
  Total: 2534 packets (8249089 bytes) muxed
2534 frames successfully decoded, 0 decoding errors

我不能说我已经阅读了所有 ffmpeg 文档,或者理解了我所读到的所有内容。无论如何,我还没有找到一个看似简单但却行不通的解决方案。我是否必须设置某种缓冲区限制才能允许编码更多帧?

系统细节如下

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    2
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 28
Model name:            Intel(R) Atom(TM) CPU N455   @ 1.66GHz

               Total       used         free         shared     buff/cache available
Mem:           1982         421          94          58        1466        1284
Swap:          2035         108        1927

NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ffmpeg version 2.8.17-0ubuntu0.1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.12) 20160609

非常感谢您的帮助

答案1

很抱歉打扰了社区。事实证明,问题不在于 ffmpeg,而在于摄像头偶尔会将损坏的帧发送到正确命名的文件。正是在那时,ffmpeg 失败了,但这并不是错。感谢您的关注。我希望这个问题/答案不会经常被提起,因为它并不真正适用。

相关内容