Android Multimedia框架总结(五)多媒体基础概念

http://blog.csdn.net/hejjunlin/article/details/52431887

上篇中介绍了MediaPlayer从prepare到playback的其他过程,但是很多的一些音视频的基础概念可能还不是很清楚,今天将介绍下对于多媒体开发时,常常有一些基本概念。看下今天的Agenda:

  • 对杂而乱的概念进行归类
  • 视频部分相关
  • 音频部分相关

先看一张图,这样常常在说的,是否真的了解它们真实含义:

对杂而乱的概念进行归类

  • 视频分辨率

    • 标清、高清、720P…
    • 标清:意思就是“标准清晰度”,是物理分辨率在720p以下的视频格式。所谓标清,英文为“Standard Definition”,是物理分辨率在1280P*720P以下的一种视频格式,是指视频的垂直分辨率为720线逐行扫描。具体的说,是指分辨率在400线左右的VCD、DVD、电视节目等“标清”视频格式,即标准清晰度。
    • 高清:而物理分辨率达到720p以上的格式则称作为高清,英文表述High Definition,简称HD。作为“高清”的入门级标准,720p是指视频的垂直分辨率为720线逐行扫描,也就是说电视的屏幕必须能够同时、完整地显示720条横线。如果用显示器中常见的分辨率A×B的形式来表示,则720p的分辨率至少必须是1280×720,此外常见的1280×1024、1280×768、1280×800等分辨率也都支持720p高清格式。反过来再看标清的分辨率,我们经常接触到的是640×480、720×576或者800×600这些分辨率,它们在垂直分辨率上都不到720线,因此不属于“高清”范畴。那么,是不是只要垂直分辨率达到720线,就能称为高清呢?答案是否定的。关于高清的标准,国际上公认的有两条:视频垂直分辨率超过720p或1080i(p代表逐行扫描,i代表隔行扫描,这个概念和CRT电视基本相同),同时视频宽纵比为16:9。对于垂直分辨率我们已经有了直观的认识,而所谓宽纵比,其实就是视频画面的“长宽比”,如果用一个矩形来表示,那么它的长和宽的比例必须符合16:9——也就是我们俗称的“宽屏”或者“宽银幕”。按照这个比例推算,则720p的分辨率至少为1280×720,这样才符合16:9的要求,因此这也就是720p的标准分辨率。
    • 看最后总结:其实“高清”和“标清”不能简单的比较,它们只是二种不同的视频格式,它们都可以装载各种不同质量的视频信号,因此实际质量与所装载的视频信号质量有很大的关系,这相当于用水缸和茶杯装水,水缸可以装一大缸水,也可以只装一杯水,当只装一杯水的时候就不能说它装的水比茶杯中的一杯水要多了。
  • 视频编码
    • H.264、H.265…
    • H.264: 是MPEG-4(MPEG-4是MPEG格式的一个压缩标准)第十部分,是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT,Joint Video Team)提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC(或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC)而明确的说明它两方面的开发者。
    • H.264优点:

      1.低码率(Low Bit Rate):和MPEG2和MPEG4 ASP等压缩技术相比,在同等图像质量下,采用H.264技术压缩后的数据量只有MPEG2的1/8,MPEG4的1/3。

      2.高质量的图像:H.264能提供连续、流畅的高质量图像(DVD质量)。

      3.容错能力强:H.264提供了解决在不稳定网络环境下容易发生的丢包等错误的必要工具。

      4.网络适应性强:H.264提供了网络抽象层(Network Abstraction Layer),使得H.264的文件能容易地在不同网络上传输(例如互联网,CDMA,GPRS,WCDMA,CDMA2000等)。

      H.264最大的优势是具有很高的数据压缩比率,在同等图像质量的条件下,H.264的压缩比是MPEG-2的2倍以上,是MPEG-4的1.5~2倍。举个例子,原始文件的大小如果为88GB,采用MPEG-2压缩标准压缩后变成3.5GB,压缩比为25∶1,而采用H.264压缩标准压缩后变为879MB,从88GB到879MB,H.264的压缩比达到惊人的102∶1。低码率(Low Bit Rate)对H.264的高的压缩比起到了重要的作用,和MPEG-2和MPEG-4 ASP等压缩技术相比,H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是,H.264在具有高压缩比的同时还拥有高质量流畅的图像,正因为如此,经过H.264压缩的视频数据,在网络传输过程中所需要的带宽更少,也更加经济。

    • H.265: H.265是ITU-T VCEG 继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264,保留原来的某些技术,同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系,达到最优化设置.
    • H.265特点:H.265旨在在有限带宽下传输更高质量的网络视频,仅需原先的一半带宽即可播放相同质量的视频。这也意味着,我们的智能手机、平板机等移动设备将能够直接在线播放1080p的全高清视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。
    • 附一张视频编码发展时间图:
  • 音频编码
    • AAC、MP3、AC3…
    • AAC: 一种专为声音数据设计的文件压缩格式,与MP3不同,它采用了全新的算法进行编码,更加高效,具有更高的“性价比”。利用AAC格式,可使人感觉声音质量没有明显降低的前提下,更加小巧。苹果ipod、诺基亚手机也支持AAC格式的音频文件。

      AAC优点:相对于mp3,AAC格式的音质更佳,文件更小。

      AAC不足:AAC属于有损压缩的格式,与时下流行的APE、FLAC等无损格式相比音质存在“本质上”的差距。加之,传输速度更快的USB3.0和16G以上大容量MP3正在加速普及,也使得AAC头上“小巧”的光环不复存在了。

    • MP3: MP3是一种音频压缩技术,其全称是动态影像专家压缩标准音频层面3(Moving Picture Experts Group Audio Layer III),简称为MP3。它被设计用来大幅度地降低音频数据量。利用 MPEG Audio Layer 3 的技术,将音乐以1:10 甚至 1:12 的压缩率,压缩成容量较小的文件,而对于大多数用户来说重放的音质与最初的不压缩音频相比没有明显的下降。
    • MP3特点:MP3是利用人耳对高频声音信号不敏感的特性,将时域波形信号转换成频域信号,并划分成多个频段,对不同的频段使用不同的压缩率,对高频加大压缩比(甚至忽略信号)对低频信号使用小压缩比,保证信号不失真。这样一来就相当于抛弃人耳基本听不到的高频声音,[1] 只保留能听到的低频部分,从而将声音用1∶10甚至1∶12的压缩率压缩。由于这种压缩方式的全称叫MPEG Audio Player3,所以人们把它简称为MP3。
  • 视频封装格式
    • TS、m3u8…

      经常说的TS流,或者说传一个m3u8地址过来,指的都是视频的封装格式。如果放到浏览器中请求时,就会写成一个流文件,可以打开看,里面就是传的播放视频的帧。也可以把视频封装成TS文件,然后用播放器进行播放。m3u8可以做多码率的适配,根据网络带宽,客户端会选择一个适合自己码率的文件进行播放,保证视频流的流畅。

  • 多媒体播放组件(Android)
    • MediaPlayer、MediaCodec、OMX、Stagefright
    • MediaPlayer:播放控制
    • MediaCodec: 音视频编解码
    • OMX:多媒体部分采用的编解码标准
    • Stagefright:一个框架,替代之前的opencore,主要是做了一个OMX层,仅仅是对 opencore的omx-component部分做了引用。stagefright是在MediaPlayerService这一层加入的,和opencore是并列的。Stagefright在 Android中是以shared library的形式存在(libstagefright.so),其中的module – AwesomePlayer可用来播放video/audio。 AwesomePlayer提供许多API,可以让上层的应用程序(Java/JNI)来调用。(后面文章会详细介绍这个框架)
  • … …

视频部分相关

  • 分辨率

    • 一帧视频的大小,表示长宽像素个数(720x576, 1280x720, 1920x1080 …)
    • 屏幕图像的精密度,是指一帧视频图像所能显示的像素有多少。由于屏幕上的点、线和面都是由像素组成的,可显示的像素越多,画面就越精细,同样的屏幕区域内能显示的信息也越多,所以分辨率是个非常重要的性能指标之一。可以把整个图像想象成是一个大型的棋盘,而分辨率的表示方式就是所有经线和纬线交叉点的数目。显示分辨率一定的情况下,显示屏越小图像越清晰,反之,显示屏大小固定时,显示分辨率越高图像越清晰。
  • 帧率
    • 每秒钟视频帧数(24/25/30/48/60 FPS)
    • 由于人类眼睛的特殊生理结构,如果所看画面之帧率高于24的时候,就会认为是连贯的,此现象称之为视觉暂留。这也就是为什么电影胶片是一格一格拍摄出来,然后快速播放的。

      而对游戏,一般来说,第一人称射击游戏比较注重FPS的高低,如果FPS<30的话,游戏会显得不连贯。所以有一句有趣的话:“FPS(指FPS游戏)重在FPS(指帧率)。

    • 每秒的帧数(fps)或者说帧率表示图形处理器处理场时每秒钟能够更新的次数。高的帧率可以得到更流畅、更逼真的动画。一般来说30fps就是可以接受的,但是将性能提升至60fps则可以明显提升交互感和逼真感,但是一般来说超过75fps一般就不容易察觉到有明显的流畅度提升了。如果帧率超过屏幕刷新率只会浪费图形处理的能力,因为监视器不能以这么快的速度更新,这样超过刷新率的帧率就浪费掉了。
  • 刷新率
    • 刷新频率:即屏幕刷新的速度。
    • 刷新频率越低,图像闪烁、停顿和抖动的就越厉害,眼睛疲劳得就越快。

      采用70Hz以上的刷新频率时才能基本消除闪烁,显示器最好稳定工作在允许的最高频率下,一般是85Hz。

  • 编码格式
    • 编码:目的是压缩数据量,采用编码算法压缩冗余数据
    • MPEG(MPEG-2, MPEG-4)
    • H.26X(H.263, H.264/AVC, H.265/HEVC)
  • 封装格式
    • 把编码后的音、视频数据以一定格式封装到一个容器
    • MKV/AVI/TS …
  • 码率
    • 每秒钟视频数据的比特位数(bps)
    • 文件大小(b) = 码率(b/s) * 时长(s)
  • 画质 vs 码率
    • 码率越大,画质越好,视频越流畅吗?(错)
    • 视频质量和码率、编码算法都有关系

本文出自逆流的鱼yuiop:http://blog.csdn.net/hejjunlin/article/details/52431887

音频部分相关

  • 编码格式

    • 有损编码: AAC/MP3/AMR/WMA
    • 无损编码: WAV/FLAC/APE/ALAC
    • 补充:用无损编码压缩的数据是可以完全恢复的,解码后的数据一原始数据完全一致,压缩比较小;有损编码在编码过程中要丢失不易察觉的信息,且丢失的数据不可恢复,压缩比较大
  • 量化精度
    • 可以将模拟信号分成多少个等级,量化精度越高,音乐的声压振幅越接近原音乐.
    • 量化精度的单位是Bit,CD标准的量化精度是16Bit,DVD标准的量化精度是24Bit。
    • 也可理解为一个采样点用多少bit表示(8/16/24/32bit)
  • 采样率
    • 每秒钟音频采样点个数(8000/44100Hz)
    • 采样率单位用Hz(赫兹)表示
  • 声道数目
    • 立体声,5.1,7.1声道
    • 立体声:声音在录制过程中被分配到两个独立的声道,从而达到了很好的声音定位效果。这种技术在音乐欣赏中显得尤为有用,听众可以清晰地分辨出各种乐器来自的方向,从而使音乐更富想象力,更加接近于临场感受。立体声技术广泛运用于自Sound Blaster Pro以后的大量声卡,成为了影响深远的一个音频标准。
    • 5.1声道:其实5.1声音系统来源于4.1环绕,不同之处在于它增加了一个中置单元。这个中置单元负责传送低于80Hz的声音信号,在欣赏影片时有利于加强人声,把对话集中在整个声场的中部,以增加整体效果。杜比AC-3(Dolby Digital)、DTS等都是以5.1声音系统为技术蓝本的。相信每一个真正体验过Dolby AC-3音效的朋友都会为5.1声道所折服。现在广泛用于传统影院和家庭影院。
  • 音频帧
    • 一定数目的采样点数的集合
    • 编码: 基本编码单元
    • 举例: 音频帧的播放时间 = 一个AAC帧对应的采样样本的个数 / 采样频率(单位为s)。

      采样率(samplerate)为 44100Hz,表示每秒 44100个采样点,

      所以,根据公式,

      音频帧的播放时长 = 一个AAC帧对应的采样点个数 / 采样频率

      则,当前一帧的播放时间 = 1024 * 1000000/44100= 22.32ms(单位为ms)

      48kHz采样率:

      则,当前一帧的播放时间 = 1024 * 1000000/48000= 21.32ms(单位为ms)

      22.05kHz采样率:

      则,当前一帧的播放时间 = 1024 * 1000000/22050= 46.43ms(单位为ms)



第一时间获得博客更新提醒,以及更多android干货,源码分析,欢迎关注我的微信公众号,扫一扫下方二维码或者长按识别二维码,即可关注。

如果你觉得好,随手点赞,也是对笔者的肯定,也可以分享此公众号给你更多的人,原创不易

时间: 2024-11-07 20:07:54

Android Multimedia框架总结(五)多媒体基础概念的相关文章

Android Multimedia框架总结(六)C++中MediaPlayer的C/S架构

http://blog.csdn.net/hejjunlin/article/details/52435789 前面几节中,都是通过java层调用到jni中,jni向下到c++层并未介绍 看下Java层一个方法在c++层 MediaPlayer后续过程 frameworks/av/media/libmedia/MediaPlayer.cpp 找一个我们之前熟悉的setDataResource方法看下C/S模式的过程,亦可参考Android Multimedia框架总结(四)MediaPlayer

Android Multimedia框架总结(九)Stagefright框架之数据处理及到OMXCodec过程

转载请把头部出处链接和尾部二维码一起转载,本文出自逆流的鱼:http://blog.csdn.net/hejjunlin/article/details/52532085 不知不觉到第九篇了,感觉还有好多好多没有写,路漫漫其修远兮 ,吾将上下而求索,上篇主要介绍了Stagefright框架及AwesomePlayer的数据解析器,最后我们说道,涉及parse及decode部分,将在本篇中介绍,看下今天的Agenda: 两张图看数据走向 AwesomePlayer中prepare过程 Awesom

Android Multimedia框架总结(七)C++中MediaPlayer的C/S架构补充及MediaService介绍

http://blog.csdn.net/hejjunlin/article/details/52465168 前面一篇主要介绍c++中MediaPlayer的C/S架构中和Client相关部分,并中间穿插了mediaplayerservice的部分.但是对于这块C/S部分,没有放大去分析.<Android Multimedia框架总结(四)MediaPlayer中从Java层到C++层类关系及prepare及之后其他过程>是从整体上看的,今天我们把这块C/S模型放大去看下.同样先看下Agen

Android Multimedia框架总结(十三)CodeC部分之OpenMAX框架初识及接口与适配层实现

转载请把头部出处链接和尾部二维码一起转载,本文出自逆流的鱼yuiop:http://blog.csdn.net/hejjunlin/article/details/52629598 前言:上篇中介绍OMX事件回调,从今天开始,走入Codec部分之OpenMAX框架里.看下今天的Agenda如下: 一张图回顾音视频同步 一张图看清OpenMAX在Android系统中位置 OpenMAX是什么 OpenMax IL简介 OpenMax IL结构 Android中OpenMax的使用情况 OpenMa

Android Multimedia框架总结(一)MediaPlayer介绍之状态图及生命周期

请尊重分享成果,转载请注明出处: http://blog.csdn.net/hejjunlin/article/details/52349221 前言:从本篇开始,将进入Multimedia框架,包含MediaPlayer, Camera, Surface, MediaRecord, 接下来几篇都是MediaPlayer相关.同样看下Agenda如下: MediaPlayer的状态图 Idle 状态 End 状态 Error 状态 Initialized状态 Prepared状态 Prepari

打造android ORM框架opendroid(五)——数据更新的实现

在上一篇博客<打造android ORM框架opendroid(四)--优雅的删除数据>中,我们介绍了opendroid是如何优雅的从数据库中删除数据的,也可以看到opendroid的设计是如此的简单,其实opendroid只是我作为兴趣或者说是抱着试试的态度写的,当然它肯定存在诸多不足,但是这并不影响我们去了解一个orm框架的流程. 废话不说了,下面进入主题,今天我选择去了解的是opendroid的update流程,其实,对于已经了解了delete操作的朋友们来说,今天的update流程肯定

Android Multimedia框架总结(二十五)MediaProjection实现手机截屏(无须root)

转载请把头部出处链接和尾部二维码一起转载,本文出自逆流的鱼yuiop:http://blog.csdn.net/hejjunlin/article/details/53966818 前言:一年半多以前,我们曾有个项目,要做一个截屏功能,当时负责调研的同事,答应了产品上这个功能,但开发一周后,发现,无法实现截取手机屏幕图像,须要root权限,才能做.因为最近研究MediaProjection,意外的发现,竟然无须root,可以轻松实现次功能.曾经被做不到的,如今做到了,很难相信此时的心情.看下今天

Android Multimedia框架总结(二十)MediaCodec状态周期及Codec与输入/输出Buffer过程(附实例)

转载请把头部出处链接和尾部二维码一起转载,本文出自逆流的鱼yuiop:http://blog.csdn.net/hejjunlin/article/details/53183718 前言:前面几节都是介绍Camera2相关,对于Camera2预览把图像显示在SurfaceView上,还有录像时,时时刷新当前图像区域.追溯到最早介绍的MediaPlayer播放视频,这些都离不开重要角色MediaCodec,今天介绍MediaCodec,看下Agenda: MediaCodec是什么? codec操

Android Multimedia框架总结(十四)Camera框架初识及自定义相机案例

转载请把头部出处链接和尾部二维码一起转载,本文出自逆流的鱼yuiop:http://blog.csdn.net/hejjunlin/article/details/52738492 前言:国庆节告一段落,又是新一月,上月主要是围绕MediaPlayer相关展开,从今天开始,开始分析多媒体框架中的Camera模块,看下今天的Agenda: Camera拍照 Camera录像 新API android.hardware.camera2 新旧API特点对比 Camera自定义相机 新API andro