2009年4月26日 星期日

optimal JPEG encoder for HD

libjpeg 預設是 compile with /MTd
如果你的程式是 /MDd 那要在 C/C++ --> Code Generation --> Runtime Library 改成 /MTd 才不會出現

warning LNK4098: defaultlib "LIBCMTD" conflicts with use of other libs


附表 ( Visual C++ CRT )
Reusable Library            Switch    Library    Macro(s) Defined
----------------------------------------------------------------
Single Threaded             /ML       LIBC       (none)
Static MultiThread          /MT       LIBCMT     _MT
Dynamic Link (DLL)          /MD       MSVCRT     _MT and _DLL
Debug Single Threaded       /MLd      LIBCD      _DEBUG
Debug Static MultiThread    /MTd      LIBCMTD    _DEBUG and _MT

Debug Dynamic Link (DLL)    /MDd      MSVCRTD    _DEBUG, _MT, and _DLL


如何看一個Library 是用什麼選項編譯的呢?

dumpbin /all xxx.obj or xxx.lib

在 section  RAW DATA #1


LNK1103: debugging information corrupt; recompile module

if compile with vs 2008, and later try to build and link with vs 2005, this error appear
solution: recompile with vs2005 ok


When using instrument profiling on Visual Studio 2005, VSP file may grow up more than 4G
and VSP error 1370 appear. But it seems on VS 2008 produce much smaller VSP file ( around 2G) and ok.




1.
Compile & R

2. Build on VS2008 command line

must set include & lib path

EX: build libjpeg

cjpeg 等 exe 無法build 因為其裏面有呼叫 fclose() 等函數
而fclose 在ce/include 中沒有stdio.h 在sdk\include\mipsii 下有定義
也是一行 #include "stdlib.h"
WINCE 下的 fclose 應該是 link 到 coredll.dll header stdlib.h
所以把 cjpeg link 到 coredll.lib 應該就ok

cjpeg.exe link error
1. 少 fclose() --> link coredll.lib
2. 少 exit() --> corelibc.lib
3. unresolved external symbol __GSHandlerCheck --> compile 選項加 /GS-
4. unresolved external symbol getenv --> jmemmgr.c 使用了getenv, 定義NO_GETENV
5. unresolved external symbol WinMain in WinMainCRTStartup --> default link entry 是 WinMainCRTStartup, link option 加 /ENTRY:mainACRTStartup


jconfig.h 把 USE_SETMODE undef
stdlib.h 沒有 getenv 所以要定義 NO_GETENV


note:
如果程式有include 到 \vc\include\*.h 的話 如 9.0\vc\include\io.h
通常程式需要修改 因為使用了 embedded vc 沒有支援的函式、標頭檔
才會跑到 vc\include\*.h


ex: Build libtiff ( MIPSII)


crtdefs.h(100) : fatal error C1189: #error : ERROR: Use of C runtime library internal header file
in crtdefs.h

#if !defined(_CRTBLD) && !defined(_WIN32_WCE)
/* This version of the header files is NOT for user programs.
* It is intended for use when building the C runtimes ONLY.
* The version intended for public use will not have this message.
*/
#error ERROR: Use of C runtime library internal header file.
#endif /* _CRTBLD && !_WIN32_WCE */

so we should define _WIN32_WCE



VC\INCLUDE\ctype.h(175) : error C2085: 'is_wctype' : not in formal parameter list
there is no ctype.h in vc\ce\include
so by viewing IDE setup
I find it use C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\ctype.h
and in this file, it simply #include "stdlib.h"

so C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII should
be before vc\include

port is ok


later build libtiff dir

error c2375: 'qsort' : redefinition; different linkage
in Search.h & stdlib.h
in stdlib.h there is no _CRTIMP in front of qsort, others are the same
Look into search.h


/* Define _CRTIMP */

#ifndef _CRTIMP
#ifdef _DLL
#define _CRTIMP __declspec(dllimport)
#else /* ndef _DLL */
#define _CRTIMP
#endif /* _DLL */
#endif /* _CRTIMP */

so shouldn't define _DLL? yes!
so use /MT instead of /MD in nmake.opt

next,
C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\winnt.h(2975) : error C2061: syntax error : identifier 'PCONTEXT'

should define _MIPS_ in nmake.opt

後來 build 到 tif_stream.cxx 又出現
>C:\Program Files\Microsoft Visual Studio 9.0\VC\ce\include
\xiosbase(209) : error C2470: 'ios_base' : looks like a function
definition, but there is no parameter list; skipping apparent body

問題 Google 了一下總算找到
vc\ce\include 必需在 STANDARDSDK_500\include 之前

就成功 compile 了 剩最後link error
LINK : fatal error LNK1195: target machine 'MIPS' requires '/SUBSYSTEM:WINDOWSCE'

/subsystem:windowsce 好像是只在link dll 時會有問題
在link static library 時沒加也沒問題

及一些 warning in tif_unix.c
主要是
C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\specstrings.h(48) : warning C4005: '__in' : macro redefinition
C:\Program Files\Microsoft Visual Studio 8\VC\ce\include\sal.h(520) : see previous definition of '__in'
C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\specstrings.h

sal.h 及 specstrings.h 兩個檔案有一堆重複的macro

經檢查 sal.h 發現當 _WIN32_WCE == 0x500 時
這些macro的定義和 specstrings.h 一樣 為null
所以定義 _WIN32_WCE 還不夠 要定義 _WIN32_WCE=0x500





1. 改nmake.opt,
OPTFLAGS = /Ox /MT /EHsc /W3 /D_WIN32_WCE=0x500 /D_MIPS_ /DDEPRECATE_SUPPORTED

comment #USE_WIN_CRT_LIB = 1

2.  改 libtiff/tif_config.h
HAVE_FCNTL_H  HAVE_SYS_TYPES_H   HAVE_IO_H 拿掉

3. 因為很多檔案使用 fcntl.h 中的定義如 O_RDONLY O_WRONLY
我們又沒有fcntl.h (WINCE下) 所以把vc\include\fcntl.h定義 copy 到 tiffiop.h中

#ifdef HAVE_FCNTL_H
# include 
#else
...
...
#endif

4. 剩下 tif_win32.c  GlobalAlloc GMEM_FIXED 的修改 ( WinCE 不支援 Global Heap)
--> use LocalAlloc LocalFree LMEM_FIXED ...

sprintf_instead_use_StringCbPrintfA ... 問題  --> define DEPRECATE_SUPPORTED
http://www.ddj.com/mobile/184405528


5. 編譯成功完後下來就是編譯 dll
又出現一堆link錯誤 在nmake.opt 裏加入
LIBS = corelibc.lib
就會剩下四個 unresolved symbol
bsearch
_lfind
__imp_CreateFileMappingA
__imp_CreateFileA

__imp_CreateFileMappingA --> 加入 UNICODE 定義後就消失了
__imp_CreateFileA --> 必需修改 tif_win32.c 因為它直接在source code中用 CreateFileA


至於 bsearch lfind
在standard sdk 中是有 search.h
但是似乎只支援 WIN32
#if !defined(_WIN32)
#error ERROR: Only Win32 target supported!
#endif

在smart device IDE 下 #include ok 但是也不能link
what the hell 為什麼 libtiff.lib ok?

lib libtiff.lib --> lib 的動作只是集合所有的 obj 檔 所以沒去link unresolved symbols
link libtiff.dll --> 有link的動作
所以 沒有 bsearch 及 lfind 必須修改 tif_dirinfo.c

原來Generate DLL 是做 Link 的動作!! (建立起 import library 和 DLL 之間的關聯?)
DLL 是 PE 格式 所以也是一種EXE

2009年4月16日 星期四

Use __declspec(dllimport) to reduce thunk overhead


warning LNK4217: locally defined symbol __rt_sdiv imported in function main 
https://blogs.msdn.com/russellk/default.aspx



//__declspec(dllimport) reduce thunk overhead
http://msdn.microsoft.com/zh-tw/library/zw3za17w.aspx

使用 __declspec(dllimport) 匯入函式呼叫

更新:2007 年 11 月

下列程式碼範例將顯示如何使用 _declspec(dllimport),以便從 DLL 匯入函式呼叫到應用程式。假設 func1 是位於 DLL 中的函式,此 DLL 和包含 main 函式的 .exe 檔位於不同位置。

請在不使用 __declspec(dllimport) 情況下給定下列程式碼:


int main(void)
{
func1();
}

編譯器所產生的程式碼看起來會像下面這樣:


call func1

而連結器會將呼叫轉譯成像下面這樣的程式碼:


call 0x4000000         ; The address of 'func1'.

如果 func1 存在於另一個 DLL,則連結器會因為無法得知 func1 的位址而無法直接解析。在 16 位元環境裡,連結器會將這個程式碼位址加入至 .exe 中的清單,載入器會在執行階段以正確位址更正清單中的位址。在 32 位元和 64 位元環境裡,連結器會產生它確實知道位址的 Thunk。在 32 位元環境中,Thunk 看起來類似:


0x40000000:    jmp DWORD PTR __imp_func1

此處 imp_func1 是 .exe 檔匯入位址表中 func1 位置的位址。因此連結器會知道所有的位址。載入器只需在載入時間 (Load Time) 更新 .exe 檔的匯入位址表,便可使所有步驟正確運作。

因此,使用 __declspec(dllimport) 是比較好的做法,因為連結器在不需要使用時就不會產生 Thunk。Thunk 會讓程式碼變大 (在 RISC 系統中,它可能是許多指令) 並可能降低您的快取 (Cache) 效能。如果您告訴編譯器此函式位在 DLL 裡,它便可以為您產生間接的呼叫。

因此現在這段程式碼:


__declspec(dllimport) void func1(void);
int main(void)
{
func1();
}

會產生下面這個指令:


call DWORD PTR __imp_func1

因為沒有 Thunk 和 jmp 指令,所以程式碼會較小並執行更快。

另一方面,對於 DLL 內的函式呼叫,您並不需要使用間接呼叫。您已經知道函式的位址。因為在間接呼叫之前,載入和儲存函式的位址會需要時間和空間,所以直接呼叫一定會較快和較小。您只需要在要從 DLL 本身外部呼叫 DLL 函式時使用 __declspec(dllimport)。在建置 DLL 時,不要在 DLL 內部的函式上使用 __declspec(dllimport)


2009年4月13日 星期一

NK.BIN boot process

NK.BIN 開機流程

During the kernel boot process, the following calls are made in the order shown:

StartUp() db1200\kernel\hal\startup.s

KernelStart() / KernelInitialize() PRIVATE\WINCEOS\COREOS\NK\KERNEL\MIPS\startup.s

OEMInitDebugSerial()

OEMInit()

KernelInit()

HeapInit()

InitMemoryPool()

ProcInit()

SchedInit()

FirstSchedule()

SystemStartupFunc()

IOCTL_HAL_POSTINIT


Build Au1200 WINCE Image

1. 裝RMI Au1200 BSP 1.51


1. 修改 kernel\hal\init.c 中
oeminit() 把 bclk 關掉 不然 High speed USB 會有問題

2. Hang after -OEMInit

Memory Map 可能需要調整
in C:\WINCE500\PLATFORM\Db1200\Files\config.bib

NK 86100000 01F00000 RAMIMAGE
RAM 81B00000 04600000 RAM

2009年4月12日 星期日

2009年4月9日 星期四

PSP 的音樂探險

PSP 的音樂公用程式為 SonicStage 目前版本為 4.3 可至Sony官方網站下載。
PSP 可播放 MP3 、WMA(要透過網路啟動此功能)、AAC(m4a mp4, 在2.7 版開始支援)、還有Sony 的獨家 ATRAC3。

要用ATRAC3的話 光是只把轉換過後的丟到PSP資料夾裏是不行的
(後來發現簡單的方法 把附檔名.OMA 改成 .AA3丟掉 Music資料夾就行了)
要讓SonicStage 來輕鬆地幫我們做這件事... (同時也把保護的機制加了進去)
傳輸方法有兩種
1. 標準模式
也就是用ATRAC3 plus 的格式 最高可達352Kbps 但是會加入保護機制(OpenMG)。
而OpenMG 好像要跟有 MagicGate 功能的 Memory Stick 卡在一起運作。
2. ATRAC3 模式
相容於舊的Sony ATRAC3 Player 的模式 使用 ATRAC3 但最高只有132Kbps。

ATRAC3檔案的原始副檔名為「aa3」,若經過OpenMG進行版權保護加密後,則會變成「omg」或「oma」。

SonicStage 也支援無損壓縮 ATRAC Advanced Lossless (但PSP不支援播放)
(硬體方面,SONY至2006年10月發表之NW-S700F、NW-S600才完全支援AAL。 ) -- from wikipedia

Visual Studio 2008 PDB

發現一件奇怪的事
在Visual Studio 2008 中
Create 一個 Smart Device 的Project
其產生的 PDB 檔為 vc80.pdb (?)

然而 把另一個Project 從 VS2005 轉成 VS2008
其產生的 PDB 檔為 vc90.pdb

在VS2008下 Windows 的Project
是正常的 vc90.pdb

是Linker path 不對嗎(呼叫到 VS2005的Linker?因為我 VS2005 VS2008 2種都有裝)
有做過實驗 其呼叫的Linker是 9.0版本的
有人知道答案嗎?

2009年4月8日 星期三

Hex Workshop

Hex Workshop 6.01 不能Right Click Load 桌面上的檔案
應該是不支援中文 "桌面" 這2個字 Cause Problem

在 Visual Studio 中 編譯 .s (Assembly)檔

要使用 mipsasm 而非 ml

mipsasm.exe 在 \VC\ce\bin\x86_mips 下


The MIPS edition of Visual C++ includes a stand-alone assembler.
The assembler does not have all of the restrictions that inline assembly does; in particular, using the stand-alone assembler is the only way to create functions written only in assembly code.
However, in some respects the stand-alone assembler is less convenient, because you cannot refer as easily to objects in C and C++ source code.
MIPS stand-alone assembler driver is Mipsasm.exe. Mipsasm recognizes assembly language source files that end with .asm or .s file extensions.
The following code example shows how to assemble and link prog.asm into an executable in one step from the command line.
mipsasm -DMIPS -QMmips2 prog.asm /link /entry:mainACRTStartup
/subsystem:windowsce /nodefaultlib corelibc.lib coredll.lib
The next code example shows how to assemble an assembly language source file into an object file without linking, using the "-c" assembler switch.
mipsasm -DMIPS -QMmips2 -c prog.asm
To see more assembler options, type the following at the command line:
mipsasm /?

奇怪的是
#include ok (有default include directory?)
#include failed


PS3, HDMI, Dolby Digital TrueHD 完全解答

在買了PSP之後 開始又在研究下一代HD 音效的部份
(或多或少跟工作也有關係)
又看了一些 ASUS HDAV13 音效卡的討論
最近剛始想買 PS3
所以對 PS3 能不能解 Dolby TrueHD
及正確的觀念及輸出接法 有了深切的研究

要了解這個問題
必需先對下一代影音的規格 有正確的認識
  1. HDMI、HDMI1.3
  2. Blu-ray disc spec
  3. Dolby Digital, Dolby TrueHD, DTS HD Master
  4. S/PDIF

直接來看問題 比較快
1. PS3 能不能播放 Dolby Digital TrueHD? 能不能點燈?

這個問題 相信在各大討論區都有討論過了 而且大家也都知道正確的答案
那就是 PS3 在播放 Dolby TureHD 時 是用內部解碼成 LPCM 格式從HDMI port輸出
所以是可以"正確"地播放 沒有問題。
但是其輸出並不是TrueHD encoded Bitstream 所以在支援TrueHD 的Amplifier 上是無法點燈的

2. LPCM 比TrueHD bitstream 差, 點燈爽度較高?
實際上來說 沒有差別 很大的部份是心理作用
HDMI LPCM 傳輸也是 Digital 格式和TrueHD Bitstream 一樣 所以線材影響不大(同一線材 2種格式沒有影響)。那麼 差別到底在哪呢? 差別在於 LPCM 格式是 Uncompressed 而 TrueHD(or DTS-MA)是 loseless compressed,差別就在於 TrueHD(DTS-MA)Bitstream 較省HDMI傳輸頻寬,因為是到從HDMI傳輸到 Amplifier之後再行解碼,而PS3 LPCM方式 是由PS3解碼後再傳輸到Amplifier。
假設 支援TrueHD 的Amplifier 和PS3 都正確地解碼,其解出來的資料,"應該"完全一致。

3. HDMI 及Blu-ray 的限制
然而,我相信HDMI及Blu-ray disc spec 的限制 會造成在某種情況下 LPCM較差。
先看 HDMI spec (from wikipedia)

HDMI version 1.0–1.2a 1.3+
Maximum signal bandwidth (MHz) 165 340
Maximum TMDS bandwidth (Gbit/s) 4.95 10.2
Maximum video bandwidth (Gbit/s) 3.96 8.16
Maximum audio bandwidth (Mbit/s) 36.86 36.86
Maximum Color Depth (bit/px) 24 48[A]
Maximum resolution over single link at 24-bit/px[B] 1920×1200p60 2560×1600p75
Maximum resolution over single link at 30-bit/px[C] N/A 2560×1600p60
Maximum resolution over single link at 36-bit/px[D] N/A 1920x1200p75
Maximum resolution over single link at 48-bit/px[E] N/A 1920×1200p60
HDMI version 1.0 1.1 1.2
1.2a
1.3 1.3a
1.3b
1.3b1
1.3c
sRGB YesY YesY YesY YesY YesY
YCbCr YesY YesY YesY YesY YesY
8 channel LPCM/192 kHz/24-bit audio capability YesY YesY YesY YesY YesY
Blu-ray Disc video and audio at full resolution[F] YesY YesY YesY YesY YesY
Consumer Electronic Control (CEC)[G] YesY YesY YesY YesY YesY
DVD-Audio support NoN YesY YesY YesY YesY
Super Audio CD (DSD) support[H] NoN NoN YesY YesY YesY
Deep Color NoN NoN NoN YesY YesY
xvYCC NoN NoN NoN YesY YesY
Auto lip-sync NoN NoN NoN YesY YesY
Dolby TrueHD bitstream capable NoN NoN NoN YesY YesY
DTS-HD Master Audio bitstream capable NoN NoN NoN YesY YesY
Updated list of CEC commands[I] NoN NoN NoN NoN Yes

我們看到 不論是HDMI 1.0或 HDMI 1.3, 其Audio 傳輸的能力都是一樣的
也就是最大 36.86 Mbit/s,8 Channel 24bit 192KHz LPCM

然後看一下TrueHD spec
有說到這一段

In the Blu-ray specification, Dolby TrueHD is an optional codec. Dolby TrueHD audiotracks may carry up to 24 bit audio in up to 8 discrete audio channels at 96 kHz or up to 6 channels at 192 kHz. The maximum encoded bitrate is 18 Mbit/s (the same as the uncompressed rate).

在Blu-ray的規格裡 Dolby TrueHD 音軌 只能儲存 8Channel 24bit 96KHz
或者 24bit 192KHz 6 Channel。其最大的 encoded bitrate 為 18Mbit/s。
有趣的是未壓縮的最大bitrate 也是 18Mbit/s。

(DTS-HD MA )
(DTS-HD MA supports variable bit rates up to 24.5 Mbit/s on a Blu-ray Disc and up to 18.0 Mbit/s for HD DVD)

DTS-HD MA 在Blu-ray 上最大碼率是 24.5Mbit/s。


這代表什麼呢? 也就是 Blu-ray 對LPCM儲存的限制
由HDMI的規格來看 其最大傳輸率為36.86 Mbit/s
在沒有超過最大上限的流量之內 傳LPCM和 TrueHD bitstream 是一樣
但是Blu-ray 的音軌最大是18Mbit/s,所以會造成一種現象
在高碼率高Channel的原始資料下 用LPCM方式儲存的資料量太大
所以通常Blu-ray disc 會用 Dolby Digital (AC3, lossy compression) 或用 Dolby TrueHD
的編碼方式儲存在音軌上。

現在,問題來了,假如高音質Dolby TrueHD 7.1聲道的影片 存滿整個音軌 也就是18Mbit/s 的資料量,但是在傳輸之前經過PS3的解碼 其解碼後的Bitrate (以壓縮率 2:1來說 解完後可達36Mbit/s)
很有可能超過 HDMI能傳輸的最大值。
此時 PS3 會怎麼做呢? 當然就是Downgrade (Re-mix)其內容。
可參考
http://www.avsforum.com/avs-vb/showthread.php?t=1017825
Downgrade 最簡單的方法 就是裁掉一些較不重要的Channel (7.1或 6.1 變成 5.1)
這才會是 LPCM 和 TrueHD, DTS-HD MA bitstream 最大的差別

(PS3 在 firmware 2.3 update 之後 開始支援 DTS-HD MA解碼)

在另一篇討論
http://www.avforums.com/forums/blu-ray-dvd-players/660426-silicon-image-confirms-ps3-will-not-support-bitstream-truehd-dts-hd-ma.html

中 可以看出 其HDMI Transmitter Silicon 9132 的限制(如果現在版本PS3 還是使用這Chip 的話)
由於此限制 要靠firmware update 來讓PS3輸出 bitstream 是不可能的
這也是非戰之罪 在當時的環境 要完整支援HDMI 1.3 的Chip 應該是沒有
所以除非 PS3有改硬體版本 + firmware update 支援
不然是不太可能的

4. 結論
在沒有超過 PS3 LPCM解碼能力或HDMI傳送能力之外的 HD Audio Content。
以LPCM over HDMI或 Bitstream over HDMI方式輸出都是一樣的。就好像在比
APE和WAV 哪個音質比較好?這是沒有意義的。
HDMI 1.3 新增的Dolby TrueHD 及DTS-HD MA Bitstream 只是一種改進,新增一些經無損壓縮的方式,來傳送資料。也因此擴大了
傳輸的效率,達到更高更美好的境界。而這也是在專業的PowerDVD 網站上,
對 Dolby TrueHD 所做的介紹

Dolby TrueHD:專門支援HD DVD播放器及部分藍光光碟。Dolby TrueHD 屬於100%無損耗音效技術,能提供和未壓縮PCM格式完全相同的播放音質,且位元率只有PCM格式的一半到三分之一。更低的位元率使內容能為您帶來更優異的聽覺體驗,且不必犧牲品質。