手机电视(DVB-H)软件接收器

图9 section封包处理延迟时间示意图

5、 实验模拟结果

本研究整个实验模拟结果均是利用个人计算机（PC）进行测试，个人计算机的配备如表4所呈现，并以公视试播计划所提供的传输串流当作是播放测试档案，而表5则是从公视所提的串流档案撷取出来的信息。

5.1正确性验证

本研究纠错后的数据验证是利用文字处理软件Ultra-Edit所提供的二进制档案比对来完成，分别将添加错误的每个Burst数据与修正后的数据存成档案后再与验证档案进行比对。

5.2效能评估

本文的MPE架构与Time-Slicing传输机制设计主要采用[4]的观实作观念与架构，[4]中对每个Burst数据（仅有针对MPEsection）的处理时间已有相当完整的分析信息，故本论文即针对主要设计的MPE-FEC纠错机制做实作上的效能分析与探讨。

表4个人计算机基本配备表

处理器厂牌规格
Intel Pentium 4

处理器处理速度
3.0 GHz

硬盘大小
80 GBytes

内存容量
512 MBytes

表5公视影像来源参数数据

参数
数值

档案大小
755,605,652（bytes）

封包总数
4,019,179（封包以188个bytes为单位）

MPE-FEC框架总列数
512列

Delta-T
1250 ms

Delta-T Jitter
7.5 ms

最大Burst持续时间
200 ms

省电效率
79.7%

每秒画面更新速率
15 （frame per second,

整个传输流档案中，每个Burst所挟带的框架大小为255×512，而框架资料量大小为1Mbits（128kBytes），每个MPE-FEC框架执行的RS纠错运算次数为512次（即每一列执行一次RS纠错运算），编码率（coderate）为2/3的情况条件下，10个Burst、50个Burst与100个Burst单纯使用Java以及RS译码采用Euclid算法在Windows上的完整MPE-FEC纠错机制与单纯RS译码的平均执行时间如图13所示。

图13完整MPE-FEC机制运作与单纯RS解码的平均执行时间

由图13可知整个MPE-FEC机制的运作时间大多花费在RS译码上，因此本研究进一步将RS译码使用C/C++并且使用RS内部不同的译码算法透过Java的JNI（JavaNativeInterface）呼叫在Windows上执行完整的MPE-FEC机制，其执行解果如图14所呈现。

图14Java与C/C++以及不同算法在Windows上的平均执行时间

虽然就执行时间上来看，使用C/C++并采用BM算法的译码时间较短，但对于表5所撷取到的Delta-T时间（1250毫秒）而言，仍无法达到DVB-H接收端的实时播放。因此，再进一步测试在Linux系统上不同算法的C/C++语言执行时间并与Windows的执行时间汇整而得到图15。

图15不同操作系统下，C/C++使用不同算法的执行时间

在Linux操作系统上执行完整的MPE-FEC机制运作后所得到的平均执行时间均小于在Windows上的执行时间。此外，使用BM算法在Linux与Windows上的执行时间更相差约略2.5秒，并且已能符合DVB-H接收端实时播放的时间要求。

最后在Windows将测试档案加入错误后，再透过本研究所设计的软件系统进行纠错之后所得的数据存成档案再进行播放。

6、结论

本研究利用纯软件的方式来仿真实作DVB-HMPE-FEC纠错机制，并确实能修复还原添加于测试档案中的错误，虽然于Windows操作系统上的数据处理时间已超过实时播放的时间要求，但在Linux上采用BM算法的RS译码测试实验结果，却已符合实时播放的限制条件。因此，以系统的执行时间及实时播放的角度来看，对于往后的软件设计实作，在Linux上实现，或许会比在Windows上更为理想。