❶ 附加： FFmpeg概念理解
FFmpeg 介紹
FFmpeg是一套可以用旅凳來記錄、轉換數字音頻、視頻，並能將其轉化為流的開源計算機程序。採用LGPL或GPL許可證。它提供了錄制、轉換以及流化音視頻的完整解決方案。它包含了非常先進的音頻/視頻編解碼庫libavcodec，為了保證高可移植性和編解碼質量，libavcodec里很多codec都是從頭開發的。
FFmpeg在Linux平台下開發，但它同樣也可以在其它操作系統環境中編譯運行，包括Windows、Mac OS X等。這個項目最早由Fabrice Bellard發起，現在由Michael Niedermayer維護。許多FFmpeg的開發人員都來自MPlayer項目，而且當前FFmpeg也是放在MPlayer項目組的伺服器上。項目的名稱來自MPEG視頻編碼標准，前面的"FF"代表"Fast Forward"。
FFmpeg模塊
libavformat：用於各種音視頻封裝格式的生成和解析，包括獲取解碼所需信息脊擾以生成解碼上下文結構和讀取音視頻幀等功能；
libavcodec：用於各種類型聲音/圖像編解碼；
libavutil：包含一些公共的工具函數；
libswscale：用於視頻場景比例縮放、色彩映射轉換；
libpostproc：用於後期效果處理；
ffmpeg：該項目提供的一個工具，可用於格式轉換、解碼或電視卡即時編碼等；
ffsever：一個 HTTP 多媒體即時廣播串流伺服器；
ffplay：是一個簡單的播放器，使用ffmpeg 庫解析和解碼，通過SDL顯示；
H.264編碼原理I／B／P幀
三種幀的說明
I幀:幀內編碼幀 ，I幀表示關鍵幀，你可以理解為這一幀畫面的完整保留；解碼時只需要本幀數據就可以完成（因為包含完整畫面）
I幀特點:
1.它是一個全幀壓縮編碼幀。它將全幀圖像信息進行JPEG壓縮編碼及傳輸;
2.解碼時僅用I幀的數據就可重構完整圖像;
3.I幀描述了圖像背景和運動主體的詳情;
4.I幀不需要參考其他畫面而生成;
5.I幀是P幀和B幀的參考幀(其質量直接影響到同組中以後各幀的質量);
6.I幀是幀組GOP的基礎幀(第一幀),在一組中只有一個I幀;
7.I幀不需要考慮運動矢量;
8.I幀所佔數據的信息量比較大。
P幀:前向預測編碼幀。P幀表示的是這一幀跟之前的一個關鍵幀（或P幀）的差別，解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。（也就是差別幀，P幀沒有完整畫面數據，只有與前一幀的畫面差別的數據）
P幀的預測與重構:P幀是以I幀為參考幀,在I幀中找出P幀「某點」的預測值和運動矢量,取預測差值和運動矢量一起傳送。在接收端根據運動矢量從I幀中找出P幀「某點」的預測值並與差值相加以得到P幀「某點」樣值,從而可得到完整的P幀。
P幀特點:
1.P幀是I幀後面相隔1~2幀的編碼幀;
2.P幀採用運動補償的方法傳送它與前面的I或P幀的差值及運動矢量(預測誤差);
3.解碼時必須將I幀中的預測值與預測誤差求和後才能重構完整的P幀圖像;
4.P幀屬於前向預測的幀間編碼。它只參考前面最靠近它的I幀或P幀;
5.P幀可以是其後面P幀的參考幀,也可以是其前後的B幀的參考幀;
6.由於P幀是參考幀,它可能造成解碼錯誤的擴散櫻鎮旦;
7.由於是差值傳送,P幀的壓縮比較高。
B幀:雙向預測內插編碼幀。B幀是雙向差別幀，也就是B幀記錄的是本幀與前後幀的差別（具體比較復雜，有4種情況，但我這樣說簡單些），換言之，要解碼B幀，不僅要取得之前的緩存畫面，還要解碼之後的畫面，通過前後畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高，但是解碼時CPU會比較累。
B幀的預測與重構
B幀以前面的I或P幀和後面的P幀為參考幀,「找出」B幀「某點」的預測值和兩個運動矢量,並取預測差值和運動矢量傳送。接收端根據運動矢量在兩個參考幀中「找出(算出)」預測值並與差值求和,得到B幀「某點」樣值,從而可得到完整的B幀。
B幀特點
1.B幀是由前面的I或P幀和後面的P幀來進行預測的;
2.B幀傳送的是它與前面的I或P幀和後面的P幀之間的預測誤差及運動矢量;
3.B幀是雙向預測編碼幀;
4.B幀壓縮比最高,因為它只反映丙參考幀間運動主體的變化情況,預測比較准確;
5.B幀不是參考幀,不會造成解碼錯誤的擴散。
注:I、B、P各幀是根據壓縮演算法的需要，是人為定義的,它們都是實實在在的物理幀。一般來說，I幀的壓縮率是7（跟JPG差不多），P幀是20，B幀可以達到50。可見使用B幀能節省大量空間，節省出來的空間可以用來保存多一些I幀，這樣在相同碼率下，可以提供更好的畫質。
h264的壓縮方法:
1.分組:把幾幀圖像分為一組(GOP，也就是一個序列),為防止運動變化,幀數不宜取多。
2.定義幀:將每組內各幀圖像定義為三種類型,即I幀、B幀和P幀;
3.預測幀:以I幀做為基礎幀,以I幀預測P幀,再由I幀和P幀預測B幀;
4.數據傳輸:最後將I幀數據與預測的差值信息進行存儲和傳輸。幀內（Intraframe）壓縮也稱為空間壓縮（Spatial compression）。當壓縮一幀圖像時，僅考慮本幀的數據而不考慮相鄰幀之間的冗餘信息，這實際上與靜態圖像壓縮類似。幀內一般採用有損壓縮演算法，由於幀內壓縮是編碼一個完整的圖像，所以可以獨立的解碼、顯示。幀內壓縮一般達不到很高的壓縮，跟編碼jpeg差不多。
幀間（Interframe）壓縮的原理是：相鄰幾幀的數據有很大的相關性，或者說前後兩幀信息變化很小的特點。也即連續的視頻其相鄰幀之間具有冗餘信息,根據這一特性，壓縮相鄰幀之間的冗餘量就可以進一步提高壓縮量，減小壓縮比。幀間壓縮也稱為時間壓縮（Temporal compression），它通過比較時間軸上不同幀之間的數據進行壓縮。幀間壓縮一般是無損的。幀差值（Frame differencing）演算法是一種典型的時間壓縮法，它通過比較本幀與相鄰幀之間的差異，僅記錄本幀與其相鄰幀的差值，這樣可以大大減少數據量。
順便說下有損（Lossy ）壓縮和無損（Lossy less）壓縮。無損壓縮也即壓縮前和解壓縮後的數據完全一致。多數的無損壓縮都採用RLE行程編碼演算法。有損壓縮意味著解壓縮後的數據與壓縮前的數據不一致。在壓縮的過程中要丟失一些人眼和人耳所不敏感的圖像或音頻信息,而且丟失的信息不可恢復。幾乎所有高壓縮的演算法都採用有損壓縮,這樣才能達到低數據率的目標。丟失的數據率與壓縮比有關,壓縮比越小，丟失的數據越多,解壓縮後的效果一般越差。此外,某些有損壓縮演算法採用多次重復壓縮的方式,這樣還會引起額外的數據丟失。
H264 NAL頭解析
如果NALU對應的Slice為一幀的開始，則用4位元組表示，即0x00000001；否則用3位元組表示，0x000001。
NAL Header：forbidden_bit，nal_reference_bit（優先順序）2bit，nal_unit_type（類型）5bit。 標識NAL單元中的RBSP數據類型，其中，nal_unit_type為1， 2， 3， 4， 5的NAL單元稱為VCL的NAL單元，其他類型的NAL單元為非VCL的NAL單元。
0：未規定
1：非IDR圖像中不採用數據劃分的片段
2：非IDR圖像中A類數據劃分片段
3：非IDR圖像中B類數據劃分片段
4：非IDR圖像中C類數據劃分片段
5：IDR圖像的片段
6：補充增強信息（SEI）
7：序列參數集（SPS）
8：圖像參數集（PPS）
9：分割符
10：序列結束符
11：流結束符
12：填充數據
13：序列參數集擴展
14：帶前綴的NAL單元
15：子序列參數集
16 – 18：保留
19：不採用數據劃分的輔助編碼圖像片段
20：編碼片段擴展
21 – 23：保留
24 – 31：未規定
H.264的SPS和PPS串，包含了初始化H.264解碼器所需要的信息參數，包括編碼所用的profile，level，圖像的寬和高，deblock濾波器等。
碼率：256～512 kb/s
幀率：15～20fps
解析度：1280x720(HD) 640x368(VGA) 1920x1080(UHD)
AAC（Advanced Audio Coding）
中文名：高級音頻編碼，出現於1997年，基於MPEG-2的音頻編碼技術。由Fraunhofer IIS、杜比實驗室、AT&T、Sony等公司共同開發，目的是取代MP3格式。2000年，MPEG-4標准出現後，AAC重新集成了其特性，加入了SBR技術和PS技術，為了區別於傳統的MPEG-2 AAC又稱為MPEG-4 AAC。
優點：相對於mp3，AAC格式的音質更佳，文件更小。
不足：AAC屬於有損壓縮的格式，與時下流行的APE、FLAC等無損格式相比音質存在「本質上」的差距。加之，傳輸速度更快的USB3.0和16G以上大容量MP3正在加速普及，也使得AAC頭上「小巧」的光環不復存在了。
音頻采樣率是指錄音設備在一秒鍾內對聲音信號的采樣次數，采樣頻率越高聲音的還原就越真實越自然。在當今的主流採集卡上，采樣頻率一般共分為22.05KHz、44.1KHz、48KHz三個等級，22.05KHz只能達到FM廣播的聲音品質，44.1KHz則是理論上的CD音質界限，48KHz則更加精確一些。
比特率是指每秒傳送的比特(bit)數。單位為 bps(Bit Per Second)，比特率越高，傳送數據速度越快。聲音中的比特率是指將模擬聲音信號轉換成數字聲音信號後，單位時間內的二進制數據量，是間接衡量音頻質量的一個指標。 視頻中的比特率（碼率）原理與聲音中的相同，都是指由模擬信號轉換為數字信號後，單位時間內的二進制數據量。
信道編碼中，K符號大小的信源數據塊通過編碼映射為N符號大小的碼字，則K/N成為碼率，其中假設編碼前後的符號表沒有變化。
FFMPEG中結構體很多。最關鍵的結構體可以分成以下幾類：
解協議（http,rtsp,rtmp,mms）
AVIOContext，URLProtocol，URLContext主要存儲視音頻使用的協議的類型以及狀態。URLProtocol存儲輸入視音頻使用的封裝格式。每種協議都對應一個URLProtocol結構。（注意：FFMPEG中文件也被當做一種協議「file」）
解封裝（flv,avi,rmvb,mp4）
AVFormatContext主要存儲視音頻封裝格式中包含的信息；AVInputFormat存儲輸入視音頻使用的封裝格式。每種視音頻封裝格式都對應一個AVInputFormat 結構。
解碼（h264,mpeg2,aac,mp3）
每個AVStream存儲一個視頻/音頻流的相關數據；每個AVStream對應一個AVCodecContext，存儲該視頻/音頻流使用解碼方式的相關數據；每個AVCodecContext中對應一個AVCodec，包含該視頻/音頻對應的解碼器。每種解碼器都對應一個AVCodec結構。
存數據
視頻的話，每個結構一般是存一幀；音頻可能有好幾幀
解碼前數據：AVPacket
解碼後數據：AVFrame
AVCodec
AVCodec是存儲編解碼器信息的結構體
const char *name：編解碼器的名字，比較短
const char *long_name：編解碼器的名字，全稱，比較長
enum AVMediaType type：指明了類型，是視頻，音頻，還是字幕
enum AVCodecID id：ID，不重復
const AVRational *supported_framerates：支持的幀率（僅視頻）
const enum AVPixelFormat *pix_fmts：支持的像素格式（僅視頻）
const int *supported_samplerates：支持的采樣率（僅音頻）
const enum AVSampleFormat *sample_fmts：支持的采樣格式（僅音頻）
const uint64_t channel_layouts：支持的聲道數（僅音頻）
int priv_data_size：私有數據的大小
1.注冊所有編解碼器：av_register_all();
2.聲明一個AVCodec類型的指針，比如說AVCodec
first_c;
3.調用av_codec_next()函數，即可獲得指向鏈表下一個解碼器的指針，循環往復可以獲得所有解碼器的信息。注意，如果想要獲得指向第一個解碼器的指針，則需要將該函數的參數設置為NULL。
AVCodecContext
這是一個描述編解碼器上下文的數據結構，包含了眾多編解碼器需要的參數信息
如果是單純使用libavcodec，這部分信息需要調用者進行初始化；如果是使用整個FFMPEG庫，這部分信息在調用 av_open_input_file和av_find_stream_info的過程中根據文件的頭信息及媒體流內的頭部信息完成初始化。其中幾個主要 域的釋義如下：
extradata/extradata_size： 這個buffer中存放了解碼器可能會用到的額外信息，在av_read_frame中填充。一般來說，首先，某種具體格式的demuxer在讀取格式頭 信息的時候會填充extradata，其次，如果demuxer沒有做這個事情，比如可能在頭部壓根兒就沒有相關的編解碼信息，則相應的parser會繼 續從已經解復用出來的媒體流中繼續尋找。在沒有找到任何額外信息的情況下，這個buffer指針為空。
time_base：
width/height：視頻的寬和高。
sample_rate/channels：音頻的采樣率和信道數目。
sample_fmt： 音頻的原始采樣格式。
codec_name/codec_type/codec_id/codec_tag：編解碼器的信息。
AVStream
該結構體描述一個媒體流
主要域的釋義如下，其中大部分域的值可以由av_open_input_file根據文件頭的信息確定，缺少的信息需要通過調用av_find_stream_info讀幀及軟解碼進一步獲取：
index/id：index對應流的索引，這個數字是自動生成的，根據index可以從AVFormatContext::streams表中索引到該流；而id則是流的標識，依賴於具體的容器格式。比如對於MPEG TS格式，id就是pid。
time_base：流的時間基準，是一個實數，該流中媒體數據的pts和dts都將以這個時間基準為粒度。通常，使用av_rescale/av_rescale_q可以實現不同時間基準的轉換。
start_time：流的起始時間，以流的時間基準為單位，通常是該流中第一個幀的pts。
ration：流的總時間，以流的時間基準為單位。
need_parsing：對該流parsing過程的控制域。
nb_frames：流內的幀數目。
r_frame_rate/framerate/avg_frame_rate：幀率相關。
codec：指向該流對應的AVCodecContext結構，調用av_open_input_file時生成。
parser：指向該流對應的AVCodecParserContext結構，調用av_find_stream_info時生成。
AVFormatContext
這個結構體描述了一個媒體文件或媒體流的構成和基本信息
這是FFMpeg中最為基本的一個結構，是其他所有結構的根，是一個多媒體文件或流的根本抽象。其中:nb_streams和streams所表示的AVStream結構指針數組包含了所有內嵌媒體流的描述；iformat和oformat指向對應的demuxer和muxer指針；pb則指向一個控制底層數據讀寫的ByteIOContext結構。
start_time和ration是從streams數組的各個AVStream中推斷出的多媒體文件的起始時間和長度，以微妙為單位。
通常，這個結構由av_open_input_file在內部創建並以預設值初始化部分成員。但是，如果調用者希望自己創建該結構，則需要顯式為該結構的一些成員置預設值——如果沒有預設值的話，會導致之後的動作產生異常。以下成員需要被關註：
probesize
mux_rate
packet_size
flags
max_analyze_ration
key
max_index_size
max_picture_buffer
max_delay
AVPacket
AVPacket定義在avcodec.h中
FFMPEG使用AVPacket來暫存解復用之後、解碼之前的媒體數據（一個音/視頻幀、一個字幕包等）及附加信息（解碼時間戳、顯示時間戳、時長等）。其中：
dts 表示解碼時間戳，pts表示顯示時間戳，它們的單位是所屬媒體流的時間基準。
stream_index 給出所屬媒體流的索引；
data 為數據緩沖區指針，size為長度；
ration 為數據的時長，也是以所屬媒體流的時間基準為單位；
pos 表示該數據在媒體流中的位元組偏移量；
destruct 為用於釋放數據緩沖區的函數指針；
flags 為標志域，其中，最低為置1表示該數據是一個關鍵幀。
AVPacket 結構本身只是個容器，它使用data成員指向實際的數據緩沖區，這個緩沖區可以通過av_new_packet創建，可以通過 av_p_packet 拷貝，也可以由FFMPEG的API產生（如av_read_frame），使用之後需要通過調用av_free_packet釋放。
av_free_packet調用的是結構體本身的destruct函數，它的值有兩種情況：(1)av_destruct_packet_nofree或 0；(2)av_destruct_packet，其中，前者僅僅是將data和size的值清0而已，後者才會真正地釋放緩沖區。FFMPEG內部使用 AVPacket結構建立緩沖區裝載數據，同時提供destruct函數，如果FFMPEG打算自己維護緩沖區，則將destruct設為 av_destruct_packet_nofree，用戶調用av_free_packet清理緩沖區時並不能夠將其釋放；如果FFMPEG不會再使用 該緩沖區，則將destruct設為av_destruct_packet，表示它能夠被釋放。對於緩沖區不能夠被釋放的AVPackt，用戶在使用之前 最好調用av_p_packet進行緩沖區的克隆，將其轉化為緩沖區能夠被釋放的AVPacket，以免對緩沖區的不當佔用造成異常錯誤。而 av_p_packet會為destruct指針為av_destruct_packet_nofree的AVPacket新建一個緩沖區，然後將原 緩沖區的數據拷貝至新緩沖區，置data的值為新緩沖區的地址，同時設destruct指針為av_destruct_packet。
AVFrame
構體保存的是解碼後和原始的音視頻信息。AVFrame通過函數av_frame_alloc()初始化，該函數僅僅分配AVFrame實例本身，而沒有分配其內部的緩存。AVFrame實例由av_frame_free()釋放；AVFrame實例通常分配一次，重復使用，如分配一個AVFrame實例來保留解碼器中輸出的視頻幀（此時應在恰當的時候使用av_frame_unref()清理參考幀並將AVFrame歸零）。該類所描述的數據通常由AVBuffer的API來保存一個引用計數，並保存於AVFrame.buf
/AVFrame.extended_buf，在至少存在一個參考的時候（如AVFrame.buf[0] != NULL），則該對象被標記為「被引用」。在此情況下，AVFrame所包含的每一組數據必須包含於AVFrame的緩存中。
AAC格式ADTS
ADTS流 跟Raw流，
1.ADTS是個啥
ADTS全稱是(Audio Data Transport Stream)，是AAC的一種十分常見的傳輸格式。
AAC解碼器都需要把AAC的ES流打包成ADTS的格式，一般是在AAC ES流前添加7個位元組的ADTS header。也就是說你可以吧ADTS這個頭看作是AAC的frameheader。
ffmpeg寫 mp4+aac時呢，音頻有兩個值得注意的地方。
1 寫aac音頻時，要添加兩個位元組的信息到AVCodecContext.
2 ffmpeg 寫AAC音頻數據不能含有ADTS頭
在AAC ES流前添加7個位元組的ADTS header。也就是說你可以吧ADTS這個頭看作是AAC的frameheader。
tvOS必須要支持 bitcode. (iOS bitcode項可選的) 所以在編譯的時候Makefile要加上 CFLAGS= -fembed-bitcode 。 如果用xcode編譯lib，要在Build Settings—>custom compiler flags —>cflags 加上OTHER_CFLAGS="-fembed-bitcode" 。
FFmpeg優化
1 內存優化。內存往上漲。沒能及時回收。最好能夠使用手動管理內存。
解碼優化，看ffmpeg文檔，最新的解碼庫，解碼效率，穩定性，綜合性考慮。
YUV->RGB OpenGLES shader來顯示。
FFmpeg轉碼
1.分離視頻音頻流
ffmpeg -i input_file -vcodec -an output_file_video//分離視頻流
ffmpeg -i input_file -acodec -vn output_file_audio//分離音頻流
2.視頻解復用
ffmpeg –i test.mp4 –vcodec –an –f m4v test.264
ffmpeg –i test.avi –vcodec –an –f m4v test.264
3.視頻轉碼
ffmpeg –i test.mp4 –vcodec h264 –s 352 278 –an –f m4v test.264 //轉碼為碼流原始文件
ffmpeg –i test.mp4 –vcodec h264 –bf 0 –g 25 –s 352
278 –an –f m4v test.264 //轉碼為碼流原始文件
ffmpeg –i test.avi -vcodec mpeg4 –vtag xvid –qsame test_xvid.avi //轉碼為封裝文件
//-bf B幀數目控制，-g 關鍵幀間隔控制，-s 解析度控制
4.視頻封裝
ffmpeg –i video_file –i audio_file –vcodec –acodec output_file
5.視頻剪切
ffmpeg –i test.avi –r 1 –f image2 image-%3d.jpeg //提取圖片
ffmpeg -ss 0:1:30 -t 0:0:20 -i input.avi -vcodec -acodec output.avi //剪切視頻
//-r 提取圖像的頻率，-ss 開始時間，-t 持續時間
6.視頻錄制
ffmpeg –i rtsp://192.168.3.205:5555/test –vcodec out.avi
7.YUV序列播放
ffplay -f rawvideo -video_size 1920x1080 input.yuv
8.YUV序列轉AVI
ffmpeg –s w*h –pix_fmt yuv420p –i input.yuv –vcodec mpeg4 output.avi
system調用
#include<stdio.h>#include<string.h>intmain(){charcommand[50];strcpy(command,"ffmpeg –s w*h –pix_fmt yuv420p –i input.yuv –vcodec mpeg4 output.avi");system(command);return(0);}
FFMpeg 中比較重要的函數以及數據結構如下:
數據結構:
(1) AVFormatContext
(2) AVOutputFormat
(3) AVInputFormat
(4) AVCodecContext
(5) AVCodec
(6) AVFrame
(7) AVPacket
(8) AVPicture
(9) AVStream
初始化函數:
(1) av_register_all()
(2) avcodec_open()
(3) avcodec_close()
(4) av_open_input_file()
(5) av_find_input_format()
(6) av_find_stream_info()
(7) av_close_input_file()
音視頻編解碼函數:
(1) avcodec_find_decoder()
(2) avcodec_alloc_frame()
(3) avpicture_get_size()
(4) avpicture_fill()
(5) img_convert()
(6) avcodec_alloc_context()
(7) avcodec_decode_video()
(8) av_free_packet()
(9) av_free()
文件操作:
(1) avnew_steam()
(2) av_read_frame()
(3) av_write_frame()
(4) mp_format()
其他函數:
(1) avpicture_deinterlace()
(2) ImgReSampleContext()
❷ FFmpeg調研報告
FFmpeg 是非常強大的多媒體編解碼框架，堪稱多媒體處理的瑞士軍刀，是集錄制，轉碼，流的完整的跨平台多媒體解決方案。本身涵蓋了大量的多媒體處理工具。
而我們常說的視頻，其實是包含的視頻，音頻甚至還有字幕的一個整體。因為視頻本身是三維的數據，在計算中直接存儲空間非常大，通常無法接受，所以，會對其進行一些編碼和壓縮，這個過程通常是有損的，但卻極大了降低了它的存儲空間。
視頻數據相比點陣圖數據多了一維，但其本身還是由像素點組成。
編碼、壓縮在流媒體領域是一項非常重要的技術：從 H264碼流 到 YUV流 的過程稱為 解碼 ，反之稱為 編碼 。
幀是流的基本元素，即視頻流中的圖像。在原始流里，各幀都一樣。但經過編碼壓縮後的幀，通常分為下面幾種：
注意：I、P、B幀，並不是依據視頻幀數據內部的元素的不同來區分的，從解碼後的幀本身而言，它穗態們沒有任何區別。僅僅是在編碼時，對幀處理的方式不同而已。
首先視頻文件與視頻編碼格猜猜源式是兩個概念。
一般包括以下部分：
FFmpeg 處理視頻轉碼時的常規過程如下：
各自狀態的數據產物如下：
視頻中會有音頻，視頻，它們在文件有各自的編碼壓縮方式，但為了傳輸過程方便，將壓縮過的音頻和視頻捆綁在一起進行傳輸。首先就需要將媒體文件中的各個音頻，視頻，字幕流等分開。
這一步叫Demux（解復用）。總結就是把不同的流從某種容器（文件）中解析出來。如上圖所示，並且，一個媒體文件中，還可以分別有不止一個音頻，視頻和字幕流。
媒體數據為了降低存儲量，針對裡面的音頻，視頻，字幕等都會採取特定方式的編碼壓縮。
這一步便對各自的流採用其對應的解碼演算法進行處理。得到原始流。
即這一步是以幀為單位實現壓縮數據到原始數據轉換。
這一步再按照目標的編碼方式對流進行編碼。即這一步是以幀為單位實現原始數據到壓縮數據轉換。
Demux的逆操作，把不同的流按照某種容器的規則放入容器
按照編解碼器的位置劃分：
FFmpeg中filter分為：
因其僅有解碼部分的硬體加速，缺少編碼部分的加速。且Nvidia有單身以NVENC和NVDEC替代掉這一塊的意思，這里不多做細節介紹。細節請看 文檔
支持的格式有：
優點：
各種型號的設計支持情況請看 Video Encode and Decode GPU Support Matrix
查看硬體支持：
使用CUDA解碼：
使用CUVID解碼：
轉碼，使用NVDEC和NVENC
可以使用 -hwaccel_device <id> 指定GPU。GPU id可以通過 nvidia-smi 查看
該方案一般通過QSV來進行加速。QSV（Quick Sync Video）即Intel的集成加速器，該方便優缺點如下：
優點：
查看CPU是否支持的方法如下：
該方案支持h264，h265，mjpeg，mpeg2video，vp8，vp9的編解碼，和vc1的解碼。
更細節的支持情況如下：
解碼支持情況：
編碼支持情況：
QuickSync對於編碼解碼在CPU使用率上都有著非常不錯的提升。編碼提升效果特別明顯。
關於抽幀的各種表現，待之後測試補上。TODO
更多細節可以參考官方 文檔
FFmpeg使用QSV加速的一些命令行參數可 參考
使用ffprobe提取兆運出IPB幀的時間
抽取IPB幀到jpg圖片：
抽幀流程其實與轉碼類似，一樣是輸入視頻文件，對視頻文件進行Demux，解碼視頻流，得到原始視頻幀，然後挑選相應的視頻幀按jpeg編碼，mux輸出到一個個文件中。
那麼要加快抽幀的效率，便是想辦法加快上面這各個階段的速率
抽幀會伴隨著大量的文件輸出。在有很多抽幀任務並行時，理論上會對磁碟造成大量的隨機寫入。
其他途徑優化：
結合以上各節點，這里列出一些進一步的調研方向：
此方案針對加快解碼，加快編碼。基於目前的信息來看：
該方案會有非常大的優化效果，若有足夠支持QSV的CPU機器，那麼該方案可行性非常大。
待進一步補充相關測試數據
同上，針對解碼編碼方面嘗試加快進行優化。目前情況：
該方案理論上也應該會有不錯的優化效果。但就目前的一些簡單測試來看，即使能達到好的加速效果，其成本也未必能夠接受
待進一步補充相關測試數據
該方案針對加快數據讀取和數據輸出。考慮的點主要是整個抽幀過程中是否對視頻文件有不小量的隨機讀取，大量抽幀任務並行時，會有巨量的圖片輸出。這塊是否會產生大量的隨機寫入，降低效率。
待進一步補充相關測試數據
該方案針對加解碼（更確切地說是減少不必要的解碼操作）
例如對於一秒一幀的均勻抽幀，我們針對這種情況，修改為，盡量抽取每一秒中的關鍵幀。做個偽的一秒一幀的均勻抽幀。這種模式不一定能為所有抽幀情況加速，但若能為大頭的需求加速也不錯
待進一步測試驗證可行性及補充相關測試數據
針對解碼編碼方面嘗試加快進行優化。
ffmpeg中，同樣格式可能有多個編碼解碼器，比如jpeg的就會有mjpeg，libjpeg等。不同的庫實現，性能，質量會有一些差距，通過測試實驗，改善參數，或許一定程度上能優化性能。
待進一步補充相關測試數據
針對流程的優化。如前面的單幀抽幀， -ss 參數的不同位置會影響 ffmpeg 抽取的時間。理論上，ffmpeg 本身設計是為了通用，而對於專用於抽幀的場景，ffmpeg本身可能存在一些沒必要的工作，嘗試通過參數和源碼級別來優化，或許能省掉這部分的資源消耗。
待進一步補充相關測試數據
TODO
FFmpeg官網
3GP/MP4 視頻文件格式解析及其播放原理（轉）
FFmpeg視頻抽幀那些事
FFmpeg原理和架構
FFmpeg 硬體加速方案概覽 （上）
FFmpeg 硬體加速方案概覽 （下）
FFmpeg wiki HWAccelIntro
視頻和視頻幀：FFMPEG+Intel QSV硬解的環境安裝篇
視頻和視頻幀：視頻和幀基礎知識整理
❸ ffmpeg基礎知識
ffmpeg是音視頻處理的c庫， 音視頻在網路傳輸過程中，由於數據量大，所有需要進行壓縮
壓縮目的為了去除冗餘信息，冗餘信息分為：
1、空間冗餘：圖像相鄰像素之間有較強的相關性
2、時間冗餘：視頻序列的相鄰圖像之間內容相似
3、 編碼冗餘：不同像素值出現的概率不同
4、 視覺冗餘：人的視覺系統對某些細節不敏感
5、知識冗餘：規律性的結構可由先驗知識和背景知識得到
● 無損壓縮(Winzip)
壓縮前解壓縮後圖像完全一致
壓縮比低
● 有損壓縮(H.264)
壓縮前解壓縮後圖像不一致
壓縮比高
利用人的視覺系統的特性(人眼能見的動畫頻率和圖像細節有限制)
音視頻壓縮其實就是對音視頻進行編碼,
視頻編碼格式
音頻編碼格式
封裝格式
流媒體協議
YUV ，是一種 顏色 編碼 方法。常使用在各個視頻處理組件中。 YUV在對照片或視頻編碼時，考慮到人類的感知能力，允許降低色度的帶寬。
YUV是編譯true-color顏色空間（colorspace）的種類，Y'UV,YUV, YCbCr ， YPbPr 等專有名詞都可以稱為YUV，彼此有重疊。「Y」表示 明亮度 （Luminance、Luma），「U」和「V」則是**[色度]
YUV格式有兩大類：(平面格式)planar和(打包格式)packed。
1.planar:先存儲Y，然後U，然後V
2.packed:yuv交叉存儲
還有我們常說的YUV420sp與YUV420p。
YUV420sp: 一種two-plane模式,即Y和UV分為兩個平面,U、V交錯排列。
YUV420p: 先把U存放完後，再存放V。UV是連續的。
YUV420的數據大小為： 亮度（行×列） ＋ V（行×列/4) + U（行×列/4）即：W H 3/2,
普遍的編碼器都以接受planar的I420數據(YUV420P)
4*4的I420數據排列如下:
y1 y2 y3 y4
y5 y6 y7 y8
y9 y10 y11 y12
y13 y14 y15 y16
u1 u2 u3 u4
v1 v2 v3 v4
Android相機的採集的視頻是NV21(YUV420sP), 也是YUV的格式 只不過U和V的交叉的。
y1 y2 y3 y4
y5 y6 y7 y8
y9 y10 y11 y12
y13 y14 y15 y16
u1 v1 u2 v2
u3 v3 u4 v4
在採集相機數據時需要把UV數據給轉換成上面的 順序。
I frame ：幀內編碼幀 ，I 幀通常是每個 GOP（MPEG 所使用的一種視頻壓縮技術）的第一個幀，經過適度地壓縮，做為隨機訪問的參考點，可以當成圖象。I幀可以看成是一個圖像經過壓縮後的產物。
P frame: 前向預測編碼幀，通過充分將低於圖像序列中前面已編碼幀的時間冗餘信息來壓縮傳輸數據量的編碼圖像，也叫預測幀；
B frame: 雙向預測內插編碼幀 ，既考慮與源圖像序列前面已編碼幀，也顧及源圖像序列後面已編碼幀之間的時間冗餘信息來壓縮傳輸數據量的編碼圖像，也叫雙向預測幀；
I frame:自身可以通過視頻解壓演算法解壓成一張單獨的完整的圖片。
P frame：需要參考其前面的一個I frame 或者B frame來生成一張完整的圖片。
B frame:則要參考其前一個I或者P幀及其後面的一個P幀來生成一張完整的圖片。
PTS：Presentation Time Stamp。PTS主要用於度量解碼後的視頻幀什麼時候被顯示出來
DTS：Decode Time Stamp。DTS主要是標識讀入內存中的幀數據在什麼時候開始送入解碼器中進行解碼。
在沒有B幀存在的情況下DTS的順序和PTS的順序應該是一樣的。
DTS主要用於視頻的解碼,在解碼階段使用。PTS主要用於視頻的同步和輸出.在顯示的時候使用。
如上圖：I frame 的解碼不依賴於任何的其它的幀.而p frame的解碼則依賴於其前面的I frame或者P frame.B frame的解碼則依賴於其前的最近的一個I frame或者P frame 及其後的最近的一個P frame.
libavformat
用於各種音視頻封裝格式的生成和解析，包括獲取解碼所需信息以生成解碼上下文結構和讀取音視頻幀等功能；音視頻的格式解析協議，為 libavcodec 分析碼流提供獨立的音頻或視頻碼流源。
libavcodec
用於各種類型聲音/圖像編解碼；該庫是音視頻編解碼核心，實現了市面上可見的絕大部分解碼器的功能，libavcodec 庫被其他各大解碼器 ffdshow，Mplayer 等所包含或應用。
libavfilter
filter（FileIO、FPS、DrawText）音視頻濾波器的開發，如水印、倍速播放等。
libavutil
包含一些公共的工具函數的使用庫，包括算數運算 字元操作；
libswresample
原始音頻格式轉碼。
libswscale
（原始視頻格式轉換）用於視頻場景比例縮放、色彩映射轉換；圖像顏色空間或格式轉換，如 rgb565,rgb888 等與 yuv420 等之間轉換。
音視頻解5封裝流程：
ffmpeg解碼流程：
❹ 使用 ffmpeg 實現 MP4 與 GIF 的互轉
在 Mac OSX 上使用 Homebrew 安裝 ffmpeg ：
從視頻中第二秒開始，截取時長為3秒的片段轉化為 gif
默認轉化是中等質量模式，若要轉化出高質量的 gif，可以修改比特率
注意 sacle 值必須是偶數，這里的 -1 表示保持長寬比，根據寬度值自適應高度。
如果要求壓縮出來的視頻尺寸長寬都保持為猛遲偶數，可以使用 -2
定義幀率 16fps:
-an 就是禁止音頻輸出
也可以將 gif 轉為其他視頻格式
使用 ImageMagick 可以方便第提取 gif 圖片的第 N 幀圖像。
安裝 ImageMagick
提取拆知數第一幀
通過 [0] 就可以提取出 gif 的第一幀圖像。
有些 GIF 轉化出來的 MP4 不能被 Mac QuickTime Player.app 播放，需要添加 pixel formal 參數
使用旅首 yunv420p 需要保證長寬為偶數，這里同時使用了 scale=420:-2 。
wiki 解釋 ： QuickTime Player 對 H.264 視頻只支持 YUV 色域 4:2:0 方式的二次插值演算法。
❺ FFmpeg功能命令匯總
前言
如此強大的FFmpeg，能夠實現視頻採集、視頻格式轉化、視頻截圖、視頻添加水印、視頻切片、視頻錄制、視頻推流、更改音視頻參數功能等。通過終端命令如何凳睜實現這些功能，Richy在本文做一記錄，以備之後查閱。
注意：下面一一列舉的命令，未歸類整理，命令參數供參考。
如果參數有誤，大家可對照首局文章－ FFmpeg參數命令 ，進行修改。
第一組
1.分離視頻音頻流
ffmpeg -i input_file -vcodec -an output_file_video//分離視頻流ffmpeg -i input_file -acodec -vn output_file_audio//分離音頻流
2.視頻解復用
ffmpeg –i test.mp4 –vcodec –an –f m4v test.264
ffmpeg –i test.avi –vcodec –an –f m4v test.264
3.視頻轉碼
ffmpeg –i test.mp4 –vcodec h264 –s 352*278 –an –f m4v test.264
//轉碼為碼流原始文件
ffmpeg –i test.mp4 –vcodec h264 –bf 0 –g 25 –s 352*278 –an –f m4v test.264 //轉碼為碼流原始文件
ffmpeg –i test.avi -vcodec mpeg4 –vtag xvid –qsame test_xvid.avi //轉碼為封裝文件
說明： -bf B幀數目控制，-g 關鍵幀間隔控制，-s 解析度控制
4.視頻封裝
ffmpeg –i video_file –i audio_file –vcodec –acodec output_file
5.視頻剪切
ffmpeg –i test.avi –r 1 –f image2 image-%3d.jpeg //提取圖片
ffmpeg -ss 0:1:30 -t 0:0:20 -i input.avi -vcodec -acodec output.avi //剪切視頻//-r 提取圖者粗讓像的頻率，-ss 開始時間，-t 持續時間
6.視頻錄制
ffmpeg –i rtsp://192.168.3.205:5555/test –vcodec out.avi
7、利用ffmpeg視頻切片
主要把視頻源切成若干個.ts格式的視頻片段然後生成一個.m3u8的切片文件索引提供給html5的video做hls直播源
命令如下：
ffmpeg -i 視頻源地址 -strict -2 -c:v libx264 -c:a aac -f hls m3u8文件輸出地址
8、ffmpeg縮放視頻
假設原始視頻尺寸是 1080p（即 1920×1080 px，16:9），使用下面命令可以縮小到 480p：
命令如下：
ffmpeg -i 視頻源地址 -vf scale=853:480 -acodec aac -vcodec h264 視頻輸出地址（如：out.mp4）
各個參數的含義：-i a.mov 指定待處理視頻的文件名-vf scale=853:480 vf 參數用於指定視頻濾鏡，其中 scale 表示縮放，後面的數字表示縮放至 853×480 px，其中的 853px 是計算而得，因為原始視頻的寬高比為 16:9，所以為了讓目標視頻的高度為 480px，則寬度 = 480 x 9 / 16 = 853-acodec aac 指定音頻使用 aac 編碼。註：因為 ffmpeg 的內置 aac 編碼目前（寫這篇文章時）還是試驗階段，故會提示添加參數 「-strict -2」 才能繼續，盡管添加即可。又或者使用外部的 libfaac（需要重新編譯 ffmpeg）。-vcodec h264 指定視頻使用 h264 編碼。註：目前手機一般視頻拍攝的格式（封裝格式、文件格式）為 mov 或者 mp4，這兩者的音頻編碼都是 aac，視頻都是 h264。out.mp4 指定輸出文件名上面的參數 scale=853:480 當中的寬度和高度實際應用場景中通常只需指定一個，比如指定高度為 480 或者 720，至於寬度則可以傳入 「-1」 表示由原始視頻的寬高比自動計算而得。即參數可以寫為：scale=-1:480，當然也可以 scale=480:-1
9、ffmpeg裁剪
有時可能只需要視頻的正中一塊，而兩頭的內容不需要，這時可以對視頻進行裁剪（crop），比如有一個豎向的視頻 1080 x 1920，如果指向保留中間 1080×1080 部分命令如下：ffmpeg -i 視頻源地址 -strict -2 -vf crop=1080:1080:0:420 視頻輸出地址（如：out.mp4）
其中的 crop=1080:1080:0:420 才裁剪參數，具體含義是 crop=width:height:x:y，其中 width 和 height 表示裁剪後的尺寸，x:y 表示裁剪區域的左上角坐標。比如當前這個示例，我們只需要保留豎向視頻的中間部分，所以 x 不用偏移，故傳入0，而 y 則需要向下偏移：(1920 – 1080) / 2 = 420
10. 轉視頻格式
ffmpeng -i source.mp4 -c:v libx264 -crf 24 destination.flv
其中 -crf 很重要，是控制轉碼後視頻的質量，質量越高，文件也就越大。
此值的范圍是 0 到 51：0 表示高清無損；23 是默認值（如果沒有指定此參數）；51 雖然文件最小，但效果是最差的。
值越小，質量越高，但文件也越大，建議的值范圍是 18 到 28。而值 18 是視覺上看起來無損或接近無損的，當然不代表是數據（技術上）的轉碼無損。
第二組
1.ffmpeg 把文件當做直播推送至伺服器 (RTMP + FLV)
ffmpeg - re -i demo.mp4 -c - f flv rtmp://w.gslb.letv/live/streamid
2.將直播的媒體保存到本地
ffmpeg -i rtmp://r.glsb.letv/live/streamid -c streamfile.flv
3.將一個直播流，視頻改用h264壓縮，音頻改用faac壓縮，送至另一個直播伺服器
ffmpeg -i rtmp://r.glsb.letv/live/streamidA -c:a libfaac -ar 44100 -ab 48k -c:v libx264 -vpre slow -vpre baseline -f flv rtmp://w.glsb.letv/live/streamb
4.提取視頻中的音頻,並保存為mp3 然後輸出
ffmpeg -i input.avi -b:a 128k output.mp3
第三組
1.獲取視頻的信息
ffmpeg -i video.avi
2.將圖片序列合成視頻
ffmpeg -f image2 -i image%d.jpg video.mpg
上面的命令會把當前目錄下的圖片（名字如：image1.jpg. image2.jpg. 等...）合並成video.mpg
3.將視頻分解成圖片序列
ffmpeg -i video.mpg image%d.jpg
上面的命令會生成image1.jpg. image2.jpg. ...
支持的圖片格式有：PGM. PPM. PAM. PGMYUV. JPEG. GIF. PNG. TIFF. SGI
4.為視頻重新編碼以適合在iPod/iPhone上播放
ffmpeg -i source_video.avi input -acodec aac -ab 128kb -vcodec mpeg4 -b 1200kb -mbd 2 -flags +4mv+trell -aic 2 -cmp 2 -subcmp 2 -s 320x180 -title X final_video.mp4
5.為視頻重新編碼以適合在PSP上播放
ffmpeg -i source_video.avi -b 300 -s 320x240 -vcodec xvid -ab 32 -ar 24000 -acodec aac final_video.mp4
6.從視頻抽出聲音.並存為Mp3
ffmpeg -i source_video.avi -vn -ar 44100 -ac 2 -ab 192 -f mp3 sound.mp3
7.將wav文件轉成Mp3
ffmpeg -i son_origine.avi -vn -ar 44100 -ac 2 -ab 192 -f mp3 son_final.mp3
8.將.avi視頻轉成.mpg
ffmpeg -i video_origine.avi video_finale.mpg
9.將.mpg轉成.avi
ffmpeg -i video_origine.mpg video_finale.avi
10.將.avi轉成gif動畫（未壓縮）
ffmpeg -i video_origine.avi gif_anime.gif
11.合成視頻和音頻
ffmpeg -i son.wav -i video_origine.avi video_finale.mpg
12.將.avi轉成.flv
ffmpeg -i video_origine.avi -ab 56 -ar 44100 -b 200 -r 15 -s 320x240 -f flv video_finale.flv
13.將.avi轉成dv
ffmpeg -i video_origine.avi -s pal -r pal -aspect 4:3 -ar 48000 -ac 2 video_finale.dv
或者：
ffmpeg -i video_origine.avi -target pal-dv video_finale.dv
14.將.avi壓縮成divx
ffmpeg -i video_origine.avi -s 320x240 -vcodec msmpeg4v2 video_finale.avi
15.將Ogg Theora壓縮成Mpeg dvd
ffmpeg -i film_sortie_cinelerra.ogm -s 720x576 -vcodec mpeg2video -acodec mp3 film_terminate.mpg
16.將.avi壓縮成SVCD mpeg2
NTSC格式：
ffmpeg -i video_origine.avi -target ntsc-svcd video_finale.mpg
PAL格式：
ffmpeg -i video_origine.avi -target pal-dvcd video_finale.mpg
17.將.avi壓縮成VCD mpeg2
NTSC格式：
ffmpeg -i video_origine.avi -target ntsc-vcd video_finale.mpg
PAL格式：
ffmpeg -i video_origine.avi -target pal-vcd video_finale.mpg
18.多通道編碼
ffmpeg -i fichierentree -pass 2 -passlogfile ffmpeg2pass fichiersortie-2
19.從flv提取mp3
ffmpeg -i source.flv -ab 128k dest.mp3
第四組
1、將文件當做直播送至live
ffmpeg -re -i localFile.mp4 -c -f flv rtmp://server/live/streamName
2、將直播媒體保存至本地文件
ffmpeg -i rtmp://server/live/streamName -c mp.flv
3、將其中一個直播流，視頻改用h264壓縮，音頻不變，送至另外一個直播服務流
ffmpeg -i rtmp://server/live/originalStream -c:a -c:v libx264 -vpre slow -f flv rtmp://server/live/h264Stream
4、將其中一個直播流，視頻改用h264壓縮，音頻改用faac壓縮，送至另外一個直播服務流
ffmpeg -i rtmp://server/live/originalStream -c:a libfaac -ar 44100 -ab 48k -c:v libx264 -vpre slow -vpre baseline -f flv rtmp://server/live/h264Stream
5、將其中一個直播流，視頻不變，音頻改用faac壓縮，送至另外一個直播服務流
ffmpeg -i rtmp://server/live/originalStream -acodec libfaac -ar 44100 -ab 48k -vcodec -f flv rtmp://server/live/h264_AAC_Stream
6、將一個高清流，復制為幾個不同視頻清晰度的流重新發布，其中音頻不變
ffmpeg -re -i rtmp://server/live/high_FMLE_stream -acodec -vcodec x264lib -s 640×360 -b 500k -vpre medium -vpre baseline rtmp://server/live/baseline_500k -acodec -vcodec x264lib -s 480×272 -b 300k -vpre medium -vpre baseline rtmp://server/live/baseline_300k -acodec -vcodec x264lib -s 320×200 -b 150k -vpre medium -vpre baseline rtmp://server/live/baseline_150k -acodec libfaac -vn -ab 48k rtmp://server/live/audio_only_AAC_48k
7、功能一樣，只是採用-x264opts選項
ffmpeg -re -i rtmp://server/live/high_FMLE_stream -c:a -c:v x264lib -s 640×360 -x264opts bitrate=500:profile=baseline:preset=slow rtmp://server/live/baseline_500k -c:a -c:v x264lib -s 480×272 -x264opts bitrate=300:profile=baseline:preset=slow rtmp://server/live/baseline_300k -c:a -c:v x264lib -s 320×200 -x264opts bitrate=150:profile=baseline:preset=slow rtmp://server/live/baseline_150k -c:a libfaac -vn -b:a 48k rtmp://server/live/audio_only_AAC_48k
8、將當前攝像頭及音頻通過DSSHOW採集，視頻h264、音頻faac壓縮後發布
ffmpeg -r 25 -f dshow -s 640×480 -i video=」video source name」:audio=」audio source name」 -vcodec libx264 -b 600k -vpre slow -acodec libfaac -ab 128k -f flv rtmp://server/application/stream_name
9、將一個JPG圖片經過h264壓縮循環輸出為mp4視頻
ffmpeg.exe -i INPUT.jpg -an -vcodec libx264 -coder 1 -flags +loop -cmp +chroma -subq 10 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -flags2 +dct8x8 -trellis 2 -partitions +parti8x8+parti4x4 -crf 24 -threads 0 -r 25 -g 25 -y OUTPUT.mp4
10、將普通流視頻改用h264壓縮，音頻不變，送至高清流服務(新版本FMS live=1)
ffmpeg -i rtmp://server/live/originalStream -c:a -c:v libx264 -vpre slow -f flv 「rtmp://server/live/h264Stream live=1〃
文／騷之哈塞給（作者）
❻ 圖像視頻相似度演算法
前段時間公司項目用到了語音識別,圖像識別,視頻識別等,其實不能說是識別,應該說是相似度對比吧,畢竟相似度對比還上升不了到識別哈,等以後有了更深的理解再來討論修改下!這次就當做一個總結吧!
其實它的原理就是一個把需要的特徵總結在一個指紋碼裡面,進行降維成渣差指紋碼,假如個指紋碼一模一樣,那兩張圖片就想似了.下面有寫怎麼編譯成唯一標識,再用漢明距離計算兩個指紋碼的相似度中枝.
圖片是採用phash演算法,一共分為四步吧.
1.將圖片縮放到16*16大小,這是我們選擇的合適的大小,假如寬高不一樣,直接將其壓到16*16,去掉細節,只保留宏觀;
2.圖片一共是16*16的,共256個像素,我們將圖片進行灰度化,灰度化就是只有黑白灰三種,從白到黑,一共分了255層;
3.灰度化之後將圖如培皮片進行DCT轉換(離散餘弦變化),因為為了識別有的圖片旋轉,這個DCT轉換是將圖片進行了一種壓縮演算法;
4.我們對這個演算法進行了優化,因為之前是計算像素的均值,我們為了更准確,我們取RGB,rgb一共分為255個像素,我們將255個像素分為16段,如果像素大於0-16記為0,17到32記為1,直到255,這樣就得到255位的二進制,這就是這張圖片的指紋碼.
得到唯一標識的指紋碼之後怎麼去計算像素度呢?
通過漢明距離比較兩個二進制距離,如果距離小於<10的話,我們就判定兩張圖片相似.如果兩個指紋碼(二進制)一模一樣,我們就判定兩個是一張圖片,或者類似;
視頻的話我們是通過ffmpeg(ff am pig),它是一個專門處理視頻的框架,可以從視頻中按針提取圖片.然後就按照圖片的相似度取對比了...