精品国产人成在线_亚洲高清无码在线观看_国产在线视频国产永久2021_国产AV综合第一页一个的一区免费影院黑人_最近中文字幕MV高清在线视频

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

為什么編解碼器需要解碼器模型

LiveVideoStack ? 來源:LiveVideoStack ? 作者:Andrey Norkin ? 2020-08-10 16:50 ? 次閱讀

這篇文章可以作為AV1規范中與解碼器型號和級別有關的部分的簡介,本文的其余部分描述了一些AV1基本概念,AV1解碼器模型,并提供了開發它時做出決策的原因。有關解碼器模型的更多詳細信息,請閱讀AV1規范。

為什么編解碼器需要解碼器模型

大多數現代視頻編解碼器都具有某種形式的解碼器模型。在MPEG-2中,它被稱為視頻緩沖驗證器(VBV);在H.264 / AVC和HEVC / H.265中,它可以稱為假設參考解碼器(HRD)。解碼器模型提高了互操作性。解碼器模型允許確認一個比特流是否可以被一個特定的解碼器解碼。這些模型還可以向解碼器提供關于何時開始解碼幀以能夠及時顯示它的指令。 通常來說,視頻解碼器聲明支持某個配置文件和級別。配置文件可以指定有關比特深度和色度二次采樣的視頻格式,以及解碼器需要支持的以解碼比特流的一組編碼工具。級別描述了視頻比特流的定量特征,例如分辨率,幀速率和比特率。對于視頻編解碼器生態系統而言至關重要的一點是,表明支持某個級別的解碼器是否能夠解碼符合該級別要求的任何比特流,并且內容提供商和編碼器制造商可以檢查其生成的流是否符合這些要求。 為了實現這些目標,由開放媒體聯盟(AOM)開發的AV1規范定義了與配置文件和級別系統耦合的解碼器模型。AV1解碼器模型包括平滑/位流緩沖區,解碼過程以及對解碼后的幀緩沖區的操作。這篇文章可以作為AV1規范中與解碼器型號和級別有關的部分的簡介。本文的其余部分描述了一些AV1基本概念,AV1解碼器模型,并提供了開發它時做出決策的原因。有關解碼器模型的更多詳細信息,請閱讀AV1規范。

AV1比特流的高級結構

在更高級別上,AV1結構以開放比特流單元(OBU)打包。每個OBU都有一個標頭,該標頭提供標識其有效負載的信息(請參見圖1)。可以在AV1視頻比特流中出現的OBU類型的示例是序列頭OBU,幀頭OBU,元數據OBU,時間定界符OBU和圖塊組OBU。幀OBU由打包到一個OBU中的幀頭和圖塊組OBU組成,以提供一種通用結構的更有效表示,其中幀頭數據后緊跟著幀或圖塊組數據。 根據語法元素show_existing_frame的值,AV1幀頭可以分為兩種主要類型。

show_existing_frame等于0的幀頭是需要解碼的常規幀。show_existing_frame等于1的幀頭指定了在該幀頭中指定的顯示時間顯示先前解碼的幀(由frame_to_show_map_idx表示)的命令。當解碼順序與顯示順序不同時,該機制有助于幀重新排序。 另一個AV1概念是時間單元(TU),它由時間定界符OBU和在此之后且在下一個時間定界符OBU之前的所有OBU組成。TU始終遵循遞增的顯示順序。如果未使用可伸縮性,則TU僅包含一個顯示幀,即show_existing_frame等于1或show_frame等于1的幀。如果使用了可伸縮性,則TU中來自不同可伸縮層的所有顯示幀都對應于相同的呈現時間。 一個TU也可以包含show_frame標志等于0的幀。此類幀會被解碼但不會立即顯示。它們用于支持如上所述的幀重排序。類似地,也可以發送覆蓋幀,該覆蓋幀會對先前解碼的幀(稱為替代參考幀(ARF))與源幀之間的差異進行編碼。AV1比特流的這一方面類似于VP9編解碼器中的超幀。 在圖2中顯示出了將比特流劃分為時間單元的示例。在該圖中,幀編號按照顯示順序編號。比特流使用具有三個時間層的4幀的雙向層級預測結構。show_frame等于0的幀顯示為青色框,show_frame等于1的幀顯示為深綠色框。FrameHdr 2是show_existing_frame標志等于1的幀頭,該幀指向先前解碼的Frame 2。

平滑緩沖

平滑緩沖器是AV1解碼器的一部分,用于存儲AV1比特流,直到壓縮數據被解碼器解碼完畢為止。緩沖區由所謂的“漏桶”模型構成。漏桶的類比和編碼器的操作有關,在壓縮器中,壓縮幀被分塊轉儲到緩沖區中,并且數據以恒定速率連續離開緩沖區。解碼器緩沖區是編碼器之一的對應部分。注意,平滑緩沖器是解碼器內部的。通常來說,解碼系統會在更高級別上具有其他緩沖區,這些緩沖區不在AV1規范的范圍內。從解碼器模型的角度來看,可以將較高級別的緩沖區視為傳輸通道中造成總延遲的一部分。例如,從解碼器的角度來看,與自適應流式傳輸有關的緩沖將被視為傳輸通道的一部分,在本文中不再討論。而且,可能經常出現預先準備編碼的比特流,而這會使延遲相當長。但是,對于模型而言,這樣的長延遲通常不是問題,因為它在方程式中被抵消了。 平滑緩沖區可確保解碼器具有足夠的內部存儲器來存儲到達(或讀取)的位流的數據。當解碼器需要時,它還確保下一幀的壓縮數據在緩沖區中。平滑緩沖器的大小限制了瞬時比特率的變化,并限制了幀數據消耗的時序。 AV1解碼器模型僅支持可變比特率(VBR)操作模式,而不支持恒定比特率(CBR)模式。解碼器模型的VBR模式是一種抽象模式,其中速率在最大級別比特率和零之間交替。聽起來可能有限制。但是,此模型足以確保在最壞的情況下確保比特流與解碼器功能匹配。 平滑緩沖區充滿度隨時間變化的示意圖如圖3所示。時鐘從與幀0有關的第一個比特的到達開始。斜線的斜率與比特到達的速率相對應。Removal [i]對應于從緩沖區中刪除幀i的數據并開始解碼幀i的時刻。注意,可能會有一段時間沒有新的比特到達,例如Removal [1]之后的時間。這與編碼器沒有要發送的位(即編碼器緩沖區為空)的時間段匹配。

幀i的removal [i]是根據兩種解碼模式之一來定義的。在解碼調度模式下,這些值在比特流中用信號發送。在資源可用性模式下,根據解碼器操作導出Removal [i]。解碼的開始,即Removal [0],由兩種模式中的變量decoder_buffer_delay確定。 在時間Removal [i]時從解碼緩沖區中刪除的比特屬于可解碼幀組(DFG)i,即與幀i ? 1相關的最后一個OBU的末尾與與幀i相關的最后一個OBU的末尾之間的所有OBU 。DFG中的OBU可以包括序列頭OBU,幀和圖塊組OBU,幀頭OBU和元數據OBU。 DFG i的第一位到達平滑緩沖區由FirstBitArrival [i]確定,該值如下所示:

關于后一個表達式中coder_buffer_delay和decoder_buffer_delay之間關系以及其他有用的信息可以從Ribas-Corbera et al, 2003中找到很好的解釋。該模型假設一個編碼器具有一個以恒定速率發送比特的平滑緩沖器,并且一個解碼器帶有一個以該比特率接收比特的平滑緩沖器。通常來說,encoder_buffer_delay和decoder_buffer_delay的作用是確定幀的編碼和解碼之間的延遲,因此限制了比特流存儲在解碼器緩沖區中的“窗口”(通過網絡/信道進行的傳輸是排除在外的)。由于緩沖區大小設置為比特流在最大級別比特率下的1秒,因此建議不要將這兩個變量的總和超過90 000,這相當于時鐘頻率的1秒。 當low_delay_mode標志等于1時,解碼器在低延遲模式下運行,在該模式下,幀數據在預定的移除時間可能還不在緩沖區,在這種情況下,移除時間會延遲,直到數據到達緩沖區。 除非處于低延遲模式,否則平滑緩沖區不應下溢。平滑緩沖區也不應溢出。這些限制適用于所有一致的比特流。

解碼幀緩沖區

幀緩沖器用于存儲解碼后的幀,以便可以將它們用于幀間預測或之后的顯示。AV1定義了一個緩沖池,該緩沖池代表幀緩沖區的存儲區域。AV1幀緩沖區的管理示意圖如圖4所示。AV1規范要求解碼器支持10個物理幀緩沖區。幀緩沖器的時隙應能夠以對應級別的最大分辨率存儲幀。虛擬緩沖器索引(VBI)用于指向圖片間預測中的幀。VBI可以在幀緩沖池中存儲8個幀索引。并且允許不同的VBI條目指向同一緩沖區。空的VBI條目值為-1。當前幀緩沖區索引(cfbi)將索引存儲到正在解碼當前幀的幀緩沖區。注意,有一個“額外的”物理幀緩沖區,可用于保存幀以用于顯示。

數組DecoderRefCount和PlayerRefCount(圖4中的前兩行)分別跟蹤解碼和顯示過程是否仍需要幀緩沖區。DecoderRefCount跟蹤對VBI中的幀緩沖區的引用數,并由語法元素refresh_frame_flags更新,而當幀在上次演示時已顯示時,PlayerRefCount設置為0。空幀緩沖區和相應的計數器在圖4中顯示為白色方塊。 幀緩沖器對視頻幀的解碼和表示施加了限制,從而限制了編碼器可以使用哪些預測結構和幀的重新排序。通常來說,10個幀緩沖區允許支持相當復雜的預測結構。解碼器模型在應顯示該幀時會驗證該幀是否可用,并且在應解碼一幀時在緩沖池中有一個空閑位置。

解碼過程

AV1解碼器模型的解碼過程將對平滑緩沖區和解碼器幀緩沖區的操作聯系在一起。特別地,解碼器模型確定何時開始幀解碼以及從平滑緩沖器中移除幀比特,這立即使平滑緩沖器的飽和度降低了相應的量。解碼器模型還會計算解碼何時完成,并將解碼后的幀添加到幀緩沖區。它還確定何時為顯示輸出幀并將其從緩沖區中移除。 AV1的一個特點是廣泛使用替代參考幀(ARF),即用作預測參考但從未顯示過的幀。此外,AV1在主配置文件中支持參考圖片的縮放和可伸縮性。這意味著該模型應適應幀解碼所需的不同時間,并支持不同的幀解碼和顯示速率。請注意,即使H.264和HEVC允許顯示不可顯示的圖片,但這并不是這些編解碼器的典型用法,而在AV1中,這是一種典型的使用情況,需要解碼器模型很好地支持。

圖5中展示了使用ARF進行編碼的示例。該圖顯示了sub-GOP大小為4的雙向層級結構編碼。可顯示的幀顯示為灰色矩形。不顯示的替代參考幀(ARF),用白色矩形表示。通常,該幀是在相同時間位置的幀的濾波版本,這為幀間預測帶來了優勢。由于對ARF進行了低通濾波,因此可以使用ARF作為預測因子對覆蓋幀(圖5中的OL)進行編碼。覆蓋幀會添加高頻和紋理信息。 為了支持替代參考幀和不同分辨率的幀,AV1解碼器模型引入了以下功能: l在解碼器中使用不同數量的時間單位并顯示時鐘節拍的可能性。注意,圖5中的顯示時鐘節拍(DispCT)和解碼時鐘節拍(DecCT)具有不同的長度,因為解碼和顯示速率不同。解碼器和顯示刻度均使用相同的時標,并且時鐘已同步l幀不會立即解碼,并且根據幀分辨率和其他因素,可以有不同的時間可以看到,圖5中的解碼和顯示時間軸使用了不同的時鐘節拍。顯然,在顯示幀之前需要完成每個幀的解碼。為了確保將來有可用的幀,編碼器可以使用initial_display_delay_minus_1,該參數對應已解碼的幀數減去在顯示第一幀之前幀緩沖區中應可用的幀數。此參數相對于解碼偏移了顯示過程。如果未發信號,則將initial_display_delay_minus_1的值推斷為BUFFER_POOL_MAX_SIZE ?1。總的顯示延遲包括coder_buffer_delay,它與圖3中的變量相同,是從第一個比特到達到開始解碼幀0之間的時間,即Removal [0]。 解碼幀i所需的時間確定為: TimeToDecode [i] = lumaSamples [i]÷MaxDecodeRate, 其中,MaxDecodeRate以樣本/秒為單位進行測量,并由每個解碼器級別指定。依次為幀內預測幀計算lumaSamples,如下所示: lumaSamples [i] = UpscaledWidth [i] * FrameHeight [i]。 UpscaledWidth是使用可選的超分辨率工具后的幀的寬度。對于幀間預測幀,在參考圖片重采樣的情況下,考慮到來自分辨率更高的幀的可能運動補償,可以確定此數量,如下所示 lumaSamples [i] = max_frame_width * max_frame_height。 在可伸縮比特流中,將lumaSamples確定為當前可伸縮層的最大寬度和高度的乘積。 除了知道幀解碼需要花費多長時間之外,解碼器模型還需要確定何時開始解碼以及從平滑緩沖區中刪除壓縮幀,即Removal [i]。關于如何計算Removal [i],AV1具有兩種不同的模式。這兩種模式是以下描述的資源可用性模式和解碼調度模式。

資源可用性模式

在資源可用性模式中,如果在解碼的幀緩沖區中有可用的空閑位置,則在完成前一幀解碼之后立即解碼一幀。否則,在一個位置釋放后對幀進行解碼。如果比特流低于解碼器的最大級別限制,則逐幀解碼這些幀,直到它們填滿所有可用的幀緩沖區,此后解碼速度會減慢。然后,僅在解碼的幀緩沖區釋放后,才進行下一幀的解碼。幀0的刪除時間由decoder_buffer_delay確定: Removal[ 0 ] =decoder_buffer_delay÷ 90000 要使用資源可用性模式,應在比特流中設置以下參數:Timing_info_present_flag = 1,decoder_model_info_present_flag = 0,并且equal_picture_interval =1。標志equal_picture_interval等于1表示使用了恒定的幀速率,并且不發送顯示時間。而是從幀速率和initial_display_delay_minus_1得出顯示時間。解碼定時Removal [i]由解碼的幀緩沖器可用時的時刻來決定,并且也不發信號通知。一些解碼器模型參數在資源可用性模式下采用默認值,例如,encoder_buffer_delay = 20 000,decoder_buffer_delay = 70 000,low_delay_mode_flag = 0。

解碼調度模式

在解碼調度模式下,除了幀顯示時間之外,還在視頻比特流中用信號發送解碼時間Removal [i]。該模型靈活地定義了何時從平滑緩沖區中刪除幀并對其進行解碼,以及何時顯示該幀。除了使用恒定的幀速率外,該模型還可以通過顯式發送幀表示時間來支持變化的幀速率。除此之外,解碼器時鐘節拍DecCT以及decoder_buffer_delay,encoder_buffer_delay和ScheduledRemovalTiming [i]也以這種解碼模式發送信號。 在這種模式下,幀i的計劃刪除時間如下所示。 ScheduledRemovalTiming [0] = encoder_buffer_delay÷90 000。 ScheduledRemovalTiming [i] = ScheduledRemovalTiming [PrevRap] + buffer_removal_time [i] * DecCT, 其中PrevRap是先前的隨機訪問點(RAP)。如果幀i對應于RAP,但不是比特流中的第一幀,則PrevRAP對應于先前的RAP。這里的隨機訪問點是指比特流中的一個位置,可以從中解碼該比特流。它通常對應于一個關鍵幀,并且應包含所有開始解碼位流所需的信息,包括序列頭。 除非解碼器在低延遲模式下運行,否則刪除時間與計劃的刪除時間一致 Removal [i] = ScheduledRemovalTiming [i]。 為了支持可伸縮性,解碼器模型針對每個工作點(OP)單獨發出信號。工作點與某個可伸縮層的解碼及其解碼所需的較低可伸縮層有關。比特流中較高的工作點可能需要使用符合較高級別的解碼器。

解碼器模型的兩種模式之間的差異

可以注意到,解碼調度模式下的解碼器操作是資源可用性模式下的解碼器操作的超集。編碼器應該有可能用信號通知在資源可用性模式中可能已經導出的相同Removal [i]。解碼時間表模式也可以用于控制幀解碼時間表。圖6示出了當比特流需求低于最大等級能力時的情形。在資源可用性模式下,將幀依次解碼,并且當幀緩沖區中沒有剩余空閑時隙時,解碼速度會變慢。在解碼調度模式下,可以以恒定速度解碼比特流。注意,當解碼器接近其最大能力工作時(例如,比特流接近于等級限制的分辨率和幀率),兩種模式下的解碼器操作是相似的。

另外,可以使用解碼調度模式來更好地控制平滑緩沖區的飽和度(見圖7)。該圖說明了平滑緩沖區充滿度如何隨時間變化,取決于參數coder_buffer_delay和decoder_buffer_delay的值。該圖使用1920×1080的視頻,每秒24幀,編碼為4.0級AV1比特流。選擇符合8幀分層預測結構的幀大小;該示例已構建,并不代表任何特定的視頻編碼。最大的平滑緩沖區容量由水平虛線顯示。

圖7(a)顯示了encoder_buffer_delay = 20 000,decoder_buffer_delay = 70 000時隨時間變化的緩沖區充滿度,它們等于資源可用性模式中使用的默認值。

通過減少coder_buffer_delay,可以更早開始解碼,這在圖7(b)中通過使用encoder_buffer_delay和decoder_buffer_delay均等于45 000進行了演示。請注意,encoder_buffer_delay與decoder_buffer_delay的總和等于90 000,這對應于1秒,即平滑緩沖區可以保持的最大級別比特率下的比特流持續時間。

通過使用參數coder_buffer_delay = 10000,decoder_buffer_delay = 45000,也可以將緩沖區充滿度保持在較低水平,如圖7(c)所示。

顯示時間

AV1的顯示時間通過frame_presentation_time語法元素發出信號。實際的顯示時間還取決于InitialPresentationDelay,其計算方式如下: PresentationTime [0] = InitialPresentationDelay, PresentationTime [j] = PresentationTime [PrevPresent] + frame_presentation_time [j] * DispCT, 其中,如果前一個RAP是關鍵幀RAP,則PrevPresent對應于與最后一個關鍵幀隨機接入點(RAP)關聯的索引;如果前一個RAP是延遲RAP,則PrevPresent對應于延遲恢復點(即對應于前向關鍵幀/open-GOP)。延遲的恢復點對應于open-GOP中的關鍵幀的顯示時間。 InitialPresentationDelay依次確定如下: InitialPresentationDelay =Removal[initial_display_delay_minus_1] + TimeToDecode [initial_display_delay_minus_1]。 換句話說,InitialPresentationDelay是幀緩沖區中存在initial_display_delay_minus_1 + 1個解碼幀的時間。 當equal_picture_interval等于1時,使用恒定幀率模式,并且大于0的幀j的顯示時間推導如下: PresentationTime [j] = PresentationTime [j ? 1] +(num_ticks_per_picture_minus_1 + 1)* DispCT, 其中PresentationTime [j-1]指的是顯示順序中的前一幀。如上導出PresentationTime [0]。

解碼器模型信令

解碼器模型參數主要在序列和幀級別上發出信號。序列標頭可以包括Timing_info()結構,該結構包含顯示時序信息。基本的解碼器模型信息位于decoder_model_info()結構中。除此之外,還可以在序列頭中用信號發送一個或多個操作點(OP),以實現可伸縮的比特流。每個OP對應于解碼該OP所必需的解碼器級別,并且可以可選地被分配一組解碼器模型參數。 Timing_info()結構包含時間刻度和顯示刻度號num_units_in_display_tick中的時間單位數,而coder_model_info()結構包含解碼器刻度號num_units_in_decoding_tick中的單位數以及其他解碼器模型語法元素的長度。這兩個語法元素將DispCT和DecCT變量的持續時間定義為: DispCT = num_units_in_display_tick÷time_scale, DecCT = num_units_in_decoding_tick÷time_scale。 operating_parameters_info()結構包含用于操作點的 encoder_buffer_delay 和decoder_buffer_delay 以及低延遲模式標志。如果使用解碼器模型,則可以在幀頭中為選定的工作點發信號通知以解碼時鐘節拍為單位的buffer_removal_time。幀頭中的temporal_point_info()結構包含frame_presentation_time語法元素,該元素以顯示時鐘節拍表示信號的顯示時間。

AV1等級

在撰寫本文時,AV1規范定義了2.0到6.3級,該級別大致涵蓋了將視頻從426×240 @ 30fps解碼到7680×4320 @ 120fps所需的解碼器功能。解碼器模型將比特流和解碼器一致性統一到了一定水平。AV1級別聲明支持某種幀分辨率(一幀中的樣本數),解碼以及顯示的采樣率。與解碼器模型相關的其他級別參數包括最大比特率和幀頭速率。級別可以屬于兩個級別(主級別和高級級別)之一,其中高級級別具有比主級別更高的最大比特率,并且面向專業和特殊應用。 最大比特率直接定義了平滑緩沖區的大小,該平滑緩沖區應能夠以最大級別的比特率保持最多1秒的壓縮流。由于對一致的比特流不允許緩沖區上溢或下溢,因此這對峰值比特率施加了限制。除此之外,還規定了幀的最小壓縮率。 聲稱符合某個級別的比特流,如果通過解碼器模型,則不應違反約束。順便說一句,相應的解碼器應能夠解碼相同或更低級別的任何順應性比特流,只要該比特流符合AV1規范(包括通過相應級別的解碼器模型測試)即可。 可以在此Wikipedia鏈接上找到AV1級別的表,盡管通常推薦的來源是AV1規范。

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 解碼器
    +關注

    關注

    9

    文章

    1131

    瀏覽量

    40684
  • 視頻解碼器
    +關注

    關注

    0

    文章

    75

    瀏覽量

    19659
  • OBU
    OBU
    +關注

    關注

    0

    文章

    17

    瀏覽量

    12690

原文標題:AV1解碼器模型

文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    配置I2S以從編解碼器設備生成BCLK

    電子發燒友網站提供《配置I2S以從編解碼器設備生成BCLK.pdf》資料免費下載
    發表于 10-21 10:30 ?0次下載
    配置I2S以從<b class='flag-5'>編解碼器</b>設備生成BCLK

    TMS320F2833x與AIC23B立體聲音頻編解碼器的接口

    電子發燒友網站提供《TMS320F2833x與AIC23B立體聲音頻編解碼器的接口.pdf》資料免費下載
    發表于 10-15 09:21 ?0次下載
    TMS320F2833x與AIC23B立體聲音頻<b class='flag-5'>編解碼器</b>的接口

    Linux上的編解碼器移植TMS320DM365預覽版

    電子發燒友網站提供《Linux上的編解碼器移植TMS320DM365預覽版.pdf》資料免費下載
    發表于 10-14 10:53 ?0次下載
    Linux上的<b class='flag-5'>編解碼器</b>移植TMS320DM365預覽版

    TMS320DM365中的智能編解碼器功能

    電子發燒友網站提供《TMS320DM365中的智能編解碼器功能.pdf》資料免費下載
    發表于 10-14 10:24 ?0次下載
    TMS320DM365中的智能<b class='flag-5'>編解碼器</b>功能

    音頻編解碼器和ADC中有哪些常見噪聲問題,如何幫助避免這些問題?

    音頻編解碼器和 ADC 中有哪些常見噪聲問題,如何幫助避免這些問題?
    發表于 10-10 08:09

    音頻編解碼器中的常見噪聲問題

    電子發燒友網站提供《音頻編解碼器中的常見噪聲問題.pdf》資料免費下載
    發表于 10-09 10:19 ?0次下載
    音頻<b class='flag-5'>編解碼器</b>中的常見噪聲問題

    遙控解碼器怎么使用

    夠接收和解碼遙控發出的紅外(IR)信號。這些信號通常用于控制電視、空調、音響等家用電器。解碼器可以復制這些信號,從而允許用戶使用新的遙控或智能手機應用程序來控制設備。 2. 準備工
    的頭像 發表于 09-30 14:23 ?582次閱讀

    帶你探索HiFi智能編解碼器的奇妙世界

    HiFi智能編解碼器就像是音頻世界的魔法師,它讓我們能聽到最真實、最動人的聲音。無論是家庭音響、智能音箱,還是無線耳機和專業設備,這個小小的設備都能帶來巨大的音質提升。讓我們一同期待,未來HiFi智能編解碼器為我們帶來的更多驚喜吧!
    的頭像 發表于 07-18 17:20 ?697次閱讀
    帶你探索HiFi智能<b class='flag-5'>編解碼器</b>的奇妙世界

    TP3094單芯片PCM編解碼器和濾波數據表

    電子發燒友網站提供《TP3094單芯片PCM編解碼器和濾波數據表.pdf》資料免費下載
    發表于 07-10 09:25 ?0次下載
    TP3094單芯片PCM<b class='flag-5'>編解碼器</b>和濾波<b class='flag-5'>器</b>數據表

    音頻編解碼器AC'97電壓轉換收發數據表

    電子發燒友網站提供《音頻編解碼器AC'97電壓轉換收發數據表.pdf》資料免費下載
    發表于 05-28 10:52 ?0次下載
    音頻<b class='flag-5'>編解碼器</b>AC'97電壓轉換收發<b class='flag-5'>器</b>數據表

    國產可編程振蕩在視頻編解碼器中的應用,兼容SiTime

    國產可編程振蕩在視頻編解碼器中的應用,兼容SiTime
    的頭像 發表于 04-17 09:39 ?1887次閱讀
    國產可編程振蕩<b class='flag-5'>器</b>在視頻<b class='flag-5'>編解碼器</b>中的應用,兼容SiTime

    集成電源管理和音頻編解碼器TPS65950數據表

    電子發燒友網站提供《集成電源管理和音頻編解碼器TPS65950數據表.pdf》資料免費下載
    發表于 03-06 11:15 ?0次下載
    集成電源管理和音頻<b class='flag-5'>編解碼器</b>TPS65950數據表

    高性能立體聲編解碼器DA7400 數據表

    電子發燒友網站提供《高性能立體聲編解碼器DA7400 數據表.pdf》資料免費下載
    發表于 02-20 10:11 ?1次下載
    高性能立體聲<b class='flag-5'>編解碼器</b>DA7400 數據表

    視頻編解碼器-晶振應用選型方案簡介

    隨著科技的日新月異,視頻編解碼技術也將迎來新的發展機遇,5G網絡的普及將進一步提升視頻傳輸速度和質量,為視頻編解碼器的發展提供更廣闊的空間。
    的頭像 發表于 12-09 10:55 ?964次閱讀
    視頻<b class='flag-5'>編解碼器</b>-晶振應用選型方案簡介

    使用具備SigmaDSP內核的編解碼器是否必須載入SigmaDSP程序才能使用?

    目前預計使用ADAU1761連接兩個MEMS數字麥克風, ADAU1761與ADAU1361相比, ADAU1761多了SigmaDSP內核. 使用具備SigmaDSP內核的編解碼器是否必須
    發表于 11-30 07:31