Android视频录制
視屏錄制 播放分二種方式
Demo實例：https://download.csdn.net/download/weixin_41956752/10692732
一:?
通過Intent的方式：Intent intent = new Intent(MediaStore.ACTION_VIDEO_CAPTURE);
二：
使用Camera的API，調用Media的MediaRecorder。
?
首先第一種：
Intent的方式
注意：這里播放camera錄制的視頻使用VideoView，不使用MediaPlayer和SurfaceView的結合。用幀布局Framelayout布局，VideoView和ImageView，播放時隱藏視頻縮略圖，暫停時或初始化時顯示視頻縮略圖。
因為VideoView沒有設置監聽播放和暫停狀態的事件，所以我自定義一個CustomVideoView繼承了VideoView，在里面創建一個監聽方法和重寫VideoView的播放、暫停的方法。
使用相機intent獲取視頻是使用最少代碼使得你的應用獲取視頻的捷徑．一個視頻獲取intent可以包含以下額外信息：
?
MediaStore.EXTRA_OUTPUT-此設置需要一個保存視頻的路徑和文件名的Uri．此設置是可選的但是強列推薦的．如果你不指定此值，相機應用就把請求到的圖像以默認的文件名保存到默認的文件夾下，這些信息保存在返回的intent的Intent.getData()字段中．
MediaStore.EXTRA_VIDEO_QUALITY-?此值在最低質量最小文件尺寸時是0，在最高質量最大文件尺寸時是１.
MediaStore.EXTRA_DURATION_LIMIT-?此值設置獲取視頻的長度，以秒為單位．
MediaStore.EXTRA_SIZE_LIMIT-?此值設置獲取視頻文件的大小，以字節為單位．
?
第二種：
?
方式二-MediaRecorder（中文：媒體記錄器）
注解：
SurfaceView（中文：曲面視圖）
Surfaceview是什么？
它擁有獨立的繪圖表面，即它不與其宿主窗口共享同一個繪圖表面。由于擁有獨立的繪圖表面，因此SurfaceView的UI就可以在一個獨立的線程中進行繪制。又由于不會占用主線程資源，SurfaceView一方面可以實現復雜而高效的UI，另一方面又不會導致用戶輸入得不到及時響應。
SurfaceHolder??用于控制SurfaceView???（getHolder()?//?獲得SurfaceHolder對象）
SurfaceHolder.Callback具有如下的接口：
surfaceCreated(SurfaceHolder holder)：
當Surface第一次創建后會立即調用該函數。程序可以在該函數中做些和繪制界面相關的初始化工作，一般情況下都是在另外的線程來繪制界面，所以不要在這個函數中繪制Surface。?
surfaceChanged(SurfaceHolder holder, int format, int width,int height)：
當Surface的狀態（大小和格式）發生變化的時候會調用該函數，在surfaceCreated調用后該函數至少會被調用一次。?
surfaceDestroyed(SurfaceHolder holder)：
當Surface被摧毀前會調用該函數，該函數被調用后就不能繼續使用Surface了，一般在該函數中來清理使用的資源。
SurfaceView和View的比較
1，SurfaceView和View最大的區別在于，surfaceView是在一個新起的單獨線程中可以重新繪制畫面而View必須在UI的主線程中更新畫面。
SurfaceView和View的使用場景
1 ，被動更新畫面的。比如棋類，這種用view就好了。因為畫面的更新是依賴于 onTouch 來更新，可以直接使用 invalidate。 因為這種情況下，這一次Touch和下一次的Touch需要的時間比較長些，不會產生影響。
2 ，主動更新。比如一個人在一直跑動。這就需要一個單獨的thread不停的重繪人的狀態，避免阻塞main UI thread。所以顯然view不合適，需要surfaceView來控制。
?
權限：
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
例子中先用mediarecorder錄制保存一個視頻然后播放看看效果，點擊“跳轉”可以調到第二個Main2Activity中，用VideoView播放剛才錄制的視頻，Main2Activity主要測試如何播放在本地手機的視頻。
?
查看網址：https://blog.csdn.net/u013742672/article/details/72457490
?
?
為什么要進行視屏壓縮？
視屏壓縮（去除掉原始數據中的一些冗余，然后再進行傳輸或者存儲，來減少對帶寬和存儲空間的需求）
假設用戶接入網帶寬為20M(在中國，有這種接入網帶寬的用戶很少吧？)，如果用戶想進行實時的視頻通信（比如說你想跟外地朋友進行視頻聊天），假設你使用的圖像分辨率為4CIF（704*576），幀頻為25f/s.如果不進行壓縮，大概需要多少呢？
每幅畫面的大小為：704*576*1.5*8 bit?= 4.64M，也就是說每一幀為4.64M。如果想看流暢的視頻畫面，大概每秒需要傳輸25幀，也即需要4.64*25M = 116M的帶寬??
也就是說如果不壓縮，20M的接入帶寬，連QQ聊天都做不了
me.?存儲和帶寬相對廉價的今天，要實現視頻的大容量存儲（如視頻監控）和實時傳輸，沒有視頻壓縮幾乎不可能。
視頻壓縮現狀：
視頻壓縮編碼標準種類繁多，其中ITU下主導的H.26x系列和ISO主導的MPEG系列影響最大，應用最為廣泛。早期，ITU下的H.26x主要應用于實時領域；ISO的MPEG系列(它包括音頻壓縮標準)主要應用于廣播電視，VCD(MPEG1)，DVD(MPEG2)存儲。ITU發展到H.264后，開始與ISO的MPEG4融合。被納入MPEG-4的第十部分
目前主流的壓縮標準為H.264/AVC。它在實時傳輸和存儲領域已經得到廣泛的應用。H.264于2003年正式發布，距今已經9年。我認為H.264標準未來5年還是視頻應用主力。其在IPTV，視頻監控，視頻會議，和光盤存儲中將繼續占主導地位
?
視頻壓縮先進性評價：
網絡帶寬就是按每秒多少bit流來計算的，而存儲容量的最小單位為Byte，也就是字節(8bit)。存儲容量單位的1M表示1MB，等于網絡帶寬8Mb.
每秒大概數據量為593Mb。如果用戶帶寬為4Mb，想實現1080P?的實時會議或者監控，最少需要將原始視頻壓縮近593/4 = 150倍。
?
視頻壓縮算法發展的動力：
“一切動力來自人類的無窮欲望”
視頻業務發展的基礎：
視頻壓縮的核心思想就是利用視頻信號的特點，去除視頻信號的時間和空間冗余
從H.261到H.264，MPEG1到MPEG4??未來還有H.265等更為先進的算法出現
(1)算法本身的發展??(2)芯片能力??(3)網絡帶寬。這三者一起推動了當今高清視頻業務的普及，也是未來3D業務發展的技術基礎。
視頻會議壓縮算法之-H.264 High profile
AVC/H.264?規定了多種不同的Profile：最低Profile、主要Profile、擴展Profile、高端Profile（這些Profile?本身還要劃分數個等級）。
-最低Profile，也叫做底線Profile（Baseline Profile）支持I/P?幀，只支持無交錯（Progressive）和CAVLC；
-擴展Profile（Extended Profile）支持I/P/B/SP/SI?幀，只支持無交錯（Progressive）和CAVLC；
-主要Profile（Main Profile）提供I/P/B?幀，支持無交錯（Progressive）和交錯（Interlaced），同樣提供對于CAVLC和CABAC?的支持；
-高端Profile（High Profile）在主要Profile?的基礎上增加了8x8?內部預測、自定義量化、無損視頻編碼和更多的YUV?格式；
?
H.264中還有一個SVC概念(Scalable Video Coding)，可分層編碼
1.帶寬問題，IP網絡帶寬是不穩定的，網絡帶寬降低是，視頻流應該自動的降低碼率，以適應當前帶寬。而視頻流碼率的降低，并不意味著視頻通信的結束，只是其幀率和分辨率相應降低。這樣還是能維持基本的視頻通信如幀率可以從60fps降低30fps或者25fps甚至20pfs。分辨率可以從高清降到標清的4cif甚至cif。這樣可以很大程度的降到碼率，但同時保證了視頻通信的基本功能正常進行（用戶還是能看到能夠分辨的圖形和聽到清晰的聲音）。
2.在未來的通信中，參與視頻對話的終端多種多樣，有專用的硬件視頻終端，有桌面軟終端，還有移動終端中的PAD和手機。終端的多樣性對視頻碼流的要求也不一樣。如移動終端一般相對帶寬較小，且屏幕尺寸也較小，屏幕寬高比也不同。每種終端希望拿到最適合自己的視頻碼流，既適合自己的網絡帶寬，又適合自己的硬件能力。如一種設備編碼流出來后，其中既包含了高清到標清不同分辨率，又具有各種幀率。終端只需要發起申請，從其中拿到適合自己的碼流，這是一件多好的事情，(好處)避免的轉碼，同時合理的利用的帶寬和終端的硬件能力。
SVC的本意就是如此，能夠實現碼流的可伸縮，也就是說能根據帶寬，終端的要求，自動調整發送給終端視頻流的格式。一次性編碼適應于多種信道和終端。視頻會議中有一種MCU設備，你要是研究MCU的功能，你會發現它多么適合采用SVC技術。SVC技術的應用理論上應該能節省MCU的部分計算資源。但一路SVC碼流實際上市多組碼流構成的，它們是相互獨立的，如果全部傳輸和存儲必然是帶寬和容量的增加。因此這種技術適合使用在中央設備上（如MCU），終端上是不會使用到的。SVC希望做到一次編碼后，按需分配。
目前SVC技術應用得不廣泛，RADVISION宣稱已經支持。目前MCU所做的是要么按最低能力編碼發送，要么按數組能力編碼，數組碼流發送。SVC技術無法做到跨越視頻壓縮標準，也就是所需要都在H,264或者其它莫一個相同的視頻壓縮標準之內，所以收端都支持該標準。如果跨域壓縮標準（如終端中支持的壓縮標準不相同，如只支持MPEG?或者只支持H.263或者只支持H.264），則終端設備還必須做轉碼才能實現互通。
?
?
?
總結
以上是生活随笔為你收集整理的Android视频录制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： VB.NET创建/修复/压缩/备份/恢复
- 下一篇： android sina oauth2.