• live555


    live555核心结构体

    1.Souce,Sink

    Souce:翻译为源,源头。表示数据的提供者。

            数据提供者:

                            1.通过RTP读取数据

                            2.通过文件读取数据

                            3.内存读取数据 

    Sink: 翻译为水槽。表示数据的流向,消费者。比如写文件,显示到屏幕等

    Filter: 翻译为过滤器。在数据流从Souce流到Sink的过程中可以设置Filter,用于过滤或做进一步加工。

    数据流向问题:对源和目的的理解

    在整个LiveMedia中,数据都是从Souce,经过一个或多个Filter,最终流向Sink。在服务器中数据流是从文件或设备流向网络,而在客户端数据流是从网络流向文件或屏幕。

     MediaSouce是所有Souce的基类,MediaSink是所有Sink的基类。

        从类数量和代码规模可以看到,LiveMedia类是整个LIVE555的核心,其内部包含数十个操作具体编码和封装格式的类。LiveMedia定义的各种Souce均是从文件读取,如果想实现从设备获得实时流的传输,可以定义自己的Souce。
    2. ClientSession

    3.第三类结构体 MediaSession, MediaSubsesion, Track

    MediaSession 媒体文件

            LIVE555使用MediaSession管理一个包含音视频的媒体文件,每个MediaSession使用文件名唯一标识。

            使用SubSession管理MediaSession中的一个音频流或视频流。为行文方便我们称音频或视频均为一个媒体文件中的媒体流。因此一个MediaSession可以有多个MediaSubsession,一个管理音频流一个管理视频流。

    在上一篇介绍RTSP协议时,客户端在给服务器发送DESCRIBE查询某个文件的SDP信息时,服务器会给客户端返回该媒体文件所包含的多个媒体流信息。并为每个媒体流分配一个TrackID。如视频流分配为Track1,音频流分配为Track2。此后客户端必须在URL指定要为那个Track发送SETUP命令。

        因此我们可以认为MediaSubsession代表Server端媒体文件的一个Track,也即对应一个媒体流。MediaSession代表Server端一个媒体文件。对于既包含音频又包含视频的媒体文件,MediaSession内包含两个MediaSubsession。

        但MediaSession和MediaSubsession仅代表静态信息,若多个客户端请求同一个文件,服务器仅会创建一个MediaSession。各个客户端公用。为了区分各个MediaSession的状态又定义了StreamState类,用来管理每个媒体流的状态。在MediaSubsession中完成了Souce和Sink连接。Souce对指针象会被设置进sink。在Sink需要数据时,可以通过调用Souce的GetNextFrame来获得。
     

  • 相关阅读:
    LyScript 实现绕过反调试保护
    接上一篇:分布式调用链追踪系统设计
    在枚举类中“优雅地”使用枚举处理器
    能碳双控| AIRIOT智慧能碳管理解决方案
    Plonky3 Mersenne素数域的Reed-Solomon codes设计
    ML 线性回归原理推导以及灵魂拷问 (面试必考知识点)
    k8s UAT改环境
    智能合约安全,著名的区块链漏洞:双花攻击
    【Java基础】java.lang包中不能被继承的类
    【C++】函数重载
  • 原文地址:https://blog.csdn.net/qq_1335857320/article/details/128057665