rtmp流转Hls流 与 flv转mpegts

rtmp协议是adobe出的一种流媒体格式协议。是目前较为流行的协议的一种。

HLS协议是苹果推出的一种流媒体协议，由于IOS系统不支持RTMP协议，如实现RTMP协议的流媒体需要自己实现RTMP的客户端，这使得移动手机端使用RTMP的流媒体增加了一些开发成本。

HLS协议的详情可以参考APPLE的网站，内容主要由M3U8和MPEGTS这两大文件组成，本文详解的是MPEGTS文件。

MPEG2-TS（Transport Stream“传输流”；又称 MTS、TS）是一种传输和存储包含音效、图像与通信协议各种数据的标准格式，用于数字电视广播系统，如 DVB、ATSC、IPTV 等等。

MPEG2-TS 定义于 MPEG-2 第一部份，系统（即原来之 ISO/IEC 标准 13818-1 或 ITU-T Rec. H.222.0）。

SMPLAYER、VLC多媒体播放器 等软件可以直接播放 MPEG-TS 文件。

MPEG2-TS传输流编码层允许一个或多个节目组合成单一流。来自每个基本流的数据同节目内允许该基本流同步显示的信息一起多路复用。

传输流由一个或多个节目组成。音频和视频基本流（ES）由存取单元（AU,一般常说的NALU）组成。

基本流数据（ES element stream ,  比如H264裸流）在PES 包中承载。PES 包由PES 包头及后随的包数据组成。PES 包插入到传输流包中。每个PES 包头的首字节定位于传输流包的第一个有效载荷位。

本文主要的参考为：ISO-13818-1，Adobe Flash Video File Format Specification  Version 10.1，ISO-14496-3，ISO-14486-15

本文所述内容与标准有一定的差异，这种差异并非指存在违背标准的内容，而是本文由于篇幅所限，对于某些约束，只取与符号标准的一项，而不是兼容标准所有的规范。

1.2结构

传输流类似OSI network 协议堆栈：

1.TS

2. PES

3.Elementarystream (ES) — audio or video (the below is for video only)

4.编码层..

1.3传输流数据包（transport stream packets）

TransportStream packets -> PES -> ES

TransportStream packets 是传输流（transport stream）内数据的最基本单位，包含了一个同步字节（sync byte）值为 0x47，它存在一个4bytes的固定包头，32bits 接着它的是可变包头区域。 Packets 有固定的188 bytes 的长度。

表1-1 Transport Stream packets结构


字段
Value
bits

sync_byte
0x47
8
bslbf

transport_error_indicator
如果这个流中包含了一个无法修复的错误，由解调器设置，以告诉多路解调器，该包存在一个无法纠正的错误
1
bslbf

payload_unit_start_indicator
1 表示是 PES 数据或 PSI数据的开始部分，否则为零.
1
bslbf

transport_priority
1 意思是在相同 PID 的数据包中含有更高的优先权.
1
bslbf

PID
PID 为13 比特字段，指示包有效载荷中存储的数据类型，也就是包的标识号。
13
uimsbf

transport_scrambling_control
此2 比特字段指示传输流包有效载荷的加扰方式。
2
bslbf

adaptation_field_control
此2 比特字段指示此传输流包头是否后随自适应字段和/或有效载荷
2
bslbf

continuity_counter
continuity_counter 为4 比特字段，随着具有相同PID 的每个传输流包而增加
4
uimsbf

这里最主要关系的是payload_unit_start_indicator，PID，adaptation_field_control，continuity_counter

payload_unit_start_indicator

这个位标志为1，指的是一个包的启示，因为ts包只有188个字节，对于一个PES包的话往往大于188字节，因此一个PES包往往要拆成多个TS包，为了识别收到的TS包属于另一个PES包，起始位表示新的一个PES包或者PSI包等到来了。

PID program id

节目标示符，一个13位的无符号整数。作用如下表描述。一般来说，参考FFMPEG，PMT表使用PID 4096，VIDEOSTREAM 采用256，AUDIOSTREAM采用257。

adaptation_field_contro

当adaptation_field_control的值为10，接下来的是自适应字段adaptation_field，当adaptation_field_control的值如下表描述

continuity_counter

这个是当前节目的一个计数器，独立于PID，也就是说各个PID分开计算。

接下来的就是有效的负载内容，具体的负载内容必须是来自PES 包（参阅2.4.3.6）、PSI 分段（参阅2.4.4）以及PSI 分段后的包填充字节数据的相连贯的数据字节，或者不在这些结构中的专用数据，如PID 所指示的。在具有PID 值0x1FFF 的空包情况中，data_bytes 可以指派为任何值。data_bytes 数N 通过184 减去 adaptation_field() 中的字节数来确定。

TS包结构图

1.4 自适应字段 （adaptation_field）

 

自适应字段我们主要关注的是第一个adaptation  field length和PCR，这里重点讲解他们的主要用处：

adaptationfield length指的是自适应字段的长度，也就是，从discontinuity indicator 到adaptation field最后的长度，也就是从第6字节（包含第6字节）开始算到最后。

 

PCR

这个值是系统的时间戳，在PES层时间戳是PTS与DTS，这里要注意与PCR，PTS,DTS的概念，可能会让人模糊。PCR是TS层的时间戳，PTS与DTS是PES的时间戳，PCR在PES层相当于DTS，TS不需要考虑PTS。为啥不需要，这里就要讲下，PTS的具体概念。详细的在ISO-13818-1上有，详细到可以看到你吐。其实实际中不需要考虑这么多。我简单的讲吧。在ES流中，依次组成图像帧序为I1P4B2B3P7B5B6I10B8B9的，这里,I、P、B分别指I帧，P帧，B帧。具体意义可以参考H264的相关基本概念，对于I、P帧而言，PES的图像帧序为I1P4B2B3P7B5B6I10B8B9，应该P4比B2、B3在先，但显示时P4一定
要比B2、B3在后，这就必须重新排序。在PTS/DTS时间标志指引下，将P4提前插入数据流，经过缓存器重新排序，重建视频帧序 I1B2B3P4B5B6P7B8B9I10。显然，PTS/DTS是表明确定事件或确定信息，并以专用时标形态确定事件或信息的开始时刻。说到这里，PTS,与DTS的概念应该明白了。但是为啥TS层不需要呢，因为TS层只是负责传输，你知道解码的时间在什么位置，确保传输的TS包不是延迟太久就可以了，具体的显示细节交给PES层去做。

 

2.1 PES包

    PES将ES流打包，打包的依据我没有发现有硬性规定，但是一般会将ES流中的一个frame打包成一个PES,在H264的ES流中的NALU流如果分段的话，会由3个NALU组成一个frame，一般来说，都没有分段的选项。所以，我们可以简单的认为一个NALU就是一个frame。

在ffmpeg中，H264的SPS与PPS一起打包在头一个NALU中，

PES包的字段没什么好讲的，

streamID , 这里视频H264填写0xe0 ,AAC音频填写OXCO

PES PACKET LENGTH 是从OPTIONAL FIELD 到包最后一个字节的长度，不算前面的4字节，和自身2字节，一般来说就是3+10+NALUSIZE，这里10是指VIDEOFRAME的，如果是AUDIOFRAME则是5.

PTS,和DTS的计算。如果是根据ES流计算怎么算，我还没想到容易的方法。但是如果根据FLV格式转换，PTS就是(flvTagHeader.timestamp +videoTagHeader.CompositionTime) * 90 , 为啥是90呢？flv里面的时间戳的单位都是毫秒的，1/1000秒。mpegts的系统时钟为27MHZ，这里要除以300(规定的除以300，参考ISO-13818-1)。也就是90000hz，一秒钟90000个周期，所以，PTS代表的周期flv的时间戳*90000/1000
，90也就是这么来的。

TS层里的PCR可以直接采用DTS。

/

以下是截取的一个TS包，红色部分为SPS，PPS，蓝色部分为es 流中的startcode ，紫色部分为H.264 video access units must use Access Unit Delimiter NALs

这在https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/streamingmediaguide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html第10个问题那里说的很清楚。可以直接在每个NALU前面直接加上00
00 00 01 09 F0。

47 41 00 30 07 50 00 00 00 00 7E 00 00 00 01 E0
50 A5 80 C0 0A 31 00 01 5D 85 11 00 01 00 01 00
00 00 01 09 F0 00 00 00 01 67 64 00 15 AC C8 60
20 09 6C 04 40 00 00 03 00 40 00 00 07 A3 C5 8B
67 80 00 00 00 01 68 E9 BB 2C 8B 00 00 00 01 65
88 84 00 7F 4D 32 19 FF 2D 02 C7 FE E6 51 22 40
3D AA 71 9A 11 60 AE 24 4B BB 66 66 4E 71 C9 E0
E4 EB 4C D1 FE D4 B7 3B 8F 1D 36 2C 76 5B B9 12
70 23 B6 F4 C0 EB 58 CD 66 AB 0D C5 2A 91 59 C6
31 7F 7B A0 5A 76 AD 3F BD 01 88 6A 35 84 BE 58
06 A0 1C 99 93 72 BC CE 61 6D 22 CB 89 E1 AD 56
26 C0 48 66 78 2C 2C EF 38 F8 84 CF

2.2 PAT

 

节目相关表：

这个表主要是节目相关信息的表。这个表在转换的时候，可以采取一种暴力的方法，就是写死。

这里CRC校验的算法，最后会说，计算的字节是只计算PSI+PXT的内容，TS头部的内容不考虑。


PAT specific data repeated until end of section length

Name
Number

of bits
Description

Program num
16
Relates to the Table ID extension in the associated PMT. A value of 0 is reserved for a NIT packet identifier.

Reserved bits
3
Set to 0x07 (all bits on)

Program map PID
13
The packet identifier that contains the associated PMT

 

 //TS
    0x47,0x40,0x00,0x10,0x00,
 //PSI,table id 00
    0x00,0xb0,0x0d,0x00,0x01,0xc1,0x00,0x00,
 //PAT
    0x00,0x01,0xf0,0x01,
 //crc
    0x2e,0x70,0x19,0x05,
 // stuffing 167 bytes
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,

2.3 PMT

 

PMT(Program map specific data)


PMT specific data

Name
Number

of bits
Description

Reserved bits
3
Set to 0x07 (all bits on)

PCR PID
13
The packet identifier that contains the program clock reference used to improve the random access accuracy of the stream‘s timing that is derived from the program timestamp. If this is unused. then it is set to 0x1FFF (all bits on).

Reserved bits
4
Set to 0x0f (all bits on)

Program info length unused bits
2
Set to 0 (all bits off)

Program info length
10
The number of bytes that follow for the program descriptors.

Program descriptors
N*8
When the program info length is non-zero, this is the program info length number of program descriptor bytes.

Elementary stream info data
N*8
The streams used in this program map.

Elementary stream specific data repeated until end of section length

Name
Number

of bits
Description

stream type
8
This defines the structure of the data contained within the elementary packet identifier.

Reserved bits
3
Set to 0x07 (all bits on)

Elementary PID
13
The packet identifier that contains the stream type data.

Reserved bits
4
Set to 0x0f (all bits on)

ES Info length unused bits
2
Set to 0 (all bits off)

ES Info length length
10
The number of bytes that follow for the elementary stream descriptors.

Elementary stream descriptors
N*8
When the ES info length is non-zero, this is the ES info length number of elementary stream descriptor bytes.

 

 //ts
    0x47,0x50,0x01,0x10,0x00,
 //PSI
    0x02,0xb0,0x17,0x00,0x01,0xc1,0x00,0x00,
 //PMT ,no pcr
    0xe1,0x00,
    0xf0,0x00,
    0x1b,0xe1,0x00,0xf0,0x00,
    0x0f,0xe1,0x01,0xf0,0x00,
 //crc
    0x2f,0x44,0xb9,0x9b,
 // stuffing 157 bytes
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,

3.FLV文件分析

FLV文件的结构，可以在网上找个flv parse的工具帮助分析。

可以看到，FLV的文件形式由FLV HEADER + pre Tag Size + Tag 组成

首先每个TAG中的前面有个11字节的头部，这个描述了该tag中的内容的类型。后续接着的是相关类型的TAG内容。

3.1 视频

对于VIDEO TAG来讲，首部会有个5字节的VIDEO TAG HEADER，

这里如果AVCPACKET TYPE为0，则表示AVC SEQUENCE HEADER，这里包含着很重要的信息，也就是H264 ES流中解码的关键信息--SPS ,PPS的内容

AVC SEQUENCE HEADER的具体内容可参考， ISO-14496-15AVC file format。这里简化如下表所示。 AVC SEQUENCEHEADER一般情况只出现一次，并出现在FLV文件的第一个VIDEO TAG。这里引用一张别人的图，出处我忘了不好意思，因为项目是一年前做的。

从AVC PACKET TYPE 看出每个VIDEO TAG至少包含一个完整的FRAME。在FLV中的NALU，需要加上00 00 00 01这样的NALU头，并在前面再加上 00 00 00 01 09 f0，具体的原因应该是规范。视频的PTS的时间戳由TAG里的TIMESTAMP + COMPOSITIONTIME构成。DTS可直接由TIMESTAMP。这里FLV里的是毫秒，需要*90向MPEGTS的时钟周期进行转换

3.2音频

音频的TAG如下图所示，值得注意的是AAC SEQUENCE HEADER，这里和视频头部一样，其实质内容是AudioSpecificConfig ，定义在14496-3中。包含了AAC解码的关键内容，ADTS HEADER的内容。ADTS 的内容定义在13818-7中。这些定义在标准里面写的看起来很复杂，实际上内容倒也没什么。AAC ES流中要求每个音频frame前面要加上ADTS HEADER 的内容。我们根据首个音频TAG中提取2字节的AUDIO SPECIFIC CONFIG，转换成7字节的ADTS
HEADER，代码可参考FFMPEG等，很多有提供。这里注意，很容易出错。

RTMP媒体流中，第一个音频包里保护的一定是AAC header.

如：af 00 13 90。包长4个字节，解释如下，

1）第一个字节af，a就是10代表的意思是AAC，

Format of SoundData. The following values are defined:

0 = Linear PCM, platform endian

1 = ADPCM

2 = MP3

3 = Linear PCM, little endian

4 = Nellymoser 16 kHz mono

5 = Nellymoser 8 kHz mono

6 = Nellymoser

7 = G.711 A-law logarithmic PCM

8 = G.711 mu-law logarithmic PCM

9 = reserved

10 = AAC

11 = Speex

14 = MP3 8 kHz

15 = Device-specific sound

Formats 7, 8, 14, and 15 are reserved.

AAC is supported in Flash Player 9,0,115,0 and higher.

Speex is supported in Flash Player 10 and higher.

2）第一个字节中的后四位f代表如下

前2个bit的含义 抽样频率，这里是二进制11，代表44kHZ

Sampling rate. The following values are defined:

0 = 5.5 kHz

1 = 11 kHz

2 = 22 kHz

3 = 44 kHz

第3个bit，代表 音频用16位的

Size of each audio sample. This parameter only pertains to

uncompressed formats. Compressed formats always decode

to 16 bits internally.

0 = 8-bit samples

1 = 16-bit samples

第4个bit代表声道

Mono or stereo sound

0 = Mono sound

1 = Stereo sound

3）第2个字节

AACPacketType，这个字段来表示AACAUDIODATA的类型：0 = AAC sequence header，1 = AAC raw。第一个音频包用0，后面的都用1

4）第3，4个字节内容AudioSpecificConfig如下

AAC sequence header存放的是AudioSpecificConfig结构，该结构则在“ISO-14496-3 Audio”中描述。AudioSpecificConfig结构的描述非常复杂，这里我做一下简化，事先设定要将要编码的音频格式，其中，选择"AAC-LC"为音频编码，音频采样率为44100，于是AudioSpecificConfig简化为下表：

0x13 0x90（1001110010000） 表示 ObjectProfile=2， AAC-LC，SamplingFrequencyIndex=7，ChannelConfiguration=声道2

AudioSpecificConfig，即为ObjectProfile，SamplingFrequencyIndex，ChannelConfiguration，TFSpecificConfig。

其中，ObjectProfile (AAC main ~1, AAC lc ~2, AAC ssr ~3)；

SamplingFrequencyIndex (0 ~ 96000， 1~88200， 2~64000， 3~48000， 4~44100， 5~32000， 6~24000， 7~ 22050， 8~16000...)，通常aac固定选中44100，即应该对应为4，但是试验结果表明，当音频采样率小于等于44100时，应该选择3，而当音频采样率为48000时，应该选择2；

ChannelConfiguration对应的是音频的频道数目。单声道对应1，双声道对应2，依次类推。

TFSpecificConfig的说明见标准14496-3中（1.2 T/F Audio Specific Configuration）的讲解，这里恒定的设置为0；

索引值如下含义：

There are 13 supported frequencies:

0: 96000 Hz

1: 88200 Hz

2: 64000 Hz

3: 48000 Hz

4: 44100 Hz

5: 32000 Hz

6: 24000 Hz

7: 22050 Hz

8: 16000 Hz

9: 12000 Hz

10: 11025 Hz

11: 8000 Hz

12: 7350 Hz

13: Reserved

14: Reserved

15: frequency is written explictly

channel_configuration: 表示声道数

0: Defined in AOT Specifc Config

1: 1 channel: front-center

2: 2 channels: front-left, front-right

3: 3 channels: front-center, front-left, front-right

4: 4 channels: front-center, front-left, front-right, back-center

5: 5 channels: front-center, front-left, front-right, back-left,back-right

6: 6 channels: front-center, front-left, front-right, back-left,back-right, LFE-channel

7: 8 channels: front-center, front-left, front-right, side-left,side-right, back-left, back-right, LFE-channel

8-15: Reserved

时间： 2024-11-05 21:10:11

rtmp流转Hls流 与 flv转mpegts的相关文章

【转】直播流程，视频推流，视频拉流，简介，SMTP、RTMP、HLS、 PLPlayerKit

原:https://www.cnblogs.com/baitongtong/p/11248966.html 1 .音视频处理的一般流程: 数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示1.数据采集:摄像机及拾音器收集视频及音频数据,此时得到的为原始数据涉及技术或协议:摄像机:CCD.CMOS拾音器:声电转换装置(咪头).音频放大电路2.数据编码:使用相关硬件或软件对音视频原始数据进行编码处理(数字化)及加工(如音视频混合.打包封装等),得到可用的音视频数据涉及技术或协议:编码

推流和拉流的概念以及RTMP和HLS协议

https://www.bbsmax.com/A/x9J2wZM56o/ 推流为将直播内容推送至服务器的过程:拉流为服务器已有直播内容,用指定地址进行拉取的过程. rtmp rtmp是Real Time Messaging Protocol(实时消息传输协议)的首字母缩写.该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种.RTMP是一种设计用来进行实时数据通信的网络协议,主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进

[转]流媒体协议介绍（rtp/rtcp/rtsp/rtmp/mms/hls）

[转]流媒体协议介绍(rtp/rtcp/rtsp/rtmp/mms/hls) http://blog.csdn.net/tttyd/article/details/12032357 RTP 参考文档 RFC3550/RFC3551 Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议.RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式.RTP 协议常用于流媒体系统(配合RTCP协议),视频会议和一键通(Push to Tal

流媒体(RTMP,RTSP,HLS)

流媒体(RTMP,RTSP,HLS) 前言 最近项目需要流媒体的播放,后端一共提供了 三种流数据(RTSP,RTMP,HLS),在不同的场景可能会使用到不同方式播放,就需要做到适配, 支持所有的流数据播放.花了一段时间研究,在这里和大家分享一下,还有些遗留问题,看大家有没有好的方法. RTSP 简介 这种协议流数据前段播放,没有特别好的解决方法,需要在本机装一个vlc 插件,依靠这个插件才能让 RTSP 协议 在网页上能播放,但是目前高版本的 Chrome 浏览器不支持 NPAPI 插件,也就是

rtmp与hls流媒体服务器搭建：ubuntu下Nginx搭建初探与rtmp-module的添加

关键词:Nignx(http服务器):rtmp,hls(流媒体服务) 前言:感谢开源,感谢战斗民族.现在在做流媒体服务的一些工作,流媒体服务器搭建的网上教程多入牛毛,但是细细查看,发现很多同志贴上来的教程都有些许问题,还有一些是爬别人的数据得来的,排版上也有问题,让新手无所适从.本文也是通过翻看一些优质的博文得到的这篇分享.以下分享的网址就是引用的博文,安利一下. 1. http://redstarofsleep.iteye.com/blog/2123752 2. http://blog.csd

最简单的基于Flash的流媒体示例：网页播放器（HTTP，RTMP，HLS）

本文继续上一篇文章,记录一些基于Flash的流媒体处理的例子.本文记录一些基于Flash技术的网页播放器.基于Flash的网页播放器相比于其他网页播放器来说最大的优势就是"免插件安装"了,这一点可以很大的提高用户的体验质量.早些时候网络视频(尤其是直播)一般都使用ActiveX控件作为视频播放器,而这些控件并不普及,所以终端用户必须下载相关的插件才能收看节目,因而对很多不熟悉电脑的用户造成了很大的障碍.直到Flash网页播放器的出现,这一障碍才得到了解决.本文将会记录几个常用的网页播放

vue播放rtmp、hls m3u8格式视频

选用Video.js作为视频播放库,如果要支持hls m3u8还需要videojs-contrib-hls组件的支持. 安装Video.js npm install --save video.js 安装videojs-contrib-hls npm install --save videojs-contrib-hls 创建一个vue的播放组件 src/components/VideoPlayer/index.vue <template> <div> <video ref=&q

EasyRTSPLive摄像机NVR录像机RTSP协议实时流转RTMP协议直播流推送之搭建EasyRTMPLive拉RTSP流转RTMP测试环境的方法解析

EasyRTMPLive是一套流媒体接入软件网关,即软件编码器:将RTSP.RTMP.HTTP.HLS等各种各样的网络流媒体先拉取到本地,进行转换,再以标准RTMP/flv协议的方式推流到RTMP流媒体服务器.CDN等,进行直播分发. 搭建EasyRTMPLive拉RTSP流转RTMP测试环境 今天主要为大家介绍一下EasyRTMPLive具体搭建流程. 1.从https://github.com/tsingsee/EasyRTMPLive 获取EasyRTMPLive程序包,直接运行EasyR

搭建rtmp直播流服务之4:videoJS/ckPlayer开源播放器二次开发(播放rtmp、hls直播流及普通视频)

前面几章讲解了使用nginx-rtmp搭建直播流媒体服务器,以及使用ffmpeg推流到nginx-rtmp服务器,java通过命令行调用ffmpeg实现推流服务,后端的事情到这里就已经全部完成了. 本章讲一下播放器的选用和二次开发,前端的播放器虽然有flex(flash)可以用,但是很遗憾flex接触的并不多,学习成本又太高,那么基于第三方开源的flash播放器二次开发就显得很有必要. 一.几种播放器选择 那么播放器,哪些已经不再更新的和收费的,这里不会介绍,只介绍两种轻量级的开源播放器. 1.