5  Sử dụng giao thức truyền tải thời gian thực (RTP)

5.1  Tổng quan

Có một số phương pháp đóng gói gói tin RTP cho dữ liệu mã hóa theo chuẩn ISO/IEC 14496. Việc đóng gói gói tin nhận biết (như các khung video phân tách tại các vùng bao của các khung con) là một nguyên lý trong giao thức truyền tải thời gian thực, vì vậy phải cần tới một số lược đồ RTP để đồng thời đáp ứng được cho các loại thông tin khác nhau như hình ảnh, âm thanh, video …, và cho các phương pháp mã hóa khác nhau (ví dụ mã hóa âm thanh theo AAC và theo CELP). Tiêu chuẩn này không định rõ bất kỳ định dạng tải nào, tuy nhiên có định rõ nền tảng chung cho việc thiết lập và sử dụng định dạng tải tin một cách thích hợp.

Tiêu chuẩn này yêu cầu, tất cả lược đồ đóng gói tin được sử dụng trong tiêu chuẩn này đều có một số đặc tính chung: tuy nhiên, những đặc tính đó phụ thuộc vào thực tế phiên truyền RTP chứa đựng một dòng đơn số liệu cơ sở hoặc dòng dữ liệu ghép kênh linh hoạt (flexmux).

5.2  Truyền tải một dòng dữ liệu cơ sở

Trong trường hợp phiên truyền RTP chỉ chứa một dòng dữ liệu cơ sở, các đặc tính sau được áp dụng:

• Mốc thời gian (timestamp) RTP tương ứng thời gian xuất hiện (như Mốc thời gian kết hợp - CTS) của đơn vị truy cập (AU) đầu tiên trong gói tin.

• Các gói tin RTP có các số tuần tự theo thứ tự truyền. Các trường tải tin về mặt logic hay vật lý đều có các số tuần tự SL (lớp đồng bộ), theo thứ tự mã hóa, đối với mỗi dòng dữ liệu cơ sở.

• Thang thời gian (timescale) (xung đồng hồ điểm cho mỗi giây) của chuẩn ISO/IEC 14496, mà là phân giải mốc thời gian (timeStampResolution) trong hệ thống ISO/IEC 14496, phải được sử dụng như thang thời gian RTP và được công bố trong giao thức mô tả phiên SDP cho mỗi dòng RTP.

...

...

...

• Các dòng dữ liệu phải được đồng bộ bằng kỹ thuật RTP (có chú thích trong các thông báo của bên gửi RTCP). Khi sử dụng chuẩn xung tùy đối tượng (OCR), nó được ánh xạ logic tới Giao thức đồng bộ thời gian mạng (NTP) sử dụng trong RTCP.

• Các lược đồ đóng gói gói tin RTP được sử dụng cho các dòng dữ liệu ‘đơn lẻ’ (như các hệ thống không phải là mã hóa theo chuẩn ISO/IEC 14496, như BIFS); hoặc chúng được sử dụng trong toàn trong cả một lần thể hiện sử dụng nền tảng chung mô tả đối tượng. Đối với trường hợp sau cùng, một trường mô tả cấu hình lớp đồng bộ (SLConfigDescriptor) được gửi đi để mô tả dòng dữ liệu. Về logic, mỗi dòng dữ liệu RTP được chuyển đi thông qua một chức năng ánh xạ mà được quy định để sử dụng các định dạng trường tải tin; chức năng này ánh xạ các trường sang một dòng dữ liệu đóng gói gói tin lớp đồng bộ (SL). Trường mô tả cấu hình lớp đồng bộ (SLConfigDescriptor) mô tả dòng dữ liệu logic này, không phải là các bit thực tại trong trường tải tin RTP. Ví dụ, số tuần tự RTP có thể được dùng để tạo số tuần tự của trường tiêu đề gói tin lớp đồng bộ (SLPacketHeader); các trường lớp đồng bộ SL khác có thể được thiết đặt theo cách này, các giá trị này có thể là giá trị động hoặc giá trị tĩnh trong đặc tả của trường tải tin. Ví dụ, như tất cả các gói tin RTP mang một mốc thời gian kết hợp, có cờ thuộc tính trong trường tiêu đề lớp đồng bộ (SL) để chỉ thị sự hiện diện của nó, thông thường có thể là giá trị tĩnh được xác định bằng ‘true’. Mỗi định dạng trường tải tin cho nội dung mã hóa theo chuẩn ISO/IEC 14496 phải quy định các chức năng ánh xạ cho thông tin của trường mô tả cấu hình lớp đồng bộ (SLConfigDescriptor) và trường tiêu đề gói tin lớp đồng bộ (SLPacketHeader). Trong trường hợp tham chiếu tới khuyến nghị RFC 3016 (Định dạng tải khung RTP cho các dòng mã hóa theo chuẩn ISO/IEC 14496), việc ánh xạ được quy định trong một tài liệu riêng.

Hình 1 - Ánh xạ gói tin RTP sang gói tin lớp đồng bộ

5.3  Lựa chọn định dạng trường tải tin

Các định dạng trường tải tin khác cũng được sử dụng. Chúng được báo hiệu như là trường nhận dạng (ID) tải tin động, được định nghĩa với tên phù hợp (như tên trường tải tin trong hàm thuộc tính RTPMAP của giao thức SDP). Đặc biệt, việc phát triển của các trường tải tin RTP chuyên biệt cho video (như các gói tin video tương ứng) và âm thanh (như việc cung cấp cơ chế xen kẽ) là cần thiết. Như vậy, các lược đồ này có thể tương thích với lược đồ mặc định đã được yêu cầu ở đây.

Có thể lựa chọn các định dạng trường tải tin RTP cho một dòng dữ liệu cho trước (như là dòng dữ liệu cơ sở, dòng dữ liệu gói tin lớp đồng bộ, dòng dữ liệu sử dụng ghép kênh linh hoạt (FlexMux), ...). Cụ thể:

• các thiết bị đầu cuối thi hành một hệ thống con nhất định (như video) đảm nhiệm ít nhất một dòng dữ liệu cơ sở (ES) và việc đóng gói SL mặc định của dòng dữ liệu đó; điều này có nghĩa rằng chấp thuận theo khuyến nghị RFC 3016 (RTP payload format for MPEG-4 audio/visual streams) và cũng chấp thuận định dạng trường tải tin chung của chuẩn hình ảnh MPEG-4;

• các thiết bị đầu cuối thi hành một định dạng trường tải tin nhất định đảm nhiệm bất kỳ dòng dữ liệu chuyển qua nào mà định dạng của chúng có thông tin giải mã, thậm chí việc đóng gói đó là bất thường so với việc đóng theo một phương pháp cụ thể “tốt nhất”.

...

...

...

Đối với những dòng dữ liệu mã hóa hình ảnh, âm thanh đó, việc yêu cầu chất lượng dịch vụ QoS nhất định (thực hiện được), phải xem xét thêm các giải pháp như việc nâng cao chất lượng so với chất lượng hiện tổ chức IETF quy định trong lĩnh vực này (nhưng không giới hạn với trường hợp sử dụng mã hóa sửa lỗi - FEC, việc khởi truyền lại, hay việc thực hiện lặp lại). Tuy nhiên, các kỹ thuật trong việc sửa lỗi dữ liệu độc lập, hay được kết hợp với các giải pháp mã hóa kênh/nguồn đưa ra các phương pháp sửa đổi hay hơn khác. Điều này cũng đưa ra một số yêu cầu như các cơ chế tạo nhóm phải có hiệu cao (ví dụ khả năng giao một gói tin RTP đơn tới nhiều bộ truy nhập liên tiếp, khả năng đăng ký thông tin lớp đồng bộ của chúng) và thông tin mào đầu thấp cũng phải được tính đến.

6  Sử dụng các thuộc tính của giao thức mô tả phiên truyền (SDP)

Tiêu chuẩn này chỉ xem xét đến các hệ thống mã hóa theo chuẩn ISO/IEC 14496 có liên quan đã phát hành. Việc sử dụng thông tin SDP cho định dạng trường tải tin cụ thể phải được quy định trong mỗi định dạng trường tải tin RTP theo các khuyến nghị RFC. Việc sử dụng của các dòng dữ liệu cơ sở trong mỗi ngữ cảnh khác không được quy định trong tiêu chuẩn mà được quy định trong các tài liệu khác.

Tiêu chuẩn này giả thiết bất kỳ phiên truyền được mô tả bởi SDP (như trong SAP, một tệp tin được tải xuống, hoặc một câu lệnh DESCRIBE trên RTSP) có tại nhiều nhất một phiên truyền chuẩn ISO/IEC 14496. Điều này giúp loại bỏ được những hạn chế.

• Các bên gửi phải thông báo cho các bên nhận một phiên truyền mã hóa theo chuẩn ISO/IEC 14496, bằng một thuộc tính SDP (trước khi bất kỳ các đường “media” nào được gửi). Điều này thể hiện hình dạng của đường thuộc tính bởi câu lệnh sau:

A =mpeg4-iod[<location>]

Location (vị trí): Trong phiên truyền RTSP, đây là một thuộc tính tùy chọn. Nếu không được chọn, giá trị trường mô tả đối tượng khởi tạo (IOD: InitialObjectDescriptor) được lấy trên phiên RTSP bằng việc sử dụng câu lệnh DESCRIBE với việc chấp nhận loại application/mpeg4-iod hay application/mpeg4-iod-xmt. Thông tin trường SDP được cung cấp bởi một số phương tiện khác (như mở một tệp tin, trong SAP), giá trị location là bắt buộc phải có. Location là một liên kết URL được đính kèm trong hai dấu ngoặc kép, mà cung cấp IOD (như những IOD nhỏ có thể được mã hóa bằng việc sử dụng “data:”, hoặc “http:”, hay các URL truy cập tệp tin phù hợp khác). Khi định dạng application/mpeg4-iod-xmt được sử dụng, IOD trong định dạng XMT phải được cung cấp. Trường InitialObjectDescriptor được quy định trong điều con 8.6.3.1 của ISO/IEC 14496-1:2001 và định dạng XMT của nó được quy định trong điều con 15.8.3 của ISO/IEC 14496-1:2001 AMD2. Bất kỳ thiết bị đầu cuối đang sử dụng IOD phải hiểu IOD nhị phân và hiểu ngữ cảnh IOD.

• Các tên mã hóa mới của thông số a = rtpmap

A = rtpmap:<payload> < name>/<time scale>/<parametters>

...

...

...

• Điều này yêu cầu bất kể định dạng trường tải tin nào được sử dụng, mỗi dòng dữ liệu truyền thông đều chạy được trong hệ thống truyền thông miễn là phù hợp. Ví dụ, một định dạng trường tải tin có thể truyền tải cả dòng dữ liệu video và audio được sử dụng trong cả 2 khởi chạy với “m=video” và SDP với “m=audio”. Tên MIME với định dạng trường tải tin cũng được đăng ký như vậy với tất cả các nhánh ứng dụng.

Đối với trường hợp một dòng dữ liệu cơ sở, các thuộc tính được quy định bởi câu lệnh:

a=mpeg4-esid : a

a là nhận dạng dòng dữ liệu cơ sở (ESID).

• Các thông số SDP khác nếu được sử dụng, phải truyền tải các giá trị phù hợp với các hệ thống mã hóa theo chuẩn ISO/IEC 14496 (ví dụ như, tốc độ bít).

7  Loại Đặc tả mở rộng thư điện tử Internet đa mục đích (MIME)

7.1  Loại MIME mức đỉnh

• “video” phải được sử dụng cho các dòng dữ liệu hình ảnh MPEG-4 (như video được quy định trong ISO/IEC 14496-2 (Streamtype = 4) và/hoặc các đồ họa được quy định trong ISO/IEC 14496-1 (Streamtype = 3)) hay các dòng dữ liệu của các hệ thống MPEG-4 mà truyền đạt thông tin cần thiết cho việc thể hiện âm thanh/hình ảnh.

• “audio” phải được sử dụng cho các dòng dữ liệu âm thanh MPEG-4 (ISO/IEC 14496-3) (Streamtype = 5) hay các dòng dữ liệu của hệ thống MPEG-4 truyền đạt thông tin cần thiết cho việc thể hiện tín hiệu thuần âm thanh.

...

...

...

7.2  Loại MIME cho các dòng dữ liệu cơ sở

• Khi một dòng cơ sở hình ảnh mã hóa theo chuẩn ISO/IEC 14496 được thực hiện (như trên HTTP) hoặc ngược lại phải được xác định bởi một loại MIME, loại “video/mp4” phải được sử dụng. Loại MIME này yêu cầu các thông số tùy chọn thêm cho việc truyền tải tất cả các thông tin cần thiết để cấu hình cho bộ thu nhận: vì vậy không có thêm thông tin bổ trợ (như được quy định bằng định dạng tệp tin MP4 hay bằng chương trình khung trường mô tả đối tượng mã hóa theo chuẩn ISO/IEC 14496) được cung cấp trong dữ liệu, và chính dữ liệu tự thể hiện nội dung truyền thông. Định dạng của dòng bít, bao gồm cả việc định thời ..., được quy định trong ISO/IEC 14496-2.

• Các tên trường tải tin được sử dụng trong một hàm thuộc tính RTPMAP của giao thức SDP, chỉ định việc ánh xạ của tên trường tải tin để xác định thuộc tính của nó, và cũng ánh xạ đến vùng không gian tên của MIME. Mỗi ánh xạ trường tải tin RTP được quy định ở trên có một tên riêng biệt. Điều này yêu cầu các dòng dữ liệu hình ảnh phải được xác định dưới dạng “video”, và các dòng dữ liệu âm thanh được xác định dưới dạng “audio”, và các dòng dữ liệu còn lại xác định dưới dạng “application” được sử dụng.

• Trong một số trường hợp, trường mô tả đối tượng khởi tạo cần được xác định với một loại MIME phù hợp. Trong trường hợp này, loại “applications/mpeg4-iod” phải được hỗ trợ, và loại “application/mpeg4-iod-xtm” cũng có thể được hỗ trợ. Trong các trường hợp sau, IOD phải được mô tả trong một định dạng ngữ cảnh XMT. Trường mô tả đối tượng khởi tạo được quy định trong điều con 8.6.3.1 của ISO/IEC 14496-1, và định dạng XMT của nó được quy định trong điều con 15.8.3 của ISO/IEC 14496-1:2001 - Bản sửa đổi 2.

7.3  Loại MIME cho tệp tin MP4

Khi một tệp tin MP4 được thực hiện (như trên HTTP) hay ngược lại phải được nhận dạng bởi một loại MIME, loại “video/mp4” phải được sử dụng. Các loại “audio/mp4” cũng có thể được sử dụng khi có chứa thông tin trình bày theo chuẩn ISO/IEC 14496 trong tệp tin MP4 mà không có thể hiện thông tin hình ảnh và chỉ có thuần thông tin âm thanh.

7.4  Loại MIME cho thông tin đăng ký

• Tên loại nội dung truyền thông MIME: video, và âm thanh.

• Tên loại phụ (subtype) MIME: mp4.

...

...

...

• Tên loại con MIME: mpeg4-iod.

• Các thông số yêu cầu: không.

• Các thông số tùy chọn: không.

• Xem xét việc mã hóa: thông thường là loại base64; các tệp tin nhị phân và phải được truyền không có sự chuyển đổi CR/LF, và dải 7 bit...

• Xem xét tính an toàn: xem ở bên dưới.

• Xem xét tính tương tác: Một số những thực hiện bổ sung hiện có trong bộ tiêu chuẩn mã hóa theo chuẩn MPEG-4; và bộ tiêu chuẩn có tham chiếu phần mềm cho việc đọc và việc ghi định dạng tệp tin.

• Tiêu chuẩn kỹ thuật đã công bố: ISO/IEC 14496-1:2001.

• Các ứng dụng: Đa phương tiện.

• Thông tin khác:

...

...

...

o Các file mở rộng: mp4 và mpg4 được khai báo cả hai tại http://pitch.nist.gov/nics/.

o Các mã loại tệp tin Macintosh: mpg4 được đăng ký với Apple.

o Thông tin người liên hệ: David Singer, singer@apple.com.

o Sử dụng thông dụng: chung chung.

o Người tác giả/sửa đổi: David Singer, chủ định dạng tệp tin ISO/IEC 14496.

8  Sử dụng Giao thức dòng dữ liệu thời gian thực (RTSP)

Phần này chỉ xem xét những vấn đề liên quan tới các hệ thống mã hóa theo chuẩn ISO/IEC 14496. Việc sử dụng của các dòng dữ liệu âm thanh hay hình ảnh cơ sở trong nội dung khác không yêu cầu bất kỳ các thuộc tính kỹ thuật về RTSP. RTSP có thể được sử dụng như là một giao thức điều khiển phiên truyền cho các phiên truyền tải thông tin mã hóa theo chuẩn ISO/IEC 14496. Khi RTSP được sử dụng như là một giao thức điều khiển phiên truyền:

• RTP được sử dụng như là giao thức truyền tải.

• Việc khởi tạo định dạng câu lệnh DESCRIBE là SDP. Nếu thông tin SDP cho thấy có một IOD là cần thiết, và thiết bị đầu cuối không có sẵn, thì câu lệnh DESCRIBE thứ hai chấp nhận một IOD được hoạt động.

...

...

...

9  Sử dụng URL trong trường mô tả dòng dữ liệu cơ sở

Khi cần thiết để tham chiếu dòng dữ liệu RTP trực tiếp từ một trường mô tả dòng dữ liệu cơ sở, trường URL của trường mô tả có thể được sử dụng. Ví dụ, URL chứa thông tin mô tả SDP của dòng dữ liệu sử dụng lược đồ “data:application/sdp”.

Khi cần thiết để đưa\nhúng dòng dữ liệu trực tiếp vào bên trong trường mô tả dòng dữ liệu cơ sở, trường URL của bộ mô tả có thể được sử dụng. Ví dụ, URL có thể chứa dữ liệu sử dụng đúng loại MIME. Trong trường hợp này, dữ liệu bao gồm một gói tin lớp đồng bộ mà chứa thông tin của một bộ truy nhập.

10  Xem xét tính an toàn thông tin

Các gói tin RTP sử dụng phần định dạng trường tải tin là đối tượng cần xem xét về an toàn bảo mật theo chuẩn giao thức RTP. Điều này có nghĩa là các luồng dữ liệu trước khi truyền tải phải được thêm vào việc mã hóa an toàn. Do việc nén dữ liệu đối với phần định dạng trường tải tin được áp dụng theo phương pháp toàn trình đầu cuối tới đầu cuối (end to end), nên quá trình mã hóa có thể được thực hiện trên phần dữ liệu đã nén sao cho không xảy ra sự xung đột giữa hai quá trình này. Sự phức tạp của quá trình xử lý gói tin đối với định dạng trường tải tin gần như không thể hiện ra bất kỳ sự thay đổi nào ở tại đầu thu mà có thể dẫn tới nguy cơ từ chối sử dụng dịch vụ (DoS). Tuy nhiên, quá trình này có thể chỉ chèn thêm các luồng MPEG phi chuẩn (âm thanh, hình ảnh và các hệ thống) gây quá tải cho bộ đệm tài đầu thu, từ đó gây lỗi các chức năng của đầu thu hoặc thậm chí làm hỏng đầu thu...

Điều đặc biệt đúng cho các hệ thống đầu cuối tới đầu cuối như MPEG nơi mà các mô hình bộ đệm được quy định rất chính xác. Các hệ thống mã hóa theo chuẩn ISO/IEC 14496 hỗ trợ các loại dòng dữ liệu bao gồm các câu lệnh mà được thực thi trên thiết bị đầu cuối giống như các câu lệnh mô tả đối tượng, các câu lệnh BIFS (định dạng nhị phân cho cảnh hình) ... và các nội dung theo chương trình giống MPEG-J (Java™ mã byte) và ECMASCRIPT. Với những điều ở trên có thể dẫn tới gây hỏng hay tạm thời làm bộ nhận không được nhận thấy thông tin đủ để nhận biết. Các cơ chế nhận thực có thể được sử dụng để xác nhận tính hợp lệ của bên gửi và ngày gửi để ngăn chặn các vấn đề về an toàn tùy thuộc vào việc không tuân thủ các dòng dữ liệu ISO/IEC 14496 khi có thông tin phá hoại. Mô hình an toàn thông tin được quy định trong các dòng dữ liệu của hệ thống mã hóa theo chuẩn ISO/IEC 14496 truyền tải các thành phần truy nhập MPEG-J bao gồm các lớp ngôn ngữ Java™ và các đối tượng. MPEG-J quy định một bộ các giao diện lập trình ứng dụng JAVA và mô hình thực thi an toàn. Nội dung MPEG-J có thể gọi đến bộ giao diện các ứng dụng và các phương thức JAVA(TM) từ một bộ các gói phần mềm Java được hỗ trợ trong bộ nhận mà trong đó đã xác định mô hình an toàn thông tin. Theo mô hình an toàn này, việc tải mã byte bị cấm đối tải các thư viện nguồn tin, và xác định các phương thức nguyên bản, các chương trình khởi tạo, cách đọc hay viết các tệp tin, hay đọc các đặc tính hệ thống. Các bộ nhận có thể thực hiện thêm các bộ lọc thông minh để yêu cầu xác nhận bộ đệm hay tham số (OD, BIFS...) hay các câu lệnh chương trình (MPEG-J, ECMAScript) trong các dòng dữ liệu. Tuy nhiên, điều này sẽ làm gia tăng tính phức tạp cao trong việc xử lý thông tin.

11  Xem xét sử dụng truyền đa điểm (Multicast)

Khi sử dụng IP đa điểm, thông tin SDP mô tả phiên truyền mã hóa theo chuẩn ISO/IEC 14496 cần sẵn sàng cung cấp tới thiết bị đầu cuối. Hơn nữa, các trường mô tả dòng dữ liệu cơ sở có thể sử dụng các URL để trỏ trực tiếp tới địa chỉ của các dòng dữ liệu cơ sở. Mục tiêu của các URL là phải truyền đạt được thông tin để kích hoạt thiết bị đầu cuối kết nối trực tiếp tới kênh RTP đang truyền tải dòng dữ liệu cơ sở. URL có thể chứa đựng thông tin SDP đã được yêu cầu để truy nhập vào dòng dữ liệu như được mô tả tại Điều 9 ở trên.

...

...

...

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ và định nghĩa

4  Chữ viết tắt

5  Sử dụng giao thức truyền tải thời gian thực (RTP)

5.1  Tổng quan

5.2  Truyền tải một dòng dữ liệu cơ sở

5.3  Lựa chọn định dạng trường tải tin

5.4  Xem xét chất lượng dịch vụ mã hóa theo chuẩn ISO/IEC 14496

...

...

...

7  Loại Đặc tả mở rộng thư điện tử Internet đa mục đích (MIME)

7.1  Loại MIME mức đỉnh

7.2  Loại MIME cho các dòng dữ liệu cơ sở

7.3  Loại MIME cho tệp tin MP4

7.4  Loại MIME cho thông tin đăng ký

8  Sử dụng Giao thức dòng dữ liệu thời gian thực (RTSP)

9  Sử dụng URL trong trường mô tả dòng dữ liệu cơ sở

10  Xem xét tính an toàn thông tin

11  Xem xét sử dụng truyền đa điểm (Multicast)

Tiêu chuẩn quốc gia TCVN 11795-8:2017 (ISO/IEC 14496-8:2004) về Công nghệ thông tin - Mã hóa đối tượng hình ảnh âm thanh - Phần 8: Truyền tải nội dung mã hóa theo chuẩn ISO/IEC 14496 trên mạng IP