c# - 逐帧录制视频时，如何处理C#.NET TimeSpan Progressive Rounding Error？

Question

这是一个巧妙的问题，而不是“告诉我什么代码有效”，而是“我如何从逻辑上处理这种情况”的问题。

简而言之，我有通过 RTSP 从 IP 摄像机传来的视频和音频。

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

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

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

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

随着时间的推移，微小的小数截断最终会导致视频和音频不同步——录制的时间越长，两个音轨就越不同步。

我真的不明白为什么会这样，因为舍入误差在逻辑上不应该重要。

即使我只有 1 秒的精度，我也只会每秒写入一个视频帧，它在时间轴中的位置将大致在它应该在 +- 1 秒的位置，这应该使每个渐进帧同样的 +- 1 秒到它应该在的地方，而不是逐渐增加更多的错位。我在想象每一帧看起来像这样:

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

我是不是漏掉了什么？

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

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

我的代码是这样的:

time expected ---------- 预计时间 ---------- 预计时间 帧时间帧时间帧时间

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

如果我实现“每 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++;
        }
    }

Answer 1

您应该注意以下几点:

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

2. 精度漂移。在处理以毫秒为单位的帧时间戳时，我遇到了漂移，但我的源时间戳以纳秒为单位。这需要我投一个双倍的长。

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

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

3. Accordion 效应。虽然随着时间的推移，所有事情都可能加起来是正确的，并且您认为即使在 1 秒的粒度上事情也应该匹配，但它们不会。音频需要完美匹配，否则听起来会很奇怪。这通常表现为您在正确的时间听到某人发出正确的音频，但嘴唇没有对齐。随着时间的推移，一切都很好，但没有什么是完全一致的。这是因为您没有在正确的时间渲染帧。有些帧有点太长，有些帧有点太短，所有的一切加起来都是正确的位置，但没有一个是正确的长度。

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

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

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

General guidelines that apply to latency times

Less than 10 ms - allows real-time monitoring of incoming tracks including effects.

At 10 ms - latency can be detected but can still sound natural and is usable for monitoring.

11-20 ms - monitoring starts to become unusable, smearing of the actual sound source, >and the monitored output is apparent.

20-30 ms - delayed sound starts to sound like an actual delay rather than a component of >the original signal.

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