nghiên cứu và thiết kế hệ thống điều khiển thiết bị điện và giám sát hình ảnh qua mạng internet

Bên thu sử dụng số thứ tự trong mào đầu gói RTP để xây dựng lại gói đúng thứ tự như gói bên phát, và số thứ tự cũng có thể được sử dụng để xác định vị trí thích hợp của một gói tin, ví d

- Lâm Ngọc Chiến

NGHIÊN CỨU VÀ THIẾT KẾ HỆ THỐNG ĐIỀU KHIỂN

THIẾT BỊ ĐIỆN VÀ GIÁM SÁT HÌNH ẢNH

QUA MẠNG INTERNET

Chuyên ngành: Kỹ thuật viễn thông

LUẬN VĂN THẠC SĨ KỸ THUẬT

KỸ THUẬT VIỄN THÔNG

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS NGUYỄN HOÀNG DŨNG

Trang phụ bìa

Hà Nội – 2015

LỜI CAM ĐOAN

Trước hết, tôi xin gửi lời cảm ơn chân thành tới tập thể các thầy cô trong Viện Điện tử viễn thông, trường Đại học Bách Khoa Hà Nội đã tạo ra một môi trường thuận lợi về cơ sở vật chất cũng như về chuyên môn trong quá trình tôi thực hiện đề tài Tôi cũng xin cảm ơn các thầy cô trong Viện Đào tạo sau đại học đã quan tâm đến khóa học này, tạo điều kiện cho các học viên như tôi có điều kiện thuận lợi để học tập và nghiên cứu Và đặc biệt tôi xin gửi lời cảm ơn sâu sắc đến thầy giáo TS.Nguyễn Hoàng Dũng đã tận tình chỉ bảo, định hướng khoa học và hướng dẫn, sửa chữa cho nội dung của luận văn này

Tôi xin cam đoan rằng nội dung của luận văn này là hoàn toàn do tôi tìm hiểu, nghiên cứu và viết ra Tất cả đều được tôi thực hiện cẩn thận và có sự định hướng và sửa chữa của giáo viên hướng dẫn

Tôi xin chịu trách nhiệm với những nội dung trong luận văn này

Tác giả

Lâm Ngọc Chiến

MỤC LỤC

Trang phụ bìa 1

MỤC LỤC 3

DANH MỤC CÁC HÌNH VẼ 5

DANH MỤC CÁC BẢNG BIỂU 7

DANH MỤC CÁC TỪ VIẾT TẮT 8

MỞ ĐẦU 10

Chương 1 LÝ THUYẾT MẠNG 13

1.1 Sơ lược về mạng Internet 13

1.2 Giao thức RTP 15

1.3 Giao thức RTCP 18

1.4 Kết luận chương 25

Chương 2 LÝ THUYẾT VỀ XỬ LÝ VIDEO 26

2.1 Sơ lược về xử lý tín hiệu 26

2.2 Sơ lược về xử lý video 26

2.3 Chuẩn nén video H264 27

2.3.1 Cấu trúc ảnh 30

2.3.2 Nhóm ảnh GOP 32

2.3.3 Cấu trúc bittream video 32

2.3.4 Thuật toán nén H.264 34

2.3.5 Mã hóa H.264 35

2.3.6 Giải mã H.264 41

2.3.7 Cấp hồ sơ và ứng dụng 43

2.4 Thư viện ffmpeg 43

2.5 Kết luận chương 45

Chương 3 THIẾT KẾ PHẦN CỨNG 46

3.1 Sơ đồ khối hệ thống 46

3.2 Khối điều khiển trung tâm 47

3.2.1 Raspberry Pi B+ 47

3.2.2 Giới thiệu LAN9514 57

3.3 Khối cảm biến hình ảnh 62

3.4 Khối cảm biến nhiệt DS18b20 65

3.5 Khối điều khiển thiết bị 68

3.6 Khối động cơ bước 69

3.7 Kết luận chương 74

Chương 4 LẬP TRÌNH PHẦN MỀM 75

4.1 Giới thiệu về Rasbian 75

4.2 Ngôn ngữ lập trình python 75

4.3 Lưu đồ thuật toán 78

4.3.1 Lưu đồ thuật toán lúc đăng nhập 78

4.3.2 Lưu đồ thuật toán điều khiển thiết bị 79

4.3.3 Lưu đồ thuật toán điều khiển camera 80

4.3.4 Lưu đồ thuật toán hẹn giờ theo thời gian 81

4.3.5 Lưu đồ thuật toán hẹn giờ theo nhiệt 82

4.3.6 Lưu đồ thuật toán thu thập dữ liệu nhiệt độ 83

4.3.7 Lưu đồ thuật toán thu thập dữ liệu video 84

4.3.8 Lưu đồ thuật toán tải trang quản trị 85

4.4 Giới thiệu giao diện điều khiển 85

4.5 Kết luận chương 89

Chương 5 KẾT LUẬN 90

5.1 Kết luận chung 90

5.2 Đánh giá chất lượng truyền tải hình ảnh 90

5.3 Những điểm hạn chế và hướng khắc phục 92

5.3.1 Những điểm hạn chế 92

5.3.2 Hướng khắc phục và mở rộng 92

TÀI LIỆU THAM KHẢO 94

DANH MỤC CÁC HÌNH VẼ

Hình 1.1: Mô hình của mạng LAN 13

Hình 1.2: Mô hình đơn giản của mạng WAN 14

Hình 1.3: Header cố định gói RTP 15

Hình 1.4: Heaer phần mở rộng 17

Hình 1.5: Cấu trúc gói SR 20

Hình 1.6: Xác định độ delay khứ hồi 22

Hình 1.7: Cấu trúc của gói RR (Receiver Report) 23

Hình 1.8: Cấu trúc của gói SDES (System Description) 23

Hình 1.9: Cấu trúc của SDES Items 23

Hình 1.10: Cấu trúc gói BYE 24

Hình 1.11: Cấu trúc gói APP 25

Hình 2.1:Sơ lược hệ thống CODEC 27

Hình 2.2: Biểu đồ PSNR của H.264 so với MPEG-4 và JPEG 30

Hình 2.3: Dự đoán bù chuyển động một chiều và hai chiều 31

Hình 2.4: Thứ tự các frame ảnh trong nén video 31

Hình 2.5:Mô hình biểu diễn các thành phần trong mã hóa video 33

Hình 2.6: Cấu trúc header và data cho từng thành phần trong mã hóa video 34

Hình 2.7: Mô hình tiến trình Coding and Decoding trong H.264 35

Hình 2.8: Mô hình hoạt động của hệ thống CODEC H.264 35

Hình 2.9: Mô hình chi tiết quá trình H.264 Encoder 35

Hình 2.10: Mô hình cấu trúc Slice trong H.264 37

Hình 2.11: Mô hình các kiểu dự đoán Intra 4x4 38

Hình 2.12: Mô hình các kiểu dự đoán Intra 16x16 39

Hình 2.13: Mô hình chi tiết quá trình H.264 Decoder 42

Hình 2.14: Ví dụ chuyển đổi hệ số lượng tử 42

Hình 2.15: Mô hìn htái cấu trúc (Reconstructors) 42

Hình 3.1: Sơ đồ khối của hệ thống 46

Hình 3.2: Hình ảnh của Raspberry Pi B+ 47

Hình 3.3: Sơ đồ khối của Raspberry PiB+ 48

Hình 3.4: Bản đồ bộ nhớ của BCM2835 49

Hình 3.5: Sơ đồ khối một chân GPIO 53

Hình 3.6: Sơ đồ các chân GPIO của raspberry pi b+ 54

Hình 3.7: Sơ đồ chân kết nối của CSI-2 55

Hình 3.8: Sơ đồ nội khối của LAN9514 58

Hình 3.9: Sơ đồ cấu trúc chân của LAN9514 58

Hình 3.11: Kết nối nguồn của LAN9514 61

Hình 3.12: Module camera của Raspberry Pi 62

Hình 3.13: Sơ đồ chân DS18B20 65

Hình 3.14: Sơ đồ khối DS18B20 65

Hình 3.15: Cấu trúc của ROM code của DS18B20 66

Hình 3.16: Tổ chức bộ nhớ của DS18B20 66

Hình 3.17: Cấu trúc byte4 bộ nhớ Scratchpad 67

Hình 3.18: Cấu trúc 2 thanh ghi nhiệt độ ở bộ nhớ Scratchpad 68

Hình 3.19: Sơ đồ ghép nối của DS18B20 68

Hình 3.20: Hình ảnh module relay 4 kênh 68

Hình 3.21: Sơ đồ nguyến lý khối relay 4 kênh 69

Hình 3.22: Cấu tạo động cơ lưỡng cực 70

Hình 3.23: Moment xoắn tổng hợp khi cấp điện nhiều mấu 70

Hình 3.24: Nguyên lý điều khiển vi bước 71

Hình 3.25: Module điều khiển động cơ bước TB6560 72

Hình 3.26: Sơ đồ khối chức năng của module TB 6560 72

Hình 3.27: Sơ đồ ghép nối với module TB6560 73

Hình 4.1: Lưu đồ thuật toán lúc đăng nhập 78

Hình 4.2: Lưu đồ thuật toán điều khiển thiết bị 79

Hình 4.3: Lưu đồ thuật toán điều khiển camera 80

Hình 4.4: Lưu đồ thuật toán hẹn giờ theo thời gian 81

Hình 4.5: Lưu đồ thuật toán hẹn giờ theo nhiệt 82

Hình 4.6: Lưu đồ thuật toán thu thập dữ liệu nhiệt độ 83

Hình 4.7: Lưu đồ thuật toán thu thập dữ liệu video 84

Hình 4.8: Lưu đồ thuật toán tải trang quản trị 85

Hình 4.9:Giao diện đăng nhập của raspi 86

Hình 4.10: Giao diện control panel của raspi 86

Hình 4.11: Giao diện biểu đồ nhiệt của không gian giám sát 87

Hình 4.12: Giao diện video của raspi 87

Hình 4.13: Trang quản trị hệ thống 88

Hình 4.14: Giao diện thay đổi các thiết lập mặc định của lưu trữ video 88

Hình 4.15: Giao diện phân cấp người dùng của raspi 88

Hình 4.16: Giao diện thiết lập thiết bị điều khiển 89

Hình 4.17: Giao diện lưu trữ video 89

Hình 5.1: PNSR qHD sau khi truyền 91

Hình 5.2: PNSR HD 720p sau khi truyền 91

Hình 5.3: PNSR HD 1080p sau khi truyền 92

DANH MỤC CÁC BẢNG BIỂU

Bảng 1.1: Giá trị các trường PT 18

Bảng 2.1: Độ phân giải của và các tốc độ bit yêu cầu trên môi trường Internet của các chuẩn video 26

Bảng 2.2: Các loại slice trong H.264 37

Bảng 2.3: Các thành phần trong cấu trúc Macroblock 38

Bảng 2.4: H.264 profile level 43

Bảng 3.1: Sơ đồ chi tiết kết nối CSI của Raspberry Pi 56

Bảng 3.2: Các chân của LAN9514 59

Bảng 3.3: Thông số kỹ thuật của Raspberry Pi Camera 63

Bảng 3.4: Tính năng phần cứng của raspicam 63

Bảng 3.5:Tính năng phần mềm của raspicam 64

Bảng 3.6: Bảng các độ phân giải của DS18B20 67

Bảng 3.7: Bảng cấu hình dòng điều khiều động cơ bước của module 74

Bảng 3.8: Bảng cấu hình dòng giữ (Stop current) 74

Bảng 3.9: Bảng cấu hình góc quay.(Excitation Mode) 74

Bảng 3.10: Bảng cấu hình suy hao của module TB6560 74

DANH MỤC CÁC TỪ VIẾT TẮT

AJAX Asynchronous JavaScript and XML

ALSA Advanced Linux Sound Architecture

ARM Advanced RISC Machines

ARPANET Advanced Research Projects Agency Network

ASO Arbitrary Slice Order

AVC Advanced Video Coding

AXI Advanced eXtensible Interface

B Bidirectionally Picture

CABAC Context-Adaptive Binary Arithmetic Coding

CAVLC Context-Adaptive Variable Length Coding

CMDTM Command and Transfer Mode

CPU Central Processing Unit

CRC Cyclic Redundancy Check

CSI Camera Serial Interface

CSMA/CD Carrier Sense Multiple Access Collision Detect

DCT Discrete Cosine Transform

DMA Direct Memory Access

DSI Display Serial Interface

DVD Digital Video Disc

EEPROM Electrically Erasable Programmable Read-Only Memory

FIFO First In First Out

FMO Flexible Macroblock Order

GNU General Public License

GOP Group of Picture

GPIO General-Purpose Input/Output

GPU Graphics Processing Unit

HDMI High-Definition Multimedia Interface

HTML5 Hyper Text Markup Language 5

HTTP Hyper Text Transfer Protocol

I Intra-Code Picture

I2C Inter-Integrated Circuit

IC Integrated Circuit

LAN Local Area Network

MAC Media Access Control

MAN Metropolitan Area Network

MB Macroblock

MCN MIPI Clock negative

MCP MIPI Clock Positive

MDN MIPI Data negative

MDP MIPI Data Positive

MIPI Mobile Industry Processor Interface

MMC MultiMediaCard

MMU Memory Management Unit

MPEG Moving Picture Experts Group

NAL Network Abstraction Layer

NSFNET National Science Foundation Network

NTP Network Time Protocol

OS Operating system

P Predictive Code Picture

PC Personal Computer

PCB Printed Circuit Board

PCI Peripheral Component Interconnect

PCM/I2S Pulse-code modulation and Inter-IC sound

PSNR Peak signal-to-noise ratio

HD Hhigh-Definition

QVGA Quarter Video Graphics Array

RTCP Realtime Transport Control Protocol

RTP Realtime Transport Protocol

SCCB Serial Camera Control Bus

SD Secure Digital

SubLVDS Low Voltage Differential Signalling

SDRAM Synchronous Dynamic Random Access Memory

SEC Sequence End Code

SPI Serial Peripheral Interface

TCP Transmision Control Protocol

UDP User Datagram Protocol

USB Universal Serial Bus

VfW Video for Windows

VGA Video Graphics Array

VS Video Sequence

WAN Wide Area Network

ZIF Zero Insertion Force

MỞ ĐẦU

Điều khiển từ xa đã và đang là một xu hướng phát triển mang tính quy luật vì

sự tiện ích mà nó đem lại Sự phát triển vượt bậc của khoa học kỹ thuật nói chung, ngành viễn thông nói riêng và đặc biệt là sự bùng nổ và phổ biến nhanh chóng của mạng Internet đã tạo nền tảng vững chắc cho xu hướng này Sự tiện lợi, xóa đi mọi khoảng cách về không gian địa lý do đó nên nó đã trở thành một nhu cầu tất yếu của cuộc sống hiện đại ngày nay, nơi lao động chân tay đang dần chuyển sang cho máy móc mà phần lớn đều sử dụng nguồn năng lượng điện

Hiện nay, xu thế này trên thế giới đã rất phổ biến và có rất nhiều ứng dụng khác nhau trong nhiều lĩnh vực phục vụ đời sống Ở Việt Nam chỉ mới manh nha nhưng chủ yếu vẫn là các ứng dụng theo dõi, giám sát truyền hình ảnh qua Internet

sử dụng thiết bị nước ngoài Vì giá thành thiết bị cao nên vẫn chưa phổ biến ở nước

ta và hầu hết là các giải pháp không đồng bộ, tách rời giữa điều khiển và giám sát, không tiết kiệm chi phí triển khai và năng lượng sử dụng Do đó cần kết hợp vào một hệ thống tích hợp tối ưu thực hiện hai chức năng trên và đáp ứng được các yêu cầu sau:

 Điều khiển và kiểm tra trạng thái thiết bị điện qua mạng Internet

o Chính xác và tin cậy cao: Các thông tin truyền tải có độ tin cậy, bảo mật, nhanh chóng và chính xác Có cơ chế lưu trữ thông tin

o Hoạt động ổn định trong điều kiện môi trường nước ta có nhiệt độ dao động từ 2.7 tới 48oC, độ ẩm

o Điều khiển tối thiểu 10 thiết bị sử dụng điện xoay chiều có điện áp 110V tới 250V AC và dòng tối đa 10A với chế độ bật/tắt đơn giản

o Tiết kiệm điện năng: công suất tiêu thụ tối đa 10W/h

o Kính thước tối đa 25cm x25cm x20cm

o Có trang quản trị cấp cao để cấu hình các tham số chuẩn, cũng như thêm, sửa hay xóa thiết bị

 Thiết lập các chế độ tự động của thiết bị về thời gian hay nhiệt độ

o Sai số nhiệt độ tối đa 1oC, tần suất lấy mẫu tối thiểu 1 mẫu /1 giây và dải nhiệt đo được từ 0 tới 100oC

o Lưu trữ thông tin nhiệt độ ít nhất 30 ngày và vẽ biểu đồ nhiệt độ trung bình tối thiểu 1 phút

o Đồng bộ thời gian với hệ thống NTP

o Hỗ trợ ít nhất 3 bộ định thời và 1 ngưỡng nhiệt

o Cập nhật liên tục thông tin về các bộ định thời và ngưỡng nhiệt

o Có hệ thống cảnh báo khi đạt ngưỡng nhiệt

 Truyền được hình ảnh thời gian thực về không gian đang giám sát

o Hỗ trợ ghi hình vào ban ngày hoặc điều kiện thiếu sáng nhẹ (không hỗ trợ ban đêm)

o Độ trễ hình ảnh tối đa 1.5 giây

o Băng thông tối đa khi truyền hình ảnh dưới 1Mbps

o Hỗ trợ các độ phân giải qHD (960x540), HD (1280x720) và Full HD (1920x1080) trong đó số khung hình tối thiểu là 24 khung hình, tốc độ bit tối thiểu 0.4 Mb

o Góc quay tối thiểu 270độ

Trong đó Raspberry Pi đóng vài trò trung tâm: thu nhận dữ liệu từ cảm biến nhiệt (DS18b20) và cảm biến hình ảnh (Omnivision 5647), nhận lệnh điều khiển, thực hiện điều khiển, gửi phản hồi thông tin và hình ảnh khu vực giám sát tới người dùng qua môi trường mạng Internet Nhằm đạt được yêu cầu về độ trễ truyền tải hình ảnh và yêu cầu băng thông tối đa khi truyền tải, ta lựa chọn sử dụng chuẩn H.264 để nén hình ảnh và giao thức RTP để truyền tải hình ảnh

Cấu trúc luận văn gồm 5 chương như sau:

Chương 1: Lý thuyết mạng

Sơ lược về mạng Internet, các ưu điểm của giao thức RTP

Chương 2: Lý thuyết về xử lý video

Sơ lược về xử lý ảnh, các ưu điểm nổi bật của chuẩn nén H.264 và thư viện ffmpeg

Chương 1 LÝ THUYẾT MẠNG 1.1 Sơ lược về mạng Internet

Nguồn gốc của Ethernet được phát triển từ những thí nghiệm đối với cáp đồng trục được thực hiện ở tốc độ truyền 2.96 Mbps và sử dụng nghi thức CSMA/CD vào năm 1975 bởi tập đoàn Xerox Sau đó, Xerox đã cùng Digital Equipment và Intel xây dựng một chuẩn 10Mbit/s – Ethernet, và phát hành như một chuẩn mở vào năm

1980 Đây chính là cơ sở cho IEEE 802.3 sau này Vào năm 1985, ủy ban tiêu chuẩn IEEE cho mạng địa phương và đô thị công bố tiêu chuẩn cho mạng LAN Các tiêu chuẩn này bắt đầu với số hiệu 802 và 802.3 là cho Ethernet, chuẩn này được biết với nghi thức CSMA/CD

Ethernet tạo ra phần lớn các mạng LAN (hiện tại đang được sử dụng cho gần 85% cho mạng LAN để nối PC và các máy trạm) Bởi vì giao thức của nó có một số đặc điểm sau:

 Dễ dàng sử dụng, triển khai, quản lý và bảo trì

 Tốc độ kết nối cao

 Cung cấp rất đa dạng mô hình mạng

 Bảo mật tốt các kết nối chung

Hiện nay, bên cạch việc sử dụng cáp đồng trục, đôi dây xoắn và cáp quang, Ethernet không dây (Wireless LAN, IEEE802.11) cũng đã phát triển mạnh mẽ do sự tiện lợi mà nó mang lại

Hình 1.1: Mô hình của mạng LAN

Internet là một mạng toàn cầu bao gồm nhiều mạng LAN, MAN và WAN trên thế giới kết nối với nhau Mỗi mạng thành viên này được kết nối vào Internet thông qua một router Tạo nên một hệ thống thông tin toàn cầu có thể được truy nhập công cộng

Hình 1.2: Mô hình đơn giản của mạng WAN

Tiền thân của mạng Internet ngày nay là mạng ARPANET Năm 1983, giao thức TCP/IP chính thức được coi như một chuẩn đối với ngành quân sự Mỹ và tất

cả các máy tính nối với ARPANET phải sử dụng chuẩn mới này Năm 1984, ARPANET được chia ra thành hai phần: phần thứ nhất vẫn được gọi là ARPANET, dành cho việc nghiên cứu và phát triển; phần thứ hai được gọi là MILNET, là mạng dùng cho các mục đích quân sự

Năm 1980, ARPANET được đánh giá là mạng trụ cột của Internet Mốc lịch

sử quan trọng của Internet được xác lập vào giữa thập niên 1980 khi tổ chức khoa học quốc gia Mỹ NSF thành lập mạng liên kết các trung tâm máy tính lớn với nhau gọi là NSFNET Nhiều doanh nghiệp đã chuyển từ ARPANET sang NSFNET.Sự hình thành mạng xương sống của NSFNET và những mạng vùng khác đã tạo ra một môi trường thuận lợi cho sự phát triển của Internet Tới năm 1995, NSFNET thu lại thành một mạng nghiên cứu còn Internet thì vẫn tiếp tục phát triển

Với khả năng kết nối mở như vậy, 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, xuất hiện trong mọi lĩnh vực thương mại, chính trị, quân sự, nghiên cứu, giáo dục, văn hoá, xã hội… Cũng từ đó, các dịch vụ trên Internet không ngừng phát triển tạo ra cho nhân loại một thời kỳ mới: kỷ nguyên thương mại điện tử trên Internet

1.2 Giao thức RTP

Giao thức RTP cung cấp các chức năng giao vận phù hợp cho các ứng dụng truyền dữ liệu mang đặc tính thời gian thực như là thoại và truyền hình tương tác Những dịch vụ của RTP bao gồm trường chỉ thị loại tải trọng xác định loại, đánh số thứ tự các gói, điền tem thời gian (phục vụ cho cơ chế đồng bộ khi phát lại tín hiệu

ở bên thu) và giám sát việc cung cấp

Giao thức RTP hỗ trợ việc truyền dữ liệu tới nhiều đích, sử dụng phân bố dữ liệu multicast nếu như khả năng này được tầng mạng hoạt động bên dưới nó cung cấp

Giao thức RTP không cung cấp cơ chế đảm bảo việc phân phát kịp thời dữ liệu tới các trạm mà nó dựa trên các dịch vụ của tầng thấp hơn để thực hiện điều này Và giao thức RTP cũng không đảm bảo việc truyền các gói theo đúng thứ tự và

độ tin cậy của gói tin Bên thu sử dụng số thứ tự trong mào đầu gói RTP để xây dựng lại gói đúng thứ tự như gói bên phát, và số thứ tự cũng có thể được sử dụng để xác định vị trí thích hợp của một gói tin, ví dụ như trong việc giải mã video, mà không nhất thiết phải giải mã các gói tin theo thứ tự

Đi cùng với RTP là giao thức RTCP có các dịch vụ giám sát chất lượng dịch

vụ và thu thập các thông tin về những trạm tham gia vào phiên truyền RTP đang tiến hành

Version (V): có độ dài 2 bit Chỉ ra phiên bản của RTP

Padding (P): có độ dài1 bit Nếu bit padding có giá trị 1, gói dữ liệu sẽ có một

vài octets thêm vào cuối gói dữ liệu Octets cuối cùng của phần thêm vào này sẽ chỉ kích thước của phần thêm vào này (tính theo byte) Những octets này không phải là thông tin Chúng được thêm vào để đáp ứng các yêu cầu sau:

 Phục vụ cho một vài thuật toán mã hóa thông tin cần kích thước của gói cố định

 Dùng để cách ly các gói RTP trong trường hợp nhiều gói thông tin được mang trong cùng một đơn vị dữ liệu của giao thức tầng dưới

Extension (X): có độ dài1 bit Nếu như bit X có giá trị 1, theo sau phần tiêu đề

cố định sẽ là một tiêu đề mở rộng

Marker (M): có độ dài 1 bit Tùy từng trường hợp cụ thể mà bit này mang

những ý nghĩa khác nhau ý nghĩa của nó được chỉ ra trong một profile đi kèm

Payload Type (PT): có độ dài 7 bit Trường này chỉ ra loại tải trọng mang

trong gói Các mã sử dụng trong trường này ứng với các loại tải trọng được quy định trong một hồ sơ đi kèm

Sequence Number: có độ dài 16 bit Mang số thứ tự của gói RTP Số thứ tự

này được tăng lên một sau mỗi gói RTP được gửi đi Trường này có thể được sử dụng để bên thu phát hiện được sự mất gói và khôi phục lại trình tự đúng của các gói Giá trị khởi đầu của trường này là ngẫu nhiên

Timestamp (tem thời gian): có độ dài 32 bit Tem thời gian phản ánh thời

điểm lấy mẫu của octets đầu tiên trong gói RTP Thời điểm này phải được lấy từ một đồng hồ tăng đều đặn và tuyến tính theo thời gian để cho phép việc đồng bộ và tính toán jitter Bước tăng của đồng hồ này phải đủ nhỏ để đạt được độ chính xác đồng bộ mong muốn khi phát lại và sự chính xác của việc tính toán jitter

Số nhận dạng nguồn đồng bộ SSRC (Synchronization Source Identifier):

có độ dài 32 bit SSRC chỉ ra nguồn đồng bộ của gói RTP, số này được chọn một cách ngẫu nhiên

Các số nhận dạng nguồn đóng góp (CSRC list – Contributing Source list)

Có từ 0 đến 15 mục trong đó mỗi mục có độ dài 32 bit Các số nhận dạng nguồn đóng góp trong phần tiêu đề chỉ ra những nguồn đóng góp thông tin và phần tải trọng của gói Các số nhận dạng này được Mixer chèn vào tiêu đề của gói và nó chỉ mang nhiều ý nghĩa trong trường hợp dòng các gói thông tin là dòng tổng hợp tạo thành từ việc trộn nhiều dòng thông tin tới mixer Trường này giúp cho bên thu nhận biết được gói thông tin này mang thông tin của những trạm nào trong một cuộc hội nghị

Số lượng các số nhận dạng nguồn đóng góp được giữ trong trường CC của phần tiêu đề Số lượng tối đa của các số nhận dạng này là 15 Nếu có nhiều hơn 15 nguồn đóng góp thông tin vào trong gói thì chỉ có 15 số nhận dạng được liệt kê vào danh sách

Mixer chèn các số nhận dạng này vào gói nhờ số nhận dạng SSRC của các nguồn đóng góp

Phần mở rộng

Cơ chế mở rộng của RTP cho phép những ứng dụng riêng lẻ của giao thức RTP thực hiện được với những chức năng mới đòi hỏi những thông tin thêm vào phần header của gói Cơ chế này được thiết kế để một vài ứng dụng có thể bỏ qua một số ứng dụng khác lại có thể sử dụng được phần nào đó Cấu trúc của phần tiêu

Length: có độ dài 16 bit Mang giá trị chiều dài của phần tiêu đề mở rộng tính

theo đơn vị 32 bit Giá trị này không bao gồm 32 bit đầu tiên của phần tiêu đề mở rộng

1.3 Giao thức RTCP

Giao thức RTCP dựa trên việc truyền đều đặn các gói điều khiển tới tất cả các trạm tham gia vào phiên truyền RTCP sử dụng có chế phân phối gói dữ liệu trong mạng giống như giao thức RTP, tức là cũng sử dụng các dịch vụ của giao thức UDP qua một cổng UDP độc lập với việc truyền các gói RTP

Các loại gói điều khiển RTCP

Giao thức RTCP bao gồm các loại gói sau:

 SR (Sender Report): Mang thông tin thống kê về việc truyền và nhận

thông tin từ những người tham gia trong trạng thái tích cực gửi

 RR (Receiver Report): Mang thông tin thống kê về việc nhận thông

tin từ những người tham gia không ở trạng thái tích cực gửi

 SDES (Source Description items): Mang thông tin miêu tả nguồn

phát gói RTP

 BYE: Chỉ thị sự kết thúc tham gia vào phiên truyền

 APP: Mang các chức năng cụ thể cửa ứng dụng

Giá trị của trường PT (Packet Type) ứng với mỗi loại gói được liệt kê trong

chèn thêm vào các bit cách ly Số lượng các gói trong hợp gói không quy định cụ thể mà tùy thuộc vào chiều dài đơn vị dữ liệu lớp dưới

Mọi gói RTCP đều phải được truyền trong hợp gói cho dù trong hợp gói chỉ

có một gói duy nhất Khuôn dạng của hợp gói được đề xuất như sau:

Tiếp đầu mã hóa (Encription Prefix): (32 bit) 32 bit đầu tiên được để dành nếu

và chỉ nếu hợp gói RTCP cần được mã hóa Giá trị mang trong phần này cần chú ý tránh trùng với 32 bit đầu tiên trong gói RTP

Gói đầu tiên trong hợp gói luôn luôn là gói RR hoặc SR Trong trường hợp không thu, không nhận thông tin hay trong hợp gói có một gói BYE thì một gói RR rỗng dẫn đầu trong hợp gói

Trong trường hợp số lượng các nguồn được thống kê vượt quá 31 (không vừa trong một gói SR hoặc RR) thì những gói RR thêm vào sẽ theo sau gói thống kê đầu tiên Việc bao gồm gói thống kê (RR hoặc SR) trong mỗi hợp gói nhằm thông tin thường xuyên về chất lượng thu của những trạm tham gia Việc gửi hợp gói đi được tiến hành một cách đều đặn và thường xuyên theo khả năng cho phép của băng thông

Trong mỗi hợp gói cũng bao gồm SDES nhằm thông báo về nguồn phát tín hiệu Các gói BYE và APP có thể có thứ tự bất kỳ trong hợp gói trừ gói BYE phải nằm cuối cùng

Khoảng thời gian giữa hai lần phát hợp gói RTCP

Các hợp gói của RTCP được phát đi một cách đều đặn sau những khoảng thời gian bằng nhau để thường xuyên thông báo về trạng thái các điểm cuối tham gia Vấn đề là tốc độ phát các hợp gói này phải đảm bảo không chiếm hết lưu lượng thông tin dành cho các thông tin khác Trong một phiên truyền, lưu lượng tổng cộng cực đại của tất cả các loại thông tin truyền trên mạng được gọi là băng thông của phiên (session bandwidth) Lưu lượng này được chia cho các bên tham gia vào cuộc hội nghị Lưu lượng này được mạng dành sẵn và không cho phép vượt quá để không ảnh hưởng đến các dịch vụ khác của mạng Trong mỗi phần băng thông của phiên được chia cho các bên tham gia phần lưu lượng dành cho các gói RTCP chỉ

được phép chiếm một phần nhỏ và đã biết là 5% để không ảnh hưởng đến chức năng chính của giao thức là truyền các dòng dữ liệu đa phương tiện

Cấu trúc gói SR

Hình 1.5: Cấu trúc gói SR

Gói SR bao gồm 3 phần bắt buộc:

Phần tiêu đề dài 8 octet

Ý nghĩa của các trường như sau:

Version (V) và Padding (P): Mang ý nghĩa giống như trong tiêu đề của gói

RTP

Reception Report Count (RC): có độ dài 5 bit Cho biết số lượng của các khối

báo cáo tin chứa trong gói Nếu trường này mang giá trị 0 thì đây là gói SR rỗng

Packet Type (PT): có độ dài 8 bit Chỉ thị loại gói Với gói SR giá trị này bằng

200 (thập phân)

Length: có độ dài 16 bit Chiều dài của gói RTCP trừ đi 1 (tính theo đơn vị 32

bit) Chiều dài này bao gồm phân tiêu đề và phần padding thêm vào cuối gói

SSRC: có độ dài 32 bit Chỉ thị nguồn đồng bộ cho nơi phát ra gói SR này

Phần thông tin bên gửi

Phần thông tin bên gửi dài 20 octet và có trong mọi gói SR Các trường có ý

nghĩa như sau:

NTP timestamp (tem thời gian NTP): có độ dài 64 bit Chỉ ra thời gian tuyệt

đối khi gói báo cáo được gửi đi Tem thời gian này có cấu trúc thời gian theo giao thức NTP (Network Time Protocol): Thời gian tính theo giây với mốc là 0h UTC ngày 1-1-1900; phần nguyên của giá trị thời gian là 32 bit đầu tiên; 32 bit còn lại biểu diễn phần thập phân

RTP timestamp (tem thời gian RTP): có độ dài 32 bit Giá trị của trường này

tương ứng với giá trị của trường NTP timestamp ở trên nhưng được tính theo đơn vị của nhãn thời gian RTP trong gói dữ liệu RTP và với cùng một độ lệch ngẫu nhiên của nhãn thời gian RTP trong gói dữ liệu RTP

Số lượng gói phát đi của nguồn gửi gói SR (Sender’s packet count): có độ

dài 32 bit Số lượng tổng cộng của các gói dữ liệu RTP được truyền từ nguồn gửi gói SR kể từ khi bắt đầu việc truyền thông tin cho tới thời điểm gói SR được tạo ra Trường này được xóa về không trong trường hợp nguồn gửi đổi số nhận dạng SSRC của nó Trường này có thể được sử dụng để ước tính tốc độ dữ liệu tải trọng trung bình

Số lượng octets đã được nguồn gửi gói SR gửi đi (Sender octets count): có

độ dài 32 bit Số lượng tổng cộng của các octet phần payload được truyền đi trong các gói RTP bởi nguồn gửi gói SR kể từ khi bắt đầu việc truyền cho đến thời điểm gói SR này được tạo ra

Các khối báo cáo thu (Reception report blocks)

Phần này bao gồm các khối thông tin báo cáo về việc thu các gói từ các trạm trong phiên truyền Số lượng các báo cáo có thể là 0 trong trường hợp gói báo cáo rỗng Mỗi khối báo cáo thống kê về việc nhận các gói RTP của một nguồn đồng bộ,

bao gồm:

Số nhận dạng nguồn (SSRC_n): có độ dài 32 bit

Tỷ lệ mất gói (fraction lost): có độ dài 8 bit Tỷ lệ mất gói thông tin tính từ lúc

gửi gói SR hoặc RR trước đó Tỷ lệ mất gói được tính bằng cách đem chia giá trị của trường cho 256

Số lượng gói mất tổng cộng (cumulative number of packets lost): có độ dài

24 bit Tổng số gói mất tính từ lúc bắt đầu nhận Số gói mất bao gồm cả những gói đến đích muộn

Số thứ tự cao nhất nhận được: có độ dài 32 bit Trong đó, 16 bit cao mang số

thứ tự cao nhất nhận được ứng với giá trị khởi đầu là ngẫu nhiên và 16 bit thấp mang số thứ tự cao nhất tương ứng với giá trị khởi đầu bằng 0

Độ Jitter khi đến đích: có độ dài 32 bit Mang giá trị ước tính độ jitter của các

gói khi đến đích Được tính theo đơn vị của trường timestamp và được biểu diễn dưới dạng số nguyên không dấu Độ Jitter được tính là giá trị làm tròn của độc chênh lệch khoảng cách về thời gian giữa hai gói ở bên thu và bên phát

Tem thời gian của gói SR trước đó (LSR): có dộ dài 32 bit Mang giá trị tem

thời gian thu gọn của gói SR trước đó Nếu trước đó không có gói SR nào thì trường này bằng 0

Độ delay tính từ gói SR trước đó (DLSR): có độ dài 32 bit Độ delay (tính

theo đơn vị 1/65536 giây) giữa thời điểm nhận gói SR trước đó từ nguồn SSRC_n

và thời điểm gửi gói RR chứa thông tin báo cáo chất lượng nhận tín hiệu của nguồn

n

Hai trường LSR và DLSR của khối báo cáo thứ r được sử dụng để xác định độ delay khứ hồi giữa hai nguồn r và nguồn n là nguồn gửi gói SR Hình sau minh họa việc xác định độ delay khứ hồi giữa hai nguồn n và r Thời điểm A nguồn n nhận được gói RR từ nguồn r được ghi lại và trừ đi giá trị của trường LSR của khối báo cáo r để ra được độ delay tổng cộng Giá trị thu được lại được trừ đi trường DLSR của khối r để tìm ra độ delay khứ hồi của gói thông tin giữa n và r

Hình 1.6: Xác định độ delay khứ hồi

Cấu trúc gói RR

Gói RR (Receiver Report) có cấu trúc giống như gói SR ngoại trừ trường PT

có giá trị bằng 201 và không mang phần thông tin về nguồn gửi Gói RR có cấu trúc như sau:

Hình 1.7: Cấu trúc của gói RR (Receiver Report)

Cấu trúc gói SDES

Gói SDES (System Description) Gói SDES có khuôn dạng như trong hình bao gồm một phần tiêu đề và các đoạn thông tin mô tả nguồn

Hình 1.8: Cấu trúc của gói SDES (System Description)

Phần mô tả nguồn

Mỗi đoạn thông tin miêu tả nguồn bao gồm một cặp số nhận dạng nguồn SSRC/CSRC theo sau đó là các mục miêu tả (SDES Items) Các mục miêu tả có cấu trúc chung như hình sau:

Hình 1.9: Cấu trúc của SDES Items

Trong đó:

Item có độ dài 8 bit

Chỉ thị loại mục mô tả Giá trị của trường này tương ứng với các loại mục miêu tả sau:

 CNAME (Canonical Name) (item =1): Phần thông tin mô tả mang số

nhận dạng tầng giao vận cố định đối với một nguồn RTP

 NAME (item = 2) User Name SDES Item: Phần thông tin mô tả

mang tên mô tả nguồn

 EMAIL (item = 3) Electronic Mail Address SDES Item: Phần thông

tin mô tả là địa chỉ email của nguồn

 PHONE (item = 4) Phone Number SDES Item: Phần thông tin mô tả

là số điện thoại của nguồn

 LOC (item = 5) Geographic User Location SDES Item: Phần thông

tin mô tả là địa chỉ của nguồn

 TOOL (item = 6) Application or Tool Name SDES Item: Phần thông

tin mô tả là tên của ứng dụng tạo ra dòng thông tin đa phương tiện

 NOTE (item = 7) Notice/Status SDES Item: Các chú thích về nguồn

 PRIV (item = 8) Private Extensions SDES Item: Dành cho các thông

tin khác

Cấu trúc gói BYE

Gói BYE được sử dụng để thông báo một hay một vài nguồn sẽ rời khỏi phiên

truyền Trường thông tin về lý do rời khỏi phiên là tùy chọn (có thể có hoặc không)

Hình 1.10: Cấu trúc gói BYE

Cấu trúc gói APP

Các gói APP được dùng cho thí nghiệm như các ứng dụng mới và các tính năng mới được phát triển, mà không đòi hỏi giá trị kiểu gói đăng ký Gói APP có

tên không được công nhận nên được bỏ qua Sau khi thử nghiệm và nếu sử dụng rộng rãi là hợp lý, nó được đề nghị để mỗi gói APP đó được định nghĩa lại mà không có subtype và tên đăng ký với IANA sử dụng một loại gói RTCP

Hình 1.11: Cấu trúc gói APP

1.4 Kết luận chương

Tìm hiểu nguồn gốc, quá trình hình thành và phát triển của mạng Internet Nắm được đặc điểm truyền thông và các ưu điểm nổi bật của giao thức RTP và RTCP trong việc truyền tải video thời gian thực so với các giao thức TCP/UDP Đây là cơ

sở lý thuyết vững chắc và quan trọng trong việc lựa chọn giao thức truyền tải, xây dựng và tối ưu phần mềm trong chương 4 nhằm giảm thiểu độ trễ, tăng cường chất lượng trong truyền tải hình ảnh

Chương 2 LÝ THUYẾT VỀ XỬ LÝ VIDEO

2.1 Sơ lược về xử lý tín hiệu

Tín hiệu là biểu diễn vật lý của thông tin, về mặt toán học tín hiệu được biểu diễn bởi hàm của một hoặc một số biến số độc lập

Xử lý tín hiệu số (Digital signal processing) là việc xử lý những tín hiệu đã

được biểu diễn dưới dạng chuỗi những dãy số Xử lý tín hiệu số và xử lý tín hiệu tương tự là hai phần của xử lý tín hiệu

2.2 Sơ lược về xử lý video

Để đảm bảo chất lượng, độ delay cho phép và phù hợp với điều kiện truyền dẫn hiện tại đòi hỏi phải nén video trước khi truyền dẫn Nén video là việc xử lý chuyển đổi video số thành các định dạng thích hợp để truyền đi hoặc để lưu trữ, sao cho giảm thiểu số bit truyền hoặc lưu trữ video đó

Bảng 2.1: Độ phân giải của và các tốc độ bit yêu cầu trên môi trường Internet của

các chuẩn video

Khái niệm nén video, đây là một hệ thống gồm 2 thành phần liên quan nhau, một là bộ phận nén (Encoder), hai là bộ phận giải nén (Decoder) Encoder chuyển đổi dữ liệu video ban đầu thành các dạng nén giảm thiểu các bit lưu trữ hoặc truyền Decoder chuyển đổi dữ liệu nén từ Encoder sang dữ liệu video ban đầu

Hệ thống Encoder/Decoder được gọi đơn giản là CODEC (enCOder/DECoder)

Hình 2.1:Sơ lược hệ thống CODEC

Hiện nay, có rất nhiều các chuẩn nén video khác như: 2 Video,

MPEG-4 Visual, H.263, VC-1, H.26MPEG-4, … v.v Mỗi chuẩn nén có những điểm mạnh và điểm yếu khác nhau Nhưng trong đó, H.264 là chuẩn nén cho ra video chất lượng tốt (không bị giảm đi nhiều so với chất lượng ban đầu) với số bitrate giảm đáng kể so với các chuẩn ra đời trước đó

Do đó, ngày nay H.264 thường được sử dụng cho các ứng dụng truyền nhận video hoặc lưu trữ video

2.3 Chuẩn nén video H264

H.264/MPEG-4 Part 10 hay AVC thường được gọi tắt là H.264 [6], là một chuẩn mã hóa/giải mã video và định dạng video đang được sử dụng rộng rãi nhất hiện nay để ghi, nén và chia sẻ video phân giải cao, dựa trên việc bù trừ chuyển động (motion-compensation) trên từng block (block oriented)

Nhưng điểm mạnh về thiết kế của H.264:

 Cấu trúc dữ liệu sau mã hóa thành các gói dữ liệu được gọi là NAL Cấu trúc NAL cho phép tùy biến tốt hơn cho các mạng khác nhau

 Kích cỡ slice linh động: không giống như các chuẩn nén MPEG, kích thước các slice trong H.264 rất linh động có thể đáp ứng cho các yêu cầu về phần vùng ảnh, delay mã hóa, dự đoán chuyển động trong các ứng dụng khác nhau

 Thứ tự các Macroblock linh động FMO : đây là tính năng mới trong H.264 để phân mảnh, hình thành các vùng được gọi là Slice Group Mỗi slice trở thành một tập con của một slice group, các slice có thể giải mã một cách độc lập Khi sử dụng FMO, có thể làm giảm đáng kể việc tổn thất dữ liệu bằng cách quản lý mối quan hệ không gian giữa các vùng mã hóa trong mỗi slice

 Sắp xếp thứ tự các slice tùy ý ASO: do mỗi slice của một ảnh có thể giải mã một cách độc lập với các slice khác của ảnh nên H.264 cho phép gửi và nhận các slice này của ảnh theo bất cứ thứ tự nào tương ứng với chúng

Những cải thiện về thiết kế

H.264 có độ nén cao hơn mà vẫn đảm bảo được chất lượng tương đương sau khi giải mã so với các chuẩn nén trước đó Trong VLC không có kỹ thuật nào làm cải thiện đáng kể hiệu suất nén so với các chuẩn trước mà là do nhiều cải thiện nhỏ trong các thành phần trước đó của bộ mã hóa H.264

Các cải thiện đó như sau:

 H.264 hỗ trợ linh hoạt hơn trong việc lựa chọn các kích thước block

bù chuyển động so với các chuẩn trước Kích thước block bù chuyển động tối thiểu được sử dụng cho độ chói là 4x4

 Bù chuyển động chính xác tới ¼ mẫu: Hầu hết các chuẩn mã hóa trước cho phép vector chuyển động chính xác tới ½ mẫu Trong khi đó, H.264 đã cải thiện độ chính xác tới ¼ mẫu, tính năng này kế thừa từ tính năng nâng cao của MPEG-4 Visual, nhưng H.264 đã giảm độ phức tạp trong tiến trình nội suy so với MPEG-4 Visual

 Vector chuyển động có thể vượt quá các biên của ảnh trong khi vector chuyển động trong các chuẩn trước chỉ yêu cầu chỉ ra vùng hình tham chiếu cho việc dự đoán chuyển động H.264 sử dụng kỹ thuật ngoại suy biên hình để làm tăng hiệu quả dự đoán chuyển động

 Bù chuyển động với nhiều ảnh tham chiếu: So với các chuẩn nén trước chỉ sử dụng một ảnh tham chiếu để dự đoán chuyển động cho ảnh thì H.264

đã sử dụng nhiều ảnh tham chiếu để dự doán chuyển động để bộ mã hóa được hiệu quả hơn Kỹ thuật này kế thừa từ tính năng nâng cao của H.263++

 Song song với việc sử dụng nhiều ảnh tham chiếu là việc áp dụng dự đoán chuyển động hai chiều (kỹ thuật này áp dụng cho các frame B)

 Tách biệt mối quan hệ giữa thứ tự tham chiếu và thứ tự hiễn thị: Trong các chuẩn trước có sự phụ thuộc rất chặt chẽ giữa thứ tự ảnh cho các tham

chiếu bù chuyển động và thứ tự ảnh hiển thị Trong H.264, các giới hạn thứ tự này

bị loại bỏ cho phép bộ mã hóa chọn thứ tự các ảnh cho việc tham chiếu và các ảnh cho hiển thị một cách linh động, chỉ ràng buộc giới hạn về tổng dung lượng bộ nhớ được sử dụng để đảm bảo khả năng giải mã

 Tách biệt phương pháp biểu diễn ảnh với khả năng tham chiếu ảnh: trong các chuẩn trước, các ảnh được tham chiếu hai chiều (ảnh B) không được sử dụng cho việc dự đoán trong chuỗi video H.264 đã sử dụng ảnh này để làm cho mã hóa trở nên linh động hơn

 Dự đoán có trọng số: là một cải tiến mới trong H.264 cho phép tín hiệu dự đoán bù chuyển động được đặt trọng số và thực hiện bù bằng những đơn vị nhất định được chỉ ra bởi bộ mã hóa Điều này cải thiện hiệu quả mã hóa rất lớn cho các cảnh mờ trong hình ảnh và có thể được sử dụng linh hoạt cho các mục đích khác nhau

 Dự đoán trực tiếp không gian cho ảnh mã hóa Intra: Một kỹ thuật mới của việc ngoại suy các biên của những phần được mã hóa trước của ảnh hiện tại được áp dụng cho các vùng ảnh được mã hóa Intra Điều này cải thiện chất lượng của tín hiện dự đoán và cũng cho phép dự đoán các vùng lân cận chưa được mã hóa

 Chuyển đổi miền không gian kích cỡ block nhỏ: các chuẩn mã hóa trước sử dụng kích cỡ block chuyển đổi là 8x8 trong khi đó thiết kế của H.264 thực hiện chuyển đổi trên block 4x4 Điều này cho phép bộ mã hóa biểu diễn các tín hiệu trong một hình dạng có sự tương thích cục bộ cao hơn, làm giảm các thành phần lạ

 Mã hóa Entropy: 2 phương pháp mã hóa entropy nâng cao là CABAC

và CAVLC Cả hai phương pháp này đều sử dụng khả năng tương thích nội dung để cải thiện hiệu quả mã hóa so với các chuẩn mã hóa trước

Hình 2.2: Biểu đồ PSNR của H.264 so với MPEG-4 và JPEG

 Chỉ loại bỏ được sự dư thừa không gian

 Dùng các điểm trong cùng một khung để dự báo

Ảnh P (Predictive Code Picture)

Ảnh P được mã hóa liên ảnh một chiều (Inter prediction) với các đặc điểm:

 Dự báo Inter một chiều

 Ảnh dự báo được tạo từ ảnh tham chiếu trước đó Ảnh tham chiếu này

có thể là ảnh I hoặc ảnh P gần nhất

 Có sử dụng bù chuyển động Thông tin ước lượng chuyển động các khối nằm trong vector chuyển động (motion vector) Vector này xác định Macroblock (MB) nào được sử dụng từ ảnh trước đó

Do vậy ảnh P bao gồm cả những Macroblock mã hóa (I-MB) là những Macroblock chứa thông tin lấy từ ảnh tham chiếu, và những Macroblock mã hóa Intra là những Macroblock thứa thông tin không thể mượn từ ảnh trước

Ảnh P có thể sử dụng làm ảnh tham chiếu tạo dự báo cho ảnh sau

Ảnh B (Bidirectionally Picture)

Ảnh B là ảnh mã hóa liên ảnh hai chiều Tức là:

 Có sử dụng bù chuyển động

 Ảnh dự báo gồm các Macroblock của cả khung hình trước và sau đó

Việc sử dụng thông tin lấy từ ảnh trong tương lai hoàn toàn có thể thực hiện

được vì tại thời điểm mã hóa thì bộ mã hóa đã sẵn sàng truy cập tới ảnh phía sau

Ảnh B không được sử dụng làm ảnh tham chiếu tạo dự báo cho các ảnh sau

đó

Hình 2.3: Dự đoán bù chuyển động một chiều và hai chiều

Ví dụ về dự đoán chuyển động sử dụng các loại ảnh được thể hiện ở hình sau:

Hình 2.4: Thứ tự các frame ảnh trong nén video

 Cấu trúc khép kín: Việc dự đoán ảnh không sử dụng thông tin của GOP

khác Ảnh cuối cùng của một GOP bao giờ cũng là ảnh P

2.3.3 Cấu trúc bittream video

Cấu trúc dòng bit video bao gồm 6 lớp như sau:

 Khối (block): là đơn vị cơ bản cho biến đổi cosin rời rạc DCT Bao gồm 8x8 pixel tín hiệu chói hoặc tín hiệu màu

 Khối Macroblock: là nhóm các block tương ứng với vùng có kích thước 16x16 pixel trên frame Có nhiều dạng macroblock khác nhau phụ thuộc vào cấu trúc lấy mẫu được sử dụng

Phần header của Macroblock chứa thông tin phân loại và vector bù chuyển động tương ứng

 Lát (slice): Được cấu thành từ một hay một số Macroblock liên tiếp nhau Phần header của slice chứa thông tin về vị trí của nó trong ảnh và tham số lượng tử hóa Kích thước của slice quyết định bởi mức bảo vệ lỗi cần có trong ứng dụng vì bộ giãi mã sẽ bỏ qua slice bị lỗi

 Ảnh: Lớp ảnh cho bên thu biết về loại mã hóa khung I, P, B Phần header mang thứ tự truyền tải của khung để bên thu hiển thị khung theo đúng thứ

tự, ngoài ra còn có một số thông tin bổ sung như thông tin đồng bộ, độ phân giải và vector chuyển động

Hình : Cấu trúc bittream cơ bản trong mã hóa video

 Nhóm ảnh (GOP): Gồm cấu trúc các ảnh I, P, B Mỗi nhóm bắt đầu bằng ảnh I, cung cấp điểm vào ra và tìm kiếm

 Chuỗi video VS: Lớp chuỗi bao gồm phần header, một hoặc một số nhóm ảnh (GOP) và phần kết thúc chuỗi SEC

Hình 2.5:Mô hình biểu diễn các thành phần trong mã hóa video

Thông tin quan trọng nhất của phần header là kích thước (dọc, ngang) của mỗi ảnh, tốc độ bit, tốc độ ảnh và dùng lượng yêu cầu

Thông tin chuỗi ảnh và phần header của chuỗi là dòng bit đã mã hóa, còn gọi

là dòng video cơ bản

Hình 2.6: Cấu trúc header và data cho từng thành phần trong mã hóa video

2.3.4 Thuật toán nén H.264

“Recommendation H.264: Advanced Video Coding” là tài liệu về H.264 được phát triển để đáp ứng nhu cầu ngày càng tăng về nén cao hơn của hình ảnh video cho các ứng dụng như hội nghị truyền hình, phương tiện lưu trữ kỹ thuật số, truyền

hình, Internet streaming và truyền thông

Hình 2.7: Mô hình tiến trình Coding and Decoding trong H.264

Hoạt động của hệ thống H.264 CODEC dựa trên 2 thành phần chính:

 H.264 video encoder, trong đó bao gồm các thành phần:

o Hoán chuyển đổi

o Tái cấu trúc các frame của video

Hình 2.8: Mô hình hoạt động của hệ thống CODEC H.264

2.3.5 Mã hóa H.264

Sơ đồ của thành phần Encoder được mô tả như hình 2.11

Hình 2.9: Mô hình chi tiết quá trình H.264 Encoder

Điểm khác biết của H.264 với các bộ mã hóa khác (MPEG – 2, MPEG – 4 visual, H.263, …) là có sự lựa chọn chế độ mã hóa liên ảnh (Inter Prediction) hoặc

mã hóa trong ảnh (Intra Prediction) giúp dự đoán trong ảnh

Chế độ mã hóa trong ảnh cho phép một Macroblock có thể nội suy từ giá trị

các điểm ảnh ở Macroblock lân cận trong cùng ảnh và nhờ đó làm tăng thêm hiệu

quả nén trong miền không gian

Quá trình mã hóa thuận:

 Source Picture: là các frame hoặc field được chia nhỏ thành các Macroblock, mỗi block sẽ được mã hóa theo chế độ intra hoặc inter

 Trong chế độ Intra, thành phần được dự đoán (Prediction MB) được suy

ra từ các mẫu đã được mã hóa hoặc đã được giải mã hoặc khôi phục trong cùng 1 slice

 Trong chế độ Inter, thành phần được dự đoán (Prediction MB) được suy

ra nhờ dự đoán bù chuyển động (Motion compensation) từ 1 đến 2 khung

đã mã hóa trước đó

 Hiệu của thành phần dự đoán và block hiện tại sẽ được biến đổi cosin rời rạc DCT và lượng tử hóa (Quantization) tạo thành một nhóm hệ số biến đổi đã lượng tử hóa, các hệ số này sẽ được sắp xếp lại và mã hóa Entropy

 Các hệ số lượng tử và các thông tin cần thiết để giải mã từng block trong Macroblock: chế độ mã hóa nào, tham số lượng tử, thông tin vector chuyển động, … được nén thành các bittream, qua NAL để truyền đi hoặc lưu trữ

Quá trình khôi phục:

 Quá trình khôi phục có nhiệm vụ giải mã block nhằm mục đích tạo ra

block tham chiếu cho lần dự đoán kế tiếp

 Block được khôi phục đã được giải lượng tử hóa (Invert Quantization) và biến đổi DCT ngược (Invert Transform) kết hợp với thành phần dự đoán

(Prediction MB), qua bộ lọc (De-blocking filter) để tạo ra các frame tham

cố định Chuẩn mã hóa H.264 có 5 loại slice được mã hóa và một frame ảnh được

mã hóa có thể bao gồm nhiều loại slice khác nhau

Ví dụ: Frame ảnh được mã hóa trong Baseline profile bao gồm các slice I và P

Frame ảnh trong Main profile bao gồm I, P và B slice Ứng dụng tiềm năng của Baseline bao gồm thoại video, hội nghị truyền hình, và truyền thông không dây, ứng dụng tiềm năng của main profile là truyền hình quảng bá và lưu trữ dữ liệu

Header slice định nghĩa loại slice và frame ảnh mã hóa mà slice đó thuộc về,

có thể kèm theo thông tin liên quan đến quản lý các ảnh tham chiếu Phần dữ liệu của slice bao gồm chuỗi các macroblock được mã hóa

Mỗi macroblock bao gồm hai thành phần: header và dữ liệu dự đoán macroblock được mã hóa

Các loại slice được thể hiện trong bảng sau:

Bảng 2.2: Các loại slice trong H.264

Cấu trúc của slice được thể hiện trong hình sau:

Hình 2.10: Mô hình cấu trúc Slice trong H.264

Macroblock

Một maroblock bao gồm các dữ liệu được mã hóa ứng với vùng 16x16 mẫu của video frame Macroblock được đánh số theo thứ tự trong frame

Bảng 2.3: Các thành phần trong cấu trúc Macroblock

Dự đoán nội khung (Intra prediction)

Trong Intra prediction, các block được dự đoán từ các block trong cùng slice của frame hiện tại Các kiểu Intra prediction trong H.264 bao gồm: dự đoán block intra 4x4, dự đoán block intra 16x16, dự đoán cho 2 đại diện của các thành phần màu Dự đoán intra 4x4 phù hợp với các vùng ảnh có độ phức tạp về chi tiết cao Có

4 chế độ dự đoán Intra 4x4

Hình 2.11: Mô hình các kiểu dự đoán Intra 4x4

Dự đoán intra 16x16 phù hợp với các vùng đơn giản của ảnh

Có 4 chế độ dự đoán intra 16x16: dự đoán theo chiều dọc, dự đoán theo chiều

ngang, dự đoán DC, dự đoán phẳng

Hình 2.12: Mô hình các kiểu dự đoán Intra 16x16

Intra prediction trong H.264 được điều khiển trong miền không gian bằng việc tham chiếu các mẫu bên cạnh đã được mã hóa trước đó (các block ở bên trái hoặc phía trên của block đang được dự đoán) Mỗi thành phần màu 8x8 của một macroblock được dự đoán từ các mẫu màu được mã hóa trước đó Các thành phần ở trên và bên trái luôn được sử dụng cùng một chế độ dự đoán Dự đoán các thành phần màu cũng có 4 chế độ như dự đoán intra 16x16

Dự đoán liên khung (Inter prediction)

Dự đoán liên khung trong H.264 cho các block có thể tham chiếu tới một hay nhiều frame đã được mã hóa trước đó

Các dự đoán liên khung được phân thành các loại: dự đoán trong slice P, dự đoán trong slice B, dự đoán có trọng số

Chuyển đổi và lượng tử (transform and quantized)

Sau khi thực hiện biến đối DCT, các hệ số sẽ được lượng tử hoá dựa trên một bảng lượng tử Q(u,v) với 0≤u, v≤ n-1, n là kích thước khối Bảng này được định nghĩa bởi từng ứng dụng cụ thể, các phần tử trong bảng lượng tử có giá trị từ 1 đến

255 được gọi là các bước nhảy cho các hệ số DCT

Quá trình lượng tử được coi như là việc chia các hệ số DCT cho bước nhảy lượng tử tương ứng, kết quả này sau đó sẽ được làm tròn xuống số nguyên gần nhất Các hệ số năng lượng thấp này, tượng trưng cho các sự thay đổi pixel - pixel cỡ nhỏ, có thể bị xóa mà không ảnh hưởng đến độ phân giải của ảnh phục hồi

Tại bộ mã hoá sẽ có một bảng mã và bảng các chỉ số nội bộ, từ đó có thể ánh

xạ các tín hiệu ngõ vào để chọn được các từ mã tương ứng một cách tốt nhất cho tập hợp các hệ số được tạo ra Có 2 loại lượng tử hóa chủ yếu:

 Lượng tử hóa vô hướng:

o Lượng tử từng giá trị một cách độc lập hay nói cách khác là ánh xạ một mẫu của tín hiệu ngõ vào tạo thành một hệ số lượng tử ở ngõ ra Đây là một quá trình tổn hao vì khi giải lượng tử, không thể xác định chính xác giá trị gốc từ số nguyên đã được làm tròn

o Lượng tử hóa thuận theo công thức FQ = round(X/QP)

o Lượng tử hóa ngược theo công thức Y = FQ*QP Với QP là bước nhảy lượng tử

 Lượng tử hóa vector:

o Là một quá trình biểu diễn một tập vector (mỗi vector gồm nhiều giá trị) bằng một tập các số hữu hạn các ký hiệu ở ngõ ra, bảng mã ánh xạ

sẽ có các giá trị xấp xỉ với giá trị gốc

o Vector lượng tử sẽ được lưu ở cả bộ mã hóa và bộ giải mã, quá trình nén một bức ảnh sử dụng lượng tử vector bao gồm các bước sau:

 Phân chia bức ảnh gốc thành các phân vùng MxN pixel

 Chọn vector thích ứng nhất từ bảng mã

 Truyền chỉ số của vector thích ứng đến bộ giải mã

 Tại bộ giải mã, ảnh cấu trúc lại sẽ xấp xỉ với phân vùng đã lựa chọn vector lượng tử

Mã hóa Entropy

Mã hóa Entropy là hình thức mã hóa một chuỗi dựa trên số lần xuất hiện các chuỗi con của nó Chuỗi con nào xuất hiện nhiều nhất sẽ được mã bởi chuỗi có độ dài ngắn nhất, nhờ vậy chuỗi kết quả sau khi mã hóa có độ dài là ngắn nhất Điều này có lợi trên đường truyền có băng thông hạn chế

Trong H.264 có các phương pháp cho mã hóa entropy như sau:

 Fixed length code: phương pháp này chuyển đổi các ký tự sang mã nhị phân với kích xác định trước (n bit)

 Exponential-Golomb variable length code: Các ký tự được biểu diễn bởi bảng từ mà Exp-Golomb với một số thay đổi của các bit (v bit) Các ký tự