已閱讀5頁,還剩5頁未讀, 繼續(xù)免費(fèi)閱讀
版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡(jiǎn)介
3G 視頻點(diǎn)播系統(tǒng)中流媒體協(xié)議棧的解決方案 摘要 隨著寬帶互聯(lián)網(wǎng)技術(shù)的普及和多媒體技術(shù)在互聯(lián)網(wǎng)上的應(yīng)用,視頻點(diǎn)播已經(jīng)不再局限于有線網(wǎng)絡(luò),擴(kuò)展到了 3G 移動(dòng)領(lǐng)域。本文首先介紹了一個(gè) 3G 視頻點(diǎn)播系統(tǒng),并在此平臺(tái)上介紹了 3G 流媒體協(xié)議棧的概念、特點(diǎn)及其架構(gòu),然后針對(duì)該系統(tǒng)的整體框架詳細(xì)論述了 3G 流媒體協(xié)議棧的模塊實(shí)現(xiàn),并討論了各個(gè)功能模塊的作用及相互之間的影響,最后詳述了流媒體傳輸?shù)年P(guān)鍵環(huán)節(jié) 同步機(jī)制,從而在 3G 終端實(shí)現(xiàn)客戶端 服務(wù)器式的流媒體數(shù)據(jù)的實(shí)時(shí)傳輸。 1、概述 1.1 3G 視頻點(diǎn)播系統(tǒng)概述 視頻點(diǎn)播技術(shù)即 VOD( VideoOnDemand),最初出現(xiàn)是緣于人們對(duì)廣播電視的需求,但之前 VOD 一直局限于有線網(wǎng)絡(luò),從而無法給用戶提供一個(gè)完全自主便捷的環(huán)境。在這樣的情況下,無線移動(dòng)視頻點(diǎn)播業(yè)務(wù)的出現(xiàn)提供了一個(gè)可以和外界交流的平臺(tái)。 3G 技術(shù)的成熟,更是為這項(xiàng)業(yè)務(wù)提供了一個(gè)可靠的實(shí)現(xiàn)基礎(chǔ),人們?cè)谌魏螘r(shí)間,任何地點(diǎn),只要通過一部 3G 手機(jī),就可以像在家通過電視或電腦連接上有線網(wǎng)絡(luò)一樣的在整個(gè)網(wǎng)絡(luò)環(huán)境中隨意瀏覽任何自己感興趣的節(jié)目,從而提供給人們一個(gè)交互式的主控權(quán)利,隨機(jī)隨時(shí)的獲取網(wǎng)絡(luò)資源。在 3G 視頻點(diǎn)播系統(tǒng) 中,手機(jī)客戶端接受來自基站服務(wù)器發(fā)送的媒體數(shù)據(jù),經(jīng)過一系列的處理呈現(xiàn)給用戶播放的圖像,服務(wù)器接收客戶端返回的質(zhì)量報(bào)告進(jìn)行分析,并根據(jù)網(wǎng)絡(luò)的實(shí)際狀況給出合適的傳輸方式以及合適的圖像編碼格式,進(jìn)行流量控制。客戶端完全是被動(dòng)的數(shù)據(jù)處理,媒體數(shù)據(jù)解碼,視頻和音頻的同步。而服務(wù)器則承擔(dān)了大部分的網(wǎng)絡(luò)質(zhì)量狀況監(jiān)測(cè)任務(wù)。這個(gè)方式有點(diǎn)類似于 HTTP 方式下的客戶機(jī) /服務(wù)器模式。而上述這種實(shí)時(shí)流媒體傳輸?shù)倪\(yùn)行架構(gòu)則需要完善可靠的流媒體協(xié)議棧來支持。 本文即介紹一個(gè) 3G 視頻點(diǎn)播系統(tǒng)(如圖 1 所示)中流媒體協(xié)議棧的實(shí)現(xiàn),該系統(tǒng)由 3 部分組成:服務(wù)器, Internet 和手持設(shè)備,針對(duì)該系統(tǒng),本文 首先介紹了實(shí)時(shí)流媒體協(xié)議棧的概念、特點(diǎn)及其發(fā)展背景,然后在此基礎(chǔ)上討論了實(shí)時(shí)流媒體協(xié)議棧在此 3G 視頻點(diǎn)播系統(tǒng)中的軟件架構(gòu),最后詳細(xì)論述各個(gè)模塊的 設(shè)計(jì)及流媒體傳輸?shù)年P(guān)鍵環(huán)節(jié) 同步機(jī)制。 圖 1 系統(tǒng)概述圖 1.2 系統(tǒng)平臺(tái) 系統(tǒng)工作的硬件平臺(tái)、軟件平臺(tái)如下: 硬件平臺(tái): SH-mobilesolutionincludesa SH3-DSP core MCU, memory, IO, and LCD etc, Abase-band controller( AT91 RM9200 Base-Band board),一臺(tái)服務(wù)器(即 PC 機(jī))。 軟件平臺(tái): SH-7300 實(shí)時(shí)操作系統(tǒng)( Norti4), MPEG-4audio/videoencoder/decodermiddleware,流媒體協(xié)議棧(如圖 2 所示)。 圖 2 系統(tǒng)軟件平臺(tái) 2、基于 3G 終端的流媒體協(xié)議棧的架構(gòu) 2.1 流媒體協(xié)議棧及其特點(diǎn) 以 3G 協(xié)議棧為基礎(chǔ)的實(shí)時(shí)流媒體協(xié)議棧( real-timestreamingmediaProtocols)具有強(qiáng)大的兼容性,能根據(jù)基站服務(wù)器通信準(zhǔn)則建立最優(yōu)播放效果,并根據(jù)網(wǎng)絡(luò)狀況,實(shí)時(shí)適應(yīng)以改變通信策略和媒體播放效果。協(xié)議棧將可以保證以下業(yè)務(wù): ( 1)進(jìn)行視頻通話,三方舉行視頻會(huì)議; ( 2)替代以電視為媒體的廣告與節(jié)目播放,提供更具吸引力的多媒體點(diǎn)播等互動(dòng)服務(wù); ( 3)享受移動(dòng)銀行,股票信息,以及電子交易等各種信息服務(wù)。 實(shí)時(shí)流媒體協(xié)議??梢栽O(shè)計(jì)為一個(gè)與系統(tǒng)無關(guān)的模塊,以實(shí)現(xiàn)在目前 3 種 3G 標(biāo)準(zhǔn) WCDMA、 cdma2000、 TD -SCDMA 之上無縫移植和嵌入。我們以協(xié)議為指導(dǎo),根據(jù)無線移動(dòng)網(wǎng)絡(luò)的實(shí)際情況,做出合適的裁減和改變。流傳輸控制機(jī)制將根據(jù) 3G 網(wǎng)絡(luò)的特性和嵌入式實(shí)時(shí)系統(tǒng)的要求定制,使協(xié)議棧能夠發(fā)揮可靠的,高效率的作用。同時(shí)協(xié)議棧不僅提供標(biāo)準(zhǔn)的應(yīng)用程序接口,還可以根據(jù)客戶的要求特別定制專用的應(yīng)用程序接口。 2.2 流媒體協(xié)議棧整體架構(gòu) 基于 3G 終端的流媒體協(xié)議棧由 RTSP 協(xié)議棧, RTP/RTCP 協(xié)議棧, TCP/IP 協(xié)議棧組成。 2.2.1 TCP/IP 協(xié)議棧 TCP/IP 協(xié)議棧是由 3G 的協(xié)議棧提供,負(fù)責(zé)對(duì)流媒體數(shù)據(jù)的傳送。 TCP、 UDP 的協(xié)議都將使用到,并且根據(jù)不同的網(wǎng)絡(luò)情況,分別使用。 TCP 是用于可靠的連接, RTSP 協(xié)議將盡量使用這個(gè)協(xié)議進(jìn)行傳輸, UDP 是無連接的協(xié)議, RTP/RTCP 協(xié)議棧將通過這個(gè)協(xié)議傳送數(shù)據(jù)。當(dāng)然這也不是絕對(duì)的,在必要的時(shí)候, RTSP可以使用 UDP 協(xié)議,比如防火墻的強(qiáng)制隔離,要求代理服務(wù)器轉(zhuǎn)發(fā),這時(shí)需要由協(xié)議棧來保障 RTSP 協(xié)議的可靠性,包括使用重發(fā)機(jī)制; RTP/RTCP 也可以使用 TCP 連接,比如要求跨防火墻,建立直接連接的通道,這時(shí)可能牽涉到 RTSP 和 RTP/RTCP 協(xié)議的算法,需要由協(xié)議棧來提供。 2.2.2 RTP/RTCP 協(xié)議棧 RTP/RTCP 協(xié)議是流媒體協(xié)議棧中關(guān)鍵的一部分,它承擔(dān)了媒體數(shù)據(jù)的傳送,由 2 個(gè)相互緊湊的協(xié)議組成,數(shù)據(jù)報(bào)文實(shí)時(shí)傳輸使用的 RTP 協(xié)議和 QoS 監(jiān)視的 RTCP 協(xié)議。協(xié)議設(shè)計(jì)者并不考慮 RTP 協(xié)議的糾錯(cuò)功能,而要求下層協(xié)議來保證,以提高媒體幀傳輸?shù)臄?shù)量,節(jié)省帶寬,節(jié)省程序的開銷,其傳輸機(jī)制專注于媒體本身的可靠性傳輸。 RTP 直接面向媒體數(shù)據(jù),是一種以帶寬和網(wǎng)絡(luò)質(zhì)量為先決條件的傳輸協(xié)議,其傳輸方式是隨著帶寬和網(wǎng)絡(luò)質(zhì)量變化而 動(dòng)態(tài)調(diào)整的協(xié)議,其宗旨是以最大的可能性利用網(wǎng)絡(luò)的負(fù)載能力,確保大容量的多媒體數(shù)據(jù)能及時(shí)的傳輸。在這樣的設(shè)計(jì)思想下, 3G 信道帶寬不至于過度浪費(fèi),因此適合于手機(jī)終端的使用。同時(shí), RTCP 協(xié)議作為傳輸控制協(xié)議,也是網(wǎng)絡(luò)質(zhì)量的監(jiān)測(cè)者,它為互動(dòng)的雙方提供了統(tǒng)計(jì)意義上的報(bào)告,為雙方提供網(wǎng)絡(luò)實(shí)際的質(zhì)量,也為流量控制,編碼方式,提供了可靠的保證和參考。作為獨(dú)立于 3G 協(xié)議棧的應(yīng)用層媒體協(xié)議棧, RTCP 根據(jù)其機(jī)制,提供質(zhì)量服務(wù) QoS,為網(wǎng)絡(luò)運(yùn)營(yíng)商監(jiān)視網(wǎng)絡(luò)情況提供參數(shù)。 2.2.3 RTSP 協(xié)議棧 RTSP 協(xié)議棧是流媒體 協(xié)議棧中與界面和 RTP/RTCP 協(xié)議相關(guān)的控制協(xié)商操作。 RTSP 提供響應(yīng)界面操作的接口,直接響應(yīng)界面發(fā)送的命令。同時(shí) RTSP 也提供互聯(lián)的雙方或多方的一個(gè)傳輸方式和編碼方式的協(xié)商操作,在網(wǎng)絡(luò)允許情況下,建立一條最佳傳輸通道。以最匹配的情況傳輸數(shù)據(jù),而無須每次傳輸都要求雙方解析,節(jié)省了大量的時(shí)間,也減少了出錯(cuò)的可能性。 RTSP 和 RTP/RTCP 協(xié)議棧組成整個(gè)流媒體協(xié)議棧的核心部分,他們各自的控制機(jī)制是需要根據(jù)無線移動(dòng)網(wǎng)絡(luò)的實(shí)際情況和媒體編碼格式統(tǒng)籌設(shè)計(jì),在協(xié)議中是沒有硬性規(guī)定的。 3、 3G 視頻點(diǎn)播系 統(tǒng)中流媒體協(xié)議棧的模塊設(shè)計(jì) 系統(tǒng)的模塊化有利于整體功能的實(shí)現(xiàn),本系統(tǒng)框架從流媒體協(xié)議棧進(jìn)行規(guī)劃,分為 5 個(gè)模塊:人機(jī)界面、 RTSP 模塊、 RTP/RTCP 模塊,以及硬件媒體編解碼器模塊。模塊架構(gòu)如圖 3 所示。 圖 3 視頻點(diǎn)播系統(tǒng)架構(gòu) 3.1 人機(jī)界面( MMI) 界面部分是手機(jī)終端提供給用戶的交互界面。用戶可以使用它來控制播放的動(dòng)作,比如通過點(diǎn)擊 Web 的鏈接,接入流媒體服務(wù)器。可以進(jìn)行播放、暫停、終止、快進(jìn)、后退等操作,當(dāng)然,所有操作是在服務(wù)允許的范圍,超出服務(wù)范圍的操作將被禁止。通過界面,用戶就可以享受到視頻 /音頻的多媒體服務(wù),可以點(diǎn)播電影,也可以召開會(huì)議。 3.2 RTSP 模塊 RTSP 模塊是以客戶端為主的應(yīng)用控制模塊,以適應(yīng) 3G 手機(jī)終端對(duì)媒體點(diǎn)播的需要。主要內(nèi)容包括: RTSP協(xié)議棧的會(huì)話的建立、會(huì)話的傳輸、會(huì)話的協(xié)商和會(huì)話的終止,以及文本指令的解析。在流媒體協(xié)議棧架構(gòu)中, RTSP 處于 TCP/IP 層之上,使用 TCP 協(xié)議傳輸會(huì)話數(shù)據(jù)。處于界面控 制程序直接操作下,為應(yīng)用界面提供編程接口。同時(shí) RTSP 對(duì)媒體數(shù)據(jù)層和 RTP 協(xié)議有著控制的權(quán)利,可以調(diào)整 RTP 會(huì)話參數(shù),以及媒體層同步等等。 RTSP 是一個(gè)類似 HTTP 的服務(wù)器 -客戶端的模型,但與 HTTP 不同的是雙方都可發(fā)送請(qǐng)求并都可以響應(yīng)請(qǐng)求,是一個(gè)對(duì)等互動(dòng)的協(xié)商協(xié)議。 在此視頻點(diǎn)播系統(tǒng)中, RTSP 模塊通過 TCP 協(xié)議的三次握手機(jī)制來保證命令消息通道的可靠性。一方面接收服務(wù)器的確認(rèn)信息傳給應(yīng)用層進(jìn)行處理;另一方面接收來自客戶端的命令信息,解析后反饋給服務(wù)器。此外, RTSP 模塊支持以下操作: ( 1)從媒 體服務(wù)器端獲取媒體??蛻舳四軌蛲ㄟ^ HTTP 或者其它模式來請(qǐng)求一個(gè)的圖像描述。如果圖像正被多點(diǎn)傳輸,那么圖像描述就包含了用來傳輸連續(xù)媒體多點(diǎn)傳輸?shù)牡刂泛投丝?。如果圖像只能被單點(diǎn)傳送,那客戶端就要因?yàn)榘踩蚨峁┙o目的地址。 ( 2)邀請(qǐng)媒體服務(wù)器參加會(huì)議。一個(gè)媒體服務(wù)器端能夠被 “邀請(qǐng) ”參加一個(gè)存在的會(huì)議,可以回放媒體成為圖像,或者記錄圖像中的媒體的全部或者一部分。 ( 3)在存在圖像中增加媒體。尤其對(duì)于活動(dòng)圖像,如果服務(wù)器能告訴客戶端,增加的媒體是有用的。 3.3 RTP/RTCP 模塊 RTP/RTCP 模塊是以客戶端為主的應(yīng)用傳輸模塊。主要內(nèi)容包括: RTP/RTCP 協(xié)議棧的會(huì)話的建立,會(huì)話的傳輸,會(huì)話的控制和會(huì)話的終止。此模塊位于 TCP/IP 層之上,使用 UDP 協(xié)議傳輸數(shù)據(jù)。當(dāng)應(yīng)用程序開始一個(gè) RTP 會(huì)話時(shí)通常使用兩個(gè)端口:一個(gè)給 RTP,一個(gè)給 RTCP。在 RTP 會(huì)話期間,各參與者周期性地傳送 RTCP 包。 RTCP 包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料,因此,服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率,甚至改變有效載荷類型。 RTP 的媒體數(shù)據(jù)載荷加載準(zhǔn)則依賴于不同的媒體編碼格式而不同,數(shù)據(jù) 報(bào)文的格式按照 RFC 規(guī)定的實(shí)現(xiàn),如圖 4 所示。 圖 4 RTP 報(bào)文頭格式 同時(shí)應(yīng)用程序可以通過此模塊調(diào)整傳輸頻率去和接受者的能力相匹配,或者以適應(yīng)網(wǎng)絡(luò)擁塞。通過參加多點(diǎn)傳送組的適當(dāng)?shù)淖蛹邮苷吣苓m應(yīng)不同的網(wǎng)絡(luò)并控制他們的接受帶寬。此外模塊中所有的多媒體會(huì)話,都將視頻和音頻分別存放,這是為了保證在與某些不具有視頻功能的終端通信或者在網(wǎng)絡(luò)質(zhì)量惡劣的情況下,可以只提供音頻服務(wù),而將視頻服務(wù)關(guān)閉。 3.4 硬件媒體編解碼模塊 硬件媒 體編解碼器是基于 MPEG-4 實(shí)現(xiàn)的硬件 Codec,采集的視頻音頻原始數(shù)據(jù)通過它壓縮后形成 MP4 的數(shù)據(jù)格式,通過傳輸協(xié)議發(fā)往服務(wù)器;來自服務(wù)器的 MP4 視頻音頻數(shù)據(jù)通過 Codec 還原為原始數(shù)據(jù),送往終端顯示器,提供用戶動(dòng)態(tài)界面。當(dāng)然畫面可能因?yàn)閴嚎s和傳輸?shù)膿p傷有所下降,針對(duì)這樣的情況,協(xié)議棧將提供糾錯(cuò),補(bǔ)償,同步功能來修復(fù)損傷,力圖保持最完美的視頻語音效果。 4、流媒體同步機(jī)制 流媒體數(shù)據(jù)和傳統(tǒng)數(shù)據(jù)的一個(gè)主要不同是不同媒體流的集成,主要表現(xiàn)為同步方式。在 3G 視頻點(diǎn)播系統(tǒng)中,流媒體傳輸?shù)耐綑C(jī)制是一個(gè)非常 關(guān)鍵的問題,同步機(jī)制設(shè)計(jì)的好壞直接涉及到了播放效果,而播放效果則是直接面向用戶,是檢驗(yàn)媒體播放質(zhì)量的直接證據(jù)。 媒體同步定義是不同媒體流之間以及數(shù)據(jù)流內(nèi)的基于時(shí)間的關(guān)系。目前有 3 層同步,分別是系統(tǒng)同步(流內(nèi)同步)、媒體間同步(流間同步)和用戶層同步(目標(biāo)間同步)。 媒體數(shù)據(jù)的同步丟失是由于從服務(wù)器發(fā)往客戶端的媒體數(shù)據(jù)報(bào)文因?yàn)椴煌穆酚陕窂綄?dǎo)致,而且所有媒體數(shù)據(jù)的存儲(chǔ)轉(zhuǎn)發(fā)都將產(chǎn)生延遲和抖動(dòng)。延遲以及延遲的可變性將導(dǎo)致以上 3 種同步的丟失。因此,媒體間同步機(jī)制是必須的,以確保在客戶端正確的播放媒體數(shù)據(jù)。 4.1 系統(tǒng)同步(流內(nèi)同步) 系統(tǒng)同步(流內(nèi)同步)是底層同步。 連續(xù)媒體或者時(shí)間相關(guān)的數(shù)據(jù)(比如,視頻和音頻)的媒體層同步是最底一層。媒體層的最小單位是邏輯數(shù)據(jù)單位( LDU),比如視頻和音頻幀,需要嚴(yán)格的按照時(shí)間順序以確保用戶可以精確的回放。系統(tǒng)同步缺失將導(dǎo)致播放暫?;蛱S。 4.2 媒體間同步(流間同步) 時(shí)間相關(guān)數(shù)據(jù)的流層同步是第二層。流層的最小單位是整個(gè)流。沒有流間的同步將導(dǎo)致不同媒體數(shù)據(jù)的失調(diào)。 網(wǎng)絡(luò)的帶寬是完成流媒體傳輸?shù)奈镔|(zhì)基礎(chǔ),在傳輸聲音、圖像、視頻等多媒體信息流時(shí),即 使這些媒體流予以壓縮,所需的帶寬仍然比文字文件大,但并不是有足夠的帶寬就可以完全解決流媒體傳輸問題。一般而言,所需帶寬的多少是與應(yīng)用密切相關(guān)的,從應(yīng)用角度來看,只要用戶數(shù)不斷增加、信息服務(wù)量不斷增加,帶寬有多少都是不夠的。同步是媒體流的基本控制方法。流媒體是時(shí)間屬性的表現(xiàn),這依賴于 RTSP協(xié)議棧。 4.3 用戶層同步(目標(biāo)間同步) 這是多媒體文獻(xiàn)中規(guī)定的最高層次的同步,是對(duì)象之間的同步,它集成了流和與時(shí)間無關(guān)的數(shù)據(jù)。對(duì)象間同步要求,如果某個(gè)以前定義的與時(shí)間相關(guān)的媒體目標(biāo)到達(dá)客戶端,那么在一個(gè)允許的時(shí) 間間隔內(nèi),必須開始與之相對(duì)應(yīng)的與時(shí)間無關(guān)的數(shù)據(jù),同時(shí)停止與之不匹配的當(dāng)前的與時(shí)間無關(guān)的數(shù)據(jù)。 用戶層同步或交互同步,是最上層的同步,要求能反映和滿足用戶的交互性,容易為用戶理解接受。用戶層同步是交互性參與的同步,用戶可以控制和使用信息,如反復(fù)調(diào)用感興趣的內(nèi)容、快速掠過不感興趣的部分。雖然 RTSP 協(xié)議支持類似錄像機(jī)的功能:播放、快進(jìn)、暫停、停止,但流媒體的交互性同步能力主要體現(xiàn)在數(shù)據(jù)流編碼過程中對(duì)交互性能的考慮。 5、小結(jié)與展望 近
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 中西醫(yī)結(jié)合與特色療法
- 產(chǎn)科護(hù)理實(shí)踐與臨床經(jīng)驗(yàn)分享
- 2026年黑龍江林業(yè)職業(yè)技術(shù)學(xué)院高職單招職業(yè)適應(yīng)性測(cè)試備考題庫有答案解析
- 2026年廣州體育職業(yè)技術(shù)學(xué)院?jiǎn)握新殬I(yè)技能筆試備考試題帶答案解析
- 生命科學(xué)領(lǐng)域的納米技術(shù)應(yīng)用
- 住院部工作質(zhì)量回顧
- 個(gè)性化醫(yī)療與精準(zhǔn)治療方案
- 2026年常州工業(yè)職業(yè)技術(shù)學(xué)院?jiǎn)握芯C合素質(zhì)筆試備考題庫帶答案解析
- 醫(yī)院感染預(yù)防與控制規(guī)范解讀
- 醫(yī)療行業(yè)禮儀在護(hù)理操作中的重要性
- 2024年太陽能光伏發(fā)電項(xiàng)目EPC建設(shè)合同
- 裝修陪跑合同范本
- DL-T5181-2017水電水利工程錨噴支護(hù)施工規(guī)范
- 肺動(dòng)脈高壓診治進(jìn)展
- 國(guó)林臭氧氧化脫硝技術(shù)簡(jiǎn)介
- 2023核電廠地質(zhì)鉆探巖芯保管技術(shù)規(guī)程
- 稽核在管理中的重要性
- 蘇寧云商財(cái)務(wù)報(bào)表分析
- 西方油畫發(fā)展歷程
- 自來水公司招聘考試筆試題目
- GB/T 325.2-2010包裝容器鋼桶第2部分:最小總?cè)萘?08L、210L和216.5L全開口鋼桶
評(píng)論
0/150
提交評(píng)論