Bạn biết tôi qua Upwork? Nếu bạn biết tôi qua Upwork và muốn sử dụng dịch vụ, vui lòng liên hệ qua Upwork. Tin nhắn từ khách Upwork gửi ngoài Upwork sẽ không được trả lời.
Cách giải mã và kiểm tra file SCC hoặc MCC bằng Caption Inspector
← Blog
🎬 Phụ đề & Caption7 phút đọc

Cách giải mã và kiểm tra file SCC hoặc MCC bằng Caption Inspector

💡 Chạy một lệnh Docker để giải mã độc lập file SCC hoặc MCC: tool tạo ba file kết quả - bản giải mã 608 dạng đọc được (-C1.608), decode dịch vụ 708 (-S1.708), và dump hex (.ccd). Đọc file .608 trước: PAC sai hàng hay text rối là dấu hiệu lỗi chuyển đổi cần sửa ngay trước khi giao file cho đài phát sóng.

Ý chính

  • Caption Inspector (Comcast, mã nguồn mở) là công cụ giải mã QC độc lập miễn phí tốt nhất cho file caption broadcast dạng SCC và MCC.
  • Ba file kết quả từ một lệnh: -C1.608 (bản giải mã 608 dạng đọc được với vị trí hàng PAC), -S1.708 (giải mã window và dịch vụ 708), .ccd (dump hex từng byte có chú thích).
  • Luôn thêm -f 2997 cho nội dung 29,97 fps; thiếu cờ này sẽ tạo timecode sai trong output.
  • X trong cột cc_valid của file .ccd là cặp byte không hợp lệ - decoder broadcast sẽ bỏ qua những byte này.
  • File SCC đầu vào cũng tạo thêm sidecar .mcc, nhưng file này chỉ mang các byte tương thích 608, không phải lớp dịch vụ CEA-708 thực sự.

Tại sao cần giải mã QC cho mỗi file caption broadcast?

Một file CEA-608 (SCC) có thể vượt qua kiểm tra định dạng nhưng vẫn giao caption sai hoặc trống cho người xem. Mã hóa byte độc quyền có nghĩa là một lỗi chuyển đổi thầm lặng tạo ra file mở bình thường trong Subtitle Edit nhưng lại giải mã thành text rối hay vị trí hàng sai trên decoder broadcast.

Tôi đã học điều này khi kiểm tra QC file SCC của một khách hàng: text hiện đúng trong bản xem trước của Subtitle Edit, nhưng Caption Inspector cho thấy tất cả caption đang ở Hàng 1 thay vì Hàng 15, nghĩa là chúng sẽ hiển thị ở đầu màn hình trên mọi tivi trong chuỗi phát sóng. Caption Inspector đọc cấu trúc cc_data() thô và hiển thị bản giải mã dạng văn bản thuần, độc lập với cách hiểu của bất kỳ công cụ chỉnh sửa nào. Tôi chạy nó sau mỗi lần export Subtitle Edit trước khi nén file để giao.

Lệnh giải mã QC duy nhất

Pull image một lần, sau đó chạy từ thư mục chứa file caption. Cờ -v mount thư mục đó vào container để các file kết quả xuất hiện cùng với file đầu vào.

docker run --rm -v $(pwd):/data nebulabroadcast/caption-inspector \
  -o /data /data/my-captions.scc -f 2997
  • --rm: xóa container sau khi thoát, không cần dọn thủ công.
  • -v $(pwd):/data: mount thư mục hiện tại thành /data bên trong container.
  • -o /data: ghi tất cả file kết quả vào /data, tức thư mục hiện tại trên ổ đĩa.
  • -f 2997: đặt frame rate 29,97 fps, đúng cho file SCC broadcast Mỹ. Dùng -f 2400 cho nội dung 24 fps. Thiếu cờ này, timecode trong output sẽ sai.

Lệnh tương tự dùng được cho file MCC và caption nhúng trong container MPEG-2 (.ts, .mpg) và MPEG-4 (.mp4). Với source MXF, dùng CCExtractor trước để lấy SCC rồi chạy Caption Inspector trên SCC đó. Để xác minh container video có dữ liệu caption trước khi giải mã, dùng ffprobe:

ffprobe -v quiet -show_streams -select_streams d input.ts

Ba file kết quả cho bạn biết gì?

Đuôi file kết quảNội dungĐọc trước?
-C1.608Bản giải mã CEA-608 Channel 1 dạng đọc được: text trong nháy kép, timestamp, Global Control Codes trong {}, mã vị trí PAC hàng và cộtCó - kiểm tra văn bản chính
-C2.608Tương tự cho Channel 2 (luồng CC2)Nếu Channel 1 trống hoặc bị rối
-S1.708Bản giải mã CEA-708 Service 1: lệnh window (Define Window, Set Pen Location), text, thuộc tính bút và màuVới file MCC - xác minh 708 có text thực
.ccdDump hex có chú thích của các byte cc_data() từng frame, với marker cc_valid và text đã giải mã bên cạnhKhi file .608 có vấn đề - truy vết byte tại đây
.mcc (chỉ với SCC)Các byte 608 gói lại trong container MCC (lớp tương thích, không phải dịch vụ 708 thực sự)Chỉ khi cần handoff dạng MCC - xác minh lại trước khi dùng

Cần tìm gì trong bản giải mã đầu ra?

Mở file -C1.608 trong bất kỳ trình soạn thảo văn bản nào. Một chuỗi caption pop-on sạch trông như thế này:

00:00:08;22
{Resume Caption Loading}
{Preamble Address Code: Row 15, Column 0, White, Normal}
"Hello, and welcome to the program."
{End of Caption}

00:00:11;04
{Resume Caption Loading}
{Preamble Address Code: Row 14, Column 0, White, Normal}
"This is the second caption event."
{End of Caption}

Bốn điều tôi kiểm tra đầu tiên trong file .608:

  • Channel 1 có dữ liệu không? Nếu -C1.608 trống hoặc toàn ký tự rác, kiểm tra -C2.608. Một số công cụ tác giả mặc định ghi CC2 thay vì CC1. Hầu hết thông số kỹ thuật broadcast Mỹ yêu cầu caption chính trên CC1.
  • Text có khớp với kịch bản không? Ký tự thay thế hay chuỗi không đọc được báo hiệu lỗi mã hóa ký tự. CEA-608 chỉ hỗ trợ ký tự Latin - ký tự nằm ngoài bộ ký tự đó sẽ xuất hiện dưới dạng ký hiệu lỗi trong file giải mã.
  • Mã hàng PAC có đúng không? Hàng 15 là hàng dưới cùng của lưới 15 hàng CEA-608; Hàng 1 là hàng trên cùng. Caption ở Hàng 1 xuyên suốt toàn bộ file nghĩa là một bước chuyển đổi đã bỏ dữ liệu định vị và dùng giá trị mặc định.
  • Timecode dùng dấu chấm phẩy không? 00:00:08;22 (dấu chấm phẩy trước số frame) là drop-frame timecode, đúng cho nội dung 29,97 fps NTSC. Dấu hai chấm thay vì dấu chấm phẩy là non-drop-frame, gây trôi caption trên chương trình dài.

Đọc dump hex .ccd

Khi file .608 có vấn đề, mở file .ccd để truy vết các byte thô. Mỗi frame tạo ra một mục như thế này:

00:00:08;22
{F1:94 20}  {Global Control Code: Resume Caption Loading}
{F1:d6 e5}  {PAC Row 15, Col 0, White} "He"

Marker quan trọng nhất là mã hợp lệ ở đầu mỗi cặp hex:

  • F: cặp byte Line 21 / Field 1 hợp lệ (dữ liệu CEA-608). Đây là điều bạn muốn thấy trong frame mang caption.
  • P: byte gói DTVCC / CEA-708 hợp lệ.
  • X: cặp byte không hợp lệ. Decoder broadcast sẽ bỏ qua. Dù chỉ một đoạn ngắn X trong frame mang caption cũng đáng truy vết.

Tự làm được gì và khi nào cần chuyên gia

Toàn bộ quy trình này chạy được trên bất kỳ máy nào có Docker. Pull image một lần (khoảng 50 MB), và decode QC một file tốn dưới 10 giây. Với bản giao hàng broadcast thường xuyên, một script hai dòng chạy Caption Inspector tự động sau mỗi lần export Subtitle Edit bắt được lỗi mã hóa trước khi file vào hệ thống tiếp nhận của đài.

Nơi kinh nghiệm tạo ra sự khác biệt: nếu bản giải mã .608 hiển thị lỗi bạn không truy vết được về bước chuyển đổi cụ thể, hoặc nếu thông số kỹ thuật của đài yêu cầu lớp dịch vụ CEA-708 thực sự đã được xác minh, đây là trường hợp kinh nghiệm với chuỗi tác giả SCC thực sự có ích.

Sidecar .mcc mà Caption Inspector tạo ra từ SCC đầu vào mang các byte 608 trong container 708 (lớp tương thích), nhưng không phải dịch vụ 708 thực sự với window, thuộc tính bút và màu được định nghĩa. Với bản giao hàng phải mang dịch vụ 708 thực sự, con đường đúng là master SMPTE-TT (ST 2052-1) XML. Dịch vụ kiểm tra caption QC của tôi bao gồm cả decode check và xác minh dịch vụ 708 cho bản giao hàng broadcast và streaming Mỹ.

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

Có thể chạy Caption Inspector không cần Docker trên Windows không?

Tệp nhị phân được biên dịch sẵn cần thư viện Linux nên Docker là con đường thực tế nhất trên Windows. Repository GitHub tại github.com/Comcast/caption-inspector có hướng dẫn biên dịch native, nhưng bạn cần FFMPEG 4.0.2 trở lên và tùy chọn MediaInfo CLI. Docker Desktop trên Windows đơn giản hơn trong thực tế.

Sự khác biệt giữa Channel 1 và Channel 2 trong CEA-608 là gì?

CEA-608 Field 1 mang hai channel caption độc lập. CC1 (Channel 1) là luồng chính cho hầu hết nội dung broadcast Mỹ. CC2 (Channel 2) mang luồng phụ, đôi khi là track ngôn ngữ thứ hai hoặc mô tả âm thanh. Caption Inspector ghi mỗi cái vào file riêng: -C1.608 cho CC1 và -C2.608 cho CC2. Hầu hết thông số kỹ thuật broadcast Mỹ yêu cầu caption chính trên CC1.

Tại sao file .608 của tôi chứa ký tự ngẫu nhiên tôi không caption?

Tài liệu Caption Inspector lưu ý rằng các channel có thể chứa "random garbage" không đại diện cho caption hợp lệ. CEA-608 mang các byte null-filler trên mọi field của mọi frame, và những byte đó có thể giải mã thành tổ hợp ký tự vô nghĩa. Dữ liệu caption hợp lệ được neo bởi Global Control Codes như Resume Caption Loading và End of Caption. Text rác mà không có mã điều khiển xung quanh có nghĩa là channel đó mang null filler, không phải caption thực.

File .mcc mà Caption Inspector tạo ra có dùng được như bản giao hàng MCC broadcast không?

Cần thận trọng. Sidecar .mcc từ SCC đầu vào gói các byte 608 gốc trong container MCC, mang lớp tương thích CEA-608 của file 708, không phải dịch vụ 708 thực sự. Một số đài phát sóng và công cụ QC chấp nhận điều này; các công cụ khác xác minh cụ thể dịch vụ 708 có mang window và thuộc tính được định nghĩa đúng không. Nếu thông số kỹ thuật yêu cầu dịch vụ 708 đã được xác minh, hãy bắt đầu từ master SMPTE-TT (ST 2052-1) XML.

Caption Inspector có hoạt động với file MXF không?

Không trực tiếp với Docker image. README cho biết hỗ trợ MOV cần thư viện GPAC được biên dịch vào, và MXF không được liệt kê trong các container được hỗ trợ. Với caption nhúng trong MXF, tôi dùng CCExtractor trước để lấy file SCC (ccextractorwinfull.exe input.mxf -o out.scc), sau đó chạy Caption Inspector trên SCC đã trích xuất.

Nguồn

Written by Dao Huy (Lucas), Vietnamese translator & localization specialist (EN · ZH · FR → Vietnamese). See translation services →

Báo giáWhatsApp