AVideo项目视频损坏检测与自动修复方案解析

问题背景

在AVideo项目中，部分用户上传的视频文件存在损坏问题，但系统未能正确识别并标记为"损坏"状态。这种情况会导致用户体验下降，管理员也难以快速定位和处理问题视频。经过分析，发现视频损坏的主要原因包括：

1. 服务器资源不足导致转码过程中断
2. 长时间录制(如11小时)超出系统处理能力
3. 文件传输或存储过程中出现错误

技术解决方案

方案一：NGINX录制限制配置

针对长时间录制导致的问题，可通过配置NGINX的RTMP模块参数来限制单个录制文件的大小和时长：

recorder video { 
    record all manual; 
    record_path /var/www/tmp; 
    record_notify on; 
    record_max_size 4600M;  # 设置4小时视频的最大尺寸
    record_suffix -%d-%b-%y-%T.flv; 
}

计算原理：

1. 估算视频流的比特率(如720p约2.5Mbps)
2. 转换为MB/s(2.5Mbps = 0.3125MB/s)
3. 计算4小时(14400秒)的总文件大小(0.3125 * 14400 ≈ 4.5GB)

方案二：自动化监控脚本

当NGINX版本不支持record_max_size参数时，可采用Bash脚本监控方案：

#!/bin/bash

RECORDING_PATH="/var/www/tmp"
MAX_SIZE=5368709120  # 5GB
MAX_DURATION=14400   # 4小时

while true; do
    current_recording=$(find "$RECORDING_PATH" -name "*.flv" -type f -printf "%T@ %p\n" | sort -n | tail -1 | cut -d ' ' -f2-)
    
    if [ -n "$current_recording" ]; then
        create_time=$(stat -c %Y "$current_recording")
        current_time=$(date +%s)
        duration=$((current_time - create_time))
        current_size=$(du -b "$current_recording" | cut -f1)
        
        if [ $duration -gt $MAX_DURATION ] || [ $current_size -gt $MAX_SIZE ]; then
            new_name=$(date '+%d-%b-%y-%T')-$(basename "$current_recording")
            mv "$current_recording" "${RECORDING_PATH}/${new_name}"
            # 触发新录制逻辑
        fi
    fi
    sleep 60
done

该脚本通过定时检查文件大小和创建时间，自动分割超限的录制文件，具有以下优势：

1. 不依赖NGINX版本
2. 同时监控大小和时间维度
3. 可灵活调整参数

系统优化建议

1. 服务器资源配置：确保服务器有足够的内存(建议64GB以上)处理长时间录制和转码任务
2. 版本升级：使用最新版NGINX以获得完整的功能支持
3. 错误检测机制：在删除原始文件前验证转码结果
4. 自动化标记：开发定期扫描损坏视频的脚本，自动标记问题文件

实施效果

通过上述方案的实施，AVideo项目可以：

• 有效预防因资源不足导致的视频损坏
• 自动分割超长录制，提高系统稳定性
• 快速识别并隔离问题视频，提升管理效率
• 为用户提供更可靠的媒体服务体验

这套解决方案不仅解决了当前问题，还为类似视频平台提供了可借鉴的技术实践。