视频编解码类型调查——抖音客户端

今天使用公司开发手机,调研一下当下很火的抖音客户端,其使用的视频编码类型。

在调研前,有个初步判断:

1.从抖音服务器推送到客户端的视频流要么是avc码流,要么是hevc码流(具体要视平台解码硬件支持情况,本地上传支持情况,云端再推来相应的码流)。

2.本地客户端,解码器选择有三个,手机平台提供硬件解码器、Android提供的解码器、抖音平台提供的解码器。

   2.1.其使用优先级为硬件解码器排首位,后面的选择则不太确定,视哪个解码效率更高使用哪个。

   2.2.有些手机不带相应的硬件解码器(例如,如果推来的是hevc的流,不是近几年出的手机的话,一般不带hevc硬件解码器),则必须使用软件解码方式。

          具体使用的是安卓提供的,还是使用抖音提供的,要看哪个解码速度更快。

3.有些视频做了保护而不能下载到本地,有办法获取视频吗?

   3.1.如果使用硬件解码器,则通过修改平台解码驱动源码,以替换平台解码库方式,可以拿到视频码流。

   3.2.如果走Android提供的DRM方式,对这种没用过,很可能无法拿到。

   3.3.如果走抖音提供的解码器,无法直接拿到码流,一种比较低效的方式是,解码后送平台显示模块,在显示模块拿yuv图(其实3.2也可以这么干)。

   3.4.另外一种方式是:拦截网卡收到的全部数据,根据hevc数据语法特征,对数据再进行再组装,但是这种非常费时费力。

4.平台带硬件解码器前提下,在java上层,解码是走MediaCodec方式还是走MediaPlayer方式?

   4.1.走MediaPlayer方式跟普通播放器没多大区别(一点区别是抖音不提供快进快退的seek功能)。

         因为MediaPlayer一般是播放本地视频使用,内部已经做了demux-decode-render很多细节功能,但是由于网络传来的流,这个需要抖音根据协议自己做音视频分离,因此可能不是走这种通路。但是也不好说,毕竟安卓也支持rtsp流播放。

   4.2.走MediaCodec的话,需要两个MediaCodec实例来分别解码音频和视频,然后java层获取到解码后的数据后分别送audio/video输出通路。

 

-----------------------------------------------------------------------------可爱的分割线-----------------------------------------------------------------------------------------

 

手机硬件情况:带avc和hevc硬件解码器。

测试结果:

1.播放了30多个短视频,一直出现平台的hevc解码log信息,因此目前节点上抖音视频都用上了h265(后来其他调查,发现不一定是265视频流,自己的苹果手机上传的视频,再下载下来,变成了264编码码流)。

2.只有一个手机,因自带硬件解码器,因此无法验证软解方式下,是使用安卓提供的还是抖音提供的。

3.有办法获得码流。因为看到无法“保存到本地”的视频,仍在使用平台硬件解码器解码。

4.从log中判断,使用了MediaCodec,未用MediaPlayer。

 

其他信息:

1.客户端的log路径在哪?用于出错时问题回溯。

logcat方式没找到(douyin、bytedance相关关键词),lib库中看到包含libalog.so,应该是log生成相关,由于去掉了符号表,只能用winhex看二进制数据,也没看到有用信息。

难道release版都把log关掉了?用户客户端出bug了,如何定位问题?

另外一种方式查找,如果本地写log文件,那么应该使用了一些fd,于是看到了:

 但是,不幸的是,下载这些log文件,看不到可识别的字符串信息,应该是log做过加密处理,不希望别人看到。

 

2.是否使用一些开源的东西?例如ffmpeg

使用了!通过其提供的库可以看到:

 使用了x264视频编码库、ffmpeg多媒体框架、fdk-aac音频编码库、libyuv图形转换库、tensorflow机器学习库等。

 

3.客户端包名:com.ss.android.ugc.aweme

21:35:14.776  4551  4551 D BluetoothMapAppObserver: The installed package is: com.ss.android.ugc.aweme

 

4.安装路径

08-29 21:34:59.502  4269  4313 D PackageManager: New package installed in /data/app/com.ss.android.ugc.aweme-mCkAz35nMlxyL_FLCfX72Q==

 

5.使用线程一览(太长就不贴全了):

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


一年前写了一个demo,用于生成几种标准的波形,如正弦波、方波、三角波。之前写的只有这几个功能:波形/通道/时长/频率的控制选择,这几天抽了些时间又加了增益控制功能。为了避免东西丢失或意外删除,特上传
wav文件格式作为一种常用的多媒体音频文件格式,其由MS在1991年8月在Windows 3.1上推出,文件扩展名为WAV,是WaveFom的简写。通常存储未压缩的pcm数据,也可存储压缩的pcm数据
mpeg2ts文件格式中有pcr和pts的概念,其代码含义如下: PCR(Program Clock Reference)——指示系统时钟本身的瞬时值的时间标签称为节目参考时钟标签(PCR)。 PTS
我的月经贴博客该更新了!!!已经有许多博文需要补了! 去年开始的jpeg解码项目,中间停止更新了大半年时间,上个月想起这事还没完工,就又做了更多兼容性和性能上的改进,目前终于接近尾声了。有需要参考的可
花了两天时间做了个h264裸流nal类型和frame类型检测的工具,已上传至github,有需要的自行下载(其中包含构建出来的可执行文件exe)。 1.NAL类型检测 nal类型检测非常容易,对照下表
随着工作业务的开展,对视频编解码的理解更加深入了一些,记录一些心得体会,以便后面回味。 某天突然有个好的想法略过心头,可以形象的向别人介绍视频编码和解码。 1.编解码像一场考试,编码就像做主观题,解码
承接昨天写的《JPEG软解码实现介绍》,今天介绍其使用方法和一些细节说明。 1.仓库下已经包含了几个jpeg文件,以方便直接校验。 2.使用命令分为两种模式。 一种是直接解码为yuv文件,另外一种是解
x264编码器,提供了两个demo来验证编码功能:一个是大而全的x264.c,另外一个是简洁版的example.c。 其中,前者demo,可以配置很多编码参数,但太冗长繁杂,对初学者不太友好。 后者d
本博文为概览性介绍。后面有空了再分几篇博文分别介绍所用到的技术细节。 1.编解码目标 编码和解码是个逆过程。jpeg编码的目的在于图形去冗余,进行数据压缩,解码的目的在于还原图像,使能够进行预览。 2
今天使用公司开发手机,调研一下当下很火的抖音客户端,其使用的视频编码类型。 在调研前,有个初步判断: 1.从抖音服务器推送到客户端的视频流要么是avc码流,要么是hevc码流(具体要视平台解码硬件支持
最近对抖音有点上瘾,经常看到这样的视频列表: 由于抖音平台的限制,用户最多只能上传60s的视频,因此分段为3个视频。而在视频列表的缩略图模式下,三个视频的封面恰好组合成一张图像。这种方式比较符合审美标
自己在学习h264的路上,欢迎讨论交流。 前段时间研究JM出品的h264编码器,代码实在看不下去,因此换了个角度来研究诸多算法——逆向方式(解码),本系列文章记录一些遇到的东西和思考。 1. JM介绍
h264裸码流,根据nalu_header可以知道类型,例如该帧是I帧,P帧/B帧。 例如,常见的0x65代表I帧,0x41代表非关键帧,即P帧或B帧,但是只根据nalu_header是无法区分P帧和