Báo cáo thực hành môn mạng máy tính

Bất cứlúc nào một client cũng có thể yêu cầu một tập tin audio hay video từ một máy chủ .Trong hầu hết các ứng dụng âm thanh / video lưu trữ được lưu trữ tồn tại, sau một vàigiây bị trễ,

TRƯỜNG ĐẠI HỌC BÁCH KHOA

KHOA CÔNG NGHỆ THÔNG TIN

MỤC LỤC

6.1 CÁC ỨNG DỤNG MẠNG ĐA PHƯƠNG TIỆN 6

6.1.1 Các ví dụ của ứng dụng đa phương tiện 6

6.1.2 Những trở ngại cho đa phương tiện trên Internet 8

6.1.3 Internet nên phát triển như thế nào để hỗ trợ đa phương tiện tốt hơn 9

6.1.4 Âm thanh và video nén 10

6.2 LƯU TRỮ ÂM THANH VÀ VIDEO TRỰC TUYẾN 14

6.2.1 Truy cập âm thanh và video từ máy chủ web 15

6.2.2 Gửi đa phương tiện từ luồng server đến ứng dụng hỗ trợ 19

6.2.3 Giao thức truyền dòng dữ liệu thời gian thực 21

6.3 LÀM TỐT NHẤT DỊCH VỤ BEST EFFORT – MỘT VÍ DỤ VỀ ĐIỆN THOẠI INTERNET 26

6.3.1 Những hạn chế của một dịch vụ Best-Effort 27

6.3.2 Loại bỏ biến động nhận được cho âm thanh 29

6.3.3 Phục hồi gói tin bị mất 33

6.3.4 Luồng lưu trữ âm thanh và video 37

6.4 GIAO THỨC RTP 39

6.4.1 Cơ bản về RTP 39

6.4.2 Trường tiêu đề trong gói tin RTP 42

6.4.3 RTP giao thức điều khiển (RTCP) 44

6.4.4 H.323 47

6.5 BEYOND BEST EFFORT 54

6.6 BỘ ĐỊNH THỜI VÀ CƠ CHẾ KIỂM SOÁT LƯU LƯỢNG MẠNG 61

6.6.1 Các cơ chế bộ định thời 61

6.6.2 Cơ chế điều khiển lưu lượng mạng 66

6.7 DỊCH VỤ TÍCH HỢP 71

6.7.1 Bảo đảm chất lượng của dịch vụ 73

6.7.2 Kiểm soát băng thông mạng 74

6.8 RSVP 76

6.8.1 Bản chất của RSVP 76

6.8.2 Một vài ví dụ đơn giản 79

6.8.3 Tin nhắn đường dẫn 81

6.8.4 Các kiểu đặt chỗ 82

6.8.5 Vận chuyển các tin nhắn đặt chỗ: 85

6.9 DỊCH VỤ CHÊNH LỆCH 87

6.9.1 Công nghệ phân lập dịch vụ ( giao thức Diffserv, dịch vụ phân biệt or phân loại dịch vụ ): một kịch bản đơn giản 88

6.9.2 Phân loại lưu lượng và điều chỉnh 90

6.9.3 Per-Hops Behavior ( tác động chặn) 93

TÓM TẮT 96

BÀI TẬP VỀ NHÀ VÀ CÂU HỎI THẢO LUẬN CHƯƠNG 6 99

CÂU HỎI ÔN TẬP 99

BÀI TOÁN 100

CÂU HỎI THẢO LUẬN 104

BẢNG PHÂN CÔNG CÔNG VIỆC NHÓM 6 106

DANH MỤC HÌNH ẢNH

Hình 6.2 - 1: Luồng thực hiện cho tập tin âm thanh 17

Hình 6.2 - 2: Máy chủ web gửi tập tin audio/video đến ứng dụng media 17

Hình 6.2 - 3: Luồng từ máy chủ streaming đến ứng dụng media 19

Hình 6.2 - 4: Bộ nhớ đệm máy khách x(t) và d 21

Hình 6.2 - 5: Tương tác giữa máy khách và máy chủ dùng RSTP 24

Hình 6.3 - 1: Mất gói tin vì trì hoãn phát lại cố định khác 33

Hình 6.3 - 2: Dự phòng sao lưu thông tin có chất lượng thấp 37

Hình 6.3 - 3: Gửi âm thanh xen kẻ 38

Hình 6.4 - 1: RTP có thể được xem như là một lớp con của lớp vận chuyển 41

Hình 6.4 - 2: RTP là một phần của lớp ứng dụng 41

Hình 6.4 - 3: RTP trường header 43

Hình 6.4 - 4: Một số loại tải trọng âm thanh được hỗ trợ bởi RTP 43

Hình 6.4 - 5: Một số loại tải trọng video được hỗ trợ bởi RTP 44

Hình 6.4 - 6: người gửi và người nhận gửi tin nhắn trong RTCP 45

Hình 6.4 - 7: Hệ thống H.323 49

Hình 6.4 - 8: Kiến trúc giao thức H.323 50

Hình 6.4 - 9: kênh H.323 52

Hình 6.4 - 10: Thiết bị đầu cuối H.323 và gatekeeper trên cùng một mạng LAN 53

Hình 6.5 - 1: Mạng đơn giản với 2 ứng dụng 55

Hình 6.5 - 2: So sánh giữa audio và ứng dụng FTP 56

Hình 6.5 - 3: Chính sách về audio và luồng điều khiển FTP 59

Hình 6.5 - 4: Luồng ứng dụng ftp và âm thanh 59

Hình 6.5 - 5: So sánh giữa 2 ứng dụng âm thanh R1 đến R2 60

Hình 6.5 - 6: Bốn nguyên tắc dịch vụ hỗ trợ QoS 61

Hình 6.6 - 1: Mô hình hàng đợi FIFO 62

Hình 6.6 - 2: Hoạt động hàng đợi FIFO 63

Hình 6.6 - 3: Mô hình hàng đợi ưu tiên 64

Hình 6.6 - 4: Mô hình hoạt động hàng đợi ưu tiên 65

Hình 6.6 - 5: Mô hình hoạt động hai hàng đợi của nguyên tắc quay vòng 66

Hình 6.6 - 6: Mô hình hàng đợi nâng cao (WFQ) 66

Hình 6.6 - 7: The Leaky Bucket Policer 68

Hình 6.6 - 8: Mô hình n bộ điều khiển lưu lượng với cơ chế hàng đợi cân bằng 70

Hình 6.7 - 1: Tiến trình cài đặt cuộc gọi 72 Hình 6.7 - 2: Gọi hành vi yếu tố 74

Hình 6.8 - 1: RSVP Đa Multicast và nhận có hướng 78

Hình 6.8 - 2: Một ví dụ về RSVP 80

Hình 6.8 - 3: Một ví dụ sử dụng RSVP trong hội nghị video 82

Hình 6.8 - 4: Tình huống giả cho kiểu đặt chỗ RSVP 84

Hình 6.8 - 5: Đặt bằng kí hiệu wildcard 85

Hình 6.8 - 6: Cách đặt bằng bộ lọc cố định 85

Hình 6.8 - 7: Đặt bằng cách chia sẽ đặt chỗ 86

Hình 6.9 - 1: Một ví dụ cho mạng lưới Diffserv đơn giản 89

Hình 6.9 - 2: Structure of the DS field in IVv4 and IPv6 header 91

Hình 6.9 - 3: Tất cả các gói đáp ứng một điều kiện cho sẵn 92

Hình 6.9 - 4: Phân loại gói tin và điều lưu lượng tại các router biên 93

6.1 CÁC ỨNG DỤNG MẠNG ĐA PHƯƠNG TIỆN

6.1.1 Các ví dụ của ứng dụng đa phương tiện

Internet chứa một lượng lớn các ứng dụng đa phương tiện thú vị Chúng ta xácđịnh ba lớp của các ứng dụng đa phương tiện

- Luồng âm thanh và video đã lưu trữ

Trong lớp này của các ứng dụng , client yêu cầu theo yêu cầu âm thanh nén hoặc filevideo, được lưu trữ trên các máy chủ Đối với âm thanh, các tập tin này có thể chứamột bài giảng giáo sư , những bản nhạc rock, giao hưởng, tài liệu lưu trữ của chươngtrình phát thanh nổi tiếng , cũng như ghi âm lưu trữ lịch sử

Đối với video, những tập tin này có thể chứa video của bài giảng giáo sư, phim vớiđầy đủ độ dài, chương trình truyền hình được ghi âm , tài liệu, lưu trữ video của sựkiện lịch sử ,ghi hình sự kiện thể thao, phim hoạt hình và âm nhạc video clip Bất cứlúc nào một client cũng có thể yêu cầu một tập tin audio hay video từ một máy chủ Trong hầu hết các ứng dụng âm thanh / video lưu trữ được lưu trữ tồn tại, sau một vàigiây bị trễ, client bắt đầu để phát lại các tập tin âm thanh trong khi nó vẫn tiếp tụcnhận được các tập tin từ máy chủ Các tính năng phát lại âm thanh hoặc video trongkhi tập tin đang được nhận được gọi là streaming

Nhiều sản phẩm hiện có cũng cung cấp cho người sử dụng tương tác, ví dụ như : tạmdừng / tiếp tục và nhảy thời gian đến trước và sau của các tập tin âm thanh.Trì hoãn từkhi người dùng tạo một yêu cầu (ví dụ, yêu cầu để nghe một tập tin âm thanh hoặc bỏqua hai phút về phía trước) cho đến khi hành động thể hiện ở các máy chủ sử dụng (ví

dụ, người sử dụng bắt đầu nghe tập tin âm thanh) nên về trình tự từ 1 đến 10 giây chođáp ứng chấp nhận được Yêu cầu đối với gói sự chậm trễ và sự bồn chồn không phải

là nghiêm ngặt như đối với các ứng dụng thời gian thực như điện thoại Internet

và hội nghị truyền hình thời gian thực (xem bên dưới) Có rất nhiều sản phẩm trựctuyến để lưu trữ audio / video, bao gồm cả RealPlayerfrom RealNetworksandNetShowfrom Microsoft

- Một đến nhiều luồng âm thanh và video thời gian thực :

Lớp này của các ứng dụng tương tự như phát sóng bình thường của đài phát thanh vàtruyền hình, ngoại trừ việc truyền tải diễn ra trên Internet.Các ứng dụng này cho phépngười dùng nhận được tín hiệu của một đài phát thanh và truyền hình phát ra từ bất kỳnơi trên thế giới (Ví dụ, một trong những tác giả của cuốn sách này thường lắng ngheyêu thích của mình Đài phát thanh Philadelphia từ nhà của ông ở Pháp.) Microsoftcung cấp một đài phát thanh Internet hướng dẫn.

Thông thường, có nhiều người sử dụng đồng thời nhận được chương trình âm thanh/video thời gian thực giống nhau Lớp này của các ứng dụng là không tương tác, mộtclient không thể kiểm soát được lịch trình truyền tải của máy chủ Như với streamingcủa lưu trữ đa phương tiện, yêu cầu cho sự chậm trễ gói và sợ bồn chồn không phải lànghiêm ngặt như đối với điện thoại Internet và hội nghị truyền hình thời gian thực

Sự chậm trễ lên đến hàng chục giây từ khi người dùng nhấp chuột vào một liên kết chođến khi phát lại âm thanh / video bắt đầu có thể được bỏ qua.Việc phân phối âm thanh/ video theo thời gian thực đến nhiều người nhận là một cách hiệu quả khi thực hiệnvới multicast, tuy nhiên, như các văn bản này, hầu hết các hệ một-nhiều âm thanh /video truyền trên Internet được thực hiện với dòng unicast riêng biệt cho mỗi ngườinhận

- Tương tác âm thanh và video thời gian thực:

Lớp này của các ứng dụng cho phép người sử dụng âm thanh / video để giaotiếp với nhau trong thời gian thực Thời gian thực âm thanh tương tác thường được gọi

là điện thoại Internet, từ đó, từ quan điểm của người sử dụng, nó tương tự như dịch vụđiện thoại chuyển mạch kênh truyền thống Điện thoại Internet có khả năng cung cấptổng đài, địa phương và dịch vụ điện thoại đường dài với chi phí rất thấp

Nó cũng có thể tạo thuận lợi cho việc hội nhập máy tính điện thoại (được gọi làCTI), nhóm thông tin liên lạc thời gian thực, dịch vụ thư mục, nhận dạng người gọi,người gọi lọc, vv Có nhiều sản phẩm điện thoại Internet hiện đã có.Với video tươngtác thời gian thực, còn được gọi là hội nghị truyền hình, các cá nhân giao tiếp trựcquan giống như nói miện Trong một cuộc họp nhóm, người dùng có thể mở một cửa

sổ cho mỗi người tham gia người sử dụng muốn nhìn thấy Ngoài ra còn có nhiều cácsản phẩm video tương tác thời gian thực, hiện có sẵn cho Internet, bao gồmNetmeeting của Microsoft

Lưu ý rằng trong ứng dụng tương tác âm thanh / video thời gian thực, mộtngười sử dụng có thể nói chuyện hay di chuyển bất cứ lúc nào Sự chậm trễ từ khingười dùng nói hoặc di chuyển cho đến khi hành động được thể hiện tại các máy chủtiếp nhận nên được ít hơn một vài trăm mili giây Đối với giọng nói, sự chậm trễ nhỏhơn 150 mili giây không được nhận thấy bởi người nghe, sự chậm trễ giữa 150 và 400mili giây có thể chấp nhận được, và sự chậm trễ quá 400 mili giây cho kết quả khôngtốt nếu đàm thoại hoàn toàn không đáng tin cậy.

6.1.2 Những trở ngại cho đa phương tiện trên Internet

IP , giao thức tầng mạng Internet, cung cấp dịch vụ băng thông tốt nhất cho tất

cả các gói dữ liệu nó mang Nói cách khác, Internet cố gắng tốt nhất để di chuyển mỗigói tin từ người gửi đến người nhận một cách càng nhanh càng tốt Tuy nhiên , dịch vụtốt nhất dù cố gắng không thực hiện bất kỳ lời hứa nào về sự chậm trễ end-to -end chocác gói cá nhân Dịch vụ cũng không thực hiện bất kỳ lời hứa về sự biến đổi củapakcet trì hoãn trong một dòng gói tin

Như chúng ta đã học ở Chương 3, bởi vì TCP và UDP chạy qua IP , không phảicủa các giao thức này có thể thực hiện bất kỳ sự chậm trễ đảm bảo cho các ứng dụnggọi Do thiếu của bất kỳ đặc biệt nỗ lực để cung cấp các gói tin một cách kịp thời , nó

là vấn đề extermely thách thức để phát triển thành công các ứng dụng mạng đa phươngtiện cho mạng Internet Đến nay, đa phương tiện trên Internet đã đạt được thành côngđáng kể nhưng hạn chế Ví dụ, cửa hàng trực tuyến audio / video với sự chậm trễngười dùng tương tác năm đến mười giây bây giờ là phổ biến trên mạng Internet.Nhưng trong thời gian cao điểm , hiệu suất có thể không đạt yêu cầu , đặc biệt là khiliên kết can thiệp là các liên kết bị tắc nghẽn (ví dụ như tắc nghẽn liên kết xuyên đạidương ) Điện thoại internet và video thời gian thực tương tác đã, cho đến nay, được ítthành công hơn trực tuyến audio / video lưu trữ Thật vậy, tương tác giọng nói vàvideo thời gian thực áp đặt những hạn chế cứng nhắc về sự chậm trễ gói và jitter gói.Gói jitteris sự thay đổi của sự chậm trễ gói trong luồng gói tin đó Thời gian thực thoại

và video có thể làm việc tốt ở vùng có băng thông là phong phú, và do đó sự chậm trễ

và jitter được tối thiểu Nhưng chất lượng có thể xấu đi đến mức không thể chấp nhậnngay khi giọng nói hoặc gói phim chơi thời gian thực truy cập một liên kết tắc nghẽn

Việc thiết kế các ứng dụng đa phương tiện chắc chắn sẽ đơn giản hơn nếuchúng là một số loại các dịch vụ Internet lớp một và lớp2, theo đó các gói tin của lớpđầu tiên được giới hạn về số lượng và luôn luôn được ưu tiên trong hàng đợi địnhtuyến Đối với dịch vụ lớp một như vậy có thể được thỏa đáng cho sự chậm trễ nhạycảm các ứng dụng Nhưng cho đến nay, Internet đã hầu như thực hiện một cách tiếpcận giống nhau với gói lập lịch trong hàng đợi định tuyến: tất cả các gói nhận đượcdịch vụ như nhau, không có gói tin, bao gồm cả gói dữ liệu âm thanh và video nhạycảm với trễ, nhận được bất kỳ ưu tiên trong hàng đợi định tuyết Không cần biết là bạn

có bao nhiêu tiền hoặc bạn quan trọng như thế nào, bạn phải tham gia phần cuối củadòng và đợi đến lượt của bạn!

Vì vậy, cho thời gian được, chúng tôi phải sống với các dịch vụ nỗ lực tốt nhất.Không có vấn đề như thế nào quan trọng hoặc làm thế nào giàu chúng tôi, các gói tincủa chúng tôi phải đợi đến lượt của họ trong hàng đợi router Nhưng với hạn chế này,chúng ta có thể làm cho một số quyết định thiết kế và sử dụng một vài thủ thuật để cảithiện với người sử dụng cảm nhận chất lượng của một đa phương tiện ứng dụng kếtnối mạng Ví dụ, chúng ta có thể gửi âm thanh và video trên UDP, và do đó phá vỡthông thấp TCP khi TCP đi vào giai đoạn chậm bắt đầu của nó Chúng ta có thể trìhoãn phát lại tại nhận 100 msecs hoặc nhiều hơn để giảm bớt những ảnh hưởng củajitter mạng gây ra chúng ta có thể gói dấu thời gian ở người gửi để nhận biết khi cácgói dữ liệu cần được phát lại Cho lưu trữ âm thanh / video chúng ta có thể Prefetch dữliệu trong quá trình phát lại khi lưu trữ và băng thông khách hàng thêm là có sẵn.Chúng tôi thậm chí có thể gửi thông tin dự phòng để giảm thiểu ảnh hưởng của mạnggây ra mất gói tin Chúng tôi sẽ điều tra rất nhiều các kỹ thuật trong chương này

6.1.3 Internet nên phát triển như thế nào để hỗ trợ đa phương tiện tốt hơn

Ngày nay có một cuộc tranh luận khác thường và đôi khi dữ dội về cáchInternet nên phát triển như thế nào để đáp ứng tốt hơn lưu lượng truy cập đa phươngtiện với thời gian hạn chế cứng nhắc của nó Ở một bên quan điểm, một số nhà nghiêncứu cho rằng nó không cần thiết để thực hiện bất kỳ thay đổi cơ bản đến dịch vụ của

nỗ lực tốt nhất và các giao thức Internet cơ bản

Thay vào đó, theo những phần tử cực đoan, nó chỉ là cần thiết để thêm băngthông nhiều hơn cho các liên kết (cùng với bộ nhớ đệm cho mạng thông tin được lưu

trữ và hỗ trợ multicast cho một-nhiều thời gian thực trực tuyến) Đối thủ để quan điểmnày cho rằng băng thông bổ sung có thể tốn kém, và ngay sau khi nó được đưa ra nó sẽđược ăn tăng băng thông ứng dụng đói mới (ví dụ, video độ nét cao theo yêu cầu)

Ở quan điểm khác, một số nhà nghiên cứu cho rằng những thay đổi cơ bản phảiđược thực hiện với Internet để các ứng dụng có thể dự trữ băng thông đầu cuối mộtcách rõ ràng Các nhà nghiên cứu cảm nhận , ví dụ,rằng nếu người dùng muốn thựchiện cuộc gọi điện thoại Internet từ máy chủ A đến máy chủ của B , sau đó điện thoạiInternet của người sử dụng ứng dụng sẽ có thể dự trữ một cách rõ ràng băng thôngtrong mỗi liên kết dọc theo tuyến đường từ máy chủ A để lưu trữ B Nhưng cho phépcác ứng dụng để thực hiện đặt chỗ và yêu cầu mạng để tôn vinh đặt đòi hỏi một sốthay đổi lớn Đầu tiên chúng ta cần một giao thức , thay mặt các ứng dụng, dự trữbăng thông từ người gửi đến người nhận của họ Thứ hai, chúng ta cần phải sửa đổichính sách kế hoạch trong hàng đợi router để đặt băng thông có thể được tôn trọng.Với những chính sách lập lịch trình mới , tất cả các gói tin không còn được đối xử bìnhđẳng , thay vào đó , những dự trữ đó (và trả tiền ) hơn nhận được nhiều hơn Thứ ba ,trong đặt để tôn vinh đặt , các ứng dụng cần để cung cấp cho mạng mô tả về giaothông họ có ý định gửi vào mạng Sau đó các mạng phải cảnh sát giao thông của mỗiứng dụng để làm chắc chắn rằng nó tuân thủ để mô tả Cuối cùng , mạng phải có mộtphương tiện xác định xem nó có đủ băng thông có sẵn để hỗ trợ bất kỳ yêu cầu đặtphòng mới Các cơ chế này , khi kết hợp , yêu cầu phần mềm mới và phức tạp trongcác máy chủ và thiết bị định tuyến cũng như các loại dịch vụ mới

6.1.4 Âm thanh và video nén

Trước khi âm thanh và video có thể được truyền qua mạng máy tính, nó phảiđược số hóa và nén Nhu cầu số hóa là rõ ràng: mạng máy tính truyền bit, do đó tất cảcác thông tin được truyền đi phải được biểu diễn như là một chuỗi các bit Nén rấtquan trọng vì không nén âm thanh và video sẽ tiêu thụ một lượng lớn dung lượng lưutrữ và băng thông; loại bỏ các cố hữu dư thừa trong số hóa tín hiệu âm thanh và video

có thể giảm đơn đặt hàng của các cường độ lượng dữ liệu mà cần phải được lưu trữ vàtruyền đi Ví dụ, một hình ảnh duy nhất bao gồm 1024 pixel x 1024 pixel với mỗiđiểm ảnh được mã hóa thành 24 bist đòi hỏi 3 MB dung lượng lưu trữ mà không cầnnén Nó sẽ mất bảy phút để gửi hình ảnh này trên một liên kết 64 Kbps Nếu hình ảnh

được nén ở mức khiêm tốn 10:01 tỉ lệ nén, các yêu cầu lưu trữ giảm xuống còn 300

KB và thời gian truyền giảm xuống dưới 6 giây

Các lĩnh vực âm thanh và nén video là rất lớn.Khu vực hoạt động có hơn 50năm nghiên cứu, và hiện nay có hàng trăm kỹ thuật và các tiêu chuẩn phổ biến cho cả

âm thanh và nén video Hầu hết các trường đại học cung cấp toàn bộ các khóa học vềnén âm thanh và video, và thường cung cấp một khóa học riêng về âm thanh nén vàmột khóa học riêng biệt về nén video Hơn nữa, kỹ thuật và khoa học máy tính ngànhđiện thường xuyên cung cấp các khóa học độc lập về đề tài này, với mỗi bộ phận tiếpcận chủ đề từ một góc độ khác nhau Do đó chúng tôi chỉ cung cấp ở đây một cáchngắn gọn và cao cấp giới thiệu về chủ đề này

Nén âm thanh trên Internet

Một tín hiệu âm thanh analog liên tục thay đổi (có thể bắt nguồn từ lời nói hoặc

âm nhạc) là bình thường chuyển đổi thành một tín hiệu kỹ thuật số như sau:

Tín hiệu âm thanh analog là lần đầu tiên lấy mẫu tại một số lãi suất cố định, ví

dụ, 8.000 mẫu mỗi giây Các giá trị của mỗi mẫu là một số thực tùy ý.Mỗi mẫu là sau đó "làm tròn" với một trong một số hữu hạn các giá trị Hoạt động này

là gọi là "lượng tử" Số các giá trị hữu hạn - gọi là giá trị lượng tử - làthường là một sức mạnh của 2, ví dụ, 256 giá trị lượng tử Mỗi giá trị lượng tử đượcđại diện bởi một số cố định của các bit Ví dụ, nếu có 256 lượng tử hóa các giá trị, sau

đó mỗi giá trị - và do đó mỗi mẫu - được đại diện bởi 1 byte Môi của các mẫu đượcchuyển thành đại diện bit của nó Cơ quan đại diện bit của tất cả các mẫu được nối vớinhau để tạo thành các đại diện kỹ thuật số của tín hiệu

Ví dụ, nếu một tín hiệu âm thanh analog được lấy mẫu tại 8.000 mẫu mỗi giây,mỗi mẫu là lượng tử hóa và biểu diễn bởi 8 bit, sau đó các tín hiệu kỹ thuật số kết quả

sẽ có một tỷ lệ 64.000 bit mỗi thứ hai Tín hiệu kỹ thuật số này sau đó có thể đượcchuyển đổi trở lại - tức là , giải mã - một tín hiệu tương tự để phát lại.Tuy nhiên, tín hiệu tương tự được giải mã thường là khác nhau từ các tín hiệu âmthanh gốc bằng cách tăng tỷ lệ lấy mẫu và số lượng các giá trị lượng tử hóa tín hiệugiải mã có thể gần đúng (và thậm chí được chính xác bằng) các tín hiệu tương tự banđầu Do đó , có một sự cân bằng rõ ràng giữa chất lượng của tín hiệu giải mã và cácyêu cầu lưu trữ và băng thông của tín hiệu kỹ thuật số Các kỹ thuật mã hóa cơ bản mà

chúng ta vừa mô tả được gọi là Pulse Code Modulation (PCM) bài phát biểu

mã hóa thường sử dụng PCM, với một tỷ lệ lấy mẫu 8000 mẫu mỗi thứ hai và 8 bit chomỗi mẫu , đưa ra một tỷ lệ 64 kbs Disk nhỏ gọn âm thanh ( CD ) cũng sử dụng PCM,

mà không có một tỷ lệ lấy mẫu của 44.100 mẫu mỗi thứ hai với 16 bit cho mỗi mẫu ,điều này cho tốc độ 705,6 Kbps cho mono và 1.411 Mbps cho âm thanh stereo Một tỷ

lệ bit của 1.411 Mbps cho âm nhạc stereo vượt quá tốc độ truy cập nhất , và thậm chí

64 kbps cho bài phát biểu vượt quá tốc độ truy cập cho một người dùng modem

dial-up Vì những lý do , PCM mã hóa giọng nói và âm nhạc là hiếm khi được sử dụngtrong Internet Kỹ thuật thay vì nén được sử dụng để làm giảm tốc độ bit của dòngsuối.Kỹ thuật nén phổ biến cho các bài phát biểu bao gồm GSM (13 Kbps ) , G.729(8.5 Kbps ) và G.723 ( cả hai 6.4 và 5.3 Kbps ) , và cũng có một số lượng lớn các kỹthuật độc quyền, bao gồm cả những người sử dụng bởiRealNetworks Một kỹ thuậtnén phổ biến cho gần nhạc stereo chất lượng CD là MPEG Layer 3, thường được gọi

là MP3 MP3 nén tốc độ bit cho âm nhạc đến 128 hoặc 112 Kbps, và sản xuất rất ít sựxuống cấp âm thanh Một tập tin MP3 có thể được chia thành từng mảnh, và mỗi phầnvẫn là có thể chơi được Định dạng tập tin không đầu này cho phép các file nhạc MP3

để được xem trực tiếp qua mạng Internet (giả sử các bitrate phát và tốc độ kết nốiInternet tương thích ) MP3 tiêu chuẩn nén là phức tạp, nó sử dụng mặt nạ tâm lý học ,

dự phòng giảm và bit đệm hồ chứa

Nén video trên Internet

Một đoạn video là một chuỗi các hình ảnh, với mỗi hình ảnh thường được hiểnthị với một tốc độ không đổi, ví dụ 24 hoặc 30 hình mỗi giây Một nén, mã hóa hìnhảnh kỹ thuật số bao gồm một loạt các điểm ảnh, với mỗi điểm ảnh được mã hóa thànhmột số bit để respresent độ sáng và màu sắc Có hai loại dư thừa trong video, cả haiđều có thể được khai thác để nén Dư thừa không gian là dư thừa trong một hình ảnhnhất định Ví dụ, một hình ảnh bao gồm chủ yếu là không gian trắng có thể hiệu quảnén Dự phòng thời gian phản ánh sự tái diễn từ hình ảnh đến hình ảnh tiếp theo.Ví dụ,một hình ảnh và hình ảnh tiếp theo là giống hệt nhau, không có lý do tái mã hóa cáchình ảnh tiếp theo , đó là hiệu quả hơn chỉ đơn giản là chỉ ra trong quá trình mã hóahình ảnh tiếp theo được chính xác như nhau Các tiêu chuẩn nén MPEG là một trongnhững kỹ thuật phổ biến nhất nén Chúng bao gồm MPEG 1 cho video chất lượng đĩaCD-ROM ( 1,5 Mbps) , MPEG2 cho video DVD chất lượng cao (3-6 Mbps) và MPEG

4 cho nén video hướng đối tượng Tiêu chuẩn MPEG thu hút rất nhiều từ JPEG chuẩnnén hình ảnh Các tiêu chuẩn nén video H.261 cũng rất phổ biến trong các Internet ,cũng rất nhiều tiêu chuẩn độc quyền.Độc giả quan tâm đến việc học thêm về âm thanh

và video mã hóa được khuyến khích để xem [ Rao ] và [ Solari ]

Tài liệu tham khảo

[ Rao ] K.R Rao và J.J Hwang , kỹ thuật và tiêu chuẩn cho hình ảnh, Video và Audio Coding ,

Prentice Hall , 1996

[ Solari ] S.J Solari , video kỹ thuật số và âm thanh nén , McGraw Hill văn bản, năm 1997

6.2 LƯU TRỮ ÂM THANH VÀ VIDEO TRỰC TUYẾN

Trong những năm gần đây, audio/video trực tuyến trở nên phổ biến với nhiềuứng dụng và là thành phần tiêu thụ chính về băng thông mạng Chúng ta hy vọng xuhướng này vẫn tiếp tục với một vài lý do sau Thứ nhất, giá thành của đĩa cứng đanggiảm theo xu hướng, thậm chí còn giảm nhanh hơn giá thành của việc xử lý và băngthông mạng Việc lưu trữ với giá rẻ sẽ dẫn theo việc tăng theo cấp số nhân số lượnglưu trữ audio video trên Internet Thứ hai, cải thiện hạ tầng mạng Internet, như là truycập tốc độ cao, lưu trữ bản sao video trên mạng và chất lượng dịch vụ tốt sẽ tạo điềukiện đóng góp cho việc lưu trữ audio và video Thứ ba, nhu cầu về video trực tuyếnvới chất lượng cao là rất lớn, ứng dụng sẽ kết hợp việc giao tiếp giữa 2 công nghệ -truyền hình và web theo yêu cầu

Trong việc truy cập audio/video trực tuyến, máy khách sẽ yêu cầu fileaudio/video đã nén nằm ở trên server Như chúng thảo luận trong phần này, thì máychủ có thể là một máy chủ web bình thường hoặc có thể là một máy chủ chuyên biệtcho việc truy cập và xử lý audio/video trực tuyến Tập tin trên máy chủ có thể là nhiềuloại tập tin audio/video với nội dung khác nhau, bao gồm bài giảng của các giáo sư,các bài nhạc rock, phim ảnh, truyền hình, các đoạn ghi hình về sự kiện thể thao …v…v…Khi máy khách gửi yêu cầu, máy chủ truy cập trực tiếp tới tập tin audio/video rồigửi đến client bằng cách gửi tập tin vào socket Hai giao thức kết nối TCP và UDPsocket được dùng trong trường hợp này Trước khi gửi tập tin audio/video lên mạng,tập tin có thể chia thành các phân đoạn nhỏ và các phân đoạn nhỏ này sẽ được đónggói với phần header đặt biệt cho việc vận chuyển gói tin audio/video Giao thức thờigian thực (RTP), được thảo luận cho phần 6.4, là một miền công cộng chuẩn cho việcđóng gói các phân đoạn nhỏ này Một khi máy khách bắt đầu nhận các yêu cầu tập tinaudio/video, máy khách sẽ bắt đầu gắn các phân đoạn này lại trong một vài giây.Người dùng tương tác cũng đòi hỏi một giao thức để tương tác giữa máy khách và máychủ Giao thức thời gian thực, sẽ được thảo luận đến cuối chương này, là giao thứccông cộng chuẩn cung cấp sự tương tác cho người dùng

Audio/video trực tuyến được gửi yêu cầu thường xuyên bởi người dùng thôngqua trình duyệt web Nhưng bởi vì audio/video diễn ra không được tích hợp trực tiếptrong trình duyệt web, nên một ứng dụng trợ giúp riêng biệt là cần thiết cho việc chơicác audio/video Ứng dụng trợ giúp này thường được gọi là media player, thường phổbiến trong các ứng dụng chơi nhạc trên mạng và trong ứng dụng chơi nhạc củaMicrosoft là Windows Media Players Media player cung cấp một vài chức năng, baogồm

- Giải nén: Audio/video thường được nén để tiết kiệm đĩa cứng và băng thôngmạng Ứng dụng chơi nhạc media player sẽ giải nén audio/video trong suốt quátrình chơi nhạc

- Loại bỏ jitter: các gói tin jitter là sự thay đổi về độ trễ trong luồng gói tin đó.Các gói tin jitter, nếu không được loại bỏ có thể dẫn đến các audio và video khóhiểu Chúng ta sẽ bàn ví dụ về trường hợp này trong phần 6.3, các gói tin jitterthường bị giới hạn bởi bộ nhớ đệm audio/video trong một vài giây tại máykhách trước khi phát nhạc

- Lỗi không đúng: Do tắc nghẽn không thể đoán trước trên mạng Internet, mộtphần nhỏ của các gói dữ liệu trong luồng dữ liệu có thể bị mất Nếu phần nàytrở nên quá lớn, người dùng nhận thức chất lượng audio/video trở nên khôngthể chấp nhận Để kết thúc việc này, nhiều hệ thống trực tuyến cố gắng phụchồi từ những gói bị mất bằng cách xây dựng lại các gói tin bị mất thông quaviệc truyền các gói dữ liệu dư thừa, bằng cách máy khách sẽ gửi yêu cầu gửi lạigói bị mất hoặc cả hai

- Giao diện người dùng với nút bấm điều khiển: Đây là giao diện thực mà ngườidùng tương tác với nó Nó bao gồm nút điều khiển âm lượng, nút pause hoặcresume, thanh trượt cho việc nhảy đến một đoạn audio/video …v…v…

Các thành phần hỗ trợ có thể được nhúng vào giao diện của ứng dụng mediatrong cửa sổ của trình duyệt web Ví dụ như phần nhúng, trình duyệt nhúng lưu khônggian màn hình của trang web hiện tại và đặt nó vào ứng dụng media để quản lý Nhưngkhi cả hai hiện lên sẽ hiện trong cửa sổ riêng biệt hoặc trong cửa sổ của trình duyệt(như một thành phần phụ trợ), ứng dụng media là chương trình được thực hiện riêng rẽvới các trình duyệt

6.2.1 Truy cập âm thanh và video từ máy chủ web

Việc lưu trữ xử lý audio/video có thể được thực hiện bên trong Web Server, nơi

mà có nhiệm vụ trung chuyển audio/video đến máy khác thông qua giao thức HTTP,hoặc trên luồng dữ liệu audio/video của server, nơi mà có nhiệm vụ trung chuyểnaudio/video không thông qua giao thức HTTP (giao thức có thể là độc quyền hoặctrong miền công cộng) Trong phần này, chúng tôi đưa ra ví dụ về việc trung chuyểnaudio/video từ Web server, trong phần tiếp theo, chúng tôi đưa ra ví dụ về việc trungchuyển từ luồng dữ liệu server

Liên quan đến trường hợp đầu tiên của việc truyền dữ liệu âm thanh Khi tập

âm thanh nằm trên máy chủ web, tập tin âm thanh này là một đối tượng bình thườnggiống như các tập tin trên server như là tập tin HTML và JPEG Khi người dùng muốnnghe tập tin âm thanh, nó sẽ kết nối bằng giao thức kết nối TCP với máy chủ Web vàgửi yêu cầu HTTP đến đối tượng, khi nhận được yêu cầu, máy chủ Web đóng gói tậptin âm thanh trong gói thông điệp phản hồi HTTP và gửi phản hồi ngược lại thông quakết nối TCP Đối với trường hợp video có thể ít phức tạp hơn, bởi vì audio và video làmôt phần của video có thể lưu trữ trong hai tập tin khác nhau, chúng có thể là hai đốitượng khác nhau trong các tập tin trên máy chủ Web Trong trường hợp này, hai yêucầu HTTP song song được gửi đến máy chủ server (với hai giao thức kết nối songsong là TCP cho HTTP/1.0), và tập tin audio và video nhận tại máy khách trong hailuồng song song Nó sẽ được đồng bộ tại máy khách trong hai luồng Có thể là audio

và video sẽ trong cùng một tập tin, vì thế chỉ một đối tượng được được gửi đến máykhách Để cho cuộc thảo luận này đơn giản, trong trường hợp video, chúng tôi giả địnhaudio và video là nằm trong một file cho phần này

Kiến trúc cho luồng dữ liệu audio/video

- Trình duyệt tạo kết nối TCP với máy chủ Web và gửi yêu cầu tập tinaudio/video với yêu cầu HTTP

- Máy chủ Web gửi lại cho trình duyệt tập tin audio/video trong thông tin phảnhồi HTTP

- Kiểu nội dung: dòng đầu phần header trong giao thức phản hồi HTTP chỉ đếnphần mã hóa đặc biệt của audio/video Trình duyệt máy khách kiểm tra loại nội

dung của thông điệp phản hồi, và chạy ứng dụng media và chuyển tập tin đếnứng dụng media

- Ứng dụng media sẽ gắn kết các tập tin audio/video

Hình 6.2 - : Luồng thực hiện cho tập tin âm thanhMặc dù phương pháp tiếp cận rất đơn giản, nó có một hạn chế chính đó là : ứngdụng media hay trình phát media (hoặc ứng dụng trợ giúp) phải tương tác với máy chủthông qua trình duyệt Web trung gian Từ đây có thể dẫn đến nhiều vấn đề, trongtrường hợp khi trình duyệt trung gian, một đối tượng phải được tải về trước khi trìnhduyệt chuyển đối tượng đến ứng dụng hỗ trợ; kết quả là độ trễ không thể chấp nhậncho tập tin audio/video với độ dài vừa phải Chính vì lý do này, luồng audio/videođược triển khai, server gửi tập tin audio/video trực tiếp đến tiến trình đang chạy trìnhphát media Trong trường hợp khác, một kết nối socket trực tiếp được tạo giữa tiếntrình server và tiến trình của ứng dụng media Như hình ở 6.2.2, đây là trường hợphoàn tất bằng cách dùng “meta file”, là tập tin cung cấp thông tin về tập audio/video

Hình 6.2 - : Máy chủ web gửi trực tiếp tập tin audio/video đến ứng dụng media

Một kết nối TCP trực tiếp giữa máy chủ và ứng dụng media thu được như sau:

1 Người dùng click trên link liên kết tập tin audio/video

2 Link liên kết không trỏ trực tiếp đến tập tin audio/video, nhưng thay vào đó

là trỏ đến tập tin meta Tập tin meta chứa địa chỉ của tập tin audio/videothật Gói tin phản hồi HTTP sẽ đóng gói tập tin meta bao gồm kiểu nộidung: dòng đầu phần header chỉ đến ứng dụng audio/video

3 Trình duyệt máy khách đọc kiểu nội dung trong phần đầu header của góiphản hồi, sau đó chạy ứng dụng media và chuyển phần nội dung của góiphản hồi đến ứng dụng media

4 Ứng dụng media thiết lập kết nối TCP trực tiếp với HTTP server Ứng dụngmedia gửi yêu cầu HTTP cho tập tin audio/video vào trong kết nối TCP

5 Tập tin audio/video sẽ được gửi tới ứng dụng media thông qua gói phản hồiHTTP Sau đó ứng dụng media sẽ chạy luồng audio/video này

Tầm quan trọng của bước trung gian là phải thu nhận các tập tin meta phải rõràng Khi trình duyệt thấy được kiểu nội dung của tập tin, nó có thể chạy ứng dụngmedia, và ứng dụng media sẽ giao tiếp trực tiếp với máy chủ

Chúng ta đã biết làm thế nào một tập tin meta có thể cho phép ứng dụng media

có thể giao tiếp trực tiếp với một máy chủ Web audio / video Tuy nhiên, nhiều công tybán sản phẩm audio / video không giới thiệu kiến trúc , chúng tôi vừa mô tả Điều này

là do các kiến trúc có ứng dụng media giao tiếp với máy chủ qua HTTP và cũng quakết nối TCP HTTP thường được xem là không đủ để làm hài lòng về sự tương tácgiữa người dùng với máy chủ Cụ thể , HTTP không dễ dàng cho phép người dùng

( thông qua máy chủ media ) gửi tạm dừng / tiếp tục, nhanh chóng, trượt về phía trước

và thời gian nhảy lệnh đến máy chủ TCP thường được xem là không phù hợp cho âmthanh / hình ảnh , đặc biệt là khi người dùng có kết nối Internet tốc độ chậm Điều này

là do , khi mất gói tin , tỷ lệ người gửi với kết nối TCP gần như dừng lại, mà có thểdẫn đến thời gian dài của các ứng dụng media dài Tuy nhiên, âm thanh và videothường được truyền từ máy chủ Web với kết nối TCP cho kết quả khả quan

6.2.2 Gửi đa phương tiện từ luồng server đến ứng dụng hỗ trợ

Để nắm được các hoạt động xung quanh các giao thức HTTP hoặc TCP, và tậptin âm thanh/video có thể lưu trữ và được gửi đi từ luồng dữ liệu server đến ứng dụngmedia Luồng dữ liệu tại server có thể là một luồng độc quyền như luồng được thiết kế

và quảng cáo bởi RealNetworks và Microsoft, hoặc luồng với miền server công cộng.Với luồng này, audio/video có thể được gửi thông qua giao thức UDP (chứ không phải

là TCP) dùng giao thức của lớp ứng dụng là HTTP

Kiến trúc này đòi hỏi hai máy chủ, như trong hình 6,2-3 Một máy chủ, máychủ HTTP, phục vụ các trang web (bao gồm cả các tập tin meta) Các máy chủ thứ hai, các máy chủ streaming , phục vụ các tập tin audio / video Hai máy chủ có thể chạytrên các hệ thống cuối cùng hoặc trên hai hệ thống kết thúc khác nhau ( Nếu máy chủWeb là rất bận rộn phục vụ các trang web , nó có thể được thuận lợi để đặt máy chủstreaming trên máy tính riêng của mình ) Các bước cho kiến trúc này cũng tương tựnhư mô tả trong kiến trúc trước đó Tuy nhiên , hiện nay các phương tiện truyền thôngyêu cầu các tập tin từ một máy chủ streaming chứ không phải là từ một máy chủ Web ,

và bây giờ ứng dụng media và máy chủ streaming có thể tương tác bằng cách sử dụnggiao thức riêng của họ Các giao thức này có thể cho phép người dùng tương tác phongphú với các dòng âm thanh / video Hơn nữa, các tập tin audio / video có thể được gửiđến máy nghe nhạc phương tiện truyền thông trên UDP thay vì TCP

Hình 6.2 - : Luồng từ máy chủ streaming đến ứng dụng media

Trong kiến trúc của hình 6,2-3 , có nhiều tùy chọn để cung cấp âm thanh / video

từ các máy chủ streaming đến ứng dụng media Một phần danh sách các tùy chọn đượcđưa ra dưới đây :

1 Âm thanh / video được gửi qua UDP với một tốc độ không đổi tương đương với tỷ

lệ cống ở người nhận ( đó là tốc độ mã hóa của âm thanh / video) Ví dụ, nếu âmthanh được nén sử dụng GSM với tốc độ 13 Kbps, sau đó xung nhịp đồng hồ máy chủnén các tập tin âm thanh ở 13 Kbps Ngay sau khi máy khách nhận được tập tin nénaudio / video từ mạng, nó giải nén âm thanh / video và chơi nó trở lại

2 Điều này tương tự như tùy chọn 1 , nhưng sự chậm trễ của ứng dụng media diễn ratrong 2-5 giây để loại bỏ mạng gây ra jitter Máy khách kết thúc nhiệm vụ này bằngcách đặt các tập tin media nén mà nó nhận được từ mạng vào một bộ đệm của nó, nhưtrong hình 6,2-4 Một khi máy khách đã " nạp trước " một vài giây của tập tin meida ,

nó bắt đầu lấy từ các vùng đệm Đối với điều này và các tùy chọn trước đó , tỷ lệ cống

d bằng với tỷ lệ lấp đầy x (t) , ngoại trừ khi có mất gói tin

3 Âm thanh được gửi qua giao thức TCP và sự chậm trễ media player diễn ra trong

2-5 giây Máy chủ truyền dữ liệu với giao thức TCP với một tốc độ không đổi tươngđương với tỷ lệ cống thu d Giao thức TCP truyền lại các gói tin bị mất, và do đó cóthể cải thiện chất lượng âm thanh Nhưng tỷ lệ lấp đầy x (t) tại biến động theo thờigian do TCP khởi đầu chậm chạp và kiểm soát dòng chảy cửa sổ, ngay cả khi không

có mất gói tin Nếu không có gói tin bị mất , trung bình tỷ lệ lấp đầy gần bằng với tỷ lệcống d Hơn nữa, sau khi kiểm soát tắc nghẽn mất gói tin TCP có thể làm giảm tỷ lệ

đến tức thời ít hơn d trong thời gian dài của thời gian Vùng bộ nhớ đệm này của máykhách có thể trống và lúc này sẽ tạm dừng và hiển thị ra đầu ra của luồng audio/videotại máy khách.

4 Điều này tương tự như phương án 3, nhưng bây giờ các phương tiện truyền thôngtại máy khách sử dụng một bộ đệm lớn - đủ lớn để giữ nhiều nếu không phải tất cả các

âm thanh / video nộp (có thể lưu trữ trong đĩa) Máy chủ đẩy các tập tin audio / videovới giao thức TCP đến máy khách và máy khách đọc dữ liệu từ Socket TCP và đặtvideo âm thanh giải nén vào bộ đệm tại máy khách Trong trường hợp này , TCP sửdụng tất cả các băng thông có sẵn để kết nối, vì vậy ở lần x (t) có thể lớn hơn nhiều sovới d Khi những băng thông tức thời dưới mức cống , người nhận không bị mất dữliệu khi bộ đệm của máy khách là không rỗng

Hình 6.2 - : Bộ nhớ đệm máy khách x(t) và d

6.2.3 Giao thức truyền dòng dữ liệu thời gian thực

Âm thanh, video và SMIL, v…v…, thường được gọi là phương tiện truyềnthông liên tục ( SMIL là viết tắt của đồng bộ đa phương tiện Ngôn ngữ, nó là mộtngôn ngữ chuẩn , ví dụ như là HTML Như tên gọi của nó , SMIL định nghĩa như thếnào là đối tượng phương tiện truyền thông liên tục, cũng như các đối tượng tĩnh , đượcđồng bộ hóa trong một bài trình bày sáng tỏ theo thời gian Một cuộc thảo luận sâu sắccủa SMIL là vượt quá phạm vi của cuốn sách này ) Người dùng thường muốn kiểmsoát phát lại audio hay video liên tục bằng cách tạm dừng, phát lại hoặc nhảy đến 1điểm muốn phát, phát lại nhanh chóng chuyển tiếp trực quan , phát tua trực quan , vv chức năng này tương tự như những chức năng khi xem một băng video hoặc với mộtđĩa CD, máy nghe nhạc khi nghe nhạc CD Để cho phép người dùng kiểm soát phátlại, các ứng dụng media và máy chủ cần một giao thức để trao đổi phát lại kiểm soátthông tin RTSP , được định nghĩa trong [ RFC 2326 ], là một giao thức như vậy

Nhưng trước khi đi vào các chi tiết của RTSP , chúng ta hãy chỉ ra những gì RTSPkhông làm được:

- RTSP không xác định được chương trình nén âm thanh và video

- RTSP không định nghĩa như thế nào âm thanh và video được đóng gói trongcác gói tin truyền qua mạng, đóng gói cho ứng dụng media có thể được cungcấp bởi RTP hoặc một giao thức độc quyền ( RTP được thảo luận trong phần6.4) Ví dụ, máy chủ G2 và máy nghe nhạc sử dụng RealMedia của RTSP để gửithông tin điều khiển với nhau Nhưng ứng dụng media chính nó có thể đượcđóng gói gói tin RTP hoặc với một số chương trình độc quyền nhưRealNetworks

- RTSP không hạn chế làm thế nào các ứng dụng media có thể được chuyển đi ,

nó có thể được vận chuyển qua UDP hoặc TCP

- RTSP không hạn chế làm thế nào các ứng dụng media đưa audio/video vào bộđệm Audio / video có thể được diễn ra ngay sau khi nó bắt đầu đến máykhách , nó có thể được diễn ra sau khi một sự chậm trễ của một vài giây , hoặc

nó có thể được tải về toàn bộ trước khi diễn ra

Vì vậy, nếu RTSP không làm bất kỳ điều gì ở trên, vậy RTSP làm gì? RTSP làmột giao thức cho phép một ứng dụng media điều khiển việc truyền tải một luồngmedia Như đã đề cập ở trên, hành động kiểm soát bao gồm pause / resume , tái định vị

và phát lại, nhanh chóng chuyển tiếp và tua lại RTSP còn được gọi là giao thức out-of-band Đặc biệt, các mẩu tin RTSP đượcgửi out-of -band, trong khi các dòng phươngtiện truyền thông, có cấu trúc gói tin không được xác định bởi RTSP, được coi là " in-band" Các tin nhắn RTSP sử dụng các cổng khác nhau hơn so với các dòng phươngtiện truyền thông RTSP sử dụng cổng số 554 ( Nếu các thông điệp RTSP đã sử dụng

số cổng tương tự như các dòng phương tiện truyền thông, sau đó tin nhắn RTSP sẽđược cho là " xen kẽ " với các dòng phương tiện truyền thông ) Các đặc điểm kỹthuật RTSP [ RFC 2326 ] cho phép thông điệp RTSP được gửi qua TCP hoặc UDP.Nhớ lại từ phần 2.3 rằng giao thức truyền file (FTP) cũng sử dụng khái niệm out-of -band Đặc biệt, FTP sử dụng hai cặp client / server của 2 giao thức, mỗi cặp với sốcổng riêng của mình: một cặp socket client / server hỗ trợ kết nối TCP vận chuyểnkiểm soát thông tin, cặp client / server với giao thức hỗ trợ kết nối TCP mà thực sựvận chuyển các tập tin Kết nối điều khiển TCP được gọi là out-of –band trong khi kết

nối TCP vận chuyển các tập tin là cái gọi là kênh dữ liệu Kênh out-of -band được sửdụng cho việc thay đổi các thư mục từ xa , xóa tập tin từ xa , đổi tên tập tin từ xa, yêucầu tập tin tải về, v…v… kênh in-band vận chuyển các tập tin đó Kênh RTSP theonhiều cách tương tự như kênh điều khiển FTP Bây giờ chúng ta đi qua một ví dụ đơngiản RTSP, được minh họa trong hình 6,2-5 Trình duyệt web đầu tiên yêu cầu mộttập tin mô tả trình bày từ một máy chủ Web Các tập tin mô tả trình bày có thể có thamchiếu đến một số tập tin liên tục phương tiện truyền thông cũng như chỉ thị cho đồng

bộ các tập tin liên tục với ứng dụng media Mỗi tham chiếu đến một tập tin liên tụcđến ứng dụng media bắt đầu với phương pháp URL , rtsp :/ / Dưới đây chúng tôicung cấp một tập tin mẫu trình chiếu, đã được chuyển thể từ giấy Trong bài trình bàynày, một âm thanh và hình ảnh video được chơi song song và lipsync ( như là mộtphần của cùng một " nhóm" ) Cho dòng âm thanh , máy nghe nhạc phương tiện truyềnthông có thể lựa chọn ( "chuyển đổi" ) trong hai bản ghi âm, ghi âm trung thực thấp vàghi âm trung thực cao

Máy chủ Web đóng gói các tập tin mô tả trình bày trong một thông điệp trả lờiHTTP và gửi thông báo cho trình duyệt Khi trình duyệt nhận được tin nhắn phản hồiHTTP , trình duyệt chạy sẽ là một ứng dụng media (ví dụ, ứng dụng trợ giúp ) dựa trênkiểu nội dung : trường của tin nhắn Các tập tin mô tả trình bày bao gồm tài liệu thamkhảo để phương tiện truyền thông dòng, sử dụng phương pháp URL rtsp :/ / , nhưtrong ví dụ trên

Như thể hiện trong hình 6,2-4 , máy nghe nhạc và máy chủ sau đó gửi cho nhaumột loạt các tin nhắn RTSP Các ứng dụng gửi một yêu cầu SETUP RTSP, và máy chủ

sẽ gửi một phản hồi SETUP RTSP Các ứng dụng gửi một yêu cầu RTSP PLAY, , vàmáy chủ sẽ gửi phản hồi RTSP PLAY

Tại thời điểm này , các máy chủ streaming đưa âm thanh vào kênh hay băng tần củariêng mình Sau đó, các ứng dụng media sẽ gửi một yêu cầu PAUSE RTSP, và máychủ đáp ứng với một phản hồi PAUSE RTSP Khi người dùng kết thúc, các ứng dụngmedia sẽ gửi một yêu cầu TEARDOWN RTSP, và máy chủ đáp ứng với một phản ứngTEARDOWN RTSP

Hình 6.2 - : Tương tác giữa máy khách và máy chủ dùng RSTP

Mỗi phiên RTSP có một định danh phiên, được lựa chọn bởi các máy chủ Máykhách khởi tạo phiên với yêu cầu SETUP, và máy chủ đáp ứng các yêu cầu cho mộtđịnh danh Máy khách lặp đi lặp lại các định danh phiên cho mỗi yêu cầu, cho đến khi

máy khách đóng phiên với yêu cầu teardown Sau đây là một ví dụ đơn giản của mộtphiên RTSP :

C : SETUP rtsp :/ / audio.example.com / twister / âm thanh RTSP/1.0

Vận chuyển : RTP / UDP , nén ; port = 3056 ; chế độ = PLAY

Tài liệu tham khảo

[Schulzrinne] H Schulzrinne, "A Comprehensive Multimedia Control Architectuurefor the Internet," NOSSDAV'97 (Network and Operating System Support for DigitalAudio and Video), St Louis, Missouri; May 19, 1997 Online version available.[RealNetworks] RSTP Resource: http://www.real.com/devzone/library/fireprot/rtsp/ [RFC 2326] H Schulzrinne, A Rao, R Lanphier, "Real Time Streaming Protocol(RTSP)", RFC 2326, April 1998

6.3 LÀM TỐT NHẤT DỊCH VỤ BEST EFFORT – MỘT

VÍ DỤ VỀ ĐIỆN THOẠI INTERNET

Giao thức lớp mạng, địa chỉ IP, cung cấp một dịch vụ best-effort (nỗ lực tối đa).Điều đó nói rằng mạng Internet cố gắng tốt nhất để di chuyển mỗi gói dữ liệu từ nguồnđến đích càng nhanh càng tốt Tuy nhiên, dịch vụ best-effort không thực hiện bất kỳlời hứa nào về mức độ chậm trễ từ nguồn đến đích cho một gói tin riêng lẻ, hoặc theomức độ biến động của gói tin và mất gói trong luồng truyền gói tin

Các ứng dụng đa phương tiện tương tác trên thời gian thực, như điện thoạiInternet và hội nghị truyền hình trực tuyến, ảnh hưởng sâu sắc đến độ trễ gói tin, sựbiến động và sự mất mát May mắn thay, các nhà thiết kế của các ứng dụng này có thểđưa ra một số cơ chế hữu ích có thể bảo vệ tốt âm thanh và video miễn là độ trễ, sựbiến động và sự mất mát không quá cao Trong phần này chúng ta xem xét một số các

cơ chế này Để thảo luận được cụ thể, chúng ta thảo luận về những cơ chế trong bốicảnh của một ứng dụng điện thoại Internet, được mô tả trong đoạn dưới dây Tìnhhuống tương tự như cho ứng dụng hội nghị truyền hình trực tuyến [Bolot 1994]

Loa trong ứng dụng điện thoại Internet của chúng ta tạo ra một tín hiệu âmthanh xen kẻ bao gồm giai đoạn đàm thoại tăng vọt và giai đoạn im lặng Để tiết kiệmbăng thông, ứng dụng điện thoại Internet của chúng ta chỉ tạo ra các gói tin trong giaiđoạn đàm thoại tăng vọt Trong giai đoạn bứt phá của cuộc trò chuyện người gửi tạo rabyte với nhịp độ 8 Kbytes mỗi giây, và cứ mỗi 20 mili giây người gửi tập hợp các bytevào một đoạn Như vậy số lượng các byte trong một đoạn (20 msecs)*(8 Kbytes/giây)

= 160 bytes Một tiêu đề đặc biệt được gắn liền với mỗi đoạn, nội dung của nó đượcthảo luận dưới đây Các đoạn cùng với tiêu đề của nó được đóng gói trong một phânđoạn UDP, và sau đó gói dữ liệu UDP được gửi vào giao diện socket Như vậy, trongmột gia đoạn bứt phá của cuộc trò chuyện thì một đoạn UDP sẽ được gửi mỗi 20 miligiây

Nếu mỗi gói tin gửi đến người nhận (không mất mát) và một hằng số độ trễ nhỏ

từ nguồn đến đích, sau đó các gói tin đi đến người nhận định kỳ mỗi 20 mili giây tronggiai đoạn bứt phá của cuộc trò chuyện Trong những điều kiện lý tưởng, người nhận có

thể chỉ đơn giản là có thể phát lại từng đoạn ngay sau khi nó đến Nhưng không may,một vài gói tin có thể bị mất và hầu hết các gói tin sẽ không có một sự trì hoãn cố định

từ nguồn đến đích nào, dù chỉ là một sự tắc nghẽn Internet nhẹ Vì lý do này , ngườinhận phải quan tâm nhiều hơn trong (i) xác định khi phát lại một đoạn, và (ii) xác địnhphải làm gì với một đoạn bị mất

nó đi qua bộ đệm (tức là, hàng đợi) trong các bộ định tuyến để truy cập các liên kếtngoài Có thế là một hoặc nhiều bộ đệm trong các tuyến đường từ người gửi đến ngườinhận là đầy đủ và không thể thừa nhận các gói dữ liệu IP Trong trường hợp này, gói

dữ liệu IP bị loại bỏ và trở thành một gói tin bị mất Nó không bao giờ đến được ứngdụng nhận

Mất mát có thể được loại bỏ bằng cách gửi các gói tin qua giao thức TCP chứkhông phải trên UDP Nhớ rằng TCP truyền lại các gói tin không đến được đích Tuynhiên, cơ chế truyền lại nói chung là không thể chấp nhận để tương tác được đối vớiứng dụng âm thanh thời gian thực Chẳng hạn như điện thoại Internet, vì chúng làmtăng sự chậm trễ từ nguồn đến đích [Bolot 1996] Hơn nữa, do TCP kiểm soát tắtnghẽn, sau khi mất gói tin tốc độ truyền tin ở người gửi có thể bị giảm xuống một mứcthấp hơn so với tỷ lệ nhận ở người nhận Điều này có thể có tác động nghiêm trọngđối với tính dễ hiểu của âm thanh ở người nhận Vì những lý do trên, hầu hết các ứngdụng điện thoại Internet hiện nay chạy trên UDP và có quan tâm đến sự mất mát góitin

Nhưng mất gói tin không nhất thiết là nghiêm trọng như người ta có thể nghĩ.Trên thực tế, tỷ lệ mất gói tin từ 1% cho đến 20% có thể được chấp nhận, tùy thuộc

vào cách âm thanh là được mã hóa và truyền đi, và làm các nào sự mất mát được chegiấu tại người nhận Ví dụ, việc sửa lỗi (FEC) có thể giúp che giấu sự mất mát gói tin.Như chúng ta sẽ thấy dưới đây, với thông tin dư thừa FEC được truyền cùng với thôngtin gốc do đó một vài dữ liệu gốc bị mất có thể được phục hồi từ những thông tin dưthừa Tuy nhiên, nếu một hoặc nhiều hơn các liên kết giữa người gửi và người nhận bịtắc nghẽn, và mất mát gói tin vượt quá 10-20%, sau đó thực sự là không có gì có thểđược hoàn thành đề đạt được chất lượng âm thanh có thể chấp nhận được Dịch vụBest-effort vẫn có hạn chế của nó.

Độ trễ từ nguồn đến đích

Độ trễ từ nguồn đến đích là sự tích tụ xử lý và hàng đợi chậm trễ trong bộ các

bộ định tuyến, độ trễ truyền tải, và độ trễ xử lý của hệ thống cuối Cho các ứng dụng

âm thanh tương tác cao, như điện thoại Internet, độ trễ từ nguồn đến đích nhỏ hơn 150mili giây không được nhận thấy bằng sự lắng nghe của con người; độ trễ từ 150 đến

400 mili giây có thể chấp nhận được nhưng không lý tưởng, và độ trễ quá 400 miligiây cho kết quả trong cuộc hội thoại bằng giọng nói

Người nhận trong ứng dụng điện thoại Internet thông thường sẽ bỏ qua bất kỳ gói tinnào bị trì hoãn hơn 1 ngưỡng nào đó Do đó, các gói tin bị trì hoãn hơn ngưỡng chophép sẽ bị mất hiệu quả

Ví dụ, xem xét hai gói tin liên tiếp trong giai đoạn tăng vọt của cuộc nói chuyệntrong ứng dụng điện thoại Internet của chúng tôi Người gửi gửi gói tin thứ 2 trong 20mili giây sau khi gửi gói tin đầu tiên Nhưng ở người nhận khoảng cách giữa các góitin có thể trở nên lớn hơn 20 ms Để thấy điều này, giả sử gói tin đầu tiên được gửi đếnhàng đợi gần như rỗng tại bộ định tuyến, nhưng ngay trước khi gói tin thứ hai đếnhàng đợi, một số lượng lớn các gói tin từ các nguồn khác đến để vào cùng một hàng

đợi giống nhau Vì gói tin thứ 2 chịu một sự trì hoãn tại hàng đợi lớn, gói tin đầu tiên

và thứ hai cách nhau hơn 20 mili giây (Trong thực tế, khoảng cách giữa 2 gói tin liêntiếp có thể trở thành 1 giây hoặc nhiều hơn) Khoảng cách giữa các gói tin liên tiếpcũng có thể trở thành ít hơn 20 mili giây Để thầy điều này, ta lại xem xét hai gói liêntiếp trong một vòng tăng vọt âm thanh cuộc trò chuyện Giả sử gói tin đầu tiên thamgia vào phần cuối của hàng đợi với số số lượng lớn các gói tin, và gói tin thứ hai đếnhàng đợi trước khi các gói tin từ các nguồn khac đến hàng đợi Do đó, hai gói tin củachúng tôi thấy chính mình ngay đằng sau mỗi gói khác trong hàng đợi Nếu thời giancần để truyền gói tin trên các liên kết ra ngoài từ router là ít hơn 20 mili giây, thì sau

đó các gói tin đầu tiên và thứ hai có khoảng cách ít hơn 20 mili giây

Tình huống tương tự với lái xe ô tô trên đường Giả sử bạn và bạn của bạn làmỗi lái xe trong ô tô riêng của bạn từ San Diego đến Phoenix Giả sử bạn và bạn củabạn có kiểu lái xe tương tự, và rằng cả hai lái ở tốc độc 100km/giờ, giao thông phép.Cuối cùng, giả sử bạn của bạn bắt đầu tiến hành trước bạn một giờ Sau đó, tùy thuộcvào lưu lượng can thiệp, bạn có thể đến Phoenix nhiều hoặc ít hơn 1 giờ sau bạn củabạn

Nếu người nhận bỏ qua sự có mặt của sự biến động, và phát ra khối ngay saukhi chúng đến nơi, sau đó kết quả chất lượng âm thanh có thể dễ dàng trở nên khó hiểu

ở người nhận May mắn là, sự biến động thường có thể được loại bỏ bằng cách sửdụng số thứ tự, nhãn thời gian và độ trễ bên ngoài,như chúng tôi thảo luận dưới đây

6.3.2 Loại bỏ biến động nhận được cho âm thanh

Cho ứng dụng bằng giọng nói như điện thoại Internet hoặc âm thanh theo yêucầu, người nhận phải cố gắng cung cấp đồng bộ khung tin khối tiếng nói với sự cómặt của biến động mạng ngẫu nhiên Điều này thường được thực hiện bằng cách kếthợp ba cơ chế sau:

- Cách thêm một số thứ tự trên mỗi đoạn Người gửi tăng giá trị số thứ tự củamỗi gói tin mà nó tạo ra

- Cách thêm một nhãn thời gian trên từng đoạn Các nhãn trên mỗi khối màngười gửi cùng với thời gian từ đó các đoạn được tạo ra

- Trì hoãn phát lại các đoạn ở người nhận Sự trì hoãn phát lại của các đoạn

âm thanh phải đủ lâu để hầu hết các gói tin nhận được trước khi thời gian

phát lại dự kiến của chúng Trì hoãn phát lại này vừa có thể cố định trongsuốt thời gian của hội nghị, hay có thể thay đổi một cách thích ứng trongsuốt thời gian hoạt động của hội nghị Các gói tin không đến trước thời gian

dự kiến phát lại của chúng được coi là bị mất và lãng quên, như đã đề cập ởtrên, người nhận có thể sử dụng một số hình thức của hình thức nội suy bàinói để che giấu đi sự mất mát

Số thứ tự và nhãn thời gian chiếm lĩnh trong tiêu đề của các khối âm thanh Mộtđịnh dạng chuẩn hóa cho các tiêu đề của âm thanh được mô tả trong phần tiếp theo

Bây giờ chúng ta thảo luận về hoạt động của ba cơ chế này, khi kết hợp, có thểlàm giảm hoặc thậm chí loại bỏ những ảnh hưởng của biến động Chúng ta kiểm trahai kế hoạch phát lại: trì hoãn phát lại cố định và thích ứng trì hoãn phát lại

Trì hoãn phát lại cố định

Với chiến lược trì hoãn cố định, người nhận cố gắng phát lại mỗi khối chínhxác q mili giây sau khi khối này được tạo ra Vì vậy, nếu một khối là nhãn thời gian tạithời điểm t, người nhận phát ra khối tại thời điểm t+q, giả sử các khối đã đến theo dựkiến phát lại tại thời điểm t+q Các gói tin đến sau lần phát lại theo kế hoạch của chúng

sẽ bị loại bỏ và được coi là bị mất

Lưu ý rằng số thứ tự không cần thiết cho chiên lược trì hoãn cố định này Cũnglưu ý rằng ngay cả trong sự có mặt thỉnh thoảng của gói tin bị mất, chúng ta vẫn có thểtiếp tục vận hoạt động chiến lược trì hoãn cố định

Một lựa chọn tốt của q là gì? Điện thoại Internet có thể hổ trợ trì hoãn lên đếnkhoảng 400 mili giây, mặc dù trải nghiệm tương tác thỏa mãn hơn là đạt được với cácgiá trị nhỏ hơn của q Mặc khác, nếu q được làm nhỏ hơn nhiều so với 400 mili giây,sau đó nhiều gói tin có thể bỏ lỡ thời gian phát lại theo kế hoạch của chúng do mạnggây ra trì hoãn biến động Đại khái nếu có sự thay đổi lớn trong trì hoãn end-to-end làđiển hình, tốt nhất là sử dụng q lớn, mặt khác, nếu trì hoãn là nhỏ và các biến thể chậmtrễ cũng là nhỏ, nó thích hợp hơn để sử dụng một q nhỏ, có lẽ ít hơn 150 mili giây

Sự cân bằng giữa sự trì hoãn phát lại và mất gói tin được minh họa trong hình6.3-1 Số liệu này cho thấy thời gian mà gói tin được tạo ra và diễn ra trong một cuộcnói chuyện tăng vọt duy nhất Hai sự trì hoãn phát lại ban đầu riêng biệt được xem xét

Khi thể hiện bằng bên trái của bậc thang nhất, người gửi tạo ra gói tin đều nhau – cụthể, mỗi 20 mili giây Gói đầu tiên trong bài nói chuyện bứt phá này nhận được vàothời điểm r Như thể hiện trong hình, lượt đến của các gói tin tiếp theo không đều nhau

do biến động mạng

Đối với lịch trình phát lại đầu tiên, sự trì hoãn phát lại cố định được thiết lập đểp-r Với lịch trình này, gói tin thứ tư không đến bởi thời gian phát lại theo lịch trình, vàngười nhận coi nó bị mất.Đối với lịch trình phát lại thứ hai, sự trì hoãn phát lại ban đầu

cố định được thiết lập để p’-r Cho lịch trình này tất cả các gói tin đến trước khi thờigian lịch trình phát lại của chúng, và do đó không bị mất

Hình 6.3 - : Mất gói tin vì trì hoãn phát lại cố định khác

Thích ứng với độ trễ phát lại

Ví dụ trên cho thấy một điều quan trọng của sự cân bằng trì hoãn – mất phátsinh khi thiết kế một chiến lược phát lại với sự trì hoãn phát lại cố định Bằng cách làmcho sự chậm trễ phát xạ lớn ban đầu, hầu hết các gói dữ liệu sẽ làm cho thời hạn của

họ và do đó sẽ có mất mát không đáng kể, tuy nhiên, cho tương tác các dịch vụ nhưđiện thoại Internet, trì hoãn lâu dài có thể trở thành khó chịu nếu không không thểchấp nhận Lý tưởng nhất, chúng tôi muốn sự chậm trễ phát xạ phải được giảm thiểuchịu sự ràng buộc mà mất được dưới một vài phần trăm

Một cách tự nhiên để đối phó với sự cân bằng này là để ước tính sự chậm trễmạng và phương sai của sự chậm trễ mạng, và để phù hợp điều chỉnh sự chậm trễ phát

xạ ở đầu mỗi talkspurt Điều chỉnh thích nghi này của sự chậm trễ phát xạ vào đầu củatalkspurts sẽ làm cho thời gian im lặng của người gửi được nén và kéo dài, tuy nhiên,nén và kéo dài của sự im lặng bằng một số tiền nhỏ là không đáng chú ý trong bài phátbiểu

Trong bài báo [Ramjee 1994], bây giờ chúng ta mô tả một thuật toán chungchung mà người nhận có thể sử dụng để điều chỉnh thích nghi chậm trễ phát xạ của nó.Này kết thúc, chúng ta hãy

= nhãn thời gian của gói tin thứ i = thời gian gói tin được tạo ra bời người gửi

= thời gian gói tin thứ i nhận được

= thời gian gói tin thứ i phát lại

Sự trì hoãn mạng end-to-end của gói tin thứ i là ri-ti Do biến động mạng, sự trì hoãn này sẽ thay đổi từ gói đến gói Để di biểu thị một ước tính của sự trì hoãn mạng

trung bình sau khi nhận được các gói tin thứ i Ước tính này được xây dựng từ cácnhãn thời gian như sau:

Nơi u là một hằng số cố định (ví dụ, u=0.1) Do đó di là một trung bình vuốtcủa mạng lưới quan sát chậm r1 - t1, , ri - ti; Dự toán đặt trọng lượng thêm về sựchậm trễ mạng gần đây quan sát hơn vào sự chậm trễ mạng quan sát của quá khứ xaxôi Hình thức này ước tính không nênhoàn toàn xa lạ, một ý tưởng tương tự được sửdụng để ước lượng thời gian chuyến đi vòng quanh, như được thảo luận trong chương

3 Cho vi biểu thị ước tính độ lệch trung bình của sự chậm trễ từ sự chậm trễ trungbình ước tính Ước tính này cũng được xây dựng từ các nhãn thời gian:

Ước tính di và vi được tính toán cho mỗi gói tin nhận được, mặc dù chúng chỉ

được sử dụng để xác định điểm phát lại cho các gói dữ liệu đầu tiên trong bất kỳ giaiđoạn tăng vọt của cuộc nói chuyện

Một khi đã tính toán những ước tính này, người nhận sử dụng các thuật toán sau

đây cho phát lại của các gói tin Nếu gói tin i là gói đầu tiên của một trong bất kỳ giai đoạn tăng vọt của cuộc nói chuyện, thời gian phát lại của nó, pi, được tính như sau:

Trong đó K là một hằng số dương (ví dụ, K = 4) Mục đích của việc hạn vi K là

để thiết lập thời gian phát xạ đủ xa trong tương lai để chỉ một phần nhỏ của các gói tinđến trong bứt phá nói chuyện sẽ bị mất do đến trễ Điểm phát xạ cho bất kỳ gói tiếptheo trong sự bứt phá nói chuyện được omputed như một bù đắp từ thời điểm khi cácgói dữ liệu đầu tiên trong talkspurt đã được diễn ra Đặc biệt, chúng ta hãy

là thời gian từ khi các gói dữ liệu đầu tiên trong bứt phá nói chuyện được tạo ra chođến khi nó được diễn ra Nếu gói j cũng thuộc về nói chuyện bứt phá này, nó được diễn ra vào thời điểm

Các thuật toán được mô tả có ý nghĩa hoàn hảo giả định rằng người nhận có thểnói cho dù một gói là gói đầu tiên trong bứt phá nói chuyện Nếu không có gói tin bịmất, sau đó người nhận có thể xác định xem gói tin tôi là gói đầu tiên của bứt phá nóichuyện bằng cách so sánh dấu thời gian của gói tin thứ i với dấu thời gian của (i-1) stgói Thật vậy, nếu ti - ti-1> 20 msec, sau đó người nhận biết rằng thứ i gói tin bắt đầumột talkspurt mới Nhưng bây giờ giả sử có mất gói tin occassional Trong trường hợpnày hai gói tiếp nhận đã nhận được có thể có nhãn thời gian mà khác nhau hơn 20msec khi hai gói thuộc về talkspurt cùng Vì vậy, đây là nơi mà các số thứ tự trở nênhữu ích Người nhận có thể sử dụng số thứ tự để xác định xem> 20 msec sự khác biệttrong nhãn thời gian là do một talkspurt mới hoặc gói tin bị mất

6.3.3 Phục hồi gói tin bị mất

Chúng tôi đã thảo luận chi tiết làm thế nào một ứng dụng điện thoại Internet cóthể đối phó với jitter gói Bây giờ chúng ta mô tả ngắn gọn một vài chương trình mà cốgắng để đảm bảo chất lượng âm thanh có thể chấp nhận sự hiện diện của mất gói tin

Đề án như vậy được gọi là chương trình phục hồi mất mát Ở đây chúng tôi xác định

gói tin bị mất trong một nghĩa rộng: một gói tin bị mất nếu một trong hai nó không baogiờ đến được người nhận hoặc nếu nó đến sau thời gian phát xạ theo lịch trình Internet

ví dụ điện thoại của chúng tôi một lần nữa sẽ phục vụ như là một bối cảnh để mô tảcác chương trình phục hồi mất mát

Như đã đề cập ở phần đầu của phần này, phát lại các gói dữ liệu bị mất là khôngthích hợp trong một ứng dụng tương tác thời gian thực như điện thoại Internet Thậtvậy, phát lại một gói tin bị mất thời hạn phát xạ của nó phục vụ hoàn toàn không cómục đích Và phát lại một gói tin tràn một hàng đợi bộ định tuyến bình thường khôngthể được thực hiện nhanh chóng Bởi vì truyền lại là không phù hợp, các ứng dụngđiện thoại Internet thường sử dụng một số loại chương trình giảm dự đoán Hai loại đề

án thua lỗ anticipiation là điều chỉnh về phía trước-lỗi (FEC) và đan xen

Sửa lỗi chuyển tiếp (FEC)

Ý tưởng cơ bản của FEC là thêm thông tin dư thừa vào dòng gói tin ban đầu Đối với chi phí nhẹ tăng tốc độ truyền tải của âm thanh của dòng , các thông tin dưthừa có thể được sử dụng để tái tạo lại " xấp xỉ " hoặc các phiên bản chính xác của một

số các gói tin bị mất Sau [ Bolot 1996] và [ Perkins 1998] , bây giờ chúng tôi phácthảo hai cơ chế FEC Cơ chế đầu tiên gửi một dư thừa mã hóa đoạn sau mỗi khối n Các đoạn dư thừa thu được bằng độc quyền OR- ing các khối ban đầu n [ Shacham1990] Theo cách này nếu có một gói nhóm n +1 gói bị mất, người nhận hoàn toàn cóthể tái tạo lại các gói tin bị mất Nhưng nếu hai hay nhiều gói trong một nhóm bị mất,ther nhận có thể không reconstuct các gói tin bị mất Bằng cách giữ cho n +1, kíchthước nhóm , nhỏ , một phần lớn của các gói tin bị mất có thể được phục hồi khi mất làkhông quá nhiều Tuy nhiên, kích thước nhỏ hơn nhóm , lớn hơn sự gia tăng tương đốicủa tốc độ truyền của dòng âm thanh Đặc biệt, tốc độ truyền tăng theo hệ số 1 / n , ví

dụ, nếu n = 3 , sau đó tăng tốc độ truyền tải 33% Hơn nữa, chương trình đơn giản nàylàm tăng phát xạ trì hoãn bởi vì người nhận phải nhận được toàn bộ nhóm các gói tintrước khi nó có thể phát xạ một nhóm ( Trong một talkspurt , lịch trình thu định kỳphát lại của các khối dựa trên kịch bản trường hợp xấu nhất - cụ thể là, các gói đầu tiêntrong một nhóm bị mất trong một số nhóm Điều này đòi hỏi người nhận trì hoãn phátlại của mỗi gói cho thời gian cần để nhận được cả một nhóm )

Cơ chế FEC thứ hai để gửi một dòng âm thanh chất lượng thấp hơn như cácthông tin cần thiết Ví dụ , người gửi sẽ tạo ra một dòng âm thanh danh nghĩa và tỷ lệbit thấp dòng âm thanh tương ứng (Các dòng danh nghĩa có thể là một mã hóa PCM

64 Kbps và dòng chất lượng thấp hơn có thể là một mã hóa GSM tại 13 Kbps ) Cácdòng tốc độ thấp -bit được gọi là dòng không cần thiết

Như thể hiện trong hình 6,3-2 , người gửi xây dựng n gói tin bằng cách lấy đoạn thứ n

từ dòng danh nghĩa và phụ thêm vào đó ( n-1) st đoạn từ các dòng không cần thiết.Theo cách này, bất cứ khi nào có mất gói tin không liên tiếp , người nhận có thể chegiấu sự mất mát bằng cách chơi các tốc độ bit thấp đoạn mã hóa mà đến với các gói tintiếp theo Tất nhiên, khối thấp tốc độ bit cho chất lượng thấp hơn so với các khối danhnghĩa , nhưng một dòng chủ yếu là khối chất lượng cao, khối chất lượng thấp thườngxuyên và không có khối thiếu cho chất lượng âm thanh tốt tổng thể Lưu ý rằng trongchương trình này , người nhận chỉ phải nhận hai gói tin trước khi phát lại , do đó, sựchậm trễ phát xạ tăng là nhỏ Hơn nữa, nếu các mã hóa tốc độ bit thấp là ít hơn nhiềuhơn so với mã hóa danh nghĩa , sau đó tăng nhẹ trong tốc độ truyền dẫn là nhỏ

Hình 6.3 - : Dự phòng sao lưu thông tin có chất lượng thấp

Để đối phó với sự mất mát không liên tiếp, một biến thể đơn giản có thể được

sử dụng Thay vì chỉ là phụ thêm (n-1) st thấp tốc độ bit đoạn đến đoạn danh nghĩa thứ

n, người gửi có thể phụ thêm (n-1) st và (n-2) thứ hai thấp tốc độ bit đoạn, hoặc nốithêm (n-1) st và (n-3) thứ đoạn tốc độ bit thấp, vv Bằng cách phụ thêm khối hơn thấptốc độ bit cho mỗi đoạn danh nghĩa, chất lượng âm thanh ở người nhận trở nên chấp

nhận được cho một đa dạng hơn khắc nghiệt môi trường tốt nhất nỗ lực Trênotherhand, các khối khác tăng băng thông truyền tải và sự chậm trễ phát xạ Điện thoạimiễn phí và RAT là được tài liệu ứng dụng điện thoại Internet có sử dụng FEC Họ cóthể truyền tải chất lượng thấp hơn các dòng âm thanh cùng với các dòng âm thanhdanh nghĩa, như mô tả ở trên.

Hình 6.3 - : Gửi âm thanh xen kẻĐan xen có thể cải thiện đáng kể chất lượng cảm nhận của một dòng âm thanh[Perkins 1998] Những bất lợi rõ ràng của interleaving là nó làm tăng độ trễ Điều nàyhạn chế việc sử dụng nó cho các ứng dụng tương tác như điện thoại Internet, mặc dù

nó có thể thực hiện tốt cho tuyến âm thanh được lưu trữ các Lợi thế chính củainterleaving là nó không làm tăng các yêu cầu băng thông của một dòng

Người nhận dựa trên các dòng âm thanh bị hỏng

Các chương trình phục hồi Người nhận dựa trên cố gắng để tạo ra một thay thếcho một gói tin bị mất tương tự như bản gốc Như đã thảo luận trong [Perkins 1998],điều này có thể kể từ khi tín hiệu âm thanh, và trong bài phát biểu đặc biệt, triển lãmmột số lượng lớn tương tự trong ngắn hạn Như vậy, những kỹ thuật làm việc cho tỷ lệtổn thất tương đối nhỏ (dưới 15%), và cho các gói nhỏ (4-40ms) Khi chiều dài mấtphương pháp tiếp cận theo chiều dài của một âm vị (5-100ms) các sự cố kỹ thuật, vìtoàn bộ âm vị có thể được bỏ qua bởi người nghe.

Một hình thức đơn giản của sự phục hồi dựa trên nhận là gói tin lặp đi lặp lại.Gói lặp lại thay thế các gói tin bị mất với các bản sao của các gói tin đến ngay lập tứctrước khi mất Nó có phức tạp tính toán thấp và thực hiện khá tốt Một hình thức phụchồi thu dựa trên là suy, trong đó sử dụng âm thanh trước và sau khi mất để nội suy mộtgói tin phù hợp để trang trải sự mất mát Nó thực hiện phần nào tốt hơn so với gói lặp

đi lặp lại, nhưng là đáng kể tính toán chuyên sâu [Perkins 1998] hơn

6.3.4 Luồng lưu trữ âm thanh và video

Chúng tôi kết thúc phần này với một vài lời về dòng lưu trữ âm thanh và video.Lưu trữ âm thanh / video trực tuyến cũng có thể sử dụng số thứ tự, nhãn thời gian và

sự trì hoãn phát lại để làm giảm bớt hoặc thậm chí loại bỏ những ảnh hưởng của biếnđộng mạng Tuy nhiên, có một sự khác biệt quan trọng giữa tương tác âm thanh /video thời gian thực và luồng lưu trữ âm thanh / video Cụ thể, luồng lưu trữ âm thanh/ video có thể chịu đựng sự trì hoãn lớn hơn đáng kể Thật vậy, khi người dùng yêucầu một âm thanh / video clip, người dùng có thể thấy nó chấp nhận để chờ năm giâyhoặc hơn trước khi phát lại bắt đầu và hầu hết người sử dụng có thể chịu đựng được sựtrì hoãn tương tự sau khi các hành động tương tác như một bước nhảy thời gian đếntương lai Khoan dung lớn cho sự trì hoãn được cung cấp cho các ứng dụng phát triểnlinh hoạt hơn khi thiết kế một ứng dụng lưu trữ truyền thông

Tài liệu tham khảo

[Bolot 1994] J-C Bolot and T Turletti, "A rate control scheme for packet video in theInternet," Proceedings of IEEE Infocom, 1994, pp 1216-1223

[Bolot 1996] J-C Bolot and Andreas Vega-Garcia, "Control Mechanisms for PacketAudio in the Internet," Proceedings of IEEE Infocom, 1996, pp 232-239

[Ramjee 1994] R Ramjee, J Kurose, D Towsley, and H Schulzrinn, "AdaptivePlayout Mechanisms for Packetized Audio Applications in Wide-Area Networks,"Proceedings of IEEE INFOCOM, 1994, pp 680-688

[Perkins 1998] C Perkins, O Hodson and V Hardman, "A Survey of Packet LossRecovery Techniques for Streaming Audio," IEEE Network Magazine,September/October 1998, pp 40-47

[Perkins 1998] C Perkins, O Hodson and V Hardman, "A Survey of Packet LossRecovery Techniques for Streaming Audio," IEMagazine, September/October 1998,

pp 40-47

[Shacham 1990] N Shacham and P McKenny, "Packet recovery in high-speednetworks using coding and buffer management," Proceedings of IEEE INFOCOM,

1990, pp 124-131

6.4 GIAO THỨC RTP

Trong phần trước chúng tôi được biết phía người gửi của một ứng dụng đaphương tiện gắn thêm các lĩnh vực tiêu đề để các khối âm thanh / video trước khi điqua các khối với lớp truyền tải Các lĩnh vực tiêu đề bao gồm số thứ tự và thời gian Vìhầu hết tất cả các ứng dụng mạng đa phương tiện có thể sử dụng số thứ tự và thời gian,

đó là thuận tiện để có một cấu trúc gói tiêu chuẩn bao gồm các lĩnh vực cho dữ liệuaudio / video, số thứ tự và dấu thời gian, cũng như các lĩnh vực có tiềm năng hữu íchkhác RTP, được định nghĩa trong [RFC 1889], là một tiêu chuẩn như vậy RTP có thểđược sử dụng cho vận chuyển các định dạng phổ biến như WAV hoặc GSM cho âmthanh và MPEG1 và MPEG2 cho video Nó cũng có thể được sử dụng để vận chuyểnđộc quyền âm thanh và các định dạng video

Trong phần này, chúng tôi cố gắng cung cấp một giới thiệu có thể đọc được đểRTP và giao thức đồng hành của nó, RTCP Chúng tôi cũng thảo luận về vai trò củaRTP trong tiêu chuẩn H.323 cho thời gian thực tương tác âm thanh và hội nghị truyềnhình Người đọc nên ghé thăm trang web của Henning Schulzrinne RTP [Schulzrinne1997], cung cấp nhiều thông tin về chủ đề này Ngoài ra, độc giả có thể muốn đếnthăm các Phonesite miễn phí, trong đó mô tả một ứng dụng điện thoại Internet có sửdụng RTP

6.4.1 Cơ bản về RTP

RTP thường chạy phía trên giao thức UDP Cụ thể, âm thanh hoặc video khối

dữ liệu, tạo ra bởi các bên gửi một ứng dụng đa phương tiện, được đóng gói trong cácgói tin RTP, và mỗi gói RTP là lần lượt đóng gói trong một phân đoạn UDP Vì RTPcung cấp dịch vụ (nhãn thời gian, số thứ tự, vv) để các ứng dụng đa phương tiện, RTP

có thể được xem như là một lớp con của lớp vận chuyển, như thể hiện trong hình 1