Real-time Object Detection: Lessons from Building a Low-Latency Pipeline

Gần đây, tôi bắt tay vào thực hiện một bài toán tưởng chừng như "Hello World" của ngành Computer Vision - một bài toán tưởng đơn giản nhưng lại cực kỳ khó khi đưa vào môi trường thực tế: Xử lý ảnh thời gian thực (Real-time Object Detection).

Setup phần cứng của tôi khá cơ bản:

• Sensor: Camera Tapo dân dụng (RTSP Stream, max 15 FPS, độ phân giải 720p).
• Compute: PC cấu hình mạnh (GPU NVIDIA) để dev và NVIDIA Jetson Nano để deploy.
• Mục tiêu: Detect vật thể và stream kết quả đi với độ trễ thấp nhất có thể.

Tôi đã nghĩ đơn giản: "Chỉ cần cv2.VideoCapture(), ném frame vào YOLO, rồi cv2.imshow() là xong." Nhưng thực tế đã khiến tôi vỡ mộng nhanh chóng: độ trễ (latency) lên tới 3 giây. Trong thế giới tự động hóa, 3 giây đủ biến một hệ thống từ "có thể sử dụng được" thành hoàn toàn không khả thi trong các ứng dụng yêu cầu phản hồi nhanh.

Bài viết này là nhật ký kỹ thuật về cách tôi đập đi xây lại pipeline này để đạt được độ trễ thấp nhất có thể.

1. Naive approach và những ngộ nhận phổ biến về real-time#

Bước đầu tiên, tôi tiếp cận vấn đề theo cách đơn giản nhất (Naive approach):

import cv2
cap = cv2.VideoCapture("rtsp://admin:pass@ip:554/stream", cv2.CAP_FFMPEG)
 
while True:
    ret, frame = cap.read() # Blocking I/O
    # ... xử lý AI ...
    cv2.imshow("Camera", frame) # Render UI
    if cv2.waitKey(1) == ord('q'): break

Kết quả là hình ảnh hiển thị trễ khoảng 3 giây so với thực tế. Nguyên nhân nằm ở cơ chế Blocking I/O và Internal Buffer:

• Chênh lệch tốc độ (Producer-Consumer Gap): Camera đẩy về 15 FPS (Producer). Nhưng nếu vòng lặp while chỉ chạy được 10 FPS (Consumer) do gánh nặng render UI của imshow hoặc AI, thì 5 frame dư thừa mỗi giây sẽ đi đâu?

• Buffer: Chúng bị nhét vào buffer nội bộ của OpenCV/FFmpeg backend. Buffer này cứ đầy dần lên.

• Hệ quả: Khi gọi cap.read(), tôi không lấy frame vừa mới tới, mà tôi lấy frame đang xếp hàng đầu tiên trong buffer (frame cũ nhất).

Throughput vs. Latency

Để tối ưu hệ thống, cần phân biệt rõ hai khái niệm này:

• Throughput (FPS): Hệ thống xử lý được bao nhiêu ảnh trong 1 giây. (Quan trọng cho Server/Batch processing).

• Latency (Độ trễ): Mất bao lâu để 1 sự kiện thực tế xuất hiện trên màn hình xử lý. (Quan trọng cho Robot/Safety/Interactive systems).

Bạn có thể có 60 FPS (video mượt) nhưng latency 3 giây (video của quá khứ). Đây là tình trạng High Throughput, High Latency.

Vấn đề của OpenCV Blocking I/O#

Pipeline mặc định của OpenCV hoạt động theo cơ chế Blocking:

• cap.read(): Chương trình dừng lại, chờ decode frame tiếp theo trong queue.

• model.predict(): Chương trình dừng lại, chờ AI chạy xong.

• cv2.imshow(): Chương trình dừng lại, chờ render UI.

Nếu camera gửi 30 FPS, nhưng tổng thời gian xử lý của vòng lặp chỉ đạt 10 FPS, thì 20 frame còn lại sẽ bị nhét vào Internal Buffer của OpenCV. Buffer này cứ đầy dần lên, và frame bạn nhìn thấy trên màn hình thực chất là frame đã được gửi từ... 3 giây trước.

Tiêu chuẩn FPS trong các hệ thống xử lý video:

• < 10 FPS: Phù hợp cho các ứng dụng giám sát thụ động, nơi đối tượng di chuyển chậm và không yêu cầu phản hồi tức thời, chẳng hạn như smart parking hoặc phân tích hành vi trong bán lẻ.

• 15–24 FPS: Đây là ngưỡng tối thiểu để mắt người cảm nhận chuyển động là liên tục. Dưới mức này hình ảnh sẽ xuất hiện giật, lag — thường gặp trong các hệ thống CCTV giá rẻ.

• 30–60 FPS: Khoảng FPS này được xem là tiêu chuẩn vàng cho các ứng dụng cần tương tác trực tiếp với người dùng (UI/UX) hoặc các hệ thống hỗ trợ lái xe ở mức cơ bản.

• > 60 FPS: Ở cấp độ này, hệ thống không chỉ phục vụ khả năng nhìn của con người mà còn đáp ứng yêu cầu phản ứng của máy móc. Chỉ một vài mili-giây trễ cũng có thể dẫn tới tai nạn hoặc lỗi sản phẩm — tiêu biểu trong xe tự hành và kiểm định công nghiệp.

Hiện nay, một hệ thống real-time object detection được đánh giá 'tốt' trong môi trường thương mại thường cần đạt 25–30 FPS ổn định trên thiết bị edge tầm trung–cao và trên giao diện người dùng cuối (mobile/web). Mức 10–15 FPS chỉ còn được chấp nhận ở phân khúc siêu rẻ hoặc các ứng dụng cực kỳ không nhạy thời gian.

2. Những giải pháp và Bài học#

Multithreading#

Ý tưởng đầu tiên là tách việc Đọc ảnh và Xử lý ảnh ra hai luồng (Thread) riêng biệt.

• Thread A (Reader): Luôn đọc frame mới nhất từ camera và đẩy vào Queue có kích thước cố định (size=1). Nếu Queue đầy, vứt bỏ frame cũ, ghi đè frame mới.

• Thread B (Processor): Lấy frame từ Queue để xử lý.

Kết quả: Latency giảm đáng kể vì ta luôn chủ động vứt bỏ frame cũ (Frame Dropping). Tuy nhiên, code trở nên phức tạp (Race conditions, Thread safety). Hơn nữa, buffer vẫn có thể bị đầy ở tầng driver/FFmpeg trước khi đến được Python thread của chúng ta.

FFmpeg CLI vs. GStreamer#

Tôi quyết định bỏ qua wrapper OpenCV mặc định để can thiệp sâu hơn vào protocol.

Thử nghiệm FFmpeg (Subprocess):

• Dùng subprocess gọi ffmpeg, ép dùng UDP, flag nobuffer.

• Kết quả: Latency cực thấp (gần như realtime).

• Vấn đề: Triết lý của FFmpeg tối ưu cho Throughput (xử lý càng nhiều càng tốt $\rightarrow$ buffer to). Để ép nó chạy Low Latency cần config rất nhiều tham số và việc pipe dữ liệu raw vào Python khá thủ công.

cmd = [
    "ffmpeg",
    "-rtsp_transport", "udp",           # Dùng UDP giảm trễ
    "-fflags", "nobuffer",              # Tắt buffer nội bộ
    "-flags", "low_delay",              # Enable low latency mode
    "-reorder_queue_size", "0",         # Không sắp xếp lại gói tin
    "-use_wallclock_as_timestamps", "1",
    "-i", RTSP_URL,
    "-f", "rawvideo",                   # Output raw
    "-pix_fmt", "bgr24",                # Định dạng pixel cho OpenCV
    "-"
]

Chuyển sang GStreamer (Chuẩn công nghiệp):

• GStreamer hoạt động theo dạng Pipeline modular, cho phép can thiệp sâu vào từng mắt xích (Element) từ source $\rightarrow$ demux $\rightarrow$ parse $\rightarrow$ decode $\rightarrow$ sink. Đặc biệt, nó hỗ trợ Zero-copy (hạn chế copy dữ liệu giữa CPU/GPU) tốt hơn FFmpeg.

• Các hãng camera lớn (như Hikvision) hay NVIDIA (DeepStream) đều xây dựng SDK trên nền tảng pipeline tương tự GStreamer để tận dụng Hardware Decoding.

• GStreamer là lựa chọn tối ưu cho Low Latency, nhưng learning curve khá cao.

3. Dependency hell khi kết hợp GStreamer và OpenCV#

Đây là phần khiến tôi mất nhiều thời gian nhất. Việc kết hợp GStreamer + Python + OpenCV là một nỗi ám ảnh đối với người mới.

• Conda: Tôi đã thử cài GStreamer bên trong Conda. Kết quả là một thảm họa. Các gói thư viện xung đột liên tục.

• Vấn đề OpenCV-Python: Gói pip install opencv-python trên PyPI mặc định KHÔNG hỗ trợ GStreamer backend. Nếu bạn dùng gói này, code sẽ chạy nhưng không mở được pipeline.

• Ultralytics (YOLO): Khi cài ultralytics, nó sẽ tự động cài đè opencv-python (bản pre-built). Điều này làm hỏng môi trường GStreamer mà tôi đã setup. ¹

Giải pháp:

Thay vì dùng Conda hay Docker (Docker build image debug rất lâu), giải pháp nhanh và ổn định nhất trên Linux là dùng venv kết hợp với packages của hệ thống:

# 1. Cài GStreamer và OpenCV system-wide (Ubuntu)
sudo apt-get install python3-opencv libgstreamer1.0-dev ...
 
# 2. Tạo venv với flag --system-site-packages để kế thừa thư viện hệ thống
python3 -m venv myenv --system-site-packages
source myenv/bin/activate
 
# 3. Lưu ý: Nếu cài ultralytics, hãy check kỹ xem nó có ghi đè opencv không

4. Kiến trúc Pipeline Tối ưu (Stream-to-Stream)#

Để đạt hiệu năng cao nhất, tôi thay đổi kiến trúc:

• Input: GStreamer Pipeline (Input RTSP $\rightarrow$ Appsink).

• Process: OpenCV + YOLO.

• Output: Thay vì imshow (Block main thread), tôi stream kết quả ra một RTSP Server local.

Tôi sử dụng MediaMTX làm RTSP Server (chạy qua Docker). ¹

Phân tích giới hạn tốc độ của từng thành phần (FPS Hierarchy)#

Kết luận từ bảng trên:

• Thành phần chậm nhất (bottleneck) chính là camera 15 FPS $\rightarrow$ toàn bộ hệ thống không thể chạy nhanh hơn 15 FPS dù phần còn lại nhanh đến đâu.
• Inference chỉ tốn ≈1.5 ms/frame trong khi mỗi frame mới chỉ đến sau mỗi ≈66 ms $\rightarrow$ AI rảnh hơn 98% thời gian.
• Vì vậy trong trường hợp này không cần multithreading/multiprocessing phức tạp mà vẫn đạt được real-time và độ trễ cực thấp (< 100 ms end-to-end).
• Khi nâng cấp lên camera 60 FPS hoặc dùng model nặng hơn (YOLO11m/x, RVT, v.v.), lúc đó mới cần tách process hoặc dùng queue + worker để tránh drop frame.

Lưu ý quan trọng: FPS của hệ thống cuối cùng luôn bằng FPS nhỏ nhất trong pipeline. Ở đây chính là 15 FPS của sensor.

The Final Code#

Đây là đoạn code kết hợp OpenCV Wrapper cho GStreamer pipeline, loại bỏ độ trễ:

import cv2
from ultralytics import YOLO
 
def main():
    # RTSP Server local
    rtsp_url = "rtsp://admin:pass@192.168.1.50:554/stream"
    output_url = "rtsp://localhost:8554/stream"
 
    model = YOLO("checkpoints/yolo11n.pt") 
 
    # --- INPUT PIPELINE ---
    # latency=0: Cố gắng giảm trễ buffer mạng
    # appsink sync=false drop=true max-buffers=1: 
    # -> Đây là chìa khóa! Chỉ giữ đúng 1 frame mới nhất, vứt hết frame cũ.
    input_pipeline = (
        f"rtspsrc location={rtsp_url} latency=0 ! queue ! "
        f"rtph264depay ! h264parse ! avdec_h264 ! "
        f"videoconvert ! appsink sync=false drop=true max-buffers=1"
    )
 
    cap = cv2.VideoCapture(input_pipeline, cv2.CAP_GSTREAMER)
    
    if not cap.isOpened():
        print("Error: Cannot open input pipeline")
        return
 
    # Lấy thông số stream
    width = int(cap.get(cv2.CAP_PROP_FRAME_WIDTH))
    height = int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT))
    fps = cap.get(cv2.CAP_PROP_FPS) or 25
 
    # --- OUTPUT PIPELINE ---
    # appsrc -> x264enc -> rtspclientsink
    # tune=zerolatency: Tối ưu encoder cho real-time
    # speed-preset=ultrafast: Hy sinh nén để lấy tốc độ
    output_pipeline = (
        "appsrc is-live=true ! "
        "videoconvert ! video/x-raw,format=I420 ! "
        "x264enc tune=zerolatency bitrate=2000 speed-preset=ultrafast key-int-max=30 ! "
        f"rtspclientsink location={output_url}"
    )
 
    writer = cv2.VideoWriter(
        output_pipeline,
        cv2.CAP_GSTREAMER,
        0, fps, (width, height), True
    )
 
    if not writer.isOpened():
        print("Error: Cannot open output pipeline")
        return
 
    try:
        while True:
            ret, frame = cap.read()
            if not ret: break
 
            # Inference YOLO
            results = model(frame, verbose=False)
            annotated_frame = results[0].plot()
 
            # Stream output đi (Không render GUI)
            writer.write(annotated_frame)
            
    except KeyboardInterrupt:
        print("Stopping...")
    finally:
        cap.release()
        writer.release()
 
if __name__ == "__main__":
    main()

Kết quả rất khả quan: latency giảm xuống dưới 100 ms và gần như không còn overhead đáng kể.

Một vài rủi ro cần lưu ý#

Pipeline ở trên hoạt động rất ổn trong môi trường LAN vì mạng sạch, jitter thấp và hầu như không có packet loss. Tuy nhiên, nếu sau này triển khai ra WiFi yếu, mạng nhiều hop hoặc Internet, sẽ xuất hiện một số vấn đề cần cân nhắc:

• latency=0 không phải camera nào cũng chịu được: GStreamer tắt toàn bộ jitter buffer $\rightarrow$ latency cực thấp, nhưng khi mạng không ổn định sẽ dễ giật hình hoặc mất frame.

• max-buffers=1 drop=true giúp cực thấp trễ, nhưng đổi lại có thể bỏ lỡ sự kiện quan trọng nếu inference thỉnh thoảng bị chậm.

• UDP nhanh nhưng dễ mất gói. Trong LAN thì ổn, nhưng ra WAN/WiFi nhiều nhiễu $\rightarrow$ output sẽ giật hoặc nhảy frame.

• ultrafast + zerolatency của x264 tạo bitrate rất cao, đòi hỏi mạng khỏe. Ở môi trường Internet yếu có thể gây tắc nghẽn và tăng trễ.

5. Kết luận#

Xây dựng một pipeline Object Detection thời gian thực với độ trễ thấp không hề đơn giản như tưởng tượng ban đầu. Qua quá trình này, tôi học được nhiều bài học quý giá về:

• Hiểu rõ về cơ chế buffering và latency trong streaming video.

• Sử dụng GStreamer để kiểm soát pipeline một cách chi tiết.

• Thiết lập môi trường phát triển phù hợp để tránh xung đột thư viện.

• Thiết kế kiến trúc hệ thống phù hợp với giới hạn phần cứng và yêu cầu thực tế.

Hy vọng những chia sẻ này sẽ giúp ích cho các bạn đang gặp khó khăn trong việc xây dựng hệ thống xử lý video thời gian thực. Chúc các bạn thành công!