亚洲色成人网站www永久,亚洲欧美人成视频一区在线,亚洲国产成人高清在线观看,亚洲精品久久久久久动漫,亚洲国产精品久久电影欧美

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
INTEGER可以用來存儲一個有符號的整數(shù),范圍從-2147483648 到 2147483647, 或者一個無符號的整數(shù),范圍從 0到 4294967295 。
如何指定數(shù)據(jù)類型為無符號整數(shù)呢？
UINTEGER？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
如題,一直沒有用過消息隊列,現(xiàn)在經(jīng)常需要內部各個系統(tǒng)之間通信。經(jīng)過一番查找資料,覺得MQ非常合適。但是沒有在生產(chǎn)環(huán)境的示例,不知道如何下手。。
想請教各位大神,你們的系統(tǒng)中MQ是如何使用的。
是下載activeMQ/rabbitMq 配置好參數(shù),直接使用？
或者經(jīng)過封裝,如果封裝,應該怎么封裝法呢？
求各位大神給個思路！

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
遇到的問題：我希望是服務器完全啟動完畢后activemq才開始接受消息處理。

但是,用spring配置activemq,spring文件一旦初始化。activemq就開始接收消息處理了

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
描述：
使用的是spring boot框架。單個系統(tǒng),假設叫做 系統(tǒng)B (系統(tǒng)內部)使用active mq 生產(chǎn)者、消費者都是正常的已經(jīng)實現(xiàn)?，F(xiàn)在有其他系統(tǒng)的時候,怎么調用。比如A系統(tǒng)是生產(chǎn)者,想要把消息發(fā)送給系統(tǒng)B。讓B來消費。這種怎么實現(xiàn)？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>> 最近在研究activeMQ,我們項目使用的有MQ消息傳遞。需要定時清理沒有消費者的,但是未消費消息不為0的數(shù)據(jù),因為沒有消費者消費這些消息,還有可能會往這個隊列上發(fā)數(shù)據(jù),研究幾天無果,求大神幫助

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
現(xiàn)在是在注解中配置隊列,如何在配置文件中配置。然后注解中直接引用？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
大佬們,請教下ffmpeg是如何做多平臺適配的？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
命令推拉失敗
##ffmpeg -i http://xxxx/1/live.m3u8 -f flv -y rtmp://127.0.0.1:9006/live/xxxx
命令推拉成功
##ffmpeg -i http://xxxx/1/live.m3u8 -c copy -f flv -y rtmp://127.0.0.1:9006/live/xxxx
求助各位大佬,有人知道怎么回事嗎？第一個命令剛開始是可以執(zhí)行的,但是執(zhí)行過幾個之后,就不再推送（上傳）數(shù)據(jù),變成下面這樣
`frame= 0 fps=0.0 q=0.0 Lsize= 0kB time=00:00:00.00 bitrate=N/A dup=0 drop=1020 speed= 0x`
用第二個的確可以成功,但是這樣就不能調整分辨率,比特率等等調節(jié)畫面的屬性了。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
下面是使用ffmpeg對rtsp流進行錄像的代碼,程序運行后,內存一直不停的往上漲,網(wǎng)上查過都說是內存泄露造成的,可是具體哪里泄露了,折騰好久了沒找到原因。哪位熟悉ffmpeg的仁兄,幫忙看看,謝過！ void saveRtsp() { AVFormatContext *pFormatCtx = nullptr; // FFMPEG所有的操作都要通過這個AVFormatContext來進行 AVCodecContext *pCodecCtx = nullptr; AVCodec *pCodec = nullptr; AVFrame *pFrame = nullptr, *pFrameRGB = nullptr; AVPacket *packet = nullptr; uint8_t *out_buffer = nullptr; struct SwsContext *img_convert_ctx = nullptr; AVDictionary *avdic = nullptr; AVDictionary *params = nullptr; int videoStream, numBytes; long start = 0, finish = 0; int frames = 0; // 保存的packet數(shù)量 // 初始化 avformat_network_init(); // 初始化FFmpeg網(wǎng)絡模塊 av_register_all(); // 初始化FFMPEG 調用了這個才能正常適用編碼器和解碼器 pFormatCtx = avformat_alloc_context(); // 分配一個AVFormatContext,查找用于輸入的設備 av_dict_set(&avdic, "rtsp_transport", "tcp", 0); av_dict_set(&avdic, "max_delay", "100", 0); //av_dict_set(&avdic, "probesize", "32000000", 0); av_dict_set(&avdic, "max_analyze_duration", "1000", 0); av_dict_set(&avdic, "buffer_size", "1024000", 0); av_dict_set(&avdic, "stimeout", "2000000", 0); // 如果沒有設置stimeout if (avformat_open_input(&pFormatCtx, rtspMain.c_str(), NULL, &avdic) != 0) { cout<<"打不開視頻,請檢查路徑是否正確："<nb_streams; i++) { if (pFormatCtx->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO) { videoStream = i; break; } } if (videoStream == -1) { cout<<"無法播放,找不到視頻流："<streams[videoStream]->codecpar); pCodec = avcodec_find_decoder(pCodecCtx->codec_id); //指向AVCodec的指針.查找解碼器 pCodecCtx->bit_rate = 0; // 初始化為0 pCodecCtx->time_base.num = 1; // 下面兩行：一秒鐘25幀 pCodecCtx->time_base.den = 25; pCodecCtx->frame_number = 1; // 每包一個視頻幀 if (pCodec == NULL) { cout<<"無法播放,找不到解碼器："<codec_id == AV_CODEC_ID_H264) { av_dict_set(¶ms, "preset", "superfast", 0); av_dict_set(¶ms, "tune", "zerolatency", 0); } else if(pCodecCtx->codec_id == AV_CODEC_ID_H265) { av_dict_set(¶ms, "x265-params", "qp=20", 0); av_dict_set(¶ms, "preset", "ultrafast", 0); av_dict_set(¶ms, "tune", "zero-latency", 0); } // 打開解碼器 if (avcodec_open2(pCodecCtx, pCodec, ¶ms) < 0) { cout<<"無法播放,無法打開解碼器："<width, pCodecCtx->height, pCodecCtx->pix_fmt, pCodecCtx->width, pCodecCtx->height, AV_PIX_FMT_RGB32, SWS_BICUBIC, NULL, NULL, NULL); numBytes = avpicture_get_size(AV_PIX_FMT_RGB32, pCodecCtx->width, pCodecCtx->height); out_buffer = (uint8_t *) av_malloc(numBytes * sizeof(uint8_t)); avpicture_fill((AVPicture *) pFrameRGB, out_buffer, AV_PIX_FMT_RGB32, pCodecCtx->width, pCodecCtx->height); int y_size = pCodecCtx->width * pCodecCtx->height; packet = (AVPacket *) malloc(sizeof(AVPacket)); // 分配一個packet //av_new_packet(packet, y_size); // 分配packet的數(shù)據(jù) av_init_packet(packet); cout<stream_index == videoStream) { frames++; //fwrite(packet->data, 1, packet->size, fpSave); // 寫數(shù)據(jù)到文件中 } av_packet_unref(packet); av_free_packet(packet); } end: if(packet) { av_packet_unref(packet); av_free_packet(packet); } if(avdic) av_free(avdic); if(params) av_free(params); sws_freeContext(img_convert_ctx); av_free(out_buffer); av_frame_free(&pFrameRGB); av_frame_free(&pFrame); avcodec_close(pCodecCtx); avcodec_free_context(&pCodecCtx); avformat_free_context(pFormatCtx); }

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
@卻又讓幽蘭枯萎 你好,想跟你請教個問題：我是?？档臄z像頭,地址如下： ffmpeg -i "rtsp://admin:EUEZAD@192.168.2.12:554/h264/ch1/sub/av_stream" -q 0 -f mpegts -codec:v mpeg1video -s 1366x768 http://127.0.0.1:8081/supersecret
現(xiàn)在出現(xiàn)下面的錯誤,望大神指點,MPEG-1/2 does not support 15/1 fps
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
目前有個項目需要實現(xiàn)把?？档臄z像頭集中起來在網(wǎng)頁中,去在網(wǎng)頁中去實現(xiàn)?？底约旱某绦蛩軐崿F(xiàn)的功能,對攝像頭錄像的實時播放,回話,有云臺的控制,這些都移植到網(wǎng)頁上,攝像頭和瀏覽器都是在一個局域網(wǎng),暫不考慮遠程訪問,要求能同時100路訪問,我現(xiàn)在是猜想,手里還沒拿到硬件,還沒辦法做實驗,
猜想是這樣子的,攝像頭取流都用rtsp協(xié)議取流,直接在網(wǎng)頁上進行播放。下面rtsp舉例內容來源于網(wǎng)絡搜索。。 【?？低暋颗e例說明： 主碼流取流: rtsp://admin:12345@192.0.0.64:554/h264/ch1/main/av_stream 子碼流取流: rtsp://admin:12345@192.0.0.64:554/h264/ch1/sub/av_stream 如果攝像機密碼是a12345678,IP是192.168.1.64,RTSP端口默認554未做改動,是H.264編碼,那么 主碼流取流: rtsp://admin:a12345678@192.168.1.64:554/h264/ch1/main/av_stream 子碼流取流: rtsp://admin:a12345678@192.168.1.64:554/h264/ch1/sub/av_stream 【如果是H.265編碼的,那么將H.264替換成H.265即可】
在網(wǎng)頁上用9個播放器,播放rtsp流,用來組成畫面墻,

至于控制這塊,?？堤峁┑挠蠸DK,網(wǎng)頁上提供對應的按鈕,后臺JAVA程序來調用對應的接口來控制設備。
不知道這樣的技術方案,是否能滿足？如果不滿足,應該用什么技術來實現(xiàn)把海康攝像頭移植到網(wǎng)頁上去播放,
我看了有好多用ffmpeg去做,取流后再做流服務器,這種方法來做直播,這樣如果有100臺被訪問,是不是需要有100個ffmpeg線程在跑,那服務器需要多大配置才能滿足呢？
還有,用戶那邊開了一個窗口后,后臺開啟Ffmpeg后,用戶看了一會又關了,怎么管理這些后臺開啟的ffmpeg?
一臉懵,從來沒做過類似的東西,現(xiàn)在硬著頭再啃這塊東西,希望做過的朋友能幫忙給點意見。。。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
我使用ffmpeg 切好的視頻文件,vlc 播放器加裝m3u8 可以播放,但是沒法在Safari里面播放,
ffmpeg -i install.mp4 -acodec libvo_aacenc -vcodec libx264 -s 720x480 -hls_time 10 -hls_list_size 10000 playlist.m3u8

切好的m3u8
#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:17 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:15.166667, playlist0.ts #EXTINF:8.333333, playlist1.ts #EXTINF:8.333333, playlist2.ts #EXTINF:8.333333, playlist3.ts #EXTINF:16.666667, playlist4.ts #EXTINF:7.733333, playlist5.ts #EXTINF:8.333333, playlist6.ts #EXTINF:8.333333, playlist7.ts #EXTINF:16.666667, playlist8.ts #EXTINF:8.333333, playlist9.ts #EXTINF:8.333333, playlist10.ts #EXTINF:8.333333, playlist11.ts #EXTINF:8.333333, playlist12.ts #EXTINF:16.666667, playlist13.ts #EXTINF:8.333333, playlist14.ts #EXTINF:8.333333, playlist15.ts #EXTINF:8.333333, playlist16.ts #EXTINF:9.466667, playlist17.ts #EXTINF:6.700000, playlist18.ts #EXT-X-ENDLIST

剛接觸流媒體 這塊 ,還請大家指點一下

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
本人利用業(yè)余時間寫了一個簡單的播放器, 已開源, 見 https://github.com/Jackarain/avplayer
在release目錄下, 可以下載可執(zhí)行程序, 目前暫時只支持windows平臺, 希望有興趣的朋友一起參與開發(fā).

HDC調試需求開發(fā)（15萬預算）,能者速來！>>> ffmpeg的ffplayer程序使用過了SDL庫,有用過的講講實際經(jīng)驗吧。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
求教：ffmpeg轉換視頻完成之后,怎么通知調用者視頻轉碼成功與失敗呢？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
求教：現(xiàn)在我的上游系統(tǒng)傳給我m3u8格式文件,我這里需要將該文件轉成mp4(通過格式),在轉碼成多種碼率,給下游使用。
請問：java程序,linux環(huán)境(docker內)下,怎么樣才能將m3u8格式轉成mp4格式視頻？上游系統(tǒng)提供了ffmepg方式,不知道ffmepg可以轉不？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
最近需要拉流,流A在國外,需要先拉到國內流B,用戶去流B上面觀看。
使用ffmpeg -i http://a.m3u8 -c copy b.m3u8命令拉下來后,觀看b.m3u8幾秒鐘就卡頓一次,沒辦法看,但是直接在國內觀看a.m3u8是不卡的,因為是買的一個,所以不能觀看A.M3U8,需要類似中?；蛘邠Q成一下,會的朋友告訴下,是不是參數(shù)加錯了,感謝了。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>> 最近做的項目需要視頻轉換器ffmpeg,代碼和程序我都有,路徑也對,可是奇怪的是我在純javaProject的環(huán)境下運行代碼,可以很順利的將a.avi轉換成a.flv,但是我把代碼復制到我的web Project中時,程序不異常,運行各方面都正常,路徑更是對的沒話說,可是就是轉換不成flv文件,凌亂了,是不是在web中還需要什么東西？為什么會這么奇怪？這是代碼： package org.whhn.utils; import java.io.File; import java.util.ArrayList; import java.util.Calendar; import java.util.List; public class ConvertVideo { public static boolean process(String PATH,String relname,String shortname) { int type = checkContentType(PATH); boolean status = false; if (type == 0) { System.out.println("直接將文件轉為flv文件"); status = processFLV(PATH,relname,shortname);// 直接將文件轉為flv文件 } else if (type == 1) { //String avifilepath = processAVI(type); //if (avifilepath == null) return false;// avi文件沒有得到 // status = processFLV(avifilepath);// 將avi轉為flv } return status; } private static int checkContentType(String PATH) { String type = PATH.substring(PATH.lastIndexOf(".") + 1, PATH.length()) .toLowerCase(); // ffmpeg能解析的格式：（asx,asf,mpg,wmv,3gp,mp4,mov,avi,flv等） if (type.equals("avi")) { return 0; } else if (type.equals("mpg")) { return 0; } else if (type.equals("wmv")) { return 0; } else if (type.equals("3gp")) { return 0; } else if (type.equals("mov")) { return 0; } else if (type.equals("mp4")) { return 0; } else if (type.equals("asf")) { return 0; } else if (type.equals("asx")) { return 0; } else if (type.equals("flv")) { return 0; } // 對ffmpeg無法解析的文件格式(wmv9,rm,rmvb等), // 可以先用別的工具（mencoder）轉換為avi(ffmpeg能解析的)格式. else if (type.equals("wmv9")) { return 1; } else if (type.equals("rm")) { return 1; } else if (type.equals("rmvb")) { return 1; } return 9; } private static boolean checkfile(String path) { File file = new File(path); if (!file.isFile()) { return false; } return true; } // 對ffmpeg無法解析的文件格式(wmv9,rm,rmvb等), 可以先用別的工具（mencoder）轉換為avi(ffmpeg能解析的)格式. /* private static String processAVI(int type) { List commend = new ArrayList(); commend.add("d:\\ffmpeg\\mencoder"); commend.add(PATH); commend.add("-oac"); commend.add("lavc"); commend.add("-lavcopts"); commend.add("acodec=mp3:abitrate=64"); commend.add("-ovc"); commend.add("xvid"); commend.add("-xvidencopts"); commend.add("bitrate=600"); commend.add("-of"); commend.add("avi"); commend.add("-o"); commend.add("d:\\ffmpeg\\output\\b.avi"); try { ProcessBuilder builder = new ProcessBuilder(); builder.command(commend); builder.start(); return "d:\\ffmpeg\\output\\b.avi"; } catch (Exception e) { e.printStackTrace(); return null; } } */ // ffmpeg能解析的格式：（asx,asf,mpg,wmv,3gp,mp4,mov,avi,flv等） private static boolean processFLV(String oldfilepath,String relname,String shortname) { System.out.println(oldfilepath); if (!checkfile(oldfilepath)) { System.out.println(oldfilepath + " is not file"); return false; } // 文件命名 Calendar c = Calendar.getInstance(); String savename = String.valueOf(c.getTimeInMillis())+ Math.round(Math.random() * 100000); List commend = new ArrayList(); commend.add("d:\\apache-tomcat-7.0.42\\webapps\\Whhn\\CuPlayer\\ffmpeg"); commend.add("-i"); commend.add(oldfilepath); commend.add("-ab"); commend.add("56"); commend.add("-ar"); commend.add("22050"); commend.add("-qscale"); commend.add("8"); commend.add("-r"); commend.add("15"); commend.add("-s"); commend.add("600x500"); commend.add("d:\\apache-tomcat-7.0.42\\webapps\\Whhn\

HDC調試需求開發(fā)（15萬預算）,能者速來！>>> http://blog.sina.com.cn/s/blog_4a424eca010005l2.html

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
系統(tǒng):deepin 15.9
ffmpeg 版本:4.1
vaifo: libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_0 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.0) vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Desktop - 2.0.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD
小弟使用希望使用ffmpeg的vaapi進行硬解。使用sudo ./configure --disable-static --enable-shared --enable-gpl --enable-version3 --enable-vaapi來編譯ffmpeg源碼,源碼編譯成功,并成功安裝。然后想運行ffmpeg官方的有關硬解的例子進行學習。故編譯了官方的例子vaapip_transcode.c hw_decode.c兩個例子,也都編譯通過.但是在運行兩個例子的出現(xiàn)出現(xiàn)如下錯誤:
轉換到源碼中查看是由于下面的回調函數(shù)出問題。即*p != AV_PIX_FMT_VAAPI static enum AVPixelFormat get_vaapi_format(AVCodecContext *ctx, const enum AVPixelFormat *pix_fmts) { const enum AVPixelFormat *p; for (p = pix_fmts; *p != AV_PIX_FMT_NONE; p++) { if (*p == AV_PIX_FMT_VAAPI) return *p; } fprintf(stderr, "Unable to decode this file using VA-API.\n"); return AV_PIX_FMT_NONE; }

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
@紅薯 你好,想跟你請教個問題：我在您提示的鏈接： http://ffdshow.faireal.net/mirror/ffmpeg/ ,沒辦法打開網(wǎng)頁下載。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
本文來自網(wǎng)易云音樂音視頻實驗室負責人劉華平在LiveVideoStackCon 2017大會上的分享,并由LiveVideoStack根據(jù)演講內容整理而成（本次演講PPT文稿,請從文末附件下載）。
1、引言
大家好,我是劉華平,從畢業(yè)到現(xiàn)在我一直在從事音視頻領域相關工作,也有一些自己的創(chuàng)業(yè)項目,曾為早期Google Android SDK多媒體架構的構建作出貢獻。
就音頻而言,無論是算法多樣性,Codec種類還是音頻編解碼復雜程度都遠遠比視頻要高。視頻的Codec目前還主要是以宏塊為處理單元,預測加變換的混合編碼框架,例如H.264和H.265都是在這一框架下。而音頻則相當復雜,且不同的場景必須要選擇不同的音頻編解碼器。以下就是本次為大家分享的主要內容,希望通過此次分享可以使大家對音頻編解碼有一個整體的認識,并在實際應用中有參考的依據(jù)。
本次分享的內容提綱： 1）語音／音頻編碼總表；
2）數(shù)字語音基本要素；
3）為什么要壓縮；
4）編碼器考慮的因素；
5）語音經(jīng)典編碼模型；
6）ISO；
7）編碼模型；
8）USAC；
9）編碼；
10）使用選型考慮的因素。
* 本次演講PPT文稿,請從文末附件下載！
（本文同步發(fā)布于： http://www.52im.net/thread-2230-1-1.html ）
2、分享者
劉華平：
- 現(xiàn)為網(wǎng)易云音樂音視頻實驗室負責人,上海大學通信學院在職博士；
- 曾任掌門集團（WIFI萬能鑰匙）音視頻技術研發(fā)總監(jiān),資深研究員；
- 行者悟空聲學技術有限公司首席技術官(聯(lián)合創(chuàng)始人)；
- 阿里巴巴前高級技術專家(P8), 阿里音樂音視頻部門總監(jiān)；
- Visualon音頻部門經(jīng)理、盛大創(chuàng)新院研究員、Freescale 上海研發(fā)中心多媒體部門；
- 早期 Google Android SDK多媒體架構的貢獻者,開源 AMR_WB 編碼器工程開發(fā)者。
劉華平擁有5項技術發(fā)明專利、二十余篇專業(yè)論文和多項軟件著作權,參與過浙江省杭州重大專項項目,浙江省金華科委項目,上海市科委項目(球諧域全景音頻關鍵技術研究)。
3、系列文章
本文是系列文章中的第18篇,本系列文章的大綱如下： 《 即時通訊音視頻開發(fā)（一）：視頻編解碼之理論概述 》
《 即時通訊音視頻開發(fā)（二）：視頻編解碼之數(shù)字視頻介紹 》
《 即時通訊音視頻開發(fā)（三）：視頻編解碼之編碼基礎 》
《 即時通訊音視頻開發(fā)（四）：視頻編解碼之預測技術介紹 》
《 即時通訊音視頻開發(fā)（五）：認識主流視頻編碼技術H.264 》
《 即時通訊音視頻開發(fā)（六）：如何開始音頻編解碼技術的學習 》
《 即時通訊音視頻開發(fā)（七）：音頻基礎及編碼原理入門 》
《 即時通訊音視頻開發(fā)（八）：常見的實時語音通訊編碼標準 》
《 即時通訊音視頻開發(fā)（九）：實時語音通訊的回音及回音消除概述 》
《 即時通訊音視頻開發(fā)（十）：實時語音通訊的回音消除技術詳解 》
《 即時通訊音視頻開發(fā)（十一）：實時語音通訊丟包補償技術詳解 》
《 即時通訊音視頻開發(fā)（十二）：多人實時音視頻聊天架構探討 》
《 即時通訊音視頻開發(fā)（十三）：實時視頻編碼H.264的特點與優(yōu)勢 》
《 即時通訊音視頻開發(fā)（十四）：實時音視頻數(shù)據(jù)傳輸協(xié)議介紹 》
《 即時通訊音視頻開發(fā)（十五）：聊聊P2P與實時音視頻的應用情況 》
《 即時通訊音視頻開發(fā)（十六）：移動端實時音視頻開發(fā)的幾個建議 》
《 即時通訊音視頻開發(fā)（十七）：視頻編碼H.264、V8的前世今生 》
《 即時通訊音視頻開發(fā)（十八）：詳解音頻編解碼的原理、演進和應用選型 》（本文）
4、語言/音頻編碼總表
▲ 語言/音頻編碼總表
上圖展示的是語言/音頻編碼總表,可以看到其比視頻編碼要復雜得多,單純的算法也遠遠比視頻要更加復雜。
5、數(shù)字語言基本要素
數(shù)字聲音具有三個要素： 1）采樣率；
2）通道數(shù)；
3）量化位數(shù)。

▲ 聲音數(shù)字化的過程
如上圖所示,聲音數(shù)字化的過程為： 1）采樣：在時間軸上對信號數(shù)字化；
2）量化：在幅度軸上對信號數(shù)字化；
3）編碼：按一定格式記錄采樣和量化后的數(shù)字數(shù)據(jù)。
6、為什么要壓縮
壓縮音頻,主要是為了在降低帶寬負擔的同時為視頻騰出更多帶寬空間。存儲和帶寬二大因素決定了語音壓縮的必要性。
我們看看下面的例子。
長度為4分鐘,采樣頻率為44100Hz,采樣深度為16bits,雙聲音Wav文件大?。?44100Hz*16bits*4minutes*2=(44100/1second)*16bits*(4minutes*(60seconds/1minutes)*2=705600bits/second*240seconds=169344000bits=169344000/(8bits/1byte)*2=42336000bytes=42336000/(1048576/1M)bytes=40.37MB
MP3,128kbps壓縮后文件大?。?128kbps*4minutes=(128kbits/1second)*(4minutes*(60seconds/1minutes))=(128kbits/1second)*240seconds=30720kbits=30720kbits/(8bits/1byte)=3840kbytes=3840k/(1024k/1M)bytes=3.75Mbytes=3.75MB
正如上面的例子,聲音壓縮后,存儲大小為原大小的十分之一,壓縮率十分可觀！
7、編碼器考慮因素
7.1 基本概念
編碼器考慮的因素： 1）最佳壓縮比；
2）算法的復雜度；
3）算法延時；
4）針對特殊場景下的特定設計；
5）兼容性。
通過一些特定的壓縮算法,可以壓縮音頻文件至原來的1/10,同時人耳也無法分辨壓縮前后的聲音質量差異,需要滿足多種條件才能實現(xiàn)這種效果；而對于編碼器,無論是設計階段還是使用階段,我們都需要考慮最佳壓縮效果、算法的復雜度與算法的延時,結合特殊場景進行特定的設計；而兼容性也是我們不能不考慮的重點。
7.2 語音經(jīng)典編碼模型：發(fā)音模型
▲ 發(fā)音模型（ 原圖點擊查看 ）
我們的很多編解碼器都是基于綜合人的發(fā)音模型與一些和聽覺相關的理論支持研究提出的特定編解碼算法。初期我們通過研究人的發(fā)音原理來設計音頻編解碼的算法,包括端到端的濾波或輕濁音等,只有充分理解人的發(fā)聲原理我們才能在編解碼端做出有價值的優(yōu)化。
【7.2.1】語音編碼模型——LPC：
▲ 經(jīng)典語音編碼模型：LPC（ 原圖點擊查看 ）

▲ LPC 數(shù)學表達
LPC作為經(jīng)典語音編碼模式,其本質是一個線性預測的過程。早期的G.7系列編碼模型便是通過此模型對整個語音進行編碼,上圖展示的過程可與之前的人發(fā)聲過程進行匹配,每個環(huán)節(jié)都有一個相應的模塊用來支撐人發(fā)聲的過程。其中使用了AR數(shù)學模型進行線性預測,此算法也是現(xiàn)在很多語音編碼的重要組成模塊。
【7.2.2】語音編碼模型——G.729：

▲經(jīng)典語音編碼模型: G.729(CELP)
G.729同樣是經(jīng)典的語音編碼模型之一,也是我們學習語音編碼的一個入門級Codec。G.729的文檔十分完善,包括每個模塊的源代碼在內都可直接下載。G.729可以說是在早期發(fā)聲模型基礎上的改進,需要關注的性能指標是幀長與算法上的延時,包括語音質量的MOS分。G.729也有很多變種,由于語音需要考慮系統(tǒng)兼容性,不同的系統(tǒng)指定攜帶的Codec也不同,音頻編碼的復雜程度要遠高于視頻編碼。
G.729 建議了共軛結構的算術碼本激勵線性預測(CS-ACELP)編碼方案。G.729算法的幀長為10ms, 編碼器含5ms 前瞻,算法時延15ms,語音質量MOS分可達4.0。
7.3 語音經(jīng)典編碼模型——聽覺模型
▲ ISO編碼模型：心理聲學模型
除了研究人發(fā)聲的原理,我們還需要研究人聽聲的原理,從而更好實現(xiàn)聲音的收集與處理。一個聲音信號是否能被人耳聽見主要取決于聲音信號的頻率、強度與其他音的干擾。心理聲學模型便是用來找出音頻信號中存在的冗余信息從而實現(xiàn)在壓縮聲音信號的同時不影響聽覺的目的。心理聲學理論的成熟為感知編碼系統(tǒng)奠定了理論基礎,這里的感知編碼主要是ISO編碼模型,主要覆蓋的聲學原理有臨界頻帶、絕對聽覺閾值、頻域掩蔽、時域掩蔽等。
▲ 聽覺模型
無論是MP3還是AAC以至于到后面的杜比音效都是基于聽覺模型進行的探索與創(chuàng)新。
【7.3.1】臨界頻帶：
由于聲音頻率與掩蔽曲線不是線性關系,為從感知上來統(tǒng)一度量聲音頻率,引入了“臨界頻帶”的概念。通常認為,在20Hz到16kHz范圍內有24個監(jiān)界頻帶。臨界頻帶的單位叫Bark(巴克)。
▲ 臨界頻帶
臨界頻帶主要用于心理聲學模型。由于聲音頻率與掩蔽曲線并非線性關系,為從感知上來統(tǒng)一度量聲音頻率,我們引入了“臨界頻帶”的概念。人耳對每段的某個頻率的靈敏度不同,二者關系是非線性的。通常我們會將人可以聽到的整個頻率也就是從20Hz到16KHz分為24個頻帶,可在其中進行時域或頻域類的掩蔽,將一些冗余信息從編碼中去除從而有效提升壓縮率。
【7.3.2】絕對聽覺閾值：

▲ 絕對聽覺閾值
絕對聽覺閾值也可有效提升壓縮率,基于心理聲學模型,可去除編碼中的冗余部分。
7.4 經(jīng)典音頻編碼：ISO
▲ 經(jīng)典音頻編碼：ISO
我們可將最早的MP3 Layer1理解為第一代的ISO感知編碼,隨后的一些純量化內容更多的是在壓縮上進行改進而核心一直未改變。從MP3 Layer1到Layer2與Layer3,主要的改變是心理聲學模型的迭代。
▲ MPEG1 LayerI Codec
▲ MPEG1 LayerIII Codec
上圖展示的是Encode與Decode的回路。輸入的PCM首先會經(jīng)過多子帶分析與頻域中的心理聲學模型冗余處理,而后進行量化編碼；Layer III中的是我們現(xiàn)在常說的MP3的Codec：Encode與Decode之間的整體回路,相比于Layer1多了幾個處理環(huán)節(jié)以及霍夫曼編碼。
7.5 AAC協(xié)議族
▲ AAC家族
AAC與G.719一樣包括很多系列,但AAC的巧妙之處在于向下兼容的特性。開始時我們就強調,所有Codec在設計時都需要考慮兼容性,瑞典的Coding Technology公司曾提出在兼容性上特別優(yōu)化的方案。AAC Plus V1包括AAC與SBR,AAC Plus V2包括AAC+SBR+PS,現(xiàn)在常見的很多音樂類或直播音頻編碼都是基于AAC Plus協(xié)議族進行的。
德國的霍朗浦學院曾在AAC低延時協(xié)議擴展方面做出一些探索并得到了AAC LD協(xié)議族,其原理仍基于傳統(tǒng)的AAC模塊,但在后端會對處理長度進行調整,例如之前是以1024bit為一個處理單位,那改進后則以960bit為一個處理單位。除此之外AAC LD加入了LD-SBR與LD-MPS等,從而形成一個規(guī)模較大的AAC-ELD V2模塊,可以說是十分巧妙。
【7.5.1】AACPlus核心模塊——SBR（Spectral Band Replication）：

▲ SBR(Spectral Band Replication)
我們可以看到,AAC可以說充分利用了頻域擴展,用很小的代價實現(xiàn)諸多功能優(yōu)化。AAC的核心之一是SBR,這是一種使用極少位數(shù)就可描述高頻部分并在解碼時進行特殊優(yōu)化從而實現(xiàn)頻域擴展的模塊。上圖展示的是不同壓縮率模塊所覆蓋的頻率取值范圍,而使用AAC時需要注意一個被稱為“甜點碼率”的指標。無論是采樣率還是碼率都是變化的,在應用時選擇何種碼率十分關鍵。例如直播時采用64Kbps即可在覆蓋整個頻段的同時保持良好音質。
【7.5.2】AACPlus核心模塊——PS（Parametric Stereo）：

▲ ：PS(Parametric Stereo)
PS 描述參數(shù)：IID(Inter-channel Intensity Difference),,ICC(Inter-channel Cross-Correlation),IPD(Inter-channel Phase Difference)。

▲ AACPlus v2編碼框圖

▲ AACPlus v2解碼框圖
PS模塊也是AAC的核心模塊之一,主要用于分析左右聲道屬性并使用非常少的位數(shù)表示左右聲道相關性,而后在解碼端將左右聲道分離。這里比較巧妙的是PS的向下兼容特性,整體數(shù)據(jù)打包是分開進行的。如果獲取到AAC、SBR、PS三者的基本數(shù)據(jù)包后,在解碼階段我們就只需AAC—LC。上圖展示的就是AAC的解碼框架,如果大家讀過3GPP的代碼就可發(fā)現(xiàn)其每一個模塊都相當清楚。我們可根據(jù)文檔讀取代碼并對應到每一個環(huán)節(jié)。
【7.5.3】甜點碼率：

▲ AAC 甜點碼率
甜點碼率是一項很關鍵的指標。例如在手機直播應用場景中,一般的視頻分辨率為640×360,音頻碼率大約在800K左右。如果音頻碼率過大則會直接影響視頻質量,因而我們需要控制音頻碼率在一個較為合適的范圍內從而實現(xiàn)最佳的音畫效果。在很多應用場景中可能需要系統(tǒng)根據(jù)不同的網(wǎng)絡環(huán)境下載不同音質的文件,例如在2G環(huán)境中下載較小的文件,這樣做主要是為了節(jié)省帶寬并提高音頻文件的播放流暢程度。
7.6 AAC-ELD家族
AAC-ELD家族產(chǎn)生背景： aacplus v2 已經(jīng)在壓縮和音質方面做到了近似于極致,但由于算法實現(xiàn)上的長達100ms左右的延時極大的阻礙aacplus v2在實時通訊領域的應用。Fraunhofer IIS 為了解決這個問題,對AAC進行相關改進,形成了AAC-ELD協(xié)議族。
▲ AAC-ELD家族
AAC-ELD家族帶來的主要改進是低延遲。如果Codec的延遲太長便無法在一些特定場景中被使用。例如早期AAC Plus V2的整體延遲可達100ms,如此高的延遲肯定無法被應用于語音通話等對實時性要求極高的應用場景?；衾势諏W院推出的AAC-ELD可在保持音質的前提下將延遲降低至15ms,相對于MP3最高長達200ms的延遲而言提升巨大。
7.7 應用中端到端的延遲
▲ 端到端的延時
編解碼過程也存在延時問題,這也是我們選擇編解碼器時需要考慮的最主要因素之一,編解碼的延時主要由處理延時與算法延時組成,例如G.729的算法延時為15ms,而AAC-LC可達到一百毫秒以上。另外,播放端或采集端的長幀數(shù)量太多,播放時緩存太多等也會直接影響延時,我們在選擇編解碼器時需要考慮延時帶來的影響。
編解碼器已經(jīng)歷了兩個發(fā)展方向：
1）一個是以G.7（G.729）為例,根據(jù)發(fā)聲模型設計的一套主要集中于語音方面的編解碼算法；
2）另一個是以ISO的MP3和AAC為例,根據(jù)心理聲學模型設計的一套感知編碼。
最近的趨勢是編碼的統(tǒng)一： 原來在語音場景下我們使用8K或16K進行采樣,音樂場景下則需使用覆蓋到全頻帶的44.1K進行采樣,每個Codec都有一個頻域覆蓋的范圍。在之前的開發(fā)中,如果應用場景僅針對壓縮語音那么需要選擇語音編碼方案,如果應用場景針對壓縮音樂則需要選擇音樂編碼方案,而現(xiàn)在的發(fā)展方向是通過一套編碼從容應對語音與音樂兩個應用場景,這就是接下來將要被提到的USAC。
這里介紹兩個比較典型的Codec：
1）一個是Opus,通過其中集成的模塊可實現(xiàn)根據(jù)傳入音頻文件的采樣率等屬性自動選擇語音編碼或音樂編碼；
2）另一個是EVS這也是霍朗普等組織推行的方案,已經(jīng)嘗試用于4G或5G之中。
EVS (Enhanced Voice Services)： 主要是VoiceAge, Dolby, Fraunhofer, 華為聯(lián)合開發(fā)的USAC編碼器,低速率音樂編碼質量很好。

▲ USAC
由框圖我們可以了解到USAC向下兼容的特性。
編解碼器可總結為經(jīng)歷了三個時代： 1）發(fā)聲模型；
2）聽覺感知；
3）融合方案。
接下來我將展示目前所有的Codec情況并整理為表格以方便大家檢索查閱。
8、解碼器（Codec）總結
8.1 IETF系列
IETF作為標準協(xié)議聯(lián)盟組織之一推出了以上Codec：Opus包括采樣率為8kHz、甜點碼率為11kbps的窄帶單聲語音（SILK）,采樣率為16kHz、甜點碼率為20kbps的寬帶單聲語音與采樣率為48kHz、甜點碼率為32kbps的全帶單聲語音（CELT）,采用甜點碼率意味著將壓縮率和音質保持在一個良好的平衡狀態(tài)。在一些窄帶單聲語音應用場景例如常見的微信語音聊天,其壓縮率可達到原來的8.5%。Opus沒有技術專利和源代碼的門檻,使得其受到現(xiàn)在很多流媒體廠商的歡迎,Opus支持更廣的碼率范圍,具備豐富采樣率選擇,可實現(xiàn)極低延遲與可變幀大小,也具備以往一些Codec的許多特性如CBR、VBR、動態(tài)調整等,支持的通道數(shù)量也更多。除此之外,Opus同樣具備許多從SILK移植而來的特性或功能。如在VUIB傳輸上集成了扛丟包模式等。
iLBC早在SILK未出現(xiàn)時就被提出同樣具備抗丟包。的特性,高達15.2kbps的甜點碼率與4.14的Mos使其音質較為良好,超過G.729的相關指標；GSM就是最早手機網(wǎng)絡仍停留在2G時代時流行的編碼形式,主要用于蜂窩電話的編碼任務。
8.2 AMR系列
AMR早在3G時期就被廣泛應用,AMR-NB是最流行的語音編碼器,具有壓縮效果好,支持多種碼率形式的特點；與此同時,這也是GSM與3G時期Android平臺最早支持的窄帶語音編碼方案。AMR-WB作為AMR-NB向寬帶的擴展版,主要用于3G和4G通話標準協(xié)議中,其甜點碼率為12.65kbps。在實踐中我們將碼率參數(shù)調整為此值即可實現(xiàn)壓縮率與質量的平衡。AMR-WB+則是上述兩者的融合,三者共同構成AMR系列。
8.3 ITU-T G系列
ITU-T G系列包括最早的波形編碼G711到現(xiàn)在大家熟悉的G.729這里我想強調的是G722.1 Siren7、G722.1c Siren14與G719 Siren22,例如G.719可覆蓋整個前頻帶且支持立體聲。即使都屬于老協(xié)議,但由于其優(yōu)秀的兼容性,不應被我們忽略。

將Opus與其他一些Codec進行對比我們可以看到,無論是質量還是延時控制,Opus的優(yōu)勢十分明顯；加之Opus作為開源的免費方案,不存在專利限制,受到業(yè)界追捧也不足為奇。
8.4 ISO系列
ISO里我想強調的是MP3與AAC,二者同樣支持很多碼率。MP3的甜點碼率為128kbps,MP3 Pro的碼率可達到MP3的一半；AAC支持8～96khz的采樣率,AAC-LC的甜點碼率為96kbps,HE-AAC的甜點碼率為32kbps,AAC-LD與ELD做到了AAC的低延時,實現(xiàn)了延時與壓縮比的最佳平衡。
8.5 3GPP系列：EVRC
EVRC 是CDMA 中使用的語音編解碼器,由高通公司1995年提出目標是取代QCELP。
高通公司主推的3GPP是CDMA中使用的語音編解碼器,在未來選擇編解碼器類型時我們需要特別考慮延時與幀長。由于語音編碼種類很多,幀長也是復雜多變的,其背后的算法復雜程度,RAM、ROM占用等都是在實踐當中需要著重考慮的。
8.6 極低碼率
極低碼率主要的應用場景是對講機、衛(wèi)星通訊、軍工等。
上圖圖表中的MELP最早由美國軍方開發(fā),現(xiàn)在絕大多數(shù)的對講機都基于此模型進行擴展開發(fā),壓縮后的碼率可達到2.4kbps而目前最極端的極低碼率可實現(xiàn)300bps,相當于壓縮為原數(shù)據(jù)的0.2%,此時的音頻文件僅能被用于傳達語音內容而丟失了很多聲色。
8.7 全頻帶
全頻帶中的組合也是多種多樣。
9、編解碼使用注意
9.1 License
▲ 開源項目常用的Lisence
國內大部分企業(yè)在開發(fā)時容易忽視包括專利安全性在內的與License相關的內容。如果企業(yè)計劃得比較長遠,需要長期使用某項技術或企業(yè)規(guī)模不斷擴大時則不能不考慮專利問題。專利費用包括Open Source與算法專利,二者完全獨立互不干涉,如果我們從某家專利公司購買了AAC的專利算法,并不能獲得此AAC專利的源代碼,僅能獲得與此技術相關的專利使用授權。專利公司會給予需要下載的文件列表,通過這種方式實現(xiàn)技術的授權使用。
▲ 一張圖看懂Lisence（來自： 阮一峰的博客 ）
上面的二叉樹圖比較清晰地展示了代碼授權的具體流程,隨著企業(yè)的規(guī)?；l(fā)展日趨成熟,企業(yè)應當規(guī)范自身的技術使用行為,盡可能避免專利糾紛帶來的不利影響。
9.2 專利
▲ 2個著名的多媒體技術專利池
主流語音編解碼技術擁有兩個專利池： 1）MPEG-LA；
2）Via Licensing。
很多非常復雜的Codec涉及高達上千個專利,與之相關的企業(yè)或組織多達幾十個,為專利授權而與每一個企業(yè)或組織進行洽談顯然是不現(xiàn)實的,因而專利池的出現(xiàn)使得技術授權更加規(guī)范清晰,方便企業(yè)統(tǒng)一處理技術授權問題。
9.3 常見Codec Patent License

希望大家在使用技術的同時尊重知識產(chǎn)權,助力技術創(chuàng)新可持續(xù)發(fā)展。
10、講稿PPT下載
（因無法上傳附件,請從原文附件下載： http://www.52im.net/thread-2230-1-1.html ）
附錄：更多音視頻技術資料 [1] 實時音視頻開發(fā)的其它精華資料：
《 實時語音聊天中的音頻處理與編碼壓縮技術簡述 》
《 網(wǎng)易視頻云技術分享：音頻處理與壓縮技術快速入門 》
《 學習RFC3550：RTP/RTCP實時傳輸協(xié)議基礎知識 》
《 基于RTMP數(shù)據(jù)傳輸協(xié)議的實時流媒體技術研究（論文全文） 》
《 聲網(wǎng)架構師談實時音視頻云的實現(xiàn)難點(視頻采訪) 》
《 淺談開發(fā)實時視頻直播平臺的技術要點 》
《 還在靠“喂喂喂”測試實時語音通話質量？本文教你科學的評測方法！ 》
《 實現(xiàn)延遲低于500毫秒的1080P實時音視頻直播的實踐分享 》
《 移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡 》
《 如何用最簡單的方法測試你的實時音視頻方案 》
《 技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播 》
《 簡述實時音視頻聊天中端到端加密（E2EE）的工作原理 》
《 移動端實時音視頻直播技術詳解（一）：開篇 》
《 移動端實時音視頻直播技術詳解（二）：采集 》
《 移動端實時音視頻直播技術詳解（三）：處理 》
《 移動端實時音視頻直播技術詳解（四）：編碼和封裝 》
《 移動端實時音視頻直播技術詳解（五）：推流和傳輸 》
《 移動端實時音視頻直播技術詳解（六）：延遲優(yōu)化 》
《 理論聯(lián)系實際：實現(xiàn)一個簡單地基于HTML5的實時視頻直播 》
《 IM實時音視頻聊天時的回聲消除技術詳解 》
《 淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標 》
《 如何優(yōu)化傳輸機制來實現(xiàn)實時音視頻的超低延遲？ 》
《 首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？ 》
《 Android直播入門實踐：動手搭建一套簡單的直播系統(tǒng) 》
《 網(wǎng)易云信實時視頻直播在TCP數(shù)據(jù)傳輸層的一些優(yōu)化思路 》
《 實時音視頻聊天技術分享：面向不可靠網(wǎng)絡的抗丟包編解碼器 》
《 P2P技術如何將實時視頻直播帶寬降低75%？ 》
《 專訪微信視頻技術負責人：微信實時視頻聊天技術的演進 》
《 騰訊音視頻實驗室：使用AI黑科技實現(xiàn)超低碼率的高清實時視頻聊天 》
《 微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密 》
《 近期大熱的實時直播答題系統(tǒng)的實現(xiàn)思路與技術難點分享 》
《 福利貼：最全實時音視頻開發(fā)要用到的開源工程匯總 》
《 七牛云技術分享：使用QUIC協(xié)議實現(xiàn)實時視頻直播0卡頓！ 》
《 實時音視頻聊天中超低延遲架構的思考與技術實踐 》
《 理解實時音視頻聊天中的延時問題一篇就夠 》
《 實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序 》
《 寫給小白的實時音視頻技術入門提綱 》
《 微信多媒體團隊訪談：音視頻開發(fā)的學習、微信的音視頻技術和挑戰(zhàn)等 》
《 騰訊技術分享：微信小程序音視頻技術背后的故事 》
《 微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術 》
《 新浪微博技術分享：微博短視頻服務的優(yōu)化實踐之路 》
《 實時音頻的混音在視頻直播應用中的技術原理和實踐總結 》
《 以網(wǎng)游服務端的網(wǎng)絡接入層設計為例,理解實時通信的技術挑戰(zhàn) 》
《 騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐 》
《 新浪微博技術分享：微博實時直播答題的百萬高并發(fā)架構實踐 》
《 技術干貨：實時視頻直播首屏耗時400ms內的優(yōu)化實踐 》
>> 更多同類文章 ……
[2] 開源實時音視頻技術WebRTC的文章：
《 開源實時音視頻技術WebRTC的現(xiàn)狀 》
《 簡述開源實時音視頻技術WebRTC的優(yōu)缺點 》
《 訪談WebRTC標準之父：WebRTC的過去、現(xiàn)在和未來 》
《 良心分享：WebRTC 零基礎開發(fā)者教程（中文）[附件下載] 》
《 WebRTC實時音視頻技術的整體架構介紹 》
《 新手入門：到底什么是WebRTC服務器,以及它是如何聯(lián)接通話的？ 》
《 WebRTC實時音視頻技術基礎：基本架構和協(xié)議棧 》
《 淺談開發(fā)實時視頻直播平臺的技術要點 》
《 [觀點] WebRTC應該選擇H.264視頻編碼的四大理由 》
《 基于開源WebRTC開發(fā)實時音視頻靠譜嗎？第3方SDK有哪些？ 》
《 開源實時音視頻技術WebRTC中RTP/RTCP數(shù)據(jù)傳輸協(xié)議的應用 》
《 簡述實時音視頻聊天中端到端加密（E2EE）的工作原理 》
《 實時通信RTC技術棧之：視頻編解碼 》
《 開源實時音視頻技術WebRTC在Windows下的簡明編譯教程 》
《 網(wǎng)頁端實時音視頻技術WebRTC：看起來很美,但離生產(chǎn)應用還有多少坑要填？ 》
《 了不起的WebRTC：生態(tài)日趨完善,或將實時音視頻技術白菜化 》
《 騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐 》
>> 更多同類文章 ……
（本文同步發(fā)布于： http://www.52im.net/thread-2230-1-1.html ）

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
環(huán)境：Windows64 + Nginx的-RTMP靜態(tài)+ ffmpeg的靜態(tài)+ Java1.8
我想使用Ffmpeg將視頻流從HLS流轉換成RTMP。剛開始幾個流是正常的,但是當我打開更多的流時,它正常看似運行,但沒有視頻數(shù)據(jù)拉動和推送。 本來以為是流量上限的問題結果,即使我重新啟動rtmp服務器也沒用。
命令 ffmpeg -i xxx/live.m3u8 -vcodec h264-s 720*480 -an -f flv -y rtmp://xxx
控制臺：

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
由于場景問題,暫時無法使用注解@JSONField, fastjson中還有什么方式可以根據(jù)自己定義的注解個性化定義字段格式？ 看了源代碼,序列化時可以通過NameFilter實現(xiàn),反序列化時ExtraProcessor需要處理各種類型的反射。不知道Fastjson是否提供類似于gson的FieldNameStrategy接口 ,可以方便自定義字段格式的。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
前臺輸入框輸入多個?,后臺實體類取出來的數(shù)據(jù)變成？？？jQuery224007647298358178567_1573798292433?

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
fastjson反序列化一個json字符串（比較大）,json字符串帶中文亂,導致cpu飆升,有人遇到過嗎？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
@溫少
fastJson 對于 Map的 features 指定是無效的吧？
比如,我在 features 指定了,WriteNullStringAsEmpty,經(jīng)測試無效,fastjson使用的是最新版本。
Map jsonMap = new HashMap();
jsonMap.put("a", 1);
jsonMap.put("b", "");
jsonMap.put("c", null);
jsonMap.put("d", "wuzhuti.cn");

String str = JSONObject.toJSONString(jsonMap, features);
System.out.println(str);

private static final SerializerFeature[] features = { SerializerFeature.SortField,//排序字段
SerializerFeature.WriteMapNullValue, // 輸出空置字段
SerializerFeature.WriteNullListAsEmpty, // list字段如果為null,輸出為[],而不是null
SerializerFeature.WriteNullNumberAsZero, // 數(shù)值字段如果為null,輸出為0,而不是null
SerializerFeature.WriteNullBooleanAsFalse, // Boolean字段如果為null,輸出為false,而不是null
SerializerFeature.WriteNullStringAsEmpty // 字符類型字段如果為null,輸出為"",而不是null
};

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
@wenshao 你好,向你請教一個問題：
我有一個List,里面的元素都引用了同一個對象實例,在toJsonString后,拿到的數(shù)據(jù)里除了第一個的引用是完整的數(shù)據(jù)外,其他的都是 $.data[0].xxx 這樣的,有沒有什么feature是可以讓這個 引用 變成完整的數(shù)據(jù)？比如做成這樣：
JSON.toJSONString(list, Features.cloneAndReplaceRef)
即,把這些引用的地方都替換成引用源的JSON拷貝。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
com.alibaba.fastjson.JSONException: syntax error, pos 6, json :

代碼寫了 ,但是報錯了
JSONObject querySql = JSON.parseArray(ccont).getJSONObject(0).getJSONObject("reader")
.getJSONObject("parameter").getJSONObject("querySql");;


要解析的json是 [{"reader":{"parameter":{"querySql":"SELECT * FROM `t_rsd_model_history` t WHERE t.`status` = '正在執(zhí)行' ;","readsource":""},"name":"mysqlreader"},"writer":{"parameter":{"writersource":"","column":["model_name"],"writeMode":"insert","batchSize":["22"],"table":["t_rsd_model_history"],"preSql":["SELECT * FROM `t_rsd_model_history` t WHERE t.`status` = '正在執(zhí)行' ;"]},"name":"mysqlwriter"}}]

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
@wenshao 你好,想跟你請教個問題：
fastjson在處理特殊字符上,因為要在輸出時保存字符串的原始模式,如\"的格式,要輸出時,要輸出為\ + "的形式,而不能直接輸出為\",后者在輸出時就直接輸出為",而省略了\,這在js端是會報錯的。 請問該如何處理??？
我的情況是這樣的：數(shù)據(jù)庫中的content內容中含有雙引號(你好"中國"),在使用fastjson轉換toJSONString()后是： {"id":1, "content":"你好\"中國\""} ,但是我在jsp頁面中將轉換后的json字符串交給js解析：
var res = JSON.parse('${res_content}'); --> var res = JSON.parse('{"id":1, "content":"你好\"中國\""}');
這樣是報錯的,應該是這樣的： var res = JSON.parse('{"id":1, "content":"你好\\"中國\\""}');
請問該如何處理??？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
整個項目都是,有碰到過的朋友嘛？
列表和編輯頁 都有加
<%@ page contentType="text/html;charset=UTF-8"%>

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
大家好,我用DWZ提示的方式進行文件上傳,可是我的后臺已經(jīng)報錯了,而且也返回報錯字符串了,可還是提示成功,有人知道怎么回事嗎？ onUploadError 這個方法總是不執(zhí)行
onUploadSuccess 這個方法執(zhí)行 onUploadComplete 這個方法執(zhí)行
下面是后臺返回的值
這是我后臺返回值 的問題還是我少指定什么參數(shù)了

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
使用chorme調試頁面,可是在source里面沒有找到頁面信息,只能看到index.jsp的信息,如何調試頁面？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
希望點擊保存按鈕后,后臺進行添加操作,添加成功后提示添加成功。
jsp頁面




后臺controller
@RequestMapping("/addProduct") public ModelAndView addProduct(HttpServletRequest request, HttpServletResponse response) throws IOException { String newProductName = request.getParameter("newProductName"); System.out.println("新產(chǎn)品添加成功！"); System.out.println(newProductName); JSONObject dwzServerJson = new JSONObject(); dwzServerJson.put("statusCode", "200"); dwzServerJson.put("message", "111"); dwzServerJson.put("navTabId", "productView"); dwzServerJson.put("rel", ""); dwzServerJson.put("callbackType", "closeCurrent"); dwzServerJson.put("forwardUrl", ""); request.setAttribute("json", dwzServerJson); return null; }

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
dwz中有幾種table方式 那些支持td換行的

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>

alt="" upimgurl="${ctx }/util/upload1.ec?folder=activityContent" <br>upimgext="jpg,jpeg,gif,png" value="" >${mallActivity.activityContent }
網(wǎng)上考的,上傳是有傳成功,但在富文本里怎么展示??？

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
我用搜狗瀏覽器點上一頁下一頁 每頁顯示數(shù)目 都可以
用IE點擊后還是原來的數(shù)據(jù) 并且 我點擊10后 還是5 而且還不能上一頁 下一些 用搜狗卻可以 求解 為什么

HDC調試需求開發(fā)（15萬預算）,能者速來！>>> 今天在給樹遍歷的時候想選中復選框,用jquery操作,設置了,但是界面上沒有顯示打勾,實際上checkbox已經(jīng)選中,看了一下dom結構,原來顯示打勾的是上層的一個DIV css,源碼里面在手動選擇的時候已經(jīng)有,但是不知道怎么在遍歷的時候怎么寫..有朋友知道嗎?@張慧華

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
很多同學接觸Linux不多,對Linux平臺的開發(fā)更是一無所知。 而現(xiàn)在的趨勢越來越表明,作為一個優(yōu)秀的軟件開發(fā)人員,或計算機IT行業(yè)從業(yè)人員, 掌握Linux是一種很重要的謀生資源與手段。
下來我將會結合自己的幾年的個人開發(fā)經(jīng)驗,及對 Linux,更是類UNIX系統(tǒng),及開源軟件文化, 談談Linux的學習方法與學習中應該注意的一些事。
就如同剛才說的,很多同學以前可能連Linux是什么都不知道,對UNIX更是一無所知。 所以我們從最基礎的講起,對于Linux及UNIX的歷史我們不做多談,直接進入入門的學習。
Linux入門是很簡單的,問題是你是否有耐心,是否愛折騰,是否不排斥重裝一類的大修。 沒折騰可以說是學不好Linux的,鳥哥說過,要真正了解Linux的分區(qū)機制,對LVM使用相當熟練, 沒有20次以上的Linux裝機經(jīng)驗是積累不起來的,所以一定不要怕折騰。
由于大家之前都使用Windows,所以我也盡可能照顧這些“菜鳥”。 我的推薦,如果你第一次接觸Linux,那么首先在虛擬機中嘗試它。 虛擬機我推薦Virtual Box,我并不主張使用VM,原因是VM是閉源的,并且是收費的,我不希望推動盜版。 當然如果你的Money足夠多,可以嘗試VM,但我要說的是即使是VM,不一定就一定好。
付費的軟件不一定好。
首先,Virtual Box很小巧,Windows平臺下安裝包在80MB左右,而VM動輒600MB,雖然功能強大,但資源消耗也多,何況你的需求Virtual Box完全能夠滿足。 所以,還是自己選。
如何使用虛擬機,是你的事,這個我不教你,因為很簡單,不會的話Google或Baidu都可以, 英文好的可以直接看官方文檔。 現(xiàn)在介紹Linux發(fā)行版的知識。
正如你所見,Linux發(fā)行版并非Linux,Linux僅是指操作系統(tǒng)的內核,作為科班出生的你不要讓我解釋, 我也沒時間。
我推薦的發(fā)行版如下： UBUNTU 適合純菜鳥,追求穩(wěn)定的官方支持,對系統(tǒng)穩(wěn)定性要求較弱,喜歡最新應用,相對來說不太喜歡折騰的開發(fā)者。 Debian,相對UBUNTU難很多的發(fā)行版,突出特點是穩(wěn)定與容易使用的包管理系統(tǒng),缺點是企業(yè)支持不足,為社區(qū)開發(fā)驅動。 Arch,追逐時尚的開發(fā)者的首選,優(yōu)點是包更新相當快,無縫升級,一次安裝基本可以一直運作下去,沒有如UBUNTU那樣的版本概念,說的專業(yè)點叫滾動升級,保持你的系統(tǒng)一定是最新的。缺點顯然易見,不穩(wěn)定。同時安裝配置相對Debian再麻煩點。 Gentoo,相對Arch再難點,考驗使用者的綜合水平,從系統(tǒng)安裝到微調,內核編譯都親歷親為,是高手及黑客顯示自己技術手段,按需配置符合自己要求的系統(tǒng)的首選。 Slackware與Gentoo類似。 CentOS,社區(qū)維護的RedHat的復刻版本,完全使用RedHat的源碼重新編譯生成,與RedHat的兼容性在理論上來說是最好的。如果你專注于Linux服務器,如網(wǎng)絡管理,架站,那么CentOS是你的選擇。 LFS,終極黑客顯擺工具,完全從源代碼安裝,編譯系統(tǒng)。安裝前你得到的只有一份文檔,你要做的就是照文檔你的說明,一步步,一條條命令,一個個軟件包的去構建你的Linux,完全由你自己控制,想要什么就是什么。如果你做出了LFS,證明你的Linux功底已經(jīng)相當不錯,如果你能拿LFS文檔活學活用,再將Linux從源代碼開始移植到嵌入式系統(tǒng),我敢說中國的企業(yè)你可以混的很好。
1、Linux基礎
你得挑一個適合你的系統(tǒng),然后在虛擬機安裝它,開始使用它。 如果你想快速學會Linux,我有一個建議就是忘記圖形界面,不要想圖形界面能不能提供你問題的答案, 而是滿世界的去找,去問,如何用命令行解決你的問題。
在這個過程中,你最好能將Linux的命令掌握的不錯,起碼常用的命令得知道,同時建立了自己的知識庫, 里面是你積累的各項知識。
2、Linux平臺的C/C++開發(fā),同時還有Bash腳本編程[JAVA]
再下個階段,你需要學習的是Linux平臺的C/C++開發(fā),同時還有Bash腳本編程,如果你對Java興趣很深還有Java。 同樣,建議你拋棄掉圖形界面的IDE,從VIM開始,為什么是VIM,而不是Emacs, 我無意挑起編輯器大戰(zhàn),但我覺得VIM適合初學者,適合手比較笨,腦袋比較慢的開發(fā)者。 Emacs的鍵位太多,太復雜,我很畏懼。然后是GCC,Make,Eclipse（Java,C++或者）。
雖然將C++列在了Eclipse中,但我并不推薦用IDE開發(fā)C++,因為這不是Linux的文化, 容易讓你忽略一些你應該注意的問題。 IDE讓你變懶,懶得跟豬一樣。如果你對程序調試,測試工作很感興趣,GDB也得學的很好, 如果不是GDB也是必修課。這是開發(fā)的第一步,注意我并沒有提過一句Linux系統(tǒng)API的內容, 這個階段也不要關心這個。你要做的就是積累經(jīng)驗,在Linux平臺的開發(fā)經(jīng)驗。
我推薦的書如下： C語言程序設計 。 C語言,白皮書當然更好。 C++推薦 C++ Primer Plus , Java我不喜歡,就不推薦了,附一個別人的書單： java 入門書籍 。 工具方面推薦VIM的官方手冊,GCC中文文檔,GDB中文文檔,GNU開源軟件開發(fā)指導（電子書）, 匯編語言程序設計（讓你對庫,鏈接,內嵌匯編,編譯器優(yōu)化選項有初步了解,不必深度）。
如果你這個階段過不了就不必往下做了,這是底線,最基礎的基礎,否則離開,不要霍霍Linux開發(fā)。 不專業(yè)的Linux開發(fā)者作出的程序是與Linux文化或UNIX文化相背的,程序是走不遠的, 不可能像Bash,VIM這些神品一樣。 所以做不好干脆離開。
3、UNIX環(huán)境高級編程（作者英年早逝,第3版即將出版,稍等）
UNIX環(huán)境高級編程 堪稱神作,經(jīng)典中的經(jīng)典。
接下來進入Linux系統(tǒng)編程,不二選擇, APUE ,UNIX環(huán)境高級編程,一遍一遍的看, 看10遍都嫌少,如果你可以在大學將這本書翻爛,里面的內容都實踐過,有作品,你口頭表達能力夠強, 你可以在面試時說服所有的考官。
（可能有點夸張,但APUE絕對是圣經(jīng)一般的讀物,即使是Windows程序員也從其中汲取養(yǎng)分, Google創(chuàng)始人的案頭書籍,扎爾伯克的床頭讀物。）
這本書看完后你會對Linux系統(tǒng)編程有相當?shù)牧私?知道Linux與Windows平臺間開發(fā)的差異在哪？ 它們的優(yōu)缺點在哪？我的總結如下：做Windows平臺開發(fā),很苦,微軟的系統(tǒng)API總在擴容, 想使用最新潮,最高效的功能,最適合當前流行系統(tǒng)的功能你必須時刻學習。 Linux不是,Linux系統(tǒng)的核心API就100來個,記憶力好完全可以背下來。 而且經(jīng)久不變,為什么不變,因為要同UNIX兼容,符合POSIX標準。 所以Linux平臺的開發(fā)大多是專注于底層的或服務器編程。
這是其優(yōu)點,當然圖形是Linux的軟肋,但我站在一個開發(fā)者的角度,我無所謂,因為命令行我也可以適應, 如果有更好的圖形界面我就當作恩賜吧。另外,Windows閉源,系統(tǒng)做了什么你更本不知道, 永遠被微軟牽著鼻子跑,想想如果微軟說Win8不支持QQ,那騰訊不得哭死。 而Linux完全開源,你不喜歡,可以自己改,只要你技術夠。
另外,Windows雖然使用的人多,但使用場合單一,專注與桌面。 而Linux在各個方面都有發(fā)展,尤其在云計算,服務器軟件,嵌入式領域, 企業(yè)級應用上有廣大前景,而且兼容性一流,由于支持POSIX可以無縫的運行在UNIX系統(tǒng)之上, 不管是蘋果的Mac還是IBM的AS400系列,都是完全支持的。 另外,Linux的開發(fā)環(huán)境支持也絕對是一流的,不管是C/C++,Java,Bash,Python,PHP,Javascript,。。。。。。就連C#也支持。而微軟除Visual Stdio套件以外,都不怎么友好,不是嗎？
如果你看完APUE的感觸有很多,希望驗證你的某些想法或經(jīng)驗,推薦 UNIX程序設計藝術 , 世界頂級黑客將同你分享他的看法。
4、選擇方向：網(wǎng)絡,圖形,嵌入式,設備驅動
網(wǎng)絡方向：服務器軟件編寫及高性能的并發(fā)程序編寫
現(xiàn)在是時候做分流了。 大體上我分為四個方向：網(wǎng)絡,圖形,嵌入式,設備驅動。
如果選擇網(wǎng)絡,再細分,我對其他的不是他熟悉,只說服務器軟件編寫及高性能的并發(fā)程序編寫吧。 相對來說這是網(wǎng)絡編程中技術含量最高的,也是底層的。 需要很多的經(jīng)驗,看很多的書,做很多的項目。
我的看法是以下面的順序來看書： APUE再深讀 – 尤其是進程,線程,IPC,套接字 多核程序設計 - Pthread一定得吃透了,你很NB UNIX網(wǎng)絡編程 – 卷一,卷二 TCP/IP網(wǎng)絡詳解 – 卷一 再看上面兩本書時就該看了 5.TCP/IP 網(wǎng)絡詳解 – 卷二 我覺得看到卷二就差不多了,當然卷三看了更好,努力,爭取看了 6.Lighttpd源代碼 - 這個服務器也很有名了 7.Nginx源代碼 – 相較于Apache,Nginx的源碼較少,如果能看個大致,很NB?？丛创a主要是要學習里面的套接字編程及并發(fā)控制,想想都激動。如果你有這些本事,可以試著往暴雪投簡歷,為他們寫服務器后臺,想一想全球的魔獸都運行在你的服務器軟件上。 Linux內核 TCP/IP協(xié)議棧 – 深入了解TCP/IP的實現(xiàn)
如果你還喜歡驅動程序設計,可以看看更底層的協(xié)議,如鏈路層的,寫什么路由器,網(wǎng)卡, 網(wǎng)絡設備的驅動及嵌入式系統(tǒng)軟件應該也不成問題了。
當然一般的網(wǎng)絡公司,就算百度級別的也該毫不猶豫的雇用你。 只是看后面這些書需要時間與經(jīng)驗,所以35歲以前辦到吧！跳槽到給你未來的地方！
圖形方向,我覺得圖形方向也是很有前途的,以下幾個方面。 Opengl的工業(yè)及游戲開發(fā),國外較成熟。 影視動畫特效,如皮克斯,也是國外較成熟。 GPU計算技術,可以應用在瀏覽器網(wǎng)頁渲染上,GPU計算資源利用上,由于開源的原因,有很多的文檔程序可以參考。如果能進火狐開發(fā),或google做瀏覽器開發(fā),應該會很好 。
嵌入式方向：嵌入式方向沒說的,Linux很重要。
掌握多個架構,不僅X86的,ARM的,單片機什么的也必須得懂。 硬件不懂我預見你會死在半路上,我也想走嵌入式方向,但我覺得就學校教授嵌入式的方法, 我連學電子的那幫學生都競爭不過。 奉勸大家,一定得懂硬件再去做,如果走到嵌入式應用開發(fā),只能祝你好運, 不要碰上像Nokia,Hp這樣的公司,否則你會很慘的。
驅動程序設計：軟件開發(fā)周期是很長的,硬件不同,很快。 每個月誕生那么多的新硬件,如何讓他們在Linux上工作起來,這是你的工作。 由于Linux的兼容性很好,如果不是太低層的驅動,基本C語言就可以搞定,系統(tǒng)架構的影響不大, 因為有系統(tǒng)支持,你可能做些許更改就可以在ARM上使用PC的硬件了, 所以做硬件驅動開發(fā)不像嵌入式,對硬件知識的要求很高。
可以從事的方向也很多,如家電啊,特別是如索尼,日立,希捷,富士康這樣的廠子,很稀缺的。

HDC調試需求開發(fā)（15萬預算）,能者速來！>>>
生產(chǎn)環(huán)境用jinkens構建maven項目時出現(xiàn)如圖異常,已經(jīng)處理了2天了還是沒有定位到問題~~,如圖：

急急急急~~~