前言
- 源碼:
https://github.com/Peakmain/Video_Audio/blob/master/app/src/main/java/com/peakmain/video_audio/activity/ - 我的簡書:http://www.itdecent.cn/u/3ff32f5aea98
- 我的Github:https://github.com/peakmain
H265編碼
為什么會有H265
- 視頻分辨率 從720p 到 1080P 再到后面的4k 8k電視蓬勃發(fā)展
- 視頻幀率從30幀 到60幀，再到120幀
- 宏塊個數(shù)爆發(fā)式增長
- 宏塊復雜度降低
- 運動矢量的復雜度大幅增加
H265的優(yōu)勢
- 1、降低碼流，提升編碼效率， H.265提供了更加多樣化的手段來降低碼流。除了在編解碼效率的提升之外，對網(wǎng)絡(luò)的適應性方面H.265也有顯著提升，可以很好地運行在多重復雜網(wǎng)絡(luò)條件下。因此視頻會議應用H.265，能夠確保在低網(wǎng)絡(luò)帶寬下，仍可實現(xiàn)高分辨率的視頻播放
- 2、高品質(zhì)1080P60圖像質(zhì)量，傳統(tǒng)H.264視頻會議系統(tǒng)，在10Mb的網(wǎng)絡(luò)帶寬下，想要達到1080P30的實時通信效果，已經(jīng)是相當困難了。現(xiàn)在運用H.265編解碼技術(shù)，這種情況得到大大改觀，支持在相同帶寬下，實現(xiàn)高于1080P30達到1080P60甚至是4k的視頻播放，大幅度提升交互感和逼真感。這也意味著：H.265能夠在有限帶寬下，傳輸更高質(zhì)量的視頻內(nèi)容，不僅讓視頻會議用戶體驗到更好的效果，也減少了網(wǎng)絡(luò)帶寬傳輸高清視頻的壓力，降低用戶使用視頻會議的帶寬費用。
- 3、降低延時，更高效快捷。 H.265編解碼在H.264的基礎(chǔ)上進行大量技術(shù)創(chuàng)新，尤其是在降低實時時延上有著顯著的成果，它通過減少信息獲取時間、降低隨機接入時延、降低算法復雜度等多維度技術(shù)優(yōu)勢來實現(xiàn)。
H265特點
- H265將宏塊的大小從H264的16x16擴展到了64x64，以便于高分辨率視頻的壓縮
- H265采用了更加靈活的編碼結(jié)構(gòu)來提高編碼效率
包括編碼單元（類似H264宏塊，用于編碼）、預測單元和變換單元。 - H265幀內(nèi)預測
- H265:所有的CU塊，亮度有35種預測方向，色度5種
- H264：亮度4x4和8x8塊都是9個方向，16x16是4種方向，色度4種方向
H265碼流分析
- 關(guān)于SPS/PPS/IDR/P/B等概念這里就不再詳細說明。H264和H265的每一個NALU前綴碼也是一樣的，即“0x00 00 00 01”或者 “0x00 00 01”。大家可以看我之前的文章Android音視頻開發(fā)——H264的基本概念
-
H264的幀類型，因為H264是后5位保存幀類型數(shù)據(jù)，所以與1F即可
image.png -
H265的幀類型：將value&7E>>1就可以得到幀類型
image.png - 我們常需要的類型
| 幀類型 | value |
|---|---|
| vps | 32 |
| sps | 33 |
| pps | 34 |
| IDR | 19 |
| P | 1 |
| B | 0 |
實例分析
image.png
- 我們以40 01為例
0100 0000 40
& 0111 1110 7E
= 0100 0000 40
>>1 0010 0000 =32
我們發(fā)現(xiàn)結(jié)果是32也就是vps
- 42 01為例我們發(fā)現(xiàn)結(jié)果是33，也就是sps
0100 0010 42
& 0111 1110 7E
= 0100 0010 42
>>1 0010 0001 =33
H265實現(xiàn)手機投屏
實現(xiàn)效果.gif
原理
image.png
核心代碼
首先我們需要獲取錄制屏幕的數(shù)據(jù),其實也就是編碼層
public void startLive() {
try {
//服務器端編碼H264通過socket發(fā)送給客戶端
MediaFormat format = MediaFormat.createVideoFormat(MediaFormat.MIMETYPE_VIDEO_HEVC, mWidth, mHeight);
format.setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface);
format.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 1);
format.setInteger(KEY_BIT_RATE, mWidth * mHeight);
format.setInteger(KEY_FRAME_RATE, 20);
mMediaCodec = MediaCodec.createEncoderByType(MediaFormat.MIMETYPE_VIDEO_HEVC);
mMediaCodec.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);
//創(chuàng)建場地
Surface surface = mMediaCodec.createInputSurface();
mVirtualDisplay = mMediaProjection.createVirtualDisplay("CodecLiveH265",
mWidth, mHeight, 1, DisplayManager.VIRTUAL_DISPLAY_FLAG_PUBLIC, surface, null, null);
mHandler.post(this);
} catch (IOException e) {
e.printStackTrace();
}
}
@Override
public void run() {
mMediaCodec.start();
MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo();
while (true) {
//取出數(shù)據(jù)發(fā)送給客戶端
int outIndex = mMediaCodec.dequeueOutputBuffer(bufferInfo, 1000);
if (outIndex >= 0) {
ByteBuffer buffer = mMediaCodec.getOutputBuffer(outIndex);
dealFrame(buffer, bufferInfo);
mMediaCodec.releaseOutputBuffer(outIndex, false);
}
}
}
如果大家有不懂的可以看我之前的文章：Android音視頻開發(fā)——MedCodec實現(xiàn)屏幕錄制編碼成H264
我們需要注意處理幀的方法dealFrame。在h265的數(shù)據(jù)中，其實只會出現(xiàn)一次VPS，SPS和PPS，但是在投屏過程中，我們必須在每次傳I幀的時候，都需要將VPS_PPS_SPS一并傳過去
public static final int NAL_I = 19;
public static final int NAL_VPS = 32;
//vps+sps+pps是一幀，所以只需要獲取vps
private byte[] vps_sps_pps_buffer;
private void dealFrame(ByteBuffer buffer, MediaCodec.BufferInfo bufferInfo) {
//過濾掉第一個0x00 00 00 01 或者0x 00 00 01
int offset = 4;
if (buffer.get(2) == 0x01) {
offset = 3;
}
//獲取幀類型
int type = (buffer.get(offset) & 0x7E) >> 1;
if (type == NAL_VPS) {
vps_sps_pps_buffer = new byte[bufferInfo.size];
buffer.get(vps_sps_pps_buffer);
} else if (type == NAL_I) {
//I幀
final byte[] bytes = new byte[bufferInfo.size];
buffer.get(bytes);
//vps_pps_sps+I幀的數(shù)據(jù)
byte[] newBuffer = new byte[vps_sps_pps_buffer.length + bytes.length];
System.arraycopy(vps_sps_pps_buffer, 0, newBuffer, 0, vps_sps_pps_buffer.length);
System.arraycopy(bytes, 0, newBuffer, vps_sps_pps_buffer.length, bytes.length);
mWebSocketSendLive.sendData(newBuffer);
}else{
//P幀 B幀直接發(fā)送就可以了
final byte[] bytes = new byte[bufferInfo.size];
buffer.get(bytes);
mWebSocketSendLive.sendData(bytes);
}
}
接下來就是接收端去解析獲得buffer
第一步初始化解碼器
//初始化解碼器
private fun initDecoder(surface: Surface?) {
mMediaCodec = MediaCodec.createDecoderByType(MediaFormat.MIMETYPE_VIDEO_HEVC)
val format =
MediaFormat.createVideoFormat(MediaFormat.MIMETYPE_VIDEO_HEVC, mWidth, mHeight)
format.setInteger(MediaFormat.KEY_BIT_RATE, mWidth * mHeight)
format.setInteger(MediaFormat.KEY_FRAME_RATE, 20)
format.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 1)
mMediaCodec.configure(
format,
surface,
null, 0
)
mMediaCodec.start()
}
第二步，對獲得的數(shù)據(jù)進行解碼
override fun callBack(data: ByteArray?) {
//回調(diào)
LogUtils.e("接收到數(shù)據(jù)的長度:${data?.size}")
//客戶端主要將獲取到的數(shù)據(jù)進行解碼，首先需要通過dsp進行解碼
val index = mMediaCodec.dequeueInputBuffer(10000)
if (index >= 0) {
val inputBuffer = mMediaCodec.getInputBuffer(index)
inputBuffer.clear()
inputBuffer.put(data, 0, data!!.size)
//通知dsp芯片幫忙解碼
mMediaCodec.queueInputBuffer(index, 0, data.size, System.currentTimeMillis(), 0)
}
//取出數(shù)據(jù)
val bufferInfo = MediaCodec.BufferInfo()
var outIndex: Int = mMediaCodec.dequeueOutputBuffer(bufferInfo, 10000)
while (outIndex > 0) {
mMediaCodec.releaseOutputBuffer(outIndex, true)
outIndex = mMediaCodec.dequeueOutputBuffer(bufferInfo, 10000)
}
}
解碼大家有不懂的可以看之前這篇文章：Android音視頻開發(fā)——MediaCodec播放H264視頻
其實投屏還是相當簡單，只是對之前的技術(shù)進行一個綜合。主要需要知道一個核心思路就是，發(fā)送端是對H265數(shù)據(jù)進行編碼，然后通過Socket發(fā)送給客戶端，而接收端(客戶端)主要對數(shù)據(jù)的解碼
關(guān)于webrtc核心通信代碼其實與上訴代碼整體類似，只是將錄屏的數(shù)據(jù)變成了相機的數(shù)據(jù)，關(guān)于相機的使用，大家可以看我的簡書
Android音視頻開發(fā)——Camera、Camera2和CameraX的使用和封裝
具體實現(xiàn)代碼，大家可以看我的GitHub：https://github.com/Peakmain/Video_Audio/blob/master/app/src/main/java/com/peakmain/video_audio/activity/VideoAcceptVideoCallActivity.kt
