代码之家 › 专栏 › 技术社区 › SMUsamaShah

WebRTC:编码器实现中的RTPfFragmentationHeader是什么?

openh264 h.264 webrtc video-streaming video

3

SMUsamaShah · 技术社区 · 8 年前

h264_encoder_impl 使用基于nvidia网格的硬件编码器。这是通过将OpenH264特定调用替换为Nvidia API调用来实现的。编码流可以成功写入文件,但无法写入 _buffer 和 _size 属于 encoded_image_ 还不够,而且 RTPFragmentationHeader 也需要填充。

// RtpFragmentize(EncodedImage* encoded_image,
//                       std::unique_ptr<uint8_t[]>* encoded_image_buffer,
//                       const VideoFrameBuffer& frame_buffer,
//                       SFrameBSInfo* info,
//                      RTPFragmentationHeader* frag_header)

// encode
openh264_->Encode(input, &info /*out*/);

// fragmentize ?
RtpFragmentize(&encoded_image_ /*out*/, &encoded_image_buffer_, *frame_buffer, 
               &info, &frag_header /*out*/); 

// ...

// send 
encoded_image_callback_->OnEncodedImage(encoded_image_, &codec_specific, &frag_header);

frag_header 在里面 RTPFragmentize() encoded_image->_length 但我不知道怎么做。

我在任何地方都找不到关于它的任何文档。我只有VP8和OpenH264实现。

那么什么是 RTPFragmentationHeader 编码图像->_长

1 回复 | 直到 8 年前

1

7

SMUsamaShah 7 年前

经过之后 RTPFragmentize() 在里面 h264_encoder_impl 我已经弄明白了。

在编码帧中有多个NALU。有不同的NALU,包括AUD、SPS(67)、PPS(68)和IDR。每个NALU由4字节开始代码分隔,该代码为 00 00 00 01 .

[00 00 00 01 67 42 c0 20 8c 8d 40 20 03 09 00 f0  
 88 46 a0 00 00 00 01 68 ce 3c 80]00 00 00 01 ..

您可以看到粗体的开始代码。只有方括号之间的字节属于标头,最后一个开始代码用于帧数据。

RTPFragmentationHeader 对于上述内容:

frag_header->fragmentationVectorSize = 3     // 2 fragments for header
                                             // 3rd fragment for frame buffer

frag_header->fragmentationOffset[0]  = 4     
frag_header->fragmentationLength[0]  = 15

frag_header->fragmentationOffset[1]  = 23    // 4 + 15 + sizeof(startcode)
frag_header->fragmentationLength[1]  = 4    

frag_header->fragmentationOffset[2]  = 31   
frag_header->fragmentationLength[2]  = 43218 // last fragment is frame buffer

下一帧总是只有一个片段,如下所示

00 00 00 01 67 b8 .. .. ..

encoded_image->_length 是实际编码帧缓冲区的大小,并且
encoded_image->_size 是编码帧缓冲区的最大大小。

OpenH264 API提供了编码帧中的NALU数,用于计算片段,而API I仅使用提供的头及其大小,无论头是否实际添加了帧。仅在帧字节中搜索头的大小可以正确计算碎片。

更新: 本质上,我不得不跳过 RTPFragmentize() 完全是因为它是专门为OpenH264设计的,并且计算 frag_header