Long-form video becomes a direct model input
Amazon Bedrock has added TwelveLabs Pegasus 1.5, a multimodal model built to understand long-form video and produce structured text. The model accepts a video through an Amazon S3 URI or a base64 payload and can answer questions, summarise events or divide footage into meaningful segments. It does not require customers to create a separate video index before making an inference request.
That direct path can simplify occasional analysis and workflows where content arrives continuously. A media team could create chapter markers, a safety team could locate a defined event and an archive could generate searchable descriptions. The absence of pre-indexing does not remove processing cost, so repeated queries over the same large video should still be compared with an indexed architecture.
Two hours and structured segments broaden the use cases
Pegasus 1.5 increases the supported video duration from one hour to two. AWS lists a maximum S3 object size of 2GB, while a base64 request is limited to 25MB. Customers can describe the segment they want, such as each product demonstration or every change of speaker, and ask the model to return JSON containing start and end times plus a description.
Machine-readable timestamps are useful because downstream software can create clips, populate a catalogue or send a reviewer directly to the relevant moment. Teams should validate that every timestamp actually brackets the claimed event. A syntactically valid JSON response can still contain an incorrect boundary or omit an important scene, particularly when audio, captions and visuals conflict.
Reference images add another retrieval cue
The model can receive reference images with the prompt, allowing a user to search a video for a product, place or visual concept without relying only on a written description. This can help when an object has an unusual appearance or when the same name refers to several things. Reference material should be governed with the same care as the video because it becomes part of the inference request.
Image matching is probabilistic rather than forensic identification. Lighting, angle, occlusion and editing can affect results, and visually similar people or products may be confused. High-consequence uses need a human review of the cited frames. Organisations should also avoid using a general video model as a biometric identification system unless the capability, legal basis and error rates have been separately established.
Bedrock provides a familiar operational route
Pegasus 1.5 is available in US West (Oregon) under the model identifier twelvelabs.pegasus-1-5-v1:0. Developers can call it through Bedrock InvokeModel or the streaming equivalent and pay on demand through AWS Marketplace. AWS reports full English support and partial multilingual capability, which makes language-specific testing necessary before the model is used across an international catalogue.
Using Bedrock centralises access through AWS identity and logging controls, but customers remain responsible for S3 permissions, retention and output handling. A video may contain faces, voices, confidential meetings or licensed material. The execution role should read only the intended objects, and generated metadata should inherit an appropriate sensitivity classification rather than being treated as harmless text.
Evaluation should measure retrieval, not just fluency
A pilot should use representative long videos and score whether the model found each relevant event, whether it introduced false segments and how accurately its timestamps align. Summary quality alone is insufficient: a polished paragraph may conceal that a critical scene was missed. Different prompts and segment definitions should be frozen as regression tests when the model or workflow changes.
Pegasus 1.5 gives Bedrock customers a practical route from raw footage to structured metadata, especially when analysis must begin without a separate indexing pipeline. Its value will depend on evidence at the frame and timestamp level. Organisations that preserve the original video, make outputs reviewable and measure misses as carefully as attractive summaries can use the longer context without confusing model confidence with a complete record.
What teams should test next
Cost planning should include failed and repeated analysis as well as the successful demonstration. Long videos can make prompt experimentation expensive, and a loosely defined segmentation request may need several attempts before its output fits a downstream system. Teams can create a small labelled evaluation library, settle the response schema and validate it before applying the workflow to an archive. They should record model identifier, prompt and source checksum with every result. That provenance makes it possible to reproduce a disputed timestamp, compare later model versions and decide whether existing metadata needs to be regenerated.
Procurement and engineering teams should record the source date, product version, supported region and evaluation conditions before relying on the result. They should then repeat the same representative tests after a model, compiler, connector or policy changes. Published performance and capability claims are useful starting points, but production confidence comes from evidence collected in the organisation’s own environment. A named owner, measurable acceptance threshold and documented fallback turn a promising technical release into a service that can be governed over time.