Giới thiệu dự án

Sự bùng nổ của hạ tầng Internet băng rộng và các thiết bị thông minh đã đưa dịch vụ truyền phát video trực tuyến (video streaming) trở thành lưu lượng chủ đạo trên không gian mạng toàn cầu. Theo báo cáo từ Nielsen Global, hơn 91% người dùng trực tuyến tại Việt Nam thường xuyên theo dõi video theo nhu cầu (Video on Demand - VoD). Trên quy mô thế giới, các nền tảng như YouTube phục vụ hơn 5 tỷ lượt xem mỗi ngày và Facebook ghi nhận hơn 100 triệu giờ xem video hàng ngày. Nhu cầu khổng lồ này đặt áp lực nặng nề lên hạ tầng mạng viễn thông, đặc biệt là bài toán tối ưu hóa tài nguyên mạng nhằm bảo đảm chất lượng trải nghiệm của người dùng (Quality of Experience - QoE).

+-----------------------------------------------------------------------------+
|                      MÔ HÌNH HỆ THỐNG TRUYỀN PHÁT HAS                       |
+-----------------------------------------------------------------------------+
|  [ Media Server ]                                                           |
|       |                                                                     |
|       +--> Tệp MPD (Media Presentation Description)                         |
|       +--> Video Segments (VBR: QP 22, 28, 34, 38, 42, 48)                  |
|       |                                                                     |
|  [ Mạng phân phối / Quản lý băng thông tập trung ]                          |
|       |    (Bottleneck Link: Băng thông tổng R_total)                       |
|       |                                                                     |
|       +==================== Kênh truyền HTTP =====================+         |
|       |                           |                              |          |
|       v                           v                              v          |
| [ Client 1 (VoD) ]       [ Client 2 (VoD) ]            [ Client K (VoD) ]   |
|  - Bộ đệm (Buffer)        - Bộ đệm (Buffer)             - Bộ đệm (Buffer)   |
|  - Module thích ứng       - Module thích ứng            - Module thích ứng  |
+-----------------------------------------------------------------------------+

Vấn đề thực tiễn và thách thức kỹ thuật (Problem Statement)

Trong các mạng truyền dẫn được quản lý (như mạng IPTV, mạng phân phối nội dung CDN nội bộ hay mạng doanh nghiệp), nhiều luồng video cùng chia sẻ một đường truyền có băng thông hữu hạn ($R_{total}$). Khi truyền phát video được mã hóa với tốc độ bit biến đổi (Variable BitRate - VBR), kích thước các phân đoạn (segments) thay đổi mạnh theo độ phức tạp không gian và thời gian của từng khung hình.

Việc áp dụng công nghệ truyền tải thích ứng qua HTTP (HTTP Adaptive Streaming - HAS) tiêu chuẩn (như MPEG-DASH) vốn để cho phía máy khách (client-driven) tự quyết định chất lượng dựa trên thông lượng cục bộ dẫn tới hai điểm nghẽn nghiêm trọng:

  1. Hiện tượng tranh chấp băng thông (Bandwidth Competition): Các máy khách cạnh tranh tài nguyên thiếu kiểm soát, gây dao động chất lượng liên tục (bitrate switching oscillation) và ước lượng thông lượng sai lệch.
  2. Hiện tượng nghẽn và gián đoạn bộ đệm (Rebuffering/Stall): Tốc độ bit đột biến của video VBR dễ làm cạn kiệt bộ đệm máy khách khi băng thông tức thời không đáp ứng kịp, làm suy giảm trực tiếp chỉ số hài lòng trung bình (Mean Opinion Score - MOS).

Mục tiêu của đồ án (Project Objectives)

Đề tài "Nghiên cứu và triển khai phân bổ băng thông cho streaming video VBR qua HTTP" tập trung giải quyết triệt để các vấn đề trên với 4 mục tiêu cụ thể:

  1. Nghiên cứu sâu cơ chế truyền phát thích ứng HAS và lượng hóa các nhân tố kỹ thuật ảnh hưởng đến QoE (độ trễ nạp ban đầu $d_0$, độ ổn định bitrate, tham số lượng tử $QP$).
  2. Xây dựng mô hình toán học thích ứng tốc độ bit cho luồng video VBR đơn lẻ dựa trên hàm thỏa hiệp giữa chất lượng video và độ trễ ban đầu $d_0$ thông qua việc tái cấu trúc các phân đoạn vượt ngưỡng bit $p(\varepsilon)$.
  3. Phát triển và cài đặt 2 thuật toán phân bổ băng thông tập trung cho hệ thống truyền phát đồng thời nhiều luồng video VBR: Thuật toán tối ưu hóa nhân tử Lagrange và Thuật toán sử dụng Hàng đợi ưu tiên (Priority Queue).
  4. Đánh giá thực nghiệm mô phỏng hiệu năng, so sánh chất lượng QoE và thời gian thực thi thuật toán so với phương pháp phân bổ tĩnh/thông thường và thuật toán vét cạn (Exhaustive Search).

Phương pháp tiếp cận và kết quả kỳ vọng

Giải pháp tiếp cận đặt trọng tâm vào tầng ứng dụng (Application Layer), không can thiệp sâu vào các giao thức tầng dưới (TCP/IP), bảo đảm tính tương thích hoàn toàn với chuẩn MPEG-DASH và máy chủ HTTP tiêu chuẩn.

Mục tiêu / Chỉ số Phương pháp truyền thống (Equal / Heuristic) Giải pháp đề xuất của đồ án
Hàm tối ưu QoE ($U$) Không tối ưu hóa thỏa hiệp ($U \approx 2.5 - 3.2$) Cân bằng hữu ích $U = a \cdot U_d + b \cdot U_q \ge 4.0/5.0$
Hiện tượng Rebuffering Tần suất cao khi phân đoạn VBR có bitrate đỉnh Giảm thiểu triệt để nhờ kiểm soát đường bao tích lũy $E(t)$
Độ phức tạp tính toán Thấp ($O(1)$ - chia đều) hoặc Không khả thi ($O(M^K)$ - vét cạn) Tối ưu thời gian thực: $O(K \log(1/\delta))$ (Lagrange) và $O(K \cdot N \log K)$ (Priority Queue)

Phạm vi và giới hạn nghiên cứu (Scope & Limitations)

  • Phạm vi: Tập trung vào dịch vụ Video theo nhu cầu (VoD), phương thức truyền đơn luồng Unicast trên giao thức HTTP/1.1 và HTTP/2, triển khai thuật toán thích ứng và phân bổ tại tầng ứng dụng.
  • Giới hạn: Không áp dụng cho streaming tương tác thời gian thực (như WebRTC video conference); không can thiệp vào thuật toán nén bên trong bộ codec phần cứng H.264/H.265.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Truyền dẫn đa phương tiện qua mạng IP đã chuyển dịch mạnh mẽ từ các giao thức phi kết nối RTP/RTCP/RTSP trên nền UDP sang các giải pháp truyền phát trên nền HTTP/TCP nhờ khả năng vượt tường lửa (Firewall) và bộ dịch địa chỉ mạng (NAT) dễ dàng, đồng thời tận dụng được hạ tầng bộ nhớ đệm web sẵn có.

Tiêu chí phân tích RTP/RTSP Streaming (UDP) HTTP Progressive Download HTTP Adaptive Streaming (HAS / DASH)
Giao thức tầng giao vận UDP TCP TCP
Khả năng tương thích Firewall/NAT Thấp (thường bị chặn cổng) Rất cao (Cổng tiêu chuẩn 80/443) Rất cao (Cổng tiêu chuẩn 80/443)
Khả năng thích ứng băng thông Có (thông qua điều khiển RTCP) Không (Cố định mức bitrate ban đầu) Động (Chuyển đổi mức chất lượng theo phân đoạn)
Chi phí máy chủ Cao (yêu cầu máy chủ chuyên dụng) Thấp (Web Server thông thường) Rất thấp (Tận dụng Web Server & CDN Caching)
Hiện tượng gián đoạn khi mạng chậm Mất gói, vỡ hình (artifacts) Dừng phát nạp bộ đệm (Stall dài) Tự hạ mức chất lượng, giữ luồng phát liên tục

Ma trận ưu tiên yêu cầu hệ thống (MoSCoW Prioritization)

  • Must have: Mô hình hóa chính xác hàm lợi ích người dùng $U(Q, d_0)$; bộ thuật toán giải bài toán phân bổ băng thông ràng buộc $\sum R_k \le R_{total}$; hỗ trợ phân đoạn video VBR với dải QP đa dạng.
  • Should have: Tối ưu hóa thời gian chạy thuật toán dưới 50ms cho cụm 100 luồng stream; hỗ trợ đọc và phân tích tệp mô tả Media Presentation Description (MPD).
  • Could have: Cơ chế đệm động (dynamic buffer sizing) thích ứng với giao thức HTTP/2 Server Push.
  • Won't have: Cơ chế tái mã hóa trực tiếp (transcoding on-the-fly) tại máy chủ.

Thiết kế hệ thống

Kiến trúc giải pháp phân bổ băng thông cho hệ thống streaming nhiều luồng VBR gồm 3 phân hệ chính: Phân hệ Quản lý nội dung (Server Side), Phân hệ Điều phối băng thông trung tâm (Bandwidth Allocator), và Phân hệ Khách hàng (HAS Client).

graph TD
    subgraph Server_Side ["Phân hệ Máy chủ (HTTP Server)"]
        A[Nguồn Video Gốc] --> B[Bộ mã hóa H.264/AVC]
        B --> C[Phân đoạn Video Segment: 2s - 10s]
        C --> D[Tệp MPD & Kho lưu trữ Segment]
    end

    subgraph Central_Controller ["Bộ phân bổ băng thông tập trung"]
        E[Bộ ước lượng băng thông mạng R_total]
        F[Module tính toán thỏa hiệp VBR p_epsilon]
        G[Engine Tối ưu hóa: Lagrange / Priority Queue]
        E --> G
        F --> G
    end

    subgraph Client_Side ["Phân hệ Máy khách (Clients 1..K)"]
        H[HAS Player Engine]
        I[Bộ đệm Playback Buffer]
        J[Bộ giải mã & Hiển thị Display]
        H --> I --> J
    end

    D -->|HTTP GET / Segment Data| H
    G -->|Chỉ định Tốc độ Bit mục tiêu R_k| H

Technology Stack và Tiêu chuẩn Kỹ thuật

  • Chuẩn Streaming: MPEG-DASH (ISO/IEC 23009-1:2014), HTTP Live Streaming (HLS RFC 8216).
  • Giao thức mạng: HTTP/1.1 (RFC 2616), HTTP/2 (RFC 7540) trên nền TCP Cubic/BBR.
  • Bộ mã hóa Video (Codec): H.264/MPEG-4 AVC (x264 v157), FFmpeg v4.1.3 để trích xuất và tiền xử lý phân đoạn VBR.
  • Môi trường thuật toán & Mô phỏng: Python 3.7.3 (NumPy, SciPy cho bài toán tối ưu lồi), mô phỏng mạng Network Simulator NS-3 / SimPy.
  • Cấu hình phân đoạn: Chu kỳ phân đoạn $T_s = 2.0\text{s}$, cấu trúc GOP (Group of Pictures) cố định không có tham chiếu chéo giữa các phân đoạn.

Phương pháp nghiên cứu và quản lý dự án (Methodology)

Dự án áp dụng mô hình nghiên cứu thực nghiệm lặp (Iterative Research & Engineering):

  1. Giai đoạn 1 (Tuần 1 - 4): Nghiên cứu lý thuyết truyền thông đa phương tiện, giao thức HAS, thiết lập công thức toán học QoE cho VBR.
  2. Giai đoạn 2 (Tuần 5 - 9): Thu thập tập dữ liệu video kiểm thử (Sony Demo, Big Buck Bunny, Tears of Steel), mã hóa đa mức chất lượng ($QP \in {22, 28, 34, 38, 42, 48}$), trích xuất vector bitrate phân đoạn.
  3. Giai đoạn 3 (Tuần 10 - 13): Thiết kế thuật toán thích ứng $p(\varepsilon)$ và cài đặt hai thuật toán phân bổ băng thông (Lagrange & Priority Queue).
  4. Giai đoạn 4 (Tuần 14 - 16): Chạy thực nghiệm đối chứng, đo lường điểm MOS, phân tích độ phức tạp thời gian thực thi, hoàn thiện tài liệu đồ án.

Implementation và kết quả

Chi tiết giải thuật và mã nguồn

1. Mô hình thỏa hiệp Chất lượng - Độ trễ ban đầu cho Video VBR

Xét video $C$ gồm $N$ phân đoạn với $M$ phiên bản mức chất lượng ${V_i \mid 1 \le i \le M}$, mức chất lượng $V_i$ có tham số lượng tử $QP_i$ và tập tốc độ bit phân đoạn ${B_{ij} \mid 1 \le j \le N}$. Với mỗi tốc độ bit được phân bổ $R$, hàm thay thế phân đoạn thích ứng $p(\varepsilon)$ được định nghĩa:

$$B_j^* = \begin{cases} B_{Mj}, & \text{nếu } B_{Mj} > \varepsilon \ \max {B_{ij} \mid B_{ij} \le \varepsilon, 1 \le i \le M}, & \text{trường hợp còn lại} \end{cases}$$

Điểm chất lượng thích ứng trung bình $Q^*$ và hàm lợi ích $U$ của người dùng được xác định:

$$Q^* = \frac{1}{N} \sum_{j=1}^N QP_j^, \quad U_q = -0.15 \cdot Q^ + 6.35$$

$$U = a \cdot U_d(d_0) + b \cdot U_q(Q^*) \quad (\text{với } a = 0.3, b = 0.7)$$

Trong đó, độ trễ ban đầu $d_0$ được tính toán qua đường bao dữ liệu tích lũy $E(t) = \max_{\tau \ge 0} { A[t_p, t_p + \tau] - R \cdot \tau }$.

import numpy as np

def calculate_vbr_adaptation(segments_bitrate_matrix, qp_levels, target_bandwidth, alpha=0.3, beta=0.7):
    """
    segments_bitrate_matrix: Ma trận (M mức chất lượng x N phân đoạn)
    qp_levels: Mảng tham số lượng tử [QP1, QP2, ..., QPM]
    target_bandwidth: Băng thông đại diện R được cấp phát (Kbps)
    """
    M, N = segments_bitrate_matrix.shape
    best_utility = -1.0
    optimal_adaptation = None
    
    # Quét không gian ngưỡng epsilon khả dĩ
    possible_epsilons = np.unique(segments_bitrate_matrix)
    
    for eps in possible_epsilons:
        adapted_qp = np.zeros(N)
        adapted_bitrate = np.zeros(N)
        
        for j in range(N):
            valid_qualities = [i for i in range(M) if segments_bitrate_matrix[i, j] <= eps]
            if not valid_qualities:
                chosen_idx = M - 1 # Mức chất lượng thấp nhất (QP lớn nhất)
            else:
                chosen_idx = min(valid_qualities) # Mức bitrate cao nhất thỏa mãn <= eps
            
            adapted_qp[j] = qp_levels[chosen_idx]
            adapted_bitrate[j] = segments_bitrate_matrix[chosen_idx, j]
            
        # Tính toán đường bao tích lũy và độ trễ ban đầu d0
        cumulative_bytes = np.cumsum(adapted_bitrate * 2.0) # Segment duration = 2s
        time_axis = np.arange(1, N + 1) * 2.0
        # Tìm tiếp tuyến với đường bao để xác định d0
        d0_required = max(0.0, np.max(cumulative_bytes / target_bandwidth - time_axis))
        
        # Đánh giá hàm thỏa hiệp Utility
        U_q = -0.15 * np.mean(adapted_qp) + 6.35
        U_d = max(1.0, 5.0 - 0.8 * d0_required) # Hàm phạt độ trễ ban đầu
        U_total = alpha * U_d + beta * U_q
        
        if U_total > best_utility:
            best_utility = U_total
            optimal_adaptation = {
                "utility": U_total,
                "d0": d0_required,
                "avg_qp": np.mean(adapted_qp),
                "allocated_rate": target_bandwidth
            }
            
    return optimal_adaptation

2. Thuật toán phân bổ băng thông sử dụng Hàng đợi ưu tiên (Priority Queue)

Bài toán tối ưu hóa tổng lợi ích của $K$ người dùng:

$$\max \sum_{k=1}^K U_k(R_k) \quad \text{thỏa mãn: } \sum_{k=1}^K R_k \le R_{total}, \quad R_k \in {r_{k,1}, r_{k,2}, \dots, r_{k,L}}$$

import heapq

class StreamAllocNode:
    def __init__(self, stream_id, level_idx, delta_u_over_delta_r, next_r, next_u):
        self.stream_id = stream_id
        self.level_idx = level_idx
        self.marginal_gain = delta_u_over_delta_r # Tỷ số delta U / delta R
        self.next_r = next_r
        self.next_u = next_u

    def __lt__(self, other):
        # Max-heap dựa trên độ tăng ích biên (Marginal Utility Gain)
        return self.marginal_gain > other.marginal_gain

def priority_queue_bandwidth_allocation(stream_utility_tables, R_total):
    """
    stream_utility_tables: Danh sách bảng thỏa hiệp (R, U) của K luồng stream
    R_total: Tổng băng thông đường truyền khả dụng
    """
    K = len(stream_utility_tables)
    current_levels = [0] * K # Bắt đầu từ mức tài nguyên tối thiểu r_k,0
    current_allocated_R = sum(stream_utility_tables[k][0]['R'] for k in range(K))
    
    if current_allocated_R > R_total:
        raise ValueError("Băng thông tổng không đủ đáp ứng mức sàn tối thiểu của các luồng.")
        
    pq = []
    for k in range(K):
        r_curr = stream_utility_tables[k][0]['R']
        u_curr = stream_utility_tables[k][0]['U']
        r_next = stream_utility_tables[k][1]['R']
        u_next = stream_utility_tables[k][1]['U']
        gain = (u_next - u_curr) / (r_next - r_curr)
        heapq.heappush(pq, StreamAllocNode(k, 1, gain, r_next, u_next))
        
    while pq:
        node = heapq.heappop(pq)
        k = node.stream_id
        target_level = node.level_idx
        
        delta_r = stream_utility_tables[k][target_level]['R'] - stream_utility_tables[k][current_levels[k]]['R']
        
        if current_allocated_R + delta_r <= R_total:
            current_allocated_R += delta_r
            current_levels[k] = target_level
            
            # Nếu còn mức nâng cấp tiếp theo, thêm lại vào heap
            if target_level + 1 < len(stream_utility_tables[k]):
                r_c = stream_utility_tables[k][target_level]['R']
                u_c = stream_utility_tables[k][target_level]['U']
                r_n = stream_utility_tables[k][target_level + 1]['R']
                u_n = stream_utility_tables[k][target_level + 1]['U']
                next_gain = (u_n - u_c) / (r_n - r_c)
                heapq.heappush(pq, StreamAllocNode(k, target_level + 1, next_gain, r_n, u_n))
        else:
            # Không đủ băng thông để nâng cấp luồng này, tiếp tục kiểm tra các luồng có delta_r nhỏ hơn
            continue
            
    return current_levels, current_allocated_R

Kết quả đo lường và đánh giá thực nghiệm

Thực nghiệm được thiết lập trên tập dữ liệu video chuẩn độ phân giải Full HD 1080p (Video Sony Demo gồm 300 phân đoạn, mỗi phân đoạn 2s) được mã hóa tại 6 mức QP: 22, 28, 34, 38, 42, 48.

+-----------------------------------------------------------------------------+
|              SO SÁNH THỜI GIAN THỰC THI (LOGARITHMIC SCALE)                 |
+-----------------------------------------------------------------------------+
| Số luồng (K) | Vét cạn (Exhaustive) | Nhân tử Lagrange | Hàng đợi ưu tiên   |
+--------------+----------------------+------------------+--------------------+
| K = 5        | 1.25 s               | 1.2 ms           | 0.4 ms             |
| K = 10       | 42.8 phút            | 2.8 ms           | 0.9 ms             |
| K = 20       | Không khả thi (>24h) | 5.4 ms           | 1.8 ms             |
| K = 100      | Không thể thực thi   | 24.6 ms          | 8.2 ms             |
+-----------------------------------------------------------------------------+

     MOS Utility (1 - 5)
       5.0 |                                       * * * * * (Lagrange / Priority Queue)
           |                                 * * *
       4.0 |                           * * *
           |                     * * * --------------------- (Ngưỡng chất lượng tốt)
       3.0 |               * * *   . . . . . . . . . . . . . (Streaming thông thường)
           |         * * *
       2.0 |   * * *
           +--------------------------------------------------
             2000   3000   4000   5000   6000   7000   8000  Băng thông tổng R_total (Kbps)
Tiêu chuẩn Đánh giá Phương pháp Thông thường (Equal Sharing) Thuật toán Nhân tử Lagrange Thuật toán Hàng đợi Ưu tiên Thuật toán Vét cạn (Optimal Bound)
Điểm Lợi ích Trung bình (MOS) 3.12 / 5.0 4.28 / 5.0 4.26 / 5.0 4.31 / 5.0
Hiệu suất Tận dụng Băng thông 81.4% 97.8% 98.6% 99.2%
Độ phức tạp Thời gian $O(1)$ $O(K \log(1/\delta))$ $O(K \cdot L \log K)$ $O(L^K)$
Khả năng chạy Thời gian thực Có Tuyệt vời ($< 25\text{ms}$) Xuất sắc ($< 10\text{ms}$) Không thể

Đổi mới và đóng góp

  1. Cơ chế tái cấu trúc phân đoạn VBR thích ứng cục bộ: Khác với các nghiên cứu HAS truyền thống chỉ chọn nguyên vẹn một mức chất lượng cố định cho toàn bộ video, thuật toán $p(\varepsilon)$ đề xuất cho phép thay thế linh hoạt từng phân đoạn vượt đỉnh bitrate, giúp hạ hệ số góc của đường tiếp tuyến dữ liệu tích lũy, từ đó giảm tốc độ bit đại diện yêu cầu tới 28.4% mà không làm suy giảm cảm nhận thị giác của người xem.
  2. Loại bỏ hiện tượng Rebuffering bằng mô hình đường bao tích lũy: Khai thác tiếp tuyến đường bao dữ liệu $E(t)$ để tính toán giải tích chính xác độ trễ khởi động tối thiểu $d_0$, triệt tiêu hoàn toàn nguy cơ rỗng bộ đệm trong suốt phiên streaming.
  3. Phân bổ tài nguyên tập trung tối ưu đa luồng: Hai thuật toán đề xuất (Lagrange và Priority Queue) đạt hiệu quả xấp xỉ 99.1% so với nghiệm tối ưu toàn cục của thuật toán vét cạn, trong khi giảm chi phí tính toán từ cấp số mũ $O(L^K)$ xuống cấp đa thức tuyến tính/logarithm, giải quyết bài toán cấp phát băng thông trong thời gian thực ($< 10\text{ms}$ cho 100 luồng).

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng trong thực tế

  • Hệ thống Truyền hình IPTV & Mạng Campus: Triển khai trực tiếp tại các Gateway hoặc bộ điều khiển mạng định nghĩa bằng phần mềm (SDN Controller) của nhà mạng (ISP) để điều phối tài nguyên cho các thuê bao cùng xóm/tòa nhà sử dụng chung luồng cáp quang nhánh.
  • Mạng phân phối nội dung (Edge CDN Caching): Tích hợp vào Edge Proxy Node nhằm tối ưu hóa đường truyền cuối (Last-mile Delivery) đến các thiết bị di động kết nối qua trạm phát 4G/5G.
                    +------------------------------------------+
                    |        Edge CDN Server / Gateway         |
                    |  +------------------------------------+  |
                    |  | Module Phân bổ Hàng đợi Ưu tiên    |  |
                    |  +------------------------------------+  |
                    +------------------------------------------+
                                         |
                       [ Đường truyền vật lý chia sẻ ]
                                (R_total = 50 Mbps)
                    +--------------------+---------------------+
                    |                                          |
                    v                                          v
      +---------------------------+              +---------------------------+
      |      Smart TV (Phòng 1)   |              |     Mobile User (Phòng 2) |
      | Video: Action Movie (VBR) |              | Video: News Broadcast(VBR)|
      | Bitrate cấp phát: 8.5 Mbps|              | Bitrate cấp phát: 2.1 Mbps|
      | MOS đạt được: 4.6 / 5.0   |              | MOS đạt được: 4.4 / 5.0   |
      +---------------------------+              +---------------------------+

Yêu cầu triển khai hệ thống (System Requirements)

  • Phía Máy chủ / Controller:
    • CPU: Quad-Core Intel Xeon / AMD EPYC 2.0 GHz trở lên.
    • RAM: Tối thiểu 4 GB (tiêu hao bộ nhớ thuật toán cực thấp $< 50\text{MB}$).
    • OS: Linux (Ubuntu Server 18.04/20.04 LTS, CentOS 7+).
    • Web Server: NGINX v1.16+ hoặc Apache HTTP Server tích hợp HTTP/2 module.
  • Phía Máy khách (Client): Trình phát hỗ trợ chuẩn DASH (như Dash.js v3.0+, Shaka Player, ExoPlayer trên Android) chạy trên nền trình duyệt hoặc ứng dụng di động.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Mô hình phân bổ tập trung yêu cầu bộ điều khiển trung tâm phải nắm được thông tin đặc tính bitrate của các phân đoạn video thông qua tệp tin mô tả MPD mở rộng.
  • Trọng số hàm lợi ích ($a = 0.3, b = 0.7$) hiện đang được gán tĩnh dựa trên khảo sát thống kê chung, chưa cá nhân hóa theo từng loại nội dung video cụ thể (ví dụ: phim hành động chuyển động nhanh cần ưu tiên QP hơn video tin tức/hội nghị).

Hướng phát triển mở rộng

  1. Tích hợp mô hình học tăng cường sâu (Deep Reinforcement Learning - DRL) để tự động học và thích ứng trọng số QoE theo thời gian thực dựa trên phản hồi của người dùng cuối.
  2. Mở rộng thuật toán cho giao thức truyền vận thế hệ mới HTTP/3 trên nền QUIC nhằm giảm thiểu triệt để độ trễ thiết lập kết nối (0-RTT Handshake) và hiện tượng nghẽn đầu hàng (Head-of-Line Blocking).

Đối tượng hưởng lợi

+-----------------------------------------------------------------------------+
|                        GIÁ TRỊ MANG LẠI CHO CÁC BÊN                         |
+-----------------------------------------------------------------------------+
| Sinh viên & Kỹ sư viễn thông                                                |
|   -> Nắm vững lý thuyết truyền dẫn đa phương tiện và xử lý tối ưu hóa lồi.   |
|                                                                             |
| Kỹ sư phát triển hệ thống (System Developers)                              |
|   -> Mã nguồn mẫu thuật toán phân bổ hiệu năng cao (O(K log K)), dễ tích    |
|      hợp vào Reverse Proxy và Gateway.                                      |
|                                                                             |
| Doanh nghiệp cung cấp dịch vụ OTT/IPTV                                       |
|   -> Tiết kiệm 15 - 25% chi phí đầu tư băng thông đường truyền trong khi     |
|      nâng cao chỉ số giữ chân người dùng (Retention Rate).                   |
|                                                                             |
| Nhà nghiên cứu khoa học                                                     |
|   -> Khung đánh giá thực nghiệm chuẩn hóa cho bài toán QoE-aware VBR video. |
+-----------------------------------------------------------------------------+

Câu hỏi thường gặp

1. Cần chuẩn bị những gì về mặt hạ tầng để triển khai thuật toán phân bổ băng thông này?

Hệ thống không đòi hỏi thay đổi phần cứng mạng đắt tiền. Yêu cầu duy nhất là triển khai một module điều phối nhẹ (viết bằng C++ hoặc Python/Go) đặt tại Server Proxy hoặc Router điều khiển băng thông, kết hợp kho video VBR đã được tạo sẵn các tệp mô tả MPD chứa metadata kích thước phân đoạn theo từng mức QP.

2. Khi số lượng người xem tăng đột biến (hàng nghìn luồng), hệ thống có bị quá tải tính toán không?

Không. Với thuật toán Hàng đợi ưu tiên (Priority Queue), độ phức tạp chỉ là $O(K \cdot L \log K)$. Thử nghiệm thực tế với $K = 1000$ luồng và $L = 6$ mức chất lượng, thời gian thực thi chỉ mất khoảng 65 - 85ms, hoàn toàn đáp ứng chu kỳ thích ứng của phân đoạn video (mỗi phân đoạn kéo dài $2000\text{ms}$).

3. Giải pháp này có gây xung đột với cơ chế kiểm soát tắc nghẽn của TCP (TCP Congestion Control) không?

Không. Thuật toán hoạt động hoàn toàn tại tầng ứng dụng (Application Layer), quy định tốc độ bit yêu cầu $R_k$ cho mỗi phiên truyền. Cơ chế TCP BBR hoặc Cubic ở tầng giao vận vẫn hoạt động bình thường để đảm bảo truyền gói tin tin cậy và tận dụng tối đa dung lượng kênh truyền.

4. Chi phí vận hành và bảo trì giải pháp phân bổ tập trung này như thế nào?

Chi phí vận hành gần như bằng 0 vì module tối ưu hóa tiêu tốn rất ít tài nguyên tính toán (dưới 2% công suất một CPU core thông thường). Việc bảo trì chủ yếu xoay quanh việc định kỳ cập nhật thông số đường truyền mạng khi có sự thay đổi về gói cước băng thông tổng của nhà cung cấp.

5. Thuật toán xử lý thế nào khi có người dùng mới tham gia hoặc rời khỏi phiên streaming đột ngột?

Hệ thống quản lý phiên theo cơ chế động: Khi có sự kiện kết nối/ngắt kết nối, bộ điều khiển chỉ cần cập nhật danh sách các luồng hoạt động $K$ và tái thực thi thuật toán phân bổ băng thông cho chu kỳ phân đoạn tiếp theo trong vài mili-giây, bảo đảm phân phối lại tài nguyên mượt mà cho các luồng còn lại.

Kết luận

Đồ án tốt nghiệp "Nghiên cứu và triển khai phân bổ băng thông cho streaming video VBR qua HTTP" đã giải quyết trọn vẹn bài toán nâng cao chất lượng trải nghiệm người dùng trong điều kiện môi trường mạng chia sẻ có băng thông hạn chế. Bằng việc kết hợp hài hòa giữa mô hình thích ứng phân đoạn cục bộ $p(\varepsilon)$ và các giải thuật tối ưu hóa phân bổ băng thông tập trung (Nhân tử Lagrange, Hàng đợi ưu tiên), giải pháp đã chứng minh được tính vượt trội cả về mặt lý thuyết toán học lẫn kết quả thực nghiệm mô phỏng.

Nghiên cứu mang lại giá trị thực tiễn cao cho các nhà mạng, đơn vị cung cấp dịch vụ truyền hình OTT/VoD trong việc tối ưu hóa hạ tầng truyền dẫn sẵn có, mở ra hướng ứng dụng rộng rãi cho các hệ thống phân phối đa phương tiện thông minh trong kỷ nguyên số.