CN107026861A - 一种推流方法及装置 - Google Patents

Abstract

本发明提供一种推流方法及装置，只有在接收到服务器发送的开始请求后，才向输入源发送推流请求，接收输入源响应所述推流请求后推流的数据，并将所述数据推流到所述服务器。而在没接收到服务器发送的开始请求时，即没有用户需要从服务器获取数据时，不会通过输入源获取数据，并且不会将数据推流到服务器中，进而避免了占用网络带宽，造成网络资源浪费的问题产生。

Description

一种推流方法及装置

技术领域

本发明属于流媒体推流和收流领域，尤其涉及一种推流方法及装置。

背景技术

目前，流媒体广泛的应用在数字电视技术和网络技术中。以网络直播为例，直播用户开启直播后，直接将直播数据推流到与直播地址对应的服务器上，使得观看直播的用户想要观看此直播时，只需要找到此直播，点击播放，即可立即从服务器获取直播内容并观看直播，其中，直播内容一边播放一边下载，而不需要将直播内容全部从服务器下载完成后，才能点击播放以观看直播。极大地提高了用户的体验。

但是，现有技术中只要直播用户开启直播后，即使没有用户观看直播，也将直播数据推流到服务器中，占用了网络带宽，造成网络资源的浪费。

发明内容

有鉴于此，本发明的目的在于提供一种推流方法及装置，用于节省网络带宽，避免造成网络资源浪费的问题产生。

技术方案如下：

本发明提供一种推流方法，包括：

接收到服务器发送的开始请求后，向输入源发送推流请求；

接收所述输入源响应所述推流请求后推流的数据；

将所述数据推流到所述服务器。

优选地，所述接收所述输入源响应所述推流请求后推流的数据，包括：

接收到所述输入源发送的收流通知后，接收所述输入源推流的数据；其中，所述收流通知在所述输入源接收到所述推流请求并获取数据后发送。

优选地，所述将所述数据推流到所述服务器之后，还包括：

接收所述服务器发送的停止请求；

向所述输入源发送停止推流请求；

停止收流。

优选地，所述向所述输入源发送停止推流请求之后，还包括：

接收所述输入源响应所述停止推流请求后返回的状态信息；

判断所述状态信息是否为成功响应所述停止推流请求；

若所述状态信息为没有成功响应所述停止推流请求，则返回执行向所述输入源发送停止推流请求。

优选地，所述接收到所述服务器发送的开始请求后之前，还包括：

根据推流地址，判断是否等待所述服务器发送的开始请求；

若等待所述服务器发送的开始请求，则接收到所述服务器发送的开始请求后，向所述输入源发送推流请求。

本发明还提供一种推流装置，包括：

第一发送单元，用于接收到服务器发送的开始请求后，向输入源发送推流请求；

第一接收单元，用于接收所述输入源响应所述推流请求后推流的数据；

推流单元，用于将所述数据推流到所述服务器。

优选地，所述第一接收单元包括：

数据接收单元，用于接收到所述输入源发送的收流通知后，接收所述输入源推流的数据；其中，所述收流通知在所述输入源接收到所述推流请求并获取数据后发送。

优选地，所述推流装置还包括：

第二接收单元，用于接收所述服务器发送的停止请求；

第二发送单元，用于向所述输入源发送停止推流请求；

停止收流单元，用于停止收流。

优选地，所述推流装置还包括：

第三接收单元，用于接收所述输入源响应所述停止推流请求后返回的状态信息；

第一判断单元，用于判断所述状态信息是否为成功响应所述停止推流请求；

若所述状态信息为没有成功响应所述停止推流请求，则调用所述第二发送单元。

优选地，所述推流装置还包括：

第二判断单元，用于根据推流地址，判断是否等待所述服务器发送的开始请求；

若等待所述服务器发送的开始请求，则调用所述第一发送单元。

与现有技术相比，本发明提供的上述技术方案具有如下优点：

从上述技术方案可知，本申请提供一种推流方法及装置，只有在接收到服务器发送的开始请求后，才向输入源发送推流请求，接收输入源响应所述推流请求后推流的数据，并将所述数据推流到所述服务器。而在没接收到服务器发送的开始请求时，即没有用户需要从服务器获取数据时，不会通过输入源获取数据，并且不会将数据推流到服务器中，进而避免了占用网络带宽，造成网络资源浪费的问题产生。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种推流方法的流程图；

图2是本发明实施例提供的另一种推流方法的流程图；

图3是本发明实施例提供的一种推流装置的结构示意图；

图4是本发明实施例提供的另一种推流装置的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明公开了一种推流方法，所述推流方法可以应用在流媒体设备中，参见图1，该实施例包括以下步骤：

S101、接收到服务器发送的开始请求后，向输入源发送推流请求；

以网络直播为例进行说明，为了实现直播，需要在输入源内设置直播输出地址，所述直播输出地址用于将输入源获取到的直播数据通过推流端推流到服务器中，且需要在服务器内设置与直播对应的直播频道和输入地址。其中，直播频道生成后，建立一个直播地址，此直播地址具体可以是一个网址。

通过在输入源内设置的输出地址和在服务器内设置的输入地址，实现了将输入源获取到的直播数据传输到服务器的目的。其中，输入地址和输出地址可以是相同的地址，也可以是不同的地址但具有唯一对应关系。

在实际应用中，由于观看直播的用户不同，因此输入源获取到的直播数据需要能够支持多个不同用户的获取，即需要将一个数据能够发送至多个不同的目的地址。基于此，本实施例中可以基于UDP协议的组播通信方式。

UDP组播中，组播报文的目的地址使用D类IP地址，D类IP地址不能出现在IP报文的源IP地址字段。单播数据传输过程中，一个数据包传输的路径是从源地址路由到目的地址，利用“逐跳”的原理在IP网络中传输。

然而在IP组播环中，数据包的目的地址不是一个，而是一组，形成组地址。所有的信息接收者都加入到一个组内，并且一旦加入之后，流向组地址的数据立即开始向接收者传输，组中的所有成员都能接收到数据包。组播组中的成员是动态的，成员主机可以在任何时刻加入和离开组播组。

用同一个IP多播地址接收多播数据包的所有主机构成了一个主机组，也称为多播组。一个多播组的成员是随时变动的，一台主机可以随时加入或离开多播组，多播组成员的数目和所在的地理位置也不受限制，一台主机也可以属于几个多播组。此外，不属于某一个多播组的主机也可以向该多播组发送数据包。

基于UDP协议的组播通信方式，可以实现将直播用户生成的数据包，发送至多个不同的想要观看直播的用户。且观看直播的用户可以随时加入或者离开。

在输入源内设置的直播输出地址和在服务器内设置的输入地址，都可以是UDP地址。

可以理解的是，本实施中还可以基于其他的协议，当协议不同的时，输入地址和输出地址根据协议进行对应的修改。

观看直播的用户，在自身的客户端通过浏览器可以选择需要观看的直播频道，此直播频道与服务器内设置的直播频道是相同的。当用户点击想要观看的直播频道后，向服务器发送开始请求。其中，开始请求中携带直播频道标识。

服务器接收到开始请求后，解析此开始请求，获取与此开始请求对应的直播频道标识，并查找到与此直播频道对应的输入地址。通过此输入地址，服务器将开始请求发送至与输入地址对应的推流端，推流端接收到服务器发送的开始请求后，向与输入地址对应的输出地址所在的输入源发送推流请求。

S102、接收所述输入源响应所述推流请求后推流的数据；

输入源在接收到推流端发送的推流请求后，获取直播数据。

获取到直播数据后，通过输出地址输出直播数据；

推流端接收从所述输出地址输出的直播数据。

可选地，在一个实施方式中，本步骤包括：

接收到所述输入源发送的收流通知后，接收所述输入源推流的数据；其中，所述收流通知在所述输入源接收到所述推流请求并获取数据后发送。

收流通知是输入源在接收到推流请求并已经获取到直播数据后，发送给推流端，用于告知推流端从输入源收流。

S103、将所述数据推流到所述服务器。

其中，推流端在接收到输入源推流的数据后，将数据推流到服务器中。

推流端将接收到的数据，推流到与直播频道对应的服务器中。以使得观看直播的用户，点击直播频道后可以从与直播频道对应的服务器中获取相应的数据。

从上述技术方案可知，本实施例公开的推流方法，并不需要对现有的流媒体设备进行任何硬件上的改进，而仅仅是在现有的流媒体设备的基础上进行软件上的改进，即可实现只有在接收到服务器发送的开始请求后，才向输入源发送推流请求，接收输入源响应所述推流请求后推流的数据，并将所述数据推流到所述服务器。而在没接收到服务器发送的开始请求时，即没有用户需要从服务器获取数据时，不会通过输入源获取数据，并且不会将数据推流到服务器中，进而避免了占用网络带宽，造成网络资源浪费的问题产生。

本发明公开了另一种推流方法，参见图2，该实施例包括以下步骤：

S201、根据推流地址，判断是否等待服务器发送的开始请求；

若等待服务器发送的开始请求，则执行S202；

若不等待服务器发送的开始请求，则当直播用户开始直播后，推流端直接将从输入源获取到的直播数据，推流到服务器。

以网络直播为例进行说明，在服务器内设置直播频道和与直播频道对应的输入地址，输入地址即推流地址。

针对不同的直播频道，可以分别设置不同的播放属性，例如可以设置为支持点播属性和不支持点播属性。若设置为支持点播属性，需要满足用户在点播时能够播放完整内容，因此服务器内应该存储有完整的点播内容，进而当直播用户开始直播后，就需要将输入源获取到的直播数据，通过推流端推流到服务器。

具体的，根据推流地址，判断与此推流地址对应的直播频道设置的播放属性，进而实现判断是否等待服务器发送的开始请求。

若播放属性为支持点播，则不等待服务器发送的开始请求；在直播用户启动直播后，则直接将直播数据推流到与直播地址对应的服务器上，确保存储直播的完整内容，进而用户随时点播此内容时，都可以观看完整的内容。若播放属性为不支持点播，则等待服务器发送的开始请求。

S202、接收到服务器发送的开始请求后，向输入源发送推流请求；

S203、接收所述输入源响应所述推流请求后推流的数据；

S204、将所述数据推流到所述服务器；

本实施例中步骤S202-S204的具体实现与图1所述的实施例中步骤S101-S103相似，此处不在赘述。

S205、接收所述服务器发送的停止请求；

推流端接收服务器发送的请求可以包括开始请求和停止请求。并且，请求是在用户在客户端通过浏览器进行相应的操作后产生的。

推流端在接收到不同的请求后，执行不同的动作。本实施例中并不限定接收服务器发送的请求的顺序，也就是说，本实施例中步骤S205并不一定是在执行完接收服务器发送的开始请求之后执行，即不一定是在步骤S204后再执行步骤S205。

S206、向所述输入源发送停止推流请求；

当观看直播的用户需要离开客户端，点击暂停播放直播的按钮后，或关闭显示直播的界面后，向服务器发送停止请求。

停止请求中可以携带直播频道标识，当服务器接收到停止请求后，解析此停止请求，获取与此停止请求对应的直播频道标识，并查找到与此直播频道对应的输入地址。

通过此输入地址，将停止请求发送至与输入地址对应的推流端，推流端接收到服务器发送的停止请求后，向与输入地址对应的输出地址所在的输入源发送停止推流请求。

S207、接收所述输入源响应所述停止推流请求后返回的状态信息；

输入源接收到推流端发送的停止推流请求后，停止向输出地址输出数据。为了避免输入源不能正常响应推流端发送的停止推流请求，导致输入源接收到停止推流请求后，仍然向输出地址输出数据，造成资源浪费。输入源在响应停止推流请求后，向推流端返回状态信息。

S208、判断所述状态信息是否为成功响应所述停止推流请求；

若所述状态信息为没有成功响应所述停止推流请求，则返回执行S206；

若所述状态信息为成功响应所述停止推流请求，则执行S209；

状态信息用于标识输入源是否成功响应停止推流请求，执行了停止推流这一动作，则返回的状态信息是成功响应所述停止推流请求，没有执行停止推流这一动作，则返回的状态信息是没有成功响应所述停止推流请求。

当状态信息为没有成功响应所述停止推流请求，即没有停止推流，则再次返回执行向输入源发送停止推流请求步骤及其后续步骤。

在具体实施时，针对服务器发送的同一个停止请求，推流端重复向输入源发送一定次数的停止推流请求后，判断所述状态信息仍然是不成功，则不再向输入源发送停止推流请求，直接停止收流。避免出现推流端一直向输入源发送停止推流请求的情况发生。

S209、停止收流。

本实施例中推流端在接收到输入源返回的状态信息为成功响应所述停止推流请求后，才停止收流。但是，在实际应用中，可以在接收到服务器发送的停止请求后，就停止收流。然后再执行向输入源发送停止推流请求及其后续步骤。

本实施例中并不限定执行向输入源发送停止推流请求和执行停止收流的先后顺序。

从上述技术方案可知，本实施例公开的推流方法中，建立推流地址后，根据所述推流地址，判断是否等待服务器发送的开始请求，若等待服务器发送的开始请求，则在接收到服务器发送的开始请求后，才向输入源发送推流请求，接收输入源响应所述推流请求后推流的数据，并将所述数据推流到所述服务器。而在没接收到服务器发送的开始请求时，即没有用户需要从服务器获取数据时，不会通过输入源获取数据，并且不会将数据推流到服务器中，实现了按需推流的目的，进而避免了占用网络带宽，造成网络资源浪费的问题产生。若不等待服务器发送的开始请求，则直接将直播数据推流到与直播地址对应的服务器上。本实施例中在可以实现按需推流的基础上，还可以实现根据用户需求选择是否按需推流的目的，满足了用户的需求。

对应上述推流方法，本发明还提供了一种推流装置，所述推流装置应用在所述推流端，所述推流装置的结构示意图请参阅图3所示，本实施例中推流装置包括：

第一发送单元301、第一接收单元302和推流单元303；

第一发送单元301，用于接收到服务器发送的开始请求后，向输入源发送推流请求；

可选地，第一发送单元301包括数据接收单元，用于接收到输入源发送的收流通知后，接收所述输入源推流的数据，其中，所述收流通知在所述输入源接收到所述推流请求并获取数据后发送。

第一接收单元302，用于接收输入源响应所述推流请求后推流的数据；

推流单元303，用于将所述数据推流到所述服务器。

从上述技术方案可知，本实施例中公开的推流装置，第一发送单元只有在接收到服务器发送的开始请求后，才向输入源发送推流请求，第一接收单元接收输入源响应所述推流请求后推流的数据，推流单元将所述数据推流到所述服务器。而在没接收到服务器发送的开始请求时，即没有用户需要从服务器获取数据时，不会通过输入源获取数据，并且不会将数据推流到服务器中，进而避免了占用网络带宽，造成网络资源浪费的问题产生。

本发明实施例还提供了另一种推流装置，其结构示意图请参阅图4所示，本实施例中推流装置包括：

第一发送单元401、第一接收单元402、推流单元403、第二接收单元404、第二发送单元405、停止收流单元406、第三接收单元407、第一判断单元408和第二判断单元409；

其中，第一发送单元401、第一接收单元402和推流单元403与图3所示的推流装置中的第一发送单元301、第一接收单元302和推流单元303结构相同，此处不再赘述。

本实施例中的推流装置，相较于图3所示的推流装置，区别在于本实施例中推流装置还包括：

第二接收单元404、第二发送单元405、停止收流单元406、第三接收单元407、第一判断单元408和第二判断单元409；

第二接收单元404，用于接收服务器发送的停止请求；

第二发送单元405，用于向输入源发送停止推流请求；

当观看直播的用户需要离开客户端，点击暂停播放直播的按钮后，或关闭显示直播的界面后，都会向服务器发送停止请求。

停止请求中可以携带直播频道标识，当服务器接收到停止请求后，解析此停止请求，获取与此停止请求对应的直播频道标识，并查找到与此直播频道对应的输入地址。

通过此输入地址，将停止请求发送至与输入地址对应的推流端，推流端接收到服务器发送的停止请求后，向与输入地址对应的输出地址所在的输入源发送停止推流请求。

停止收流单元406，用于停止收流。

第三接收单元407，用于接收所述输入源响应所述停止推流请求后返回的状态信息；

第一判断单元408，用于判断所述状态信息是否为成功；

若所述状态信息为不成功，则调用第二发送单元405。

通过判断所述状态信息是否为成功，可以避免输入源在接收到停止推流请求后，不能正常停止推流的问题产生。

第二判断单元409，用于根据推流地址，判断是否等待服务器发送的开始请求；

针对不同的直播频道，可以分别设置不同的播放属性，例如可以设置为支持点播属性和不支持点播属性。

设置为支持点播属性后，需要满足用户在点播时能够播放完整内容，因此服务器内应该存储有完整的点播内容。进而当直播用户开始直播后，就需要将输入源获取到的直播数据，通过推流端推流到服务器。

建立推流地址后，第二判断单元409根据推流地址，判断与此推流地址对应的直播频道设置的播放属性，进而实现判断是否等待服务器发送的开始请求。

若播放属性为支持点播，则不等待服务器发送的开始请求；

在直播用户启动直播后，则直接将直播数据推流到与直播地址对应的服务器上，确保存储直播的完整内容。进而用户随时点播此内容时，都可以观看完整的内容。若播放属性为不支持点播，则等待服务器发送的开始请求。

若等待服务器发送的开始请求，则调用第一发送单元401。

若等待服务器发送的开始请求，则调用第一发送单元401，以实现只有当用户需要时才推流。

从上述技术方案可知，本实施例中公开的推流装置，第二判断单元根据推流地址，判断是否等待服务器发送的开始请求，若等待服务器发送的开始请求，则第一发送单元在接收到服务器发送的开始请求后，才向输入源发送推流请求，第一接收单元接收输入源响应所述推流请求后推流的数据，推流单元将所述数据推流到所述服务器。而在没接收到服务器发送的开始请求时，即没有用户需要从服务器获取数据时，不会通过输入源获取数据，并且不会将数据推流到服务器中，实现了按需推流的目的，进而避免了占用网络带宽，造成网络资源浪费的问题产生。若不等待服务器发送的开始请求，则直接将直播数据推流到与直播地址对应的服务器上。本实施例中在可以实现按需推流的基础上，还可以实现根据用户需求选择是否按需推流的目的，满足了用户的需求。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例提供的装置而言，由于其与实施例提供的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种推流方法，其特征在于，包括：

接收到服务器发送的开始请求后，向输入源发送推流请求；

接收所述输入源响应所述推流请求后推流的数据；

将所述数据推流到所述服务器。

2.根据权利要求1所述的推流方法，其特征在于，所述接收所述输入源响应所述推流请求后推流的数据，包括：

接收到所述输入源发送的收流通知后，接收所述输入源推流的数据；其中，所述收流通知在所述输入源接收到所述推流请求并获取数据后发送。

3.根据权利要求1或2所述的推流方法，其特征在于，所述将所述数据推流到所述服务器之后，还包括：

接收所述服务器发送的停止请求；

向所述输入源发送停止推流请求；

停止收流。

4.根据权利要求3所述的推流方法，其特征在于，所述向所述输入源发送停止推流请求之后，还包括：

接收所述输入源响应所述停止推流请求后返回的状态信息；

判断所述状态信息是否为成功响应所述停止推流请求；

若所述状态信息为没有成功响应所述停止推流请求，则返回执行向所述输入源发送停止推流请求。

5.根据权利要求1、2、4中任一项所述的推流方法，其特征在于，所述接收到所述服务器发送的开始请求后之前，还包括：

根据推流地址，判断是否等待所述服务器发送的开始请求；

若等待所述服务器发送的开始请求，则接收到所述服务器发送的开始请求后，向所述输入源发送推流请求。

6.一种推流装置，其特征在于，包括：

第一发送单元，用于接收到服务器发送的开始请求后，向输入源发送推流请求；

第一接收单元，用于接收所述输入源响应所述推流请求后推流的数据；

推流单元，用于将所述数据推流到所述服务器。

7.根据权利要求6所述的推流装置，其特征在于，所述第一接收单元包括：

数据接收单元，用于接收到所述输入源发送的收流通知后，接收所述输入源推流的数据；其中，所述收流通知在所述输入源接收到所述推流请求并获取数据后发送。

8.根据权利要求6或7所述的推流装置，其特征在于，所述推流装置还包括：

第二接收单元，用于接收所述服务器发送的停止请求；

第二发送单元，用于向所述输入源发送停止推流请求；

停止收流单元，用于停止收流。

9.根据权利要求8所述的推流装置，其特征在于，所述推流装置还包括：

第三接收单元，用于接收所述输入源响应所述停止推流请求后返回的状态信息；

第一判断单元，用于判断所述状态信息是否为成功响应所述停止推流请求；

若所述状态信息为没有成功响应所述停止推流请求，则调用所述第二发送单元。

10.根据权利要求6、7、9中任一项所述的推流装置，其特征在于，所述推流装置还包括：

第二判断单元，用于根据推流地址，判断是否等待所述服务器发送的开始请求；

若等待所述服务器发送的开始请求，则调用所述第一发送单元。