Khám phá Learn Stream About Jokes
INSIDER Tony's Friends — Insider — ~2 playbook/tuần, Discord riêng, tài nguyên dựng sẵn Tham gia →
Bài viết

Khi video trở thành perception layer cho auto-edit

Giá trị thật của video-analyzer không phải biến video thành thứ để search, mà thành signal có timestamp để một pipeline khác tự ra quyết định cắt. video-analyzer lo perception, Claude Code lo judgment, ffmpeg lo execution.

Khi video trở thành perception layer cho auto-edit

Khi video trở thành perception layer cho auto-edit

Giá trị thật của video-analyzer không phải là biến video thành thứ để mình đọc và search, mà là biến footage thô thành signal có timestamp để máy khác tự ra quyết định edit.


Mình từng nghĩ sai về “video thành text”

Có một cách rất dễ để nhìn những tool như video-analyzer: mình đưa video vào, nó trích keyframe, chạy Whisper, rồi nhả ra một file analysis.json; từ đó con người có thể đọc, search, grep, tìm đoạn cần xem lại. Cách nhìn đó không sai, nhưng nó nhỏ quá. Nó vẫn đặt con người ở giữa vòng lặp, vẫn giả định việc chính là mình cần hiểu video nhanh hơn.

Điều đáng chú ý hơn là analysis.json không chỉ là một bản tóm tắt cho người đọc. Nó là một lớp perception. Nó ghi lại những gì model nhìn thấy trong các frame được chọn, transcript có segment và word timestamp từ Whisper, metadata về cách video được xử lý, rồi một video_description cuối cùng được reconstruct từ tất cả những signal đó. Nói cách khác, video bắt đầu có một lớp output machine-readable bên cạnh pixels và audio.

Perception layer biến video thành signal để script khác hành động

Khi đã nhìn như vậy, use case “search trong video” chỉ còn là cửa vào. Search nghĩa là con người hỏi: đoạn nào có pricing, đoạn nào có demo, đoạn nào có slide này. Nhưng nếu file JSON đã có timestamp, transcript, mô tả visual, scene/action clues, thì một script khác có thể đọc nó và hành động luôn. Và hành động mạnh nhất, theo mình, là auto video editing.

Ba vai phải tách riêng

Điểm làm mình thấy mô hình này rõ hơn là đừng bắt một tool làm tất cả. video-analyzer không cần trở thành editor. Nó chỉ cần làm perception tốt: cái gì đang xảy ra, ở khoảng nào, frame nào có scene change, transcript nói gì, đoạn nào có action nhìn thấy được.

Claude Code, hoặc một LLM script tương tự, giữ vai editorial judgment. Nó không nhìn video gốc theo nghĩa timeline editor truyền thống; nó đọc analysis.json, đọc brief của mình, rồi phán đoán đoạn nào đáng giữ. Phán đoán ở đây không phải regex. Nó là kiểu quyết định mềm: đoạn này nói đúng chủ đề nhưng mở hơi cụt, đoạn kia có câu hay nhưng visual đang transition, đoạn này cần nới thêm vài giây vì action bắt đầu trước lời nói.

Còn ffmpeg là execution. Nó không cần hiểu gì. Nó chỉ nhận -ss, -to, input file, output file, rồi cắt thật. Pipeline trở thành: video dài đi vào video-analyzer, sinh output/analysis.json; Claude Code đọc JSON và rule của mình, xuất cut list dạng [{start,end}]; ffmpeg splice thành video đã edit. Không có ai ngồi tua tay từng đoạn.

video-analyzer workshop.mp4 \
  --output output/workshop \
  --whisper-model large \
  --language en \
  --keep-frames

Sau lệnh đó, thứ quan trọng không phải là một bài summary đẹp. Thứ quan trọng là output/workshop/analysis.json đã trở thành API nội bộ của footage. Một process khác có thể consume nó như consume log, event stream, hay bất kỳ structured artifact nào khác.

Cắt short từ video dài

Use case dễ hình dung nhất là lấy short từ một talk hoặc workshop 90 phút. Brief của mình có thể rất cụ thể: lấy 3 đoạn nói về pricing, mỗi đoạn 30-60 giây, mở và đóng ở ranh giới tự nhiên, tránh cắt giữa câu, ưu tiên đoạn có visual action hoặc slide đổi rõ. Nếu làm tay, mình phải scrub timeline, nghe lại, đánh marker, rồi thử cắt. Nếu làm bằng perception layer, mình đưa brief đó cho Claude Code cùng analysis.json.

Ở đây transcript làm phần “nói gì”. Whisper trong code đang trả segments, và trong mỗi segment có cả words với start, end, probability. Đó là thứ rất hợp để tìm nội dung theo audio và chỉnh cut cho khỏi chém vào giữa chữ. Còn frame analysis làm phần “nhìn thấy gì”. video-analyzer dùng OpenCV để sample video, tính frame diff trên grayscale bằng cv2.absdiff, chọn những frame có thay đổi mạnh, rồi đưa từng frame qua vision model. Mỗi frame analysis được tạo với context từ các frame trước qua token {PREVIOUS_FRAMES}, nên output không hoàn toàn là một loạt caption rời rạc.

Từ góc edit, keyframe diff quan trọng vì nó cho mình ranh giới scene/action tương đối tự nhiên. Một câu nói về pricing có thể bắt đầu ở 1832.4 giây, nhưng nếu frame ngay đó đang fade, camera đang lia, hoặc speaker chưa vào pose ổn, cut sẽ cụt. Claude Code có thể đọc transcript để biết đoạn nào đúng chủ đề, rồi nhìn các timestamp visual gần đó để nắn start/end về scene change gần nhất.

Một cut list có thể đơn giản như thế này:

[
  {"start": 1830.8, "end": 1884.2, "reason": "pricing model setup"},
  {"start": 2412.0, "end": 2465.5, "reason": "enterprise pricing objection"},
  {"start": 3188.6, "end": 3242.0, "reason": "clear pricing takeaway"}
]

Rồi execution là phần nhàm chán nhưng đáng tin:

ffmpeg -ss 1830.8 -to 1884.2 -i workshop.mp4 -c copy clip-01.mp4
ffmpeg -ss 2412.0 -to 2465.5 -i workshop.mp4 -c copy clip-02.mp4
ffmpeg -ss 3188.6 -to 3242.0 -i workshop.mp4 -c copy clip-03.mp4

--keep-frames đặc biệt đáng bật trong pipeline kiểu này. Nó giữ lại các JPEG frame đã trích trong output, nên khi một đoạn bị chọn, mình có thể audit ngược: model chọn đoạn này vì transcript nói pricing, nhưng visual ở frame gần đó có gì? Có đang transition không? Có slide đúng không? Với auto-edit, audit trail quan trọng hơn một UI đẹp.

Auto-edit theo rule của mình

Cắt short vẫn chỉ là một bài toán cụ thể. Cái lớn hơn là auto-edit theo rule. Mình có thể giữ một system prompt đóng vai “chuẩn dựng” của mình: bỏ dead air dài hơn 2 giây, cắt filler như “ờ”, “à” khi không làm mất nghĩa, mỗi segment phải mở trên một action nhìn thấy được chứ không mở vào transition, tổng bản cut tối đa 8 phút, bỏ các đoạn lạc đề theo transcript, giữ lại những đoạn có setup rồi payoff.

Pipeline auto-edit với video-analyzer, Claude Code và ffmpeg

Điểm hay là rule nằm trong prompt, không nằm trong footage. Nghĩa là cùng một pipeline có thể normalize nhiều footage thô về cùng một house style. Hôm nay là workshop, ngày mai là interview, hôm khác là screen recording có webcam. video-analyzer vẫn emit perception signal. Claude Code vẫn đọc signal đó qua cùng chuẩn editorial. ffmpeg vẫn cắt theo EDL hoặc cut list.

Đây là chỗ mình thấy đáng giá nhất: mình không outsource “gu dựng” cho tool. Mình biến gu dựng thành một prompt có thể chạy lại. Prompt đó không chỉ nói “hãy tìm đoạn hay”, mà nói rõ thế nào là hay trong ngữ cảnh của mình. Một đoạn có nhiều keyword chưa chắc đáng giữ. Một đoạn ít keyword nhưng có moment rõ, mở đẹp, kết gọn, và nối được với narrative chính thì có thể đáng giữ hơn. Đó là judgment, và LLM làm phần đó hợp hơn regex rất nhiều.

Một script ở giữa có thể trông rất thô:

video-analyzer raw.mp4 --output output/raw --keep-frames --whisper-model large

claude-code \
  --system edit-rules.md \
  --input output/raw/analysis.json \
  --output output/raw/cuts.json

jq -r '.[] | "ffmpeg -ss \(.start) -to \(.end) -i raw.mp4 clip-\(.id).mp4"' \
  output/raw/cuts.json

Đoạn trên không phải turnkey product. Nó chỉ minh họa mental model: perception, judgment, execution. Ba phần càng tách bạch, pipeline càng dễ thay. Muốn perception riêng tư thì chạy Ollama local với llama3.2-vision, không cần API key, video không rời máy. Muốn nhanh hoặc scale hơn thì dùng client OpenAI-compatible như OpenRouter hoặc OpenAI với --client openai_api, --api-url, --api-key, --model gpt-4o hay model vision tương thích khác.

Những flag nhỏ nhưng đổi workflow

video-analyzer có vài flag nhìn qua tưởng chỉ là CLI convenience, nhưng khi đem vào auto-edit lại thành control surface. --prompt không chỉ hỏi một câu ở cuối; trong code nó được format thành “I want to know …” rồi inject vào cả frame analysis lẫn reconstruction qua {prompt}. Nếu mình đang làm video sales, prompt có thể bias analysis về objection, pricing, demo moment. Nếu đang làm tutorial, prompt có thể bias về step, error, before/after.

--max-frames giúp giới hạn lượng frame đưa qua vision model. Code chọn candidate theo diff score, rồi khi có max frame thì sample đều trong nhóm selected candidate để coverage tốt hơn thay vì chỉ lấy N frame đầu. --duration hữu ích khi chỉ muốn chạy thử đầu video. --start-stage cho phép resume từ stage 1, 2, hoặc 3, đúng kiểu pipeline dài không muốn làm lại từ đầu. --temperature nên giữ thấp nếu output dùng để máy khác đọc tiếp, vì mình cần consistent signal hơn là văn hay.

Với transcript, --whisper-model tiny..large, --device cuda, và --language quyết định nhiều đến chất lượng cut theo lời nói. Nếu video là tiếng Việt, ép --language vi sẽ sạch hơn auto-detect trong nhiều trường hợp. Nếu đang làm batch lớn, model Whisper nhỏ hơn có thể đủ cho coarse edit; nếu đang cắt sát chữ, large đáng tiền hơn.

Nói thẳng về giới hạn

Pipeline này không phải timeline finish-grade. Timestamp visual đến từ keyframe được sample, chịu ảnh hưởng bởi frames.per_minute, sample interval, và threshold diff trong OpenCV. Nó không nhìn mọi frame. Một scene change nhanh có thể bị miss. Một frame có score cao có thể bị loại nếu bị những frame khác outrank. Với cut thô ở cấp clip, chapter, short candidate, vậy là ổn. Với frame-accurate edit, cắt đúng từng chữ, J-cut, L-cut, beat theo nhạc, thì đây chưa phải lớp cuối.

Cách thực tế hơn là dùng hai loại timestamp đúng việc của chúng. Whisper word/segment timestamp dùng để bám audio: câu bắt đầu ở đâu, chữ kết thúc ở đâu, dead air nằm ở khoảng nào. Keyframe và frame description dùng để bám hình: scene change gần đâu, có transition không, action đã bắt đầu chưa, visual có đủ sạch để mở clip không. Claude Code ở giữa reconcile hai nguồn đó và xuất rough cut.

Vì vậy mình gọi đây là first-pass auto-edit. Nó tạo bản rough cut mạnh, có rule, chạy headless, batch được, và đủ tốt cho repurpose-at-scale. Sau đó con người vẫn có thể review, trim lại, thêm caption, mix audio, chỉnh pacing. Nhưng phần mệt nhất, tức việc dò video dài để tìm đoạn đáng giữ, đã được biến thành một pipeline có thể chạy lại.

Search chỉ là phần nổi

Search vẫn hữu ích. Mình vẫn muốn hỏi “đoạn nào nói về pricing?” hoặc “frame nào có slide roadmap?”. Nhưng khi dừng ở search, mình đang dùng perception layer như một cuốn mục lục. Giá trị lớn hơn là để output của video trở thành machine-actionable. Editing là ví dụ rõ nhất, nhưng cùng logic đó có thể auto-tag media library, trigger alert khi thấy một event, hoặc feed CMS bằng chapter và highlight có timestamp.

Điều mình thích ở cách nhìn này là nó không đòi video-analyzer phải trở thành một app edit hoàn chỉnh. Nó chỉ cần emit signal đủ tốt, đủ có cấu trúc, đủ trace được. Phần còn lại để prompt, script và ffmpeg làm đúng vai của chúng. Khi video đã có perception layer, footage thô không còn là một khối opaque phải mở bằng timeline nữa; nó trở thành input cho automation.

Rule edit nào của bạn đủ lặp lại, đủ riêng, và đủ đáng giá để biến thành một pipeline thay vì tiếp tục ngồi tua tay?

#video-analyzer #perception-layer #auto-edit #ffmpeg #whisper #ai-workflows

Bài viết liên quan

Canary: lớp verify cho autonomous coding

idea

Một autonomous harness lo việc build. Nhưng ai kiểm tra cái nó vừa build, và lần sau mình chạy lại bằng gì? Canary là lớp QA biến mỗi lần agent thử thành một Playwright script chạy lại được.

Harness ép kỷ luật, không thay kỹ sư

idea

Giá trị của một harness cho autonomous coding không nằm ở chỗ 'AI tự code', mà ở chỗ nó bắt mình đi qua những bước một kỹ sư tốt thường bỏ qua khi đang vội. Cái thang đó mới là phần portable.

0:00

Chia sẻ ảnh

Bắt đầu gõ để tìm kiếm...