飞凌嵌入式
直播中

dutong0321

3年用户 697经验值
擅长:模拟技术 嵌入式技术 接口/总线/驱动 光电显示 控制/MCU RF/无线
私信 关注
[技术]

【飞凌嵌入式OK3588J-C开发板体验】OK3588J-C开发板的ffmpeg编解码、HDMI输入及编码

在上篇报告中,我们烧写好了开发板,并且简单的测试了一下qt、ffmpeg以及板子的芯片、内存和存储。接下来,我们先将板子的软件源更新一下。

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
sudo sed -i 's/http:\/\/ports.ubuntu.com/http:\/\/mirrors.aliyun.com/g' /etc/apt/sources.list
sudo update
sudo upgrade

如果不想更新,其实速度也还可以基本在10兆左右,但是如果换成阿里云的话,速度甚至可以达到百兆,还是建议想换的更换一下哈!

测试ffmpeg的编解码

想要测试ffmpeg的话,我们需要先往里放一个视频,视频信息如下,是我刚刚转换的一个1080P的50帧33秒的视频,使用的编码器是H264的。
10200.png

在上传到开发板里面,然后我们再使用ffprobe来查看一下具体的媒体信息。
10201.png

我们首先使用最不带参数的转换命令试一下:

ffmpeg -i video.mp4 test1.mp4

执行完毕的截图如下:
10203.png

可以看到默认的调用的编码器是软解的libx264编码器,转换速度是0.53x,要知道这个速度已经很厉害了,我们在使用11代I5处理器进行处理时,也只能做到1.1x的转换速度。虽然开发板的CPU的确是非常厉害,但是如果我们进行直播的话,编码速度至少需要做到1x的速度才可以保证直播的流畅,包括使用RTSP进行拉流,也是一样的。
10202.png

上面这张截图就是正在运行时htop的截图,可以看到8个核心基本上都跑满了,CPU占用也基本是百分百。

接下来我们换一个命令执行。

ffmpeg -i video.mp4 -vcodec h264_rkmpp test2.mp4

然后我们看一下这次的截图,可以看到这次使用的是rkmpp的编码器,速度也达到了非常厉害的5.77x的速度了。

10205.png

我们再次打开htop的截图:
10204.png

可以看到这次的CPU也降下来许多,达到了5.77x的速度,也可以保证图像的传输已经没有任何的问题了。

但是,这不是3588开发板的极限,我们换一条命令试试:

ffmpeg -vcodec h264_rkmpp -i video.mp4 -vcodec h264_rkmpp test3.mp4

然后,我们就可以看到速度达到了更加恐怖的9.08x的速度。

10207.png

同时,我们再打开htop的截图,可以看到CPU的占用更加少了,基本上只有一个核心差不多快跑满了,其他核心正在摸鱼当中,当然CPU摸鱼是好事,说明我们系统运行起来有更多的空间。

10206.png

CPU的占用不多说明RK3588的强大,而编码的速度快说明RK3588的编解码能力强,接下来先探讨一下为什么三条命令相差的这么多呢?

首先先说第一条命令,第一条命令是什么参数都没指定,那么ffmpeg默认将会使用软解码软编码,也就是解码编码都会使用CPU来进行,众所周知,解码已经很占用CPU了,但是编码比解码占用CPU更加厉害的多!

接下来说第二条命令,第二条命令指定了编码器使用h264_rkmpp,这就是使用的瑞芯微的H264硬编码进行的,虽然速度上来了,但是可以看到CPU占用率还是不低,这不仅仅是因为解码所占用了CPU,而且还需要把CPU解码后每一帧从内存当中传送到显存当中才可以进行硬编码器进行编码。

所以,我们最后一条命令使用的是硬解码硬编码,这样不仅仅解码编码不占用CPU了,而且也可以保证解码后的帧直接就在显存当中然后就直接进行编码了,CPU的占用率就更加低了,只进行控制就好了,所以就可以看到只有一个核心占用,而不是像上面的两个命令需要多线程进行编解码!

可以看到飞凌给我们提供的ffmpeg已经兼容性特别好了,而RK3588的性能无论是速度还是编解码能力都是属于非常强大的了!

HDMI的输入及编码

在上一篇报告中曾提到板子拥有两个HDMI的输入接口,一个是用来输出的,另一个是用来输入的,所以需要先把电脑的HDMI接口连接到板子的HDMI输入接口上面,然后我们打开电脑的设置界面。
10208.png

可以看到第2个屏幕也显示出来了,屏幕的分辨率是1920x1080。

10209.png

我们先使用v4l2命令来查看一下HDMI设备挂载到系统的什么位置了

v4l2-ctl --list-devices

可以看到rk_hdmirx (fdee0000.hdmirx-controller)挂载到了/dev/video73上面。

10210.png

然后我们再输入命令来查看一下HDMI的视频信息:

v4l2-ctl -d /dev/video73 --get-dv-timings

可以看到分辨率也是1920x1080,帧率也是60帧,与电脑输出是相同的!

10211.png

然后我们再使用命令来查看一下HDMI的视频信息。

v4l2-ctl -d /dev/video73  -V

可以看到默认的pixel format是RGB3之类相关的视频信息。

10212.png

上面使用的命令都是v4l2来查看信息的,但是我们要使用ffmpeg来进行编码的话,需要使用ffmpeg命令来查看一下!

ffmpeg -f v4l2 -list_formats all -i /dev/video73

可以查看到,我们已经获取到了HDMI输入的信息,该HDMI支持输出的pixel format有BGR24/NV24/NV16/NV12,这个地方其实如果经常玩视频的都知道属于是帧格式,比如BGR24指的是每个像素点以黑绿红的方式每种颜色都是以8位来存储的,也就是一个像素点占3个字节,但是这种保存方式是比较占空间的,假设1秒50帧的1920x1080的视频那么久占用了50x1920x1080x3这么多空间,所以又开发了一种YUV格式,Y 表示明亮度,而 U 和 V 表示色度,使用这种方式的优点是因为人眼的视觉特点是对亮度更敏感,对位置、色彩相对来说不敏感,所以Y占用更多的存储,而UV则占用更少的存储,比如YUV420这种格式则代表Y占用1Byte,而UV两个也只占用半Byte,我们经常使用的H.264也是需要把YUV格式的图像进行编解码的,这块可能我的讲解不太好,大家可以看看雷神的文章,我就不贴连接了。

但是我们可以看到它支持的格式里并没有YUV格式,只有NV格式,其实NV格式与YUV格式是相同的,只不过他们对YUV的存储方法是不同的,一般来讲软编解码NV格式和YUV格式都支持,但是硬编码一般是只支持NV格式的,这HDMI输入格式刚好使用NV格式,我们使用硬编码的时候可以说是刚刚好。

10213.png

那么接下来使用ffmpeg来对HDMI输入进行编码。

ffmpeg -f v4l2 -pixel_format nv12 -i /dev/video73 -vcodec h264_rkmpp -an test4.mp4

我们编码一段后,按q就可以退出了,在编码时使用htop来查看CPU占用率。
10214.png

可以看到CPU的占用率也非常低。
10215.png

然后我们使用ffprobe命令来查看生成的信息,可以看到帧率、分辨率和编码器信息。

10216.png

我们在windows里使用PotPlayer打开文件就可以看到视频了,可以看到RKMPP编码后的视频依旧是非常的清晰!

更多回帖

发帖
×
20
完善资料,
赚取积分