android採集視頻流

Ⅰ android 開發 怎麼通過地址鏈接訪問獲取視頻流,並解析播放

你可以直接把這個鏈接發送給系統播放器播放，或者用videoview播放， 你的地址鏈接是個參數，set一下就可以播放了

Ⅱ android中做視頻監控系統，使用海康威視的攝像頭，如何獲取視頻留，如何在android端實現編碼解碼

你為什麼在手機端做編碼呢

Ⅲ android中關於接收攝像頭視頻流的問題懂的指點了思路

我個人結合自己的了解，談一點點個人的看法吧：
使用手機去查看交通、景點或是家裡裝的監控，與android關系不大，很多系統都可以實現。
交通、景點或是家裡裝的監控，可以通過網路協議，傳入網路伺服器，並且存儲在伺服器中，供隨時調用。
用戶使用終端，如電腦、手機等設備，按指定的方法進入到相應的伺服器，通過伺服器驗證，輸入用戶名和密碼，即可查看相應的內容。
前幾年，杭州交-警申請IP4，用於監控各交通路口的交通情況，實現的原理就是這樣的。
當然，除了使用互聯網，還可以通過一些特定波段的無線來實現，但原理都是一樣的。

至於說手機將這種視頻流顯示出來，就相對簡單多了，相當於播放網路視頻。

Ⅳ Android 實時視頻採集—Camera預覽採集與顯示（平台系統camera功能理解分享）

        本文之所以有必要編寫並作記錄，主要原因是因為在工作中開發出一個萬能的自定義camera預覽控制項之後，本是一個提高效率以及提供一個強大能力的控制項，但是產品並不能理解這個萬能控制項存在的意義，產品無法與技術設計相結合的理解使用；並且發現我們的智能業務部Camera自定義預覽技術雖然是使用多年，但是我們並沒有真正的形成規范，由於產品在不能夠理解系統平台（Android/iOS）給產品和研發帶來了什麼，導致產品可能會出現在不理解系統平台以及系統知識的情況下，臆想產品所謂的形態；當產品設計脫離了系統平台所支持的技術點以及設計的初衷，就會導致回歸問題的時候，出現不必要的討論，其根結就是一點：「信息不同步，知識不同步」。

        所以，為了提高效率，就採用記錄和分享的方式，嘗試性推動產品、測試、研發三者對工程與架構的同步理解，更深的懂得程序架構設計意義，嘗試性通過信息同步的方式，在一個統一的知識儲備的平台下，共同完成一個更高效，和高品質的工程產品。（為了能夠讓非技術：產品設計，以及測試都能夠理解，所以，使用了更多的白話解釋）

        附：強大靈活的FsCameraTextureView（第一版，自適應截取）（ 第二版本版本：自適應展示）

        首先，拋出幾個問題，

      1）什麼是攝像頭支持的previewSize？

      2）什麼是視頻或者圖片的pictureSize?

      3)  如何獲取和查看攝像頭支持的PreViewSize 和PictureSize ？

      4）手機預覽所見的區域SurfaceView(TextureView)與camera 的previewSize的關系是什麼？

      5）為什麼會設計了兩種預覽方式view，兩種預覽方式都會有什麼樣子的效果呢？

一，概述

通過Android Camera拍攝預覽中設置setPreviewCallback實現onPreviewFrame介面，實時截取每一幀視頻流數據（簡單說來，就是通過設置一個介面，接收系統回調通知我們的每一幀數據）

二，知識點

    1， camera支持的格式：

    2，拍照流程

    3，camera許可權

  三，Android Camera中PreviewSize、 PictureSize、 SurfaceView(TextureView)之間的關系

        1，PreviewSize：

          相機預覽時候的能支持的尺寸，簡單的說一下，就是預覽的大小，也就是拍照前能夠看到的圖片大小。（通過Android手機相機可以試一下，這個參數設置不同，同樣的焦距下，拍攝桌子上一個固定距離的東西，看到的視野會不同）

          相機的預覽尺寸，不能隨意的設置值，只能通過camera的parameters的getSupportedPreviewSizes方法，獲取支持的預覽尺寸列表，並從列表中選擇一個設置在parameters中。（通俗簡單的說就是，獲取camera中能夠支持的預覽大小合集，如果你想要查看某個預覽對應的尺寸，就把該尺寸設置到camera的屬性中即可，則camera會返回相對應尺寸的預覽數據流提供顯示）。

        2，PictureSize :

指的是拍照之後，最終拍攝到的圖片大小，也就是圖片的質量。圖片尺寸同樣也只能從支持的列表中選取一個設置。 調用camera的takePicture方法（拍照）後，獲得拍照的圖像數據，注意picturesize和previewsize的寬高比也要保證一致，否則獲取的圖片會將preview時的圖像裁剪成picturesize的比例。 previewsize的解析度，只會影響預覽時的解析度，不會影響獲取圖片的解析度，所以preview只是確定了圖像的取景最大范圍。最終圖片的解析度是由picturesize來決定。 所以，最好的設置方法，例如：previewsize為1280*720，picturesize為2560*1440。（由於我們沒有拍照業務，目前這個知識，不做深究）

        3，SurfaceView(TextureView)

          用於展示camera預覽圖像的view，就是將preview獲得的數據，放在這個view上。所以如果preview的寬高比和SurfaceView的寬高比不一樣，就會導致看到的圖像拉伸變形。圖像拉伸變形解決的辦法：

          （1）就是在確定preview的解析度後，重新設置SurfaceView寬高；

          （2）如果SurfaceView寬高定死，則需要獲取一個比例適合SurfaceView尺寸的PreviewSize 的preview，盡量小的裁剪，然後填充在SurfaceView中。

        4，利用圖片的顯示方式，理解Preview與SurfaceView（TextureView）顯示關系

          ImageView （UI上面設計的一個控制項）與圖片bitmap 的關系，比如限定死一個ImageView的大小，但是圖片與ImageView尺寸不一致，就會有幾種方案，首先選取一張長方形1920*1080的圖片，ImageView就是紫色部分，無論長寬比都比ImageView要大。

圖片適配例1：拉伸填充ScaleType.FIT_XY :雖然被全部填充，但是整個圖片為了適配圖片已經扭曲，失真，圖片縮放到控制項大小，完全填充控制項大小展示。

圖片適配例2：等比例裁剪填充ScaleType.CENTER_CROP ，因為在該模式下，圖片會被等比縮放直到完全填充整個ImageView，並居中顯示。該模式也是最常用的模式了。如圖可以看到，圖片的高度是能完全展示出來的，但是左右部分被進行了裁剪，並沒有完全顯示。

圖片適配例3 :  ScaleType.CENTER_INSIDE，此模式，用以完全展示圖片內容為目的。圖片將被等比縮放到能夠完整展示在ImageView中並居中，如果圖片大小，小於控制項尺寸，那麼就直接居中展示該圖片

            圖片適配ImageView方式還有很多，就不一一列舉，這三種已經足夠重要，為什麼講解camera預覽，卻穿插了圖片的適配，其實可以這么理解，camera的preview就是由多張圖片組成，不斷的像幀動畫一樣變化，而SurfaceView就是一個載體，相當於ImageView，業務中定死了SurfaceView的大小之後，被動的承載你選擇的previewSize，來展示camera的Preview，你可以選擇類似於前面三種例子來理解preview的填充，以下會舉例說明preview的填充策略選擇有哪幾種方式，我們會採用哪種方式：

        1）拉伸填充，自適應view，不可取，比如：手機的SurfaceView是整個手機的屏幕尺寸（全屏填充），或者任意尺寸比例的surfaceView，使用這種方式，就如同（圖片適配例1）的方式，導致視頻扭曲，拉伸。

        2）等比例裁剪填充，目前我們項目中，採用的就是這種方式，並且提供給很多三方使用，已經成為一種獨立，並且穩定的技術實現自定義view，簡單說一下視頻的適配策略方式，SurfaceView隨便由業務方，自定義寬度大小，比如業務方選擇了1900*1000的SurfaceView， 我們的適配過程是：（1）從PreviewSize列表中選取最接近SurfaceView尺寸的PreviewSize（假設該攝像頭，只支持1920*1080，和320*640），1920*1080最接近，所以被獲取；(此處展示一下蹩腳的英文Try to find an size match aspect ratio and size,嘗試找到縱橫比與view大小比適中的一個尺寸)（2）等比例裁剪填充到SurfaceView，首先我們設計的邏輯是，先選取一個縮放比例，假設等比例1920的圖片按照SurfaceView的寬度等比例縮小到1900，而為了不讓Preview失真，則高度1080等比例縮小的值是1068.75（等比例方程式，這里就不重復初中的知識，請自行計算），所以圖片被壓縮成為1900*1068這個尺寸，依舊保證圖片完整，並且不失真。（3）將等比例縮減的圖片，1900*1068進行顯示在1900*1000的SurfaceView中，就會有一種效果類似（圖片適配例2），寬度全部展示，高度被裁剪。（如同  圖片適配例2中左右部分裁剪一樣的道理）                       

          3）完全展示camera內容的縮放填充（類似圖片適配例3），我們打開任意一部手機的camera，預覽圖像都沒有全屏幕展示，類似拍照功能，所見即所得，PreviewSize是多少，就顯示什麼樣子的比例尺寸，以及最後生產的照片比例就是多少，我們的自定義view，也可以隨意設置大小，此模式下，用以完全展示camera內容為目的。Preview將被等比縮放到能夠完整展示在SurfaceView中並居中，但是可能會有部分位置無法填充（類似圖片適配例3顯示效果）。

（該方式只是進行了技術儲備，由於沒有業務場景設計，所以沒有使用，目前只是儲備了這樣的自定義控制項）

四，靈活的自定義TextureView預覽控制項       

        FsCameraTextureView（第一版，自適應截取）：等比例裁剪填充，方式（適配方式2），採用前面說的適配方式2，而產出的一種自定義view，2019年5月產出至今，在金融APP，以及商城的app中使用，經過逐步優化，和多版本檢驗，目前該控制項，擁有以下特點：  1）穩定：目前各個使用場景，均無邏輯崩潰，內存泄漏，線程等任意問題； 2）靈活：隨意設置預覽view的尺寸大小，自適應任意業務設計；不僅僅滿足刷臉業務，並且滿足任意相機預覽業務方使用； 3）提高效率，減輕工作量：使用簡單，操作步驟簡潔，接入只需要兩步；減輕接入端，或者想要使用相機預覽的業務的工作量，不需要重復造車，並且安全穩定。

      輸出的業務方有（經不完全統計）：（目前業務為保密進行公網保密處理）1）**創新科技業務部-區塊鏈部門 2）泰國人臉識別業務SDK3）S D**Bank 人臉業務4）核驗身份證業務5）HT**Bank 人臉業務 6）**雲，商業平台部門

      FsAllPreviewCameraTextureView（技術儲備版，全預覽模式顯示）：完全展示camera內容的縮放填充，採用前面說的（適配方式3）適合拍照相關的業務使用，優點同樣是，外部業務隨意改變view大小，可以自適應view，由於目前沒有業務方使用，暫時做儲備，不深入講解。

如果可以控制項開源成功，後期，我將開源這兩個控制項，讓更多的使用方使用，我們也希望共同技術進步，提高工程產出的使用能力。

預計下一次分享內容是（臨時命名）

1）人臉核驗內存和線程爆表到泄漏為零

2）分享七年前參於的Scrum（如何提高崗位間效率所定製的敏捷開發過程）

本文參考：

https://www.jianshu.com/p/32e335d5b842

https://www.cnblogs.com/skyseraph/archive/2012/03/26/2418665.html

Ⅳ Android 編程中，MediaRecord中據說有個Icamera可以獲取視頻流，詳細如下

MediaMetadataRetriever retriever = new MediaMetadataRetriever();
retriever.setDataSource(filePath);

Ⅵ Android 音視頻01 --- H264的基本原理01

H264壓縮技術主要採用了以下幾種方法對視頻數據進行壓縮。包括：

解決的是空域數據冗餘問題。

解決的是時域數據冗徐問題

將空間上的相關性變為頻域上無關的數據然後進行量化。

經過壓縮後的幀分為：I幀，P幀和B幀:

關鍵幀，採用幀內壓縮技術。

向前參考幀，在壓縮時，只參考前面已經處理的幀。採用幀音壓縮技術。

雙向參考幀，在壓縮時，它即參考前而的幀，又參考它後面的幀。採用幀間壓縮技術。
除了I/P/B幀外，還有圖像序列GOP。

H264的基本原理其實非常簡單，下我們就簡單的描述一下H264壓縮數據的過程。通過攝像頭採集到的視頻幀（按每秒 30 幀算），被送到 H264 編碼器的緩沖區中。編碼器先要為每一幅圖片劃分宏塊。

劃分好宏塊後，計算宏塊的象素值。以此類推，計算一幅圖像中每個宏塊的像素值。

對於視頻數據主要有兩類數據冗餘，一類是時間上的數據冗餘，另一類是空間上的數據冗餘。其中時間上的數據冗餘是最大的。為什麼說時間上的冗餘是最大的呢？假設攝像頭每秒抓取30幀，這30幀的數據大部分情況下都是相關聯的。也有可能不止30幀的的數據，可能幾十幀，上百幀的數據都是關聯特別密切的。
H264編碼器會按順序，每次取出兩幅相鄰的幀進行宏塊比較，計算兩幀的相似度。如下圖：

在H264編碼器中將幀分組後，就要計算幀組內物體的運動矢量了。
H264編碼器首先按順序從緩沖區頭部取出兩幀視頻數據，然後進行宏塊掃描。當發現其中一幅圖片中有物體時，就在另一幅圖的鄰近位置（搜索窗口中）進行搜索。如果此時在另一幅圖中找到該物體，那麼就可以計算出物體的運動矢量了。
運動矢量計算出來後，將相同部分（也就是綠色部分）減去，就得到了補償數據。我們最終只需要將補償數據進行壓縮保存，以後在解碼時就可以恢復原圖了。壓縮補償後的數據只需要記錄很少的一點數據。
我們把運動矢量與補償稱為 幀間壓縮技術 ，它解決的是視頻幀在時間上的數據冗餘。除了幀間壓縮，幀內也要進行數據壓縮，幀內數據壓縮解決的是空間上的數據冗餘。

人眼對圖象都有一個識別度，對低頻的亮度很敏感，對高頻的亮度不太敏感。所以基於一些研究，可以將一幅圖像中人眼不敏感的數據去除掉。這樣就提出了幀內預測技術。
一幅圖像被劃分好宏塊後，對每個宏塊可以進行 9 種模式的預測。找出與原圖最接近的一種預測模式。然後，將原始圖像與幀內預測後的圖像相減得殘差值。再將我們之前得到的預測模式信息一起保存起來，這樣我們就可以在解碼時恢復原圖了，經過幀內與幀間的壓縮後，雖然數據有大幅減少，但還有優化的空間。

可以將殘差數據做整數離散餘弦變換，去掉數據的相關性，進一步壓縮數據。

上面的幀內壓縮是屬於有損壓縮技術。也就是說圖像被壓縮後，無法完全復原。而CABAC屬於無損壓縮技術。
無損壓縮技術大家最熟悉的可能就是哈夫曼編碼了，給高頻的詞一個短碼，給低頻詞一個長碼從而達到數據壓縮的目的。MPEG-2中使用的VLC就是這種演算法，我們以 A-Z 作為例子，A屬於高頻數據，Z屬於低頻數據。看看它是如何做的。
CABAC也是給高頻數據短碼，給低頻數據長碼。同時還會根據上下文相關性進行壓縮，這種方式又比VLC高效很多。

制定了相互傳輸的格式，將宏快 有組織，有結構，有順序的形成一系列的碼流。這種碼流既可 通過 InputStream 網路流的數據進行傳輸，也可以封裝成一個文件進行保存，主要作用是為了傳輸。

組成H264碼流的結構中 包含以下幾部分 ，從大到小排序依次是：
H264視頻序列，圖像，片組，片，NALU，宏塊 ，像素。

NAL層:（Network Abstraction Layer,視頻數據網路抽象層） ： 它的作用是H264隻要在網路上傳輸，在傳輸的過程每個包乙太網是1500位元組，而H264的幀往往會大於1500位元組，所以要進行拆包，將一個幀拆成多個包進行傳輸，所有的拆包或者組包都是通過NAL層去處理的。
VCL層:（Video Coding Layer,視頻數據編碼層） ： 對視頻原始數據進行壓縮

起始碼0x 00 00 00 01 或者 0x 00 00 01 作為 分隔符 。
兩個 0x 00 00 00 01之間的位元組數據 是表示一個NAL Unit。

I 幀的特點：

1.分組:把幾幀圖像分為一組(GOP，也就是一個序列),為防止運動變化,幀數不宜取多。
2.定義幀:將每組內各幀圖像定義為三種類型,即I幀、B幀和P幀;
3.預測幀:以I幀做為基礎幀,以I幀預測P幀,再由I幀和P幀預測B幀;
4.數據傳輸:最後將I幀數據與預測的差值信息進行存儲和傳輸。

1．更高的編碼效率：同H.263等標準的特率效率相比，能夠平均節省大於50％的碼率。
2．高質量的視頻畫面：H.264能夠在低碼率情況下提供高質量的視頻圖像，在較低帶寬上提供高質量的圖像傳輸是H.264的應用亮點。
3．提高網路適應能力：H.264可以工作在實時通信應用（如視頻會議）低延時模式下，也可以工作在沒有延時的視頻存儲或視頻流伺服器中。
4．採用混合編碼結構：同H.263相同，H.264也使用採用DCT變換編碼加DPCM的差分編碼的混合編碼結構，還增加了如多模式運動估計、幀內預測、多幀預測、基於內容的變長編碼、4x4二維整數變換等新的編碼方式，提高了編碼效率。
5．H.264的編碼選項較少：在H.263中編碼時往往需要設置相當多選項，增加了編碼的難度，而H.264做到了力求簡潔的「回歸基本」，降低了編碼時復雜度。
6．H.264可以應用在不同場合：H.264可以根據不同的環境使用不同的傳輸和播放速率，並且提供了豐富的錯誤處理工具，可以很好的控制或消除丟包和誤碼。
7．錯誤恢復功能：H.264提供了解決網路傳輸包丟失的問題的工具，適用於在高誤碼率傳輸的無線網路中傳輸視頻數據。
8．較高的復雜度：264性能的改進是以增加復雜性為代價而獲得的。據估計，H.264編碼的計算復雜度大約相當於H.263的3倍，解碼復雜度大約相當於H.263的2倍。
H.264的目標應用涵蓋了目前大部分的視頻服務，如有線電視遠程監控、交互媒體、數字電視、視頻會議、視頻點播、流媒體服務等。H.264為解決不同應用中的網路傳輸的差異。定義了兩層：視頻編碼層（VCL：Video Coding Layer）負責高效的視頻內容表示，網路提取層（NAL：Network Abstraction Layer）負責以網路所要求的恰當的方式對數據進行打包和傳送。

Ⅶ android視頻流處理

《android逆向視頻》網路網盤資源免費下載

鏈接:https://pan..com/s/1W1NAE-AeKbz0bb6E4mdXfA

Ⅷ android mediarecorder硬編碼獲取音視頻流，怎樣設置時間戳達到音視頻同步

參考spydroid開源項目，這個開源項目有音頻(aac)，視頻(H264)流的讀取，具體操作都有，就是音視頻時間戳不知怎麼弄，音視頻同步搞不定，您有想法記得分享哦！

Ⅸ Android 如何實現攝像頭不進行預覽顯示，只獲取視頻流數據

好像是強制要求有預覽的,安全問題,比如偷窺什麼的所以不允許無預覽畫面的使用攝像頭