#ifndef _NET_COMMON_H
#include "NetCommon.h"
#endif
#include <stdio.h>
#ifdef VXWORKS
#include <inetLib.h>
#endif
#if defined(__WIN32__) || defined(_WIN32)
#ifndef IMN_PIM
#define WS_VERSION_CHOICE1 0x202/*MAKEWORD(2,2)*/
#define WS_VERSION_CHOICE2 0x101/*MAKEWORD(1,1)*/
int initializeWinsockIfNecessary(void) {
/* We need to call an initialization routine before
* we can do anything with winsock. (How fucking lame!):
*/
static int _haveInitializedWinsock = 0;
WSADATA wsadata;
if (!_haveInitializedWinsock) {
if ((WSAStartup(WS_VERSION_CHOICE1, &wsadata) != 0)
&& ((WSAStartup(WS_VERSION_CHOICE2, &wsadata)) != 0)) {
return 0; /* error in initialization */
}
if ((wsadata.wVersion != WS_VERSION_CHOICE1)
&& (wsadata.wVersion != WS_VERSION_CHOICE2)) {
WSACleanup();
return 0; /* desired Winsock version was not available */
}
_haveInitializedWinsock = 1;
}
return 1;
}
#else
int initializeWinsockIfNecessary(void) { return 1; }
#endif
#else
#define initializeWinsockIfNecessary() 1
#endif
#ifndef NULL
#define NULL 0
#endif
#ifdef USE_SYSTEM_RANDOM
/* Use the system-supplied "random()" and "srandom()" functions */
#include <stdlib.h>
long our_random() {
#if defined(__WIN32__) || defined(_WIN32)
return rand();
#else
return random();
#endif
}
void our_srandom(unsigned int x) {
#if defined(__WIN32__) || defined(_WIN32)
srand(x);
#else
srandom(x);
#endif
}
#else
/* Use our own implementation of the "random()" and "srandom()" functions */
/*
* random.c:
*
* An improved random number generation package. In addition to the standard
* rand()/srand() like interface, this package also has a special state info
* interface. The our_initstate() routine is called with a seed, an array of
* bytes, and a count of how many bytes are being passed in; this array is
* then initialized to contain information for random number generation with
* that much state information. Good sizes for the amount of state
* information are 32, 64, 128, and 256 bytes. The state can be switched by
* calling the our_setstate() routine with the same array as was initiallized
* with our_initstate(). By default, the package runs with 128 bytes of state
* information and generates far better random numbers than a linear
* congruential generator. If the amount of state information is less than
* 32 bytes, a simple linear congruential R.N.G. is used.
*
* Internally, the state information is treated as an array of longs; the
* zeroeth element of the array is the type of R.N.G. being used (small
* integer); the remainder of the array is the state information for the
* R.N.G. Thus, 32 bytes of state information will give 7 longs worth of
* state information, which will allow a degree seven polynomial. (Note:
* the zeroeth word of state information also has some other information
* stored in it -- see our_setstate() for details).
*
* The random number generation technique is a linear feedback shift register
* approach, employing trinomials (since there are fewer terms to sum up that
* way). In this approach, the least significant bit of all the numbers in
* the state table will act as a linear feedback shift register, and will
* have period 2^deg - 1 (where deg is the degree of the polynomial being
* used, assuming that the polynomial is irreducible and primitive). The
* higher order bits will have longer periods, since their values are also
* influenced by pseudo-random carries out of the lower bits. The total
* period of the generator is approximately deg*(2**deg - 1); thus doubling
* the amount of state information has a vast influence on the period of the
* generator. Note: the deg*(2**deg - 1) is an approximation only good for
* large deg, when the period of the shift register is the dominant factor.
* With deg equal to seven, the period is actually much longer than the
* 7*(2**7 - 1) predicted by this formula.
*/
/*
* For each of the currently supported random number generators, we have a
* break value on the amount of state information (you need at least this
* many bytes of state info to support this random number generator), a degree
* for the polynomial (actually a trinomial) that the R.N.G. is based on, and
* the separation between the two lower order coefficients of the trinomial.
*/
#define TYPE_0 0 /* linear congruential */
#define BREAK_0 8
#define DEG_0 0
#define SEP_0 0
#define TYPE_1 1 /* x**7 + x**3 + 1 */
#define BREAK_1 32
#define DEG_1 7
#define SEP_1 3
#define TYPE_2 2 /* x**15 + x + 1 */
#define BREAK_2 64
#define DEG_2 15
#define SEP_2 1
#define TYPE_3 3 /* x**31 + x**3 + 1 */
#define BREAK_3 128
#define DEG_3 31
#define SEP_3 3
#define TYPE_4 4 /* x**63 + x + 1 */
#define BREAK_4 256
#define DEG_4 63
#define SEP_4 1
/*
* Array versions of the above information to make code run faster --
* relies on fact that TYPE_i == i.
*/
#define MAX_TYPES 5 /* max number of types above */
static int const degrees[MAX_TYPES] = { DEG_0, DEG_1, DEG_2, DEG_3, DEG_4 };
static int const seps [MAX_TYPES] = { SEP_0, SEP_1, SEP_2, SEP_3, SEP_4 };
/*
* Initially, everything is set up as if from:
*
* our_initstate(1, &randtbl, 128);
*
* Note that this initialization takes advantage of the fact that srandom()
* advances the front and rear pointers 10*rand_deg times, and hence the
* rear pointer which starts at 0 will also end up at zero; thus the zeroeth
* element of the state information, which contains info about the current
* position of the rear pointer is just
*
* MAX_TYPES * (rptr - state) + TYPE_3 == TYPE_3.
*/
static long randtbl[DEG_3 + 1] = {
TYPE_3,
0x9a319039, 0x32d9c024, 0x9b663182, 0x5da1f342, 0xde3b81e0, 0xdf0a6fb5,
0xf103bc02, 0x48f340fb, 0x7449e56b, 0xbeb1dbb0, 0xab5c5918, 0x946554fd,
0x8c2e680f, 0xeb3d799f, 0xb11ee0b7, 0x2d436b86, 0xda672e2a, 0x1588ca88,
0xe369735d, 0x904f35f7, 0xd7158fd6, 0x6fa6f051, 0x616e6b96, 0xac94efdc,
0x36413f93, 0xc622c298, 0xf5a42ab8, 0x8a88d77b, 0xf5ad9d0e, 0x8999220b,
0x27fb47b9,
};
/*
* fptr and rptr are two pointers into the state info, a front and a rear
* pointer. These two pointers are always rand_sep places aparts, as they
* cycle cyclically through the state information. (Yes, this does mean we
* could get away with just one pointer, but the code for random() is more
* efficient this way). The pointers are left positioned as they would be
* from the call
*
* our_initstate(1, randtbl, 128);
*
* (The position of the rear pointer, rptr, is really 0 (as explained above
* in the initialization of randtbl) because the state table pointer is set
* to point to randtbl[1] (as explained below).
*/
static long* fptr = &randtbl[SEP_3 + 1];
static long* rptr = &randtbl[1];
/*
* The following things are the pointer to the state information table, the
* type of the current generator, the degree of the current polynomial being
* used, and the separation between the two pointers. Note that for efficiency
* of random(), we remember the first location of the state information, not
* the zeroeth. Hence it is valid to access state[-1], which is used to
* store the type of the R.N.G. Also, we remember the last location, since
* this is more efficient than indexing every time to find the address of
* the last element to see if the front and rear pointers have wrapped.
*/
static long *state = &randtbl[1];
static int rand_type = TYPE_3;
static int rand_deg = DEG_3;
static int rand_sep = SEP_3;
static long* end_ptr = &randtbl[DEG_3 + 1];
/*
* srandom:
*
* Initialize the random number generator based on the given seed. If the
* type is the trivial no-state-information type, just remember the seed.
* Otherwise, initializes state[] based on the given "seed" via a linear
* congruential generator. Then, the pointers are set to known locations
* that are exactly rand_sep places apart. Lastly, it cycles the state
* information a given number of times to get rid of a
LIVE555 拉取H264 按每帧读取数据流
需积分: 0 108 浏览量
更新于2024-02-15
收藏 976KB RAR 举报
在IT行业中,流媒体技术是不可或缺的一部分,而LIVE555是一个开源的多媒体框架,广泛用于实时流媒体传输。本文将深入探讨如何利用LIVE555库来拉取并处理H264视频流,特别是如何按帧读取数据并进行单帧数据的重构与测试。
LIVE555是一个C++库,它提供了多种协议(如RTSP、RTP、RTCP等)的支持,使得开发者能够构建复杂的多媒体服务器、客户端或者应用程序。H264是一种高效的视频编码标准,广泛应用于网络视频传输,因为它能够在较低带宽下提供高质量的视频。
拉取H264数据流涉及的主要步骤如下:
1. **初始化LIVE555**:你需要创建一个`UsageEnvironment`对象,它是LIVE555的核心组件,负责处理事件调度和错误处理。接着,创建一个`TaskScheduler`实例,用来安排任务执行。
2. **建立RTSP连接**:通过`LiveMedia::createNewSession`函数建立到RTSP服务器的连接。提供服务器地址、端口号和会话信息,以便开始交互。
3. **订阅媒体流**:使用`LiveMedia::BasicSession`对象,调用`initiate`方法来订阅特定的媒体流。H264流通常通过RTP传输,因此需要设置适当的SDP描述。
4. **接收RTP数据包**:定义一个回调函数来处理接收到的RTP数据包。这些数据包包含H264编码的视频帧。LIVE555会调用这个回调函数,将数据包传递给用户代码。
5. **单帧数据提取**:在回调函数中,解析RTP包头以获取时间戳和序列号,这些信息用于重组连续的H264 NAL单元(Network Abstraction Layer units)。每个NAL单元通常代表视频的一帧或部分帧。
6. **数据重构**:根据H264的编码规范,NAL单元可能被分割并分布在多个RTP包中。你需要收集所有属于同一帧的NAL单元,然后按照正确的顺序重新组装它们。
7. **输出到测试文件**:重构后的H264数据可以写入到本地文件,以供进一步分析或播放。这可以通过打开一个文件流,然后将数据写入其中来实现。
8. **测试与调试**:编写测试用例,检查重构过程是否正确,确保每一帧都能正确解码和显示。可以使用开源的解码工具,如FFmpeg,对输出文件进行验证。
在这个过程中,"重构"主要指的是将接收到的分片的H264数据恢复成完整的视频帧,而"测试"则包括了确保数据正确性的验证步骤。理解H264编码规范和RTP协议是完成这项工作的关键。
总结来说,使用LIVE555拉取H264数据流并按帧处理涉及到多媒体协议、网络编程以及视频编码知识。在实际应用中,可能还需要考虑到网络条件的变化、错误处理以及性能优化等因素。通过不断测试和调试,你可以构建出一个可靠的系统,有效地处理和呈现H264视频流。


溯光鳐
- 粉丝: 129
最新资源
- 自动化LED功能性及特殊照明封装及光源建设项目环境影响表.doc
- 基于信息支持设备的通信系统的设计.docx
- 桩基础施工技术现状及发展趋向浅谈.doc
- 基于AT89S51单片机的数字万年历方案设计书.doc
- PHP网上问卷调查系统的方案设计书与实现.doc
- 管理评审程序-secret.doc
- 互联网+模式下《传播学》教学模式探索.docx
- 地下连续墙施工方案.ppt
- .《基因工程的基本操作程序》.ppt
- 化学水处理静设备安装施工技术方案.pdf
- 第七章工程量清单计价.pptx
- 全国河流水系网络化与渤海淡化工程的思考.docx
- WLAN网络优化指导.ppt
- 人力资源盘点与规划操作流程手册.docx
- 提高烟囱筒壁施工质量(QC).ppt
- 软件项目管理简答题名词解释.docx