Convert DVD VOB to TS by DGMPGDec + tsMuxeR

What is DGMPGDec?

DGMPGDec is an MPEG decoder suite. It is used to decode MPEG1 or MPEG2 streams from such sources as DVD VOBs, captured transport streams, *.mpg/*.m2v/*.pva files, etc. Perhaps its most common use is in decoding VOBs from DVDs.


What Do I Need to Use It?

You need the DGMPGDec package and Avisynth. First get Avisynth 2.5 (or better) and install it:

Avisynth

Homepage: http://sourceforge.net/projects/avisynth2/

Download latest install package from the homepage

DGMPGDec package
Homepage: http://neuron2.net/dgmpgdec/dgmpgdec.html

Version 1.5.8 is the latest full released version. Note that binaries are no longer provided due to potential MPEGLA licensing liabilities. You'll have to build it yourself, or find binaries elsewhere. One place where the binaries can be found is: http://hank315.nl/.

You are going to use DGIndex.exe and DGDecode.dll from the DGMPGDec package, so extract them from the ZIP file and put them together in a directory.

DVD VOB file

DVD video file is with extension .vob. You are going to demux the Video and Audio stream contain in the VOB file.
I will use the Dobly Digital opening .vob which exist in many DVD as an example of this exercise.


OK. Now What?

Fire up DGIndex. Using File/Open, open your VOB. You should see the video. Now select Audio/Output Method/Demux All Tracks. That will cause your audio to be saved in a file(s) when you save the project.

Click "File" > "Save Project and Demux Video"

My test vob detail:
DD_Opening.VOB

Video
ID                               : 224 (0xE0)
Format                           : MPEG Video
Format version                   : Version 2
Format profile                   : Main@Main
Format settings, BVOP            : Yes
Format settings, Matrix          : Default
Duration                         : 31s 465ms
Bit rate mode                    : Variable
Bit rate                         : 7 182 Kbps
Nominal bit rate                 : 8 000 Kbps
Width                            : 720 pixels
Height                           : 480 pixels
Display aspect ratio             : 4:3
Frame rate                       : 29.970 fps
Standard                         : NTSC
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Interlaced
Scan order                       : Top Field First
Compression mode                 : Lossy
Bits/(Pixel*Frame)               : 0.693
Stream size                      : 26.9 MiB (93%)


Audio
ID                               : 128 (0x80)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Duration                         : 31s 584ms
Bit rate mode                    : Constant
Bit rate                         : 384 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Side: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Compression mode                 : Lossy
Stream size                      : 1.45 MiB (5%)

DGIndex will generate a .m2v and .ac3.
DD_Opening.demuxed.m2v

Video
Format                           : MPEG Video
Format version                   : Version 2
Format profile                   : Main@Main
Format settings, BVOP            : Yes
Format settings, Matrix          : Default
Duration                         : 31s 534ms
Bit rate mode                    : Variable
Bit rate                         : 6 911 Kbps
Nominal bit rate                 : 8 000 Kbps
Width                            : 720 pixels
Height                           : 480 pixels
Display aspect ratio             : 4:3
Frame rate                       : 29.970 fps
Standard                         : NTSC
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Interlaced
Scan order                       : Top Field First
Compression mode                 : Lossy
Bits/(Pixel*Frame)               : 0.667
Stream size                      : 26.0 MiB (96%)

DD_Opening T80 3_2ch 384Kbps DELAY 0ms.ac3

Audio
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Duration                         : 31s 552ms
Bit rate mode                    : Constant
Bit rate                         : 384 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Side: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Compression mode                 : Lossy
Stream size                      : 1.44 MiB (100%)


tsMuxeR
Homepage: http://www.smlabs.net/tsmuxer_en.html


SmartLabs tsMuxeR – the software utility to create TS and M2TS files for IP broadcasting as well as for viewing at hardware video players (i.e., Dune HD Ultra, Sony Playstation3 and others). tsMuxeR is a part of SmartCONTENT, content preparation solution.

SmartLabs tsMuxeR is a freeware.

Download tsMuxeR_1.10.6.zip, extract and run tsMuxerGUI.exe.

Add Video and Audio to tsMuxeR

* Rename DD_Opening.demuxed.m2v to DD_Opening.m2v, otherwise, tsMuxeR cannot recognize the video, maybe it interpret the extension as .demuxed instead of .m2v

Drag and drop DD_Opening.m2v and DD_Opening T80 3_2ch 384Kbps DELAY 0ms.ac3 to tsMuxeR.

Click "Start muxing" to start muxing.

The output TS detail:
DD_Opening.ts

Video
ID                               : 4113 (0x1011)
Menu ID                          : 1 (0x1)
Format                           : MPEG Video
Format version                   : Version 2
Format profile                   : Main@Main
Format settings, BVOP            : Yes
Format settings, Matrix          : Default
Codec ID                         : 2
Duration                         : 31s 565ms
Bit rate mode                    : Variable
Bit rate                         : 7 058 Kbps
Nominal bit rate                 : 8 000 Kbps
Width                            : 720 pixels
Height                           : 480 pixels
Display aspect ratio             : 4:3
Frame rate                       : 29.970 fps
Standard                         : NTSC
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Interlaced
Scan order                       : Top Field First
Compression mode                 : Lossy
Bits/(Pixel*Frame)               : 0.681
Stream size                      : 26.6 MiB (90%)


Audio
ID                               : 4352 (0x1100)
Menu ID                          : 1 (0x1)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Codec ID                         : 129
Duration                         : 31s 552ms
Bit rate mode                    : Constant
Bit rate                         : 384 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Side: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Compression mode                 : Lossy
Stream size                      : 1.44 MiB (5%)

Have fun! :)

[百佳泰技術文章] Android裝置的開發挑戰：軟硬體如何巧妙整合

隨著科技的快速演進，現代人對行動通訊、無線上網與多媒體娛樂的需求更甚以往，所謂的智慧型手機（Smart Phone）便成了炙手可熱的個人消費電子產品之一，從Apple不斷推出iPhone企圖顛覆消費者對手機的想像、RIM推出主打商務功能的黑莓機、Google的Android系統讓眾家手機廠商爭食大餅，到微軟屢敗屢戰的從WinMo一路開發到WP7，智慧型手機的這塊戰場可說是打的如火如荼。然而在這些眾家競爭者中，Android可說是目前行情看俏的一套作業系統，以國際市調研究機構Gartner最新出爐2010年第三季的調查為例，採用Android作業系統的智慧型手機在過去一年以來成長幅度最高，光是市佔率便是前一年同期的七倍之多，銷售量更是達到14倍的成長，同時也一舉從市佔率排名的第六名竄升到第二名。而在今年一月份甫落幕的國際消費性電子展（CES），也處處可見各式各樣採用Android作業系統的產品。

＊Gartner 2010 Q3 Worldwide Smartphone Sales

Android在過去一直扮演後起之秀的角色，切入智慧型手機的速度似乎慢了蘋果的iOS一步，但與Apple相同的是，它也成功的將其應用從手機移植到了平板電腦（Tablet PC）上。Android開放原始碼（Open Source）的特性，能輕易地提高廠商對自家產品的接受度，更不用提背後Google的強力撐腰能帶來多大的經濟效益。目前可見包括手機廠商HTC、Motorola、SAMSUNG，以及電腦大廠HP與Dell等皆投向Android的懷抱，Android被廣泛應用可說是勢在必行。

儘管Android系統的普及看似指日可待，但在實際的產品應用上，也有其可能產生的問題風險。Android作為一個開放式的作業系統，是Google提供廠商的作業系統參考架構（reference design），廠商能有充足的發揮空間，以Android為基礎向上開發設計自家產品，但也因為這樣的開放性與自由性，讓廠商在軟硬體結合的這個環節必須下更大的功夫，像是如何挑選合適的硬體包括基頻處理器、通訊晶片、觸控感應晶片、天線與記憶體模組等，以及如何調整出最適當的軟體設定等，更重要的是如何將軟硬體整合，開發出差異化的產品。這中間所有的細節都會對產品最終樣貌產生莫大的影響，像是其功能的完整度、使用介面的設計、效能表現（例如觸控滑動畫面、開啟程式所需時間）、品質可靠度、甚至是後續的韌體升級動作等等。在此百佳泰便試圖以專業中立的測試實驗室角度，來點出廠商應用Android於手機、平板電腦或其他裝置時應注意的開發重點，以希冀作為一個有效的參考資訊。

解構Android基本技術架構

首先我們先來看到Android的基本技術架構，Android是以Linux為核心，並採用軟體堆疊（software stack）的架構延伸發展的一套軟體平台與作業系統。根據下圖可以看出，其基本架構分為五層：

＊Android Structure by Google

• Linux核心（Linux Kernel）：以Linux開發提供最底層的核心系統服務，包括安全性 (Security)、、記憶體管理(Memory Management)、進程管理(Process Management)、網路堆疊(Network Stack)與驅動程式模型（Driver Model）。
• Android執行環境（Android Runtime）：透過Core Libraries(核心函式庫)以及暫存器型態的Dalvik Virtual Machine(Dalvik虛擬機器)來執行程式。
• 系統函式庫（Library）：使用C/C++函式庫的系統元件以供呼叫使用，開發者可透過上層的應用程式框架來運用這些功能，這也是主要Android裝置的效能關鍵。
• 應用程式框架（Application Framework）：被設計來簡化元件的再運用，開發者能完整存取使用與核心應用程式（Core Application）相同的API，應用程式可以發佈功能並為其它應用程式所使用（需受限於其安全性限制），開發者也可運用同樣的機制來新增與置換元件。
• 應用程式（Application）：所有Android應用程式皆是以Java程式語言編寫，原始就會包含像是Email、簡訊、日曆、地圖、瀏覽器、聯絡人等其它應用程式，讓使用者一開始就擁有這些基本功能，開發者也可在此客製其使用介面。

廠商越想要設計出與原始設定不同且增強效能的產品，便越需要對這五層架構進行修改。譬如像是多工處理能力（multi-tasking），便可能需要修改包括Linux核心與應用程式框架的設計；而應用程式的開發者更可能需要針對應用程式與框架進行調整。由此可見，對Android裝置而言，任何一個功能的置入或是對硬體設定的細微更動，都需要對Android系統進行從下到上的調整以達到最優化的效能，而這正是最為困難與需要驗證的一環。

Android裝置軟硬體整合的五大技術環節

如前所述，對眾家開發廠商而言最大的挑戰其實在於，如何將自己理想的產品訴求，與Android系統巧妙結合成一個功能完整並使用流暢順手的產品，這其中牽涉了不同技術間的整合與運用。在此我們便根據其多年的測試與研究經驗，歸納出五大Android相關裝置在技術整合上的重要環節：

一、Linux驅動程式的導入

由於Android是根源於Linux所延伸出來的作業系統，因此各種關鍵功能的驅動程式也必須要能順利的寫入其中，舉凡像是字元裝置、記憶體的空間配置、中斷處理、網路通訊、螢幕顯示或是連接介面像是USB與PCI的驅動程式，這些可能是自行撰寫、或是來自不同元件廠商的驅動程式，都必須要能被導入到Android系統，並維持良好穩定的效能表現。

二、系統單晶片的優化處理

對廠商而言，開發一款Android裝置，不僅僅只是將所有零組件組合成為一個產品那麼容易，最大的學問便在於將系統單晶片（System-on-a-chip，SoC）、各種新技術和Android系統進行整合，SoC涉及像是Dalvik Virtual Machine、OpenGL、V8、Webkit Engine等上層的演算，與Android間的結合便必須透過不斷的嘗試與驗證，才能研發出既符合成本效益、又有良好效能的優化產品。目前市面上有些SoC廠商已針對Android系統的特性，提供整合過的SoC平台，將藍牙、相機或上網等常用功能模組預先寫入，減少終端成品廠商費力整合開發的時間，但對廠商而言，這樣的預先整合是否適合自身產品，以及是否需要再作更細緻的修改，則又是更困難的課題。

三、新技術的移植

隨著技術的快速發展，更多新興的技術規格也逐漸應用在手機等手持裝置上，以手機為例，已經從過去以撥打電話為主要功能，轉變為擁有各種多樣化用途的產品。像是觸控技術讓消費者可以透過手指的滑動傳送指令甚至是具備多點觸控的支援、Wi-Fi模組提供隨時無線上網的可能、通用圖形處理器（General-purpose computing on graphics processing units，GPGPU）則能以並行方式透過圖形處理器來執行通用計算任務、Android 2.3版所支持的NFC近場通訊技術，以及更高階的相機模組等等，背後都有各自的驅動程式與軟體技術，也必須要與Android系統相結合使用。

四、效能表現的穩定

儘管上述這些技術不斷推陳出新，但也都不能因此而犧牲裝置原本的效能表現，讓處理速度因此變慢或造成使用上不順暢的狀況。除了採用更好的硬體設備外（例如現今處理器的時脈已邁向1GHz），更需要作業系統的支持，像是如何在多工運作的狀況下維持程式執行速度以及系統滿載的處理等等，都必須要透過軟體面的奧援。也就是說，一台Android裝置除了要能將各種功能與技術收納起來、將軟硬體整合外，更必須同時注重它在效能上能否維持應有的水準，以提供使用者在操作上流暢易上手的感受。

五、低電耗設計

Android的設計概念主要是應用於可攜式裝置上，目前市面上可見的像是平板電腦與智慧型手機等。對這類產品而言，電池續航力的好壞可說是影響消費者使用感受的關鍵之一，試想，若是一台智慧型手機的待機時間過短，而使用者在外時又無法隨時充電使用，不能即時的連網查詢資料或執行其他手機功能，這樣的產品便失去了它作為可攜式行動裝置應有的便利性。追根究底，良好的待機時間除了需仰賴高容量的電池以提供充足電力之外，另一個重點就是裝置本身在被使用執行時能否作到低電耗設計。Android裝置讓使用者能透過各種多樣化的應用程式，來達到各種不同的使用目的，舉凡像是單純上網、觀看新聞、郵件推播或是遊戲等等，各種不同功能的程式都能透過自由下載使用，也由於其多工處理與讓程式背景執行的能力，更讓降低耗電量成為開發者不可輕忽的一項課題。

持續驗證修正 找出最佳Android整合方案

正如前面我們不斷提到的，對Android裝置而言，最困難的開發挑戰便在於如何完美地”整合”軟體與硬體，以開發出一項功能完整又同時注重使用者感受的產品。從對Android本身程式碼的修改、相關硬體的選擇，到驅動程式的結合運用以及能否維持穩定的效能表現等，在在都必須要透過仔細的研究與不斷的嘗試，才能找出問題的根源並解決、更進而找出最合適的整合方案。

附圖我們歸納出一些在Android裝置上經常出現的問題與其可能肇因，而這些也都是開發廠商必須重視卻可能忽略的一環。像是Android原始碼中對音源的重新取樣（Re-sampling）設計，就會導致裝置在讀取48K音源時重新取樣成44K，而造成諧波失真的現象影響音質，這便是廠商不會注意到而未去修改的問題；另外像是天線位置的設計，也可能直接的影響到收訊能力的好壞；而不良的電源管理設計，也極有可能影響到裝置在持續使用狀態中的耗電情形。百佳泰在此僅以專業測試驗證實驗室的角度，希冀以宏觀的方式，針對Android裝置的開發設計提供可用的參考，近期內我們也將會提供實際的相關測試數據報告，並進一步指陳這些可能的問題風險，以期讓更多廠商與消費者都能注意到品質驗證的重要性，是從產品設計的根源就要開始層層把關。

（本文由測試服務暨諮詢顧問公司百佳泰Allion Test Labs, Inc提供）

[Mercurial] Export and Import CS by bundle/unbundle

1. Bundle a changeset
Suppose the project have 2 developer A, B, working on a common base, then make their own change in their local working directories.
After B fix a bug and commit to his local repository (but havn't pushed to main), and A want B's changes, B can create a bundle for A by:

$ hg bundle -r BUG_FIX_CSID --base BASE_CSID b_changes.hg

2. Sending the bundle
These bundle files can then be exchanged via email attachments, FTP, USB drive, etc.

3. Unbundle, Update and Merge
After A received b_changes.hg, A can unbundle the file to A's local repository by:

$ hg unbundle b_changes.hg

This will create a new head.
A need to "hg update" to update A's working directory with B's bug fix which has been pull/import/unbundle to A's local repository.

Then A can see B changed files by "hg status", "hg diff", then merge by "hg merge".
Finally, "hg push" to main repository.

2011 新年快樂 HAPPY NEW YEAR !!!