Đồ án Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng Ad hoc

ăn cứ vào thông tin này, các bên thu sẽ thực hiện giải mã cho đúng. Mạng Internet cũng như các mạng gói khác đều có khả năng xảy ra mất gói và sai lệch về thứ tự các gói. Để giải quyết vấn đề này, phần tiêu đề RTP mang thông tin định thời và số thứ tự các gói, cho phép bên thu khôi phục định thời với nguồn phát. Sự khôi phục định thời được tiến hành độc lập với từng nguồn phát trong hội nghị. Số thứ tự gói có thể được sử dụng để ước tính số gói bị mất trong khi truyền. Các gói thoại RTP được truyền đi theo các dịch vụ của giao thức UDP để có thể đến đích nhanh nhất có thể. Để giám sát số người tham gia vào hội nghị và chất lượng thoại họ nhận được tại mỗi thời điểm, mỗi một trạm trong hội nghị gửi đi một cách định kỳ một gói thông tin RR( Reception report) của giao thức RTCP để chỉ ra chất lượng thu của từng trạm. Dựa vào thông tin này mà các thành phần trong hội nghị có thể thoả thuận với nhau về phương pháp mã hoá thích hợp và việc điều chỉnh băng thông. Hội nghị điện thoại truyền hình Nếu cả hai dòng tín hiệu thoại và truyền hình đều được sử dụng trong hội nghị thì ứng với mỗi dòng sẽ có một phiên RTP( RTP session) độc lập. Mỗi một phiên RTP sẽ ứng với một cổng ( port number) cho thu phát các gói RTP và một cổng thu phát các gói RTCP. Các phiên RTP sẽ được đồng bộ với nhau để cho hình ảnh và âm thanh ngưòi dùng nhận được ăn khớp. Lý do để bố trí các dòng thông tin thoại và truyền hình thành những phiên RTP tách biệt là để cho các thiết bị đầu cuối chỉ có khả năng thoại cũng có thể tham gia vào cuộc hội nghị truyền hình mà không cần có bất kỳ thiết bị hỗ trợ nào. Translator (bộ dịch) và Mixer (bộ trộn) Các ứng dụng miêu tả ở phần trên đều có điểm chung là bên thu và bên phát đều sử dụng chung một phương pháp mã hoá thoại. Trong trường hợp một người dùng có đường kết nối tốc độ thấp tham gia vào một hội nghị gồm các thành viên có đường kết nối tốc độ cao thì tất cả những người tham gia đều buộc phải sử dụng kết nối tốc độ thấp cho phù hợp với thành viên mới tham gia. Điều này rõ ràng là không hiệu quả. Để khắc phục, một translator hoặc một mixer được đặt giữa hai vùng tốc độ đường truyền cao và thấp để chuyển đổi cách mã hoá thích hợp giữa hai vùng. Điểm khác biệt giữa translator và mixer là mixer trộn các dòng tín hiệu đưa đến nó thành một dòng dữ liệu duy nhất trong khi translator không thực hiện việc trộn dữ liệu. 32-bit người đầu tiên, chứa một hồ sơ cụ thể định danh (16 bit) và một chiều dài specifier ( 16 bit) cho biết rằng chiều dài đuôi( EHL mở rộng = chiều dài tiêu đề) ở 32-bit, đơn vị, ngoại trừ 32 bit của mở rộng tiêu đề. Chuẩn nén Video H264 Giới thiệu chung về H 264 Kể từ khi mới xuất hiện vào đầu những năm 90, chuẩn nén video MPEG-2 đã hoàn toàn thống lĩnh thế giới truyền thông. Cũng trong thập kỷ này, chuẩn nén MPEG-2 đã được cải tiến về nhiều mặt. Giờ đây nó có tốc độ bit thấp hơn và việc ứng dụng nó được mở rộng hơn nhờ có các kỹ thuật như đoán chuyển động, tiền xử lý, xử lý đối ngẫu và phân bổ tốc độ bit tùy theo tình huống thông qua ghép kênh thống kê.  Tuy nhiên, chuẩn nén MPEG-2 cũng không thể được phát triển một cách vô hạn định. Thực tế hiện nay cho thấy chuẩn nén này đã đạt đến hết giới hạn ứng dụng của mình trong lĩnh vực truyền truyền hình từ sản xuất tiền kỳ đến hậu kỳ và lưu trữ Video số. Bên cạnh đó, nhu cầu nén Video lại đang ngày một tăng cao kèm theo sự phát triển mạnh mẽ của mạng IP mà tiêu biểu là mạng Internet. Khối lượng nội dung mà các công ty truyền thông cũng như các nhà cung cấp dịch vụ thông tin có thể mang lại ngày càng lớn, ngoài ra họ còn có thể cung cấp nhiều dịch vụ theo yêu cầu thông qua hệ thống cáp, vệ tinh và các hạ tầng viễn thông đặt biệt là mạng Internet.  Các tiêu chuẩn mã hoá Video ra đời và phát triển với mục tiêu cung cấp các phương tiện cần thiết để tạo ra sự thống nhất giữa các hệ thống được thiết kế bởi những nhà sản xuất khác nhau đối với mọi loại ứng dụng Video; Nhờ vậy thị trường Video có điều kiện tăng trưởng mạnh. Chính vì lý do này nên những người sử dụng bộ giải mã cần có một chuẩn nén mới để đi tiếp chặng đường mà MPEG-2 đã bỏ dở.  Hiệp hội viễn thông quốc tế (ITU) và tổ chức tiêu chuẩn quốc tế/ Uỷ ban kỹ thuật điện tử quốc tế (ISO/IEC) là hai tổ chức phát triển các tiêu chuẩn mã hoá Video. Theo ITU-T, các tiêu chuẩn mã hoá Video được coi là các khuyến nghị gọi tắt là chuẩn H.26x (H.261, H.262, H.263 và H.264). Với tiêu chuẩn ISO/IEC, chúng được gọi là MPEG-x (như MPEG-1, MPEG-2 và MPEG-4).  Những khuyến nghị của ITU được thiết kế dành cho các ứng dụng truyền thông Video thời gian thực như Video Conferencing hay điện thoại truyền hình. Mặt khác, những tiêu chuẩn MPEG được thiết kế hướng tới mục tiêu lưu trữ Video chẳng hạn như trên đĩa quang DVD, quảng bá Video số trên mạng cáp, đường truyền số DSL, truyền hình vệ tinh hay những ứng dụng truyền dòng Video trên mạng Internet hoặc thông qua mạng không dây (wireless).  Với đối tượng để truyền dẫn Video là mạng Internet thì ứng cử viên hàng đầu là chuẩn nén MPEG-4 AVC, còn được gọi là H.264, MPEG-4 part 10, H.26L hoặc JVT. Mục tiêu chính của chuẩn nén H.264 đang phát triển nhằm cung cấp Video có chất lượng tốt hơn nhiều so với những chuẩn nén Video trước đây. Điều này có thể đạt được nhờ sự kế thừa các lợi điểm của các chuẩn nén Video trước đây. Không chỉ thế, chuẩn nén H.264 còn kế thừa phần lớn lợi điểm của các tiêu chuẩn trước đó là H.263 và MPEG-4 bao gồm 4 đặc điểm chính như sau:  Phân chia mỗi hình ảnh thành các Block (bao gồm nhiều điểm ảnh), do vậy quá trình xử lý từng ảnh có thể được tiếp cận tới mức Block.  Khai thác triệt để sự dư thừa về mặt không gian tồn tại giữa các hình ảnh liên tiếp bởi một vài mã của những Block gốc thông qua dự đoán về không gian, phép biến đổi, quá trình lượng tử và mã hoá Entropy (hay mã có độ dài thay đổi VLC).  Khai thác sự phụ thuộc tạm thời của các Block của các hình ảnh liên tiếp bởi vậy chỉ cần mã hoá những chi tiết thay đổi giữa các ảnh liên tiếp. Việc này được thực hiện thông qua dự đoán và bù chuyển động. Với bất kỳ Block nào cũng có thể được thực hiện từ một hoặc vài ảnh mã hoá trước đó hay ảnh được mã hoá sau đó để quyết định véc tơ chuyển động, các véc tơ này được sử dụng trong bộ mã hoá và giải mã để dự đoán các loại Block.   Khai thác tất cả sự dư thừa về không gian còn lại trong ảnh bằng việc mã các block dư thừa. Ví dụ như sự khác biệt giữa block gốc và Block dự đoán sẽ được mã hoá thông qua quá trình biến đổi, lượng tử hoá và mã hoá Entropy. Cơ chế nén ảnh của H264 Với chuẩn nén H264, mỗi hình ảnh được phân chia thành nhiều Block, mỗi block tương ứng với một số lượng nhất định các MacroBlock. Ví dụ một hình ảnh có độ phân giải QCIF (tương đương với số lượng điểm ảnh 176x144) sẽ được chia thành 99 MacroBlock với kích cỡ 16x16. Một sự phân đoạn các MacroBlock tương tự được sử dụng các kích cỡ ảnh khác. Thành phần chói của ảnh được lấy mẫu tương ứng với độ phân giải của ảnh đó, trong khi đó thành phần màu CR và CB được lấy mẫu với tần số thấp hơn theo 2 chiều ngang và dọc. Thêm vào đó mỗi hình ảnh có thể được phân thành số nguyên lần các lát mỏng (slice), việc này rất có giá trị cho việc tái đồng bộ trong trường hợp lỗi dữ liệu.  Mỗi hình ảnh thu được được xem như một ảnh I. Ảnh I là ảnh được mã hoá bởi việc áp dụng trực tiếp các phép biến đổi lên các MacroBlock khác nhau trong ảnh. Các ảnh I được mã hoá sẽ có kích cỡ lớn bởi nó được xây dựng từ một khối lượng lớn thông tin của bản thân ảnh hiện tại mà không sử dụng bất cứ thông tin nào từ miền thời gian trong quá trình xử lý mã hoá để tăng hiệu quả xử lý mã hoá bên trong trong H.264.  Giảm bớt độ dư thừa  Cũng giống như các bộ lập giải mã khác, H.264 nén video bằng cách giảm bớt độ dư thừa cả về không gian và thời gian trong hình ảnh. Những dư thừa về mặt thời gian là những hình ảnh giống nhau lặp đi lặp lại từ khung (frame) này sang khung khác, ví dụ như phần phông nền không chuyển động của một chương trình đối thoại trên truyền hình. Dư thừa về không gian là những chi tiết giống nhau xuất hiện trong cùng một khung, ví dụ như nhiều điểm ảnh giống nhau tạo thành một bầu trời xanh. Hình 1 biểu diễn một cách sơ lược các bước mà bộ lập giải mã MPEG-4 phải tiến hành để nén không gian và thời gian.  Chọn chế độ, phân chia và chế ngự  Bộ lập giải mã bắt đầu bằng việc quyết định loại khung cần nén tại một thời điểm nhất định và chọn chế độ mã hoá phù hợp. Chế độ "trong khối" tạo ra ảnh "I", trong khi chế độ "giữa khối" tạo ra khung "P" hoặc "B". Sau đó, bộ mã hoá sẽ chia ảnh thành hàng trăm hàng và cột các điểm ảnh của ảnh video số chưa nén thành các khối nhỏ hơn, mỗi khối có chứa một vài hàng và cột điểm ảnh.  Nén theo miền thời gian  Khi bộ mã hoá đang hoạt động ở chế độ "giữa khối" (inter), khối này sẽ phải qua công đoạn hiệu chỉnh chuyển động. Quá trình này sẽ phát hiện ra bất kỳ chuyển động nào diễn ra giữa khối đó và một khối tương ứng ở một hoặc hơn một ảnh tham chiếu đã được lưu trữ từ trước, sau đó tạo ra một khối "chênh lệch" hoặc "lỗi". Thao tác này sẽ giảm bớt dữ liệu trong mỗi block một cách hiệu quả do chỉ phải trình bày chuyển động của nó mà thôi. Tiếp đến là công đoạn biến đổi côsin rời rạc (DCT) để bắt đầu nén theo miền không gian. Khi bộ mã hoá hoạt động ở chế độ "trong khối" (intra), khối này sẽ bỏ qua công đoạn hiệu chỉnh chuyển động và tới thẳng công đoạn DCT. Hình 2. 13: Sơ đồ khối mã hóa MPEG-4 AVC (H264)  Nén theo miền không gian  Các khối thường có chứa các điểm ảnh tương tự hoặc thậm chí giống hệt nhau. Trong nhiều trường hợp, các điểm ảnh thường không thay đổi mấy (nếu có). Như vậy có nghĩa là tần số thay đổi giá trị điểm ảnh trong khối này là rất thấp. Những khối như thế được gọi là khối có tần số không gian thấp. Bộ lập mã lợi dụng đặc điểm này bằng cách chuyển đổi các giá trị điểm ảnh của khối thành các thông tin tần số trong công đoạn biến đổi côsin rời rạc.  Biến đổi cosin rời rạc:  Công đoạn DCT biến đổi các giá trị điểm ảnh của khối thành một ma trận gồm các hệ số tần số ngang, dọc đặt trong không gian tần số. Khi khối ban đầu có tần số không gian thấp, DCT sẽ tập hợp phần lớn năng lượng tần số vào góc tần số thấp của mạng. Nhờ vậy, những hệ số tần số thấp ở góc đó sẽ có giá trị cao hơn.  Một số lượng lớn các hệ số khác còn lại trên ma trận đều là các hệ số có tần số cao, năng lượng thấp và có giá trị thấp. Hệ số DC và một vài hệ số tần số thấp sẽ hàm chứa phần lớn thông tin được mô tả trong khối ban đầu. Điều này có nghĩa là bộ lập mã có thể loại bỏ phần lớn hệ số tần số cao còn lại mà không làm giảm đáng kể chất lượng hình ảnh của khối.  Bộ lập mã chuẩn bị các hệ số cho công đoạn này bằng cách quét chéo mạng lưới theo đường zig-zag, bắt đầu từ hệ số DC và qua vị trí của các hệ số ngang dọc tăng dần. Do vậy nó tạo ra được một chuỗi hệ số được sắp xếp theo tần số.  Lượng tử hoá và mã hoá entropy:  Tại đây thao tác nén không gian mới thực sự diễn ra. Dựa trên một hệ số tỷ lệ (có thể điều chỉnh bởi bộ mã hoá), bộ lượng tử hoá sẽ cân đối tất cả các giá trị hệ số. Do phần lớn hệ số đi ra từ DCT đều mang năng lượng cao nhưng giá trị thấp nên bộ lượng tử hoá sẽ làm tròn chúng thành 0. Kết quả là một chuỗi các giá trị hệ số đã được lượng tử hoá bắt đầu bằng một số giá trị cao ở đầu chuỗi, theo sau là một hàng dài các hệ số đã được lượng tử hoá về 0. Bộ lập mã entropy có thể theo dõi số lượng các giá trị 0 liên tiếp trong một chuỗi mà không cần mã hoá chúng, nhờ vậy giảm bớt được khối lượng dữ liệu trong mỗi chuỗi. Bộ mã hóa H264 Hình 2. 14: Sơ đồ bộ mã hóa H264 Bộ mã hóa bao gồm hai luồng dữ liệu, luồng thuận từ trái sang phải, và luồng tái tạo từ phải sang trái trong hình Một khung đầu vào hay một trường Fn được xử lý theo từng khối macro. Mỗi khối được mã hóa theo mô hình mã hóa trong hay ngoài, đối với mỗi khối macro, một ảnh tham chiếu để dự đoán PRED ( điểm P trên vẽ) được tái tạo từ các mẫu của bức ảnh. Trong chế độ mã hóa trong, PRED được tạo bởi các mẫu trong slice hiện tại trước đó đã được mã hóa, giải mã và tái tạo (xem uF_n, chú ý rằng các mẫu chưa được lọc sẽ được sử dụng để tạo lên PRED). Trong chế độ mã hóa ngoài, PRED được tạo bởi dự đoán bù chuyển động từ một hoặc hai ảnh tham chiếu được lựa chọn từ tập danh sách các ảnh tham chiếu 0 hay 1. Trong hình minh họa ảnh tham chiếu là Fn-1 nhưng tham chiếu dự đoán cho một vùng của khối macro có thể chọn là ảnh tham chiếu (đã được mã hóa, tái tạo và lọc trước đó) ở tương lai hay là quá khứ ( theo thứ tự hiển thị) PRED sẽ được loại bỏ đi từ khối hiện tại để tạo ra khối dư thừa còn lại Dn ( sai khác). Dn sẽ được biến đổi và lượng tử hóa để tạo ra X một tập các hệ số biến đổi lượng tử hóa .Các hệ số này sẽ được xắp xếp lại thứ tự và sau đó mã hóa entropy.Các hệ số được mã hóa entropy kết hợp với các thông tin cần thiết để giải mã mỗi khối trong khối macro (chế độ dự đoán, tham số lượng tử hóa, thông tin vector chuyển động) tạo thành luồng bit được nén sẽ được chuyển tới Lớp mạng trừu tượng - NAL để truyền đi hay lưu trữ.Đồng thời khi mã hóa và truyền đi, mỗi khối trong khối macro sẽ được bộ mã hóa tái tạo lại để làm tham chiếu cho việc dự đoán. Các hệ số X sẽ được tái tạo qua các khối biến đổi ngược Q-1, T-1 để tạo thành Dn. Khối dự đoán PRED được cộng vào với Dn để tạo ra khối uFn( bản giải mã của khối nguyên thủy). Tiền tố “u” để chỉ khối này chưa được lọc. Bộ lọc dùng để giảm méo và ảnh tham chiếu được tái tạo từ nhiều khối Bộ giải mã H264 Hình 2. 15: Sơ đồ bộ giải mã H264 Bộ giải mã nhận được 1 luồng dữ liệu nén từ NAL và giải mã entropy nhưng thanh phần cơ bản của dữ liệu để tạo ra tập các hệ số được lượng tử hóa X.Những hệ số này được chia tỉ lệ và chuyển đổi ngược thành .Dn.Sử dụng thông tin tiêu đề được giải mã từ lượng bit, bộ giải mã tạo ra khối dự đoán PRED, phân biệt với khối PRED được tạo ở bộ mã hóa Tải dữ liệu của RTP cho H264 Hình 2. 16: Các loại gói RTP chứa đơn vị NAL Chế độ đóng gói Chế độ đóng gói của các slice vào các NAL unit: Single Nal unit mode Non-interleaved mode Interleaved mode Bảng các loại NAL unit được cho phép với mỗi chế độ đóng gói (yes=allowed, no=disallowed, ig=ignore) Hình 2. 17: Chế độ đóng gói ứng với mỗi loại đơn vị NAL Đơn vị NAL đơn (single nal unit) Single NAL unit chỉ chứa duy nhất 1 NAL unit ở bên trong điều nay có nghĩa là không có 1 FU hoặc gói tổng hợp được sử dung bên trong 1 gói Single NAL uniit Một luồng NAL unit được tạo bởi việc mở gói Single NAL unit theo thứ tự của số RTP phù hợp với trật tự mã hoá của NAL unit Cấu trúc của Single NAL unit Hình 2. 18: Cấu trúc chung của gói tích lũy Gói tích lũy đơn thời gian (STAP) STAP là gói có giá trị NAL là 24,chứa nhiều NAL unit bên trong với 1 nhãn thời gian xác định.STAP chia làm 2 loại: STAP-A: không chứa DON(decoding order number) STAP-B: có chứa DON STAP và MTAP có luật đóng gói chung:Nhãn thời gian RTP phải đựoc đặt là thời gian sớm nhất của NAL unit trong các NAL unit đựoc đóng gói Bít F đựoc đặt là 0 khi tất cả các gói NAL unit đựoc ghép đều có bit F là 0, còn lại thì đật là 1.Giá trị của NRi lá giá trị lơn nhất của tất cả các NAL đựoc mang trong gói tổng Maker bit trong header của RTP được đặt giá trị của maker bit của NAL unit trong gói tổng sẽ có nếu nó được truyền trong chính gói RTP của nó Trong gói STAP có 1 số 16 bit không dấu chỉ độ dài của NAL unit theo sau nó kể cả header Riêng trong các gói STAP-B có DON dùng STAP A Hình 2. 19: Cấu trúc của STAP-A Byte đầu tiên của RTP payload chứa các thông tin về loại dữ liệu,, về mức độ ưu tiên khi truyền gói dữ liệu.Trước mỗi NAL unit đều có 1 số nguyên không dấu 16 bit chứa thông tin về độ dài của NAL unit theo sau đó.Các NAL unit chứa trong gói tổng hợp thì đều có cùng NAL unit STAP B Hình 2. 20: Cấu trúc gói STAP-B Cấu trúc của STAP-B chỉ khác với STAP-A  ở DON (decoding order number):còn lại giống với STAP-A Gói tích lũy đa thời gian (Multi time aggregate packet hay MTAP) Gói tổng hợp MTAP thì chứa các NAL unit có thời gian khác nhau.Trong đó MTAP NAL header chứa các thông tin về loại dữ liệu chứa trong gói DONB (decoding order number base) chứa thông tin về DON của NAL unit đầu tiên trong trật tự giải mã NAL unit.Tuy nhiên gói NAL unit đầu tiên không nhất thiết là NAL unit đầu tiên được đóng gói trong gói MTAP NAL unit size là số nguyên 16 bit chứa độ dài của NAL unit theo sau đó NALU DOND là là số nguyên không dấu 8 bit, là giá trị lệch so với DONB=>DON = (DOND+DONB) %65536 Do sự khác nhau về giá trị của độ lệch thời gian: 16 bit nguyên không dấu và 24 bit nguyên không dấu.Cho nên có 2 loại gói MTAP: M.TAP 16 và MTAP 24. Độ lệch thời gian của các NAL unit được tính so với thời gian của NAL unit sớm nhất, và được tính theo công thức sau: Nếu NALU-time lớn hơn nhãn thời gian của RTP thì độ lệch nhãn thời gian = (NALU- time của NALU - RTP timestamp) Nếu NALU-time nhỏ hơn nhãn thời gian của RTP thì độ lệch nhãn thời gian = (NALU- time của NALU + (2^32 -RTP timestamp)) Độ lệch thời gian của gói NALU sớm nhất (so với các NALU trong gói tổng hợp) phải là 0 MTAP 16 Hình 2. 21: Cấu trúc gói MTAP-16 MTAP 24 Hình 2. 22: Cấu trúc gói MTAP-24 Đơn vị phân đoạn (Fragmentation Unit hay FU) Hình 2. 23: Tiêu đề của đơn vị phân mảnh Việc phân đoạn (fragmentation) chia các NALU có kích thước lớn thành các phần nhỏ để thch hợp với việc truyền gói đi trên mạng.Phân đoạn chỉ được định nghĩa cho NAL đơn(single NALU) Các phân đoạn của cùng NAL unit phải được gửi theo trật tự liên tiếp với việc tăng số thứ tự (sequnce number) của gói RTP (không có gói RTP khác bên trong luồng RTP đấy được gửi giữa đoạn đầu tiên và đoạn cuối cùng) Cấu trúc của các octet của đầu tiên của gói FU: FU indicator: giá trị trong trường F, NRI, type được định nghĩa giống trong trường F, NRI, type của NALU header.Giá trị trong trường type là 28 hoặc 29 Do đó có 2 loại gói FU: có DON và không có DON FU header: S : được đặt là 1 khi phân đoạn là phân đoạn bắt đầu của NALU,các phân đoạn còn lại thì được đặt là 0 E : được đặt là 1 khi phân đoạn là phân đoạn kết thúc của NALU,các phân đoạn còn lại của cùng NALU thì được đặt là 0 R : bít ngược thường được đặt là 0 Type (5 bit): loại NALU được phân đoạn Chú ý: Nếu 1 phân đoạn bị mất thì bên thu huy tất cả FU phía sau (của cùng NALU) theo trật tự truyền.Tuy nhiên bên thu có thể tổng hợp (N-1) gói đầu tiên của 1 NALU thành một NALU không hoàn chỉnh và lúc đó bit F của tiêu đề của đơn vị NAL được đặt là 1 để thông báo lỗi FU-A Hình 2. 24: Cấu trúc gói FU-A FU-B Hình 2. 25: Cấu trúc gói FU-B Chương 3 : Cross-layer design Sự cần thiết của giao tiếp liên tầng trong mạng adhoc Mạng không dây adhoc được đặc trưng bởi sự thay đổi không dự đoán trước được của chất lượng kênh truyền,như băng thông có thế thay đổi theo thời gian và không gian.Do đó việc truyền video thời gian thực trong mạng adhoc gặp rất nhiều thách thức, đặc biệt khi có sự thay đổi của topo mạng (các nut di chuyển tương đối với nhau),lưu lượng mạng, độ trễ của gói dữ liệu,mất gói dữ liệu, và thêm vào nữa là sự hạn chế về mặt tài nguyên của chính các thiết bị sử dụng liên lạc sử dụng trong mạng adhoc, như năng lượng tiêu thụ,khả năng xử lí của các thiết bị,phạm vi hoạt động. Điều này có thế lý giải như sau, tầng ứng dụng (application) là tầng mã hoá Video h264, đầu ra của tầng là các chuỗi NAL, các gói NAL này sẽ được đóng gói RTP và được truyền đi trên mạng theo giao thức UDP/IP,khi chất lượng đường truyền tốt,thì luông video truyền trên mạng sẽ không gặp rủi ro nhiều,tức là có bao nhiêu gói NAL được tạo ra bởi bộ Encoder ,thì sẽ được gửi đi trên mạng với tỉ lệ mất gói ít, và không ảnh hưởng nhiều đến quá trình giải mã bên thu. Nhưng nếu với cùng tốc độ đầu ra của bộ mã hoá như trên, mà chất lượng đường truyền không tôt, tỉ lệ mất gói cao,do vậy sẽ ảnh hưởng đến quá trình giải mã bên thu khi mất gói rtp chứa các gói NAL quan trọng trong quá trình giải mã. Do vậy để có được sự mềm dẻo trong quá trình truyền, thích ứng với môi trường mạng thì cần phải có sự liên lạc giữa các tầng. Thiết kế giao tiếp liên tầng routing – transport – Application Mô hình crosslayer tổng quan Hình 3. 1: Mô hình tổng quan cross-layer Việc thiết kế cross-layer nhằm mục đích phản hối được chất lượng kênh truyền từ phía thu về phía phát trong thời gian thực Phía phát,nhận bản tin phản hồi từ phía thu và tính toán giá trị tương ứng với chất lượng kênh truyền tại thời điểm hiện tại.Việc nhận thông tin phản hồi từ phía thu sẽ kết hợp thêm thông tin được đưa lên từ tầng routing, để tính toán hợp lí thông số QP cho bộ mã hoá Đồng thời phía phát sẽ lựa chọn các gói truyền lại,dựa trên danh sách gói mất từ phía thu và mức độ quan trọng của dữ liệu chứa trong gói mất(khung I,P hay tập các tham số như SPS,PPS) việc thay đổi tốc độ của phía phát dựa trên việc thay đổi giá trị phiên làm việc có sự liên thông của 3 tầng tầng ứng dụng (application) tầng (truyền) transport tầng (mạng) network Thiết kế bao gồm 3 module chính Modules transcode: thực hiện chức năng chuyển mã và mã hóa luồng dữ liệu video đầu vào thành luồng video được mã hoá H264 Modules transport: thực hiện đống gói rtp luồng video được mã hoá h264 và truyền đi các gói RTP.Mặt khác modules này cũng xử lí các bản tin phản hồi từ Receiver,sau đó thực hiện truyền lại và đưa thông tin lên lớp trên(lớp application) Modules routing: thực hiện việc duy trì bang định tuyến tới các nút trong mạng, và trạng thái của các nút đó.Thông tin định tuyến sẽ được đưa lên lớp trên,phục vụ cho việc tính toán tốc độ phát của phía phát và số gói cần phát lại để đảm bảo truyền gói thành công Feedback Hình 3. 2: Bản tin feedback Bản tin feedback dùng để tính tỉ lệ mất gói.bản tin này được xử lí tại tầng transport và thông qua bản tin này,Sender sẽ điều chỉnh tốc độ luồng RTP ,và truyền lại các gói RTP quan trọng trong việc giải mã Nội dung của bản tin feedback danh sách gói mất tống số gói nhận được sequence của gói mất như vậy ta có cấu trúc của bản tin feedback như sau struct NACK_t { int recvPk; //so goi nhan duoc int list_SeqlostPk[500]; //danh sach goi mat int i_lostPk; //so goi mat } thuật toán. Bên thu sẽ quét số gói phát nhận được trong chu kỳ 5s,và bên phát sẽ đếm số gói phát đi trong vòng 5s. Vì trong quá trình quét gói bên Sender liên tục phát gói trên mạng,do vậy để đảm bảo lossrate chính xác thì số gói nhận được bên thu phải nằm trong số gói được phát đi bên phát. Để đảm báo yêu cầu này quá trinh quét gói cần một cơ chế đồng bộ giữa quá trình xử lí feedback bên Sender và Receiver như sau. Bên phía Receiver khi bắt đầu quét gói phải gửi một bản tin đến Sender và khi Sender nhận được bản tin thông báo này sẽ phản hồi trở lại bên phía Reveiver và đếm số gói RTP phát đi sau một khoảng thời gian RounStripTime/2 tính từ khi gửi thông báo.Receiver bắt đầu quét gói sau một khoảng thời gian RoundStripTime/2 tính từ lúc nhận bản tin thông báo của Sender.Như vậy quá trình feedback bao gồm các bước sau tính toán roundstriptime thông báo đồng bộ đếm số gói RTP phát đi bên Sender quét số gói RTP đến bên Receiver Gửi bản tin feedback Xử lý bản tin feedback bên Sender Hình 3. 3: Minh họa roundstrip time Mảng a[1000] chứa danh sách gói nhận được và danh sách gói mất Giá trị của mỗi phần tử mảng là số thứ tự của gói RTP Mảng a sẽ được reset sau chu kỳ 5s Vị trí của một phần tử bất kỳ trong mảng tuân theo qui luật sau: a[offset] = A, với offset = A – a[0] Bên phía sender có một biến đếm số gói đã phát Sau chu kỳ 5s, duyệt mảng một lần Thiết kế chi tiết Các quá trình trên không được ảnh hưởng đền quá trình nhận gói tin RTP, do vậy cần phải tạo ra một tuyến feedback(), hoạt động song song với tuyến bắt gói tin RTP. tạo bản tin feedback bên Receiver bao gồm các quá trình sau Quét gói và lưu trong mảng a if(Index==0) { a[Index]=tk->rtpSource->curPacketRTPSeqNum(); Index++; } else { Index=tk->rtpSource->curPacketRTPSeqNum()-a[0]; a[Index]=tk->rtpSource->curPacketRTPSeqNum(); } Xử lí mảng a, tạo ra các bản tin feedback và gửi bản tin này đến Sender Quá trình quét gói diễn ra liên tục trong vòng lặp while( 1 ) while(1) { Chu kỳ quét gói là 5s, do vậy cần chờ 5s ,để các gói đến được lưu trong mảng a[] sleep(5); Sau 5s, bắt đầu xử lí mảng a[], và đảm bảo để đồng bộ tuyến , ta cần phải tạo khóa, không cho các tuyến khác truy cập, làm thay đổi giá trị mảng a[] pthread_mutex_lock(&feedback_lock); for(i = 0;i<= i_maxIndex; i++) { Duyệt mảng a, kiểm tra gói mất dựa trên giá trị các phần tử trong mảng , gói nhận được tương ứng với giá trị a[i] > 0 if(a[i] > 0) temp.recvPk++; và giá trị a[i] = 0, tương ứng với trường hợp , gói mất. Tính toán giá trị sequence của gói mất dựa trên vị trí của gói mất trong mảng a, và mốc là phần tử thứ nhất else{ temp.list_SeqlostPk[j] = i + a[0]; temp.i_lostPk++; temp.list_SeqlostPk[j]); j++; } } Index = 0; i_maxIndex = 0; refresh lai mang danh sach goi nhan duoc memset(a, 0, 1000*sizeof(int)); j = 0; tháo khóa , tạo một chu kỳ bắt gói mới pthread_mutex_unlock(&feedback_lock); sendMsgSize = send(sockfd, &temp, sizeof(struct NACK_t), 0); if(sendM