• 一个RTSP/RTP over TCP 的丢包引起的问题


    背景知识:可以查看https://www.cnblogs.com/lidabo/p/4483497.html

    RTSP/RTP over TCP
    TCP承载RTSP/RTP
     
    When you use RTSP/RTP over TCP, all command and media data will be sent through the RTSP port, normally, port 554. Also, when using
    当使用TCP协议承载RTSP/RTP时,所有的命令和媒体数据都将通过RTSP端口,通常是554,进行发送。同时,数据将经过二元交织格式化之后才能发
    RTSP/RTP over TCP, the data will be sent via binary interleave format.
    送。
     
    Below will describe the essential for using RTSP/RTP over TCP
    接下来我们将描述使用TCP承载RTSP/RTP的主要要素:
     
    SETUP
     
    To use TCP communication, you need to request TCP connection during RTSP SETUP. You have to sent SETUP command with
    要使用TCP连接,RTSP客户端需要在SETUP阶段请求TCP连接。SETUP命令中应该包括如下格式的Transport:
    Transport: RTP/AVP/TCP;interleaved=0-1
    This will tell the server to send media data with TCP and interleave the data in channel 0 and 1. Given in the specification, data channel is even
    上述Transport将告诉服务端使用TCP协议发送媒体数据,并且使用信道 0 和 1 对流数据以及控制信息进行交织。详细说来,使用偶数信道作为数据
    number and control channel is odd (data_ch_num + 1). So, if you data channel is 0, your control channel will be 0 + 1 = 1.
    传输信道,使用奇数信道作为控制信道(数据信道 + 1)。所以,如果你设定数据信道为 0 ,那控制信道应该是 0 + 1 = 1。
     
    Below is an example of TCP SETUP
     
    RTP Data
     
    After the setup, RTP data will be sent through the TCP socket that is used for RTSP commands. The RTP data will be encapsulate in the following format
    SETUP之后,RTP数据将通过用来发送RTSP命令的TCP Socket进行发送。RTP数据将以如下格式进行封装:
    | magic number | channel number | embedded data length | data |
    magic number - 1 byte value of hex 0x24
    RTP数据标识符,"$"
    channel number - 1 byte value to denote the channel
    信道数字 - 1个字节,用来指示信道
    embedded data length - 2 bytes to denote the embedded data length
    数据长度 - 2个字节,用来指示插入数据长度
    data - data packet, ie RTP packet, with the total length of the embedded data length
    数据 - 数据包,比如说RTP包,总长度与上面的数据长度相同
    Below is a full example of the communication exchanged
    下面是交互过程的一个完整示例:
    问题描述:
     当我们的rtp定位符丢失之后,机顶盒应该如何在不重新建联的情况下,保证后面的播放?
    1.定位符$(0x24)这部分丢失,也就是不知道信道,也不知道长度,由于是tcp,无法知道下一个定位符在哪。
    2.如果遍历后面的报文,可能是媒体,也可能是信令,则0x24可能会找错,比如媒体数据里面有0x24.
    3.定位符丢失的原因可能是因为前面的rtp媒体数据丢失,后面连着一个定位符,但是被机顶盒解码为媒体数据,这样相当于后面那个定位符就丢失了。
    4.tcp按道理是不会丢包,但是由于用户态在多次tryagain的时候,到时间就可能需要发送下一个报文了(处于实时性考虑),这样就出现了丢包现象。
     
    解决方法:
    媒体服务器发包的时候,保证原子性,因为tcp会重传,那么唯一丢失rtp定位符是的可能条件是,应用程序在发包的时候,发送到定位符部分,而socket由于buf是满的,
    会导致我们应用程序重试,假设那段时间一直重试失败,则有可能导致发送下一个报文。这就要求在tcp发送的时候,必须一直重试,而在udp的时候,可以重试几次后
    发送下一个报文,因为udp的是有界的。
    水平有限,如果有错误,请帮忙提醒我。如果您觉得本文对您有帮助,可以点击下面的 推荐 支持一下我。版权所有,需要转发请带上本文源地址,博客一直在更新,欢迎 关注 。
  • 相关阅读:
    golang学习笔记 ---面向并发的内存模型
    使用airdrop进行文件共享
    Sense编辑器(Sense Editor)
    Spring Boot + Spring Data + Elasticsearch实例
    ElasticSearch位置搜索
    批量修改mp3文件的title等
    ElasticSearch reindex报错:the final mapping would have more than 1 type
    Mac下安装SecureCRT并激活
    Mac快捷键
    ​Mac触控板常用的手势操作
  • 原文地址:https://www.cnblogs.com/10087622blog/p/10278397.html
Copyright © 2020-2023  润新知