Win32 API
Ultimate++ 搞不定。因為我需要 multi-threading 才能比較方便地加上 GUI，但是 Ultimate++ 的設計主要是跑 single thread。現在我打算回到 Win32 API，上次寫已經是高三的事情了，那時用 iterated function system 畫了Sierpiński gasket & carpet XD。
--
可惜竟然沒把 code 留下來 XD。
再經過一番折騰，總算是把圖片順暢地連續顯示出來了。因為我很懶惰，所以我直接畫在螢幕正中央，播完之後影像會殘留在螢幕上 XD。一開始我用 SetPixel 一點一點地直接畫上去，慢得慘不忍睹；然後我改成先建立一個 memory device context 然後對它做 SetPixel，一張圖解碼完才用 BitBlt 刷到螢幕去，果然快了很多，但還是和實際解碼的速度有差距；最後我終於找到 CreateDIBSection，可以直接把 pixels 寫進對應的記憶體位置而不用透過 SetPixel，顯示速度就和解碼速度差不多了。
我決定不做 timing control 了，因為我懶得去找怎麼控制 XD。開最佳化之後，只含 I-frames 的影片播放出來比 real-time 還要快個 1 到 1.5 倍，速度可以接受。這樣「資訊理論與編碼技巧」實質就算結束啦。期末進度目前慢了快要一天，要加把勁！
--
所以如果播放含有 I, P, B frames 的影片，就會飛也似地結束 XD。
我還是來做一下好了，不然實在快得讓人措手不及 XD。
--
明明就有個 picture_rate 嘛 XD
Labels: NTUCSIE
請問可以跟你伸第一個SLICE的第一個macroblock的第一個block的quantizer後的第一個y嘛
Hi,
不太確定你指的是哪個階段的資料，所以我就把可能有用的都貼上來嘍。
我的程式讀 I_ONLY.M1V，第一個 block 的 dct_recon（定義在標準書的 Section 2.4.4.1）是
-824 0 0 0 0 0 0 0
-27 0 0 0 0 0 0 0
-15 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
經過 IDCT 之後是
18 18 18 18 18 18 18 18
20 20 20 20 20 20 20 20
23 23 23 23 23 23 23 23
27 27 27 27 27 27 27 27
28 28 28 28 28 28 28 28
29 29 29 29 29 29 29 29
28 28 28 28 28 28 28 28
27 27 27 27 27 27 27 27
希望以上包含你想要的資訊 :P。
喔對了，Y, Cb, Cr 的 DC predictor 預設值我設定成 0，出來的顏色才是正常的。如果用標準書裡面寫的 1024，出來會一片洋紅色。
謝謝我大概知道我錯的地方了
想再請問一下，IDCT轉換後的值有可能是負的嗎？
因為我長成下面這樣
-109 -109 -109 -109 -109 -109 -109 -109
-107 -107 -107 -107 -107 -107 -107 -107
-104 -104 -104 -104 -104 -104 -104 -104
-101 -101 -101 -101 -101 -101 -101 -101
-99 -99 -99 -99 -99 -99 -99 -99
-99 -99 -99 -99 -99 -99 -99 -99
-100 -100 -100 -100 -100 -100 -100 -100
-100 -100 -100 -100 -100 -100 -100 -100
根據 Wikipedia 的說法，做 DCT 之前必須先把 [0, 255] 平移到 [-128, 127]，所以 IDCT 轉回來之後，必須把每個值都加上 128，平移回原本的值域。你的 block 看起來就只差這一步 :)。
我用的 IDCT 是 third-party code，它應該是直接把平移整合進去了，所以我先前的描述可能有點誤導。
可以跟你伸一下idct嘛
我用的是 Small JPEG Decoder Library 裡面附的 code，在 jpgdlib/ 目錄下有兩份 IDCT 實作。
<< 回到主頁