即时通讯音视频开发（八）：常见的实时语音通讯编码标准

前言

即时通讯应用中的实时音视频技术，几乎是IM开发中的最后一道高墙。原因在于：实时音视频技术 = 音视频处理技术 + 网络传输技术 的横向技术应用集合体，而公共互联网不是为了实时通信设计的。有关实时音视频开发时的技术难题请参见《音视频云声网Agora：从demo到实用，中间还差1万个WebRTC》：http://www.52im.net/article-119-1.html

本文是一篇讲述常用的实用音频通讯编码标准的文章。

系列文章

本文是系列文章中的第8篇，本系列文章的大纲如下：

• 《即时通讯音视频开发（一）：视频编解码之理论概述》
• 《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
• 《即时通讯音视频开发（三）：视频编解码之编码基础》
• 《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
• 《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
• 《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
• 《即时通讯音视频开发（七）：音频基础及编码原理入门》
• 《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》（本文）
• 《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
• 《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
• 《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
• 《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
• 《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
• 《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
• 《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
• 《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
• 《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
• 《即时通讯音视频开发（十八）：详解音频编解码的原理、演进和应用选型》
• 《即时通讯音视频开发（十九）：零基础，史上最通俗视频编码技术入门》
  

内容概述

视频通讯过程是视频和音频的实时双向完整通讯过程。在这个过程中我们为了获得高清晰视频图像，有时却忽略了另外一个重要的过程——音频通讯过程。如果我们在观看高清晰视频图像的时候，不能得到一个更清晰、连续的音频效果。那么这个过程实际上就没有任何意义，所以其重要性甚至超过视频。

在传统的视频会议系统、即时通讯聊天系统中音频技术发展极其缓慢，原因在于目前应用于视频通讯的音频编解码压缩标准都是为了保持传输时的低带宽占用和较高的编解码效率，从而将音频信号的采样频率、采样精度和采样范围指标做了极大的降低，使得所能提供的音频清晰度和还原性都有很大程度上的衰减。与用于存储和回放非实时压缩协议的标准（如OGG、MP3等）相比，音频的保真度非常低。这样就在某种程度上对现场声音的还原达不到要求。

目前传统视频通讯过程中主要采用的是G.711、G.722、G.721、G.728等音频标准，音频宽度仅有50Hz－7KHz单声道，而人耳所能感知的自然界的频响能力可以达到20Hz－20KHz，因此，在对现场环境音的还原过程中过多的音频信息的丢失造成了无法真实表现现场情况。所以在高清晰视频通讯过程中我们势必要有一种相辅助的音频处理方式解决此问题。使整个高清晰通讯过程更去近于完美。

目前国际上对音频处理技术上标准较多，在对下一代实时交互音频处理上可以采用MPEG-1 Layer 2或AAC系列音频，对选用标准的原则是，音频频响范围要达到22KHz，这样就几乎可以覆盖了人耳听觉的全部范围，甚至在高频方面还有所超越，能够使现场音频得到真实自然的还原，并且在还原时可以采用双声道立体声回放，使整个视频通讯的声音有更强的临近感，达到CD级音质。同时在对链路带宽的适应和编解码效率上达到最佳。

以下是各种音频编码标准的说明。

实时音频通讯编码标准：G.711

类型：Audio
制定者：ITU-T
所需频宽：64Kbps
特性：算法复杂度小，音质一般
优点：算法复杂度低，压缩比小（CD音质>400kbps），编解码延时最短（相对其它技术）
缺点：占用的带宽较高
备注：70年代CCITT公布的G.711 64kb/s脉冲编码调制PCM。

实时音频通讯编码标准：G.721

制定者：ITU-T
所需带宽：32Kbps
音频频宽：3.4KHZ
特性：相对于PCMA和PCMU，其压缩比较高，可以提供2：1的压缩比。
优点：压缩比大
缺点：声音质量一般
备注：子带ADPCM（SB-ADPCM）技术。G.721标准是一个代码转换系统。它使用ADPCM转换技术，实现64 kb/s A律或μ律PCM速率和32 kb/s速率之间的相互转换。

实时音频通讯编码标准：G.722

制定者：ITU-T
所需带宽：64Kbps
音频宽度：7KHZ
特性：G722能提供高保真的语音质量
优点：音质好
缺点：带宽要求高
备注：子带ADPCM（SB-ADPCM）技术

实时音频通讯编码标准：G.722.1

制定者：ITU-T
所需带宽：32Kbps/24Kbps
音频宽度：7KHZ
特性：可实现比G.722 编解码器更低的比特率以及更大的压缩。目标是以大约一半的比特率实现  G.722 大致相当的质量。
优点：音质好
缺点：带宽要求高
备注：目前大多用于电视会议系统。

实时音频通讯编码标准：G.721附录C

制定者：ITU-T
所需带宽：48Kbps/32Kbps/4Kbps
音频宽度：14KHZ
特性：采用自Polycom 的Siren™14 专利算法，与早先的宽频带音频技术相比具有突破性的优势，提供了低时延的14 kHz 超宽频带音频，而码率不到MPEG4 AAC-LD 替代编解码器的一半，同时要求的运算能力仅为十分之一到二十分之一，这样就留出了更多的处理器周期来提高视频质量或者运行因特网应用程序，并且移动设备上的电池续航时间也可延长。
优点：音质更为清晰，几乎可与CD 音质媲美，在视频会议等应用中可以降低听者的疲劳程度。
缺点：是Polycom的专利技术。
备注：目前大多用于电视会议系统

实时音频通讯编码标准：G.723(低码率语音编码算法)

制定者：ITU-T
所需带宽：5.3Kbps/6.3Kbps
音频宽度：3.4KHZ
特性：语音质量接近良，带宽要求低，高效实现，便于多路扩展，可利用C5402片内16kRAM实现53coder。达到ITU-TG723要求的语音质量，性能稳定。可用于IP电话语音信源编码或高效语音压缩存储。
优点：码率低，带宽要求较小。并达到ITU-TG723要求的语音质量，性能稳定。
缺点：声音质量一般
备注：G.723语音编码器是一种用于多媒体通信，编码速率为5.3kbits/s和6.3kbit/s的双码率编码方案。G.723标准是国际电信联盟（ITU）制定的多媒体通信标准中的一个组成部分，可以应用于IP电话等系统中。其中，5.3kbits/s码率编码器采用多脉冲最大似然量化技术（MP－MLQ），6.3kbits/s码率编码器采用代数码激励线性预测技术。

实时音频通讯编码标准：G.723.1(双速率语音编码算法)

制定者：ITU-T
所需带宽：5.3Kbps(29)
音频宽度：3.4KHZ
特性：能够对音乐和其他音频信号进行压缩和解压缩，但它对语音信号来说是最优的。G.723.1采用了执行不连续传输的静音压缩，这就意味着在静音期间的比特流中加入了人为的噪声。除了预留带宽之外，这种技术使发信机的调制解调器保持连续工作，并且避免了载波信号的时通时断。
优点：码率低，带宽要求较小。并达到ITU-TG723要求的语音质量，性能稳定,避免了载波信号的时通时断。
缺点：语音质量一般
备注：G.723.1算法是ITU-T建议的应用于低速率多媒体服务中语音或其它音频信号的压缩算法，其目标应用系统包括H.323、H.324等多媒体通信系统 。目前该算法已成为IP电话系统中的必选算法之一。

实时音频通讯编码标准：G.728

制定者：ITU-T
所需带宽：16Kbps/8Kbps
音频宽度：3.4KHZ
特性：用于IP电话、卫星通信、语音存储等多个领域。G.728是一种低时延编码器，但它比其它的编码器都复杂，这是因为在编码器中必须重复做50阶LPC分析。G.728还采用了自适应后置滤波器来提高其性能。
优点：后向自适应，采用自适应后置滤波器来提高其性能
缺点：比其它的编码器都复杂
备注：G.728 16kb/s短延时码本激励线性预测编码（LD-CELP）。1996年ITU公布了G.728 8kb/s的CS－ACELP算法，可以用于IP电话、卫星通信、语音存储等多个领域。16 kbps G.728低时延码激励线性预测。

G.728是低比特线性预测合成分析编码器（G.729和G.723.1）和后向ADPCM编码器的混合体。G.728是LD-CELP编码器，它一次只处理5个样点。对于低速率（56~128 kbps）的综合业务数字网（ISDN）可视电话，G.728是一种建议采用的语音编码器。由于其后向自适应特性，因此G.728是一种低时延编码器，但它比其它的编码器都复杂，这是因为在编码器中必须重复做50阶LPC分析。G.728还采用了自适应后置滤波器来提高其性能。

实时音频通讯编码标准：G.729

制定者：ITU-T
所需带宽：8Kbps
音频宽度：3.4KHZ
特性：在良好的信道条件下要达到长话质量，在有随机比特误码、发生帧丢失和多次转接等情况下要有很好的稳健性等。这种语音压缩算法可以应用在很广泛的领域中，包括ＩＰ电话、无线通信、数字卫星系统和数字专用线路。

G.729算法采用“共轭结构代数码本激励线性预测编码方案”（CS-ACELP）算法。这种算法综合了波形编码和参数编码的优点，以自适应预测编码技术为基础，采用了矢量量化、合成分析和感觉加权等技术。

G.729编码器是为低时延应用设计的，它的帧长只有10ms，处理时延也是10ms，再加上5ms的前视，这就使得G.729产生的点到点的时延为25ms，比特率为8 kbps。
优点：语音质量良，应用领域很广泛，采用了矢量量化、合成分析和感觉加权，提供了对帧丢失和分组丢失的隐藏处理机制。
缺点：在处理随机比特错误方面性能不好。
备注：国际电信联盟（ITU-T）于1995年11月正式通过了G.729。ITU-T建议G.729也被称作“共轭结构代数码本激励线性预测编码方案”(CS-ACELP)，它是当前较新的一种语音压缩标准。G.729是由美国、法国、日本和加拿大的几家著名国际电信实体联合开发的。

实时音频通讯编码标准：G.729A

制定者：ITU-T
所需带宽：8Kbps(34.4)
音频宽度：3.4KHZ
特性：复杂性较G.729低，性能较G.729差。
优点：语音质量良，降低了计算的复杂度以便于实时实现，提供了对帧丢失和分组丢失的隐藏处理机制
缺点：性能较G.729差
备注：96年ITU-T又制定了G.729的简化方案G.729A，主要降低了计算的复杂度以便于实时实现，因此目前使用的都是G.729A。

实时音频通讯编码标准：MPEG-1 audio layer 1

制定者：MPEG
所需带宽：384kbps（压缩4倍）
音频宽度：
特性：编码简单，用于数字盒式录音磁带，2声道，VCD中使用的音频压缩方案就是MPEG-1层Ⅰ。
优点：压缩方式相对时域压缩技术而言要复杂得多，同时编码效率、声音质量也大幅提高，编码延时相应增加。可以达到“完全透明”的声音质量（EBU音质标准）
缺点：频宽要求较高
备注：MPEG-1声音压缩编码是国际上第一个高保真声音数据压缩的国际标准，它分为三个层次：
--层1(Layer 1)：编码简单，用于数字盒式录音磁带
--层2(Layer 2)：算法复杂度中等，用于数字音频广播(DAB)和VCD等
--层3(Layer 3)：编码复杂，用于互联网上的高质量声音的传输，如MP3音乐压缩10倍

实时音频通讯编码标准：MPEG-1 audio layer 2，即MP2

制定者：MPEG
所需带宽：256～192kbps（压缩6～8倍）
音频宽度：
特性：算法复杂度中等，用于数字音频广播(DAB)和VCD等，2声道，而MUSICAM由于其适当的复杂程度和优秀的声音质量，在数字演播室、DAB、DVB等数字节目的制作、交换、存储、传送中得到广泛应用。
优点：压缩方式相对时域压缩技术而言要复杂得多，同时编码效率、声音质量也大幅提高，编码延时相应增加。可以达到“完全透明”的声音质量（EBU音质标准）
缺点：无记录
备注：同MPEG-1 audio layer 1

实时音频通讯编码标准：MPEG-1 audio layer 3(MP3)

制定者：MPEG
所需带宽：128～112kbps（压缩10～12倍）
音频宽度：无记录
特性：编码复杂，用于互联网上的高质量声音的传输，如MP3音乐压缩10倍，2声道。MP3是在综合MUSICAM和ASPEC的优点的基础上提出的混合压缩技术，在当时的技术条件下，MP3的复杂度显得相对较高，编码不利于实时，但由于MP3在低码率条件下高水准的声音质量，使得它成为软解压及网络广播的宠儿。
优点：压缩比高，适合用于互联网上的传播
缺点：MP3在128KBitrate及以下时，会出现明显的高频丢失
备注：同MPEG-1 audio layer 1

实时音频通讯编码标准：MPEG-2 audio layer

制定者：MPEG
所需带宽：与MPEG-1层1，层2，层3相同
音频宽度：无记录
特性：MPEG-2的声音压缩编码采用与MPEG-1声音相同的编译码器，层1, 层2和层3的结构也相同，但它能支持5.1声道和7.1声道的环绕立体声。
优点：支持5.1声道和7.1声道的环绕立体声
缺点： 无记录
备注：MPEG-2的声音压缩编码采用与MPEG-1声音相同的编译码器，层1, 层2和层3的结构也相同，但它能支持5.1声道和7.1声道的环绕立体声。

实时音频通讯编码标准：AAC-LD (dvanced Audio Coding，先进音频编码)

制定者：MPEG
所需带宽：48-64 kbps
音频宽度：22KHZ
特性：提供高质量的低延时的音频编码标准，以其20ms的算法延时提供更高的比特率和各种声音信号的高质量音频。
缺点：无记录
备注：超宽带编解码器技术支持高达48KHz采样率的语音传输，与传统的窄带与宽带语音编解码器相比大幅提高了音质。该技术可提供接近CD音质的音频，数据速率高达48–64kbps，不仅提高了IP语音与视频应用的清晰度，而且支持电话音乐传输功能。高清语音通道支持更高的采样率，配合音频编解码器的高保真音效，显著丰富并扩展了频谱两端的音质范围，有效改善了语音回响性能，提高了清晰度。

附录1：更多实时音视频技术文章

[1] 开源实时音视频技术WebRTC的文章：
《开源实时音视频技术WebRTC的现状》
《简述开源实时音视频技术WebRTC的优缺点》
《访谈WebRTC标准之父：WebRTC的过去、现在和未来》
《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》
《WebRTC实时音视频技术的整体架构介绍》
《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》
《WebRTC实时音视频技术基础：基本架构和协议栈》
《浅谈开发实时视频直播平台的技术要点》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《实时通信RTC技术栈之：视频编解码》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》
>> 更多同类文章 ……

[2] 实时音视频开发的其它精华资料：
《专访微信视频技术负责人：微信实时视频聊天技术的演进》
《实时语音聊天中的音频处理与编码压缩技术简述》
《网易视频云技术分享：音频处理与压缩技术快速入门》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《声网架构师谈实时音视频云的实现难点(视频采访)》
《浅谈开发实时视频直播平台的技术要点》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡》
《如何用最简单的方法测试你的实时音视频方案》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《移动端实时音视频直播技术详解（一）：开篇》
《移动端实时音视频直播技术详解（二）：采集》
《移动端实时音视频直播技术详解（三）：处理》
《移动端实时音视频直播技术详解（四）：编码和封装》
《移动端实时音视频直播技术详解（五）：推流和传输》
《移动端实时音视频直播技术详解（六）：延迟优化》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《IM实时音视频聊天时的回声消除技术详解》
《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》
《如何优化传输机制来实现实时音视频的超低延迟？》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《Android直播入门实践：动手搭建一套简单的直播系统》
《网易云信实时视频直播在TCP数据传输层的一些优化思路》
《实时音视频聊天技术分享：面向不可靠网络的抗丢包编解码器》
>> 更多同类文章 ……

附录2：全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

（原文链接：点此进入）

有时间一定要每天都看一下.扩展下网络编程也好

收藏

收藏

感谢分享