播放器的音视频不同步问题：ffplay

自动丢帧的问题：
其实我都不知道目前播放的状态！哪里有问题？说是延迟？那不是播放的挺好的嘛。音视频不是已经同步了吗？
 
一定要实时，断断续续也比延迟要好的思考。   这是对的，
之前是要求能显示就行。能显示，不卡顿很流畅。但是一旦到电视信号就开始延迟，不是实时的。后来为了不能延迟，降低分辨率到720P，数据量下降了，延迟也小了。
####应该是数据处理不过来，数据都在缓存中，所以导致延时。 当时就是为了实时性，可以丢掉一些视频质量。（最终目的是实时的基础上，提供流畅清晰的画面）
后来继续用高分辨率测试，我试的结果是仍然卡顿。丁工用它的命令接收，竟然可以实时了！！分辨率也没问题。
后来加上声音，然后音视频不同步，然后尝试修改ffplay.c的源码。

现在的情况应该是音视频大部分同步，少部分情况仍然会不同步。而且偶尔会卡顿。猜测：有可能还是视频处理不过来的问题，怎么解决呢？
已经没有缓冲了，所以他才会卡顿，因为他需要在内存中编解码边渲染播放，没有缓存了，那么可能会出现什么情况呢？  
1.解码太慢，播放速度快，看着卡顿不流畅。（网络延迟、数据传输速度、解码效率，会影响传输到端口数据的稳定性。导致解码器速度跟不上播放速度，导致视频卡顿、画面不连续，甚至丢帧现象，这样就会影响到观看的流畅性和观感）
2.解码，播放速度不一致时，导致音视频不同步。
3.丢帧或音频漏帧： 在解码速度跟不上播放速度的情况下，为了保持音视频同步，播放器可能会丢弃部分视频帧或者音频样本，从而导致画面不连贯或者音频断续。
4.实时性高，但是稳定性差

可以尝试的方法：
如何指定解码的缓冲区
-framedrop    //丢帧保证音视频同步
-sync        //调整同步策略
-probesize 和 -analyzeduration：这两个选项可以用来设置 FFmpeg 在打开媒体文件时探测媒体文件的大小和持续时间。通过设置适当的值，可以加速文件打开的速度，并且对于实时流媒体，可以减少启动延迟。
解码器缓冲区：#################
https://zhuanlan.zhihu.com/p/51582357

ffplay -itsoffset命令
-itsoffset 是 FFmpeg 中的一个选项，用于设置输入文件的时间偏移量。这个选项通常与 -i 一起使用，后面跟着一个时间值，表示对输入文件应用的时间偏移量。
例如，-itsoffset 5 表示在播放输入文件时，将时间向后偏移5秒。而-itsoffset -5 则表示向前偏移5秒。这在处理需要对输入文件进行时间调整的情况下很有用，比如音视频同步问题的调试或者需要从视频中的特定时间点开始播放等。
因此，ffplay -itsoffset 命令的使用场景是在播放视频时，对输入文件应用时间偏移量。

以下是一个使用 ffplay 和 -itsoffset 选项的示例：
假设你有一个名为 example.mp4 的视频文件，并且你想从视频的第5秒开始播放，你可以使用以下命令：
ffplay -itsoffset 5 -i example.mp4
这个命令的意思是，播放 example.mp4 这个视频文件，但从文件的第5秒开始播放，即向后偏移5秒。
udp流不可以从某个位置进行播放。

这是ffmpeg控制解码器的延迟时间：xx
-max_delay 500
-max_delay 1000
如果不设置最大延迟时间，可能会导致画面卡顿，因为编码器也在等数据来以便进行解码，假如网络信号不好，后面的帧等了很久才到，那你可有的等了。
但是如果设置了最大延迟时间，其实也就是最多等你那么长时间，你不来我编码器照样要开始进行解码了。

记录：测试的结果
指定解码的缓冲区,不可行。
framedrop    video    //音视频同步，偶尔花屏
video            //音视频同步，花屏，偶尔杂音
framedrop    audio    //音视频同步，偶尔花屏
audio             //音视频同步，花屏。
framedrop    ext    //音视频同步，比ext强点    
ext            //音视频同步，卡的厉害，频繁

再次进入时音频提前。可能是新到来的数据不同步，只能先播放音频。那也就是说不是缓存的问题。也有可能是因为不同步而进行丢帧吧。
总之，加上framdrop好了一些。

---

基础知识：
-autoexit
func: Exit when video is done playing.
example: ffplay -i 1.mp4 -t 5 -autoexit
此命令控制视频播放5s后，播放窗体自动关闭。注意，ffplay播放结束后，默认是停留在最后一帧画面的。

###########
强制使用某解码器！！！，可用硬件解码。
example: ffplay -i 1.mp4 -codec:v h264
强制使用h264解码器实现来实现1.mp4视频流解码。
其次，使用ffprobe -codecs -hide_banner| find "h264"，我们可以找到当前ffmpeg支持的h264解码器实现为h264，h264_qsv，h64_cuvid。
最后，我们使用ffplay -i 1.mp4 -codec:v h264或者ffplay -i 1.mp4 -codec:v h264_qsv或者ffplay -i 1.mp4 -codec:v h264_cuvid来尝试解码，发现使用解码器h264和h264_qsv是可以解码的，但是h264_cuvid不能解码。
h264: cpu软解码.
h264_qsv：英特尔Quick Sync Video(QSV)，这是intel的GPU解码技术
h264_cuvid：这是nvidia显卡的硬件解码技术

 -acodec decoder_name
-vcodec decoder_name
---------------------------------------------------

可能是解码，也可能是渲染。网络传输应该不至于，发送端应该也没什么问题。
ffplay udp://127.0.0.1:1234执行时，根据接收到的数据流中的标志或元数据来确定使用哪种解码器。如果你的UDP流包含H.264编码的视频数据，ffplay将会自动选择H.264解码器来解码视频流。

解码的过程是ffplay的内部操作，内部操作的具体流程是什么，是怎么实现的？
解码的过程是ffplay的核心功能之一，它通过调用 FFmpeg 库来实现。FFmpeg 是一个功能强大的多媒体处理工具，其中包含了音视频编解码器、格式转换器等多种功能。ffplay实际上是 FFmpeg 库中提供的一个用于播放音视频的简单命令行工具。
以下是ffplay解码过程的简要流程：
打开输入源：ffplay首先会根据用户提供的输入源（文件路径、网络地址等）打开音视频数据流。
**解封装（Demuxing）：**如果输入源是容器格式（例如.mp4、.avi等），ffplay会使用 FFmpeg 库中的**解封装器模块**来解析容器并提取其中的音视频数据流。
**选择解码器：**根据音视频流中的编码格式，ffplay会自动选择合适的解码器。例如，如果视频流使用 H.264 编码，ffplay将选择 H.264 解码器进行解码。
**解码：**选择解码器后，ffplay会调用相应的解码器模块来将压缩的音视频数据解码为原始的音频采样数据和视频像素数据。
**播放：**解码完成后，ffplay会将解码后的音频采样数据传递给音频输出设备进行播放，同时将解码后的视频像素数据显示在屏幕上。
循环处理：ffplay会持续循环执行上述步骤，以确保持续的音视频播放。
整个过程是在后台由 FFmpeg 库完成的，ffplay作为一个简单的命令行工具，隐藏了这些细节，使用户可以方便地播放音视频文件或数据流。

ffplay进行播放流视频时，对于解码后的数据会直接进行渲染，还是说会存到缓冲区中平缓的渲染?
默认情况下，ffplay在解码后会将数据存储到缓冲区中，然后再以平滑的方式渲染。这样做的目的是为了防止播放过程中出现画面卡顿或者音视频不同步的问题，尤其是当网络状况不稳定时。通过在缓冲区中积累一定量的数据，ffplay可以更好地处理丢包、网络抖动等问题，从而提高播放的稳定性和流畅度。
然而，你提到的-fflags nobuffer和-flags low_delay参数可以改变这种行为。-fflags nobuffer会禁用缓冲区，使得解码后的数据直接进行渲染，而-flags low_delay则会尽量减少解码过程中的延迟，这也可能会导致更快的渲染速度。
因此，如果使用了-fflags nobuffer参数，ffplay会直接渲染解码后的数据，而不经过缓冲区的存储。而如果没有使用这个参数，默认情况下ffplay会将数据存储到缓冲区中，然后再进行渲染。

接上例，当ffplay没有使用缓冲区，那么是不是程序在内存中一边解码一边播放，这可能会导致什么问题？
当ffplay没有使用缓冲区时，解码后的数据将直接传递给渲染器进行播放，而不会在内存中积累一定量的数据。这种情况下可能会导致以下问题：
播放不稳定性： 如果解码速度跟不上播放速度，可能会导致视频卡顿或者播放不流畅。特别是在网络环境不稳定或者视频解码复杂的情况下，解码速度可能无法满足播放需求。
音视频不同步： 如果视频解码速度快于音频解码速度，或者反之，可能会导致音视频不同步的问题。这可能会使观看体验变差。
丢帧或音频漏帧： 在解码速度跟不上播放速度的情况下，为了保持音视频同步，播放器可能会丢弃部分视频帧或者音频样本，从而导致画面不连贯或者音频断续。
实时性差： 在需要低延迟的场景下，由于解码和渲染过程都是即时进行的，可能无法达到最低延迟的要求。
总之，尽管禁用缓冲区可以减少延迟，但也会增加播放的不稳定性和可靠性。因此，在选择是否禁用缓冲区时，需要权衡延迟和稳定性之间的取舍，并根据实际需求做出相应的调整。