none
想請大家看一個播放影片的現象 RRS feed

  • 一般討論

  • flicking video

    這個平台是小弟正在開發的,目前播放影片會有此現象發生,想請問大家可能是什麼問題呢?

    平台資訊
    CPU: ARM 1136 Freescale iMX31
    RAM: DDR 128MB
    Flash: 64MB NOR type flash
    OS: WinCE 5.0 core
    面板解析度:800X480 (WVGA)

    播放的檔案(4比3解析度)在預覽模式下(小圖)是正常的,聲音也正常,但全螢幕之後就會發生flicking的現象,希望有經驗的大大能提供一點資訊,謝謝!
    2009年2月24日 上午 06:55

所有回覆

  • Display Controller 是用 CPU Built-in 的 Fram buffer Controller 嗎?
    假如是的話, 有可能是因為 Frame Buffer 的 BUS 頻寬不足.
    雖然就 DDR RAM 的 Bandwidth 看起來很夠, 但假如考慮到和其它 device shared, 還有會被慢速的 device 拖慢等因素, 這還是一個問題.
    可以朝幾個方向來分析.
    1) OS Image 是在 NOR 上 XIP or 是整個 copy to RAM 在跑? 因為 RAM 的 performance 遠比 NOR Flash 要來的快, 可以試看看假如 Image 在 RAM 跑時有沒有改善
    2) 現在的 CPU 大多有 DVFM, 在改變頻率時, 也有可能會改變 BUS speed, 假如 control Freq. policy 的 driver 沒有設計好, 很有可能一直切換, 而導至這樣的問題. 可以先把 CPU Freq 固定 (通常先試最高速) 有沒有改善
    3) Pixel Format 是用 16,24 or 32 bpp? 越高頻寬消耗也越大, 不過因為 32 bits 的 system, 通常 32 bpp 的整體 performance 會比 24bpp 來的更好. (假如一定要用到 True Color 的話)
    4) LCD 的 Refresh Rate setting. 通常 LCD 都是 60Hz, 不過也都有一定的容許範圍, 把 refresh rate 降低通常也都可以簡少 Bandwidth loading
    5) Fram Buffer Controller DMA Priority - 由於 Frame Buffer 裡的東西也都是由 DMA controller 把 data 從 RAM 搬到 LCD 去, 有時這個 DMA 的 Priority 不夠高的話, 可能就會讓 Frame Buffer FIFO stall, 以至於就沒有資料送出來
    6) 此外也最好 probe 一下 Pixel Clock, Fame Sync, H sync 等 signal 確認是不是有不正常的偏移
    7) 考慮使用有 Smart Panel (有 Built-In RAM 的 LCD Panel) 不過也要看 iMX31 有沒有辦法接就是了. 這類 Panel 因為有 Built-in frame buffer, 所以不需要一直靠 CPU 來 pump data 到 panel, 也就是說在只有在 update 畫面時, 才需要消耗 Bandwidth
    8) 另一種類似的做法就是外加一顆獨立的 Graphic Controller, 這類 chip 通常也都會有 H/W codec function. (不過也要有適當的 Driver and DirectShow Filter support)
    2009年2月24日 上午 07:49
  • 感謝ellen大大的回答,相當開心:)
    1) XIP的確比download IMAGE的狀況來的糟,可是播放程式是放在SD CARD執行,依小弟的經驗,播放程式不都是load到DRAM裡面執行嗎?怎麼還會有如此差異呢?
    2) 因為是車機,我們沒有開啟DVFM,頻率也採用最高。
    3) 4) 6)則是我們還必須努力的方向,感謝您的提點!
    5) 這個方式我們有試過,在download IMAGE有明顯改善,但XIP的情況卻沒有辦法:( 很怕是硬體的限制。

    感謝您的費心解答!
    2009年2月24日 上午 09:01
  • 通常 XIP 是為了 節省 RAM 同時降低耗電量, 假如是車機, 那 RAM 應該不是問題, 可以在一開始就把整個 OS Image 都 load 到 RAM, performance 也會比較好.
    而 program 即始是在 SD Card 裡, 可是所有的 OS Kernel, drivers, 甚至 codec (假如是用 OS Built-in DS filter), 那都在 NOR Flash 裡, 而就看 playback program 本身好了, 雖然會 load to RAM, 但因為有 demand paging, 不是全部都 load 到 RAM, 而是有需要的部份才 load, 這也都會造成 real-time performance 的瓶頸. 假如真的要這樣做, 可以試看看把 Demand Paging 關掉 (可以改 Storage Manager/FATFS 的 "Paging"=dword:0 或是 BIB file 的 ROMFLAGS)
    而 假如真的一定要在 NOR XIP, 可以看看是否 CPU and Flash 可以跑 Sync. mode, 以增加 performance.
    或是至少把核心 modules load to RAM (不過這就要改成 MultiXIP)


    2009年2月25日 上午 07:21
  • 感謝回答,小弟對這個"將一開始就把整個image load到RAM"的方法相當有興趣,這兩天也一直在找和試。如果大大知道如何做,是否能題醒小弟如何做呢?
    2009年2月25日 上午 08:21
  • 首先 Image 的 address 是要 FIXUP to RAM (=> for download 的 configuration),然後,那, boot loader 要能夠把這種 Image 也 program 到 NOR Flash, 之後 boot-loader 開起來時, 要能夠把 Image 從 NOR Flash 讀到 RAM.

    *不過這樣一來, 用 NAND Flash 還比較便宜,而當做 File system Storage 時, Write Performance 也遠比 NOR 要好很多 :)
    2009年2月25日 上午 09:15
  • 看來是單純修改EBOOT了,讓小弟來試試看吧!感謝!
    2009年2月25日 上午 09:47
  • Hi ellen:
    請問有沒有方法是XIP之後(進入OS後)才將部分載到RAM中去執行的?因為我估計在EBOOT時期將OS載到RAM中可能得多花十幾秒,不輸給NAND開機了。
    ============================================================================================
    抱歉沒看清楚您之前的回覆。
    首先Flash的確是跑Sync mode了,而且已經調校到最高performance了。
    所以您說把Demand paging關掉是嗎?這部份小弟也會試試。

    最後您說的改成MultiXIP,小弟有參考Wince help,但似乎是很難...可以指點一二嗎?



    2009年2月26日 上午 05:22
  • 要改善 Loading Speed, 只 Load 一小部份 Image 是一種方法, 不過在討論這種做法前, 也應該要思考是不是可以改善 Eboot 的 performance. 假如 Flash 是跑 Sync. mode, 每秒達到數十 MB 也不是問題, 更不用說 RAM 的部份.
    所以 performance 不夠好, 是不是因為 data access (無論 from NOR Flash or to DRAM) 是 uncached, 所以沒辦法做 Burst Transffer. 此外 EBoot 本身的 code, data 是不是也在 Cachable Memory 中? 這對 performance 也會有一定影響. 而因為 Launch OS 時 MMU一定是回到 Disable, 所以也在這前記得把 cache flush.

    另外再談到 將部份 Load 到 RAM 的做法, 簡單說 只要是放在 FILES section 的東西就沒辦法 XIP, 而這時只要再把 ROMFLAGS Disabled Deamand Page 給打開, 那就會強迫整個 load to RAM. 但也不是什麼都可以放到 FILES section, 至少像是 kernel, 還有一些 core components 就不可能, 但這些 module 又很有可能會很常被 run 到, 就變成必要之惡.....

    所以取而代之的就是做 MultiXIP or MultiBIN. 簡單說 MultiXIP 就是在 BIB 中 declare 一個以上的 RAMIMAGE sections, 而 MultiBIN 則是一個 RAMIMAGE and 多個 NANDIMAGE sections.
    只要是 RAMIMAGE 的部份, 在該 Address 一定要有可以 XIP 的 memory (不論是 NOR Flash or DRAM), 也就是說假如某一個 RAMIMAGE section 是 declare 在 RAM, 那 boot loader 就要負則把這個 section 給 load 到 RAM. 此外 MultiXIP 的 case, OAL 在一開始時也要負則把所有的 Section 的 ROM Header 給 Chained 起來, Kernel 才會知到有其它 XIP section 的存在. 詳細請參考 http://msdn.microsoft.com/en-us/library/aa450783.aspx

    MultiBIN 則是另一種做法, 早其 WM 的 device 幾乎都是用 NOR Flash 當 OS Image storage, 所以理所當然 MultiXIP 也就因應產生 (不過 MultiXIP/MultBIN 某種程度上也是為了 Partial Image Update, 然而都不是很成功的 solution, 所以現在 WM5 開始才又有 IMGFS 但 CE 上就沒有) 後來 non-XIP memory 開始流行, NAND or MDOC 但 DRAM 又希望不要整個 Load to RAM 而是做 Deman Paging 的前提下, MultiBIN or 所謂的 BINFS (MultiBIN 的 FS driver) 就因應產生. 通常在 MultiBIN 上, 只有一個小的 RAMIMAGE section 包含必要的 kernel component and driver (mini Kernel), 這部份通常 bootloader 會 load to RAM (假如是用 NOR Flash 是可以直接把 address fixup 到 NOR 上, 但假如 performance 至上, 還是 load to RAM), 而其它的部份是由 BinFS 在 run-time 時才 page-in 進來. BinFS 本身只是一個 FS Driver, 也就依為著需要一個 NOR Flash 的 Block Device Driver (通常是 NOR FMD driver).
    由 BinFS Page-in 東西, OS 會 allocate 一個 Paging Pool, 也就代表 Page-Pool 滿時會有東西被 Page-Out, 所以 RAM 夠最好 Page-Pool 就設大一點, 並且把 Deman Paging Disable.
    關於 MultiBIN/BINFS 可以參考 http://msdn.microsoft.com/en-us/library/aa915545.aspx
    2009年2月26日 下午 06:54
  • 非常感謝ellen大大:)

    目前小弟朝兩個方向邁進, 一方面檢視video driver的問題(目前發現演算法可能不適合16:9的screen),另一方面就是朝OS這方面著手。

    有什麼消息小弟會第一手分享,感謝!

    2009年2月27日 上午 03:44