[Audio and video processing] MP4 files cannot be played? Working principles of video playback and transcoding. Encapsulation, coding

Hi everyone, and welcome to the Stop Refactoring channel.

At the beginning of this issue, we will launch a brand new series: audio and video processing.

It will involve application scenarios such as live broadcast, audio and video transcoding, audio and video synthesis, and audio and video AI processing.

In this issue , we will start with the basics and introduce the working principles of audio and video files, live streaming playback, and transcoding .

This working principle is not as simple as the page flip animation, otherwise why the browser can play some MP4 files but not others?

At the same time, this working principle is also very important . It will be mentioned in almost all audio and video processing content in the follow-up. We will discuss it in this order:

1. The structure of the video file

2. The working principle of playback

3. Audio and video synchronization

4. How transcoding works

Structure of video files

A video file is generally composed of file information and audio and video data .

The specific structure of the video file varies with different packaging formats , and the packaging formats are .mp4, .avi, .flv, hls and so on.

For some streaming media protocols, such as rtmp, rtsp, http-flv, etc., they are actually encapsulation formats.

File information will record some information of the current video file for subsequent decompression of audio and video data.

The audio and video data is compressed data.

Generally, audio data and video data are interleavedly stored according to time sequence, but each small piece of audio data or video data is not necessarily an independent frame .

What needs to be added here is that audio and video files have the concept of tracks .

原则上,音频、视频轨道都可以是多个的,但一般的播放器只会播放一个视频轨道和一个音频轨道。当然,除了音频轨道、视频轨道,还可以有其他类型的轨道,如文字轨道等。

播放的工作原理

播放视频文件时,需要按顺序读取视频文件的一块块音视频数据,这个步骤叫解封装(demux)。

读出这些数据后并不能立刻播放,因为这些数据是压缩后的。

所以还需要还原成能显示的图像或音频采样才能播放,这个解压缩步骤叫做解码(decode)。

解码过程根据不同的编码格式不同而不同。

但一般编码格式都有对应的解码器程序,编码格式就是我们常听到的H264、H265、AAC这些。

封装格式决定的是视频文件的结构、音视频数据块的大小等。

编码格式决定的是音视频数据压缩的方式及算法。

所以为了得到能播放的图像或音频采样,需要经过解封装、解码两个步骤。

这里顺便一提,浏览器只能播放一部分MP4文件,是因为浏览器的音视频解码器是内嵌的,只能解压缩几种固定的编码格式。

这里补充说明一下,每一帧图像、音频采样本身也有自己的格式,图像会有YUV、RGB等图像格式,音频采样会有float等样本格式,但一般这些格式处理过程在音视频处理中是不需要特别关心的,因为编码解码时会自动处理这些。

音视频同步

那么音频和视频是如何同步的呢?

是时间戳

在视频文件的每一小块音视频数据中,一般都含有解码时间戳DTS、播放时间戳PTS。

解码时间戳DTS一般决定着视频文件中数据块的排列顺序,在解码时,解码器需要用到DTS。

在经过解封装、解码后,每一帧数据都会含有播放时间戳PTS ,播放器程序需要根据这个播放时间戳PTS切换图像或音频采样。

这些时间戳是相对时间,不一定都是从0开始,时间戳需要根据时间基换算才能得到具体时间。

时间基可以理解为把1秒分成多少份 如1/9000,就是把1秒分成9000份。

解码时间戳(DTS)和播放时间戳(PTS,不一定是相等的,如H264的B帧需要滞后解码,该解码时间戳(DTS)会大于播放时间戳(PTS)。

转码的工作原理

那么视频文件、直播流转码成高清流畅是怎么个过程呢?

其实就是在解封装、解码后,对每一帧图象、音频采样进行处理,如改变分辨率、采样率等。

之后再重新编码、重新封装就可以了。

当然,如果仅仅是想把视频文件从mp4变成flv文件,而不改变视频分辨率、编码格式等的话,可以解封装后直接重新封装

这样做会非常快,因为重新封装不需要重新处理图像、音频采样数据。

总结

以上是音视频文件播放、转码的工作原理,其实直播流转码、播放的过程也是一样的,只是封装格式不一样。

音视频文件的封装格式一般是MP4、AVI、FLV这些,直播流的协议一般是RTMP、RTSP,但是它们的编码格式都可以同为是H264、ACC。

本期只是介绍完整的转码过程。

也就是解封装>解码>处理>编码>封装这一过程。

至于分辨率、码率、GOP、单双声道、单个音视频帧等概念,将会在后续基础知识内容中介绍。

Guess you like

Origin blog.csdn.net/Daniel_Leung/article/details/128905976