在具體的業務領域，你可以慢慢沉澱下來，用自己的努力和時間換來對領域知識的深入理解和積累，逐漸從一個開發小白走向最懂這個行業的專家。
– 無論什麼平臺，他們的學習曲線其實是類似的，都要經歷差不多如下的環節：
-
1.學習對應平臺的編程語言，如：C/C++，Java，Object C，Javascript 等
-
2.熟悉對應平臺提供的 API，如：UI 庫，網絡，文件，數據庫， 圖片處理，多媒體處理 等等
-
3.掌握平臺相關的特性、框架和原理，如：Windows 的 WINSOCK，ODBC，WPF 等，Unix 的設計哲學，Android 的四大組件，iOS 的 MVC 模式等等
-
4.通過具體的項目，熟悉和練手，達到可完成任意功能的開發.
– 音視頻幾個重要的環節:
1.錄製音視頻 AudioRecord/MediaRecord
2.視頻剪輯 mp4parser 或ffmpeg
3.音視頻編碼 aac&h264
4.上傳大文件 網絡框架,進度監聽,斷點續傳
5.流媒體傳輸 流媒體傳輸協議rtmp rtsp hls
6.音視頻解碼 aac&h264
7.渲染播放 MediaPlayer -
視頻組成：音頻 視頻 字幕。
封裝格式：MKV/WebM, AVI, MP4/MOV, MPEG-TS/PS (including basic EVO support), FLV, OGG, 以及其他ffmpeg支持的格式！
視頻編碼：H264, VC-1, MPEG-2, MPEG4-ASP (Divx/Xvid), VP8, MJPEG 等。
音頻編碼：AAC, AC3, DTS(-HD), TrueHD, MP3/MP2, Vorbis, LPCM 等。
字 幕：VOB, DVB Subs, PGS, SRT, SSA/ASS, Text
–對於多媒體開發入門及提升:(MPEG陣營和Google開源陣營)
1.首先，務必明確自己的目標和定位。用互聯網式的語言說，就是場景在哪裏、有什麼樣的痛點，最終學習/開發出的技術方案/軟件產品需要滿足哪些可量化的指標。我個人建議在入門階段不要過早聚焦在一個技術點上，而應該更多建立一個偏全局、偏框架性的概念理解。早早地手捧一份類似ISO/IEC 14496-10的大部頭生掰硬啃，收穫的可能只有心理上的高大上。不如先以外行心態、以給產品經理或者商務銷售講技術的心態，僅僅從通用性的邏輯層面來入門學習。把大象放進冰箱需要3步，那麼一個實時視頻聊天系統有哪幾個邏輯模塊呢？從一方好友開始呼叫、到雙方建立連接、開始數據通信直至最終會話終止，其間的協議交互和流程是怎樣的呢？不考慮具體的Codec實現及複雜的應用場景技術指標要求，就當是加強版的CS通信，比起某年初學socket API調用時的DEMO代碼如何？……由此一層層、一步步用自己熟悉的技術類比、反推和延伸，並逐步理解主要環節的實現原理及技術難點，最終能給自己明確一兩個點進行後續的深究挖掘，例如：徹底排查和理清實時通話中時延的原因並優化、尋找系統中能夠影響圖像質量的因素並進行優化等。
2.其次，針對一個具體的、“局部性”問題不妨以“庖丁解牛”“掘地三尺”的態度來對待。因爲音視頻技術有一定的數學基礎和較清晰的年代演進歷程，所以我個人非常主張追根溯源式的學習。例如我在公司內開設視頻壓縮原理的課程時，一定會先講一次圖像壓縮的課程。看似古老的JPEG壓縮框架，能夠非常直接地理解Spatial domain到Transform domain的意義、DCT頻帶數據特徵之於人類視覺的影響、量化及量化表的由來、變長字編碼的設計理念等等。這些技術環節構成了視頻壓縮的半壁江山，而且雖然歷經二十餘年的發展，很多環節不斷演進更迭，但其數學理論根基和工程設計理念得以傳承和延續。再略微進一步，體會下WebP和JPEG流程上的差異與改進，Intra prediction的設計理念與作用已然清晰。至此，視頻編碼框架下I frame的主幹流程躍然眼前；剩下的細節，比如Intra prediction如何從H.264/AVC的9種模式演變到HEVC的35種，雖是匠心不改、歷經雕琢、但可作爲錦上添花之物了。
3.再次，當一個個小的局部性問題逐個攻克後，就需要回歸全局性視角，對之前已有的結論和觀點再次推敲。多媒體項目產品中往往會遇到技術指標之間的衝突和矛盾，例如：開啓複雜的算法工具可以獲得更高的壓縮效率，即同等碼率下可以有更高的圖像清晰度，但在中低端設備上複雜度過高會導致編碼幀率上不來，嚴重時用戶甚至會覺得畫面有明顯的頓挫感、通話質量不好。如何在一對對矛盾中取得權衡，既需要對每個指標背後的技術原理有深刻的理解，同時更要求對整體業務需求和應用場景有所把控。懂得取捨、合理平衡，也是多媒體開發進階的必由之路。
4.最後，身處互聯網行業，自然要重視信息的交流。但我個人不建議白紙一張時就盲目交流，也對很多自媒體鼓吹的碎片化乾貨學習保留懷疑。我建議初學者在具備一定基礎後，帶着自己的理解、感悟和困惑去交流，切勿人云亦云、東施效顰，對所謂大公司的“成功案例”、“領先指標”最好在充分對比業務場景、成本投入、平臺差異、目標用戶羣等等因素後進行消化，併爲我所用。
–《視音頻基礎知識》包括下面內容：
1.視頻播放器原理
2.封裝 格式（MP4，RMVB，TS，FLV，AVI）
3.視頻編碼數據（H.264，MPEG2，VC-1）
4.音頻編碼數據（AAC，MP3，AC-3）
5.視頻像素數據（YUV420P，RGB）
6.音頻採樣數據（PCM）
– 2012,2013年總結：在視音頻技術道路上摸索- https://blog.csdn.net/leixiaohua1020/article/details/17851977
研究視頻質量評價的。做一個網絡視音頻方面的項目，需要研究網絡協議。究RTSP+RTP/RTCP這樣的流媒體協議。這樣的協議組合很適合IPTV系統。實際互聯網視頻分析。對一個未知領域的摸索 。找到開源的優秀的視音頻項目，花費了大量的時間。有實際應用價值的很多視音頻項目都是不開源的商業項目。FLV是互聯網上相當通用的封裝格式，H.264也是相當通用的視頻編碼標準。文章《100行代碼實現最簡單的基於FFMPEG+SDL的視頻播放器》。
爲了尋找互聯網視頻使用較多的協議，我做了很多的分析工作。比如說，用WireShark抓取正在播放的互聯網視頻的數據報。然後把數據報的內容取出來進行分析。在多次的嘗試之後，我發現：直播使用最多的是RTMP，主要因爲它可以實現無插件直播；點播使用最多的是HTTP，主要因爲它不丟包，而且節約服務器資源。基於HTTP的點播其實不用多學，因爲實際上它和下載文件差不多。直播的RTMP協議則是需要學習的。
RTMP大部分文章都是協議破解之類的文章。後來找到了協議規範。把libRTMP看一看。libRTMP差不多是我看的第一個視音頻工程內部的代碼了，通過查看libRTMP的源代碼，我漸漸的掌握了RTMP。
教室直播，學習的JavaEE，再結合新學的流媒體技術，自己設計前臺，後臺，各種界面；前臺用div + css + jQuery，後臺用Struts2 + Spring + Hibernate，流媒體技術採用RTMP相關技術，搞出了一個Demo。
用Eclipse + MinGW搭建了一個環境後就開始看起了FFMPEG的源代碼。FFMPEG不僅僅侷限於視頻解碼。事實上，它可以做和視音頻相關的方方面面的工作。掌握了它，基本上就掌握了視音頻處理技術了。互聯網視音頻的播放，碼流分析，圖像分析的系統。
視頻質量評價技術其實很重要，是衡量視頻好壞的關鍵技術。互聯網視頻技術，重點應該是質量評價。網絡，視頻，音頻，編解碼，質量評價。
– Android 音視頻開發入門指南- http://blog.51cto.com/ticktick/1956269
Android 音視頻從入門到提高 —— 任務列表》，如果你認真把所有任務都完成了，你一定會成爲音視頻人才招聘市場的香餑餑
- 在 Android 平臺繪製一張圖片，使用至少 3 種不同的 API，ImageView，SurfaceView，自定義 View
- 在 Android 平臺使用 AudioRecord 和 AudioTrack API 完成音頻 PCM 數據的採集和播放，並實現讀寫音頻 wav 文件
- 在 Android 平臺使用 Camera API 進行視頻的採集，分別使用 SurfaceView、TextureView 來預覽 Camera 數據，取到 NV21 的數據回調
- 學習 Android 平臺的 MediaExtractor 和 MediaMuxer API，知道如何解析和封裝 mp4 文件
- 學習 Android 平臺 OpenGL ES API，瞭解 OpenGL 開發的基本流程，使用 OpenGL 繪製一個三角形
- 學習 Android 平臺 OpenGL ES API，學習紋理繪製，能夠使用 OpenGL 顯示一張圖片
- 學習 MediaCodec API，完成音頻 AAC 硬編、硬解
- 學習 MediaCodec API，完成視頻 H.264 的硬編、硬解
- 串聯整個音視頻錄製流程，完成音視頻的採集、編碼、封包成 mp4 輸出
- 串聯整個音視頻播放流程，完成 mp4 的解析、音視頻的解碼、播放和渲染
- 進一步學習 OpenGL，瞭解如何實現視頻的剪裁、旋轉、水印、濾鏡，並學習 OpenGL 高級特性，如：VBO，VAO，FBO 等等
- 學習 Android 圖形圖像架構，能夠使用 GLSurfaceviw 繪製 Camera 預覽畫面
- 深入研究音視頻相關的網絡協議，如 rtmp，hls，以及封包格式，如：flv，mp4
- 深入學習一些音視頻領域的開源項目，如 webrtc，ffmpeg，ijkplayer，librtmp 等等
- 將 ffmpeg 庫移植到 Android 平臺，結合上面積累的經驗，編寫一款簡易的音視頻播放器
- 將 x264 庫移植到 Android 平臺，結合上面積累的經驗，完成視頻數據 H264 軟編功能
- 將 librtmp 庫移植到 Android 平臺，結合上面積累的經驗，完成 Android RTMP 推流功能
- 上面積累的經驗，做一款短視頻 APP，完成如：斷點拍攝、添加水印、本地轉碼、視頻剪輯、視頻拼接、MV 特效等功能
– 推薦的參考資料：
- 《雷霄驊的專欄》：http://blog.csdn.net/leixiaohua1020
- 《Android音頻開發》：http://ticktick.blog.51cto.com/823160/d-15
- 《FFMPEG Tips》：http://ticktick.blog.51cto.com/823160/d-17
- 《Learn OpenGL 中文》：https://learnopengl-cn.readthedocs.io/zh/latest/
- 《Android Graphic 架構》：https://source.android.com/devices/graphics/
- 實時音視頻技術入門提綱- https://blog.csdn.net/GV7lZB0y87u7C/article/details/80523625
- 音視頻開發，就是要掌握圖像、音頻、視頻的基礎知識，並且學會採集、渲染、處理、傳輸等：
採集：它解決的是，數據從哪裏來的問題
渲染：它解決的是，數據怎麼展現的問題
處理：它解決的是，數據怎麼加工的問題
傳輸：它解決的是，數據怎麼共享的問題
- 音視頻第三方庫：
1）圖像處理：OpenGL，OpenCV，libyuv，ffmpeg 等；
2）視頻編解碼：x264，OpenH264，ffmpeg 等；
3）音頻處理：speexdsp，ffmpeg 等；
4）音頻編解碼：libfaac，opus，speex，ffmpeg 等。
源碼庫：kxMovie，GPUImage，FFmpeg，WebRTC，lame
-研究音視頻傳輸，其實就是在研究協議，具體有哪些協議呢 ？
1）音視頻在傳輸前，怎麼打包的，如：FLV，ts，mpeg4 等；
2）直播推流，有哪些常見的協議，如：RTMP，RSTP 等；
3）直播拉流，有哪些常見的協議，如：RTMP，HLS，HDL，RTSP 等；
4）基於 UDP 的協議有哪些？如：RTP/RTCP，QUIC 等。
進階研究
movie player for iOS using ffmpeg- https://github.com/kolyvan/kxmovie
騰訊音視頻實驗室：基於音視頻細分場景的技術創新探索- https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/79276611
直面音視頻質量評估之痛——走進騰訊音視頻質量體系- http://www.infoq.com/cn/presentations/enter-tencent-audio-and-video-quality-system
視頻推薦中用戶興趣建模、識別的挑戰和解法- http://www.infoq.com/cn/presentations/user-interest-modeling-and-recognition-in-video-recommendation?
utm_source=infoq&utm_medium=videos_homepage&utm_campaign=videos_row1
騰訊視頻全網清晰度提升攻堅戰- https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/80603661
多媒體技術領域，國家多媒體軟件工程技術研究中心-http://multimedia.whu.edu.cn/index.php?m=content&c=index&a=show&catid=123&id=89
– 視頻編碼解碼器流程概述：
1.編碼
(1)打開視頻文件,獲得視頻流；
(2)從視頻流中解包得到幀；
(3)幀不完整，重複從視頻流中取；
(4)某些情況下需要將RGB格式的顏色空間轉換到YUV格式的；
(5)對幀進行編碼工作，也就是壓縮的過程；
(6)重複第二步；
2.解碼
(1)打開視頻文件,獲得視頻流；
(2)從視頻流中解包得到幀；
(3)幀不完整，重複從視頻流中取；
(4)對幀進行解碼工作；
(5)某些情況下需要將YUV格式的顏色空間轉換到RGB格式；
(6)通過顯示設備顯示到顯示器上；
(7)重複第二步；
3.編碼器的核心爲編碼，解碼器的核心在解碼，二者是一個互爲可逆的過程。
– 音視頻中的數據
– 1.碼流/每一幀中的哪些信息值得關注 ？
[ ] 是否包含：音頻、視頻；
[ ] 碼流的封裝格式；
[ ] 視頻的編碼格式；
[ ] 音頻的編碼格式；
[ ] 視頻的分辨率、幀率、碼率；
[ ] 音頻的採樣率、位寬、通道數；
[ ] 碼流的總時長；
[ ] 其他 Metadata 信息，如作者、日期等；
[ ] 音頻幀還是視頻幀；
[ ] 關鍵幀還是非關鍵幀；
[ ] 幀的數據和大小；
[ ] 時間戳信息；
2.爲什麼需要拿到這些信息 ？
[ ] 碼流的封裝格式 -> 解封裝；
[ ] 音頻、視頻的編碼格式 -> 初始化解碼器；
[ ] 視頻的分辨率、幀率、碼率 -> 視頻的渲染；
[ ] 音頻的採樣率、位寬、通道數 -> 初始化音頻播放器；
[ ] 碼流的總時長 -> 展示、拖動；
[ ] 其他 Metadata 信息 -> 展示；
[ ] 音頻幀還是視頻幀 -> 分別送入音頻/視頻解碼器；
[ ] 關鍵幀還是非關鍵幀 -> 追幀優化；
[ ] 幀的數據和大小 -> 取出幀的內容；
[ ] 時間戳信息 -> 音視頻同步；
– 音視頻產品典型的場景
音視頻產品往往需要權衡和取捨，以爭取到端到端的整體表現和用戶體驗。以下有3個典型的場景舉例：
1）點對點視頻聊天、視頻會議場景。這類用戶場景對時延的要求很高，以至於傳輸協議很多時候是基於UDP的私有協議。甚至可以說，時延以及圖像聲音的連續性就決定了用戶體驗，而單幀圖像的分辨率、紋理細膩度等，應該讓位給前者。換言之，Codec的壓縮率可以作出一定程度犧牲。因爲可以預期的是，我們輸入的圖像分辨率不會太大、目標輸出碼率也不會太高，所以我們可以選擇baseline方案、關閉B Frame類型、限制P Frame的參考範圍等等。這種場景下，對Codec的更大期望，反而是追求輸出碼率的平穩，儘量避免發送數據量的陡變。
2）個人直播、典型的1 vs. N場景。這類應用對時延的要求相比會議應用要寬鬆不少，協議側往往使用RTMP推流(主播端)和HTTP FLV/HLS播放(觀衆端)。顯然，用戶對圖像質量有了較高的期望，圖像分辨率和碼率會向高位傾斜。此時的Codec應該盡力迎合質量的要求，提升壓縮率、提升寶貴的上行帶寬利用率，但需要留意的底線是Codec編碼效率切勿直接造成(發送端)幀率低下、或者碼流輸出的嚴重滯後。如上文所言，我們需要建立和完善機型能力模型，另外APP內部具備不同檔位碼流切換的策略和能力。
3）拍攝類短視頻場景。嚴格意義上這個不算實時場景，但考慮拍攝環節所見即所得的用戶體驗要求，我也一併討論。這個場景下，對圖像質量的要求極高，拍攝階段需要儘可能快地響應用戶回看、編輯等操作，發表階段則一般是異步式的文件上傳，所以時延完全是個僞命題。重點說下拍攝階段的Codec要求，因爲圖像質量極高，所以按理應該極致追求壓縮率，但如此一來，幾乎必然影響用戶回看操作的響應時間。可行的方案是轉換思維，在拍攝階段儘可能快、且保留圖像細節，硬件Codec、高碼率、“粗糙”的壓縮算法配置爲先；等待拍攝完成後，再開啓複雜的Codec算法工具，作二次壓縮，提高壓縮率、保障發佈階段的上行效率。
– 音視頻容器中的視頻和音頻軌、字幕軌
平時看到的視頻文件有許多格式，比如 avi， mkv， rmvb， mov， mp4等等，這些被稱爲容器（Container）， 不同的容器格式規定了其中音視頻數據的組織方式（也包括其他數據，比如字幕等）。容器中一般會封裝有視頻和音頻軌，也稱爲視頻流（stream）和音頻流，播放視頻文件的第一步就是根據視頻文件的格式，解析（demux）出其中封裝的視頻流、音頻流以及字幕（如果有的話），解析的數據讀到包 （packet）中，每個包裏保存的是視頻幀（frame）或音頻幀，然後分別對視頻幀和音頻幀調用相應的解碼器（decoder）進行解碼， 比如使用 H.264編碼的視頻和MP3編碼的音頻，會相應的調用H.264解碼器和MP3解碼器，解碼之後得到的就是原始的圖像(YUV or RGB)和聲音(PCM)數據，然後根據同步好的時間將圖像顯示到屏幕上，將聲音輸出到聲卡，最終就是我們看到的視頻。
– 音視頻領域
包括基礎樂理知識；音頻的處理（音效處理，混音處理等），處理視頻，比如美顏、比如視頻合唱等；跨平臺的視頻處理系統（VideoEffectProcessor-基於OpenGL ES的跨平臺視頻幀處理系統），實現了美顏、貼紙以及視頻主題的功能；開發我了想和你唱的視頻、音頻聯動的玩法；直播產品線，從錄播做到直播；音頻直播 視頻直播；多媒體領域其實是很大的一個領域，包括但不限於採集、處理、編碼、傳輸，解碼，渲染等；比如傳輸，大家最常用的可能就是RTMP和HLS，而基於UDP的一些協議可能就會更加複雜一些，比如kcp、srt、rtp/rtcp；從人的生理感知能力來講，文字->圖片->語音->視頻->直播->實時交互，這是感知的層級遞進關係；秀場直播的連麥、PK，教育行業的一對一教學或者小班課的產品，遊戲行業狼人殺等實時互動的桌遊產品。
– 視頻功能
視頻上很容易就可以做到倍速播放，一般的視頻格式都是每秒固定的幀數，按比例跳幀就可以了。
音頻加速，把相鄰時鐘週期內的聲音電平信號取平均，或者用高斯平均值代替原信號，再精細點可以自適應地在音調信號比較豐富的地方設置比較高的權重來儘量少壓縮保持音色。
音視頻編碼時，音視頻同步；音視頻解碼時，音視頻同步。
– NV21，YUV，420SP，420P，NV21TOARGB，NV21TOYUV
YUV定義：分爲三個分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V” 表示的則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用於指定像素的顏色。
一般來說，直接採集到的視頻數據是RGB24的格式，RGB24一幀的大小size＝width×heigth×3 Bit，RGB32的size＝width×heigth×4，如果是I420（即YUV標準格式4：2：0）的數據量是 size＝width×heigth×1.5 Bit。 在採集到RGB24數據後，需要對這個格式的數據進行第一次壓縮。即將圖像的顏色空間由RGB2YUV。
YUV420有打包格式(Packed)，一如前文所述。同時還有平面格式(Planar)，即Y、U、V是分開存儲的，每個分量佔一塊地方，其中Y爲 width*height，而U、V合佔Y的一半，該種格式每個像素佔12比特。根據U、V的順序，分出2種格式，U前V後即YUV420P，也叫 I420，V前U後，叫YV12(YV表示Y後面跟着V，12表示12bit)。另外，還有一種半平面格式(Semi-planar)，即Y單獨佔一塊地 方，但其後U、V又緊挨着排在一起，根據U、V的順序，又有2種，U前V後叫NV12，在國內好像很多人叫它爲YUV420SP格式；V前U後叫 NV21。 對手機攝像頭採集的原始幀做Rotate或者Scale.
YCbCr不是一種絕對色彩空間，是YUV壓縮和偏移的版本。
Y（Luma，Luminance）視訊，也就是灰階值。UV 視作表示彩度的 C（Chrominance或Chroma）。主要的採樣（subsample）格式有YCbCr 4:2:0、YCbCr 4:2:2、YCbCr 4:1:1和 YCbCr 4:4:4。YUV的表示法稱爲 A:B:C 表示法：
- 4:4:4 表示完全取樣。
- 4:2:2 表示 2:1 的水平取樣，沒有垂直下采樣。
- 4:2:0 表示 2:1 的水平取樣，2:1 的垂直下采樣。
- 4:1:1 表示 4:1 的水平取樣，沒有垂直下采樣。
– IPB幀，DTS，PTS
I幀編碼是爲了減少空間域冗餘，P幀和B幀是爲了減少時間域冗餘。
GOP是由固定模式的一系列I幀、P幀、B幀組成。常用的結構由15個幀組成，具有以下形式 IBBPBBPBBPBBPBB。GOP中各個幀的比例的選取和帶寬、圖像的質量要求有一定關係。例如因爲B幀的壓縮時間可能是I幀的三倍，所以對於計算 能力不強的某些實時系統，可能需要減少B幀的比例。
DTS：Decoding Time stamp 解碼時間戳 ;
PTS: Presentation Time Stamp 顯示時間戳
– 對於語音採樣：
8,000 Hz - 電話所用採樣率, 對於人的說話已經足夠
11,025 Hz
22,050 Hz - 無線電廣播所用採樣率
32,000 Hz - miniDV 數碼視頻 camcorder、DAT (LP mode)所用採樣率
44,100 Hz - 音頻 CD, 也常用於 MPEG-1 音頻（VCD, SVCD, MP3）所用採樣率
47,250 Hz - Nippon Columbia (Denon)開發的世界上第一個商用 PCM 錄音機所用採樣率
48,000 Hz - miniDV、數字電視、DVD、DAT、電影和專業音頻所用的數字聲音所用採樣率
50,000 Hz - 二十世紀七十年代後期出現的 3M 和 Soundstream 開發的第一款商用數字錄音機所用採樣率
50,400 Hz - 三菱 X-80 數字錄音機所用所用採樣率
96,000 或者 192,000 Hz - DVD-Audio、一些 LPCM DVD 音軌、Blu-ray Disc（藍光盤）音軌、和 HD-DVD （高清晰度 DVD）音軌所用所用採樣率
2.8224 MHz - SACD、 索尼 和 飛利浦 聯合開發的稱爲 Direct Stream Digital 的 1 位 sigma-delta modulation 過程所用採樣率。
50 Hz - PAL 視頻
60 / 1.001 Hz - NTSC 視頻
13.5 MHz - CCIR 601、D1 video
– MPEG到目前爲止已經制定並正在制定以下和視頻相關的標準：
MPEG-1： 第一個官方的視訊音訊壓縮標準，隨後在Video CD中被採用，其中的音訊壓縮的第三級（MPEG-1 Layer 3）簡稱MP3， 成爲比較流行的音訊壓縮格式。
MPEG-2： 廣播質量的視訊、音訊和傳輸協議。被用於無線數位電視-ATSC、DVB以及ISDB、數字衛星電視（例如DirecTV）、 數字有線電視信號，以及DVD視頻光盤技術中。
MPEG-3： 原本目標是爲高解析度電視（HDTV）設計，隨後發現MPEG-2已足夠HDTV應用，故 MPEG-3的研發便中止。
MPEG- 4：2003 年發佈的視訊壓縮標準，主要是擴展MPEG-1、MPEG-2等標準以支援視訊／音訊物件（video/audio “objects”）的編碼、3D內容、低位元率編碼（low bitrate encoding）和數位版權管理（Digital Rights Management），其中第10部分由ISO/IEC和ITU-T聯合發佈，稱爲H.264/MPEG-4 Part 10。參見H.264。
MPEG-7：MPEG-7並不是一個視訊壓縮標準，它是一個多媒體內容的描述標準。
MPEG-21：MPEG-21是一個正在制定中的標準，它的目標是爲未來多媒體的應用提供一個完整的平臺。
在MPEG-4制定之前，MPEG-1、MPEG-2、H.261、H.263都是採用第一代壓縮編碼技術，着 眼於圖像信號的統計特性來設計編碼器，屬於波形編碼的範疇。第一代壓縮編碼方案把視頻序列按時間先後分爲一系列幀，每一幀圖像又分成宏塊以進行運動補償和編碼，這種編碼方案存在以下缺陷：
1.將圖像固定地分成相同大小的塊，在高壓縮比的情況下會出現嚴重的塊效應，即馬賽克效應；
2.不能對圖像內容進行訪問、編輯和回放等操作；
3.未充分利用人類視覺系統（HVS，Human Visual System）的特性。
MPEG-4則代表了基於模型/對象的第二代壓縮編碼技術，它充分利用了人眼視覺特性，抓住了圖像信息傳輸的本質，從輪廓、紋理思路出發，支持基於視覺內容的交互功能，這適應了多媒體信息的應用由播放型轉向基於內容的訪問、檢索及操作的發展趨勢。
MPEG-4實現基於內容交互的首要任務就是把視頻/圖像分割成不同對象或者把運動對象從背景中分離出來，然後針對不同對象採用相應編碼方法，以實現高效壓縮。因此視頻對象提取即視頻對象分割，是MPEG-4視頻編碼的關鍵技術，也是新一代視頻編碼的研究熱點和難點。
音視頻同步通訊SDK源碼包分享：Android：http://down.51cto.com/data/711001