问题背景：
凡是和流媒体和音视频打交道，时间戳基本是一个必须深刻理解的概念。你会在各种各样的传输协议和封装格式中看到这个东西，而且表现形式还不一样。其次这个概念会涉及到音视频播放的同步问题，也会影响音视频播放的控制问题。前者说的是音画同步，后者说的是类似快进，随机点播放等。如果要理解好这个概念，需要掌握下面几个名词的含义。
基本概念：
采样率
音视频现在采用的数字编码方法，简单说就是把音视频这种波形和图像进行采集，量化，编码，传输，解码。所以采样率就是每秒钟抽取图像或者声波幅度样本的次数。比如音频采样率8k,就是表示把波形进行每秒8000次采样。
我们看到一秒的采样频率其实挺大的，至于这个值是多少合理，其实无论视频还是音频都和人的视觉特征和听觉特征有关系。
对于人的视觉而言，只要1秒钟播放的视频达到25帧以上，我们就看到了连续的图像即为视频。如果低于这个值，我们人眼就能感觉出来卡顿。
对于人的听觉而言，正常的听觉频率范围在20Hz-20kHz,根据奎斯特采样理论，为了保证音频不失真，我们的采样频率应该在40kHz左右。为什么采样率不是越高越好呢，因为采样率越高意味着你传输的数据量越多，这样给编码和传输都带了极大的负担，成本也是个重要考虑因素。
帧率
帧率就是每秒显示的帧数，比如30fps就是1秒显示30帧图像。但是对于音频可能理解帧率不太好理解，这有点抽象。对于音频，不同的编码方式比如AAC和mp3分别就规定1024采样sample，mp3每帧为1152采样，如果一个采样用一个字节表示，那就是1024字节AAC编码音频为一帧，1152字节为MP3编码方式的音频一帧。
时间戳单位
前面我们提到采样率，感觉到采样率是个很大的单位，一般标准的音频AAC采样率达到了44kHz,视频采样率也规定在90000Hz.所以我们衡量时间的单位不能再是秒，毫秒这种真实的时间单位，我们的单位应该转换为采样率，也就是一个采样的时间为音视频的时间单位，这就是时间戳的真实值。当我们要播放和控制时，我们再将时间戳根据采样率转换为真实的时间即可。
一句话，时间戳不是真实的时间是采样次数。比如时间戳是160，我们不能认为是160秒或者160毫秒，应该是160个采样。要换算真实时间，我们必须知道采样率，比如8000，那么说明1秒被划分成8000分之一，如果你要明确160个采样占用的时间，则160*(1/8000)即可，即20毫秒。
时间戳增量
就是一帧图像和另外一帧图像之间的时间戳差值，或者一帧音频和一帧音频的时间戳差值。同理时间戳增量也是采样个数的差值不是真实时间差值，还是要根据采样率才能换算成真实时间。
所以对于视频和音频的时间戳计算要一定明确帧率是多少，采样率是多少。
比如视频而言，帧率25，那么对于90000的采样率来说，一帧占用的采样数就是90000/25也就是3600，说明每帧图像的时间戳增量应该是3600，换算成实际时间就是3600*（1/90000）=0.04秒=40毫秒，这也和1/25=0.04秒=40毫秒一致。
对于AAC音频，一帧1024个采样，采样频率是44kHz,所以一帧的播放时间应该是1024*（1/44100）=0.0232秒=23.22毫秒。
同步方法：
上面说了时间戳重要的功能就是来为了音视频的同步，那么这个时间戳到底是如何让音视频同步的呢？
播放器本地需要建立一个系统时钟，这个时钟一般是根据CPU时间计算出来的，当播放开始时时钟时间为0，时间戳决定了一帧解码和渲染的时刻。当播放开始，时钟时间会进行增加，播放器会用系统时钟和当前视频和音频的时间戳进行比较，如果音视频的时间戳小于当前系统时钟，那么就要晚点进行解码和渲染播放。
可以看到播放能否准确进行需要编码器打的时间戳必须精确，同时播放器端的系统时钟也精确，因为播放时要基于时间戳和这个系统时钟对数据流进行控制，也就是对数据块要根据时间戳来采取不同的处理方法。实际无论编码器还是本地播放器都不能非常精确，所以我们说固定帧率25，也有可能编码器一遍打24帧的现象出现。为了解决这个累计误差问题，一般我们需要在播放端有一套反馈机制，能够消除这种误差。其实，同步是一个动态的过程，是一个有人等待、有人追赶的过程。同步只是暂时的，而不同步才是常态。人们总是在同步的水平线上振荡波动，但不会偏离这条基线太远。