• 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来获得。
     

  • 相关阅读:
    【回归预测-NN预测】基于文化算法优化神经网络实现数据回归预测附matlab代码
    Java基础入门·File类的使用
    JAVA MongoDB 连接以及增删改查
    c++ 类的继承(一)
    React Native简介 说明为什么要学习React Native
    项目中的自定义注解
    计算机网络(八) | Tomcat
    记录 Maven 版本覆盖 Bug 的解决过程
    医疗领域的数字化浪潮:互联网医院平台的关键作用
    【ROS】Nav2源码之nav2_behavior_tree详解
  • 原文地址:https://blog.csdn.net/qq_1335857320/article/details/128057665