Defending Chat with YouTube in viva — transcript, timestamps, and fallback

Video RAG adds one layer PDF projects do not have: time. Every answer must cite mm:ss and jump the player there. Examiners who have already seen Chat with PDF will ask how you get transcripts when captions are disabled, how timestamps stay accurate after chunking, and why your system is not just “paste the transcript into ChatGPT.” Have a three-layer fallback story, a citation demo, and a clear PDF-vs-video comparison ready before you walk into the panel.

Opening pitch (45 seconds)

Our project answers questions about a YouTube video using retrieval-augmented generation on its transcript. We fetch captions when available, fall back to Whisper when captions are missing, chunk the transcript while preserving start times, retrieve relevant segments for each question, and show clickable mm:ss citations that seek the embedded player. The LLM only answers from retrieved transcript chunks — it does not invent timestamps.

Practice that pitch until it fits under a minute. Panels for Indian B.Tech / BCA / MCA viva often interrupt early; if the first answer already names transcript, fallback, chunk metadata, and player seek, follow-ups become technical instead of “explain your project from scratch.”

Transcript pipeline — three layers, one story

Layer 1: official captions via a transcript library such as youtube-transcript-api. Layer 2: auto-generated captions pulled with a downloader such as yt-dlp when official captions are empty. Layer 3: download audio and run speech-to-text (commonly Groq Whisper or a similar ASR API) when no caption track exists. Order matters: captions are cheap and fast; Whisper costs money and time. Say that ordering aloud — it shows cost awareness, which examiners treat as engineering maturity.

What to draw on the whiteboard

URL → extract video_id → try official captions → try auto captions → if empty, download audio → Whisper → plain transcript text with optional timing → chunk with start_time → embed → vector index (FAISS or equivalent) → user query → retrieve top-k → prompt LLM with chunks + instruction to cite times → answer + mm:ss links → IFrame seekTo.

Narrate while drawing in under 90 seconds. If you freeze on the board, the panel assumes you memorized a slide, not the pipeline.

Caching and re-fetch policy

After the first successful fetch, cache the transcript keyed by video_id (session memory, disk file, or SQLite). Re-asking questions on the same video should not hit YouTube or Whisper again. Viva answer: “We cache the transcript after ingestion to avoid rate limits and to keep demo latency predictable on college Wi-Fi.”

Rate limits and API keys

YouTube may throttle transcript requests. Whisper needs an API key in environment variables — never commit .env to git. If the panel asks about secrets, show that keys live outside the repo and that the report documents required env vars. Mention a soft max video duration (for example 30 minutes) as a deliberate scope control tied to transcription cost and index size, not as a vague “limitation.”

Timestamp citations — metadata, not LLM guesswork

Each chunk stores at least text, start_time (seconds), and video_id. When retrieval returns chunk 7 starting at 312 seconds, the UI renders [05:12] as a link. JavaScript calls the YouTube IFrame API seekTo(312). Emphasize: the model may paraphrase the spoken content, but the timestamp comes from your chunk store. If an examiner claims “the LLM invents times,” correct them politely with this pipeline fact.

Chunk boundary choices

Common approaches: fixed 30–60 second windows, or sentence/paragraph grouping with overlap. Overlap (a few seconds or one overlapping sentence) reduces answers that miss context at window edges. Store the start time of the first sentence in the chunk. On the whiteboard, draw a timeline with overlapping bars — panels remember visuals better than “we used 500 tokens.”

Player integration details

Explain iframe embed vs downloading the full video: you embed YouTube’s player and seek; you do not redistribute the media file. That distinction supports both architecture and copyright answers. Rehearse the click-to-seek path on the presentation laptop. A citation that does not seek looks worse than omitting the player entirely.

Timestamp demo tips

During viva, ask a question whose answer appears mid-video, click the citation, and wait for the seek. Mute audio if the room is noisy, but keep the player visible so the scrubber position proves the jump. Prepare a second question near the end of the video so the panel sees that early and late times both work.

Multi-video sessions as a differentiator

If your kit or customization supports multiple URLs in one session, retrieval metadata must include video_id so citations open the correct player or switch the active video. Say: “Indexing is per video; the query retrieves across the session index and returns which video each chunk belongs to.” Even if you ship single-video only, mentioning multi-video as scoped future work shows you understand the metadata model.

Comparison to PDF RAG

Both projects share embed → retrieve → generate. Ingestion differs: PDF uses page-bounded text from a parser; YouTube uses timed transcript segments. Citations differ: page numbers vs mm:ss. If a classmate presents Chat with PDF, your viva edge is the fallback chain and player seek — not claiming a brand-new LLM stack. Linking the sibling architecture also helps if the panel asks “why not just use PDF notes of the lecture?” Answer: video Q&A needs time-aligned evidence for lecture review; policy manuals fit PDF better.

For a deeper PDF-side defense, see defending Chat with PDF. For the shared RAG pattern across kits, skim how RAG works once before the panel so vocabulary stays consistent.

Copyright, Terms of Service, and academic framing

Keep the story honest and limited: the system processes a user-provided URL for educational analysis; it does not scrape channels in bulk, host mirrored video files, or claim commercial fair use beyond a college demo. Attribution of the source URL in the UI helps. If live demo uses one rehearsed video, say so — “We validate against a fixed demo URL to avoid random caption failures during the presentation” is engineering hygiene, not cheating.

Shorts vs long-form

YouTube Shorts and long videos can differ in caption availability and length. State what you tested. If Shorts are out of scope, write that in Chapter 1 and refuse them gracefully in the UI with a clear error. Panels sometimes paste a Short just to see whether you panic or enforce scope.

Language support

Whisper multilingual models can transcribe non-English audio; caption APIs may expose a language parameter. Document one language you actually tested (for example English lecture + one Hindi sample if you tried it). Do not claim “all languages” without evidence.

Embedding transcript vs frames

Your scope is text-only RAG on transcript. You are not doing frame OCR, scene detection, or multimodal CLIP over thumbnails unless you built that. If asked why, say transcript answers “what was said”; visual-only content without speech is a known limitation. That single sentence prevents a spiral into computer vision you did not implement.

Failure modes you must rehearse

Captions disabled → Whisper path (warn that it may take 30–60 seconds). Private or age-restricted video → clear error. Very long video → reject with max duration message. Query unrelated to the video → model should say the transcript does not contain that information, not invent a lecture. Empty transcript after all layers fail → stop before embedding; show a user-visible error.

Fallback demonstration

Bring or bookmark one public video with captions off (or simulate by forcing the Whisper branch in a debug flag if the kit supports it). Walking the panel through Layer 3 proves you understand the hardest part of video RAG. Set expectations: “This path downloads audio and calls ASR; it is slower than captions.” Silence during a long Whisper call feels like a hang unless you narrate.

Bandwidth and lab constraints

College Wi-Fi often fails mid-download. Practical mitigations: cache the demo transcript and optionally a local audio file for Whisper rehearsal; prefer captioned demo URLs for the main path; keep a screen recording of a successful seek as backup if the network dies. Saying “offline cache for demo reliability” is a valid engineering decision when asked about deployment.

Extended technical Q&A bank

Q: Video length limit? A: State your configured max (for example 30 minutes) due to transcription cost, ASR latency, and index size. Show where the check lives in code if asked.

Q: Chunk size for transcripts? A: 30–60 second windows or sentence-based chunks with overlap — justify with a tradeoff: smaller chunks improve timestamp precision; larger chunks improve conversational context.

Q: Multiple speakers? A: Standard captions often lack speaker labels; without diarization we treat the transcript as one stream. Future work: speaker diarization before chunking.

Q: Non-English video? A: Name the Whisper model family and one tested example. Captions may already be translated — specify which you used.

Q: Storage? A: Transcript and embeddings cached per video_id for the session or until clear; policy documented in the report.

Q: Why not send the full transcript to the LLM every time? A: Context limits and cost; retrieval keeps only top-k relevant segments, same rationale as PDF RAG.

Q: Evaluation? A: Manual set of 8–10 questions with expected approximate timestamps; check that cited times fall within a tolerance window of the true segment. Undergraduate panels accept this when you document failures too.

Q: Hallucinations? A: System prompt instructs answers only from retrieved chunks; demo an out-of-video question that returns “not in transcript.”

Architecture comparison slide for the presentation

One slide with two columns: PDF ingestion (pages) vs YouTube ingestion (transcript + timestamps). Shared middle box: embed, retrieve, generate. Bottom row: page citation vs mm:ss seek. This slide answers “difference from Chat with PDF” in fifteen seconds and pairs well with the Chat with YouTube kit architecture diagram if you include it in the report appendix.

Report chapter mapping

Chapter 1: problem — lecture/video Q&A with evidence. Chapter 3: requirements — caption fallback, max duration, citation UX. Chapter 4: design — pipeline diagram, chunk schema with start_time. Chapter 5: implementation — libraries, env vars, IFrame seek snippet location. Chapter 6: tests — captioned URL, captionless URL, seek accuracy, out-of-scope question. Chapter 7: limitations — no frame OCR, ToS-aware scope, network dependency.

Carry tabbed printouts if your college allows report reference during viva. Map every spoken answer to a section number when possible.

Live demo script (about four minutes)

1. ▸Paste the rehearsed YouTube URL; show caption path completing quickly.
2. ▸Ask a factual question answered mid-video; read the answer; click mm:ss; confirm seek.
3. ▸Ask a paraphrase question (“what did they say about X?”) to show semantic retrieval, not keyword-only search.
4. ▸Ask something absent from the video; show refusal or “not found.”
5. ▸If time remains, mention or briefly trigger Whisper fallback on a second URL and narrate why it is slower.

Do not improvise a brand-new long video on stage unless you have already verified captions.

Prompting and hallucination control

Your system prompt should require: answer only from provided transcript excerpts; include mm:ss citations that match the chunk metadata you inject; say “not in the transcript” when evidence is missing; avoid inventing speaker names or slide content that never appears in text. Pass retrieved chunks into the user message with explicit time prefixes such as [03:40–04:10] ...text... so the model’s citations align with what the UI will link. If the model cites a time you did not provide, treat that as a bug in prompting or post-processing — some kits strip or rewrite citations to only allow times present in retrieved metadata.

Hybrid search optional note

If you added BM25 alongside vectors (same idea as many PDF kits), explain it briefly: exact phrases from lectures (“Section 4.2”, course codes, API names) often match keyword search better than embeddings alone. If you did not implement hybrid search, say vector-only is sufficient for the demo and name hybrid as future work — do not invent a feature mid-viva.

Customization ideas that stay honest

College name and logo in the Streamlit or web header; a fixed “demo lecture” URL documented in the user guide; bilingual UI labels if your department prefers regional language chrome while keeping English transcripts; exporting Q&A history to PDF for the report appendix. Avoid claiming playlist ingestion, live stream support, or automatic quiz generation from video unless you actually built them. Panels punish feature lists that the demo cannot show.

Group project ownership map

If you split work, one student owns ingestion and fallback, another owns retrieval and prompting, another owns player UI and citations. Everyone must still narrate the full pipeline at overview level — examiners ignore internal “that was his module” excuses. Agree on shared vocabulary: chunk, embedding, citation, fallback layer. Mismatched terms between teammates sound like copy-paste reports.

Common viva mistakes for this project

Saying “Whisper always runs” when captions exist — wastes the cost story. Claiming timestamps are “from the LLM.” Demo with a random trending URL. Ignoring muted-player seek proof. Comparing poorly to PDF by dismissing page citations instead of contrasting metadata types. Overclaiming multi-language or Shorts support. Forgetting to clear a previous session’s index so answers leak from the wrong video.

Pre-viva checklist

• ▸[ ] Demo URL opens and captions path works on the presentation machine
• ▸[ ] Citation click seeks correctly under the projector resolution
• ▸[ ] .env present locally; keys not in screenshots of code
• ▸[ ] Max duration and scope written in report Chapter 1
• ▸[ ] One captionless fallback story rehearsed with time estimate
• ▸[ ] Whiteboard pipeline drawable without notes
• ▸[ ] Sibling PDF comparison one sentence ready
• ▸[ ] Backup: cached transcript or recorded demo clip

Related reading

See also defending Chat with PDF and viva questions for RAG projects.

Project kits

• ▸Chat with YouTube — transcript fallback chain, timestamp citations, and viva-oriented report sections.
• ▸Chat with PDF — baseline document RAG for architecture comparison in multi-project panels.

Takeaway: Defend the chain caption → Whisper fallback → timed chunks → retrieval → mm:ss seek as metadata-backed evidence, not model guesswork. The Chat with YouTube kit documents each fallback layer so you can point to code and diagrams instead of improvising under pressure.