Ngoàiviệc đo lường các tham số chất lượng dịch vụ của mạng ví dụ như tốc độ tổn thất, trễ, và biến độ trễ jitter, nó còn đưa ra việc đánh giá chất lượng video một cách chủ quancho vide
Trang 1MỤC LỤC
MỤC LỤC 1
DANH MỤC HÌNH VẼ 2
DANH MỤC BẢNG 2
I EvalVid- Cơ cấu cho truyền video và đánh giá chất lượng 3
1.1 Giới thiệu -3
1.2 Cơ cấu và thiết kế -4
1.3 Các chức năng hỗ trợ -6
1.3.1 Xác định tổn thất gói tin và tổn thất khung 6
1.3.2 Đánh giá chất lượng video 9
1.4 Các công cụ -11
1.4.1 Cấu trúc dữ liệu và files 11
1.4.2 Bộ gửi video- VS 12
1.4.3 ET – Evaluate Traces 13
1.4.4 Fix Video- FV 16
1.4.5 PSNR- đánh giá chất lượng 18
1.4.6 Tính toán MOS 19
1.4.7 Nhóm công cụ thứ 3 cần thiết 20
1.5 Các kết quả để làm mẫu -21
1.6 Kết luận và các chủ đề cho việc nghiên cứu sau này -22
II Assignment 23
2.1 Mã hóa -23
2.2 Giải mã -25
2.3 Thiết lập mạng và truyền file -26
TÀI LIỆU THAM KHẢO 27
Nhóm V 1 Lớp 10BĐTVT- KH
Trang 2DANH MỤC HÌNH VẼ
Hình 1: Sơ đồ cơ cầu đánh giá chất lượng Video 4
Hình 2: Video CBR MPEG-4 với tốc độ bit đích 200 kbps 7
Hình 4: Ví dụ PSNR 19
Hình 5: Ví dụ về video được phân loại theo MOS 20
Hình 6: Ví dụ về đánh giá chất lượng video (mức độ MOS) với EvalVid 21
Hình 7: Ví dụ về việc đánh giá chất lượng video với EvalVid 22
DANH MỤC BẢNG Bảng 1: Chất lượng ITU-R và mức độ suy yếu 10
Bảng 2: Possible PSNR to MOS conversion 11
Bảng 3: Dữ liệu liên quan chứa trong video trace file 12
Bảng 4: Dữ liệu liên quan chứa trong sender trace file 12
Bảng 5: Thứ tự giải mã và hiển thị khung MPEG 17
Nhóm V 2 Lớp 10BĐTVT- KH
Trang 3I EvalVid- Cơ cấu cho truyền video và đánh giá chất lượng
Với EvalVid, chúng ta giới thiệu một cơ cấu hoàn thiện và một công cụ để đánhgiá chất lượng video được truyền trên mạng truyền thông thực hoặc mô phỏng Ngoàiviệc đo lường các tham số chất lượng dịch vụ của mạng ví dụ như tốc độ tổn thất, trễ,
và biến độ trễ (jitter), nó còn đưa ra việc đánh giá chất lượng video một cách chủ quancho video thu được dựa vào việc tính toán PSNR từng khung một Công cụ có bộ chếtạo theo kiểu modun giúp nó có thể trao đổi với cả mạng và bộ mã hóa-giải mã Báocáo này giới thiệu ứng dụng của nó cho MPEG-4 EvalVid tạo mục đích cho các nhànghiên cứu muốn đánh giá việc thiết kế mạng của họ hoặc đánh giá sự cài đặt xét về sựcảm nhận của người sử dụng
1.1 Giới thiệu
Ngày nay có rất nhiều các hệ thống viễn thông cung cấp việc truyền dẫn thờigian thực theo kiểu khác nhau, truyền video được cho là một trong những ứng dụngquan trọng nhất của hệ thống viễn thông Sự phát triển ngày càng tăng này làm chochất lượng video được hỗ trợ trở thành một vấn đề đang được quan tâm Mặc dùnhiều bài báo nghiên cứu về các cơ chế hỗ trợ chất lượng dịch vụ QoS cho cácmạng khác nhau thì vẫn có rất ít bài báo hỗ trợ việc đánh giá có tính thống nhất vàtính so sánh chất lượng thực sự thu được bằng sự cảm nhận cá nhân Trong thực tế,nhiều nhà nghiên cứu hạn chế mình để chứng minh rằng cơ chế trong nghiên cứu cóthể giảm được tỷ lệ mất gói, trễ gói hoặc biến độ trễ và họ đã cho rằng những phép
đo này là đủ để đánh giá chất lượng video thu được Tuy nhiên, người ta biết đượcrằng các tham số được mô tả ở trên không được chuyển đổi dễ dàng và duy nhất vàomột chất lượng cho việc truyền tải Video Tức là việc chuyển đổi này có thể khácnhau phụ thuộc vào phương thức mã hóa, phương thức che giấu tổn thất và xử lýtrễ/biến độ trễ
Các công cụ chung có sẵn cho việc đánh giá chất lượng video thường giảthuyết rằng các khung được đồng bộ tại phía phát và phía thu, có nghĩa là chúngkhông thể tính toán chất lượng video trong trường hợp khung bị mất hoặc các lỗi
giải mã khung Chẳng hạn như phần mềm JNDmetrix-IQ, và dự án AQUAVIT
Những công cụ này không phù hợp để đánh giá cho khung video nhận được khônghoàn thiện Chúng chỉ có thể áp dụng cho các khung video tại nơi mà mỗi khung cóthể được giải mã tại phía thu Những nhà nghiên cứu khác đánh giá chất lượngvideo khi dạng khung video bị biến dạng trong lúc truyền, không cho phép phầnmềm của họ có thể dùng được một cách công khai Theo sự hiểu biết tốt nhất củacác tác giả thì chưa có công cụ miễn phí để thỏa mãn các yêu cầu được mô tả ở trên
Nhóm V 3 Lớp 10BĐTVT- KH
Trang 4Báo cáo này giới thiệu về EvalVid Nó là một cơ cấu và một công cụ để đánhgiá thống nhất về chất lượng truyền tải video EvalVid có cấu trúc khối, làm cho nócó thể trao đổi theo ý muốn của người sử dụng cho cả hệ thống truyền tải lẫn cáccodecs Vì vậy nó được áp dụng cho bất kỳ phương thức mã hóa nào và có thể đượcdùng cả trong các cài đặt thực nghiệm thật và thí nghiệm mô phỏng Các dụng cụđược thực hiện ISO-C tinh khiết cho tính khả chuyển tối đa Tất cả các tương tácvới mạng được thực hiện thông qua hai trace files Do đó nó dễ dàng được tích hợpEvalVid trong bất kỳ môi trường nào.
Cấu trúc của bài báo này như sau: Phần 2 giới thiệu tổng quan về toàn bộ cơcấu Phần 3 giải thích phạm vi của các phần tử chức năng hỗ trợ Sau đó các công
cụ cá nhân được mô tả chi tiết hơn trong phần 4
1.2 Cơ cấu và thiết kế
Hình 1 cho thấy cấu trúc của cơ cấu EvalVid Sự tương tác giữa công cụ thực
hiện và luồng dữ liệu được ký hiệu hóa Cái gì được tính toán sẽ được giải thíchtrong phần 3 và phần 4 cho thấy nó thực hiện bằng cách nào và từ đó thu được cáckết quả
Hình 1: S đ c c u đánh giá ch t l ơ đồ cơ cầu đánh giá chất lượng Video ồ cơ cầu đánh giá chất lượng Video ơ đồ cơ cầu đánh giá chất lượng Video ầu đánh giá chất lượng Video ất lượng Video ượng Video ng Video
Cũng từ hình 1, quá trình truyền video số đầy đủ được bắt đầu từ việc mã
hóa thông tin từ nguồn, đóng gói, truyền qua mạng, giảm jitter bằng bộ đệm tái tạo,giải mã và hiển thị cho người sử dụng Hơn nữa các điểm tại đó dữ liệu được rút ra
từ luồng truyền dẫn được đánh dấu Thông tin này được lưu trữ trong các file khác
Nhóm V 4 Lớp 10BĐTVT- KH
Trang 5nhau Các file này được dùng để thu thập kết quả mong muốn ví dụ như, tỷ lệ mấtgói tin, jitter và chất lượng video Rất nhiều thông tin là cần thiết để tính toán cácgiá trị này
Dữ liệu cần thiết là (từ bên gửi):
- video ch a nén b n g cư ản gốc ốc
Và từ bên nhận
- nhấn thời gian và loại gói nhận được
- tập hợp lại video được mã hóa
- video giải nén gốc được hiển thị
Việc đánh giá các dữ liệu này được thực hiện tại bên gửi vì vậy các thông tin
từ bên nhận cần phải gửi lại cho bên gửi Trên thực tế thì video gốc chưa nén códung lượng rất lớn ví dụ 680 MB đối với cho 3 phút video trên màn hình PDA Mặtkhác, có thể tái tạo video để được hiển thị từ các thông tin sẵn có ở bên gửi Thôngtin duy nhất cần thiết từ bên nhận là một file chứa các nhấn thời gian của mỗi gói tinđã thu được Điều này thuận tiện hơn nhiều so với việc truyền các file video hoànthiện (sai số và mã hóa) từ bên nhận
Xử lý các dữ liệu thực hiện trong ba giai đoạn Giai đoạn đầu tiền đòi hỏi cácnhấn thời gian từ cả hai bên và các loại gói tin Các kết quả của bước này là biếtđược loại khung dựa vào tỷ lệ mất gói và trễ giữa các gói Hơn nữa, sai số file video
từ bên nhận được tái tạo bằng cách dùng file video gốc được mã hóa và thông tintổn thất gói Video ở đây có thể được giải mã thành các khung video gốc để đượchiển thị cho người sử dụng Tại điểm này, vấn đề chung của việc đánh giá chấtlượng video được thực hiện Các chuẩn đo chất lượng video luôn luôn đòi hỏi việc
so sánh khung được hiển thị (có thể bị biến đổi) với các khung gốc tương ứng.Trường hợp các khung hoàn toàn bị mất thì việc đồng bộ không thể được duy trì.Giai đoạn thứ hai của quá trình này đưa ra một biện pháp để giải vấn đề này.Dựa vào thông tin tổn thất, đồng bộ khung được hồi phục bằng cách xen khungđược hiển thị sau cùng cho mỗi khung bị mất Điều này làm cho việc đánh giá chấtlượng tốt hơn Do đó, file video gốc cố định và file video gốc được dùng tại giaiđoạn cuối để thu được chất lượng video
Nhóm V 5 Lớp 10BĐTVT- KH
Trang 6Các hộp trong hình 1 có tên là VS, ET, FV, PSNR và MOS là các chươngtrình mà cơ cấu việc đánh giá chất lượng có Tương tác giữa các công cụ và mạng(được xem như là hộp đen) dựa vào các trace files Các files này chứa tất cả các dữliệu cần thiết Chỉ có một file cần phải được cung cấp từ người sử dụng EvalVid là
“receiver trace file” Nếu mạng là một đường liên kết thực tế thì file này được tạo ra
từ TCP-dump Nếu mạng được mô phỏng thì file này tạo ra bởi thành phần bênnhận của sự mô phỏng
Đối với các công cụ nằm trong EvalVid người ta chỉ cần các trace file này, filevideo gốc và bộ giả mã thui Do đó, trong trường hợp EvalVid thì mạng chỉ là mộthộp đen mà tạo ra trễ, tổn thất gói và việc sắp xếp lại gói tin Nó có thể là mộtđường liên kết thực, chẳng hạn như mạng Ethernet hoặc là WLAN, hoặc mô phỏngcủa mạng Do tương tác của EvalVid với mạng chỉ được biểu diễn bởi hai trace file(bên gửi và bên nhận), có thể dễ dàng thay hộp mạng để làm cho EvalVid càng tíncậy hơn Tương tự, bộ codec video cũng có thể được thay một cách dễ dàng
1.3 Các chức năng hỗ trợ
Phần này mô tả về các tham số được tính toán bởi công cụ của EvalVid, cáckhái niệm hình thức và các tài liệu tham khảo cho việc nghiên cứu sâu hơn đối vớivấn đề này đặc biệt là việc đánh giá chất lượng video đã đuọc cho biết
1.3.1 Xác đ nh t n th t gói tin và t n th t khung ịnh tổn thất gói tin và tổn thất khung ổn thất gói tin và tổn thất khung ất gói tin và tổn thất khung ổn thất gói tin và tổn thất khung ất gói tin và tổn thất khung
a Tổn thất gói
Việc mất gói tin thường được xác định dựa trên cơ sở ký hiệu nhận dạng gói
Do đó, hộp đen mạng phải cung cấp ID gói duy nhất Điều này không phải là vấn đềđối với việc mô phỏng bởi vì các ID duy nhất có thể dễ dàng được phát Trong cácphép đo, các ID gói tin thường được lấy từ IP (cung cấp một ID duy nhất) ID góiduy nhất cũng được sử dụng dể hủy bỏ việc sắp xếp lại gói Trong trường hợptruyền dẫn video, nó không chỉ đề cấp đến việc là bao nhiêu gói bị mất mà còn chobiết về loại dữ liệu nằm nằm trong các gói.Ví dụ, bộ codec MPEG-4 định nghĩa 4loại khác nhau của khung (I, P, B, S) và cũng định dạng một số phần mào đầuchung Do nó rất cần thiết cho truyền dẫn video và rằng loại dữ liệu nào bị mất thìnó cũng cần thiết để phân biệt các loại gói tin Việc đánh giá tổn thất gói tin đượctính phụ thuộc vào loại gói Tổn thất gói được định nghĩa trong phương trình (1)tính theo %
Nhóm V 6 Lớp 10BĐTVT- KH
Trang 7T: loại của dữ liệu trong gói (một trong tất cả, mào đầu, I, P, B, S)
nTrecv : Tổng số gói tin loại T được gửi.
nT sent : Tổng số gói tin loại T nhận được
b Tổn thất khung
Một khung video (thực ra là một ảnh tĩnh đơn được mã hóa) có thể tương đốilớn, không chỉ trong trường hợp tốc độ bit video biến đổi mà còn trong tốc độ bit cốđịnh la do thuật ngữ không đổi được áp dụng cho số trung bình cho khoảng thờigian ngắn Các khung I thường lớn đáng kể so với tốc độ bít đích không đổi (sốtrung bình thời gian ngắn) thậm chí trong “CBR” videos (hình 2)
Rất có thể và có khả năng rằng một số hoặc có thể là tất cả các khung lớn hơnđơn vị truyền tối đa (MTU) của mạng MTU là kích thước gói tối đa được hỗ trợbởi mạng (ví dụ Ethernet = 1500 bytes và 802.11b WLAN = 2312 bytes) Cáckhung này cần phải được phân đoạn thành các gói nhỏ hơn để phù hợp cho MTUcủa mạng Việc có thể phân đoạn các khung này đưa ra một vấn đề cho việc tínhtoán về tổn thất gói
Hình 2: Video CBR MPEG-4 v i t c đ bit đích 200 kbps ới tốc độ bit đích 200 kbps ốc độ bit đích 200 kbps ộ bit đích 200 kbps
Về nguyên tắc thì tổn thất gói có thể thu được từ tốc độ tổn thất gói (ở đây, góiluôn mang nghĩa là gói IP) Nhưng quá trình này phụ thuộc ít vào khả năng sử dụng
bộ giải mã video thực bởi vì một số bộ giải mã có thể xử lý một khung tuy một số
Nhóm V 7 Lớp 10BĐTVT- KH
Trang 8thành phần của khung bị mất và một số bộ giải mã thì không thể Hơn nữa, mộtkhung có thể được giải mã dựa vào gói nào của nó bị mất Nếu gói thứ nhất bị mấtthì khung gần như không bao giờ được giải mã Do đó, các tính năng của các bộ giảimã nào đó cần phải quan tâm đến để tính toán tốc độ tổn thất khung Nó được tínhriêng cho từng loại khung.
T: kiểu của khung (một trong tất cả mào đầu, I, P,B, S)
nTrecv : Tổng số gói loại T được gửi
nT sent : Tổng số gói loại T nhận được
c Xác định trễ và biến độ trễ- Jitter
Trong các hệ thống truyền video không chỉ sự tổn thất là quan trọng cho độcảm nhận chất lượng video mà phải quan tâm đến một số tham số khác như trễ cáckhung và biến độ trễ-Jitter Video số luôn chứa các khung để được hiện thị với tốc
độ không đổi Việc hiện thị một khung trước hoặc sau khi thời gian nhất định dẫn
đến “giật hình” Vấn đề này được giải quyết bằng bộ đếm tái tạo Các bộ đệm này
nhằm mục đích hấp thụ jitter được tạo ra bởi các trễ mạng Rõ ràng một bộ đệm táitạo đủ lớn có thể bù lại bất kỳ số lượng jitter Trong trường hợp đặc biệt bộ đệm lớnđến mức để chứa toàn bộ video và việc hiển thị bắt đầu mà không cần chờ đến khinhận đượckhung cuối cùng Điều này sẽ loại bỏ bất kỳ jitter có thể có nhưng phải cóthêm trễ cho toàn bộ thời gian truyền Một trường hợp đặc biệt khác sẽ là một bộđệm có thể chứa đúng một khung Trong trường hợp này không thể loại bỏ bất kỳjitter nào nhưng lại không có trễ thêm nào được tạo ra
Đã có các kỹ thuật tinh vi được phát triển cho các bộ đệm tái tạo tối ưu để giải
quyết sự cân bằng đặc biệt này Các kỹ thuật này không nằm trong phạm vi cơ cấu
được mô tả Dung lượng bộ đệm tái tạo là tham số cho quá trình đánh giá chất
lượng Điều này đang hạn chế cơ cấu này về các bộ đệm tái tạo tĩnh Tuy nhiên, do
việc tích hợp bộ đệm tái tạo liên quan đến quá trình đánh giá, thì sẽ xảy ra tổn thấtmới do tràn bộ đệm tái tạo hoặc thiếu bộ đệm
Nhóm V 8 Lớp 10BĐTVT- KH
Trang 9Định nghĩa hình thức của Jitter được sử dụng trong bài báo này được chotrong phương trình 3, 4, và 5 Đó là sự thay đổi về trễ giữa các khung liên tiếp hoặctrễ giữa các gói liên tiếp “Frame time” được tính bằng thời gian tại đó đoạn góicuối cùng của khung phân đoạn được nhận.
Trễ giữa các gói liên tiếp
00
Trễ giữa các khung liên tiếp
00
itN : là trễ trung bình giữa các gói liên tiếp
itM : trễ trung bình giữa các khung liên tiếp
Các biểu đồ thống kê cho trễ giữa các gói liên tiếp và khung liên tiếp cũngđược tính toán bằng các công cụ của cơ cấu này (xem phần 4.3)
1.3.2 Đánh giá ch t l ất gói tin và tổn thất khung ượng video ng video
Việc đánh giá chất lượng video số cần phải dựa vào chất lượng độ cảm nhậncủa người dùng bởi cảm giác của người dùng là cái cuối cùng Có hai phương pháp
cơ bản để đánh giá chất lượng video đó là đánh giá chất lượng chủ quan và phépđánh giá khách quan Các chuẩn đo chất lượng chủ quan luôn nằm được yếu tố quan
Nhóm V 9 Lớp 10BĐTVT- KH
Trang 10trọng, cảm giác của người dùng xem video khi chúng cực kỳ đặt tiền: rất tổn thờigian, yâu cầu nhân lực cao và công cụ đặc biệt Các phép đánh giá khách quan được
thường được cho theo mức độ từ 5(tốt nhất) về 1 (xấu nhất) như trong bảng 1 Mức
độ này được gọi là điểm trải nghiệm trung bình (Mean Opinion Score_MOS)
B ng 1: Ch t l ảng 1: Chất lượng ITU-R và mức độ suy yếu ất lượng Video ượng Video ng ITU-R và m c đ suy y u ức độ suy yếu ộ bit đích 200 kbps ếu
Nhiều công trình trong công nghiệp và nghiên cứu yêu cầu phương pháp tựđộng hóa để đánh giá chất lượng video Các thử nghiệm phức tạp và đắt tiền củaphương pháp chủ quan thường không được áp dụng Do đó, phương pháp kháchquan đã được phát triển để cạnh tranh với cảm giác chất lượng của hệ thống thị giáccủa con người (HVS)
Tuy nhiên, phương pháp phổ biến nhất là việc tính tỷ số tín hiệu đỉnh trên tạp
âm (PSNR) cho mỗi ảnh tĩnh Tỷ số này là một trường hợp đặc biệt của tỷ số trêntín hiệu trên tạp âm (SNR) SNR so sánh năng lượng tín hiệu với năng lượng tạp
âm Tỷ số PSNR so sánh năng lượng tín hiệu tối đa với năng lượng nhiễu Nó có kết
quả tương quan với độ cảm nhận chất lượng chủ quan cao hơn so với tỷ số SNR.
Phương trình (6) là định nghĩa của PSNR giữa thành phần độ sáng Y của ảnh tĩnhnguồn S và ảnh tĩnh đích D
Trang 11Tử số được có thể gọi là sai số trung bình bình phương (MSE) Do đó, biểuthức PSNR có thể viết tắt thành:
Một phương pháp nữa là đầu tiên phải tính MOS (bảng 2) và tính số tỷ lệkhung với MOS xấu hơn tỷ số khung của video đã được gửi (không bị méo dạng).Phương pháp này có ưu điểm là thấy rõ sự biến dạng gây ra bởi mạng Trong phần
4, ta có thể thấy ví dụ được cho bởi công cụ MOS của EvalVid Các kết quả rõ hơnđược cho bởi EvalVid được tóm tắt trong phần 5
B ng 2: Possible PSNR to MOS conversion ảng 1: Chất lượng ITU-R và mức độ suy yếu
1.4 Các công cụ
Phần này giới thiệu các công cụ của cơ cấu EvalVid, mô tả về mục đích vàcách sử dụng của nó và cho thấy các ví dụ về kết quả thu được Ngoài ra, phần nàycòn cho biết về các nguồn của file video mẫu và các bộ codecs
1.4.1 C u trúc d li u và files ất gói tin và tổn thất khung ữ liệu và files ệu và files
Đầu tiên, cần một nguồn video Raw (chưa mã hóa) video files thường lưu trữdưới dạng YUV, bởi vì dạng này là dạng đầu vào được ưu tiên hơn đối với các bộgiải mã có sẵn Files kiểu này có thể thu được từ nhiều nguồn khác nhau, chẳng hạn
Nhóm V 11 Lớp 10BĐTVT- KH
Trang 12như các bộ codec miễn phí MPEG-4 Các khung video mẫu cũng có thể thu được từtác giả.
Khi có được file video được mã hóa (các luồng bit), trace files được tạo ra từnó Các trace files này chứa tất cả các thông tin liên quan cho các khối công cụ củaEvalVid để thu được các kết quả như trình bày trong phần 3 Các công cụ đánh giáchất lượng video tạo ra các đoạn chương trình để đọc và viết các trace files này và
sử dụng cấu trúc dữ liệu trung tâm chứa tất cả các thông tin cần thiết để đưa ra cáckết quả mong muốn Dạng thực của trace files, cách sử dụng các đoạn chương trình
và định nghĩa cấu trúc dữ liệu trung tâm được mô tả ngắn gọn trong phần sau vàđược mô tả chi tiết trong tài liệu tham khảo
1.4.2 B g i video- VS ộ gửi video- VS ửi video- VS
Đối với các file video MPEG-4, bộ phân tách đã được phát triển dựa vào
chuẩn video MPEG-4; simple profile và advanced simple profile được thực hiện.
Điều này làm cho nó có thể đọc được bất kỳ file video MPEG-4 được tạo ra bởi bộgiải mã thích hợp Mục đích của bộ VS là phải tạo ra một trace file từ file video đãđược mã hóa Một cách tùy ý, file video có thể được gửi đi qua UDP (nếu hệ thốngquan sát là một thiết lập mạng) Các kết quả từ VS là hai trace files chứa các thôngtin về mỗi khung trong file video và mỗi gói được tạo ra để truyền dẫn (bảng 3 vàbảng 4)
Dạng của video trace file:
B ng 3: D li u liên quan ch a trong video trace file ảng 1: Chất lượng ITU-R và mức độ suy yếu ữ liệu liên quan chứa trong video trace file ệu liên quan chứa trong video trace file ức độ suy yếu
Trang 13B ng 4: D li u liên quan ch a trong sender trace file g m có time stamp, ảng 1: Chất lượng ITU-R và mức độ suy yếu ữ liệu liên quan chứa trong video trace file ệu liên quan chứa trong video trace file ức độ suy yếu ồ cơ cầu đánh giá chất lượng Video packet ID và packet size File này đ ượng Video ạo ra rời rạc bởi vì nó có thể thu c t o ra r i r c b i vì nó có th thu ời rạc bởi vì nó có thể thu ạo ra rời rạc bởi vì nó có thể thu ởi vì nó có thể thu ể thu
đ ượng Video ừ các công cụ khác (ví dụ TCP-dump, xem tài liệu tham khảo) c t các công c khác (ví d TCP-dump, xem tài li u tham kh o) ụ khác (ví dụ TCP-dump, xem tài liệu tham khảo) ụ khác (ví dụ TCP-dump, xem tài liệu tham khảo) ệu liên quan chứa trong video trace file ảng 1: Chất lượng ITU-R và mức độ suy yếu
Cả hai trace files này biểu diễn việc truyền tải video hoàn thiện (tại bên gửi)
và chứa tất cả các thông tin cần thiết cho việc đánh giá sâu hơn bằng EvalVid Đốivới bộ VS, chúng ta có thể tạo ra một cặp trace files này cho các files video khácnhau và với chiều dài gói tin khác nhau Sau đó các file này có thể được đưa vàohộp đen mạng (chẳng hạn như sự mô phỏng) Điều này được thực hiện với sự hỗ trợ
từ các đoạn chương trình đầu vào và các cấu trúc dữ liệu cung cấp bởi EvalVid Sauđó mạng sẽ tạo ra trễ và tổn thất và sự sắp xếp lại các gói tin Một trace file khác tạibên nhận được tạo ra hoặc với sự hỗ trợ của đoạn chương trình đầu ra của EvalVidhoặc trong trường hợp truyền dẫn thực chỉ bởi TCP-dump (nó tạo ra trace filestương thích với EvalVid)
Cần lưu ý rằng mặc dù lớp IP sẽ phân đoạn các gói UDP trên MTU của lớpphía dưới và lớp IP sẽ cố gắng tập hợp lại các đoạn gói tại bên nhận thì tốt hơn hãycho nó tự phân đoạn Nếu một đoạn gói (IP fragment) bị mất thì toàn bộ gói (UDP)được coi là bị mất Do nó thích hợp hơn để có được phần còn lại của các đoạn góitin thì báo cáo này muốn khuyến nghị chúng ta nên sử dụng chức năng phân đoạngói MTU của VS nếu có thể
1.4.3 ET – Evaluate Traces
Điểm trung tâm của cơ cấu đánh giá chất lượng là một chương trình được gọi
là ET (Evaluate Traces) Ở đây thực hiện phép tính toán thực sự cho tổn thất gói tin
và tổn thất khung và cũng như trễ và biến độ trễ (jitter) Đối với việc tính toán các
dữ liệu này chỉ yêu cầu ba trace files bởi vì đến đây đã có đầy đủ tất cả các thông tincần thiết để tính toán tổn thất và jitter, thậm chí kể cả loại khung, loại gói cũng đãbiết Việc tính toán tổn thất rất dễ dàng chỉ nhờ vào tính có sẵn của ID gói duy nhất.Nhờ vào video trace file, mỗi gói được phân loại Mỗi gói của loại này không chứatrong trace file bên nhận thì được xem như là bị mất Tỷ lệ tổn thất dựa trên loại góiđược tính toán nhờ phương trình (1) Tổn thất khung được tính toán bằng cách tìmbất kỳ khung nào, nếu một trong những đoạn khung (các gói) bị mất Nếu đoạn đầutiên của một khung nằm trong các đoạn bị mất thì khung được xem là bị mất Điềunày là do bộ giải mã video không thể giải mã một khung mà thành phần đầu tiên bịmất Tổn thất khung dựa trên loại được tính toán theo phương trình (2)
Dưới đây là một ví dụ cho đầu ra của ET đối với các tổn thất (một truyền dẫnvideo của 4498 khung trong 8301 gói)
Nhóm V 13 Lớp 10BĐTVT- KH
Trang 14Trễ giữa khung liên tiếp được tính theo phương trình (3) và (4) Tuy nhiên,trong trường hợp tổn thất gói, các biểu thức này không thể áp dụng dễ dàng được.Điều này do trong trường hợp này không có time-stamp có sẵn trong trace file bênnhận cho các gói tin bị mất Do đó có một câu hỏi đặt ra rằng trễ giữa các gói liêntiếp được tính bằng cách nào, nếu ít nhất một trong hai gói liên tiếp bị mất? Một khảnăng là phải đặt trễ giữa gói liên tiếp trong trường hợp gói bị mất với giá trị “error”
ví dụ giá trị 0 Sau đó nếu một gói thực sự nhận được, thì có thể tìm kiếm phản hồicho đến khi tìm thấy một giá trị đúng Trong trường hợp này trễ giữa các gói liên
một giá trị cho mỗi gói và trễ giữa gói liên tiếp có thể tăng quá lớn Đó là lý do tạisao phương pháp được sử dụng bởi ET là hơi khác nhau Nếu ít nhất một (trong haigói thực sự được dùng trong việc tính toán) gói bị mất thì sẽ không được gửi với giátrị đúng nhưng gửi với giá trị dự đoán Điều này được thực hiện bằng cách tính thờigian đến có thể giả định được cho một gói bị mất Dưới đây sẽ cho thấy cách nàythực hiện như thế nào và phương trình (7) Điều này thực tế có nghĩa là đối với cácgói tin bị mất thì giá trị của trễ giữa các khung liên tiếp tại bên gửi được dùng Nếugói tin tương đối ít bị mất thì phương pháp này không tác động đáng kể cho thống
kê Jitter Mặt khác, nếu có tỷ lệ tổn thất rất cao thì một phương pháp khác đã đượcgiới thiệu: để tính toán các gói từng đôi nhận được và tính các gói bị mất một cáchriêng biệt
Thời gian đến (gói bị mất)
Đến đây, do mỗi gói tin có time-stamp đúng thì người ta có thể tính trễ giữacác gói liên tiếp theo phương trình (3) Hình 3 cho một ví dụ về các trễ giữa các góiliên tiếp được tính bởi ET
Nhóm V 14 Lớp 10BĐTVT- KH
