Đồ án Truyền video đa chặng trong mạng AD hoc

định nghĩa trước cho mỗi ảnh được lưu trữ tùy thuộc số bit được mã hóa của ảnh IDR đầu tiên và ảnh được lưu trữ đầu tiên và độ phức tạp trung bình của ảnh.Sau khi mã hóa ảnh được lưu trữ ởnhóm ảnh thứ j, giá trị khởi đầu của cấp độ(level) của bộ đệm mục tiêu được đặt : Cấp độ của bộ đệm mục tiêu cho ảnh được lưu trữ của chuỗi phụ được xác định bới (2-5) Với  là trọng số phức tạp trung bình của ảnh được tham chiếu , là giá trị trung bình của ảnh không được tham chiếu :  (2-6) Khi không có ảnh không được lưu trữ giữa 2 ảnh được lưu trữ thì công thức được tính đơn giản như sau (2-7) Tính toán lượng bít mong muốn cho ảnh được lưu trữ hiên tại: Lượng bít mong muốn được phân phối cho ảnh được lưu trữ thứ j của nhóm ảnh được xác định dựa trên cấp độ của bộ đệm mong muốn, tốc độ khung,băng thông hiệu dụng và sự chiếm dụng của bộ đệm hiện thời: (2-8) Trong đó g là hằng số và giá trị điển hình là 0.5 khi không có ảnh không được lưu trữ và 0.25 cho các trường hợp còn lại.. Đồng thời, lượng bit còn lại cũng nênđược xem xét khi lượng bít mong muốn được tính (2-9) Với và lần lượt là số bít còn lại của ảnh được tham chiếu và ảnh không được tham chiếu Số bít mong muốn được kết hợp có trọng số của và : (2-10) Với β là hằng số có giá trị là 0.5 khii không có ảnh không tham chiếu và bằng 0.9 trong các trường hợp còn lại Để phù hợp với yêu cầu của bộ giải mã HRD; lượng bít mong muốn được giới hạn bởi : (2-11) Với    Zi(j) và Ui(j) được tính bởi công thức (2-12)       (2-13)                 Trong đó t(1)là thời gian xóa bỏ của ảnh đầu tiên từ bộ đệm ảnh được mã hóa ,là hằng số với giá trị đặc trưng bằng  0.9 -Bước 2: Tính toán giá trị QP và thực hiên RDO (rate-distortion optimization) MAD của ảnh được lưu trữ tạm thời được dự đoán bởi mô hình tuyến tính sử dụng MAD hiện tại của ảnh lưu trữ trước đó         (2-14)                         Trong đó a1 và a2 là 2 hệ sô. Gái trị khởi đầu của a1 và a2 được đặt lần lượt là 1 và 0 .Hai hệ số trên được cập nhật bởi phương pháp hồi quy tuyến tính sau khi mã hóa 1 ảnh hoăc 1 đơn vị cơ bản. Bước lượng tử liên quan tới lượng bit mong muốn đuocj tính theo công thức sau   (2-15)                     Trong đó  là tổng số bit của tiêu đề và vector chuyển động, và là 2 hệ số. Giá trị QP đúng được tính dựa theo bước lượng tử hóa và tham sô lượng tử của AVC(advance video coding).Để duy trì sự trơn tru chắt lượng nhìn thấy giữa các khung hình liên tiếp nhau,giá trị QP được điều chỉnh Gía trị QP cuối cùng dược giới hạn bởi 0 và 51.Tham số lượng tủ hóa sau đó được dùng để thực hiên RDO cho mỗi macroblock của khung hiên tại 2)Giai đoạn post-encode Sau khi mã hóa 1 ảnh,tham số a1 và a2 của mô hình dự đoán tuyến tính,và cững như c1 và c2 của mô hình R-D bình phương được cập nhật.Phương pháp hòi quy tuyến tính đươck dung để cập nhật những tham sô đấy Trong khi ấy, luồng bit được tạo ra hiện thời được thêm vào bộ đệm.Để đảm bảo sự chiếm dụng của bộ đệm được cập nhật không quá cao,1 số ảnh có thê được bỏ qua 3)Điều khiển tốc độ mức độ đơn vị cơ bản (Basic unit level rate control) Giả thiết 1 bức ảnh được tạo bởi Nmbpicmacroblock.Môtij đơn vị cơ bản được định nghĩa là 1 nhóm liên tục của macroblock và bao gồm Nmbunit  macroblock với Nmbunit là 1 phần của  Nmbpic.Nếu Nmbunit = Nmbpic ,đây sẽ là điều khiển tốc độ cấp ảnh (picture level).Nếu Nmbunit =1 thì  đây sẽ là điều khiển tốc độ cấp macroblock Tổng số đơn vị cơbản trong 1 khung hình Nunitđược tính toán bởi công thức sau   (2-16)                                           Nếu đơn vị cơ bản không được chọn như là 1 khung hình, điều khiển tốc đọ cấp đơn vị cơ bản nên được thêm vào Gióng với điều khiển tốc độ cấp đô frame, giá trị QP cho ảnh IDR và ảnh không được lưu trữ giống nhau cho tất cả các đơn vị cơ bản trong cùng 1 ảnh và đực tính toán tương tự cấp khung hình được cung cấp mà, được thay thế bằng giá trị trung bình cho các đơn vị cơ bản trong bức ảnh tương ứng Điều khiển tốc độ cấp đơn vị cơ bản lựa chọn giá trị QP của tất cả đơn vi cơ bản trong 1 khung hình để tổng số bit được sinh ra gần với đích ngắm đến của khung hình Mô tả theo từng bước của phương pháp +Bước 1: Dự doán MAD  của các đơn vịcơ bản còn lại trong ảnh được lưu trữ hiện tại bằng mô hình có sử dụng MAD hiện tại của ảnh được lưu trữ trước đây +Bước 2:Tinh toán số bít dư thừa (texture bit hoăc residual bít) cho đơn vị cơ bản thứj.Bước này bao gồm 3 bước phụ -Bước2.1: Tính toán lượng bít mong muốn cho dơn vịcơ bản thứ j Để chỉ số bit còn lại cho khung hình hiện tại và gía trị khởi đầu được đặt là  Số bit mong muốn cho đơn vị cơ bản thứ l được tính như sau:       (2-17)                               -Bước2.2: Tính toán lựơng bit tiêu đề trung bình được tạo ra bởi tất cả đơn vị cơ bản được mã hóa:       (2-18)                    Trong đó là sốbít tiêu đềđược tạo ra hiên thời bởi đơn vịcơ bản thứ l trong ảnh được lưu trữ.được tính toán từ tất cả các đơn vị cơ bản của ảnh tham chiếu hiện tại -Bước 2.3:Tính toán số bit dư thừa cho đơn vị cơ bản thứ l           (2-19)                             +Bước 3: Tính toán bước lượng tử cho đơn vị cơ bản thứ l của ảnh thứ j trong nhóm ảnh thứ i bằng cách sử dụng mô hình R-D, và được chuyển thành giá trị QP đúng.Xét 3 trường hợp sau -Trường hợp 1: Đơn vị đầu tiên của khung hình hiện tại   (2-20)                                          Trong đó  lá giá trị trung bình của gía trị QP cho tất cảcác đươn vịcơ bản của ảnh lưu trữtrước đó -Trường hợp 2 Khi lượng bít còn lại ít hơn 0, giá trị QP phải lớn hơn giá trị QP của đươn vị cơ bản trước đấy để trong lượng bít được tạo ra gần với lượng bit yêu cầu    (2-21)                                 Trong đó khoảng biến đổi của giá trị QP đi cùng với đơn vịcác cơ bản , là 1 nếu lớn hơn 8 và bằng 2 trong các trường họp còn lại. được cập nhật  sau khi mã hóa 1đơn vị cơ bản:        (2-22)                          Trong đó là khoảng biến đổi của giá trị QP đi cùng với khung hình và được định nghĩa bởi :   (2-23)                                    -Trường hợp 3 Còn lại , chúng ta nên tính toán bước lượng tử đầu tiên bằng cách sử dụng mô hình R-D bình phương (quadric R-D model) và chuyển giá trị bước lượng tử thành giá trị QP tương ứng   (2-24)      +Bước 4:Thực hiện RDO cho tất cả các macroblock trong đơn vị cơ bản hiện tại và mã hóa chúng. +Bước 5:Cập nhật số bit còn lại ,các hệ số của mô hình dự đoán tuyến tính và của mô hình R-D bình phương. Tính toán độ phức tạp (Complexity Estimation) Độ dư thừa (Residual):sự khác biệt giữa ảnh nguồn và ảnh được dự đoán (prediction error).Chuyển đổi theo không gian sau đó được áp dụng tới độ dư thừa để tạo ra các hệ số được chuyển đổi chứa nhưng chi tiêt về mặt không gian mà không được lấy trong dự đoán (prediction) hoăc bản thân ảnh tham chiếu MAD: mean absolute Difference of Prediction (2-25) với giả thiết  xi là giá trị nguồn của pixel thứ i: Bộ khởi tạo QP (QP initializer) Giá trị QP phải được khởi tạo ở điểm bát đầu của chuỗi video.Giá trị khởi đầu này có thể thiết lập bằng tay hoặc có thể tính từ số bít yêu cầu trên 1 pixel (DemandedBitsPerPixel) DemandedBitsPerPixel = DemandedBitrate / (FrameRate * height * width) Trong đó DemandedBitrate: tốc độ bit được yêu cầu, giá trị có thể được thiết lập bởi người dùng Height, width: kích thước ảnh FrameRate: tốc độ frame (frame/s) Giá trị QP ứng với các khoảng giá trị của số bítx yêu cầu trên 1 pixel (2-27) với (2-27) Trong đó N là số pixel của 1 bức ảnh               f:  tốc độ frame               R tốc độ bít đích (target) Mô hình bộ nhớ ảo (Virtual bufer model Bất cứ bộ giải mã nào được cung cấp 1 bộ đệm để loại bỏ sự biến đỏi tốc đọ và thời gian đến của dữ liệu tới.Bộ mã hóa tương ứn phải tạo ra 1 luông bit thoảm mãn sự hạn chế của bộ mã hóa.Vì vậy mô hình bộ đệm ảo được dùng đẻ mo phỏng đầy đủ bộ đệm của bộ mã hóa thực sự  Sự thay đổi đầy đủ của bộ đẹm ảo là khác biệt giữa lượng bit tổng cộng được mã hóa thành luồng Giới hạn delta QP (Delta QP-Limiter): Với những chuỗi video có tốc độ thay đổi sự phức tạp (complexity) nhanh, giá trị QP được yêu cầu có thể  thay đổi theo chu kì có thể thấy được .Vì vậy bộ giới hạn tốc độ được áp dụng để giới hạn sự thay đổi giá trị QP không quá ± 2 đơn vị giữa các ảnh Phân bố bít của đơn vị cơ bản (Basic Unit Bit Allocation) Đơn vị cơ bản là khái niệm cơ bản trong điều khiển tốc độ của h264.Việc điều khiển tốc độ, được thực hiện ở các mức độ khác nhau: ảnh, slice, hàng macroblock  hoặc tập liên tục các macroblock Trong H264,điểm nhấn mạnh là trên việc tính toán giá trị QP  cho mỗi ảnh được lưu trữ (thường là ảnh P mặc dù chuẩn H264 cho phép ảnh B được dùng như làm ảnh tham chiếu nhưng không thông dụng).Giá trị QP cho ảnh không tham chiếu (thường là ảnh B ) sau đó được chèn vào (độ lệch) từ giá trị QP cho các ảnh P bên cạnh.Đầu tiên xem xét MAD (mean absolute difference ) của bức ảnh , quyết định cấp độ đích cho mức đầy bộ đệm Phân loại ratecontrol 1pass VBR Hinh 220: Chế độ tốc độ biến đổi VBR (variable bitrate) là chế độ 1pass được thiết kế cho truyền thời gian thực.Nó cũng có tình toàn độ phức tạp cho việc tính toàn cỡ bit như ABR Tỉ lệ thang đo được dùng cho việc đạt kích cỡ file được yêu cầu được dựa trên mức trung bình cục bộ (phụ thuộc kích thước bộ đệm VBV) thay cho các khung trong quá khứ.Bù quá tràn (overflow compensation) được chạy sau mỗi hàng của macroblock thay vì trên mỗi khung 1pass CBR Hinh 221: Chế độ tốc độ không đổi CBR (constant bitrate) là chế độ 1pass được tối ưu khi người dùng không yêu cầu 1 tốc độ bit cụ thể mà thay vào đó là chất lượng.CBR giống với chế độ ABR(average bitrate) ngoại trừ tỉ lệ đo là 1 hằng số được người dùng định nghĩa và không có bù cho tràn đươc thực hiện 1pass constant QP:Là chế độ 1pass có giá trị QP được tính toán dựa trên khung là I-P hoặc P-B.Trong x264,giá trị QP trong chế độ này không đổi cho cả chuỗi và tùy thuộc vào loại khung (I,P,B) 1pass ABR:Đây là kịch bản 1-pass khi diều khiển tốc độ phải được thực hiện mà không biết khung sau này.Vì vậy,ABR không thể đạt được kích thước file mong muốn môt cách chính xác.Chế độ này sử dụng SATD(Sum of Absolute Hadamard Transformed Differences) của độ dư thừa như là độ phức tạp 1pass constant QP:Là chế độ 1pass có giá trị QP được tính toán dựa trên khung là I-P hoặc P-B.Trong x264,giá trị QP trong chế độ này không đổi cho cả chuỗi và tùy thuộc vào loại khung (I,P,B) Giao thức truyền tải thời gian thực RTP Giao thức truyền dữ liệu RTP Hinh 31: Tiêu đề gói RTP Payload type Chỉ định loại media nào được truyền đi trong các gói RTP. Các ứng dụng bên nhận kiểm tra trường này để quyết định cách thức xử lý dữ liệu. Tất cả các định dạng dữ liệu đều được đăng ký theo chuẩn MIME (MIME type registration). Các định dạng mới hơn được định nghĩa trong đặc tả của chúng; Một nhóm đăng ký cho các định dạng cũ hơn đang được phát triển. Toàn bộ danh sách Trong chuẩn MIME được lưu trực tuyến tại địa chỉ : Dù kiểu dữ liệu được chỉ định là tĩnh hay động, điều cần thiết là phải mô tả được phiên hiện thời tới ứng dụng sao cho ứng dụng đó hiểu được những loại dữ liệu nào dang được sử dụng. Một trong các giao thức dùng để mô tả phiên đó là SDP (Session Description Protocol). Một ví dụ về một bản ghi SDP như sau: v=0 o=bloggs 2890844526 2890842807 IN IP4 10.45.1.82 s=- e=j.bloggs@example.com(Joe Bloggs) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 Ví dụ trên mô tả 2 phiên RTP, audio được gửi tới một nhóm IPv4 multicast 224.2.17.12 qua cổng 49170, Time-To-Live là 127, video được gửi tới cùng nhóm multicast nói trên qua cổng 51372. Cả audio và video đều sử dụng giao thức RTP/AVP làm giao thức chuyển vận. Sequence number Là số không dấu 16 bit dùng để phân biệt các gói,và được dùng để sắp xếp gói theo đúng trật tự ở phía thu và phát hiện mất gói.Tuy nhiên nó không được dùng để đặt lịch playout của các gói tin Giá trị của số thứ tự được khởi đầu ngẫu nhiên để tăng tính bảo mật của dòng dữ liệu (khó cho các cuộc tấn công khi không biết phiên bắt đầu từ gói nào). Giá trị của số thứ tự tăng lên 1 sau mỗi gói và khi giá trị của số thứ tự tăng tới giá trị tối đa (65535) thì trở về 0.Và giá trị của số thứ tự tăng đều liên tục không nhảy lại phía sau trừ trưòng hợp quay vòng (wrap-around). Tùy theo ứng dụng người ta có thể dùng thêm số thứ tự mở rộng theo công thức sau: extended_sequence_number = sequence_number + (65535 * wrap_around_count) Timestamp Nhãn thời gian chỉ khoảng thời gian lấy mẫu của octet đầu tiên của dữ liệu media ở trong 1 gói, đựoc dùng để đặt lịch của dữ liệu media Nhãn thời gian là số nguyên 32 bit không dấu tăng tuỳ theo tốc độ của media,và trở về không khi giá trị đạt cực đại.Giá trị bắt đầu là ngẫu nhiên làm cho các cuộc tấn công vào dòng dữ liệu khó khăn hơn Nhãn thời gian không phải là duy nhất trong 1 phiên,2 gói dữ liệu khi có cùng nhãn thời gian có nghĩa là chúng có cùng thời gian lấy mẫu.Cụ thể hơn,trong trưòng hợp truyền 1 khung video có kích thước lớn,khung sẽ chia thành các mảnh nhỏ hơn và được đóng trong các gói có số thứ tự khác nhau nhưng có cùng nhãn thời gian Hinh 32: Quá trình đóng gói khung video thành các gói RTP có cùng nhãn thời gian SSRC Được sử dụng để định danh các bên tham gia trong một phiên RTP. Giá trị của nó chỉ có ý nghĩa trong một phiên và được ánh xạ tới một định danh phiên (long- lived canonical name) CNAME thông qua giao thức điều khiển RTCP. SSRC là một số nguyên 32 bit có giá trị ngẫu nhiên được chọn bởi các bên tham gia khi tham gia vào phiên. Bởi SSRC được chọn ngẫu nhiên từ phía host nên sẽ có thể xảy ra trường hợp 2 bên tham gia có cùng giá trị này. Những xung đột kiểu như vậy có thể được phát hiện khi một ứng dụng nhận được một gói từ một bên tham gia khác có số SSRC trùng với số SSRC của nó, phương pháp phát hiện xung đột này đảm bảo SSRC là duy nhất cho mỗi bên tham gia trong một phiên. Tất cả các gói có cùng SSRC tạo, bên nhận cần phải nhóm các gói theo SSRC để thực hiện quá trình playback. Nếu một bên tham gia nào đó tạo ra nhiều luồng media trong một phiên RTP thì với mỗi luồng sẽ phải có một số SSRC khác nhau để các bên nhận có thể phân biệt gói nào thuộc luồng nào. CSRC Trong các trường hợp thông thường, các gói RTP được tạo ra chỉ bởi một nguồn duy nhất, nhưng khi có nhiều luồng RTP đi qua một bộ mixer hoặc translator, các dữ liệu từ nhiều nguồn này có thể được góp vào một gói RTP. Trong danh sách CSRC chứa thông tin của các bên tham gia có dữ liệu nằm trong gói RTP nhưng không chứa các thông tin liên quan đến thời gian và đồng bộ. Mỗi mã nhận dạng nguồn là một số nguyên 32 bit mang thông tin chính là SSRC của bên tham gia có dữ liệu nằm trong gói. Chiều dài của danh sách CSRC được chỉ định trong trường CC của RTP Header. Các gói chứa danh sách CSRC được tạo ra bởi bộ RTP Mixer, khi nhận được một gói chứa danh sách CSRC, các số SSRC sẽ được sử dụng để nhóm các gói và xử lý một cách bình thường và mỗi CSRC được thêm vào danh sách các bên tham gia đã biết. Mỗi bên tham gia xác định bởi một CSRC sẽ có một luồng giao thức điều khiển gói RTP tương ứng mang đầy đủ thông tin về bên tham gia. Maker Bit đánh dấu Marker trong header của RTP được sử dụng để đánh dấu các sự kiện trong một luồng media, giá trị của nó quyết định bởi đặc tả RTP và định dạng media được sử dụng. Đối với các luồng dữ liệu audio sử dụng đặc tả RTP cho dữ liệu audio và video với cấu hình tối thiểu, bit Marker được đặt là 1 khi gói đầu tiên được gửi sau một khoảng lặng, còn lại được đặt là 0. Bit Marker được đặt là 1 là dấu hiệu cho các ứng dụng biểt được lúc nào nên điều chỉnh thời lượng chơi bởi một chút thay đổi trong độ dài khoảng lặng thường người nghe khó nhận ra. Đối với các luồng dữ liệu video sử dụng đặc tả RTP cho dữ liệu audio và video với cấu hình tối thiểu, bit Marker được đặt là 1 khi đó là gói cuối cùng chứa dữ liệu của một frame video, các gói khác được đặt bằng 0. Bit Marker được đặt là 1 là dấu hiệu cho các ứng dụng biết thời điểm nào bắt đầu giải mã frame đó thay vì chờ đợi một gói có timestamp khác (cũng là một cách nhận biết) để xác định dữ liệu đầy đủ cho một frame. Trong mọi trường hợp, bit Marker chỉ là dấu hiệu cho các ứng dụng. Với luồng audio, thông thường có thể nhận biết điểm kết thúc của một khoảng lặng nhờ mối quan hệ giữa sequence number và timestamp thay đổi. Điểm bắt đầu của một frame video có thể được phát hiện bởi sự thay đổi timestamp. Một ứng dụng có thể sử dụng các nhận biết này để hoạt động tốt nhưng làm giảm khả năng thi hành nếu gói chứa bit Marker bị mất. Version Mỗi gói RTP chứa một số chỉ phiên bản hiện hành của RTP là trường V trong header RTP. Phiên bản hiện thời là 2, phiên bản cũ không còn được sử dụng rộng rãi. Mục đích duy nhất của trường này là kiểm tra tính hợp lệ của gói. Padding Bit Padding trong header RTP được sử dụng để chỉ thị rằng có một đoạn dữ liệu bổ sung ở phía sau dữ liệu chính. Khi bit P được đặt bằng 1, octet cuối cùng của phần dữ liệu sẽ chỉ kích thước (số lượng octet) của phần dữ liệu bổ sung. Phần dữ liệu bổ sung này ít khi được sử dụng nhưng đôi khi cần thiết trong một số phương thức mã hóa,  sửa lỗi hoặc để điều chỉnh kích thước gói cho phù hợp với dung lượng kênh. Header extension RTP cho phép một phần header mở rộng được báo hiệu bằng bit X trong header RTP. Khi bit X được đặt là 1, sau phần header cố định của RTP và trước phần dữ liệu của gói sẽ có một header mở rộng, chiều dài của header này không cố định nhưng đều bắt đầu bằng 16 bit chỉ kiểu và 16 bit chỉ chiều dài (không bao gồm 32 bit này), cho phép các ứng dụng có thể loại bỏ nếu không đọc được thông tin trong header này. Header mở rộng này được cung cấp khi ứng dụng cần nhiều thông tin hơn những gì có trong header cố định của RTP. Chúng rất ít khi được sử dụng. Thông thường thay vì sử dụng header mở rộng, chúng ta sẽ lưu các thông tin bổ sung bên trong phần dữ liệu của gói như là một header của phần dữ liệu. Giao thức điều khiển luồng RTCP Giao thức điều khiển RTCP gửi các thông tin phản hồi từ bên nhận một cách tuần hoàn, các thông tin đó bao gồm phản hồi về chất lượng, xác nhận các bên tham gia, thông tin mô tả nguồn, cảnh báo về sựthay đổi về các thành viên trong phiên, và các thông tin về đồng bộ các luồng. Cấu trúc của gói điều khiển RTCP được thể hiện trong Hình 3-3. Hinh 33: Cấu trúc gói điều khiển RCTP Version (V): Kích thước 2 bit luôn có giá trị bằng 2 thể hiện phiên bản của RTP. Do hiện chưa có kế hoạch cho việc phát triển các phiên bản tiếp theo và các phiên bản cũ không còn sử dụng rộng rãi.Thường được sử dụng để kiểm tra tính hợp lệ của gói. Padding (P): bit P được đặt bằng 1 khi có một hay nhiều octet được bổ sung vào cuối gói, octet cuối cùng lưu thông tin về sốlượng octet được bổ sung. Mục đích sử dụng tương tự như trong gói RTP. Sử dụng sai bit P có thể gây ảnh hưởng tới hoạt động của giao thức RTCP. Item count (IC): Một số kiểu gói RTCP chứa một danh sách các phần tử. Trường này được sử dụng để chỉ số lượng phần tử được đặt trong gói. Số phần tử tối đa là 31, nếu cần hơn 31 phần tử thì cần tạo ra nhiều gói RTCP. IC có thể bằng 0, nghĩa là gói không chứa phần tử nào. Các kiểu gói không sửdụng đến số lượng phần tử có thể dùng trường này vào mục đích khác. Packet type (PT): Chỉ định kiểu thông tin chứa trong gói. Có 5 kiểu gói chuẩn được định nghĩa trong đặc tả của RTP. Các kiểu khác có thể được định nghĩa trong tương lai. Chiều dài (length): Chỉ chiều dài của phần dữ liệu theo sau phần header chung. Đơn vị của nó là 32 bit (4 octet) bởi kích thước của gói RTCP luôn là số nguyên lần của 32 bit. Giá trị độ dài có thể bằng 0 nghĩa là gói chỉ chứa 4 octet header. Theo sau header RTCP là phần dữ liệu và phần dữ liệu bổ sung nếu có. Gói RTCP không bao giờ được truyền đi một cách riêng lẻ, thay vào đó chúng luôn được gộp lại với nhau tạo thành một nhóm gói (compound packets) để cùng truyền đi. Mỗi nhóm gói được đặt trong một gói ở lớp thấp hơn, thông thường là gói UDP/IP để truyền đi. Nếu nhóm gói được mã hóa, nhóm gói sẽ bắt đầu bằng một trường 32 bit có giá trị ngẫu nhiên. Hinh 34: Cấu trúc gói SR RTCP RR: Receiver Reports Một trong những chức năng chủ yếu của RTCP là ghi nhận về chất lượng đường truyền, chức năng này được thực hiện thông qua gói RR được gửi bởi tất cả các bên tham gia có nhận dữ liệu. Cấu trúc một gói RR được thể hiện qua Hình 3-5. Một gói RR có thông tin về kiểu gói là 201, ngoài ra nó còn chứa số SSRC của bên tham gia đã gửi gói RR này và theo sau đó là các khối báo cáo nếu có được định lượng bằng trường RC. Hinh 35: Cấu trúc gói SR Mỗi khối thông tin mô tả về chất lượng dữ liệu nhận của một bên tham gia đang nhận dữ liệu RTP trong quá trình báo cáo. Tổng số có thể có đến 31 khối báo cáo trong một gói RR. Nếu có hơn 31 bên tham gia trong phiên thì cần phải tạo ra nhiều gói RR và gộp chúng vào trong một nhóm gói. Mỗi khối thông tin có 7 trường và có kích thước tổng cộng là 24 octet. Loss fraction: Tỷ lệ gói bị mất mát là số gói bị mất trong một chu kỳ báo cáo chia cho sốgói được mong đợi. Giá trị về jitter là một giá trịước lượng từ thống kê về sựthay đổi thời gian truyền trong mạng của các gói dữ liệu RTCP được gửi từ bên tham gia. Last sender report (LSR) timestamp: nhãn thời gian báo cáo lần gửi cuối cùng của SR là một trường chứa 32 bit trong 64 bit NTP (Network Time Protocol) là thời điểm gói SR (Sender Report) gần đây nhất nhận được từ một bên tham gia có số nhận dạng SSRC. Nếu không nhận được gói SR nào thì trường này được đặt bằng 0. Delay since last sender report (DLSR): Độ trễ tính từ lần gửi gói SR cuối, tính theo đơn vị1/65536 giây, là độ trễ giữa thời điểm nhận được gói SR gần đây nhất từ một bên gửi có số nhận dạng SSRC và thời điểm gửi khối báo cáo này. Nếu không có gói SR nào được nhận từ bên gửi có số nhận dạng SSRC thì DLSR được gán bằng 0. Thông tin phản hồi chất lượng từ gói RR rất hữu ích không chỉđối với bên gửi mà với cả các bên tham gia khác và với một số công cụđo lường khác. Những thông tin này cho phép bên gửi điều chỉnh phương thức truyền dữ liệu hợp lý. Ngoài ra các bên tham gia khác cũng có thểxác định được các vấn đề xảy ra là do bản thân nó hay là vấn đề chung của các bên nhận khác, và các hệ thống quản lý mạng cũng có thể sử dụng thông tin này đểđánh giá hiệu năng của mạng. Bên gửi cũng có thể sử dụng các giá trịLSR và DLSR để tính toán thời gian truyền từ nó với mỗi bên nhận. Tỷ lệ mất mát được sử dụng để lựa chọn định dạng media và phương thức sửa lỗi. Trường jitter thường dùng để phát hiện tắc nghẽn. RTCP SR: Sender Reports Ngoài việc sử dụng các thông tin phản hồi chất lượng từ các bên nhận, RTCP còn tạo ra các gói SR là các gói gửi bởi bên tham gia vừa thực hiện gửi dữ liệu. SR cung cấp thông tin về luồng dữliệu được gửi, chủ yếu phục vụ cho mục đích đồng bộ các luồng dữ liệu ở bên gửi (ví dụ đồng bộ hình và tiếng). Cấu trúc của một gói SR thể hiện trên Hình 29. Hinh 36: Cấu trúc của 1 block gói SR Mặc dù nhãn thời gian NTP trong gói SR sử dụng định dạng chuẩn của NTP tuy nhiên đồng hồ lại không được đồng bộ với Network Time Protocol hay một thứ gì đó chính xác, ổn định. Nếu bên nhận cần đồng bộ giữa các luồng media, các luồng này cần có chung đồng hồ. RTP timestamp tương tự với NTP timestamp nhưng mục đích của nó là để chỉcác đơn vị của đồng hồ media RTP. Giá trị này nói chung không giống giá trị RTP timestamp của gói dữ liệu bởi đôi khi có những khoảng thời gian trôi đi từ lúc dữ liệu trong gói được lấy mẫu. Sender's packet count: là số gói dữ liệu màmột bên gửi tạo ra kể từlúc bắt đầu phiên. Sender's octet count: là số octet chứa trong phần dữ liệu của các gói dữ liệu nói trên (không bao gồm header và dữ liệu bổ sung). Các trường packet count và Octet count sẽđược xác lập lại khi bên gửi thay đổi số nhận dạng SSRC (ví dụ khi xung đột SSRC). Các trường này cho phép các bên nhận tính toán tỉ lệ dữ liệu trung trình của nguồn gửi. Nhờ các thông tin từ gói SR mà các ứng dụng có thể tính toán tỷ lệ dữ liệu trung bình và tỷ lệ gói trung bình trong một khoảng thời gian mà không cần nhận dữ liệu. Tỷ số giữa hai thành phần trên gọi là kích thước tải tin trung bình. Nếu cho rằng các gói bị mất mát không phụ thuộc vào kích thước gói thì số gói nhận được bởi từng bên nhận nhân với kích thước tải tin trung bình là lưu lượng tới bên nhận đó Tải dữ liệu của RTP cho h264 Hinh 37: 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) Hinh 38 : 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 Hinh 39 : 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 Hinh 310 : 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 Hinh 311 : 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 Hinh 312 : Cấu trúc gói MTAP-16 MTAP 24 Hinh 313 : Cấu trúc gói MTAP-24 Đơn vị phân đoạn (Fragmentation Unit hay FU) Hinh 314 : 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 Hinh 315: Cấu trúc gói FU-A FU-B Hinh 316 : Cấu trúc gói FU-A Cross-layer design cho mạng adhoc Giới thiệu về cross-layer Mạng không dây ad hoc được đặc trưng bởi sự thay đổi không dự đoán được của chất lượng kênh truyền như: cụ thể 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 ad hoc có rất nhiều thách thức đặc biệt khi có sự thay đổi của topo mạng (các nút di chuyển tương đối so với nhau), lưu lương mạng, độ trễ của gói dữ liệu, mất gói dữ liệu đặc biệt là sự hạn chế về mặt tài nguyên của chính các thiết bị liên lạc sử dụng trong mạng ad hoc: năng lượng tiêu thụ, khả năng xử lí.của các thiết bị, phạm vị hoạt động. Hinh 41 : Kiến trúc hệ thống Việc thiết kế cross-layer nhằm mục đich: 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 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 phả hồi từ phía thu sẽ kết hợp thêm thông tin được đưa lên từ tầng mạng (netwwork) như rtt(round-trip time),PLR(packet los rate) để tính toán hợp lí thông số đầu vào cho bộ mã hóa Đồng thời phía phát sẽ lựa chọn các gói sẽ được phát lại dựa trên danh sách gói mất được yêu cầu 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 các tập 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ị QP ( quantisation parameter ) của bộ mã hóa Phiên làm việc có sự liên thông của 3 tầng :tầng  ứng dụng(application layer), tầng truyền(transport layer), và tầng mạng (network layer) Sơ đồ thiết kế Hinh 42: Sơ đồ khối của thiết kế Thiết kế bao gồm 3 module chính: Module 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ã hóa H264 Module transport :thực hiên các chức năng đóng gói luồng video được mã hóa h264 và truyền đi các gói RTP.Mặt khác module này cũng xử lí các bản tin phản hồi từ client đưa về sau đó thực hiện truyền lai và đưa thông tin lên lớp trên (lớp ứng dụng) Module routing:thực hiên việc duy trì bảng đí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 :RTT,PLR phục vụ cho việc tính toán tốc độ phát của phía phát và việc lựa chọn đúng đề cần truyền lại các gói mất theo yêu cầu từ client Và việc triển khai thiết kế sử dụng các phần mềm mã nguồn mở:: vlc-0.8.6c => streaming server, client x264 thực hiện chức năng của bộ mã hóa H264 ffmpeg thực hiện chức năng giải mã live hỗ trợ giao thức rtsp Module transcode Hinh 43: Module transcode Module này thực hiên chức năng chuyển mã dữ liệu đưa từ đầu vào, sau đó mã hóa dữ liệu đầu vào thành luồng byte được mã hóa theo chuẩn H264.Đồng thời module này còn làm nhiệm vụ tính toán giá trị QP cho các khung hình tiếp theo.Hay nói cách khác module này sẽ cập nhật thời gian thực thông số mã hóa cho bộ mã hóa H264.Trong module này ngoài việc thực hiên chức năng chuyển mã(transcode),thì có thêm chức năng thực hiên tính toán và cập nhật thông số mã hóa như giá trị QP cho bộ mã hóa trong thời gian thực Rate control Hinh 44: Module con trong module transcode để tính giá tị QP cho các khung hình sau Trong đó : R1(t) là tốc độ bit của luồng dữ liệu đi ra khỏi bộ mã hóa h264 R2(t) là tốc độ bit của luồng dữ liệu tại tầng truyền QP(t) là tham số mã hóa tại thời điểm hiện tại của bộ mã hóa H264 QP(t+T) là tham số mã hóa của bộ mã hóa H264 sau khi được tính toán với là tổng số gói nhận được tại phía thu còn là tổng số gói đươc gửi đi bởi phía phát Thông số lossrate được tính toán tại phía phát dựa trên thông tin feedback nhận được tại phía thu..Các gói khi truyền trên mạng có thể bị mất hoặc đến quá muộn.Trong cả 2 trường hợp trên các gói video sẽ không được sử dụng tại phía thu .Nếu lossrate giảm chứng tỏ có thể số gói mất trên đường truyền tăng hoặc thời gian truyền trên kênh truyền tăng lên (do xung đột,băng thông giảm hoặc do khoảng cách giữa phía phát và phía thu tăng lên),điều đó gián tiếp phản ánh chất lượng kênh truyền của chúng ta.Mặt khác,từ lossrate chúng ta có thể tính được số gói cần truyền lại để phía thu có thể nhận được gói thành công là 1/lossrate Việc tính toán lossrate dựa vào mối quan hệ giữa các đại lượng : R1(t),lossrate,QP(t) để tính ra được giá trị QP(i+T) cho các khung tiếp theo Hàm cập nhập tham số thời gian thực cho bộ mã hóa được khai báo trong thư viện x264.h của x264 int crosslayer(struct crosslayer_t param) { if(param.i_control==1) { i_CRF = param.i_CRF;//gia trị crf cho che do crf i_QP = param.i_QP;//gia tri qp cho che do QP b_crf = param.b_crf;//co bat che do crf b_cqp = param.b_cqp;//co bat che do QP control =param.i_control; param.i_control=0; } return param.i_control; } Module transport Hinh 45: Module transport Module này thực hiên chức năng đóng gói dữ liệu thành các gói RTP sau đó truyền đi trên mạng.Sau khi mỗi gói RTP được truyền đi sẽ được thống kê lại như :số thứ tự của gói RTP,loại NAL chứa trong gói, mức độ ưu tiên khi truyền đi, thời gian truyền gói đi. Và cũng trong module này sẽ nhận và xữ lí gói tin feedback từ phía thu phản hồi về phía phát, cùng với thông tin thống kê phía phát sẽ tính toán xem cấn truyền lại với số lượng gói là bao nhiêu đề có thể phía thu nhận được 1 gói RTP Feedback a)Cơ chế tìm gói mất Hinh 46: Cơ chế tìm gói mất 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 và được đặt là 0 sau chu kì là 5s Vị trí của 1 phần  tử bất kì trong mảng tuân theo quy luật sau: a[offset]=A với offset=A-a[0]; Sau chu kì 5 s,duyệt mảng 1 lần Expected number(EN):số gói được mong đợi (không xảy ra mất mất gói hoặc đến quá muộn) Actual number(AN):số gói thực tế nhận được sau chu kì T(s) Ta có AN<=EN với EN=1+max{a[j]} và i=1..,1000 Ta chỉ xét EN phần tử của mảng tính từ phần tử a[0]   if(Index==0)    {             a[Index]=tk->rtpSource->curPacketRTPSeqNum();             fprintf(stdout,"seq_num=%d\n",a[Index]);             Index++;         }       else    {        Index=tk->rtpSource->curPacketRTPSeqNum()-a[0];        a[Index]=tk->rtpSource->curPacketRTPSeqNum();    } a)Bản tin feedback sẽ được tạo một cách đều đắn theo chu kì 2s.Nội dung bản tin feedback Hinh 47: Bản tin feedback struct NACK_t {     int receivedpacket;//so goi nhan duoc tai thoi diem tao feedback     int *p_list_losspacket;//danh sach goi mat     int i_losspacket;//so goi mat } c) Tạo gói tin feedback Một tuyến được khởi tạo để xử lí dữ liệu danh sách gói nhận được,và tạo feedback trở về server.Việc sử dụng 2 tuyến giúp cho việc tạo phản hồi của client sẽ tuân theo chu kì và linh hoạt hơn không ảnh hưởng tói việc nhận và xử lí gọi ở client //dong khoa mutex cua tuyen de thong tin trong mang a[] khong bi thay doi      pthread_mutex_lock(&lock);      for(i=0;i<=1000;i++)      {       b[i]=a[i];      }      Index=0;   //refresh lai mang danh sach goi nhan duoc      memset(a,0,1000*sizeof(int));     //mo khoa mutex cua tuyen      pthread_mutex_unlock(&lock) ;      int size=realsize(b,1000);      last_seq=b[size];      temp.i_lostpacket=0;      temp.receivedpacket=0;      for(i=0;i<=size;i++)      {       if(b[i]>0)         {          temp.receivedpacket++;          fprintf(stdout,"%d\n",b[i]);         }       else           {         temp.p_list_lostpacket[temp.i_lostpacket]=b[0]+i;         temp.i_lostpacket++;         if(b[0]+i>0)             fprintf(stdout,"SEQ GOI MAT %d\n",b[0]+i);           }      } d) Xử lí gói tin feedback Phía phát nhận gói tin feedback tại cổng 10000, và nó hiển thị danh sách gói mất lên màn hình while(1) { cliAddrLen = sizeof(echoClntAddr); /* Block until receive message from a client */ if ((recvMsgSize = recvfrom(sock,&RecvBuffer,sizeof(struct NACK_t), 0, (struct sockaddr *) &echoClntAddr, &cliAddrLen)) < 0) puts("recvfrom() failed"); crf_Mode=x264_noncrf; cqp_Mode=x264_cqp; if(QP-1<8) { QP=40; } else { QP-=1; } fprintf(stdout,"gia tri QP:%d\n",QP); if(Count>0) { fprintf(stdout,"SO GOI NHAN DUOC %d\n",RecvBuffer.receivedpacket); fprintf(stdout,"SO GOI PHAT %d\n",Count); lossrate=RecvBuffer.receivedpacket/Count; fprintf(stdout,"lossrate=%f\n",lossrate); Count=0; } fprintf(stdout,"DANH SACH GOI MAT\n"); for(i=0;i<=RecvBuffer.i_lostpacket-1;i++) { fprintf(stdout,"%d\n",RecvBuffer.p_list_lostpacket[i]); } } Selection và re-stream Hinh 48: Module selection và re-stream Việc truyền lại từ server theo yêu cầu từ phía client không thể thức hiện toàn bộ mà phải có cơ chế lựa chọn thông minh để xem trong danh sách những gói mất hoặc đến quá muộn ở phía client thì gói tin nào mang thông tin quan trọng như khung hình I, P, hoặc slice được mã hóa của ảnh IDR, tập tham số SPS,PPS.Việc truyền lại có lựa chọn giúp cho server tiết kiệm được năng lượng, không tiêu tốn năng lượng vô ích cho các gói tin không quan trọng Bộ đệm dành cho truyền lại có kích thước chứa được tối đa 1000 gói tin (khoảng 1000 kbyte).Mỗi gói tin đều có thời gian tồn tại của mình trong bộ đệm dành cho truyền lại.Cứ sau khoảng thời gian hoặc tràn bộ đệm dành cho truyền lại thì môt số gói có thời gian tồn tại sẽ bị hủy khỏi bộ đệm Cấu trúc gói tin thống kê gói phát đi: StatTable_t {   uint8_t id_packet;//vi tri cua goi khi tach 1 nal unit thanh nhieu goi RTP   uint8_t nal_nri_idc;//muc do uu tien cua nal unit khi duoc truyen   uinit8_t naltype;//loai nal unit chua trong goi RTP   uint16_t seq_num;//so thu tu cua goi tin RTP   time_t ;;//thoi diem goi duoc gui di } Hinh 49 :Điều kiện thời gian để chọn gói truyền lại Trong đó là thời điểm xử lí xong gói tin feedback là thời điểm gói RTP được gủi đi và được server lưu lại trong bộ thống kê là thời điểm gói RTP sẽ bị hủy đi trong bộ đệm dành cho việc truyền lại là khoáng thời gian tồn tại của gói RTP được lưu trong bộ dệm truyền lại Căn cứ vào các thông tin như độ ưu tiên của đơn vị NAL chứa trong gói RTP, thời gian phát đi của gói để quyết định xem gói RTP cần truyền lại có quan trọng hay không=>danh sách gói cần truyền lại Hinh 410:Lựa chọn gói truyền lại Đầu tiên chúng ta kiểm tra xem gói tin đã được truyền lâu hay chưa. là thời gian truyền gói lần đầu tiên. thời điểm hiện tại bắt đầu xứ lí gói tin. Nếu ->thì yêu cầu truyền lại của gói tin sẽ bị hủy (bởi có thể gói RTP được yêu cầu đã bị hủy khỏi bộ đệm dành cho truyền lại).Và nal_nri_idc là trường thông tin chứa trong header của 1 NAL uint, chứa mức độ ưu tiên khi truyền của gói tin.Khi gói tin RTP chứa dữ liệu của một single NAL (PPS, SPS) hay các ảnh (IDR, khung I hoặc P) thì sẽ được ưu tiên truyền lại nếu như không được truyền quá lâu. Module routing Hinh 411: Module routing Module này sẽ sử dụng các giao thức định tuyến và duy trì 1 bảng thông tin định tuyến về các nút trong mạng.Mọi sự thay đổi của các nút (thêm 1 nút mạng mới hoặc có 1 nút tách khỏi mạng) sẽ được cập nhật.Đồng thời thông tin chứa trong bảng định tuyến sẽ giúp cho phía phát tìm được đường đi tối ưu tới phía thu.Một số thuật toán định tuyến sử dụng trong mạng adhoc như adaptive routing, pro-active routing,… Module này sẽ được thực thi bởi 1 chương trình riêng ,tách biệt với chương trình thưc hiện 2 module transcode và transport.Việc trao đổi dữ liệu thông qua cơ chế chia sẻ vùng nhớ chung (shared memory) trong IPC (intercommunication process hay giao tiếp giữa các tiến trình) trên linux Hinh 412: Bảng dịnh tuyến khi chạy chương trình olsrd Kết quả nghiên cứu, kết luận và hướng nghiên cứu tiếp theo Test case Test case 1: Streaming server không thay đổi tham số mã hóa khi hoạt động Goal Làm kết quả chuẩn để so sánh khi thay đổi tham số bộ mã hóa thì tốc độ biến đổi thế nào. Test conditions Hardware: 1 PC chạy linux địa chỉ 192.168.10.89 1 PC chạy window 192.168.10.99 1 Webcam Labtek 1 card wi-fi USB ralink chạy trên PC linux,1 card wi-fi USB D-link chạy trên PC window XP,2 card wi-fi chạy chế độ ad hoc Software: Streaming server chạy trên PC (vlc-0.8.6c) với bộ encoder h264 (x264 chạy chế độ constant QP) chạy trên linux.Dữ liệu lấy từ webcam Labtec Client chạy trên PC chạy hệ điều hành windowXP để nhận dữ liệu từ streaming server. Sử dụng công cụ netlimiter và nettool của window để đo tốc độ luồng video đến client Test procedure: Kiểm tra cáp kết nối giứa server và client Cấu hình 2 card wi-fi hoạt động ở chế độ ad-hoc. Chạy streaming server trên PC chạy linux phát dữ liệu tới client.. Chạy 1 client chạy linux với đầu vào là rtsp://10.0.0.100:554/test.sdp. Bật client trên window.Chọn đầu vào là rtsp://10.0.0.100:554/test.sdp . Bật các công cụ trên network monitoring phía client như Netlimiter hoặc của chính windowXP , DU Meter. Chụp màn hình kết quả thu được :tốc độ bit của luồng video dến. Test case 2: Streaming server thay đổi tham số trong thời gian thực khi truyền thành công 50 gói RTP liên tiếp Goal Kiểm tra quy luật thay đổi tốc độ bit của phía phát khi thay đổi giá trị QP Test conditions Hardware: 1 PC chạy linux địa chỉ 192.168.10.89 1 PC chạy window 192.168.10.99 1 Webcam Labtek 1 card wi-fi USB ralink chạy trên PC linux,1 card wi-fi USB D-link chạy trên PC window XP,2 card wi-fi chạy chế độ ad hoc Software: Streaming server chạy trên PC (vlc-0.8.6c đã được thay đổi mã nguồn và chạy với chế độ constant QP,giá trị QP biến thiên hình vẽ) với bộ encoder h264 (x264 có thể cập nhật giá trị QP thời gian thực) chạy trên linux.Dữ liệu lấy từ webcam Labtec Client chạy trên PC chạy hệ điều hành windowXP để nhận dữ liệu từ streaming server. Sử dụng công cụ netlimiter và nettool của window để đo tốc độ luồng video đến client Test procedure: Kiểm tra cáp kết nối giứa server và client Cấu hình 2 card wi-fi hoạt động ở chế độ ad-hoc Chạy streaming server trên PC chạy linux phát dữ liệu tới client. Chạy 1 client chạy linux với đầu vào là rtsp://10.0.0.100:554/test.sdp Bật client trên window.Chọn đầu vào là rtsp://10.0.0.100:554/test.sdp Bật các công cụ trên network monitoring phía client như netlimiter hoặc của chính windowXP , DU meter Chụp màn hình kết quả thu được :tốc độ bit của luồng video dến Test case 3: Streaming server thay đổi tham số trong thòi gian thực khi nhận thông tin từ phản hồi từ client Goal Kiểm tra kết quả thay đổi tốc độ bit của phía phát, kiểm tra cơ chế feedback của hệ thống Test conditions Hardware: 1 PC chạy linux địa chỉ 192.168.10.89 1 PC chạy window 192.168.10.99 1 Webcam Labtek 1 card wi-fi USB ralink chạy trên PC linux,1 card wi-fi USB D-link chạy trên PC window XP , ,2 card wi-fi chạy chế độ ad hoc Software: Streaming server chạy trên PC (vlc-0.8.6c đã được thay đổi mã nguồn và chạy với chế độ constant QP,giá trị QP biến thiên hình vẽ) với bộ encoder h264 (x264 có thể cập nhật giá trị QP thời gian thực) chạy trên linux.Dữ liệu lấy từ webcam Labtec Client chạy trên PC chạy hệ điều hành windowXP để nhận dữ liệu từ streaming server. Sử dụng công cụ netlimiter và nettool của window để đo tốc độ luồng video đến client Test procedure: Kiểm tra cáp kết nối giứa server và client Cấu hình 2 card wi-fi hoạt động ở chế độ ad-hoc Chạy streaming server trên PC chạy linux phát dữ liệu tới client. Chạy 1 client chạy linux với đầu vào là rtsp://10.0.0.100:554/test.sdp Bật client trên window.Chọn đầu vào là rtsp://10.0.0.100:554/test.sdp Bật các công cụ trên network monitoring phía client như netlimiter hoặc của chính windowXP ,hay DU meter Chụp màn hình kết quả thu được :tốc độ bit của luồng video dến Kết quả thu được Tiến hành thí nghiệm trong môi trường mạng LAN có dây để đo tốc độ. Test report No Test type/ Test ID Testing Parameters Date/ Time Duration Tester Expected result Actual result Remarks Test case 1 Khi QP không thay đổi 21/5/08 5m Đỗ Mạnh Đoàn Tốc độ biến đổi không nhiều theo thờii gian Pass Tốc đô bit lớn nhất là 96 kbyte/s Test case 2 Khi QP thay đổi theo chu kì 50 gói truyền thành công ở server 21/5/08 10m Đỗ Mạnh Đoàn Tốc độ thay đổi theo chu kì thay đổi của giá trị QP đầu vào bộ mã hóa Pass Tốc đô bit lớn nhất là 1.9 Mbyte/s Test case 3 Khi QP thay đổi theo chu kì 1s tạo feedback từ client về server 21/5/08/ 10m Đỗ Mạnh Đoàn Tốc độ biến đổi theo thờii gian Pass Tốc đô bit lớn nhất là 500 kbyte/s Remarks: Chất lượng của video thu được tại client có chất lượng tốt khi truyền ở chế độ constrant QP của bộ encoder Việc thay đổi giá trị mã hóa theo chu kì dẫn tới việc tốc độ bit truyền đi cũng thay đôi theo chu kì Việc truyền với khoảng cách gần nên chưa xảy ra mất gói nhiều ,độ trễ nhỏ Khi không thay đổi tham số mã hóa trong thời gian thực Tại phía thu Hinh 51: Tốc độ bit của luồng video đến client Phía phát sẽ phát tốc độ gần như không thay đổi nhiều tới các client và không nhận biết được sự thay đổi của kênh truyền=>Không sử dụng được cho mạng không dây khi chất lượng kênh biến đổi liên tục, và không dự đoán được. Khi thay đổi tham số mã hóa Đầu vào dữ liệu thay đổi theo quy luật sau: Hinh 52: Giá trị QP thay đổi theo số gói truyền thành công Hinh 53: Hình thu được tại phía thu Hình 54: Kết quả tại phía thu Điều kiện thay đổi dựa trên căn cứ thay đổi tham số sau khi gủi thành công 50 gói RTP liên tiếp nhau: Chất lượng ảnh thu được tại phía thu có chất lượng tốt Khi thay đổi thông số QP của bộ mã hóa dựa trên việc nhận và xử lí feedback Hinh 55:Tốc độ tại client khi server thay đổi tốc độ dựa trên feedback của client Hinh 56:Tốc độ tại phía thu khi QP thay đổi từ 8 đến 40 (dựa vào việc nhận và xử lí feedback) Danh sách gói mất tại phía phát và phía thu Hinh 57: Danh sách gói mất được lấy từ gói tin feedback tại phía phát Hinh 58: Danh sach gói nhận được tại phía thu Kết luận Đồ án xây dựng hoàn chính cơ chế truyền thích nghi trên PC, và cho hiệu quả tốt trong việc tìm và xử lí danh sách gói mất tịa phía thu client-server .Việc thay đổi tốc độ thời gian thực đã thực hiện được thành công.Đồ án án đã xây dựng được cơ chế cập nhật giá trị của tham số lượng tử (QP) trong thời gian thực , tuy chưa thể tính toàn giá trị QP phù hợp từ các thông số nhận được.(lossrate,..) Tuy nhiên việc truyền lại gói và cơ chế tính toán thông số phù hợp cho bộ mã hóa chưa được hoàn thiện.Môi trường chủ yếu chạy trong mạng LAN có dây,mạng ad hoc trong khoảng cách ngắn , và chỉ từ client-server chưa có nút trung gian. Hướng nghiên cứu tiếp theo Do việc truyền video trong mang không dây gặp nhiều vấn đề như: Băng thông hạn chế trong khi tốc độ luồng dữ liệu lớn Việc điều khiển tốc độ truyền dữ liệu ở bên phát Vấn đề năng lượng do các nút di chuyển và kích thước nhỏ Nhiễu do việc di chuyển giữa các nút,do điều kiện môi trường luôn thay đổi theo không gian và thời gian => Hướng nghiên cứu chính là xây dựng hoàn thiện cơ chế truyền thích nghi cho mạng không dây ad hoc, và có thể triển khai cross-layer trên các board mạch nhúng,và việc điều khiển tốc độ bộ mã hóa trên PC sẽ được thay bằng điểu khiển trên phần cứng.Và đồng thời cơ chế truyền thích nghí cũng sẽ được áp dụng cho “Hệ thống chia sẻ video thời gian thực trên mạng hỗn hợp” Hinh 59: Mô hình hệ thông chia sẻ video thời gian thực trên mạng hỗn hợp Tài liệu tham khảo Iain E. G. Richardson , “H.264 and MPEG-4 Video Compression Video Coding for Next-generation Multimedia “, John Willey & Son 2003 Tien Pham Van, “Proactive ad hoc devices for relaying real-time video packets”, Doctor of Philosophy Dissertation 2007 ITU-T Recommendation H.264 Advanced video coding for generic audiovisual services: Advanced video coding for generic audiovisual services 2006 Colin Perkin, “RTP: Audio and Video for the Internet”, Addison Wesley 2003 S. Wenger M.M. Hannuksela, T. Stockhammer , Request for Comments 3984: RTP Payload Format for H.264 Video,2005 David Austerberry, “The Technology of Video and Audio Streaming”, Focal press 2005 Victor Ramamoorthy ,”A ρ-domain Rate Control Algorithm for the H.264 Encoder “,CA 94566 2004 László Czúni, Gergely Császár, Attila Licsár,”Estimating the Optima Quantization Parameter in H.264”, Pannon University, Veszprém, Hungary 2006 M. Mahdi Ghandi and Mohammed Ghanbari ,”A lagrangian optimized rate control algorithm for the h.264/avc encoder”,Department of Electronic Systems Engineering, University of Essex 2007 Thomas Wiegand et al, .Overview of the H.264/AVC video coding standard,. IEEE Trans. on circuits and systems for video technology, Vol. 13, No. 7, pp. 560-576, July 2003 Thomas Wiegand et al, .Rate-Constrained Coder Control and Comparison of Video Coding Standards,.IEEE Trans. on circuits and systems for video technology,Vol. 13, No. 7, pp. 688-703, July 2003 Thomas schierl and Thomas wiegand.“H.264/avc rate adaptation for Z. Li et al., "Proposed Draft of Adaptive Rate Control," JVT-H017, 8th Meeting: Geneva, May 2003 ngày truy cập cuối 22/5/2008 truy cập lần cuối ngày 22/5/08 truy cập ngày cuối là 20/5/2008 truy cập ngay cuối 20/5/2008