2010年3月13日

自製電路板用曝光機(使用掃瞄器改裝)-實作

在上篇對曝光機的事前規劃、成本計算後,這篇將實做的曝光機照片和過程貼出來。


  1. 二手掃瞄器(已拆解)
  2. 如果還留有掃瞄器的,可以直接使用,家裡曾經有一台,但幾年前就丟了,這台則是上網拍買的,基於回收價格多半都NT 100元,因此網拍大概都是NT 100元比較多也比較合理。 至於哪種好?反正都是要拆的,差別不大,我當時的需求是高度要10cm上下,當時是考慮到可能用日光燈管和燈座,但使用LED的話,高度問題比較小,如果有疑慮,可以找差不多8cm~10cm高的掃瞄器。 下面是掃瞄器的照片:
    曝光機外觀
    曝光機拆解1
    曝光機拆解2
  3. UV LED洞洞板
  4. 前篇成本篇計算過,要作曝光機,UV LED的C/P值高,而在真正製作時,我們需要洞洞板。 常見的洞洞板有兩種,綠色的是玻璃纖維板;咖啡色的是電木板。一般來說,玻璃纖維板比電木板耐用很多,不過價格也貴很多。基於高職時候做的8051板子到現在都還能動,電木板材質的板子也都一切正常,加上最重要的價格因素,因此我還是買了電木板。 施工過程並沒有拍照,因此只有完成品,但差別僅在於電烙鐵的銲接。 UV LED電路板照片:
    UV LED電路板正面
    UV LED電路板背面
  5. 掃描器+UV LED電路板
  6. 在UV LED電路板完成後,接著就是把它和掃描器結合,這邊比較麻煩的是電源接頭的固定,我最後是在掃描器背後打兩個洞,用螺絲倒鎖卡住電源接頭,效果相當不錯。雖然解釋的不清楚,但大家可以點選下面第一張照片放大來看,注意到電源部份,就可以清楚看到固定用的螺絲了。
    掃描器、UV LED電路板結合照1
    掃描器、UV LED電路板結合照2
    曝光機完成照
  7. 實際測試
  8. 曝光機至此已完成,接著實際插電測試看看。
    曝光機測試照

2010年3月3日

自製電路板用曝光機(使用掃描器改裝)-前傳(成本計算)

最近打算開始自己洗電路板,因此著手購置相關器具。
在網路上搜尋後得知,要洗出成功好看的電路板,曝光的程序是很重要的。
常見的曝光包括:
1. 曬太陽,這方法穩定性不好,時間不好掌控。
2. 檯燈+玻璃(或壓克力板),這方法滿常見的,但檯燈會有死角,而且我手邊沒有大玻璃或大壓克力板,買起來都不便宜
3. 專用曝光機,這個效果當然一級棒,但機器很貴,家裡不可能有
4. 投影機曝光,這個很新奇,看起來效果也不錯,可是我家也沒有投影機

基於上述理由,加上網路搜尋後,發現自行DIY曝光機的人很多,我稍微列出一些相關的網頁:
中文:
http://www.haifeng.idv.tw/leo/cgi-bin/topic.cgi?forum=241&topic=3&show=0
http://61.70.96.216/phpbb2/viewtopic.php?f=3&t=118&start=0

英文:
http://www.scienceprog.com/pcb-exposure-using-uv-light-led-box/
http://hackedgadgets.com/2009/04/21/diy-uv-led-double-sided-pcb-exposure-box/
http://www.embedds.com/ultraviolet-light-box-for-pcb-exposure/
http://www.webtreatz.com/index.php/projects/39-electronic-projects/60-uv-led-based-pcb-exposure-unit

中文的大概是上述兩個最經典,是使用掃瞄器+日光燈管或UV燈管製成的。
英文的則不少,很多是隨便找個工具箱就做了,另外,注意到很多都是用UV LED來製作。

接著,開始計算成本。
1. 二手掃瞄器,網拍很多,NT $100

使用燈管製作時,需要2組日光燈,包括2組燈座、2組電子安定器、2根燈管。
粗略估計
2a. 電子安定器約 NT $100 x 2
2b. 燈座(沒查,估計一組低於 NT $100) x 2
2c. 燈管,如果是日光燈管,一根約 NT $30 x 2;如果是UV燈管,一根約 NT $200~NT $350 不等 x 2

如果用日光燈管製作,估計成本大概要 NT $500 左右,應該可以低於NT $500。
但日光燈曝光時間大概需要10分鐘左右。

而如果用UV燈管製作,則成本大概要到NT $800 ~ NT $1000,要看UV燈管的價格而定。
使用UV燈管曝光時間大概只需要1分鐘~2分鐘的時間。

而使用UV LED製作,需要n顆UV LED、多張洞洞板、多顆電阻、一個變壓器、一個電源母座、一堆銅柱。
2a. UV LED我在露天拍賣有找到一顆NT $3,根據我在國外網站的搜尋,大概需要56~90不等的數量,這要根據LED矩陣的鋪設來決定,目前我使用88顆
2b. 洞洞板,因為洞洞板尺寸和一般的紙不大一樣,我設計時以A4為大小,因此準備了4張洞洞板,每張為10cm x 16cm,價格一張NT $30
2c. 多顆電阻,因為LED是二極體,需要有電阻來匹配,因此需要多顆電阻,電阻數量根據變壓器的輸入電壓、LED電壓、電流、串並聯方式而定,關於電阻的選擇,可以用這個網站幫你計算,原則上來說,變壓器的輸入電壓越大,LED可以串連越多,則矩陣並聯數量越少,電阻需要量也越少。以我這邊來說,需要16根150歐姆電阻,2根330歐姆電阻。購買UV LED時,網拍很貼心的有附上電阻和二極體,如果剛好和需要的一樣,則可以省下電阻費用,電阻一顆NT $0.5
2d. 變壓器很貴,尤其大電壓大電流的更貴,不過好在現在筆記型電腦便宜,幾乎人手一台,像我有報廢的舊筆電,變壓器都剩下來了,筆電的變壓器除了小筆電外,幾乎都是19V,電壓夠大,電流更是不用說,可以到2A以上,非常適合拿來替用,因此費用可以省下來
2e. 電源母座,找個筆電變壓器可以插的母座接頭,一個大概NT $3。
2f. 銅柱,用來把電路板固定在掃瞄器裡面的,因為有4塊電路板,至少需要16根銅柱,一個NT $2~NT $3。

整個成本算下來,大概在NT $500上下,和日光燈版的曝光機差不多費用,但UV LED曝光時間大概只要2~3分鐘,看起來C/P值很高,因此最後決定使用UV LED製作曝光機。

2010年1月7日

FFMpeg與SDL之播放器~心得 - 1

FFMpeg是Linux上知名的影音編解碼函式庫。
有多知名呢?這樣描述吧~Linux上播放程式並不多,但有數的播放程式幾乎都靠它進行解碼,就算這類播放程式有自帶解碼器或介面,也都會支援FFMpeg。

在這篇開始之前我必須要說清楚,FFMpeg是有軟體專利問題的,理論上無法用於商業開發,一旦被軟體專利的組織查到,是要花大錢的。
我在一年前左右就開始看FFMpeg,當時就是因為看到軟體專利問題,就停止了,這次會繼續的原因主要是:
1. FFMpeg是Linux上主要的編解碼函式庫,除了它別無選擇,Google Chrome的影音播放器目前也是以它為基礎,連Google Browser都用它,我只能相信在一般使用上,軟體專利問題應該不很大。
2. FFMpeg本身其實只是個編解碼函式庫的介面,意思是它在編譯時,可以選擇要編譯的編碼器和解碼器,我認為在商業化使用時,應該可以把有問題的編解碼器全部拿掉,只留下沒問題的(theora/ogg),如此一來對於自主的播放器來說,沒有軟體專利的問題,但程式又不需要更動即可使用。
3. 現在新版的FFMpeg有提供Nvidia的VDAPU的支援,可以直接用VDAPU進行H264的解碼,我一廂情願的認為,Nvidia的VDAPU應該已經有付過相關解碼器的專利費用了,所以用FFMpeg的VDAPU對影片解碼應該是沒軟體專利的問題。

因為上述的幾個想法,所以決定繼續FFMpeg和SDL的學習。

FFMpeg和SDL的播放器,最主要的學習是以An ffmpeg and SDL Tutorial - ffmpeg tutorial為主,不幸的是,隨著2010年跨年,跨完年它網站資料就不見了...@_@!
好加在它html雖然都不見了,但txt和source code倒是到還在,連結如下:
Tutorial 01文字版 Tutorial 01原始碼
Tutorial 02文字版 Tutorial 02原始碼
Tutorial 03文字版 Tutorial 03原始碼
Tutorial 04文字版 Tutorial 04原始碼
Tutorial 05文字版 Tutorial 05原始碼
Tutorial 06文字版 Tutorial 06原始碼
Tutorial 07文字版 Tutorial 07原始碼
Tutorial 08文字版 Tutorial 08原始碼

最後,有一點必須要說的,整篇FFMpeg與SDL的教學,是基礎在ffplay這個播放器,我按照他的教學寫了2週,在EeePC上播放都有問題,一執行CPU就滿載且播放一陣子程式就卡住,必須要強制關閉,結果搞半天,我用ffplay也遇到一樣的問題,所以測試上有問題,目前我打算改看mplayer,看播放器的設計上有何不同,來瞭解ffplay為啥在EeePC上執行會有這樣的問題。
前言結束。

第一篇:
本篇的教學在理解之後其實很簡單,目前網路上找得到的FFMpeg範例,程式碼幾乎都類似這篇的內容,如果只是想要進行影片的轉檔(不含聲音),那麼本篇足矣。

再次重申,FFMpeg是影音的編碼/解碼函式庫,因此它的主要工作都是在編碼解碼上,今天我們要寫個播放器,那麼單單只有FFMpeg是不夠的,所以還會需要SDL這樣的函式庫,不過這在第二篇才會細說,這邊僅針對FFMpeg的影片解碼過程進行解說(不含聲音)。

在瞭解FFMpeg的操作前,我們要先瞭解兩樣東西,一個是「檔案讀取流程」,另一個是「FFMpeg解碼處理流程」。
首先我們看到「檔案讀取流程」 。

檔案讀取流程:
char ch;
FILE *fp = fopen("test.txt","r");
while((ch = fgetc( fp )) != EOF)
printf("%c", ch);
fclose(fp);


上述這是一個非常常見的檔案讀取的程式段,它的流程很單純,就是下面三個步驟:


這裡關於流程圖的符號細節我們就不要考究了,菱形、圓弧型之類的會讓圖片一大團。

在FFMpeg也是一樣,FFMpeg操作的大架構事實上和檔案讀取相同,下面是它部份的程式段:
AVFormatContext *VideoFormatInfo;
av_open_input_file(&VideoFormatInfo, "test.mpg", NULL, 0, NULL);
.....
while(av_read_frame(VideoFormatInfo, &VideoPacket) >= 0)
{
影片操作;
.....
}
av_close_input_file(VideoFormatInfo);


操作上大概就上述這樣,不過我把大部分細節都去除了,因為這部份還沒提到。
這裡要讓人瞭解的是,FFMpeg的核心操作,其實就像是檔案讀取一般,只是FFMpeg要使用
1. av_open_input_file() 代換 fopen()
2. av_read_frame() 代換 fread()
3. av_close_input_file() 代換 fclose()

接著我們看到「FFMpeg解碼處理流程」。

FFMpeg解碼處理流程:
要瞭解FFMpeg的對影音檔的處理流程,基本上流程如下圖:


幾乎所有的播放程式,解碼的處理流程都像上圖這樣。

上述圖片中,關於聲音處理的部份都以半透明方式表示,原因在於,目前這篇文章僅討論影片處理,並沒有處理聲音部份,因此聲音部份並沒有在下面的程式碼和說明中。

上述的流程相對應到FFMpeg,會類似下面這樣的程式段:
.....
1. 解析出影音檔中的串流資訊
av_find_stream_info(VideoFormatInfo);
.....

2. 從影音檔的串流資訊取得影片軌是哪一軌
int VideoStreamIndex = -1;
int i = 0;
for(; i < VideoFormatInfo->nb_streams; i++)
{
if(VideoFormatInfo->streams[i]->codec->codec_type == CODEC_TYPE_VIDEO)
{
VideoStreamIndex = i;
break;
}
}
.....

3. 從影片軌中取得影片的編碼
AVCodecContext *VideoCodecInfo = VideoFormatInfo->streams[VideoStreamIndex]->codec;
.....

4. 根據影片的編碼找出相對應的解碼器
AVCodec *VideoDecoder = avcodec_find_decoder(VideoCodecInfo->codec_id);
.....

5. 開啟解碼器
avcodec_open(VideoCodecInfo, VideoDecoder);
.....

6. 對讀取出來的影片資料進行解碼
avcodec_decode_video(VideoCodecInfo, VideoFrame, &frameFinished, VideoPacket.data, VideoPacket.size);
.....


到此,FFMpeg解碼的主要部份都解說了,接著我們把讀取影音檔的程式段和影片解碼的程式段整合,並且加入一些細節做說明。
#include "libavcodec.h"
#include "libavformat.h"
#include "stdio.h"

int main(int argc, char **argv)
{
//註冊所有FFMpeg的編碼器
av_register_all();

AVFormatContext *VideoFormatInfo;

if( av_open_input_file(&VideoFormatInfo, argv[1], NULL, 0, NULL) !=0 )
return -1; // Couldn't open file

if( av_find_stream_info(VideoFormatInfo)< 0 ) return -1; //顯示 dump_format(VideoFormatInfo, 0, argv[1], 0); AVCodecContext *VideoCodecInfo; int VideoStreamIndex = -1; int i = 0; for(; i < VideoFormatInfo->nb_streams; i++)
{
if(VideoFormatInfo->streams[i]->codec->codec_type == CODEC_TYPE_VIDEO)
{
VideoStreamIndex = i;
break;
}
}
if(VideoStreamIndex == -1)
return -1;

VideoCodecInfo = VideoFormatInfo->streams[VideoStreamIndex]->codec;

AVCodec *VideoDecoder;

VideoDecoder = avcodec_find_decoder(VideoCodecInfo->codec_id);
if(VideoDecoder == NULL)
{
fprintf(stderr, "Unsupported codec!\n");
return -1;
}

if(avcodec_open(VideoCodecInfo, VideoDecoder) < 0) return -1; int frameFinished; AVPacket VideoPacket; i = 0; while(av_read_frame(VideoFormatInfo, &VideoPacket) >= 0)
{
if(VideoPacket.stream_index == VideoStreamIndex)
{
avcodec_decode_video(VideoCodecInfo, VideoFrame, &frameFinished, VideoPacket.data, VideoPacket.size);

if(frameFinished)
{
//影片檔圖片讀取完成,進行圖片操作或影像處理
}
}
av_free_packet(&VideoPacket);
}

av_free(VideoFrame);
avcodec_close(VideoCodecInfo);
av_close_input_file(VideoFormatInfo);

return 0;
}


上述的程式碼比之前2段程式段都更複雜些,但相似度非常高,沒加入的部份很少,這裡會對沒加入的部份進行說明。
這個程式碼應該算是可以動作的,但它並不會對取出的影片圖片進行處理,只是單純的解碼而已,更完整的部份再接著才會進行。
在這個程式碼中,有幾個前面沒提到的部份。
首先:
av_register_all();
這個function是用來告訴FFMpeg,我們要註冊所有的FFMpeg解碼器,註冊之後,我們後面的解碼器操作才能順利進行。

接著:
while(av_read_frame(VideoFormatInfo, &VideoPacket) >= 0) //跟讀取檔案方式相同,只要影片還有 Frame,就一直讀,av_read_frame會將讀到的 Frame 放入 AVPacket結構 中
{
// Is this a packet from the video stream?(這個 packet 是從 video stream 來的?)
if(VideoPacket.stream_index == VideoStreamIndex) //從已經讀到的 AVPacket結構 中,判斷這個 Packet 是哪個 stream 的,在這裡我們只需要 video stream,因此這行判斷
{
}
}

在使用av_read_frame()遞迴的讀取時,因為讀取到的影音資料是影片、聲音混合的,所以我們在讀取後要使用 if(VideoPacket.stream_index == VideoStreamIndex) {} 來判斷影片或聲音,判斷出影片後才能進一步操作,聲音在此則不管它。

接著:
if(frameFinished)
{
//影片檔圖片讀取完成,進行圖片操作或影像處理
}

這裡這段想必會很疑惑,frameFinish用途何在。
其實FFMpeg使用 av_read_frame() 讀出時,讀出的單位並不是一張圖片,而是影音的 Packet(封包),因為一部分的「Packet」並不能表示成一張「畫面」,因此我們在使用 avcodec_decode_video() 進行影片解碼時,要傳入 frameFinish,讓FFMpeg透過 frameFinish 告訴我們是否完成了一張完整的圖片解碼,當完成了一張圖片解碼時,if(frameFinished) {} 才會符合,我們也才能對這個解出的圖片(畫面)進行進一步的處理。

為了讓這個程式有意義,而不是虛無飄渺的甚麼東西都沒有,我們加上最後一個部份,把解碼出來的畫面進行輸出,整個程式可以把影片的最前面5張畫面輸出成5個圖片檔。

首先加入下面這段程式碼:
void SaveFrame(AVFrame *pFrame, int width, int height, int iFrame)
{
FILE *pFile;
char szFilename[32];
int y;

// Open file
sprintf(szFilename, "frame%d.ppm", iFrame);
pFile=fopen(szFilename, "wb");
if(pFile==NULL)
return;

// Write header
fprintf(pFile, "P6\n%d %d\n255\n", width, height);

// Write pixel data
for(y=0; ydata[0]+y*pFrame->linesize[0], 1, width*3, pFile);

// Close file
fclose(pFile);
}


這段程式碼功能很簡單,將讀取出來的畫面(圖片),以 fwrite() 的方式寫入到檔案中,就成為了 ppm 格式的圖片檔。

為了要能使用 SaveFrame(),我們還需要改寫剛剛的程式碼。
.....
if(avcodec_open(VideoCodecInfo, VideoDecoder) < 0) return -1; //針對 SaveFrame() 新加程式段 開始 AVFrame *VideoFrame; AVFrame *VideoFrameRGB; VideoFrame = avcodec_alloc_frame(); VideoFrameRGB = avcodec_alloc_frame(); if(VideoFrameRGB == NULL) return -1; uint8_t *VideoBuffer; int numBytes; numBytes = avpicture_get_size(PIX_FMT_RGB24, VideoCodecInfo->width, VideoCodecInfo->height);
VideoBuffer = (uint8_t *)av_malloc(numBytes*sizeof(uint8_t));

avpicture_fill((AVPicture *)VideoFrameRGB, VideoBuffer, PIX_FMT_RGB24, VideoCodecInfo->width, VideoCodecInfo->height);
//新增 結束

int frameFinished;
AVPacket VideoPacket;
i = 0;
while(av_read_frame(VideoFormatInfo, &VideoPacket) >= 0)
{
.....
if(frameFinished)
{
//針對 SaveFrame() 新加程式段 開始
if(new_img_convert == NULL)
{
new_img_convert = sws_getContext(VideoCodecInfo->width, VideoCodecInfo->height, VideoCodecInfo->pix_fmt, VideoCodecInfo->width, VideoCodecInfo->height, PIX_FMT_RGB24, SWS_BICUBIC, NULL, NULL, NULL);
}
if(new_img_convert == NULL)
{
fprintf(stderr, "Cannot initialize the conversion context!\n");
exit(1);
}
sws_scale(new_img_convert, VideoFrame->data, VideoFrame->linesize, 0, VideoCodecInfo->height, VideoFrameRGB->data, VideoFrameRGB->linesize);

// 將 frame 存入檔案中
if(++i <= 5) { SaveFrame(VideoFrameRGB, VideoCodecInfo->width, VideoCodecInfo->height, i);
}
}
.....

最後,下面這個連結就是完整的程式碼檔案。
ffmpeg_1x.c

2009年9月14日

LUXGEN7 MPV試駕開始~

之前blog的台灣~裕隆~汽車設計提到現在裕隆正在自製汽車,最近這段時間可以注意到,開始陸續有廣告出現,mobile01也出現了LUXGEN的版面和相關活動介紹。

雖然我買不起,但支持還是要的,針對這台非常現代化的自製汽車,專業介紹很多,我也就不獻醜了。

網路雜誌對LUXGEN7 MPV的介紹:
汽車線上:【國內試駕】LUXGEN7 MPV <上>
汽車線上:【國內試駕】LUXGEN7 MPV <下>

網友的試駕心得:
智慧車款新體驗-LUXGEN7 MPV試駕分享

從這台車的介紹看起來,我個人覺得它倒車攝影機相當方便,和我之前想到的想法差不多,把攝影機放置在後照鏡,可以方便的透過LCD即可看到後方的狀況,是很方便的設計,想想看,每次開車看後照鏡時,總是會卡一條黑邊擋住視線,或者有些地方就是因為鏡子角度不好橋看不到,能夠有個這樣的攝影機可以無死角的看到後方,真的是很棒;此外,它的夜視系統真的很不錯哩,0.1流明的極低亮度下,可以看到前方100公尺,寬度40公尺範圍內的畫面,這性能相當的好。

其他部份,我沒親自看過車,對汽車瞭解也不深,也就不方便評論太多(好壞不會分),不過站在資工人的角度來看,它的電腦系統還有剛剛提到的夜視系統和攝影系統,我覺得相當的先進。

對於mobile01上一些人批評它只是加了電子設備的飛羚101,或者說這台車號稱世界第一的智慧型汽車,根本沒把大廠車放眼裡...等等的說法,我只能說,這台車好歹是台灣人自己做的,未來要賣大陸賣歐洲賣美國的,這台車在研發過程中,夜視系統跟中科院技轉,酒精測試系統跟工研院,使用了醫療上的無接觸感測技術,加上它電腦系統跟HTC合作,這些裝置、設備、技術還有和汽車本身的高度整合,並不是全世界所有車廠都有的,你可以說它某部份比不過BMW、賓士、Toyota(像停車輔助系統,BMW、賓士都提供自動停車),但這台車並不是所有技術其他車廠都有,有些是它才獨有的,有些則是賓士、BMW這種高級車款才有的,如果僅僅只是在旁邊打嘴砲,看看DM就說這個賓士有、這個BMW有,這個Toyota做更好是不公平的,因為最終能夠把這些技術統統整合放入一台汽車中,售價又能比賓士、BMW低很多符合台灣人口袋的水準,那就是一台好車,對於這樣的車子,只是在旁邊看熱鬧,那就多點讚美少點批評吧!!

2009年8月21日

軌跡記錄器有無機會變成自救器?

這次風災,開始出現一些新聞是討論空投位置錯誤,因此拿不到救援物資,也出現了女兒給國軍座標後,救出父親的新聞。

在現在這個資訊發達的時代,GPS & GIS已經普遍到深入一般人的生活中了,而在遇到災難時,只要能夠有GPS座標且人沒死,能夠獲救的機會就很大。

目前軌跡記錄器已經十分普遍了,記錄器本身其實就是GPS,透過不斷地紀錄目前位標,最後透過USB傳輸線傳回電腦後,和GIS結合並顯示。
既然這樣,有沒有可能把軌跡記錄器和救生器結合?當發生意外時(按下按鈕或者受到強烈碰撞),記錄器便會自動發送訊號,告知目前的GPS座標,如此一來就能自救。
我認為這樣的想法不錯,但最大的問題可能是在「發送訊號」這部份,是要送出無線電信號(摩斯電碼)?SMS簡訊?無線網路?3G?

我個人是覺得,如果size許可,軌跡記錄器結合無線電,在遭遇災難時,固定30分鐘或1小時發送一次SOS+GPS座標的無線電信號,應該是不錯的idea。

2009年8月14日

颱風災情嚴重,請大家有錢出錢有力出力

首先,我在今天下午終於辦完離校,拿到畢業證書了,雖然還要留學校幾天寫交接文件和測試,但這算是負責了~沒有直接跑掉~

回主題~
先po上我最近幾天的MSN標題:
讓我們一起用愛與善款幫助88水災受難者!我決定捐出半個月薪水3000元給紅十字會!http://tw.charity.yahoo.com/

因為我還算是學生身份,薪水還只有6000元,我在8/11號已經透過Yahoo!奇摩 公益捐出半個月薪水3000元,我想這是目前我還有能力做到的事情。
我其他實驗室的同學在口試完畢後,因為他們老闆並沒有太多要求,沒什麼事情~已經去當義工幫忙好幾天了!

這次捐款也是我繼上次四川震災後的第二次捐款,金額也都是3000元。

我的捐款紀錄
日期公益團體專案名稱需求名稱捐款金額方式
2009/08/11中華民國紅十字會八八水災援助計畫災後重建3,000信用卡


這次的風災災情非常誇張,南台灣降下2500毫米以上的雨,這樣的量已經超過了200年防洪標準,我相信就算在美國、日本等更先進的國家,這樣的雨量造成的災害並不會比較好。
這次風災,似乎也是第一次看到派出特戰隊員去搜救探路,我不確定之前有沒有過,但上新聞應該也是第一次,值得鼓勵,畢竟養兵千日,就是用在這時候。

我相信目前的物資應該已經夠了,救災物品應該已經爆了,特別把捐款紀錄列出來不是炫耀,是建議可以把錢捐給災後重建,我認為:
1. 目前看來物資不缺,再捐物資意義不大且浪費資源
2. 目前快進入災後重建的步驟,災後重建就會開始需要花錢
3. 災後重建需要的費用更高,而且耗費時間更長
4. 這時候在無法預料未來需求時,錢比物資更有用
5. 到災後重建的階段,大家心都冷了,捐款會變少,到時候指定用途為救災用途的捐款可能會過多卻沒用,變成浪費

基於上述5點,我把錢捐來做「災後重建」,相信可以讓3000元達到最大的效力,也希望大家還要捐款、捐愛心的,有錢可以捐給重建基金,有力有時間的可以去當義工幫忙。

2009年8月3日

PDAMessager成果展示

口試結束了~搞了四年終於快畢業了~
口試後 新Media Center 計畫繼續。

新Media Center打算用朋友建議的,主機和外接盒分離,外接盒部份就只放光碟機、讀卡機...等,主機部份就用個舊PC殼加上Core 2 Pentium CPU、入門主機板和N9400GT顯示卡。

因為目前的Media Center-ASUS DigiMatrix是有個小小地LED顯示幕的,我上面透過程式擷取中央氣象局的資訊,它能顯示時間和目前的氣溫。
為了能夠有同樣的訊息顯示,我考慮在外接盒上加入一個LCM顯示幕,不過後來受到銀欣 GD02-MT 家庭劇院機殼銀欣 CW03-MT 全鋁家庭劇院機殼的啟發,想到可以仿照它的方式,加個LCD顯示器,而這樣的LCD顯示器不過就是個ARM開發板+LCD螢幕罷了,在網拍後發現目前舊的PDA價格非常不錯,NT 1000多就可以買到iPAQ 3xxx(3600、3800、3900都有),而LCM顯示幕一塊128x64 藍底白字版本,網拍要NT 500,光華要NT 800,這還不算Printer Port...等零件的費用,考慮到CP值,用舊PDA當然划算,因此就有了PDAMessager的計畫。

PDAMessager功能上,就是一個類似捷運的資訊看板,它的主要功能就是替代ASUS DigiMatrix上氣溫、時間的顯示,不過既然全彩又更大,當然希望加些新功能,因此開發上訴求是:
1. 要能顯示時間、溫度
2. 要能夠按遙控器時,顯示訊息(像「播放」)
3. 因為PC不可能一直開著,當PC關機時,要能顯示PC為關機狀態

這次這個是口試後開工的成果,到目前為止大概花了3周的時間,原則上就是SDL + Socket Server的成品。

首先如下圖,這是測試的示意圖,原則上它就是USB接電腦,USB網路就會自動連線並設定好IP。
寄件者 iPAQ3950


接著看到它的成果影片:


畫面的內容是這樣的:
當程式啟動後,會進入MODE 1,也就是一般的天氣、時間顯示的模式。

當PC關機時,我們可以透過Socket Client的方式下指令,讓它進入MODE 0,也就是畫面切換成只有時間的模式,注意看,右下角有個關機。

再來展示的是當遙控器按下時,PC同樣可以透過Socket Client下指令,將要顯示的文字、字體大小、顏色(RGB)傳過去,之後切換到MODE 2,即可顯示出文字內容,為了展示這個程式可以支援多國語言,因此顯示了「中文 にほんご EN」,表示中文、日文、英文都ok。

再來看到畫面變成了一張風景照,這是考慮到傳入的訊息,如果只是文字可能太單調了,顏色又只有一種,也許未來可以在PC端即時的產生「圖片」來顯示,因此也提供了可以傳入圖片顯示的功能,這功能說不定還能當作相簿來使用。

最後我們看到最後一個畫面,同樣也是風景照,但是上面印了文字「風景照片」四個字,這是考慮到遙控器動作時,可能希望顯示個背景加上訊息,因此結合了上面顯示文字和顯示圖片的功能,讓它能夠同時顯示圖片和文字。

2009年6月28日

FreeBSD MPD PPPoE斷線檢查Script

家裡是用中華電信FTTB的VDSL,設定實際上就是PPPoE的設定,而我使用FreeBSD+pf+mpd當NAT。

雖然中華電信大部分情況下都滿穩的,不大會斷線(可能VDSL過熱、機房改設定...等原因吧),但有時候就是會不知道什麼原因斷線,mpd上關於重新連線的設定雖然有加,但似乎沒啥效果,斷線後就是沒IP不會重新連線。

這次又發生了這樣的情況,為瞭解決這樣的問題,寫了個超簡單斷線檢查Script,在發生PPPoE斷線時自動把電腦重新開機。

#!/bin/tcsh

if(== `/sbin/ifconfig | /usr/bin/sed '/-->/\\!d' | /usr/bin/awk '{ print $2 }'`) then
/sbin/reboot
endif


程式碼超級簡單,當執行它之後,它會執行

/sbin/ifconfig | /usr/bin/sed '/-->/\!d' | /usr/bin/awk '{ print $2 }'


也就是執行ifconfig,然後找「-->」,找到後把第二個字串取出(PPPoE取得的IP),如果找不到,顯然就是PPPoE斷線了。
接著透過 tcsh 的 if 判斷式,判斷上述指令「找不到時」,就執行裡面的指令

/sbin/reboot


完成後改好權限,把它放入/etc/crontab中

*/30 * * * * root /usr/local/bin/disconnect-check.sh


如此一來,每30分鐘它都會執行一次,看看PPPoE有沒有秀斗,如果秀斗了,就把電腦重開。

我有測試過,應該是能夠work的。

2013-08-30更新
程式更新如下
#!/bin/tcsh

if( ! -e /var/log/disconnect-reboot.log ) then
  touch /var/log/disconnect-reboot.log
endif

if(== `/sbin/ifconfig ng0`) then
  echo `date +%Y-%m-%d\ %H:%M:%S` reboot >> /var/log/disconnect-reboot.log
  reboot
else
  if(== `/sbin/ifconfig ng0 | /usr/bin/sed '/-->/\\!d'`) then
  echo `date +%Y-%m-%d\ %H:%M:%S` mpd restart >> /var/log/disconnect-reboot.log
  /usr/local/etc/rc.d/mpd5 restart
  endif
endif

新增與修改:
1. 檢查log檔案是否存在,不存在則建立
2. 如果裝置ng0不存在,重新開機(異常情況)
3. 如果裝置ng0存在,但沒有IP,將mpd重新啟動(通常的斷線情況)

2009年5月15日

FreeBSD登入後中文亂碼問題

在 FreeBSD 中,雖然已經支援 Unicode(UTF-8) 了,但如果我們只有設定在 csh.cshrc 中,我們會發現登入後的訊息依然是亂碼,原因是在於登入時候的環境設定並沒有設定成 zh_TW.UTF8。

這意思是說,雖然我們在 csh.cshrc 裡面設定了環境是 zh_TW.UTF8,但在我們登入時,系統完成認證,並執行 SHELL 的時候,並沒有設定環境是 zh_TW.UTF8,因此這時候的訊息如果是 UTF-8 的編碼,會是亂碼的狀況。

解決辦法很簡單,我們在 /etc/login.conf 裡面加入相關設定,修改如下:
default:\
:passwd_format=md5:\
:copyright=/etc/COPYRIGHT:\
.....
:ignoretime@:\
:umask=022:


改成
default:\
:passwd_format=md5:\
:copyright=/etc/COPYRIGHT:\
.....
:ignoretime@:\
:charset=zh_TW.UTF-8:\
:lang=zh_TW.UTF-8:\
:umask=022:


修改完畢後,要記得執行如下指令,將設定寫入系統中:
# cap_mkdb /etc/login.conf

即可!

2009年4月8日

永豐開戶ok嚕~~

今天天氣不錯,特別在下午跑了一趟永豐銀行。

永豐銀行的無摺戶我想不用再介紹了,它的跨行免手續費很優,我就是衝著這點辦的(4/1開始,跨行提款、轉帳免手續費改成4次,不再是8次了),在此之前,我是用富邦的V Banking,不錯是不錯,一家富邦分行離我家又超近(走路就可以到了),但它只有2次跨行轉帳免手續費,有時候會不大夠用。

也剛好有一家永豐銀行離學校不會非常遠,以距離來說,從學校出發,到永豐的距離比到富邦近。

今天開戶很順利,並不像網路說的被一直刁難,倒是有說我不是在戶籍地,我就直接說我是學校的學生,然後服務小姐跟我要學生證,整個過程都很順利,幾乎就簽簽名,填填個人資料就完成了。
接下來就是等下週去銀行拿提款卡嚕~~

Google App Engine支援Java啦~

自從去年的Google Developer Day之後,我就對Google App Engine頗有興趣,想想看,我們能夠免費的利用到Google龐大的Cluster系統,是一件多棒的事情阿!
可惜它一直以來都只支援Python,我跟它完全不認識,因此對Google App Engine一直都只能看著流口水.....
現在不同了~Google App Engine在昨天4/7正式發佈支援Java,未來我就可以用熟悉的Java來開發App Engine,不論是玩票性質的寫個留言板,還是其他奇怪的想法,都會是很棒的事情。

2009年3月29日

Smoothie光合舒果昔試飲心得

每次到便利商店要買喝的,看到琳瑯滿目的飲料都不知道要買什麼才好。
看到果汁、蔬果汁,就會注意到果汁成份只有30%、50%,甚至還有10%的。
喝紅茶、綠茶、奶茶,就會發現裡面果糖加很大,好像整瓶果汁有半瓶都是糖的感覺。
喝烏龍茶、綠茶儘管不錯,也有無糖可以選,但永遠都只有烏龍茶和綠茶可以選。

這次因為看到「Smoothie光合舒果昔」的試飲心得活動,我注意到了這個新的飲料,更因此愛上了它。


Smoothie光合舒果昔從拿在手上到喝下第一口的感覺,都讓我注意到了它的用心,它使用的不是傳統的鋁箔包,而是目前最新的「利樂鑽包裝」,這種包裝拿在手上握感很不錯,不像傳統的鋁箔包,哪個方向握感覺都怪怪的;此外這種包裝和傳統的鋁箔包相比,從表面看感覺大小差不多,但它的內容量卻足足有330ml,份量比傳統的鋁箔包多了很多。

一個新的飲品單單只有包裝好是沒有用的,Smoothie光合舒果昔的口感相當的棒。

我這次買的是「strawberry & banana」的口味,正如名字中的Smooth,飲料倒入嘴巴、滑過喉嚨的感覺非常滑順,不會有喝冰水的刺激感;此外,非常值得一提的,在喝過後一陣子,不會殘留不自然的甜味或化學糖份的苦味、澀味。
喝一口放入口中,香蕉的綿密感讓人印象深刻,其他的水果像是草莓、水蜜桃、蘋果的香甜滿溢口中,此刻會有一種幸福的感覺,好像煩惱都煙消雲散一般。

感謝7-11能夠研發出這麼讚的飲品,讓我自烏龍茶、綠茶後,又找到一個新的選擇。

下面是我和它的親密合照。



晚餐與它的合照。


http://blog.7-11.com.tw/diary.asp?blogid=153

2009年3月27日

FON變身大絕招

剛剛因為學弟send給我關於FON賺錢相關的文章,勾起了我對FON的回憶。

之前曾經google過FON可以怎麼改裝,而查到下面這個網址:
http://www.lefinnois.net/wpen/index.php/2007/05/13/i2c-bus-for-la-fonera/

當然還有其他類似的網站,原則上以「FON i2c」來搜尋就能找到了。

很多人都會問,FON要怎麼改裝?能夠變成怎樣?能不能當電話?能不能跑BT?
但大部份都還侷限在軟體相關的服務,通常把它和無線基地台或IP分享器劃上等號,然後查詢或試想能做什麼。

但其實~FON它還有個很棒的地方,就是它是個超小且支援802.11g的嵌入式開發板,它上面同樣有I/O可以使用。
這時候我們終於介紹到上述網站的內容了。

在國外瘋狂的FON hacker的努力下,FON已經被完全且深入的瞭解了。

FON內建的I/O並不多,經過「處理」後(以4根GPIO模擬2組I2C介面),FON可以拉出「2組I2C」介面,這是FON僅能利用的I/O介面,但對於電子相關科系的同學們來說,這已經足以讓我們開始各種惡搞計畫。

I2C是近年熱門的介面,它有幾種表示方式,IIC、I2C,其中的2其實是平方,因為打字的關係,通常連著打。
在電子相關科系中,大部分同學可能還沒聽過它,但它被用的很多了。
I2C其實和RS-232(UART)差不多,同樣是串列傳輸埠,但它只需要2條線就能動作了,I2C因為只有2條線,又只是high/low的表示,因此在遇到沒有內建I2C的時候,可以用2根標準IO來模擬出I2C的動作,而目前一些單晶片像是部份AVR就有內建I2C介面。

既然FON有I2C可以操作,而且還有2組,我們就能夠透過I2C將FON和AVR之類的單晶片進行連接,由FON對AVR下指令,再由AVR實際動作,開發上其實和PC<->RS232<->8051差不多。

有了類似AVR這樣的單晶片,我們就能夠用AVR開發各類電子專題,像是常見的自走車、警報器...等。
AVR+FON,我們就能夠開發802.11g的遙控自走車。

人家說沒圖沒真相,事實上國外已經有不少人以FON開發出自走車,原理不外乎就是FON+單晶片組合而成,影片如下:
http://www.youtube.com/watch?v=7qqthHWTheA
http://www.youtube.com/watch?v=2hBb3F27Tsc
http://www.youtube.com/watch?v=A4wdrhiMO0s

而關於FON的I2C介面如何拉出來,下面的blog有不錯的教學:
i2c bus for La Fonera

另外,下面這個網頁雖然不是拉出I2C,拉出來的是SPI介面,但用的I/O腳相同,同樣可以參考:
Fonera SD Card Hack

2009年3月26日

該用64bit Linux嗎?(新測試已逆轉)

剛剛朋友問我,它們公司在考慮新環境是否該改用64bit Linux,問我是否適合換成64 bit,換了有什麼好處?效能表現差異多大?

我曾經在摩托學園詢問過Intel 64 bit 在 Debian 上要怎麼設定?,另外也搜尋到大家的 x86-64 CPU 都跑 amd64 還是 i386 呢?,看起來大部分都還是建議用32bit Linux。

而一般來說,64 bit Linux的效能應該會比較好,那以效能表現來說,64 bit Linux效能能好多少?是否以效能為考量的Linux Server用64 bit會比較好呢?
於是我用「32bit 64bit linux performance」為關鍵字在Google搜尋,找到下面2篇:
AMD Phenom 32-bit vs. 64-bit Performance
Ubuntu: 32-bit v. 64-bit Performance

這邊要特別注意,Ubuntu: 32-bit v. 64-bit Performance這篇是2006年的測試。

從上述2個網頁中,作者針對32bit和64bit的Linux的比較,我發現到幾個事情:
1. 在遊戲相關的效能中比較,64 bit Linux幾乎都比32 bit Linux差,而且差不少
2. 在I/O相關的行為上,包括RAM的讀寫...等,32 bit Linux和64 bit Linux表現差不多,32 bit Linux略快
3. 針對CPU處理頻繁的工作,包括kernel make(gcc compiler)、MP3轉檔(lame)、檔案壓縮(gzip)上,64 bit Linux的表現要比32 bit Linux好
4. 可能是因為硬體不同,也可能是新版有針對64 bit做最佳化,2006年的那份測試和2008年的測試,gzip的表現反應差異較大,lame的表現差距幅度也有差異

整體來說,我認為64 bit Linux應該只有在CPU關聯性大的工作會有較突出的效能表現,其他部份「效能不一定比較好」,此外,在摩托學園的討論中看得出來,目前64 bit Linux還是有不少應用程式不支援。
所以我認為,目前還不是全面使用64 bit Linux的時候,除非對於CPU效能極度要求的情況下,那麼我個人的建議是,先瞭解該Linux Server要運作的應用程式或服務,目前對64 bit Linux的支援狀況(包括相容性、是否針對64 bit指令集EM64T最佳化...等),全部確定後,一切ok再上路
如果是個人PC或桌面系統,那麼正如上面說的,我認為目前還不是使用64 bit Linux的時候。


感謝回覆留言的匿名網友,從最新的測試中可以發現,現在64 bit Linux在64 bit平台上效能已經超越32 bit,而且超越很多,上述評估已經不正確了。

2009年3月24日

詐騙電話

剛剛又接到詐騙電話了~
可能因為上次耍了他,這次打來一接就掛斷~
因此上網搜尋後,下面列出搜尋到的詐騙電話,未來會持續更新:
0913925523
0927344966
0927429858
0938822315
0938822531
0989041218
0989041220
0989041385
0989382037
0989385003
0989385004
0989385031
0989385032
0989385033
0989385034(我剛剛接到這隻)
0989385037
0989385039
0989385040
(以上來源:http://www.wretch.cc/blog/hsueh925/10138374)
0989677972
(以上來源:http://www.wretch.cc/blog/may931107/20411495)
0989565193
0989506753
(以上來源:http://blog.yam.com/speed777/article/14211587)
0982649297
0982752752
0923790350
(以上來源:http://blog.sina.com.tw/t_mango/article.php?comment_page=19&pbgid=1523&entryid=16674)
0980486012
(以上來源:http://www.mobile01.com/topicdetail.php?f=37&t=791387&p=7)
0980149288
(以上來源:網友留)
最後寫下防堵的辦法
如果使用新款的智慧型手機(高階手機),可以針對不同手機作業系統來找「來電黑名單(也叫來電警衛...等類似名稱)」軟體並安裝,輸入上述電話號碼後即可幫你自動過濾,未來有新的,再持續更新。
如果像我一樣使用舊款手機,我記得Sony手機有黑名單功能,之前的T68記得有看過,而我正在用的Nokia 6230沒有黑名單功能,不過Nokia手機可以設定「號碼分組」,目前設定一個「黑名單分組」,把上述號碼全部加入,接著錄製一段無聲鈴聲並設為分組鈴聲即可。

2009年3月21日

建置1080p Media Center事項

最近家裡要換客廳電視,目前我是看好SONY 32S4000,雖然它只有32吋,又雖然它只支援到1366x768,但沒辦法~目前1080p的LCD TV都還很貴,老爸缺錢又要換電視的現在,只能選擇32吋了~
我的想法是,反正目前都還是看有線電視,高畫質有線電視目前還不普及,就算有了也不能保證一定是1920x1080的解析度,至於數位電視,那個就更不用說了~所以我認為,3年內要讓1920x1980普及應該是有難度的,與其買台用不到這麼高解析度的,不如買台SONY 32吋高品質的LCD TV,看起來應該會爽很多。
關於電視最後提一下,SONY 32吋系列,S和V根據Mobile01魔人的深入分析,兩者雖然差價3000元,但內容相同,此外,SONY 32吋系列再次根據Mobile01的魔人檢查,發現裡面的面板用的是奇美的,在這經濟艱困的時期,別懷疑~買SONY也是愛台灣啦~

雖然電視沒辦法用到1080p,但Media Center播放的高畫質電影檔情況稍稍不同,Media Center是電腦,它在播放影片時,並不會因為輸出的解析度比較差,就因此能夠節省CPU使用率或系統資源,因此,為了能夠播放所有影片,包括高畫質影片,Media Center需要升級,來應付720p以上畫質的影片檔,所以,最近開始尋覓目前針對高畫質影片的電腦建置。

我在之前的Media Center中應該提到過,我家目前的Media Center是P4-2.4G的CPU,主機板的整合式晶片組是Sis 630,因此顯示卡部份也是Sis的晶片。
P4-2.4G看起來很新,但事實上對於720p以上的影片,它是不足的。
目前我實際使用的經驗是,以網路上下載的720p日劇,播放時CPU使用率大約75%~100%,中間的Range是關係到影片播放當時的影片狀況,通常較細膩的片段就會lag,此時就是100%,因此網路上通常有人會說,720p影片P4-2.4G可以看,那是不精確的,測試的人八成只是把影片拿來開開看,看CPU使用率只有80%上下,就認為ok,這實際上是錯誤的結論。

此外,有一類720p的影片P4-2.4G CPU也是不夠力的,那就是下載的高畫質電影常使用的H264編碼,就算這部H264編碼的片子只是720p,P4-2.4G還是不夠力的,情況會比前面的日劇更糟(720p日劇編碼通常是DivX 6)。

高畫質影片往往需要更大的儲存空間,為了盡可能的減少儲存所需的空間,因此都會壓縮,而傳統的影片壓縮格式像是MPEG-1、MPEG-2、MPEG-4、DivX...等,壓縮率已經不足以應付FullHD(1920x1080)的影片,因此H264被提出並成為了FullHD影片的標準壓縮格式之一。
H264能讓高畫質影片儲存空間更小,但所付出的代價就是運算量,因此對CPU的負擔非常大。
很不幸的,如果要以軟體解碼的方式來處理,目前要能夠處理包括H264在內高畫質影片的CPU,至少需要中階以上的CPU才能應付,而中階以上CPU的價位並不很親民。

可能是因為上述的原因,最近幾年Nvidia和ATi(AMD)的顯示卡都內建了高畫質影片的硬體解碼晶片,而且具備這樣能力的顯示卡並不貴,大概NT $2000上下就能買到了,因此最近配Media Center的電腦,幾乎都會額外添購一張能夠支援FullHD的顯示卡,而挑選這樣的顯示卡,就變成了一個新的學問了。

在1080p Media Center建置的事項中,我們可以分為硬體和軟體兩類:

硬體:
要能夠處理1080p的影片,硬體上有2種解決方式,1種是買強力的CPU用軟體解碼來解決,另一種是買張新的顯示卡用硬體解碼來解決。

1. 使用CPU來解決
用CPU來解決問題其實不錯,後續問題可以少很多,但CPU很貴,要能夠處理到1080p影片的中階CPU價格通常需要NT $4000以上,如果錢不是問題,那直接買顆高速高貴的CPU統統都能搞定。
但這邊要注意一點,高速CPU通常很燙,高畫質影片軟體解碼時CPU使用率通常不會只有10%~20%,至少也有30%~50%,它會較耗電也會較熱,如何選擇高效能的散熱器又可以減少噪音,會是一個大問題。

2. 使用顯示卡來解決
以目前(2009-03-21)來說,目前NVIDIA主流的顯示卡大致有8000系列和9000系列兩種,網路上許多人會說這時候買8000系列的中階顯示卡最划算,因為8000系列是NVIDIA的舊晶片組,它的中階卡在之前都是NT $5000、NT $6000,現在只要NT $2000、NT $3000即可買到了,可以說是物超所值,但是,我在這邊要提出完全不同的結論。
如果以Media Center為用途,專門用來播放高解析度影片,那麼~買9000系列低階顯示卡會比8000系列中階顯示卡更合適,2者價格差不多~9000系列低階卡稍微低一點。
原因有2個:
1. 溫度
9000系列使用新的晶片,它的低階顯示卡溫度較低,8000的中階顯示卡通常都需要很大的散熱片和風扇,對Media Center來說,噪音是非常難搞的,沒有人會希望看電影的同時旁邊有個嗡嗡嗡的聲音,因此就溫度來說,9000系列更合適。

2. 硬體解碼的支援
NVIDIA在8000系列的顯示卡中就已經支援高畫質影片的硬體解碼(稱為PureVideo)了,但是8000全系列都只支援3種格式的硬體解碼,包括:
a. MPEG-1
b. MPEG-2
c. H264

而9000系列使用的新晶片,內建則支援4種格式的硬體解碼,包括:
a. MPEG-1
b. MPEG-2
c. H264
d. VC-1

關鍵在新出現的VC-1,VC-1乍看之下很陌生,但其實被應用的地方不少,VC-1是Microsoft提出的wmv中使用的編碼。
Microsoft在高畫質影片中一樣插了一腳,以類似H264的演算法來設計,並使用在wmv當中,Microsoft稱之為VC-1。
如果使用NVIDIA 8000系列的顯示卡,不論是低階、中階或是高階,全部都沒有包含VC-1的硬體解碼,換句話說,未來如果看到wmv的影片,就算使用的是8000系列中最高級的顯示卡,同樣都必須用CPU來運算,CPU不夠力,就是lag。

軟體:
如果使用CPU來做軟體解碼,基本上軟體的設定沒什麼問題,按照傳統的作法把codec安裝上去即可。
但如果是使用顯示卡來進行硬體解碼,軟體的配置就需要注意了。

接下來我會以NVIDIA來說,ATi的不清楚。

在Windows上,首先NVIDIA的顯示卡驅動程式是「一定要安裝」的,不安裝不可能支援硬體解碼,而且要安裝到最新版本的驅動程式。
安裝好驅動程式是不夠的,目前在Windows上,幾乎所有的codec都是軟體解碼,支援硬體解碼的codec很少,根據這陣子在網路上看到的,大概只有CyberLink PowerDVD提供的CyberLink Decoder和CoreAVC的Decoder可以支援顯示卡的硬體加速(使用硬體解碼)。
因此在設定上,必須要指定特定的檔案給特定的decoder才能使用到顯示卡的硬體加速。
而這部份,需要在各個播放程式裡面單獨的定義,像是KMPlayer可以設定,Media Player Classic目前我還不清楚。

在Linux上,為了讓Linux也能使用顯示卡的PureVideo(硬體解碼)功能,NVIDIA提出了VDPAU (Video Decode and Presentation API for Unix)。
VDPAU是專門針對NVIDIA顯示卡PureVideo(硬體解碼)功能的API,透過這組API程式設計師就能夠應用NVIDIA顯示卡上硬體解碼的晶片。
因為Linux上不同的文化和錯綜複雜的歷史因素,所以Linux上的播放軟體都直接內建decoder,所以目前要在Linux上支援VDPAU,必須針對播放軟體進行patch,讓播放軟體能夠支援VDPAU,才能夠使用硬體解碼。
目前在Linux上,確實有提供patch檔的播放軟體只有mplayer,而vlc、xine對VDPAU的支援都還在開發中。
比較讓人高興的是,Linux上的編解碼器軟體ffmpeg,已經有提供VDPAU的patch,所以是不是可以直接用vlc或xine呼叫ffmpeg來使用VDPAU,是之後使用時可以注意的部份。

整體來說,為了要處理1080p,我認為代價是很高的,以顯示卡的硬體解碼來處理1080p目前看來是不錯的選擇,但軟體設定很麻煩,而且硬體解碼只支援到1920x1080,未來更高解析度的影片它沒辦法處理(這邊指的沒辦法處理不是速度不夠快,而是顯示卡不能動作,有更高解析度的影片,顯示卡並不能支援,到時候完全只能用CPU來處理)。

2009年2月12日

Media Center Linux升級

(本文同步回覆在Linux Media Center設置心得(使用DiGiMatrix搭配Debian使用MythTV或Freevo))
在今年過年的連假,將Media Center改灌成Mythbuntu了(又一台電腦被Ubuntu佔領啦~)。
整個安裝的確方便快速很多,以往lirc需要自己重新編譯相對應的kernel module或kernel,現在已經完全不需要了,在安裝時直接可以用選單選擇,選好、安裝完畢後即可使用。

由於Ubuntu和Debian系出同源,所有原先Debian上的設定全部都可沿用,整個移機重灌的過程中,雖然沒有完全無痛~但頂多也只是小痛~非常推薦Mythbuntu。

如果是完全沒裝過Media Center,希望以Linux作為Media Center的話,強烈推薦Mythbuntu,幾乎所有以前需要辛苦的設定,Mythbuntu都只需要簡單的選單選項即可完成,不需要花費功夫處理。

關於diskless的部份,目前已經處理完畢了,這部份是整個移機過程中最痛的部份,因為Mythbuntu預設的kernel initramfs是硬碟開機,因此無法直接diskless安裝,我是先用硬碟裝好,然後複製到NFS Server上的。

而設定上,大部分參照Booting On PXE And On A Customized Debian System的設定即可,
比較不一樣需要處理的,是要修改
/etc/initramfs-tools/initramfs.conf

確定以下幾個參數:
BOOT=nfs
DEVICE=eth0
MODULES=most


首先最關鍵的是 BOOT=nfs,不設這項,則開機後會出現「/dev/nfs does not exist」,反過來如果設了,則會無法硬碟開機。

接著是 DEVICE=eth0,這裡要設定相對應的網路裝置,沒設對則開機後會造成在網路卡的位置死掉!

再來是 MODULES=most,這項可以改成 netboot,改成 most 則所有 module 都會載入。

存檔後執行
update-initramfs -u

完成後即可用diskless的系統開機了。

2009年2月3日

關於「有趣的預言&先知」

因應原網站作者早先留言,該文已於1月初即已收編,
未來該文將不再登載,原文連結將永久無效,
在此公告。

原作者留言如下:
============================
您所說的都不是根據事實
雖然發表個人文章實屬言論自由
但由於您的部分發言已經涉及到刑法上之
[譭謗罪][造謠罪][人身攻擊]
並讓該廟負責人及信眾深感不悅
本網已拍照存證
望君一個月之內拿下此篇文章
不然我們將偕同網警採取法律途徑
感謝您的合作
============================

2009年2月2日

自力開發的Java FTP Server

去年年底忙完國科會計劃書之後,就開始發瘋的用Java寫FTP Server,過年期間同樣沒有懈怠,持續發瘋中~

既然是發瘋的成果,自然成果驚人。

我寫的FTP Server取名叫做「MyFTPBox」。

和其他自己寫得程式一樣,在開發時有注意使用的套件授權。
目前MyFTPBox使用的第三方套件只有SQLiteJDBC,這個SQLite的Java API授權是BSD,非常自由。
因此目前來說,產權沒有任何問題。

MyFTPBox目前已經支援下面功能:
1. 完全支援 UTF8,啟動時偵測系統的檔案編碼,並以此作為預設編碼,FTP Client登入後,可以使用OPTS UTF8 ON支援UTF8(Linux下由於預設都已經是UTF8編碼,因此FTP Server預設編碼直接是UTF8)

2. 經過簡單的測試,看起來能夠正常支援MODE ZMODE Z是一種壓縮技術,使用zlib作為壓縮的演算法,它會在資料傳輸過程中自動壓縮,不需要額外設定,但FTP Client同樣需要支援MODE Z,目前用CuteFTP Pro、SmartFTP測試,在使用MODE Z後,CuteFTP ProSmartFTP仍舊能夠正常的顯示出檔案列表,證明應該是work的

3. 流量控制,每個使用者能夠設定流量限制,但目前只能對每個連線限制流量,例如我限制10k,當同時下載2個檔案時,2個檔案都是10k

4. 極端混亂且可能有問題的虛擬檔案系統,我仿照ZFTP Server的模式設定,可以新增虛擬目錄,也可以把實體目錄對應到虛擬目錄下,但目前還有些bug(混亂原因在於,ZFTP那應該是用linklist寫的,我是用SQL寫的,SQL上資料都是平面的,而且因為欄位的關係,目前我處理目錄的方式很笨,寫得也亂)

5. 帳號管理、虛擬檔案系統均使用SQLite管理,因為都使用SQL code,因此未來很容易可以移植到mysql、M$ SQL Server,甚至M$ Access中,至於Server的設定,由於要可以指定使用的SQL Server和帳號密碼等,目前傾向另外用xml來儲存,用xml儲存的設定應該會包括Server Port、Admin Port、SQL、系統編碼

6. 簡易的Telnet管理介面,目前有實做了管理用Telnet Admin Server,目前可以用telnet的方式連入進行帳號、虛擬檔案系統的管理,未來畫出GUI的管理程式後,就可以有類似ZFTP Administraotr Interface那樣的管理程式來操作了。

7. 其他比較值得提到的,大概就是PASV/PORT mode,正式一點的FTP Server原則上都支援了,只有那種超小型的FTP Server半成品才不支援PASV mode,我的Java FTP Server能夠正常的支援PASV/PORT mode;此外,大概就是檔案列表吧~目前我的Java FTP Server支援UNIX Style檔案列表和MLSD/MLST Style檔案列表,這也是比較正式的FTP Server原則上都支援的(UNIX上的FTP Server有可能只支援UNIX Style)

整體來說,基於老王賣瓜的心裡,我認為這FTP Server還不錯,不過還需要花很多時間繼續加功能和修程式,但以功能性來說,目前Windows上主流FTP Server有的幾個功能都有支援了,不過都不夠完善就是了。
那最容易被問到的就是,既然都有了,那寫它幹嘛?它作用是?
首先,它就基本的FTP Server來說算是完成度很高的,它再加入SSH Tunnel的功能後,可以寫成類似Tunnelier這樣的SSH Tunnel程式,並且和Tunnelier一樣可以作到FTP-SFTP-Bridge的功能。
而目前Java的SSH Tunnel API很多,而且幾乎都是BSD、LGPL的,要開發Java版的SSH Tunnel並不難。
除了可以延伸寫成支援FTP-SFTP-Bridge的SSH Tunnel外,它算是我第一個檔案傳輸伺服器的程式,基本樣式完成了,未來要改成影像串流或其他檔案傳輸用的Custom Server都可以節省伺服器開發的功夫。
而這套Java FTP Server本身可能的賣點是,雖然在Windows上FTP Server選擇很多,像ZFTP Server、FileZilla Server、G6都是常見的選擇,我也是以它們為範本開發的,但首先,ZFTP Server在3.0之前都還不支援UTF8,G6要錢,FileZilla Server的管理介面非常難用。
其次,我們把場景放到Linux上,Linux上的FTP Server幾乎都強調高效能、高穩定性,但是很少可以像ZFTP Server、FileZilla Server這樣有虛擬檔案系統可以讓我們自己拉目錄,使用者管理又幾乎都跟系統帳戶綁在一起,不用系統帳戶,就要透過複雜的步驟讓FTP Server支援mysql。
對大部分人來說,僅僅希望在Linux上安裝個FTP站台,專門放mp3、動畫這樣簡單的需求,卻要搞得好像要開ftp.ntu.edu.tw這樣的大型站台。
然而對於一般性的需求,像是頻寬限制,帳戶登入時間管制之類的,卻要辛苦的k 使用手冊,找設定找半天才能作到,如果以這樣的角度來看,我認為我這套Java FTP Server是有賣點在的,因為它跨平台,又以Windows FTP Server為範本,用在Linux上反而能凸顯出它的特殊性,像MODE Z,Linux上有多少FTP Server支援它?應該很少吧~

PS:
最後附註一下,一直以來Java都號稱對網路程式開發可以很容易的設計,我一直都對此疑惑,但這次寫FTP Server,我發現Java在開發FTP Server時,其實滿容易的,Java本身幾乎支援FTP Server所需的所有功能,像MODE Z的核心zlib,Java直接就有InputStream、OutputStream可以套用,套上去就有了,像UTF8也是,直接套個InputStreamReader加個編碼就搞定了,同樣是開發FTP Server,我相信用gcc和glibc應該會複雜很多,光要把zlib library套進socket stream應該就有點麻煩了,再處理UTF8和non-UTF8應該也不是輕鬆的事。

Office 2007專用的2003選單外掛

最近把家裡自己的桌機改安裝成WinXP Pro,也許會納悶~是「XP Pro」嗎?
是的~我自己的桌機之前一直都是Win2000 & Ubuntu雙系統。
前陣子Ubuntu用比較多,這陣子Windows用比較多,兩個系統適應的都不錯。

由於Win2000沒有終端機服務,MSN又只能用可憐的7.5,加上這台電腦CPU是P4-2.4HT,卻因為Win2000對HT支援並不好,始終有個疙瘩在,因此這次過年就把他更新成XP Pro了。

因為更新成XP Pro,C碟有了很大很大的空間,所以也一併把Office從2003升級成2007。

眾所皆知的,M$不知道發甚麼神經病,把Office2007的選單介面換了,更神經的是,它竟然不提供2003選單樣式,強迫可憐的芸芸眾生只能一邊幹一邊接受(XP至少都還提供所謂的「Windows Classic Theme」)。

不過沒關係,我們廣大的網際網路,萬能的Google給了我們選擇其他選擇。

用Google以「office 2007 classic」進行搜尋會發現,大概有2~3套的國外套裝軟體提供了這樣的功能,只要安裝它並輸入序號,就能夠變身成原來2003的樣式。
如果有人跟我一樣對正版軟體有奇怪的執著,沒關係,這裡提供了一個免費的選擇,和其他自由軟體、免費軟體一樣,要好好感謝開發的作者。
Excel Add-ins這個網站作者特別針對Office2007的Word、Excel、PowerPoint、Access開發了增益集外掛,只需要下載並直接點選執行它,它就會彈出視窗問你,是否要啟用這個「看起來很危險的增益集」,二話不說,啟用它~
重新開啟程式後就會看到選單多了一項叫做「增益集」,點它之後就會看到下面出現一排熟悉的選單。

我個人覺得相當不錯,讓我很方便的就能夠適應Office2007的操作。

至於XP Pro和Office2007怎麼來的?
相信許多人都知道去年M$有提供Office2007的學生方案(話說~這應該是因為Office2007銷售太差,普及率太低的原因才提出的吧...),身為對正版軟體、免費軟體有奇怪執著的我,就以自己和老妹的名義各買一套。
至於XP Pro,最近因為M$好像要淘汰XP了,XP Pro教育版價格跟之前隨機版、升級版一樣,而隨機版、升級版都不見了,擔心未來買不到XP,因此砸錢買了一套。

至於身為Linux/FreeBSD愛好者兼免費軟體愛好者的我為啥要花錢贊助M$?
相信我,目前的XP(Win2000)、M$ Office還是有非常大的必要性,OpenOffice我不是沒在用,但因為一堆原因,它跟M$ Office就是無法完全相容,可我老闆、國科會範本、學校論文範例,都是用Word格式,在這個看老闆看學校吃飯的環境下,我也只能低頭了。
至於Linux上的wine?相信我,它對M$ Office的支援只是「不錯」,並不是「非常好」,原因包括:
1. 像我有在使用Zotero管理參考文獻,WINE的M$ Office沒辦法支援
2. WINE的M$ Office甚至不能按「ctrl + s」進行存檔動作
3. 因為WINE的中文需要額外設定,也因為額外設定的關係,M$ Office顯示的字型會和一般Windows上的Office不大一樣(設定會有些差別),讓文件看起來就不同會不一致

PS:
我會因為遠端桌面而改用XP也許看來有點可笑,不過我有原因。
目前在Windows上,效能最好、支援性最好、各平台都有Client程式的,只有俗稱遠端桌面的終端機服務
有跨平台能力的,多半直接想到VNC,我之前win2000時的確都是用VNC,不過我相信任何用過遠端桌面的人,只要用一次VNC,就會直接移除了。
VNC底層不是用DirectX寫的,因此無法像終端機服務可以遠端直接看影片,VNC也不支援音效功能,沒辦法遠端聽音樂,在棒球8搶3轉播時,我不少同學用遠端桌面直接連到宿舍,用電視棒看轉播,邊看還會邊說,影像有點lag,但這在VNC上,是完全辦不到的。
VNC檔案傳輸能力很弱,到現在~只有Windows上的VNC可以傳檔案,而且是一個檔案一個檔案傳,還要用類似FTP那種選單來傳輸,遠端桌面整合網路芳鄰,非常方便,離譜的是,Linux上的遠端桌面client(rdesktop)也支援這能力,可以把Linux的「/」對應到遠端桌面上。
此外,不知道是不是VNC protocol不好,幾乎所有用VNC核心的遠端遙控,感覺效率都不好,反應鈍鈍的,吃頻寬又兇,而且解析度差、畫面常常不會更新
至於其他的遠端遙控程式,多半都還是小眾市場,大多只提供Windows的client,Linux上無法操控。
而以遠端遙控軟體來比較,不論Windows、Linux,M$的終端機服務整體來說,相當的優秀,它吃使用的頻寬小,因為使用圖示快取,畫面品質很不錯,加上前面提到的它直接用DirectX,影像、聲音都能通,而且品質非常好,它甚至能把遠端的Printer Port、Serial Port對應過來,要達成這些條件的遠端遙控軟體真的不多,在Linux上,我認為只有NX最接近,但NX目前還無法處理影像,聲音部份會lag大約3秒。

補圖:
Word 2007


Excel 2007


PowerPoint 2007