當(dāng)前位置:首頁 > 消費(fèi)電子 > 消費(fèi)電子
[導(dǎo)讀]1、 簡介手持式數(shù)字電視DVB-H(DigitalVideoBroadcasting-Handheld)系統(tǒng)標(biāo)準(zhǔn)規(guī)范[1]主要以地面廣播系統(tǒng)DVB-T(DigitalVideoBroadcasting-Terrestrial)的架構(gòu)為核心,再附加新的技術(shù)標(biāo)準(zhǔn)以進(jìn)行規(guī)格制定。由于DVB-T系統(tǒng)系

1、 簡介

手持式數(shù)字電視DVB-H(DigitalVideoBroadcasting-Handheld)系統(tǒng)標(biāo)準(zhǔn)規(guī)范[1]主要以地面廣播系統(tǒng)DVB-T(DigitalVideoBroadcasting-Terrestrial)的架構(gòu)為核心,再附加新的技術(shù)標(biāo)準(zhǔn)以進(jìn)行規(guī)格制定。由于DVB-T系統(tǒng)系利用編碼正交分頻多任務(wù)(CodedOrthogonalFrequencyDivisionMultiplexing,COFDM)之多載波調(diào)變技術(shù),對于多重路徑(Multi-path)反射效應(yīng)所衍生出的干擾及衰減問題,能提供有效的處理與抑制能力,因此非常適合使用于行動應(yīng)用。此外,DVB-H系統(tǒng)標(biāo)準(zhǔn)另外新增的功能與改進(jìn)的技術(shù)有:DVB-H傳輸參數(shù)信號(TransmissionParameterSignaling,TPS)、分時切片(TimeSlicing)、軟式交遞(SoftHandover)算法、4K模式、深度符號內(nèi)間插(In-depthsymbolinterleaver)與多協(xié)定封裝前向糾錯機(jī)制(Multi-ProtocolEncapsulationForwardErrorCorrection,MPE-FEC)等技術(shù),用來提升手持裝置之移動接收性能并克服耗電問題,更透過行動電視條件接收(ConditionAccess,CA)之應(yīng)用與電子服務(wù)指南(ElectricServiceGuide,ESG)等功能來使得所提供的服務(wù)內(nèi)容更為完備并更具保障。

2、 相關(guān)技術(shù)研究

最近對于DVB-H之MPE-FEC機(jī)制的研究文章,主要著重于接收端于解封裝時,如何對傳輸串流中的數(shù)據(jù)進(jìn)行錯誤偵測判斷、如何提供糾錯譯碼運(yùn)算時所需的錯誤信息與如何改善增強(qiáng)MPE-FEC機(jī)制對錯誤的檢測修復(fù)能力。

目前對于接收端接收數(shù)據(jù)進(jìn)行錯誤偵測與判斷的方式,主要能夠分為兩類,這兩類的主要差異點(diǎn)是在于不同層次的封裝格式上進(jìn)行錯誤偵測與判斷,其中一種判斷方式是在解傳輸串流封包時進(jìn)行,另一種則是在進(jìn)一步解多協(xié)議封裝(Multi-ProtocolEncapsulation,MPE)格式時進(jìn)行,而在DVB-H規(guī)范中的建議方式是采用后者,主要是利用循環(huán)冗贅核對(CyclicRedundancyCheck,CRC)來對數(shù)據(jù)進(jìn)行錯誤偵測與判斷。

另外,對于提供糾錯譯碼運(yùn)算時所需的錯誤信息方面,則會根據(jù)所提供的錯誤信息形式上的不同而有不同的糾錯譯碼方式。以上兩種方面的各種規(guī)劃設(shè)計概念大多已被整合介紹于一篇研究文章內(nèi)[2]并主要被分成五種架構(gòu),而本研究考慮設(shè)計與實作上的便利,故采用所謂的TSE(TransportStreamErasure)的錯誤偵測方式(即根據(jù)TS封包標(biāo)頭內(nèi)的錯誤指標(biāo)字段來進(jìn)行正確性判斷),而于RS譯碼部分則是采用歐幾里得(Euclid)方式來進(jìn)行RS糾錯譯碼。

3、 數(shù)字電視廣播系統(tǒng)核心技術(shù)簡介

3.1DVB-H傳輸系統(tǒng)結(jié)構(gòu)與封裝格式

DVB-H傳輸IP服務(wù)的傳輸系統(tǒng)如圖1所示。DVB-H的服務(wù)數(shù)據(jù)封裝成IP封包之后,再透過MPE機(jī)制封裝于傳輸串流之中,并同時加入Time-Slicing信息后與其它DVB-T的電視節(jié)目(MPEG-2TVService)經(jīng)由多任務(wù)器多任務(wù)成一個更大的傳輸串流(又稱復(fù)合節(jié)目串流,MultipleProgramTransportStream),再調(diào)變成無線信號送出,其中在發(fā)送端的MPE、MPE-FEC與Time-Slicing機(jī)制合稱為DVB-HIP封裝器(IP-Encapsulator),而在接收端的反向解回部份則稱為DVB-HIP解封裝器(IP-Decapsulator),而整個DVB-H的封裝格式則如同圖2所示。

圖1 DVB-H傳輸IP服務(wù)的傳輸系統(tǒng)[3]

當(dāng)影音壓縮與其它服務(wù)數(shù)據(jù)經(jīng)過一連串的封裝之后,最后將被封裝成傳輸串流(TransportStream)的封包格式,而在接收端將再其遞送給底層硬件進(jìn)一次所羅門編碼后,才將封包調(diào)變成無線訊號送出。相對地在接端接收到封包時,將先進(jìn)行一次所羅門譯碼,而將譯碼的結(jié)果記錄在封包標(biāo)頭中。

圖2DVB-H數(shù)據(jù)封裝格式

3.2Time-Slicing傳輸機(jī)制與時間參數(shù)

Time-Slicing傳輸機(jī)制的目的在于降低手持式終端設(shè)備的平均能源消耗與實現(xiàn)SoftHandover機(jī)制在基地臺間平滑交接。Time-Slicing傳輸機(jī)制如圖3所示,系以瞬間高流量脈波傳輸(Burst)的方式傳輸數(shù)據(jù)。

圖3Time-Slicing傳輸機(jī)制的Burst傳輸方

 

另外,為了讓接收端設(shè)備能正確地接收每一個Burst數(shù)據(jù),故在Burst中夾帶時間卷標(biāo)(Delta-T)信息來指出下一個Burst到達(dá)的時間(如圖4),而接收端則預(yù)先提早Delta-TJitter的時間來打開接收器,以便能正確地接收數(shù)據(jù),介于兩個Burst中間的OffTime時間則不傳輸任何數(shù)據(jù),藉由此種頻寬分享方式來傳遞其它不同服務(wù)的數(shù)據(jù)。整個Burst在傳輸數(shù)據(jù)時有個最大持續(xù)時間(MaxBurstDuration)而這個信息也一并被夾帶于整個傳輸流中傳送。

圖4時間參數(shù)Delta-T示意圖

3.3MPE-FEC機(jī)制原理與運(yùn)作

MPE-FEC機(jī)制在DVB-H系統(tǒng)中負(fù)責(zé)進(jìn)行錯誤數(shù)據(jù)修復(fù)動作,整體技術(shù)是建構(gòu)于一個名為MPE-FEC框架的方形內(nèi)存裝置之中。如圖5,此框架又被定義成兩部份稱為:ApplicationDataTable與RSDataTable,其分別用來存放DVB-H系統(tǒng)中傳送的服務(wù)數(shù)據(jù)與糾錯冗余編碼數(shù)據(jù)。

圖5MPE-FEC框架

如圖6,在發(fā)送端透過縱向填入數(shù)據(jù)與橫向糾錯編碼來完成交織編碼的編碼方式再進(jìn)行封裝傳送。而在接收端接收后則進(jìn)行反向的糾錯譯碼動作,藉此來修復(fù)因傳輸所發(fā)生的數(shù)據(jù)錯誤。

圖6 MPE-FEC框架交織編碼方式

4、 DVB-H軟件接收器系統(tǒng)設(shè)計

DVB-H接收器的詳細(xì)軟件架構(gòu)如圖7所呈現(xiàn),主要由傳輸串流分派器(TransportStreamDispatcher)、子譯碼器(SubDecoder)組件、控制器(Controller)對象與MPE-FEC運(yùn)算單元(MPE-FECOperationUnit)所組成。

圖7DVB-H接收器軟件架構(gòu)

4.1傳輸串流分派器

傳輸串流分派器主要負(fù)責(zé)將DVB-H傳輸串流中各種類型的封包轉(zhuǎn)遞給不同的子譯碼器進(jìn)行處理并從封包中過濾使用者所欲觀看的節(jié)目傳遞給DVB-H終端裝置。若在Burst傳輸期間,封包數(shù)據(jù)因噪聲干擾而損毀,或者傳送端于傳送時為符合服務(wù)的傳輸位率而添加一些填塞封包,因此為減少封包的處理時間,故在傳輸串流分派器取得封包之后,便先檢查此流封包是否發(fā)生錯誤與是否為填塞封包,若發(fā)生錯誤,則將封包丟棄,而整個執(zhí)行程序?qū)⑦M(jìn)入到錯誤分類機(jī)制(ErrorCategorizationmechanism)中,若為填塞封包則即早丟棄,避免填塞封包送入子譯碼器中花費(fèi)不必要的處理時間。為簡化子譯碼器的復(fù)雜度,傳輸串流分派器系使用分派表方式來注冊欲譯碼的封包子譯碼器類型,并藉此分離各個子譯碼器之間的相依關(guān)系。分派表系采用雜湊表(Hashtable)的一種應(yīng)用,使用雜湊表的優(yōu)點(diǎn)在于不論注冊數(shù)量的多寡,查詢時間花費(fèi)永遠(yuǎn)固定為常數(shù)值,因此將可廣泛支持未來規(guī)范中新增的窗體或電視臺所自訂的私有窗體。而整個傳輸串流分派器的分派處理動作則如表1的虛擬程序代碼(Pseudocode)所示。

表1 傳輸串流分派器之虛擬程序代碼

If System Start then

Set Buffer to receive TS packet

If ErrorIndicator is equal to 1

Drop this TS packet

Start Error Categorization mechanism

else if PID is equal to 8191

Drop this TS packet

else if PayloadUnitStartIndicator is equal to 1

If ContinueSection is not equal to Null

Call the sub-decoder to continue decode

else

If sub-decoder is not found

Drop this unknown TS packet

else

Call the sub-decoder to decode

else

If ContinueSection is not equal to Null

Call the sub-decoder to continue decode

else

Drop this TS packet

 

4.2子譯碼器組件

于初始化時期,子譯碼器必須向傳輸串流分派器注冊封包類型,以便從傳輸串流分派器中得到相對應(yīng)的封包。

表2子譯碼器共通虛擬程序代碼

Function:DecodeFunction

從傳輸串流分派器中取得section中的第一個封包并譯碼。

Set PayloadBuffer to receive the section data

Set PaylaodLength equal to PacketPayloadLength

If SectionHeaderLength is equal to 12

Decode the section header

If section payload is not equal to Null

Output section payload to

SectionPayloadCottectionUnit

else

Set ReceiveLength equal to PayloadLength

Set ContinueSection to this sub-decoder

Function:ContinueFunction

從傳輸串流分派器中取得接續(xù)的section封包資料。

Set PayloadBuffer to receive the section data

Set PayloadLength equal to PayloadLength add

ReceiveSectionPayloadLength

If SectionHeaderLength is equal to 12

Decode the section header

If section payload is not equal to Null

Output section payload to

SectionPayloadCottectionUnit

If PayloadLength is equal to SectionLength

Set ContinueSection to Null

else

Set ContinueSection to this sub-decoder

子譯碼器共通的虛擬程序代碼如表2所示,傳輸串流分派器則根據(jù)分派表中已經(jīng)注冊的子譯碼器信息來遞送封包給特定子譯碼器,子譯碼器則根據(jù)封包中所傳達(dá)的數(shù)據(jù)將訊息或組態(tài)釋出,并傳遞給控制器對象。當(dāng)子譯碼器藉由解讀section的長度字段得知該section數(shù)據(jù)長度超過一個封包所能承載的數(shù)量時,會將接續(xù)片段指針對象設(shè)定指向自己。此后,當(dāng)傳輸串流分派器接收到封包后,將會檢視接續(xù)片段指針對象是否為空對象,若為空對象則從分派表中尋找負(fù)責(zé)解碼此封包的子譯碼器。若非空對象,則將封包傳送給欲接續(xù)接收的子譯碼器,直到整個section數(shù)據(jù)接收完成之后,子譯碼器才會將接續(xù)片段指針對象重設(shè)為空對象,而從下一個封包開始,將以正常程序?qū)ふ曳獍幼g碼器。

4.3控制器對象

控制器對象為DVB-H軟件接收器與使用者互動的接口。控制器的主要功能除了擷取使用者的輸入訊息之外,也實作訊息輸出接口。在控制行為部分,控制器僅與子譯碼器互動,在訊息輸出方面,則是與整個DVB-H軟件接收器中的所有組件連結(jié)在一起。另外,在實作設(shè)計上則不同于傳統(tǒng)將控制接口嵌入于播放器的作法,藉由此方式達(dá)到DVB-H軟件接收器與播放裝置各別獨(dú)立的能力。

4.4MPE-FEC運(yùn)算單元

MPE-FEC運(yùn)算單元主要負(fù)責(zé)進(jìn)行整個MPE-FEC機(jī)制的運(yùn)作,如圖8而其又可分為三個運(yùn)作單元,分別為:MPEsection數(shù)據(jù)收集單元、FECsection數(shù)據(jù)收集單元與所羅門譯碼單元(RSDecodingUnit)。

其中MPE與FECsection數(shù)據(jù)收集單元主要負(fù)責(zé)收集從子譯碼器解讀取出的section數(shù)據(jù),當(dāng)完成section數(shù)據(jù)收集后即填入位于所羅門譯碼單元中的MPE-FEC框架中,直到整個框架的所有section數(shù)據(jù)均已收集完成,則立即進(jìn)行每列的所羅門糾錯譯碼,藉此來修復(fù)于傳輸時因噪聲干擾所造成的數(shù)據(jù)錯誤。

4.5錯誤產(chǎn)生、偵測與分類機(jī)制

當(dāng)接收端硬件接收到由傳送端所傳送的傳輸串流封包時,硬件會先對封包進(jìn)行一次所羅門譯碼,若是超出其糾錯解碼能力時,將會把封包標(biāo)頭內(nèi)的錯誤指標(biāo)字段(ErrorIndicator)設(shè)定為1,藉此來標(biāo)示發(fā)生錯誤的封包,而本研究于錯誤偵測判斷時,即是根據(jù)此標(biāo)頭字段值,并透過設(shè)定此字段值來產(chǎn)生顯著的錯誤數(shù)據(jù),以突顯MPE-FEC機(jī)制的運(yùn)作。當(dāng)發(fā)現(xiàn)錯誤封包之后,將立即執(zhí)行錯誤分類機(jī)制來找出錯誤發(fā)生在整個section的哪個區(qū)段并在一個與MPE-FEC框架相同大小的ErrorBit-mapBuffer(EBB)中的相對應(yīng)位置設(shè)成1來表示其在框架中的錯誤位置,以便提供往后所羅門譯碼所需的錯誤位置數(shù)據(jù),而整個錯誤分類機(jī)制的虛擬程序代碼如表3所示。

表3 錯誤分類機(jī)制虛擬程序代碼

If ErrorIndicator is equal to 1

If HeaderDecoded is true

If error at middle of section

Set 1 in EBB according to the TS payload

region of this section in MPE-FEC frame

Drop this TS packet

else

If packet carry part of next section header

Set 1 in EBB according to the TS payload

region of this section and whole the next

section payload region in MPE-FEC

frame

Drop this TS packet and drop all TS

packets of next section

else

Set 1 in EBB according to the TS

payload region of this section in

MPE-FEC frame

Drop this packet

else

Set 1 in EBB at whole section payload

region in MPE-FEC frame

Drop all TS packets of this section

當(dāng)傳輸串流分派器收到封包并立即偵測與判斷封包標(biāo)頭中的錯誤指標(biāo)字段是否為1,若為1則表示發(fā)生錯誤而進(jìn)一步開始找出此錯誤封包所載送的數(shù)據(jù)是位于整個section的哪個區(qū)段位置,若是發(fā)生在section標(biāo)頭部位,由于標(biāo)頭是載送整個section最重要的信息來源位置,因此為了能正確地接收往后的section,故當(dāng)發(fā)生錯誤的封包包含任一字節(jié)的標(biāo)頭信息時,將會將整個section數(shù)據(jù)完全丟棄而等待下一個正確載送section標(biāo)頭的封包進(jìn)來。如果發(fā)生錯誤的封包是載送標(biāo)頭信息之外的部份時,則再進(jìn)一步判斷封包中載送的數(shù)據(jù)范圍是位于整個section數(shù)據(jù)的哪個區(qū)段,若僅是中間部位,則只丟棄該封包而等待下一個正確封包即可,但若是section末端數(shù)據(jù)的話,則需再進(jìn)一步的判斷是否包含到下一個section標(biāo)頭信息,如果有的話,則一并把載送下一個section數(shù)據(jù)的所有封包丟棄而等待下一個正確載送section標(biāo)頭的封包進(jìn)來,反之則一樣僅丟棄該封包即可。

4.6Time-Slicing傳輸機(jī)制設(shè)計

DVB-H傳送數(shù)據(jù)的方式是采用Burst傳輸方式,采用此種方式時,則必須精確地得知下一個Burst的抵達(dá)時間與傳輸該Burst數(shù)據(jù)的最大傳輸時間,才能讓硬件能于正確時間點(diǎn)開關(guān)接收器來接收數(shù)據(jù),而接收端在接收數(shù)據(jù)時,必須滿足兩個時間要求:

(1) 當(dāng)Burst到來,并接收到第一個MPEsection進(jìn)行解讀時,section標(biāo)頭必須在Delta-TJitter時間內(nèi)解碼并將Delta-T值回傳到實體層。

(2) IP解封裝器必須于Delta-T時間內(nèi)完成所有section的譯碼與MPE-FEC機(jī)制的運(yùn)作,并將數(shù)據(jù)輸出到終端。

由于未必能在Burst的最大維持時間內(nèi)將所有section數(shù)據(jù)解讀完成,故接收端必須以緩沖器暫存整個Burst時間內(nèi)的所有section封包,而封包的譯碼工作在剩余的Delta-T時間內(nèi)完成即可。

 

除此之外,由于在處理的過程中使用緩沖器來暫存section封包數(shù)據(jù),而再取出解讀時,其標(biāo)頭中所挾帶的實時性Delta-T信息已失效,僅有解讀第一個MPEsection所造成的延遲時間最為短暫。

因此,在實作上即采用第一個MPEsection標(biāo)頭所挾帶的Delta-T信息來告知實體層下一個Burst的到來時間,而其余section標(biāo)頭內(nèi)的Delta-T信息將不被讀取采用。整個section封包處理延遲時間示意圖即以圖9呈現(xiàn)。

圖9 section封包處理延遲時間示意圖

5、 實驗?zāi)M結(jié)果

本研究整個實驗?zāi)M結(jié)果均是利用個人計算機(jī)(PC)進(jìn)行測試,個人計算機(jī)的配備如表4所呈現(xiàn),并以公視試播計劃所提供的傳輸串流當(dāng)作是播放測試檔案,而表5則是從公視所提的串流檔案擷取出來的信息。

5.1正確性驗證

本研究糾錯后的數(shù)據(jù)驗證是利用文字處理軟件Ultra-Edit所提供的二進(jìn)制檔案比對來完成,分別將添加錯誤的每個Burst數(shù)據(jù)與修正后的數(shù)據(jù)存成檔案后再與驗證檔案進(jìn)行比對。

5.2效能評估

本文的MPE架構(gòu)與Time-Slicing傳輸機(jī)制設(shè)計主要采用[4]的觀實作觀念與架構(gòu),[4]中對每個Burst數(shù)據(jù)(僅有針對MPEsection)的處理時間已有相當(dāng)完整的分析信息,故本論文即針對主要設(shè)計的MPE-FEC糾錯機(jī)制做實作上的效能分析與探討。

表4個人計算機(jī)基本配備表

處理器廠牌規(guī)格

Intel Pentium 4

處理器處理速度

3.0 GHz

硬盤大小

80 GBytes

內(nèi)存容量

512 MBytes

表5公視影像來源參數(shù)數(shù)據(jù)

參數(shù)

數(shù)值

檔案大小

755,605,652(bytes)

封包總數(shù)

4,019,179(封包以188個bytes為單位)

MPE-FEC框架總列數(shù)

512列

Delta-T

1250 ms

Delta-T Jitter

7.5 ms

最大Burst持續(xù)時間

200 ms

省電效率

79.7%

每秒畫面更新速率

15 (frame per second,

整個傳輸流檔案中,每個Burst所挾帶的框架大小為255×512,而框架資料量大小為1Mbits(128kBytes),每個MPE-FEC框架執(zhí)行的RS糾錯運(yùn)算次數(shù)為512次(即每一列執(zhí)行一次RS糾錯運(yùn)算),編碼率(coderate)為2/3的情況條件下,10個Burst、50個Burst與100個Burst單純使用Java以及RS譯碼采用Euclid算法在Windows上的完整MPE-FEC糾錯機(jī)制與單純RS譯碼的平均執(zhí)行時間如圖13所示。

圖13完整MPE-FEC機(jī)制運(yùn)作與單純RS解碼的平均執(zhí)行時間

由圖13可知整個MPE-FEC機(jī)制的運(yùn)作時間大多花費(fèi)在RS譯碼上,因此本研究進(jìn)一步將RS譯碼使用C/C++并且使用RS內(nèi)部不同的譯碼算法透過Java的JNI(JavaNativeInterface)呼叫在Windows上執(zhí)行完整的MPE-FEC機(jī)制,其執(zhí)行解果如圖14所呈現(xiàn)。

圖14Java與C/C++以及不同算法在Windows上的平均執(zhí)行時間

 

雖然就執(zhí)行時間上來看,使用C/C++并采用BM算法的譯碼時間較短,但對于表5所擷取到的Delta-T時間(1250毫秒)而言,仍無法達(dá)到DVB-H接收端的實時播放。因此,再進(jìn)一步測試在Linux系統(tǒng)上不同算法的C/C++語言執(zhí)行時間并與Windows的執(zhí)行時間匯整而得到圖15。

圖15不同操作系統(tǒng)下,C/C++使用不同算法的執(zhí)行時間

在Linux操作系統(tǒng)上執(zhí)行完整的MPE-FEC機(jī)制運(yùn)作后所得到的平均執(zhí)行時間均小于在Windows上的執(zhí)行時間。此外,使用BM算法在Linux與Windows上的執(zhí)行時間更相差約略2.5秒,并且已能符合DVB-H接收端實時播放的時間要求。

最后在Windows將測試檔案加入錯誤后,再透過本研究所設(shè)計的軟件系統(tǒng)進(jìn)行糾錯之后所得的數(shù)據(jù)存成檔案再進(jìn)行播放。

6、結(jié)論

本研究利用純軟件的方式來仿真實作DVB-HMPE-FEC糾錯機(jī)制,并確實能修復(fù)還原添加于測試檔案中的錯誤,雖然于Windows操作系統(tǒng)上的數(shù)據(jù)處理時間已超過實時播放的時間要求,但在Linux上采用BM算法的RS譯碼測試實驗結(jié)果,卻已符合實時播放的限制條件。因此,以系統(tǒng)的執(zhí)行時間及實時播放的角度來看,對于往后的軟件設(shè)計實作,在Linux上實現(xiàn),或許會比在Windows上更為理想。

 

 

 

 

 

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉