如何逐帧录制视频时如何处理C#.NET TimeSpan逐行舍入错误？

Question

这是一个很好的问题,而不是"告诉我代码是什么工作",而是"如何在逻辑上处理这种情况"问题.

简而言之,我通过RTSP从IP摄像机进入视频+音频.

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

问题是由于TimeSpan结束时间和每个视频帧的开始时间不精确,视频和音频会逐渐变得越来越不同步.

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

我可以调整29.97的视频解码器帧速率值(它从摄像机的设置声明的帧速率中拉出),导致视频在音频之前,或滞后于音频 - 这只是制作每个视频mediaBuffer.StartTime和mediaBuffer .EndTime要么太早,要么太晚,与音频相比.

随着时间的推移,微小的十进制截断最终导致视频和音频不同步 - 录制时间越长,两个轨道获得的同步越多.

我真的不明白为什么会这样,因为舍入误差在逻辑上不重要.

即使我只有1秒的精度,我每秒只会写一个视频帧,它在时间线上的位置大致应该是+ - 1秒,这应该使每个渐进帧相同+ - 1秒到达应有的位置,不会逐渐增加错位.我想象每个框架看起来都像这样:

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

我在这里错过了什么吗？

我没做"新帧开始时间=最后帧结束时间,新帧结束时间=新帧开始时间+ 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++;
        }
    }

Answer 1

您应该注意以下几点：

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

2. 精密漂移。在处理以毫秒为单位的帧时间戳时，我遇到了漂移，但我的源时间戳是以纳秒为单位的。这需要我将双精度型转换为长型。

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

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

3. 手风琴效果。 虽然随着时间的推移，一切都可能会加起来成为正确的事情，并且您认为即使在 1 秒粒度中，事情也应该匹配，但事实并非如此。音频需要完美匹配，否则听起来会很奇怪。这通常的特点是你在正确的时间听到一个人发出正确的声音，但嘴唇没有对齐。随着时间的推移，一切都还好，但一切都不太顺利。这是因为您没有在正确的时间渲染帧。有些框架有点太长，有些框架有点太短，总的来说，所有的东西加起来都在正确的位置，但没有一个是正确的长度。

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

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

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

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

小于 10 毫秒 - 允许实时监控传入曲目（包括效果）。

10 毫秒 - 可以检测到延迟，但听起来仍然很自然，并且可用于监听。

11-20 ms - 监听开始变得不可用，实际声源出现模糊，并且监听的输出很明显。

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

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