java的rtsp通信、rtp接收数据、本地实现连续播放视频片段（源源不断）（基本实现）

gitee上放着的代码

---------------------------------------------2021/5/30--------------------------------------------

1、进行客户端和服务器端的rtsp协议通信，客户端使用java代码编写，服务器端使用vlc代替（已成功）。其中要注意的是客户端发送SETUP请求是需要把trackID号带上。

---------------------------------------------2021/6/1----------------------------------------------
截至现在，还卡在了解析rtp包上。

1、我已经对分片和未分片的rtp包进行了区分打包处理，分片的去掉rtp头部12字节后，再从后两个字节提取前一个字节的前三位和后一个字节的后五位进行组合，再拼接在数据前，未分片的则只去掉了rtp头部12字节然后拼接。
2、 打包时也加上了先导0 0 0 1四个字节和0 0 1三个字节，但是接收出来的数据输出的文件还是不能播放。
3、udp的接收方法当这次的数据长，下次数据短时，会导致末端数据覆盖，因此每次接收前需要重新new一个字节数组和重新捆绑套接字

---------------------------------------------2021/6/2----------------------------------------------
1、今天用进制编辑器观察发现，.h264文件能够播放时，不是以I帧开头 16进制（00 00 00 01 65）而是在I帧前有00111（16进制的67中的7） 01000（16进制的68中的8），接着再是I帧，这样的.h264文件是可以播放的。
我下的进制编辑器

---------------------------------------------2021/6/3----------------------------------------------
1、 发现昨天的理解有误，开头并不一定必须是67 68，这两个也有可能是其他的，反正有就行了（发现一般是x7 x8这种16进制数也就是00 00 00 01 x7 xx xx 00 00 00 01 x8 xx xx），之后接着是视频数据，这里需要判断是否分片。
2、今天，开始编写新代码。
3、晚上的时候已经能够播放视频了，但是每一段都还很短，下一步准备将视频文件变长一点保存。（我在这里面使用了ArrayList和HashMap来存放数组，我感觉这样不用重复扩容数组，加快速度一点）。

----------------------------------------------2020/6/4------------------------------------------

1、今天发现接收的视频数据，和它本身的数据不一致，例如：文件中应该为0是，我读出来的数据不是0(没有分片，是荷载数据)，不知道为什么，数据会有变化，下周继续弄。

----------------------------------------------2020/6/7------------------------------------------
1、今天发现接收的数据仍然是有问题的，因此准备直接用网络调试助手，直接获取源字节数组，看一下是不是服务端发送的数据有问题.
2、发现之前代码中存在着问题的几个地方，例如：每次输出一个文件后，List重置条件写错了以及没有清零输出后的Map。

----------------------------------------------2020/6/8------------------------------------------
1、 用网络调试助手获取到的数据就是不正确的，需修改服务端发送代码。
2、 今天对照了解析出来的数据和原始数据发现了之前的两个误区。 第一个：分片时并不是每一片都要加上00 00 00 01四个字节，只有第一片才会加。第二个：也是分片时，除了第一片，其余片都要直接把nal的头（每次的前两个字节）去掉。
3、还发现了一个问题，就是在我写入map的时候，由于每次的字节数组地址都是一致的，导致加的时候会有重复添加，（虽然每次数组的值改变了，但是地址没变，添加到map中时，由于是同一地址，会把上一次的值也重复添加进去，因此每次需要把字节数组重新new一次 例如：new ArrayList<>(rtpBody) rtpBody为此次存储的数组），此外我还把map改成了List，用了两次List 一个List存放数组，一个List存放List，每次自动添加到末尾，省去了Map的put中的key。
自此，视频已经能够成功解析和播放了！！！！！，但是其中仍有一些问题，例如：发送的数据中有错误的或者丢失了一段，程序还不能处理这样的异常，后面再改。

----------------------------------------------2020/6/9------------------------------------------
现在还需实现视频的播放，我们现在是一段视频一段视频保存在本地，因此，需要将这些一段一段的视频合起来形成连续播放。
1、通过ffmpeg可以实现视频合并，此外通过ffplay可以实现播放，因为他们是全家桶我就一起使用了,其中需要完成的还有调取文件连续播放，今天尝试完成。
----------------------------------------------2020/6/10------------------------------------------
1、实现了顺序播放接收到的视频。当服务器关闭重启后，接收到视频文件时会从当前接收到的视频文件开始播放而不会从之前的开始播放。（注意：我播放完之后会把当前文件剪切去另一个文件夹。在执行这个方式时要确保，前面调用这个文件夹的流已经关闭，否则会出错。）
2、播放不是无缝的，还找寻找解决方案，来实现播放无缝的效果.（现在还未找到）
3、想到一个将本地存储的文件推流，然后使用ffplay播放的方法来连续播放，不知道可不可以。
----------------------------------------------2020/6/11------------------------------------------
1、在昨天的基础上基本实现了一直播放，用的是ffmpeg的推流，最开始我采用的是rtp的方式推流，但是这种方式经常会卡在那里，ffplay接收不到后面的包（我想的是ffplay一直在接收这个流，另外一方就一直源源不断的往里面推流）。最后想到用udp的形式推流，然后发现它能够达到这种效果就采用了它。
2、但是使用推流以UDP的方式有一个问题，就是一个视频在推流的时候，另一个视频来了，也开始推流，这时候就会导致画面开始异常，我想到可能是接收数据的问题，就进行了一个排队，先把要推流的视频加进来，推完一个再推下面的一个，改正后果然效果很好，在本地用VLC模拟rtp发包给我时，基本能够达到不卡顿播放。
3、当我和远程设备联系时，会有很大的延时，原因是我推流的速度没有生成文件的速度快，导致挤压，因此需要找到一个合理的值来设定。
至此，基本已经实现了所有我需要完成的功能！！！

----------------------------------------------2020/6/23------------------------------------------
1、发现了导致延迟的原因，就是我在推流后进行了文件删除工作，浪费了一定的时间，我把文件删除换成线程批量删除文件后，延迟和视频间的卡顿降低了许多。
2、利用两个链表来存放视频文件信息，一个边存边推流，当达到我们设定的值时，就转换为另一个存，把之前存的文件都删除，这样依次循环。