晚上和LAB的人一起吃飯
學弟小虎說，今天學校餐廳看起來好冷清
隨便一瞧 今天餐廳真的頗冷清
平常熱門時段要搶的座位今天做不到四分之一滿
五個宅宅默默的各自去買飯來吃
然後老頭就說了
今天是三大ㄕ(ㄙ) ㄕㄣ(ㄥ)日呀
我心中OS了一下 三大私生日...嗯
私自慶生的日子嗎??!!
名義上慶祝行政紀念日但實際是聖誕節降?!
還沒說話小虎就問了
師生日
餐廳人少老師學生怎麼了 ?
你今天ㄕ(ㄙ) ㄕㄣ(ㄥ)了嗎?!
解答是大一女學生三大失身日
九月入學後..12/25第一大
緊接著過情人節
第三大是女生的生日
所謂三大失身日...
講解完畢
五個宅宅默默的繼續吃飯
炎之男為灌籃高手片尾唱的「直到世界的盡頭」
單行本破一億本的熱血漫畫
籃高手沒有續集，這是作者井上雄彥自己說的。所有看到的“續集”都是同人，井上雄彥只是在去年灌籃高手單行本銷量突破1億冊後，為了感謝讀者在一所學校的 幾十個教室的黑板上畫了叫做《十日後》的漫畫，講的是全國大賽結束十天后每個人的情況，開放參觀。畫得相當好，很感動，雖然有些意外，但相信是灌籃高手的 終章了。曾經期待井上“十年一夢試續章”，如今只是如此平淡的一個結尾。
2004年12月，為了紀念《灌籃高手》累計銷售突破一億冊，井上雄彥以其公司“I.T.Planning.Inc”的名義，在神奈川縣一所廢棄的中學教室的黑板上，用粉筆畫了23間教室的黑板。描述了IH比賽結束十天之後，那些籃球少年們的生活瑣事。
從1990年《SLAM DUNK》第1話開始連載，至1996年第276話完結，六年時間，一個叫井上雄彥的青年創造了一個神話。2004年8月，《SLAM DUNK》以短短31卷成為日本第四部銷量達一億冊的漫畫作品，在滿載盛譽的同時，更多的是勾起了人們濃濃的懷念。90年到04年，十四年的時間足夠一個 兒童成長為步入社會的青年，足夠一個少年去夢想去奮鬥直至成家立業，足夠井上雄彥的作品從熱血少年漫畫轉型到深刻的《浪客行》，也足夠我們遺忘曾經的一切 不成熟。
然而，我們仍然熱愛並期盼著井上先生時隔八年後的筆下，那些不曾老去的容顏。
<基本上十日後畫的沒什麼重點 影片是從黑板翻下來處理過後的成品>
原本一個學弟在玩
後來和另外令兩個學弟一起組團玩
免錢的 好不好玩說不上來 T.T
至少有伴玩起來還OK
介面設計的有點不是很順 3D畫面轉來轉去的ˊˋ""
我在第17伺服器 通常會上第七分流
角色兩隻
10級的H.264小杯杯 戰士一名 取名是因為另兩個學弟叫H.264、H.264DrJ
11級的魔法師 女乃火包奚隹 一名
衣服那邊綠色的字是學弟的帳號 肉盾 奚隹 女乃 火包
還有一個學弟刺客是 火包女乃奚隹.. 
歡迎大家來17服..
今天要準備歡迎第四為兄弟!!!
女乃奚隹火包 Get!!!!
加入
四兄弟團體照..
[文字引用]PTT bear0914大
Matt Harding，1976年次的年輕人，
他在2003年用他所有的積蓄去旅行，
在旅行中只是一個簡單的想法，用跳舞記錄他到過的每個地方，
而他都把所有的紀錄放在自己的網站，
當初網站也只是要讓他的親人與朋友知道他在外一切安好。
後來有人發現了這些影片並開始傳閱，
於是有家口香糖廠商覺得他的構想很棒，贊助他旅遊經費，
因此在2006年他花了六個月走遍了39個國家，
接下來的2007、2008年他依舊到世界各地跳舞（包括了台灣），
而且還有了許多的同伴共舞。
Matt跳的舞很滑稽，但是他的笑容與熱情卻是讓人感動，
他只是一個簡單的動作、簡單的想法改變了他的一生，
至今他已經去了63個國家！
它的網站：
http://www.wherethehellismatt.com
最近拍的VISA廣告
用哭砂做兩個活動的代表感覺
真的有點莫名其妙=ˇ=
候選歌曲還有忠孝東路走九遍、最甜蜜的事..
好糟 囧.....
第一次聽到小拆唱KTV 果然迷人
也許該是克服一下討厭唱歌的情緒@"@
對我來說 不想開口唱歌那種感覺到底是什麼時候養成的呢..?!
未唱先哭哭呀....哭哭..
每個夥伴都往前走了
我呢??
女孩把自己的青春與未來經營的很好
我呢..??
出去玩抽了一籤 是個好籤呢..
薛仁貴救駕
福如東海壽如山 君爾何須嘆苦難 命內自然逢大吉 祈保分明自平安
我的福阿 壽阿 是我努力來的嗎..??! 
從Im Vlog畢業了
YouTube我來了~
--
某個PTT看到別人的簽名檔
對流血一週仍然不死的生物千萬不能大意……
0.0
2003年5月，當 H.264編碼標準草案發佈時，很多人都覺得H.264太複雜，不宜實用。眨眼間3年過去了，以往的論斷、疑惑被如今的現實沖洗的乾乾淨淨。隨著硬體性能的提高和視頻編碼工作者對H.264的不斷優化，如今的H.264已完全實用，最新的達芬奇晶片上能實現D1解析度(720*480)視頻的即時編碼，而 對於解碼，普通的PC機就能實現x264編碼的DVDrip電影的流暢播放。縱觀過去的三年，有多少人對H.264傾注了熱情和汗水才換來今天的成績，而 那些H.264的開源項目以及參與這些項目的開發者自然是功不可沒。
本文評測的是作者接觸過的 H.264開源解碼器，包括：JM decoder, T264 decoder, x264 decoder, ffmpeg libavcodec, Intel IPP simple player。評測的內容有：對H.264特性的支援、解碼速度以及二次開發難易程度。
一、H.264開源解碼器介紹
1、JM decoder
JM decoder是H.264的官方源碼，通常也稱為校驗模型。其特點是支援特性好，實用性差。本文選用的程式是JM86，不支持high profile，因為本文不對high profile部分進行實驗比較。
NOTE: JM一直沒有做實用化方面的努力，所以其解碼速度代表的是2003年的水準。
2、T264 decoder
T264是國內的開源項目，T264 decoder的程式做過彙編優化，速度還可以，但只能解T264本身的碼流。作者對T264 decoder version 0.14（2005-3-29）作了修改，支持baseline的解碼。
3、x264 decoder
x264本沒有decoder，但其包含decoder的部分函數雛形，猜想作者在一開始時是準備實現decoder，後來可能是因為有了ffmpeg，就放棄了這個想法（純粹屬於猜測，呵呵）。
本文的x264 decoder是作者在x264 svn check out 2005.12.26的基礎上實現的，支持baseline的解碼。
4、ffmpeg libavcodec
ffmpeg是一個大專案，它包含各種音視頻標準的codec，還支持各類file format（.avi, .mp4, .mkv and etc）的parsing。所以，很多開源項目都有直接或間接地採用了ffmpeg，如mplayer播放器就是直接採用了ffmpeg，而mpc播放器 則是先採用了ffdshow filter，而ffdshow又採用了ffmpeg。ffmpeg是一個非常棒的音視頻編解碼庫，支援的標準非常全，而且編解碼速度也很快。
本文實驗採用的是cvs check out 2006.02.20的版本，作者對其中的apiexample demo進行了簡單的修改，用於解碼h.264碼流
5、Intel IPP simple player
Intel的IPP庫，全稱為Integrated Performance Primitives，在Intel的各種處理器平臺（IA-32, Itanium, xscale and etc）上實現了信號處理常用演算法、常用數學運算及音視頻編解碼演算法等等。IPP給我的第一感覺是，在Intel的處理器平臺上，它實現的各種演算法應該是最快的，至於實際結果如何，待等到實驗比較後見分曉。
本文採用的IPP庫版本為IA32 5.1.017 評估版
Intel IPP simple player是用於播放各種音視頻檔的簡單播放器，用c++實用，具體演算法調用IPP庫來實現。本文採用的simple player版本是5.0.017
二、對於H.264特性的支援
1、JM86 decoder
support baseline, extended, main profile
2、T264 decoder
baseline
3、x264 decodeer
baseline
4、ffmpeg libavcodec
support baseline, main profile, high profile except the feature: paff, mbaff…
5、Intel IPP simple player
support baseline and main profile
三、评测条件
1、所用测试序列
2、編碼參數
編碼程式：x264 svn check out 2006.05.06
參數設置示例：x264enc --frames 300 --no-cabac --qp 26 -o test.264 foreman.cif 352x288（相當於baseline）
量化步長：26和36
2、環境
CPU: Pentium4 2.4GHz, RAM: DDR 512M
OS: windows2000 professional+sp4
3、解碼器程式編譯環境
JM86 decoder: vc71 release
T264 decoder: vc71 release
x264 decodeer: vc71 release
ffmpeg libavcodec: MinGW
Intel IPP simple player: vc71 release + directX 9.0c sdk
4、解碼參數設置
不保存重建序列（note: 是否保存重建序列對於解碼速度的影響很大）
四、解码速度比较结果
【note】
t264的解碼程式能解jm baseline的碼流，但無法解上面x264生成的碼流，故無法給出實驗結果。但通過對自身t264 fast mode碼流的解碼速度進行統計，t264 decoder和x264 decoder，解碼速度降低40％左右。
Intel IPP simple player在我的電腦上編譯未成功，在其他成功編譯的電腦（xp系統，directx, vs.net, IPP均安裝於C盤）上進行簡單測試，其解碼速度和ffmpeg的解碼速度相比，降低10%左右。
【簡單結論】
解碼速度：ffmpeg > IPP simple player > x264 decoder > t264 decoder > jm86 decoder
以ffmpeg的編碼速度為基準，假設為100fps，則：
IPP simple player：90fps
x264 decoder：50fps
t264 decoder：30fps
jm86 decoder：3fps
五、程式開發上的比較
我估計閱讀本文的大部分讀者都是搞開發的，因此，閱讀過程中自然會思考如何在程式開發上借鑒或者採用以上開源的H.264解碼器，下面就針對程式開發上的難易、適用場合等作個比較。
1、JM86 decoder
適合寫paper群體
2、T264 decoder
3、x264 decodeer
兩者代碼非常相似，所以就合在一起講了。這兩個源碼的程式結構都比較清晰，支持vc和gcc的編譯環境，但對H.264的特性支援不好，解碼速度和ffmpeg相比，還有差距。
4、ffmpeg libavcodec
程式結構比較差，H.264解碼的代碼基本上在h264.c一個檔中，這個檔有8000多行，不利於閱讀。
編譯環境為gcc或MinGW，移植到vc下比較難（我嘗試過）。
解碼速度快（BTW: 通過doom9論壇瞭解到，目前最快的h.264解碼器是CoreAVC decoder，比ffmpeg快50%左右）。
對於H.264特性的支援好。
5、Intel IPP simple player
分兩個方面講：
（a）IPP庫
我覺得是非常棒的，但實現的是H.264解碼（IPP中也有H.264編碼）的一些關鍵函數，如deblock，dct，插值補償等，不能直接拿來用。
其他的缺點：IPP庫是商業軟體，要money的，而且只支援Intel平臺
（b）simple player
開源，用c++寫的，而且是directshow編程，也就是說只支持windows平臺。
其解碼速度比ffmpeg慢10%左右，我覺得原因不在於IPP庫，而是simple player的代碼不夠完善。
