【概念解释】packet, frame,...

参考

[1] Definition of Network Units: Packet, Fragment, Frame, Datagram, and Segment
[2] Difference between Frame and packets in IEEE 802.11

1 背景

不同的OSI层 & 不同的协议都有自己的 specific units
the packet, fragment, frame, datagram, and segment, …
作为wireless领域的的phd candidate,目前还并不是很清晰这些units的具体定义以及互相之间的联系,因此专门写一篇笔记理一下

2 OSI model

先复习一下
在这里插入图片描述

在这里插入图片描述
下面从底层向高层记录

3 Frame

frames are small parts of a message

It helps to identify data and determine the way it should be decoded and interpreted

frame有两种类型:
fixed-length and variable-length frames

variable-length frames需要规定起始符和结束符,fixed-length frame不用

4 Packet & Frame

The basic unit of communication between a source and a destination in a network. Data sent through the network is divided into packets, that are recombined by the destination devices.

packets结构如下
在这里插入图片描述


Frame & Pakcet区别

The main difference between a packet and a frame is the association with the OSI layers

A frame contains more information about the transmitted message than a packet

Frames are not much different from packets. Frames contain more information about the data than Packets

越往底层,units包含的信息越多,越复杂。


In each network, there is a maximum size of the data to be transmitted called the MTU (Maximum Transmitted Unit). Packets can often be larger than the maximum size, so each packet is also divided into smaller pieces of data called fragments.

Fragment仍然属于网络层

When the network layer receives a packet, it checks the MTU of the packet. If the packet length is bigger than the MTU, the network layer checks the Don’t Fragment (DF) flag associated with the packet. If the DF flag is 1, we discard the packet. Otherwise, the network layer decides the size of the fragments, create the header, encapsulate the fragments within the header, and send them to the next layer在这里插入图片描述
现在知道路由器是干啥用的了

5 Datagram & Segment

In a datagram, we divide data frequently and transmitted from source to destination without a predefined route. We also can’t guarantee the order of delivery to the receiver end.

While TCP uses packets in connection-oriented protocols, datagrams are used in UDP, making them carry less information since they don’t need to have a response message from the destination

In the case we sent an email using the UDP protocol, there will be no packets but datagrams. The information transmitted would be in the following figure:
在这里插入图片描述
A segment is a broken piece of a packet with a TCP header in each of them

f we sent an email with a TCP connection, then the data that exists in the transport layer to complete the operation is an example of a segment. The email packet will then become:

在这里插入图片描述

6 Specificaitons on PHY layer

上面是广义的计算机网络的知识, network layer的pakcet作为payload被包含在data link layer的frame中

在 PHY layer中,packet 与 frame有另外的意思

比如在 IEEE 802.11标准中(WIFI)的packets中,the frame is encapsulated within the data field of the packet

在matlab的数据处理中,也经常用frame来作为数据单位,比如处理音频流时的长度参数叫frameLength

<think>嗯,用户问的是关于C语言中H.264实时视频压缩传输的介绍。首先,我需要确认H.264的基本概念,以及它在实时视频传输中的应用。H.264,也就是AVC,是一种高效的视频编码标准,常用于流媒体实时通信。用户可能想知道如何在C语言环境下实现这个,所以应该涉及相关的库,比如x264或者FFmpeg。 接下来,实时视频传输需要考虑的几个关键点:编码速度、延迟、网络传输。编码速度必须足够快,才能实时处理每一帧。延迟要低,否则会影响实时体验。网络传输可能需要使用RTP或RTCP这样的协议,或者更现代的WebRTC。不过用户提到的是C语言,所以可能需要更底层的实现。 然后,我应该分步骤介绍实现过程。首先,视频采集,可能需要用到V4L2在Linux或者DirectShow在Windows。然后,编码部分,使用x264库进行编码,这里需要配置编码器的参数,比如码率、GOP结构、帧类型等。编码后的数据需要封装成NAL单元,然后传输。 传输部分,可能需要用套接字编程,TCP还是UDP?UDP更快,但不可靠,适合实时视频。RTP通常基于UDP,所以可能需要实现RTP打包。然后是解码播放,但用户可能主要关注发送端,不过接收端也是整个系统的一部分。 另外,优化方面,多线程编码、降低分辨率、调整码率来适应网络带宽。错误恢复机制,比如插入IDR帧或者使用FEC。不过用户可能没有提到这些细节,是否需要深入呢? 还要考虑不同平台的兼容性,比如LinuxWindows的差异。可能还需要提到一些开源项目或库,比如FFmpeg的libavcodec,它内部可能用了x264,这样在C语言中调用FFmpeg的API也是一种方法。 用户可能的背景是什么?可能是学生或者开发者,想做一个实时视频传输的项目,需要技术选型步骤指导。他们可能对视频编码不太熟悉,所以需要解释基本流程关键点,同时给出代码示例会更好。 有没有可能用户的需求不仅仅是介绍,而是想实现一个具体的项目?比如视频监控、视频会议等。所以可能需要强调低延迟高效率的设置。 另外,H.264的专利问题需要注意,虽然现在有开源实现,但商业用途可能需要考虑许可。不过这可能超出技术介绍的范围,但或许值得提一下。 总结,回答的结构应该是:介绍H.264,实时传输的关键点,实现步骤(采集、编码、传输),推荐的库工具,优化方法,最后可能给出简单的代码示例或参考项目。</think>在C语言中实现H.264实时视频压缩传输,主要涉及视频采集、编码、传输解码等步骤。以下是关键点技术实现方案: --- ### **1. H.264编码基础** - **H.264/AVC** 是一种高效的视频压缩标准,支持低码率、高画质的实时传输。 - 核心特性:帧内预测、帧间预测、整数变换、熵编码(CABAC/CAVLC)、分块编码等。 --- ### **2. 实现流程** #### **(1) 视频采集** - **工具/库**: - **Linux**:V4L2(Video4Linux2)捕获摄像头数据。 - **Windows**:DirectShow或Media Foundation。 - **输出格式**:通常为YUV420P原始帧(H.264编码的输入格式)。 #### **(2) H.264编码** - **推荐库**: - **x264**:轻量级、高性能的H.264编码库(C语言实现)。 - **FFmpeg/libavcodec**:集成x264的多媒体框架,提供更高层API。 - **编码配置**: - 设置参数:分辨率、帧率(如30fps)、码率(如2000kbps)、GOP(关键帧间隔)。 - 低延迟模式:`preset=ultrafast` + `tune=zerolatency`(x264专用参数)。 ```c // x264编码示例(伪代码) x264_param_t param; x264_param_default_preset(&param, "ultrafast", "zerolatency"); param.i_width = 1280; param.i_height = 720; param.i_fps_num = 30; param.i_fps_den = 1; x264_t* encoder = x264_encoder_open(&param); x264_picture_t pic_in, pic_out; // 填充YUV数据到pic_in int frame_size = x264_encoder_encode(encoder, &nal, &i_nal, &pic_in, &pic_out); ``` #### **(3) 网络传输** - **协议选择**: - **RTP over UDP**:低延迟,适合实时传输(需打包H.264 NAL单元)。 - **WebRTC**:集成拥塞控制,但需复杂信令(如STUN/TURN)。 - **TCP**:可靠但延迟高,非实时首选。 - **数据封装**: - H.264码流由多个**NAL单元**组成,需按RTP规范分包(RFC 6184)。 - 关键帧(IDR帧)需完整传输,防止花屏。 ```c // RTP包头示例(12字节) typedef struct { uint8_t version; uint8_t payload_type; uint16_t seq; uint32_t timestamp; uint32_t ssrc; } RTPHeader; ``` #### **(4) 接收与解码** - **解码库**:FFmpeg/libavcodec 或 OpenH264。 - **Jitter Buffer**:缓解网络抖动,需平衡延迟与流畅性。 --- ### **3. 关键优化点** - **低延迟**: - 编码器启用`zerolatency`模式。 - 缩短GOP(如每2秒一个关键帧)。 - **抗丢包**: - 使用FEC(前向纠错)或重传关键帧。 - 插入SEI信息辅助错误恢复。 - **多线程**: - 分离采集、编码、传输线程,避免阻塞。 --- ### **4. 开源工具参考** - **x264**:直接集成到C项目中的编码库。 - **Live555**:C++实现的RTP/RTSP流媒体库(支持H.264)。 - **FFmpeg**:采集、编码、传输一站式解决方案(C API)。 --- ### **5. 简单代码框架** ```c #include <x264.h> #include <netinet/udp.h> void encode_and_send() { // 1. 初始化x264编码器 x264_param_t param; // ...配置参数... x264_t* encoder = x264_encoder_open(&param); // 2. 采集YUV帧(示例伪代码) uint8_t yuv_data[width*height*3/2]; capture_yuv_from_camera(yuv_data); // 3. 编码为H.264 x264_picture_t pic_in; x264_picture_alloc(&pic_in, X264_CSP_I420, width, height); memcpy(pic_in.img.plane[0], yuv_data, width*height); // ...填充U/V分量... x264_nal_t* nals; int i_nals; int frame_size = x264_encoder_encode(encoder, &nals, &i_nals, &pic_in, NULL); // 4. 通过RTP发送NAL单元 for (int i = 0; i < i_nals; i++) { send_rtp_packet(nals[i].p_payload, nals[i].i_payload); } } ``` --- ### **6. 注意事项** - **硬件加速**:考虑使用NVIDIA NVENC或Intel QSV提升编码速度。 - **带宽适应**:动态调整码率(如基于网络反馈)。 - **版权问题**:H.264需专利许可,商业项目建议使用VP9或AV1(免版税)。 如需更具体的实现细节(如V4L2采集或RTP封包),可进一步深入某个环节!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值