Đề tài sử dụng phần mềm hệ thống truyền hình ảnh kỹthuật số (digital video transport system – DVTS)

Một giải pháp đơn giản và hiệu quả hơn được sử dụng phổ biến hiện nay ở nhiều Mạng Nghiên cứu và Đào tạo Quốc gia NREN ở các nước khác như: Hàn Quốc, Nhật Bản, Thái Lan, Trung Quốc, Đài

Sự xuất hiện và phát triển của internet tới ngày này đã làm thay đổi hoàn toàn thế giới bởi những đóng góp to lớn của nó Với những ngày đầu nó chỉ phục

vụ cho mục đích quốc phòng của Mỹ vào cuối năm 1960 có tên là ARPANET, qua những năm phát triển sau đó internet được lan rộng và phục vụ cho mục đích dân

sự Với khả năng kết nối mở, Internet đã trở thành một mạng lớn nhất trên thế giới, mạng của các mạng, chúng giao tiếp với nhau qua giao thức

Bởi chính tiện ích internet mang lại, do đó nhiều doanh nghiệp muốn triển khai định hướng kinh doanh trên internet để cung cấp các sản phẩm, dịch vụ cần thiết cho người dùng Bên cạnh đó một số trường đại học, viện nghiên cứu, cũng cho ra đời nhiều ứng dụng giúp ích cho con người thuận tiện trong việc trao đổi thông tin từ xa

Hội nghị truyền hình trực tiếp là một ứng dụng cụ thể cho thành tựu nghiên cứu của trường đại học Keio, Nhật Bản chạy trên môi trường mạng khắc phục khó khăn về mặt địa lí cũng như tiết kiệm thời gian và chi phí Với kỹ thuật mới, ứng dụng giúp trao đổi giữa hai đầu truyền hình đạt chất lượng cao Tại các bệnh viện, hội chẩn đoán bệnh từ xa nhận ý kiến, thảo luận từ những bác sĩ giỏi trên thế giới qua cầu truyền hình, đưa ra phương pháp tối ưu nhất cho việc điều trị Hội nghị này tạo điều kiện cho nhiều đơn vị, tổ chức, bệnh viên trao đổi kinh nghiệm, thắt chặt mối liên kết toàn cầu cùng nghiên cứu đưa ra giải pháp trong y khoa Ngoài

ra phục vụ cho các chương trình học từ xa và nhiều ứng dụng hơn nữa

Do sự phát triển ngày càng mạnh mẽ của khoa học và công nghệ tạo ra nhiều ứng dụng trong thực tiễn, chính vì vậy mô hình này cần chú trọng, nghiên cứu và phát triển lan rộng hơn nữa trong tương lai

Chương 1: Tổng quan về hệ thống DVTS

1.1 Hội nghi truyền hình(video conferencing)

Để có cuộc hội nghị, hội thảo, diễn đàn từ xa thì một trong những điều kiện không thể thiếu đó là cần phải có sự hỗ trợ của các phương tiện, thiết bị và công nghệ

Sử dụng các thiết bị chuyên dụng dành cho Hội nghị truyền hình (Video Conferencing) là một trong những giải pháp hữu hiệu Tuy nhiên, thiết bị dành cho hội nghị truyền hình có giá thành cao, không phải đơn vị nào cũng có thể tự mua sắm riêng một bộ, số điểm truy cập từ xa cũng bị hạn chế, việc cài đặt, sử dụng phần mềm điều khiển cần được đào tạo hướng dẫn một thời gian khá dài trước khi

có thể sử dụng thành thạo các thiết bị chuyên dụng đó

Một giải pháp đơn giản và hiệu quả hơn được sử dụng phổ biến hiện nay ở nhiều Mạng Nghiên cứu và Đào tạo Quốc gia (NREN) ở các nước khác như: Hàn Quốc, Nhật Bản, Thái Lan, Trung Quốc, Đài Loan, Indonesia, Malaysia, Philippine,

Úc, Tây Ban Nha…đó chính là sử dụng phần mềm Hệ thống truyền hình ảnh kỹ thuật số (Digital Video Transport System – DVTS) :

Hệ thống đơn giản

Kinh phí thấp

Dễ sử dụng ( không cần đào tạo nhân lực)

1.2 Digital Video Transport System

1.2.1 Khái niệm

Digital Video Transport System viết tắt DVTS là một phần mềm ứng dụng chạy trên đường truyền mạng máy tính 30Mbps không nén video để gửi và nhận hình ảnh, âm thanh chất lượng cao với độ trễ thấp DVTS có thể chạy trên hệ điều hành khác nhau và hệ thống phân phối hình ảnh chất lượng bằng việc kết nối DVTS với máy tính cá nhân thông qua cổng giao tiếp IEEE1394

Hình 1.1: Minh họa phần mềm DVTS

Qua quá trình nghiên cứu triển khai và ứng dụng thực tiễn khi tham gia vào các diễn đàn do CanalAVIST , trường Đại học Kyushu Nhật Bản tổ chức, có thể thấy một số ưu điểm của việc sử dụng DVTS đó là:

- Cài đặt phần mềm đơn giản, không mất nhiều thời gian, có thể tải phần mềm

về Internet;

- Giao diện đơn giản, dễ thao tác và sử dụng;

- Các đơn vị thành viên, cá nhân có thể tham gia diễn đàn, hội nghị, hội thảo

từ xa, đào tạo từ xa

- Hình ảnh được gửi đi và nhận đến có chất lượng cao…

- Âm thanh phải sử dụng âm li điều chỉnh âm thanh mới chất lượng tốt…

- Phần mền không tự lưu trữ, việc lưu trữ phụ thuộc máy quay video

- Không tích hợp truyền text(chat)

- Có một khung hình nhận video

1.2.2 Khả dụng của DVTS mang lại

1.2.2.1 Kết nối toàn cầu

Thông qua đường truyền cáp quang băng thông rộng đã liên kết nhiều quốc gia và DVTS là cầu nối cho các chuyên gia cùng nhau chia sẽ thuộc nhiều phạm vi

Hình 1.2 : mô hình mạng nghiên cứu thế giới

• Nghiên cứu bệnh học tại Đại học Pennsylvania hệ thống y tế đang thử nghiệm với DVTS cho telemicroscopy

• DVTS cũng được sử dụng cho các sự kiện văn hóa khoa học, chẳng hạn

như nở hoa arum Titan

1.2.2.3 Ứng dụng mạng nghiên cứu và đào tạo VinaREN

VinaREN là mạng Nghiên cứu và Đào tạo[7] Việt Nam hoạt động tháng 3-2008, mang lại nhiều lợi ích trong hoạt động nghiên cứu và đào tạo cho các đơn

vị thành viên tham gia kết nối và sử dụng hệ thống DVTS Một trong những lợi ích thiết thực và đem lại hiệu quả cao cho các thành viên đó chính là việc tổ chức tham gia vào các diễn đàn, hội nghị, hội thảo từ xa qua mạng VinaREN[2], mạng TEIN Khi tổ chức tham gia các sự kiện, các kỹ sư công nghệ thông tin, các giáo

sư, bác sĩ đến từ các trường đại học, bệnh viện trong nước như: Đại học Bách Khoa

Hà Nội, Đại học Thuỷ lợi, Đại học Y Hà Nội, Đại học Huế, Bệnh viện Trung ương Quân đội 108, Học viện Quân y, Bệnh viện Bạch Mai, Bệnh viện Nhi Trung ương, Bệnh viện Việt Đức,….đã có điều kiện được phổ biến thêm những kiến thức, kỹ thuật chuyên môn mới

Thông qua việc truyền nhận hình ảnh qua DVTS, các giáo sư, bác sĩ của các bệnh viện đã có điều kiện tham gia các cuộc phẫu thuật nội soi được thực hiện trực tiếp tại các phòng mổ của các bệnh viện ở nước ngoài như: Prince of Wales Hospital, Hong Kong Mạng VinaREN phối hợp với Bệnh viện 108 tổ chức tham gia sự kiện “International GI Endoscopy Live Demonstration” diễn ra tại Bangkok, Thailan Tại sự kiện này, các bác sĩ của Việt Nam tiếp tục có dịp tham gia vào những ca mổ được thực hiện trực tiếp tại các phòng mổ của các bệnh viện

Ngoài ra mạng VinaREN và một số đơn vị thành viên đã cùng phối hợp

tổ chức thành công khi tham gia các diễn đàn, hội nghị, hội thảo từ xa với các tổ chức, các mạng nghiên cứu và đào tạo nước ngoài như:

Về E-Learning:

- Diễn đàn CanalAVIST – ICT Forum, ngày 31/7 và 1/8/2008 Các nước tham gia: Việt Nam, Úc, Nhật Bản, Xingapo, Thái Lan (http://www.canalavist.org/ict-forum)

- Diễn đàn Asian School on Computer Science, ngày 16 và 17/11/2008 Các nước tham gia: Thái Lan, Việt Nam, Phillipin, Xingapo.(

http://www.interlab.ait.ac.th/ascs/)

Về Telemedicine:

- Diễn đàn Medical, ngày 11 và 19/9/2008 Các nước tham gia:Việt Nam, Inđônêxia, Nhật Bản, Hàn Quốc, Malaixia, Thái Lan, Xingapo (http://www.canalavist.org/med-forum)

- Hội thảo “23rd International WorkshoponTherapeutic Endoscopy” (với phần

trình diễn “Live Demonstration of Endoscopy”, tổ chức ngày 9/12/2008 Các nước

tham gia: Nhật Bản, Hồng Kông, Thái Lan, Đài Loan, Việt Nam

- Hội thảo chuyên đề “Tele-lecture of Laparoscopic Colo-Rectal Surgery” tại

Hội nghi APAN lần thứ 27 (www.apan.net )

1.3 Xây dựng mục tiêu

Thực hiện hội nghị truyền hình(video conferencing) thì một trong những điều kiện không thể thiếu đó là cần phải có sự hỗ trợ của các phương tiện, thiết bị và công nghệ Sử dụng những thiết bị chuyên dụng này là một trong những giải pháp tốt Xong bên cạnh đó không phải đơn vị nào cũng trang bị cho riêng một bộ

Từ những khó khăn trang thiết bị nêu trên, đã đưa ra giải pháp xây dựng ra hệ thống Digital Video Transport System(DVTS) có thể truyền hình ảnh, âm thanh chất lượng cao với các mục tiêu chính như sau:

- Chạy trên mạng internet:

- kết nối từ camera: IEEE 1394, USB 2.0 camera

- kết nối sound on board

- Truyền text(chat)

- Lưu trữ video

- Xem lại video

Để thực hiện những mục tiêu đề ra ta cần tới một ứng dụng máy chủ RED5 đây

là một máy chủ mã nguồn mở viết bẳng ngôn ngữ java đóng vai trò làm trung gian thực hiện công việc trung chuyển hình ảnh, âm thanh Trên máy chủ Red5 này ta tạo ra gói AppServer phản hồi các kết nối từ client, lưu trữ video và sreaming video Ngoài ra tạo một ứng dụng Client có tên LHDVTS viết bằng ngôn ngữ Mxml + ActionScript thực hiện công việc chính truyền, hiển thị hình ảnh, âm thanh nhận từ server, chat và xem lại video

Nghiên cứu các chuẩn nén :

™ Chuẩn nén âm thanh High Efficiency AAC(HE-AAC)

Hình 1.3: mô hình tích hợp chuẩn nén HE-AAC

™ Chuẩn nén hình ảnh Moving Picture Experts

Group/H264(MPEG-4/H264)

Hình 1.4: mô hình chia nhỏ hình ảnh cosine trong MPEG-4/H264

™ Giao thức truyền thời gian thực RTMP(Real Time Messaging protocol)

- RTMP chạy trên TCP với port 1935

- RTMP chạy đường hầm trên kết nối HTTP port 80

- RTMPS là RTMPT kết nối bảo mật sử dụng cho HTTPS

RTMP ở chế độ tiêu chuẩn

RTMP ở chế độ đường hầm

Hình 1.5: gói tin rtmp được cắt nhỏ trong các dạng đường truyền

Chương 2

Mô hình hệ thống và máy chủ Red5

2.1 Mô hình hệ thống

2.1.1 Mô hình Peer to Peer

Hình 2 1: Mô hình Peer to Peer trong DVTS

Mô hình Peer to Peer được sử dụng bởi một số phần mềm cung cấp dịch vụ video như Skype, DVTS, … Có nhiều giải pháp cho mô hình Peer to Peer, trong đó DTVS là một hệ thống cho phép chuyển phát hình ảnh, âm thanh giữa các nơi sử dụng mô hình này bằng địa chỉ IP Multicast (như trong hình)

Ưu điểm chủ yếu của mô hình này là khả năng tận dụng các máy đầu cuối Tuy nhiên nhược điểm của nó là không thể quản lý được người dùng nếu ở mô hình Peer to Peer truyền thống Do đó việc áp dụng rộng rãi mô hình này gặp nhiều khó khăn cho những tổ chức nhỏ

2.1.2 Mô hình Client – Server

Hình 2.2: Mô hình Client – Server

Mô hình Client – Server là một mô hình thông dụng được sử dụng bởi các nhà cung cấp dịch vụ video nổi tiếng như Yahoo, Youtube,…

• Mô hình này có nhiều ưu điểm:

- Khả năng đáp ứng nhanh: người dùng có thể kết nối đến server dễ nhành để nhận được sự cung cấp dịch vụ

- Dễ dàng cho việc thi công và cung cấp dịch vụ: nhà cung cấp dịch vụ chỉ cần thiết kế server quản lý và cung cấp dịch vụ của mình Sau đó để đưa tới tay người

sử dụng thì chỉ cần sử dụng thêm tên miền hoặc địa chỉ IP là có thể sẫn sàng đáp ứng dịch vụ cho người dùng

- Dễ dàng quản lý truy cập của người dùng

• Nhược điểm chủ yếu của mô hình này là :

- Dễ dàng bị quá tải do số người truy cập tăng

Tuy nhiên có thể giải quyết vấn đề này bằng cách tuỳ thuộc vào khả năng của máy làm server, người quản trị hoặc người thiết kế dịch vụ cần giới hạn khả năng đáp

ứng của dịch vụ Hoặc xây dựng các giải pháp về mạng khác để tăng khả năng đáp ứng cho server tránh bị quá tải khi yêu cầu tăng Với các nhận định trên, trong quá trình phát triển server chuyển phát âm thanh và hình ảnh, em đã sử dụng mô hình Client – Server

2.1.3 Kiến trúc Server

Kiến trúc của server được thiết kế như hình sau:

Hình 2.3: Kiến trúc của Server

Server hoạt động dựa trên nền tảng giao thức RTMP đóng vai trò như một framework Các ứng dụng (Application) hoạt động trên Server trong suốt với giao thức, server đảm nhiệm công việc làm trong suốt này và giúp cho ứng dúng chạy trên Server liên lạc được với các Client tham gia vào ứng dụng này

Trong một ứng dụng được chia làm nhiều phòng (Room) Trong mỗi phòng

có nhiều người dùng (User) Mỗi người dùng này thực chất là một Client đang hoạt động kết nối tới Server với một ứng dụng được cung cấp nào đó của Server

Cũng theo mô hình kiến trúc mỗi Client còn có nhiều kênh (Channel) Các kênh này giúp cho người dùng có thể nhận cùng lúc nhiều loại dữ liệu khác nhau mà không cần phải tạo nhiều kết nối tới Server

Hình minh hoạ trên chỉ ra một Server cung cấp các ứng dụng cho phép các người dùng chia sẻ video, nhạc và một ứng dụng cho phép các bác sĩ tạo và tham gia vào các cuộc hội chẩn từ xa Mỗi phòng có nhiệm vụ giống như một cuộc hội chẩn Còn các kênh giúp cho các bác sĩ vừa có thể xem các đoạn video về ca phẫu thuật đang tiến hành, vừa có thể nói chuyện bàn bạc được với nhau Đồng thời các bác sĩ cũng có thể xem thông tin bệnh nhân và các hình ảnh liên quan tới bệnh nhân này

2.2 Máy chủ Red5

Red5 là một máy chủ mã nguồn mở Flash Server viết bằng ngôn ngữ Java Hệ thống Server được xây dựng đã hỗ trợ sẵn các dịch vụ về hình ảnh, âm thanh Server sử dụng chuẩn nén Video H.264 và Audio HE-AAC Chuẩn nén H.264 có tỉ

số nén cao nhưng vẫn không làm giảm nhiều chất lượng Video Người ta tính toán

ra được đối với chuẩn nén H.264 khi Video có độ phân giải 700x525 và tốc độ frame là 30 frame/sec thì băng thông yêu cầu nhỏ hơn 1.5 Mbps Với băng thông yêu cầu chỉ khoảng 1.5 Mbps thì hệ thống Server đang được xây dựng có thể hoạt động trên những đường truyền Internet tốc độ trung bình

Nếu so sánh hệ thống đang được xây dựng với các giải pháp phần cứng thì hệ thống đang được xây dựng sẽ có chi phí thấp hơn đáng kể do không cần sử dụng các thiết bị chuyên dụng, không cần phải sử dụng kênh thuê riêng nhưng về chất lượng truyền dẫn thì không đảm bảo bằng vì trên các đường truyền Internet thông thường

có thể xảy ra tắc nghẽn Ngoài ra do sử dụng Web và Flash nên hệ thống đang được xây dựng có tính khả chuyển và mềm dẻo chứ không bị cố định tại một vài địa điểm

như các hệ thống phần cứng Việc thêm một địa điểm tham gia vào ứng dụng chỉ cần một máy tính có gắn camera và phone là đủ mà không cần phải đầu tư thêm thiết bị đắt tiền như các hệ thống dựa trên phần cứng

Dưới đây là những hỗ trợ của máy chủ Red5 :

• Streaming Video (FLV, F4V, MP4, 3GP)

• Streaming Audio (MP3, F4A, M4A, AAC)

• Recording Client Streams (FLV and AVC+AAC in FLV container)

Chương 3 Giao thức truyền và các chuẩn nén

3.1 Giao thức truyền tải dữ liệu thời gian thực

3.1.1 Giới thiệu

Mạng Internet vốn được xây dựng để truyền dữ liệu, và các giao thức truyền tải lớp Transport như TCP (Transmission Control Protocol) hay UDP (User Datagram Protocol) chỉ có khả năng truyền dữ liệu từ đầu cuối đến đầu cuối mà không có bất kì cơ chế nào để đảm bảo gói dữ liệu được truyền đến đích trong một thời gian xác định nghĩa là không đảm bảo vấn đề thời gian thực cho âm thanh, hình ảnh Khi truyền một gói dữ liệu trên mạng Internet có nhiều nguyên nhân khiến gói

dữ liệu đến đích không đúng thời gian (có thể đến sớm hoặc đến trễ) chẳng hạn như lưu lượng trên mạng tại thời điểm gửi quá lớn, cũng có thể gói dữ liệu phải đi qua một link có tốc độ thấp, một hoặc vài router bị quá tải… khiến cho gói dữ liệu đến trễ không theo một quy luật nào (jitter) Ngoài ra còn vấn đề mất gói dữ liệu khi Time-to-Live trong gói dữ liệu bị giảm xuống 0, các router drop các gói dữ liệu khi

bị quá tải…Tất cả các nguyên nhân trên khiến cho mạng Internet không thật thích hợp để truyền âm thanh,hình ảnh Tuy nhiên, người ta sử dụng cơ chế “Buffering” (vùng đệm Playback) ở phía nhận để giảm jitter khi truyền âm thanh, hình ảnh trên mạng Internet Cơ chế này như sau:

Hình 3.1: Vùng đệm dùng cho việc playback

Bên nhận khi nhận được dữ liệu thì không phát ra ngay mà lưu vào vùng đệm K Khi vùng đệm K đầy thì bên nhận bắt đầu phát hình ảnh và âm thanh (lấy

dữ liệu ra khỏi vùng đệm K với một tốc độ không đổi) Trong lúc phát âm thanh, hình ảnh thì nó tiếp tục nhận dữ liệu âm thanh, hình ảnh từ bên gửi bù đắp vào dữ liệu được lấy ra khỏi vùng đệm K để phát Nếu chỉ có trì hoãn nhỏ xảy ra thì vùng đệm K sẽ không bị cạn kiệt và đảm bảo triệt tiêu jitter, nếu có trì hoãn lớn hoặc mất

dữ liệu thì tới một lúc nào đó vùng đệm K sẽ bị cạn kiệt, khi đó bên nhận sẽ dừng phát âm thanh, hình ảnh và phải tiến hành thao tác trên lại từ đầu Có một vài điểm đáng lưu ý khi chọn kích thước của vùng đệm K Nếu chọn K lớn thì có thể giảm đáng kể jitter nhưng thời gian chờ đợi trước khi bắt đầu phát âm thanh, hình ảnh sẽ rất lâu Ngược lại nếu chọn K nhỏ thì thì thời gian chờ đợi trước khi bắt đầu phát

âm thanh, hình ảnh sẽ ngắn nhưng trong quá trình phát thường hay dừng để đệm lại

Vì RTP được thiết kế để truyền tải nhiều loại dữ liệu thời gian thực khác nhau, bao gồm cả âm thanh và video, nên RTP không bó buộc một cách diễn dịch ngữ nghĩa chung nhất Thay vì thế, mỗi packet bắt đầu với một phần đầu cố định; các vùng trong phần đầu này xác định cách diễn dịch các vùng còn lại Sau đây là định dạng phần đầu trong RTP

Kiểu payload cũng ảnh hưởng đến việc diễn dịch của vùng Timestamp Timestamp là một giá trị 32 bit để cho thời gian tại đó octet đầu tiên của dữ liệu số hóa được lấy mẫu, với timestamp ban đầu được chọn ngẫu nhiên Chuẩn xác định rằng timestamp được tăng liên tục, ngay cả trong những lúc không có tín hiệu hay không có giá trị được gửi đi, nhưng nó không xác định độ gia tăng chính xác Độ gia tăng được xác định bởi kiểu payload, nghĩa là mỗi ứng dụng có thể chọn một độ gia tăng, cho phép nơi nhận định vị được những mục trong dữ liệu xuất với mục chính xác thích hợp trong ứng dụng Ví dụ, nếu một dòng dữ liệu thoại được truyền

qua RTP, thì độ gia tăng timestamp (theo logic) một nhịp đồng hồ cho một mẫu là thích hợp Tuy nhiên, nếu dữ liệu video được truyền, thì độ gia tăng timestamp cần phải lớn hơn để cho việc playback được trung thực

3.1.2.2 Đóng gói RTP

Từ tên gọi của nó, RTP là giao thức mức chuyên chở Nếu nó đóng vai trò như giao thức chuyên chở thông thường, thì RTP sẽ yêu cầu mỗi thông điệp được đóng gói trực tiếp trong một IP datagram Thực ra, RTP không có chức năng là giao thức chuyên chở; mặc dù nó được phép, nhưng việc đóng gói trực tiếp trong IP không xảy ra trong thực tế Thay vì thế, RTP chạy trên UDP; có nghĩa là mỗi thông điệp RTP được đóng gói trong một UDP datagram Ưu điểm chính của việc sử dụng UDP là xử lí song song – một máy tính có thể có nhiều ứng dụng cùng sử dụng RTP

Hình 3.3: Minh họa đóng gói tiêu đề RTP

Không giống như nhiều giao thức ứng dụng khác, RTP không sử dụng một giá trị cổng UDP dành riêng Thay vì thế, một cổng được cấp phát để sử dụng cho mỗi giao dịch, và ứng dụng ở xa phải được thông báo về giá trị cổng này Theo qui ước, RTP chọn một cổng UDP có số chẵn

3.1.3 Giao thức RTMP (Real Time Messaging Protocol)

3.1.3.1 Giới thiệu

RTMP là giao thức được tạo ra bởi Macromedia (hiện nay là Adobe) dùng để truyền tải các đối tượng Flash và video trên các kết nối mạng Hiện tại chỉ có 2 máy chủ hỗ trợ giao thức này là Macromedia Media Sever, và server mã nguồn mở Red5

Đây là một giao thức đơn giản, được tối ưu cho các kết nối tốc độ thấp Nó có thể hỗ trợ tối đa 64 luồng dữ liệu trên cùng một kết nối Trong header của một AMF

có chứa chỉ số của luồng dữ liệu mà nó thuộc về Một message RTMP có thể chứa nhiều hơn một đối tượng AMF

Server khi nhận được gói dữ liệu sẽ lưu lại khối dữ liệu 1536 byte này, và cũng gởi 1 byte giá trị 0x03 theo sau bởi hai khối 1536 byte Khối thứ hai chính là nội dung đã được gửi lên bởi client trước đó

Client nhận hai khối dữ liệu 1536 byte từ server, so sánh với khối dữ liệu ban đầu nó gửi lên server, nếu phù hợp thì kết nối được thiết lập, nó cũng gửi trả khối

dữ liệu này về lại cho server

Hình 3.6: Quá trình bắt tay giữa Client và Server trong giao thức RTMP

Sau thao tác bắt tay Client tiếp tục gửi ba đối tượng AMF lên server để khởi động truyền dữ liệu Đối tượng đầu tiên là đối tượng connect nhằm thông báo client

đã sẵn sàng cho quá trình truyền thông Đối tượng AMF thứ hai chính là đối tượng NetConnection từ client, lớp Action Script này được sử dụng tạo kết nối tới media server Đối tượng AMF thứ ba là đối tượng NetStream từ client dùng để xác định file cần stream từ server

• 0x03: tiêu đề 1 byte

Sáu bít còn lại biểu diễn chỉ số của đối tượng AMF Một khi đối tượng AMF

đã được nhận đầy đủ bởi client thì chỉ số này có thể được tái sử dụng

Hình 3.7: Tiêu đề RTMP 12 byte

Đối với tiêu đề 12 byte thì 3 byte tiếp theo là trường timestamp (little-endian),

3 byte tiếp theo nữa là chiều dài của đối tượng AMF (big-endian), byte kế tiếp quy định nội dung của đối tượng AMF (xem hình ?), 4 byte cuối cùng xác định source

id

Đối với tiêu đề 8 byte thì bỏ đi trường source id trong tiêu đề 12 byte

Đối với tiêu đề 4 byte thì bỏ đi trường length, content type trong tiêu đề 8 byte

Đối với tiêu đề 1 byte thì bỏ đi trường timestamp trong tiêu đề 4 byte nghĩa là

nó chỉ gồm byte đầu tiên chứa kiểu tiêu đề và chỉ số đối tượng AMF

Bảng 3.8: Một số giá trị trong trường Content Type

3.1.3.5 Truyền tải nhiều đối tượng AMF trên cùng một kết nối

Mỗi đối tượng AMF được chia thành các khối dữ liệu có kích thước 128 byte (ngoại trừ audio có kích thước 64 byte) Khối đầu tiên thường được gắn tiêu đề 12 byte, các khối tiếp theo thường được gắn tiêu đề 1 byte, trong bất kì loại tiêu đề nào cũng có chứa chỉ số của đối tượng AMF tương ứng

Hình 3.9: Các khối dữ liệu của một đối tượng AMF có chỉ số là 0x03

Để có thể truyền nhiều đối tượng AMF trên một kết nối đơn người ta không truyền các khối dữ liệu của một đối tượng AMF liên tiếp nhau mà truyền xen kẽ các khối dữ liệu của nhiều đối tượng AMF

Hình 3.10: Truyền các khối dữ liệu xen kẽ nhau

3.1.4 So sánh giữa RTP và RTMP

Hai giao thức RTP và RTMP rõ ràng không cung cấp cơ chế để chuyển phát đúng thời hạn, điều này phải được đảm bảo hệ thống cơ sở Chúng chỉ cung cấp cơ

chế timestamp để kiểm soát việc playback Trong RTP có sequence number để kiểm

tra trật tự các gói còn trong RTMP việc này được đảm bảo bởi TCP Cả hai cùng phải sử dụng cơ chế vùng đệm để giảm jitter

Có thể nói khả năng của hai giao thức này là tương đương nhau Việc chọn RTMP trong đề tài là do nó gắn liền với Flash Sở dĩ sử dụng Flash là vì tính đơn giản, khả chuyển và mềm dẻo của nó

3.2 Chuẩn mã hoá dữ liệu - AMF (Action Message Format)

AMF là một định dạng dùng ghép nối tiếp các dữ liệu được dùng để giao tiếp thông qua môi trường mạng AMF giúp mã hoá và định nghĩa các kiểu dữ liệu cần tương tác giữa hai hệ thống Thông qua AMF, các hệ thống đầu cuối sẽ hiểu được

dữ liệu được chuyền từ hệ thống khác là kiểu dữ liệu gì AMF được giới thiệu đầu tiên 2001 trong Flash Player 6 là AMF0 Sau này được phát triển thêm thành AMF

3 trong Flash Player 9 Tuy nhiên AMF0 vẫn còn được hỗ trợ để tương thích lùi

3.2.1 AMF0

3.2.1.1 Giới thiệu

Như đã giới thiệu ở trên AMF0[3] là phiên bản đầu tiên của AMF giúp ghép nối các đối tượng dữ liệu, chứa thông tin về kiểu của của dữ liệu AMF0 cũng hỗ trợ truyền các kiểu dữ liệu phức tạp bằng cách dùng tham chiếu để tránh dư thừa dữ liệu

3.2.1.2 Kiểu dữ liệu AMF0

Trong AMF0, các kiểu dữ liệu được đánh dấu bằng một 1 byte Theo sau đó

là dữ liệu theo đúng những gì đã được mô tả ở byte đánh dấu phía trước

Các kiểu dữ liệu của AMF0 được liệt kê ngay sau đây:

Kiểu số 0x00

Kiểu chuỗi 0x02 Kiểu đối tượng 0x03

Kiểu tham chiếu 0x07

Đánh dấu kết thúc đối tượng 0x09

Kiểu ngày tháng 0x0B

Kiểu lớp 0x10

Bảng 3.11: Kiểu dữ liệu trong AMF0

• Kiểu số được dùng để mã hoá một số ActionScript Dữ liệu theo sau một marker luôn luôn là 8 byte số dấu chấm động double IEEE-754

Kiểu_số = đánh_dấu DOUBLE

• Kiểu logic được dùng để mã hoá kiểu nguyên thuỷ logic của ActionScript Một byte đánh dấu là kiểu logic, theo sau đó là một byte chỉ giá trị của dữ liệu logic Giá trị này bằng 0 là false, bằng 1 là true

Kiểu_logic = đánh_dấu U8 (số nguyên không dấu 8 bit)

• Kiểu chuỗi được dùng để mã hoá bất kì một chuỗi nào có độ dài nhỏ hơn

65525 kí tự Nếu chuỗi nào dài hơn độ dài này thì sẽ chuỗi kiểu chuỗi dài

Kiểu_chuỗi = đánh_dấu UTF-8

• Kiểu đối tượng được dùng để mã hoá kiểu object của ActionScript Kiểu này tương đối phức tạp được ghép nối như sau:

Kiểu_đối_tượng = đánh_dấu (UTF-8 giá_trị)(UTF-8

giá_Trị)…(UTF-8 giá_Trị) UTF-giá_Trị)…(UTF-8_rỗng đánh_dấu_kết_thúc

• Kiểu null chỉ được biểu diễn bằng byte đánh dấu kiểu, và không có thông tin đính kèm theo sau

Kiểu_null = đánh_dấu

• Kiểu tham chiếu được dùng để chỉ lại dối tượng đã mã hoá phía trước mà không cần phải truyền lại, tránh dư thừa dữ liệu Kiểu dữ liệu tham chiếu sử dụng số nguyên 16 bit đề dùng như một chỉ mục và bắt đầu bằng 0

Kiểu_tham_chiếu = đánh dấu U16

• Kiểu mảng ECMA được xem như là một kiểu phức tạp của AMF0 Kiểu này

có thể được sử dụng kèm với kiểu tham chiếu cho dữ liệu của nó Sau byte

đánh dấu là một byte chỉ kích thước của mảng, và tiếp theo sau đó là dữ liệu của mảng

Kiểu_mảng_ECMA = đánh_dấu U32 U32*(8 gia_tri) 8_rỗng đánh_dấu_kết_thúc

UTF-• Kiểu mảng dày chứa dữ liệu cần truyền đi

Kiểu_mảng_dày = dánh dấu U32 U32*giá_tri

• Kiểu chuỗi dài được sử dụng trong AMF0 để mã hoá một chuỗi chiếm chiều dài nhiều 65535

Kiểu_chuỗi_dài = dánh_dấu UTF-8_dài

• Kiểu ngày tháng được dùng để mã hoá số lượng ms đã qua để từ ngày 1 tháng 1 năm 1970 giờ UTC

Múi_giớ = S16 (số nguyên có dấu 16 bit) Kiểu_ngày_tháng = đánh_dấu DOUBLE Múi_giờ

• Kiểu XML cũng được hỗ trợ trong AMF0 khi dùng để ghép nối dữ liệu trong chuỗi XML AMF0 coi Kiểu XML giống như những kiẻu chuỗi dài khác

Kiểu_XML = đánh_dấu UTF-8_dài

• Kiểu lớp là kiểu được dùng để ghép nối các dữ liệu trong một lớp lại thành một chuỗi gửi đi Kiểu lớp cũng có thể được sử dụng kèm với kiểu tham chiếu

Tên_lớp = UTF-8 Kiểu_lớp = đánh_dấu Tên_lớp (UTF-8 giá_trị) (UTF-8 giá_trị) … (UTF-8 giá_trị) UTF-8_rỗng đánh_dấu_kết_thúc

3.2.2 AMF3

3.2.2.1 Giới thiệu

AMF3 là một phiên bản mới của AMF, nhằm cải tiến những hạn chế của AMF0 Cải tiến của AMF3[4] là hạn chế lại việc truyền dư thừa dữ liệu và bổ sung thêm một số kiểu dữ liệu mới

3.2.2.2 Kiểu dữ liệu AMF3

Trong AMF3, mỗi kiểu dữ liệu cũng được bắt đầu bằng một byte chiều dài, tiếp theo là dữ liệu tương ứng với dữ liệu được mô tả ở byte đánh dấu Giá trị của byte đánh dấu có ý nghĩa như sau:

Kiểu undefined 0x00

Kiểu logic false 0x02 Kiểu logic true 0x03 Kiểu số nguyên 0x04 Kiểu số double 0x05 Kiểu chuỗi 0x06 Kiểu văn bản XML 0x07

Kiểu ngày tháng 0x08 Kiểu mảng 0x09 Kiểu đối tượng 0x0A

Kiểu mảng byte 0x0C

Hình 3.12: Kiểu dữ liệu của AMF3

• Kiểu undefined chỉ được biểu diễn bằng byte đánh dấu không có dữ liệu đi kèm theo sau

• Kiểu số nguyên được dùng để mã hoá số nguyên không dấu 29 bit theo cú pháp ABNF (Augmented Backus-Naur Form)

Kiểu_số_nguyên = đánh_dấu U29

• Kiểu double được dùng để mã hoá một số, Kiểu này cũng được dùng thay cho Kiểu số nguyên nếu số có giá trị lớn hơn 229 Kiểu này bao gồm một số dấu chấm động IEEE-754 theo sau một byte đánh dấu

Kiểu_double = đánh_dấu DOUBLE

• Kiểu chuỗi được dùng để biểu diễn một chuỗi trong AMF3 và dùng tương đương như chuỗi dài trong AMF0

Kiểu_chuỗi = đánh_dấu UTF-8-vr

• Kiểu văn bản XML được dùng để mã hoá Kiểu XMLDocument trong

ActionScript Chiều dài của một văn bản XML được giới hạn trong 256MB

Kiểu_văn_bản_XML = đánh_dấu UTF-8

• Kiểu ngày tháng có ý nghĩa giống như trong AMF0

Kiểu_ngày_tháng = đánh_dấu (U29_1 | U29_2 DOUBLE) U29_1 có bit đầu tiên là 0 chỉ kiểu ngày tháng tham chiếu, U29_2 có bit đấu tiên là 1 tiếp theo sau là một DOUBLE chỉ số lượng ms từ ngày 1 tháng 1 năm 1970 tới thời điểm hiện tại tính theo giờ UTC

• Kiểu mảng được sử dụng thay cho kiểu ECMA, mảng dày đặc của AMF0

Kiểu_mảng = đánh_dấu (U29_1 | U29_2 (Kiểu_ECMA | Kiểu_mảng_dày))

• Kiểu đối tượng được dùng để chất lượng đối với các kiểu Object của

ActionScript và kiểu lớp của người dùng

Kiểu_mảng = đánh_dấu (kiểu_đối_tượng | kiểu_lớp)

• Kiểu XML được dùng để mã hoá đối tượng XML của ActionScript có hỗ trợ

cú pháp E4X Nội dung của kiểu này được xử lý giống như một UTF-8

Kiểu_XML = đánh_dấu (U29_1 | U29_2 UTF-8)

• Kiểu mảng byte là một kiểu mới được hỗ trợ trong AMF3 so với AMF0 Kểu này cũng tượng tự như kiểu mảng của AMF3 nhưng các phần tử của nó là các byte

Kiểu_mảng_byte = đánh_dấu (U29_1 | U29_2 n*(U8))

3.3.1 Số hóa âm thanh

Nếu muốn thực hiện truyền âm thanh trên mạng số, trước tiên cần phải số hóa

nó bằng cách dùng bộ chuyển đổi tín hiệu từ tín hiệu tương tự sang tín hiệu số (A/D Analog-to-Digital).Để đạt độ chính xác cao khi khôi phục tín hiệu âm thanh thì tần

số lấy mẫu phải lớn hơn hai lần tần số của tín hiệu âm thanh Trong mạng thoại người ta thường sử dụng tần số lấy mẫu là 8 KHz nhưng để phục vụ cho việc hội chẩn từ xa thì cần sử dụng tần số lấy mẫu cao hơn 11 KHz, 22 KHz,…bởi vì âm thanh trong hội chẩn từ xa không chỉ là giọng nói của bác sĩ mà có thể là nhịp tim, nhịp thở của bệnh nhân nên cần phải được truyền một cách chính xác

Chuẩn được sử dụng để nén âm thanh là HE-AAC được phát triển từ chuẩn AAC Chuẩn này cung cấp khả năng nén âm thanh với hiệu suất cao nhưng vẫn đáp

ứng được chất lượng tốt

3.3.2 Chuẩn AAC

3.3.2.1 Giới thiệu

Chuẩn nén AAC trước đây là một phần của MPEG-2, nhưng sau này được

mở rộng và bổ sung thêm như là một phần của MPEG-4 AAC[5] là kết quả của một nỗ lực lớn có tính chất quốc tế của nhiều công ty và cá nhân Dự án phát triển AAC được khởi động 1994 khi có số lượng lớn đề nghị được đệ trình lên uỷ ban của MPEG Uỷ ban này sau đó đã tiến tới xây dựng một cấu trúc cho chuẩn AAC bao gồm nhiều module khác nhau mà các module này đóng vai trò như là các thành phần độc lập nhau Các module này được phát triển và kiểm tra một cách riêng biệt trước khi hợp lại thành sản phẩm cuối cùng Các module chính bao gồm:

• Điểu chỉnh khuếch đại (Gain Control)

• Bộ lọc (FilterBank)

• Dự đoán (Prediction)

• Lượng tử (Quantization)

• Mã hoá Huffman (Noiseless Huffman Coding)

• Ghép luồng bit (Bitstream Multiplexing)

• Nắn nhiễu (Temporal Noise Shaping - TNS)

• Mid/side (M/S) stereo coding

• Mã hoá cường độ (Intensity Stereo Coding)

3.3.2.2 Đặc tính âm học của tai người

Các nhà khoa học, các kĩ sư và các chuyên gia đã áp dụng đặc tính của hệ thống cảm nhận âm thanh của con người để thực hiện việc nén âm thanh Các nhà khoa học khi nén âm thanh đã làm giảm hoặc loại bỏ hoàn thành những phần âm thanh mà con người không cảm nhận được Hình sau đây mô tả chi tiết về đặc tính cảm nhận âm thanh của tai người Trong hình có một đường cong biểu diễn ngưỡng nghe của tai người Nếu âm thanh có các đặc tính âm học nằm phía dưới đường cong này thì tai người không cảm nhận được Theo như hình, đặc tính cảm nhận âm thanh của tai người phụ thuộc nhiều vào tần số Ngưỡng dưới biên độ của âm thanh cao ở cả tần số cao và tần số thấp Để âm thanh ở các tần số này có thể nghe được, thì nó cần phải được khuếch đại lên cao hơn mức ngưỡng Ngưỡng mà tai người có thể nghe được thấp nhất ở trong khoảng tần số từ 3KHz – 5KHz, điều này cho thấy rằng tai người rất nhạy cảm với âm thanh ở tần số này và có thể nhận biết những âm thanh dù là nhỏ nhất

Hình 3.13: Ngưỡng âm thanh của tai người phụ thuộc vào tần số

Tuy nhiên vẫn còn có những điểm mà tại đó tai người cũng không thể nghe thấy được mặc dù cường độ âm thanh lớn hơn mức ngưỡng Trên hình có một đường cong đứt nét chỉ ra rằng với những âm thanh ở khoảng tần số này, tai người không thể nghe thấy được những âm thanh có cường độ cao hơn mức biểu diễn của đường cong đứt nét này

Thời gian cũng là một nhân tố ảnh hưởng tới khả năng cảm nhận âm thanh Hình sau đây biểu diễn một ngưỡng khác về khả năng cảm nhận âm thanh của tai Lúc đầu một âm thanh 60dB (ở một tần số f nào đó) kéo dài trong vòng 5ms, tai người có thể cảm nhận được âm thanh này Nhưng nếu âm thanh “x” 30 dB xuất hiện sau đó 5ms thì không thể nghe được vì nó bị lấn át bởi âm thanh 60dB xuất hiện trước đó Nhưng cũng với âm thanh “x” 30 dB này xuất hiện sau đó 10ms thì tai có thể nghe được Như vậy, tai người cũng có thể bị lấn át bởi các âm thanh lớn trong vòng một khoảng thời gian mà trong khoảng thời gian này tai người không thể

bị kích thích bởi các âm thanh khác nữa

Hình 3.14: Ngưỡng âm thanh của tai người phụ thuộc vào thời gian

Tiếp theo sau đây là hình biểu diễn tính chất âm học của tai ở các khía cạnh tần số thời gian và biên độ

Hình 3.15: Ngưỡng âm thanh theo tần số, thời gian, và biên độ

3.3.2.3 Hoạt động của thuật toán nén âm thanh AAC

Dựa vào tính chất này của tai, thuật toán nén mất âm thanh theo tần số và thời gian làm việc theo các bước sau

Hình 3.16: Biểu đồ hoạt động của thuật toán nén âm thanh

• Đầu tiên các tin hiệu âm thanh sau khi đã lấy mẫu được gom thành những nhóm gối lên nha (tức là dùng những cửa sổ trượt) rồi đưa vào bộ lọc

(Filter Bank) Tại bộ lọc, mỗi cửa sổ sẽ được chuyển thành các giá trị tần

số Các giá trị này tương ứng với một khoảng của tần số (dải tần số) và chỉ ra cường độ của âm thanh ở dải tần số này

• Sử dụng các giá trị này để quyết định nhưng âm thanh bị che (loại bỏ) Khi quyết định âm thanh nào bị che, một mô hình cảm giác (Perceptual model) được sử dụng Mô hình này đưa ra các thông số về ngưỡng cụ thể cho từng loại tần số để quyết định xem những giá trị tần số nào là không quan trọng

• Các giá trị tần số sẽ được lượng tử rồi được mã hoá bằng loại mã có chiều dài thay đổi Các từ mã này là kết quả của cả quá trình trên

Nhiệm vụ đầu tiên của bộ mã hoá là lấy các mẫu âm thanh rồi tính toán ra các tần số của sóng âm thanh biểu diễn những âm thanh này Trên thực tế là các khoảng âm thanh (hay dải âm thanh) được tính toán ra, và một hệ số tần số ( hay hệ

số phổ) được tính toán cho một dải âm thanh Độ rộng của dải phải không được vượt quá bộ rộng của dải âm thanh của tai người Điều này được hoàn thành bởi ngân hàng bộ lọc Đối với mp3, 512 mậu được lưu trong bộ đệm và được tính toán cho 32 dải tần số Sau đó 32 mẫu âm thanh tiếp theo được chuyển vào bộ đệm và quá trình được lặp lại Còn đối vời AAC cũng thực hiện như trên nhưng sử dụng

2048 mẫu âm thanh, tính toán cho 1024 hệ số phổ, mỗi hệ số biểu diễn cho một dải băng tần rộng 23.4 Hz, và sau đó 1024 mẫu âm thanh tiếp theo được chuyển vào trong bộ đệm

Thành phần tiếp theo là mô hình cảm giác Nó quyết định độ cao của ngưỡng cho mỗi dải tần số Trong mp3, mô hình này không được đặc tả chi tiết và do đó mỗi nhà thiết kế lại cho ra những mô hình của riêng họ Sự thành công của mỗi mô hình phụ thuộc nhiều vào sự chi tiết và sự giống nhau của nó với mô hình của tai người Còn AAC cũng tương tự với mô hình cảm giác mà không đặc tả hoạt động chính xác của nó

Đối với mỗi dải tần số, bộ mã hoá so sánh hệ số của phổ so với ngưỡng của dải tần số Nếu hệ số phổ nhỏ hơn ngưỡng thì hệ số được lượng tử theo dải tần số tương ứng Nếu lượng tứ quá nhiều sẽ làm giảm chất lượng của âm thanh và nhiễu rất cao Ngược lại nếu lượng tử không đủ thì sẽ không đáp ứng được tốc độ bit đề

• Module dự đoán tăng hiệu suất của bộ lượng tử trong trường hợp âm thanh gốc giống với mẫu cò sẵn, như là âm giọng cao (âm thanh có dạng hình sin)

Bước kế tiếp là mã hoá (coding) Hệ số phổ sau được lượng tử sẽ được mã hoá Bước này cũng đóng góp vào việc làm tăng khả năng nén bởi vì hệ số được thay thế bởi các từ mã có kích thước thay đổi, nhưng với cách mã hoá này thì không làm mất dữ liệu Cả mp3 và AAC đều sử dụng mã Huffman

Như vậy, AAC chia sẻ những điểm mạnh của mp3 dồng thời có nhưng cải tiến như sau:

Ngân hàng bộ lọc lớn hơn với 1023 hệ số phổ được tao ra từ cửa sổ 2048 mẫu âm thanh, dẫn tới dải tần số hẹp hơn do đó có chất lượng âm thanh khi giải nén tốt hơn mp3

Temporal noise shaping (TNS) một thuật toán mới cho phép giải thiểu đến thấp nhất ảnh hưởng của … điều này đặc biệt hữu dụng đối với nén tín hiệu giọng nói

Module dự đoán làm tăng khả năng lượng tử cho nhưng âm thanh theo chu

kì hoặc những âm thanh theo mẫu có sẵn

3.3.2.4 Mô tả chi tiết về AAC

Sau đây là phầm mô tả chi tiết về AAC được định nghĩa trong MPEG-2 và những tính năng được thêm vào AAC trong MPEG-4

AAC hỗ trợ 3 loại profile Mỗi loại profile là một hồ sơ miêu tả cấu hình cấu hình khác của các thuật toán cơ bản và các profile này cung cấp các thoả hiệp khác nhau giữa hiệu suất nén và độ phức tạp của bộ mã hoá (ảnh hưởng đến khả năng thực hiện của máy tính) Một chỉ mục 2 bit chỉ profile nào sử dụng sẽ được lưu lại sau khi nén

Dự trữ

Hình 3.17: Ba loại profile của AAC

• Index 0, profile chính (Main Profile) Trong profile này, AAC đưa ra khả năng nén tốt nhất cho bất cứ tốc độ bit và tốc độ lấy mẫu nào Tất cả các module, các hàm, và các công cụ của đặc tả ( ngoại trừ công cụ điểu chỉnh khuếch đại) đều được miêu tả Đây là profile thông dụng và nó được thực hiện khi có đủ bộ nhớ và năng lực xử lý (hiện nay thì tất cả các máy tính đều

có thể áp dụng được)

• Index 1, profile độ phức tạp thấp (Low Complexity Profile – LC Profile) Điều chỉnh khuếch đại và dự đoán không được sử dụng Và TNS cũng bị giới hạn còn 12 Mặt khác, LC là một profile con của profile chính cho nên là LC

có thể được giải mã bởi bộ giải mã của profile chính

• Index 2, profile tốc độ lấy mẫu thay đổi (Scalable Sampling Rate Profile - SSR) Profile này được thiết kế để làm đơn giản độ phức tạp tính toán khi dữ liệu âm thanh gốc chỉ gồm những khoảng tần số giới hạn (như vậy sẽ làm

giảm băng thông sau khi được mã hoá) Công cụ điều chỉnh khuếch đại được yêu cầu trong SSR và công cụ này chỉ được sử dụng duy nhất trong SSR Order của TNS và băng thông cũng bị giới hạn Một luồng nén của LC có thế giải mã được bởi SSR nhưng kết quả của âm thanh sau khi giải mã sẽ bị giới hạn

• Index 3 được dự trữ cho profile trong tương lai

Điều chỉnh khuếch đại là công cụ tiền xử lý và chỉ được sử dụng trong profile SSR Nó bao gồm nhiều module lọc, nhận dạng độ khuếch đại, thay đổi độ khuếch đại Điều chỉnh khuếch đại bắt đầu bằng việc lọc dữ liệu đầu vào tạo thành bốn băng tần rộng 6 KHz Các hệ số phổ của mỗi dải tần số được kiểm tra bởi bộ nhận dạng dộ khuếch đại, Bộ nhận dạng tìm kiếm các thay đổi mạnh trong độ khuếch đại của tín hiệu (nghĩa là các hệ số liên tục nhau rất khác nhau về kích thước) Bộ thay đổi độ khuếch đại sử dụng các kết quả này để thêm vào các hệ số này nhằm làm tăng khả năng nén tín hiệu âm thanh đầu vào

Hình 3.18: Bộ mã hoá âm thanh AAC

Hình 3.19: Bộ giải mã âm thanh AAC

Hình 3.20: Module mã hoá và giải mã điều chỉnh khuếch đại

Filtering, bộ mã hoá AAC chuyển đổi các mẫu âm thanh thành các hệ số tần

số bằng biến đổi cosin rời rạc cải biên (MDCT) Quá trình xử lý giống với mp3, nhưng với độ phân giải tần số cao hơn và có nhiều cải tiến hơn Bộ mã hoá sử dụng hai loại cửa sổ: dài và ngắn Cửa sổ dài gồm có 2048 mẫu liên tục nhau và được biến đổi để tạo ra 1024 hệ số tần số (biến đổi dài) Một cửa sổ ngắn hơn có 256 mẫu

và đưa ra kết quả là 128 hệ số (biến đổi ngắn) Một khi hệ số của một cửa sổ đã được tính toán thì bộ mã hoá chuyển vào thêm một số mẫu mới bằng với ½ kích thước của cửa sổ

Cửa sổ dài tạo ra nhiều hệ số, do đó mỗi hệ số sẽ tương ứng với một dải tần

số hẹp hơn Điều này dẫn tới việc lượng tử sẽ chính xách hơn và giúp ích cho việc làm giảm băng thông vì sẽ có thể bỏ nhiều đoạn âm thanh nằm trong vùng tần số mà không có tác động tới tai người

Độ rộng của dải tần số tuỳ thuộc vào tốc độ lấy mẫu (số lượng mẫu âm thanh trong một giây), số lượng kênh (hai cho âm thanh nổi) và số lượng dải tần số AAC cung cấp đặc tả và bảng thống kê cho 12 loại tốc độ lấy mẫu sau (tính bằng Hz): 96000, 88200, 64000, 48000, 44100, 32000, 24000, 16000, 12000, 11025,

8000 Đối với tốc độ lấy mẫu 48000 Hz và có 2 kênh, mỗi kênh được lấy mẫu ở tốc

độ 24000 Hz

Hình 3.21: Tập 12 dải tần số và đặc tả

Công thức cho MDCT của bộ mã hoá được cho như sau:

Trong đó Zi,n là một mẫu âm thanh, i là chỉ số khối, n là mẫu âm thanh ở cửa

sổ hiện tại, k là chỉ số của hệ số tần số X, N là kích thước cửa sổ (2048 hoặc 256) và

n0= (N/2+1)/2

Lượng tử trong AAC cũng giống như những tính năng khác của AAC đều cải tiến từ mp3 Quy tắc lượng tử như sau: