> For the complete documentation index, see [llms.txt](https://getsquish.gitbook.io/squish/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://getsquish.gitbook.io/squish/th/the-primitive/video-as-address-space.md).

# วิดีโอในฐานะพื้นที่อ้างอิง

**ให้ AI เข้าถึงวิดีโอแบบสุ่มได้** นั่นคือคำอธิบายผลิตภัณฑ์ในประโยคเดียว หน้านี้อธิบายแนวคิดเบื้องหลังว่า: มองเส้นเวลาในวิดีโอเป็น **พื้นที่ที่อยู่** — ระบบพิกัดที่โมเดลสามารถชี้เข้าไปและอ้างถึงข้อมูลได้ — แทนที่จะเป็นสตรีมที่ต้องนั่งดูไล่ไปเรื่อยๆ

## วิดีโอดิบคือสตรีม

คุณเล่นสตรีมได้ แต่คุณไม่สามารถ *อ้างอิงเข้าไปใน* มัน ไม่มีทางส่งตำแหน่งภายในวิดีโอให้โมเดลได้ ไม่มีทางให้โมเดลบอกว่า "ขอเพิ่มจาก *ตรงนั้น*", และไม่มีอะไรให้มันอ้างอิงย้อนกลับไปให้ใครตรวจสอบได้ โมเดลที่รับวิดีโอแบบต่อเนื่องต้องจ่ายต้นทุนทุกวินาที ไม่ว่าวินาทีนั้นจะสำคัญหรือไม่ — และส่วนใหญ่แล้วก็ไม่สำคัญ

## การใส่ไทม์โค้ดในทุกช่องทำให้เข้าถึงเวลาได้โดยตรง

คอนแทกต์ชีต — ตารางกรอบภาพที่สุ่มมาจากคลิป โดยแต่ละช่องประทับไทม์โค้ดแบบสัมบูรณ์ของตัวเอง — ไม่ใช่คอลลาจ มันคือ **ระบบพิกัด**. โมเดลอ่านชีตแล้วได้ที่อยู่ (`1:07`), และตอนนี้ก็สามารถ *อ้างถึงที่อยู่นั้นเพื่อดึงข้อมูล* ช่วงที่อยู่ด้วยความหนาแน่นสูงขึ้น: รัน Squish อีกครั้งเฉพาะ `1:00–1:15` แล้วได้ชีตที่แน่นกว่าในช่วงนั้น โดยแต่ละช่องมีที่อยู่ละเอียดขึ้น ทุกครั้งที่ซูมจะได้ที่อยู่ละเอียดขึ้น และที่อยู่ทุกอันยังอ้างอิงแบบสัมบูรณ์กลับไปยังวิดีโอต้นฉบับ ดังนั้นไทม์โค้ดจากทุกระดับสามารถนำมาอ้างอิงหรือใช้ซ้ำได้โดยตรง

```
squish(video)                          → ชีตภาพรวม (ดัชนี)
อ่านชีต เลือกช่วง           → "จังหวะล้มอยู่ที่ประมาณ 1:07"
squish(video, start=1:00, end=1:15)    → ชีตแบบแน่นของช่วงนั้น
อ่าน ปรับให้ละเอียด ทำซ้ำ                   → ละเอียดได้เท่าที่คำตอบต้องการ
```

คอนแทกต์ชีตคือ *รูปแบบของหน้า*, ไม่ใช่ตัวผลิตภัณฑ์ ผลิตภัณฑ์คือการเข้าถึงเวลาแบบสุ่มสำหรับโมเดลที่มองเห็นได้แค่ภาพนิ่ง

## เครื่องมือ Read สำหรับแกนเวลา

ชุดเครื่องมือของเอเจนต์ทุกตัวมีเครื่องมือ Read สำหรับไฟล์ — `Read(file, offset, limit)` — เพราะไฟล์ใหญ่เกินกว่าจะใส่ในบริบทได้ และไม่มีเอเจนต์ตัวไหนอ่านหนังสือทั้งเล่มจากหน้าแรกถึงหน้าสุดท้าย Squish คือเครื่องมือ Read สำหรับแกนเวลา:

| ไฟล์                  | วิดีโอ                                |
| --------------------- | ------------------------------------- |
| หนึ่งหน้าในไฟล์       | คอนแทกต์ชีต                           |
| หมายเลขบรรทัด         | ไทม์โค้ด                              |
| การอ่านช่วงที่แคบกว่า | การซูมด้วย `จุดเริ่มต้น`/`จุดสิ้นสุด` |
| การอ่านทั้งไฟล์       | การแปลงวิดีโอ → ชีตแบบครั้งเดียว      |

การแปลงแบบครั้งเดียว — เอาคลิปทั้งคลิปมาเป็นชีตเดียว — เป็นเพียงกรณีสุดโต่งเท่านั้น: การอ่านทั้งไฟล์ รูปแบบพื้นฐานทั่วไปคือแบบเจาะช่วงและทำซ้ำได้ ลึกได้เท่าที่คำถามต้องการ เอเจนต์ไม่ควรต้อง "ดู" วิดีโอทั้งเรื่อง มากพอๆ กับที่มันไม่ควรต้องอ่านหนังสือทั้งเล่ม

## การดึงข้อมูลชนะการเล่นซ้ำ

วิดีโอเป็นต่อเนื่อง แต่การให้เหตุผลเป็นแบบกระจายเป็นจุดๆ คำถามส่วนใหญ่แตะเส้นเวลาเพียงส่วนน้อยมาก — เช่น ฉากตัด ช่วงที่ข้อผิดพลาดปรากฏ หรือขั้นตอนที่การประกอบเกิดข้อผิดพลาด สิ่งที่ควรทำคือ **การดึงข้อมูล** (ดึงเฟรมที่คำตอบต้องใช้) แทนที่จะ **การเล่นซ้ำ** (ถอดรหัสทุกอย่างแล้วหวังว่า attention จะพอ) ในเซสชันเอเจนต์จริง มีการระบุตำแหน่งฉากตัดไว้ที่ **0.2 วินาที** โดยการดึง **34 เฟรมแทน 3,088 เฟรม** — ดูขั้นตอนเต็มได้ใน [ลูปการนำทาง](/squish/th/the-primitive/the-navigation-loop.md) ต้นทุนจะเพิ่มตามคำถาม ไม่ใช่ตามความยาวฟุตเทจ

## ขอบเขต: โมเดล = ความหมาย, Squish = กลไก

Squish แปลง *เวลา → เฟรม*, แบบกำหนดแน่นอน มันไม่เคยแปลง *ความหมาย → เวลา*. ไม่มีเอมเบดดิ้ง ไม่มีการค้นหาเชิงความหมาย ไม่มีคำสั่ง "หาจุดหมาย" อยู่ในเอนจิน — และนี่คือหลักการออกแบบ ไม่ใช่ช่องโหว่ ชั้นเชิงความหมายมีอยู่แล้ว: มันคือโมเดลที่เรียกใช้งานอ่านชีตภาพรวม "หาช่วงที่ผู้รักษาประตูกระโดด" คือ *การประกอบ* ที่เอเจนต์ทำ — อ่านภาพรวม เลือกช่วง ซูม — ไม่ใช่ฟีเจอร์ของเอนจิน

เหตุผลนี้มั่นคงถาวร: ทุกสิ่งที่เป็นความหมายซึ่งเครื่องมือสร้างขึ้นจะด้อยค่าลงทุกครั้งที่โมเดลแนวหน้าดีขึ้น แต่การกำหนดที่อยู่แบบแน่นอนจะไม่เป็นเช่นนั้น การทำให้เอนจินอยู่ฝั่งกลไกของขอบเขตนี่เองที่ทำให้มันเล็ก คาดเดาได้ และมีประโยชน์กับทุกโมเดล — รวมถึงโมเดลที่ยังไม่มีอยู่ตอนนี้

## ไปต่อที่ไหน

* [คอนแทกต์ชีต](/squish/th/the-primitive/the-contact-sheet.md) — รูปแบบหน้าจริงๆ เป็นอย่างไร
* [ลูปการนำทาง](/squish/th/the-primitive/the-navigation-loop.md) — ขับเคลื่อนตั้งแต่ภาพรวม → ซูม → อ้างอิง แบบครบกระบวนการ
* [สเปกรูปแบบชีต](/squish/th/reference/sheet-format.md) — รูปแบบมาตรฐานที่กำหนดไว้
* [เริ่มต้นใช้งานเร็ว: CLI](/squish/th/getting-started/quickstart-cli.md) · [เริ่มต้นใช้งานเร็ว: MCP](/squish/th/getting-started/quickstart-mcp.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://getsquish.gitbook.io/squish/th/the-primitive/video-as-address-space.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.