5

这是一个简洁的问题,而不是“告诉我什么代码有效”,而是“我如何在逻辑上处理这种情况”的问题。

简而言之,我有来自 IP 摄像机通过 RTSP 的视频 + 音频。

视频和音频通过单独的线程逐帧解码并记录到单个 mp4 容器中(如下所示)。

问题是视频和音频随着时间的推移变得越来越不同步,这是由于每个视频帧的 TimeSpan 结束时间和开始时间缺乏精确性。

每个视频帧的持续时间应该是 1 / framerate = 0.0333667000333667,但它使用(即使使用 FromTicks() 方法),第一帧的开始时间 = 0.0 和结束时间 0.0333667。

我可以从 29.97 调整视频解码器的帧率值(它是从相机的设置声明的帧率中提取的),导致视频先于音频,或者滞后于音频——这只是让每个视频 mediaBuffer.StartTime 和 mediaBuffer .EndTime 与音频相比太早或太晚。

随着时间的推移,微小的十进制截断最终会使视频和音频不同步——录制的时间越长,两个轨道就越不同步。

我真的不明白为什么会发生这种情况,因为舍入误差在逻辑上应该不重要。

即使我只有 1 秒的精度,我也只会每秒写一个视频帧,它在时间轴中的位置大致应该是 +- 1 秒,这应该使每个渐进帧都相同 + - 1 秒到它应该在的位置,而不是逐渐增加更多的错位。我想象这对于每一帧来说都是这样的:

[<-------- -1 秒 --------> 预期的确切帧时间 <-------- +1 秒 -------->] --- ------------------------------------------------- 记录帧时间--------

我在这里错过了什么吗?

我不是在做“新帧开始时间 = 上一帧结束时间,新帧结束时间 = 新帧开始时间 + 1 / 帧率”——我实际上是在做“新帧开始时间 = 帧索引 - 1 / 帧率,新帧结束时间 = 帧索引 / 帧率”。

也就是说,我正在根据它们应该具有的预期时间(帧时间 = 帧位置/帧速率)计算帧开始和结束时间。

我的代码在做什么是这样的:

预期时间 ---------- 预期时间 ---------- 预期时间 帧时间 帧时间 帧时间

我从数学上理解这个问题,我只是不明白为什么小数截断会证明这样一个问题,或者从逻辑上知道解决它的最佳解决方案是什么。

如果我实现“每 x 帧,使用“(1 / 帧率)+ 一些量”来弥补所有缺失的时间,是否有可能使帧匹配到它们应该在的位置,或者只是导致混乱的视频?

    public void AudioDecoderThreadProc()
    {
        TimeSpan current = TimeSpan.FromSeconds(0.0);

        while (IsRunning)
        {
            RTPFrame nextFrame = jitter.FindCompleteFrame();

            if (nextFrame == null)
            {
                System.Threading.Thread.Sleep(20);
                continue;
            }

            while (nextFrame.PacketCount > 0 && IsRunning)
            {
                RTPPacket p = nextFrame.GetNextPacket();

                if (sub.ti.MediaCapability.Codec == Codec.G711A || sub.ti.MediaCapability.Codec == Codec.G711U)
                {
                    MediaBuffer<byte> mediaBuffer = new MediaBuffer<byte>(p.DataPointer, 0, (int)p.DataSize);
                    mediaBuffer.StartTime = current;
                    mediaBuffer.EndTime = current.Add(TimeSpan.FromSeconds((p.DataSize) / (double)audioDecoder.SampleRate));

                    current = mediaBuffer.EndTime;

                    if (SaveToFile == true)
                    {
                        WriteMp4Data(mediaBuffer);
                    }
                }
            }
        }
    }

    public void VideoDecoderThreadProc()
    {
        byte[] totalFrame = null;

        TimeSpan current = TimeSpan.FromSeconds(0.0);
        TimeSpan videoFrame = TimeSpan.FromTicks(3336670);
        long frameIndex = 1;

        while (IsRunning)
        {
            if (completedFrames.Count > 50)
            {
                System.Threading.Thread.Sleep(20);
                continue;
            }

            RTPFrame nextFrame = jitter.FindCompleteFrame();

            if (nextFrame == null)
            {
                System.Threading.Thread.Sleep(20);
                continue;
            }

            if (nextFrame.HasSequenceGaps == true)
            {
                continue;
            }

            totalFrame = new byte[nextFrame.TotalPayloadSize * 2];
            int offset = 0;

            while (nextFrame.PacketCount > 0)
            {
                byte[] fragFrame = nextFrame.GetAssembledFrame();

                if (fragFrame != null)
                {
                    fragFrame.CopyTo(totalFrame, offset);
                    offset += fragFrame.Length;
                }
            }

            MediaBuffer<byte> mediaBuffer = new MediaBuffer<byte>(
                totalFrame,
                0,
                offset,
                TimeSpan.FromTicks(Convert.ToInt64((frameIndex - 1) / mp4TrackInfo.Video.Framerate * 10000000)),
                TimeSpan.FromTicks(Convert.ToInt64(frameIndex / mp4TrackInfo.Video.Framerate * 10000000)));

            if (SaveToFile == true)
            {
                WriteMp4Data(mediaBuffer);
            }

            lock (completedFrames)
            {
                completedFrames.Add(mediaBuffer);
            }

            frameIndex++;
        }
    }
4

2 回答 2

1

突出的一件事是您的帧率计算是错误的。

每个视频帧的持续时间应该是 1 / framerate = 0.0333667000333667

那是您29.97用作帧速率的时候。29.97 只是一个显示值。实际帧率是30 / 1.001 = 29.97002997002997FPS。因此,一帧持续1 / (30 / 1.001) = 0.0333666666666667几秒钟。来源,见“60i”。

于 2013-01-31T22:18:22.867 回答
1

您应该注意以下几点:

  1. 不正确的手动帧时间戳。手动计算帧持续时间通常是一个坏主意,而不是让驱动程序/卡/任何给你帧时间的东西。由于可变比特率、内部计算机时序等原因,自己标记帧几乎总是会导致漂移。

  2. 精密漂移。在处理以毫秒为单位的帧时间戳时,我遇到了偏差,但我的源时间戳以纳秒为单位。这要求我将双倍转换为长。

    例如,我从 directshow 获得以纳秒为单位的媒体时间,但是我的内部计算需要以毫秒为单位。这意味着我需要在 ns 和 ms 之间进行转换。对我来说,这就是精度损失所在。我对此的解决方案是您需要跟踪任何精度损失。

    我过去所做的是我有一个正在运行的“timingFraction”计数器。基本上任何时候我做除法,这给了我一个帧的基本时间戳(所以帧时间/NS_PS_MS)。但是,我还将预制时间戳的丢弃小数部分添加到计时分数计数器(在 c++ 中我使用了该modf函数)。现在,如果时间分数是整数,我将转换的时间戳(这是一个整数,因为它被转换为 long)与剩余的时间分数相加。基本上,如果您累积了额外的毫秒,请确保将其添加到帧中。这样您就可以补偿任何精度漂移。

  3. 手风琴效果。 虽然随着时间的推移,一切都可能加起来是正确的,你认为即使在 1 秒的造粒过程中,事情也应该匹配,但它们不会。音频需要完美匹配,否则听起来会很奇怪。这通常的特点是您在正确的时间听到来自某人的正确音频,但嘴唇没有对齐。随着时间的推移,一切都还好,但没有什么完全一致的。这是因为您没有在正确的时间渲染帧。有些帧有点太长,有些帧有点太短,总而言之,一切都加起来是正确的,但没有什么是正确的长度。

现在,如果您的精度已经达到 100 纳秒级别,为什么您会遇到这个问题,在我看来这可能是第 1 项。我会验证您是否确定在继续之前计算正确的结束时间戳。

我有时也会运行测试,总结帧之间的增量并确保添加正确。流持续时间内每帧之间的时间总和应等于流的时间。即第 1 帧长 33 毫秒,第 2 帧长 34 毫秒,而您录制了 67 毫秒。如果您录制 70 毫秒,您会在某处丢失一些东西。漂移通常会在几个小时后出现,并且在将音频和视频匹配在一起时更容易被耳朵/眼睛检测到。

此外,为了反驳 Hans 的评论,音频工程界对此有很多话要说。10 毫秒足以听到延迟,尤其是在与视频反馈配对时。您可能无法看到 10 毫秒的延迟,但您绝对可以听到。来自http://helpx.adobe.com/audition/kb/troubleshoot-recording-playback-monitoring-audition.html

适用于延迟时间的一般准则

少于 10 毫秒 - 允许实时监控传入的轨道,包括效果。

在 10 毫秒 - 可以检测到延迟,但听起来仍然很自然,可用于监控。

11-20 毫秒 - 监听开始变得不可用,实际声源模糊不清,>并且监听输出很明显。

20-30 毫秒 - 延迟的声音开始听起来像是实际的延迟,而不是原始信号的一部分。

我在这里有点咆哮,但有很多事情在起作用。

于 2013-01-22T22:08:51.690 回答