Visual Studio 6: open pjproject.dsw workspace, 2.新建一個(gè)空文件pjlib/include/pj/config_site.h后，編譯pjsua工程出現(xiàn)以下錯(cuò)誤：1>LINK : fatal error LNK1104: cannot open file ''dsound.lib''看名字dsound.lib像是directX里面的東本，試著在Microsoft DirectX 9.0 SDK (Summer 2004)/lib中查找(DirectX SDK需要單獨(dú)下載)，果然找到了，將路徑添加進(jìn)去后，編譯通過(guò)了。

軟件中的緩沖區(qū)管理軟件中的緩沖區(qū)管理1. 前言 什么是緩沖區(qū)管理策略？生產(chǎn)者把數(shù)據(jù)放入緩沖區(qū)，而消費(fèi)者從緩沖區(qū)取出數(shù)據(jù)?！八还芾怼狈桨福? （1）緩沖區(qū)剛開(kāi)始為空時(shí)，由于處于“低水位”狀態(tài)，故采用的是“低水位門(mén)限控制方案”，即若消費(fèi)者消耗速率為Vo，生產(chǎn)者則以速率Vo的n倍（例如2倍）填充緩沖區(qū)，直到水位到達(dá)50%時(shí)，再回到消費(fèi)的速率Vo來(lái)填充緩沖區(qū)。

檢查各個(gè)芯片的地，該接模擬地的接模擬地，該接數(shù)字地的是否接的數(shù)字地，數(shù)字地與模?獾刂涫欠窀艨? 一般處理模擬信號(hào)的芯片有：傳感器芯片、模擬信號(hào)采集芯片、AD轉(zhuǎn)換芯片、功放芯片、濾波芯片、載波芯片、DA轉(zhuǎn)換芯片、模擬信號(hào)輸出芯片等等，往往只有當(dāng)系統(tǒng)中存在這些處理模擬信號(hào)的芯片或者?緶肥輩嘔嶸婕澳Ｄ獾睪褪值亍? 一般芯片的接地腳該連接模擬地還是數(shù)字地在芯片手冊(cè)中都有說(shuō)明，按照datasheet上連接就可以了。

struct file_operations tvp5158_dev_FileOps = { .owner = THIS_MODULE, .open = tvp5158_devOpen, .release = tvp5158_devRelease, .ioctl = tvp5158_devIoctl, };cdev_del(&g_tvp5158_dev.cdev);// 假設(shè)生成的模塊.ko名稱(chēng)為 tvp5158.ko 第一步：insmod tvp5158.ko // 假設(shè)上面tvp5158_i2c_init函數(shù)中 g_tvp5158_dev.major 的值為 74 第二步：mknod /dev/tvp5158_dev c 74 0.

Linux下讀寫(xiě)芯片的I2C寄存器Linux下讀寫(xiě)芯片的I2C寄存器。要想在Linux下讀寫(xiě)芯片的I2C寄存器，一般需要在Linux編寫(xiě)一份該芯片的I2C驅(qū)動(dòng)，關(guān)于Linux下如何編寫(xiě)I2C驅(qū)動(dòng)，前一篇文章《手把手教你寫(xiě)Linux I2C設(shè)備驅(qū)動(dòng)》已經(jīng)做了初步的介紹，并且留下了兩個(gè)疑問(wèn)尚未解決，第一個(gè)是如何對(duì)Linux提供的I2C操作函數(shù)進(jìn)行進(jìn)一步封裝，實(shí)現(xiàn)對(duì)芯片寄存器的讀寫(xiě)；首先分析寫(xiě)操作，該芯片的手冊(cè)中給出的I2C寄存器寫(xiě)時(shí)序圖如下：

static struct i2c_driver tvp5158_i2c_driver = { .driver = { .name = "tvp5158_i2c_driver", }, .attach_adapter = &tvp5158_attach_adapter, .detach_client = &tvp5158_detach_client, .command = NULL, };static int tvp5158_detect_client(struct i2c_adapter *adapter,int address,int kind) { struct tvp5158_obj *pObj;

為什么要使用RTP為什么要使用RTP.一提到流媒體傳輸、一談到什么視頻監(jiān)控、視頻會(huì)議、語(yǔ)音電話（VOIP），都離不開(kāi)RTP協(xié)議的應(yīng)用，但當(dāng)大家都根據(jù)經(jīng)驗(yàn)或者別人的應(yīng)用而選擇RTP協(xié)議的時(shí)候，你可曾想過(guò)，為什么我們要使用RTP來(lái)進(jìn)行流媒體的傳輸呢？RTP包頭中的流媒體特性。從RTP包頭的規(guī)定中，我們可以非常清晰地看出，在RTP協(xié)議中，添加了非常多專(zhuān)為流媒體傳輸所使用的特性，更加有助于應(yīng)用于流媒體的傳輸。RTP的profile機(jī)制。

// 如果某個(gè)線程等到了這個(gè)通知，那個(gè)線程就會(huì)轉(zhuǎn)到就緒隊(duì)列中 // 但是本線程仍然繼續(xù)擁有signal這個(gè)同步鎖，本線程仍然繼續(xù)執(zhí)行 // 嘿嘿，雖然本線程好心通知其他線程， // 但是，本線程可沒(méi)有那么高風(fēng)亮節(jié)，放棄到手的同步鎖 // 本線程繼續(xù)執(zhí)行下面的代碼 …綠色線程。當(dāng)前版本的Ruby語(yǔ)言的線程就屬于綠色線程，無(wú)法映射到操作系統(tǒng)的線程，因此Ruby語(yǔ)言的線程的運(yùn)行速度比較慢。目前，線程的流行實(shí)現(xiàn)模型就是綠色線程。

UDP、TCP、RTP三種協(xié)議的總結(jié)UDP、TCP、RTP三種協(xié)議的總結(jié)。RTP實(shí)現(xiàn)者在發(fā)送RTP數(shù)據(jù)時(shí)，需先將數(shù)據(jù)封裝成RTP包，而在接收到RTP數(shù)據(jù)包，需要將數(shù)據(jù)從RTP包中提取出來(lái)。SR分組的主要內(nèi)容有：相應(yīng)的RTP流的SSRC，RTP流中最新產(chǎn)生的RTP分組的時(shí)間戳和NTP，RTP流包含的分組數(shù)，RTP流包含的字節(jié)數(shù)。RTP數(shù)據(jù)發(fā)向偶數(shù)的UDP端口，而對(duì)應(yīng)的控制信號(hào)RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)UDP端口（偶數(shù)的UDP端口＋1），這樣就構(gòu)成一個(gè)UDP端口對(duì)。RTP/RTCP.

OPTIONAL RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.3 Fragmentation Units (FUs).(Fragmentation unit: 一個(gè)RTP Payload 包含一個(gè)NAL 單元的一部分. 有FU-A, FU-B 兩種,分別標(biāo)記為 28, 29.)而當(dāng) NALU 的長(zhǎng)度超過(guò) MTU 時(shí), 就必須對(duì) NALU 單元進(jìn)行分片封包. 也稱(chēng)為 Fragmentation Units (FUs).0 1 2 3.

h264 Nalu 詳解(轉(zhuǎn)載) 及 sps.pps.idr相關(guān)h264 Nalu 詳解(轉(zhuǎn)載) 及 sps.pps.idr相關(guān)。Nal_unit_type：當(dāng)前NAL 單元的類(lèi)型。RTP通常使用UDP來(lái)進(jìn)行多媒體數(shù)據(jù)的傳輸，但如果需要的話可以使用TCP或者ATM等其它協(xié)議，整個(gè)RTP協(xié)議由兩個(gè)密切相關(guān)的部分組成：RTP數(shù)據(jù)協(xié)議和RTP控制協(xié)議。CSRC標(biāo)識(shí)緊跟在RTP固定頭部之后，用來(lái)表示RTP數(shù)據(jù)報(bào)的來(lái)源，RTP協(xié)議允許在同一個(gè)會(huì)話中存在多個(gè)數(shù)據(jù)源，它們可以通過(guò)RTP混合器合并為一個(gè)數(shù)據(jù)源。

后來(lái)有所進(jìn)步，陸續(xù)地寫(xiě)了一些大都是這個(gè)樣子的Makefile:CODEfoobar:foo.o bar.o gcc -o foo.o bar.ofoo.o:foo.c gcc -c foo.cbar.o:foo.c gcc -c bar.c.其實(shí)很多源文件的編譯規(guī)則都是一樣的，就像最開(kāi)始那個(gè)Makefile中那樣CODEfoo.o:foo.c gcc -c foo.cbar.o:foo.c gcc -c bar.c.這個(gè)規(guī)則利用了GNU make的后綴規(guī)則。主Makefile:CODECC = gccCFLAGS = -Wall -OINCLUDE = -I./libbarLFLAGS = -L./libbar -lbar.

RTP協(xié)議包頭的格式：第五，時(shí)間戳增量是指兩個(gè)RTP包之間的時(shí)間間隔，詳細(xì)點(diǎn)說(shuō)，就是發(fā)送第二個(gè)RTP包相距發(fā)送第一個(gè)RTP包時(shí)的時(shí)間間隔（單位是時(shí)間戳單位）。但在ORTP中每次數(shù)據(jù)的發(fā)送都需要自己傳入時(shí)間戳的值，即自己需要每次發(fā)完一個(gè)RTP包后，累加時(shí)間戳增量，不是很方便，這就需要自己對(duì)RTP的時(shí)間戳有比較深刻地理解，我剛開(kāi)始就是因?yàn)闆](méi)搞清楚，隨時(shí)設(shè)置時(shí)間戳增量導(dǎo)致傳輸一直有問(wèn)題，困擾我好久。

創(chuàng)建根文件系統(tǒng)目錄，主要包括以下目錄/dev /etc /lib /usr /var /proc /tmp /home /root /mnt /bin /sbin /sys.#cp bin/ sbin/ linuxrc /home/rootfs -ra.# cp /etc/passwd rootfs/etc # cp /etc/group rootfs/etc # cp /etc/shadow roofs/etc.2)#cd /usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/armv4t/usr/lib 將以下動(dòng)態(tài)庫(kù)拷貝到rootfs/lib下 #cp ./libstdc++.so.* rootfs/lib -a.

參數(shù)：IPIPE_HST,IPIPE_VST定義開(kāi)始點(diǎn)（與HD，VD上升沿為原點(diǎn)），IPIPE_HSZ, IPIPE_VSZ定義要處理的數(shù)據(jù)區(qū)域大小。參數(shù)：RSZ[n].RSZ_H_TYP類(lèi)型選擇，HRSZ (RSZ[n].RSZ_H_DIF) and VRSZ (RSZ[n].RSZ_V_DIF)比例，上下限為32-4096，對(duì)應(yīng)X8-X1/16，實(shí)際以256/HRSZ，256/VRSZ計(jì)算，影像輸出尺寸最大為1344 pixels/line for RSZ[0] and 640 pixels/line for RSZ[1].RSZ_H_PHS = 0YCC_ADJ.CTR = 16 RSZ_SEQ.TMM = 0 RSZ[0].RSZ_EN = 0.

初始化代碼讀取uboot到內(nèi)存里面，然后跳轉(zhuǎn)到uboot那里去執(zhí)行uboot，uboot初始化必要的硬件，加載一些驅(qū)動(dòng)，其中包括nand flash的驅(qū)動(dòng)，然后根據(jù)uboot里面設(shè)置的一個(gè)啟動(dòng)命令。而這里的mtd的第3個(gè)分區(qū)具體對(duì)應(yīng)的nand flash中的的地址，是你在內(nèi)核中，一般是在core.c自己定義的的nand flash的分區(qū)。一般是uboot是第一個(gè)分區(qū)，內(nèi)核kernel是第二個(gè)，然后就是rootfs是第三個(gè)分區(qū)，也就是/dev/mtdblock2。

dm365 color spacedm365 color space.420PSemi，422PSemi：這是TI新添加的一種格式，在DM6467的輸出當(dāng)中使用的是422PSemi來(lái)進(jìn)行輸出，所以將YUV的數(shù)據(jù)輸出之前都需要將其他格式的YUV數(shù)據(jù)轉(zhuǎn)換為422PSemi格式。與RGB視頻信號(hào)傳輸相比，它最大的優(yōu)點(diǎn)在于只需占用極少的頻寬（RGB要求三個(gè)獨(dú)立的視頻信號(hào)同時(shí)傳輸）。void yuv_420p_to_420psemi(int32_t height, int32_t width, int32_t lineLength, char *src, char *dst)

DM365/DM355/DM6467上使用的YUV顏色空間說(shuō)明DM365/DM355/DM6467上使用的YUV顏色空間說(shuō)明 比較DM365和DM6467兩款芯片在處理YUV圖像時(shí)的區(qū)別，這個(gè)對(duì)于要處理像TVP5158多通道圖像輸入或直接播放視頻文件時(shí)有重要作用。(DM6467在編解碼、壓縮視頻圖像數(shù)據(jù)時(shí)都是使用這種格式，所以對(duì)YUV422 Semi-Planar數(shù)據(jù)進(jìn)行。其它TI芯片，像DM6446\DM365\DM355在某些模式下是。使用這種格式的，例如DM365在接收TVP5146/TVP5158時(shí)就是使用這種格式)

支持30KB大小的UBL（DM365有32KB的內(nèi)存，其中2KB用作了RBL的堆棧，剩下的空間可以放UBL）用戶可以選擇在RBL執(zhí)行的時(shí)候是否需要支持DMA，I-cache（例如，加載UBL的時(shí)候）使用并且需要4位硬件ECC（支持每512字節(jié)需要ECC位數(shù)小于或等于4位的NAND Flash）。表1 NAND UBL描述符。但RBL根據(jù)UBL描述符里提供的UBL大小信息將UBL全部成功復(fù)制到ARM內(nèi)存后，RBL會(huì)跳到UBL起始地址，這樣芯片的控制權(quán)就交給了UBL，UBL開(kāi)始在ARM內(nèi)存里運(yùn)行了。

linux內(nèi)核的打印printk的級(jí)別調(diào)整內(nèi)核printk打印級(jí)別--減少啟動(dòng)時(shí)的打印信息。DEFAULT_CONSOLE_LOGLEVEL, /* console_loglevel */內(nèi)核通過(guò)printk() 輸出的信息具有日志級(jí)別，日志級(jí)別是通過(guò)在printk() 輸出的字符串前加一個(gè)帶尖括號(hào)的整數(shù)來(lái)控制的，如printk("<6>Hello, world!\n");。未指定日志級(jí)別的printk() 采用的默認(rèn)級(jí)別是DEFAULT_MESSAGE_LOGLEVEL，這個(gè)宏在kernel/printk.c 中被定義為整數(shù)4，即對(duì)應(yīng)KERN_WARNING。