🤖 AI 代码检视意见 | 🔒 Security | 🚨 Critical | 行号区间: L590-L599

问题描述: 在 record_video_frame 函数中，若 data1 的 malloc 失败，data2 尚未被赋值，此时 frData.data2 仍为栈上的随机未初始化值。随后执行的 free(frData.data2) 会对该野指针进行释放，导致未定义行为、堆损坏或直接崩溃。

frData.data0 = NULL;
frData.data1 = NULL;
frData.data2 = NULL;
frData.data0 = (uint8_t *)malloc((size_t)frame->linesize[0] * frame->height);
frData.data1 = (uint8_t *)malloc((size_t)frame->linesize[1] * frame->height / DATA_NUM_2);
frData.data2 = (uint8_t *)malloc((size_t)frame->linesize[1] * frame->height / DATA_NUM_2);
if (!frData.data0 || !frData.data1 || !frData.data2) {
LOGE("record_video_frame: malloc failed");
free(frData.data0);
free(frData.data1);
free(frData.data2);
return;
}

【AI-Review】【一般】【基础代码问题】【资源使用问题】ffp_start_record 停止旧录制时未释放旧 recordFilePath 导致内存泄漏

● 问题：当 ffp->record_write_data.recThreadid 非零时，代码会停止旧录制线程然后启动新录制。但在 pthread_join 之后、分配新 filePath 之前，未释放旧的 ffp->record_write_data.recordFilePath。旧录制线程的 WriteRecordFile 在 fail 路径和正常路径中均不会释放 recordFilePath（FreeRecordFrames 只释放 recordFramesQueue），因此每次重新开始录制都会泄漏上一次的 recordFilePath。

● 影响：一般。频繁调用 ffp_start_record（先停止再重新录制）会累积内存泄漏。每次泄漏大小为录制文件路径字符串长度+1。

● 建议：在 pthread_join 之后、分配新 filePath 之前，释放旧的 recordFilePath：

if (ffp->record_write_data.recThreadid) {
    ffp->record_write_data.isInRecord = OHOS_RECORD_STATUS_OFF;
    UpdateRecordStatus(ffp, OHOS_RECORD_STATUS_OFF);
    pthread_join(ffp->record_write_data.recThreadid, NULL);
    ffp->record_write_data.recThreadid = 0;
    free(ffp->record_write_data.recordFilePath);
    ffp->record_write_data.recordFilePath = NULL;
}

【AI-Review】【严重】【基础代码问题】【代码逻辑错误】ffp_start_record 中 recThreadid 非零时未释放 recordFilePath 和 recordFramesQueue

● 问题：ffp_start_record 中当 ffp->record_write_data.recThreadid 非零时，会先 pthread_join 等待旧线程结束，但 pthread_join 之后旧的 recordFilePath 和 recordFramesQueue 没有被释放就立即分配新的。WriteRecordFile 线程中 FreeRecordFrames 会释放 recordFramesQueue，但 recordFilePath 只在 fail 路径中被释放。如果录制正常完成（非 fail 路径），recordFilePath 由 ReleaseResources 释放——但 ReleaseResources 只释放 oc 相关资源，不释放 recordFilePath。因此每次重复调用 ffp_start_record 都会泄漏上一次的 recordFilePath。

● 影响：严重。每次重复启动录制都会泄漏 recordFilePath 的内存。在频繁开始/停止录制的场景下，内存泄漏会持续累积。

● 建议：在 pthread_join 之后释放旧的 recordFilePath：

if (ffp->record_write_data.recThreadid) {
    ffp->record_write_data.isInRecord = OHOS_RECORD_STATUS_OFF;
    UpdateRecordStatus(ffp, OHOS_RECORD_STATUS_OFF);
    pthread_join(ffp->record_write_data.recThreadid, NULL);
    ffp->record_write_data.recThreadid = 0;
    // 释放旧的录制资源
    if (ffp->record_write_data.recordFilePath) {
        free(ffp->record_write_data.recordFilePath);
        ffp->record_write_data.recordFilePath = NULL;
    }
    if (ffp->record_write_data.recordFramesQueue) {
        free(ffp->record_write_data.recordFramesQueue);
        ffp->record_write_data.recordFramesQueue = NULL;
    }
}

【AI-Review】【严重】【基础代码问题】【代码逻辑错误】filePath malloc 返回值未检查导致空指针崩溃

● 问题：char* filePath = (char*)malloc(strlen(recordFilePath) + 1) 的返回值未做 NULL 检查，紧接着 memcpy(filePath, recordFilePath, strlen(recordFilePath) + 1) 会对 NULL 指针写入，导致程序崩溃。本 PR 对 recordFramesQueue 的 malloc 已添加了 NULL 检查，但对 filePath 的 malloc 遗漏了。

● 影响：严重。当内存不足时 malloc 返回 NULL，后续 memcpy 会导致空指针写入崩溃（SIGSEGV），录制功能不可用且可能影响整个播放器进程稳定性。

● 建议：添加 NULL 检查，与 recordFramesQueue 的处理方式保持一致：

char* filePath = (char*)malloc(strlen(recordFilePath) + 1);
if (!filePath) {
    LOGE("filePath malloc failed");
    free(ffp->record_write_data.recordFramesQueue);
    ffp->record_write_data.recordFramesQueue = NULL;
    return OHOS_RECORD_CALLBACK_STATUS_FAILED;
}
memcpy(filePath, recordFilePath, strlen(recordFilePath) + 1);

【AI-Review】【一般】【基础代码问题】【稳定性问题】ffp_stop_record 中 pthread_join 可能长时间阻塞调用线程

● 问题：ffp_stop_record 中新增了 pthread_join(ffp->record_write_data.recThreadid, NULL) 等待 WriteRecordFile 线程完成。但 WriteRecordFile 中的 StartEncoderWrite 循环需要编码并写入所有缓存的帧，在视频较长或编码速度慢时可能非常耗时。如果 ffp_stop_record 从 UI 线程调用，会导致界面卡顿甚至 ANR。

● 影响：一般。停止录制时可能导致 UI 线程阻塞，用户体验差。

● 建议：考虑将 pthread_join 改为异步等待机制，或设置超时。例如在 WriteRecordFile 线程完成后再回调通知结果（已有 FindRecordResult 的条件变量机制），避免在 ffp_stop_record 中同步等待：

int ffp_stop_record(FFPlayer *ffp)
{
    if (!ffp) {
        return OHOS_RECORD_STATUS_OFF;
    }
    ffp->record_write_data.isInRecord = OHOS_RECORD_STATUS_OFF;
    UpdateRecordStatus(ffp, OHOS_RECORD_STATUS_OFF);
    // 不在此处 pthread_join，让 WriteRecordFile 线程自行退出后通过 FindRecordResult 异步获取结果
    return FindRecordResult(ffp);
}

FindRecordResult 已有条件变量等待机制，可以设置合理的超时时间。

【AI-Review】【建议】【软件设计】【冗余重复代码】FlushVideoEncoder 和 FlushAudioEncoder 代码高度重复

● 问题：FlushVideoEncoder 和 FlushAudioEncoder 的逻辑几乎完全相同，仅编码函数不同（avcodec_encode_video2 vs avcodec_encode_audio2）和日志信息不同。两个函数共约 60 行代码，重复度超过 90%。

● 影响：建议。功能正确，但增加了维护成本——修改一处逻辑时容易遗漏另一处。

● 建议：可提取公共模板函数，通过函数指针或编码类型参数区分：

static void FlushEncoder(AVFormatContext *oc, OutputStream *ost,
                         int (*encodeFunc)(AVCodecContext*, AVPacket*, AVFrame*, int*),
                         const char *encoderName)
{
    if (!oc || !ost || !ost->st) return;
    AVCodecContext *c = ost->st->codec;
    if (!c) return;
    for (;;) {
        AVPacket pkt = {0};
        int gotPacket = 0;
        av_init_packet(&pkt);
        int ret = encodeFunc(c, &pkt, NULL, &gotPacket);
        if (ret < 0) {
            LOGE("Flush %s encoder failed: %s", encoderName, av_err2str(ret));
            av_packet_unref(&pkt);
            break;
        }
        if (!gotPacket) { av_packet_unref(&pkt); break; }
        ret = WriteFrame(oc, &c->time_base, ost->st, &pkt);
        av_packet_unref(&pkt);
        if (ret < 0) {
            LOGE("Flush %s encoder write failed: %s", encoderName, av_err2str(ret));
            break;
        }
    }
}

【AI-Review】【一般】【基础代码问题】【性能和效率问题】FlushVideoEncoder/FlushAudioEncoder 使用已废弃的 FFmpeg API

● 问题：新增的 FlushVideoEncoder 和 FlushAudioEncoder 使用了 avcodec_encode_video2 和 avcodec_encode_audio2。这两个 API 在 FFmpeg 3.1+ 中已被标记为 deprecated，推荐使用 avcodec_send_frame + avcodec_receive_packet 的组合。虽然当前代码库可能仍在使用旧 API（如 HandleEncodeWritePicture 中的 avcodec_encode_video2），但新增代码应避免使用废弃 API，以减少未来升级 FFmpeg 版本时的迁移工作量。

● 影响：一般。使用废弃 API 不会立即导致功能问题，但会增加未来 FFmpeg 版本升级的迁移成本，且旧 API 可能在未来版本中被移除。

● 建议：使用推荐的 avcodec_send_frame(NULL) + avcodec_receive_packet 模式进行编码器刷出：

static void FlushVideoEncoder(AVFormatContext *oc, OutputStream *ost)
{
    AVCodecContext *c;
    int ret;
    if (!oc || !ost || !ost->st) return;
    c = ost->st->codec;
    if (!c) return;
    ret = avcodec_send_frame(c, NULL);
    if (ret < 0 && ret != AVERROR_EOF) {
        LOGE("Flush video encoder send failed: %s", av_err2str(ret));
        return;
    }
    while (true) {
        AVPacket pkt = {0};
        av_init_packet(&pkt);
        ret = avcodec_receive_packet(c, &pkt);
        if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
            av_packet_unref(&pkt);
            break;
        }
        if (ret < 0) {
            LOGE("Flush video encoder receive failed: %s", av_err2str(ret));
            av_packet_unref(&pkt);
            break;
        }
        ret = WriteFrame(oc, &c->time_base, ost->st, &pkt);
        av_packet_unref(&pkt);
        if (ret < 0) {
            LOGE("Flush video encoder write failed: %s", av_err2str(ret));
            break;
        }
    }
}

【AI-Review】【一般】【基础代码问题】【稳定性问题】StartEncoderWrite 中 swsState 未显式初始化

● 问题: StartEncoderWrite 函数中 RecordVideoSwsState swsState 是局部栈变量，其 swsContext、lastSrcWidth、lastSrcHeight 字段未显式初始化。虽然 C++ 中带有默认值初始化（struct 定义中有 = nullptr 和 = 0），但 swsState 是局部变量，如果后续代码依赖这些字段为 0/nullptr 来做判断（如 UpdateRecordVideoSwsContext 中比较 fr->width != state->lastSrcWidth），未初始化的值可能导致首次比较错误。

● 影响: 一般。如果编译器未正确零初始化，首次 sws_getContext 调用可能使用错误的 outWidth/outHeight（0x0），导致 sws_scale 失败。

● 建议: 显式初始化 swsState：

RecordVideoSwsState swsState = {0};

或者使用 memset(&swsState, 0, sizeof(swsState));，确保所有字段为零初始化。

【AI-Review】【严重】【基础代码问题】【代码逻辑错误】srcFormat 为零时 StartEncoderWrite 的 fallback 路径使用零分辨率

● 问题: PR 删除了 record_video_frame 和 RecordMediaCodecVideoFrame 中对 srcFormat.height/width 的实时更新，改为在 ffp_start_record 中清零并在 InitRecordOutputResolution 中从已有帧初始化。但 StartEncoderWrite 中新增的 fallback 路径 swsState.outWidth = videoCodec ? videoCodec->width : recordWriteData->srcFormat.width 在 videoCodec 为 NULL 时回退到 srcFormat.width。如果录制开始时只有音频帧、没有视频帧（InitRecordOutputResolution 找不到视频帧），则 srcFormat.width/height 为 0，导致 sws_getContext 以 0x0 目标分辨率创建上下文，后续 sws_scale 必定失败。

● 影响: 严重。纯音频流或首帧非视频帧的场景下，录制输出文件可能损坏或录制失败。

● 建议: 在 StartEncoderWrite 中增加对 outWidth/outHeight 为 0 的防护：

swsState.outWidth = videoCodec ? videoCodec->width : recordWriteData->srcFormat.width;
swsState.outHeight = videoCodec ? videoCodec->height : recordWriteData->srcFormat.height;
if (swsState.outWidth <= 0 || swsState.outHeight <= 0) {
    LOGE("StartEncoderWrite: invalid output resolution %dx%d", swsState.outWidth, swsState.outHeight);
    return;
}

【AI-Review】【一般】【基础代码问题】【代码逻辑错误】WriteHeader 仍直接调用 CalculateFrameRate 可能返回负帧率

● 问题：av_dict_set_int(&opt, "video_track_timescale", CalculateFrameRate(mFFPlayer), 0) 仍直接调用 CalculateFrameRate，未使用本 PR 新增的 GetSafeRecordFrameRate。CalculateFrameRate 在 PTS 乱序时可返回负值，将负值设为 video_track_timescale 可能导致编码器行为异常。本 PR 已将 OpenVideo、VideoAudioStreamAndAvcodecOpen、WriteRecordFile 中的帧率获取统一替换为 GetSafeRecordFrameRate，但 WriteHeader 遗漏了。

● 影响：一般。在 PTS 乱序的异常视频流中，可能向编码器设置负 timescale 值，导致录制输出文件损坏。

● 建议：统一使用 GetSafeRecordFrameRate：

if (frameRate <= 0) {
    av_dict_set_int(&opt, "video_track_timescale", GetSafeRecordFrameRate(mFFPlayer), 0);
}

【AI-Review】【一般】【基础代码问题】【代码逻辑错误】FindRecordResult 先 find 再 wait_for 存在通知丢失风险

● 问题：PR 修改了 FindRecordResult，在 wait_for 之前先查找 ijkplayerRecordResultMap。逻辑意图是：如果结果已在之前写入map，直接返回避免不必要的等待。但现有实现存在通知丢失风险——如果在 find 返回 end() 之后、wait_for 调用之前，另一个线程调用了 UpdateRecordResult 写入结果并 notify_one()，那么 wait_for 将错过这个通知，一直等到超时才返回失败。这是因为 unique_lock 在 find 之前就已持有，但 UpdateRecordResult 中的 lock_guard 也会争抢同一把锁，所以实际上不会并发。但更根本的问题是：ffp_stop_record 中新增的 pthread_join 确保 WriteRecordFile 已完成，那么在 pthread_join 返回时 UpdateRecordResult 应该已经被调用。此时 FindRecordResult 的 find 一定能命中，wait_for 分支永远不会执行。这意味着 wait_for 逻辑变得冗余，但不会导致功能错误。

● 影响：一般。逻辑冗余，不会导致功能错误，但增加了代码理解的复杂度。如果未来移除 ffp_stop_record 中的 pthread_join，则 wait_for 超时可能导致录制结果丢失。

● 建议：如果 ffp_stop_record 中保留 pthread_join，可以简化 FindRecordResult 的逻辑——在 ffp_stop_record 调用路径下结果必定已写入，直接 find 即可。如果后续移除 pthread_join，则需要将 find 和 wait_for 合并在同一个锁区间内避免竞态：

std::unique_lock<std::mutex> lock(ijkplayerRecordResultMutex);
auto it = ijkplayerRecordResultMap.find(ffp);
if (it != ijkplayerRecordResultMap.end()) {
    return it->second;
}
if (ijkplayerRecordResultCondition.wait_for(lock,
    std::chrono::milliseconds(RECORD_RESULT_TIMEOUT_MS)) == std::cv_status::no_timeout) {
    it = ijkplayerRecordResultMap.find(ffp);
    if (it != ijkplayerRecordResultMap.end()) {
        return it->second;
    }
}