Share videos at full quality.

From upload to link in four steps

Each step is a separate cloud service, so uploads, processing and playback scale independently.

1. UploadYour browser sends the file straight to private cloud storage. You get the share link at once.
2. QueueThe upload adds a job to a queue, so bursts of videos wait their turn instead of failing.
3. OptimiseA worker repackages the video, or converts it to H.264 and AAC if needed.
4. WatchThe video is served from a global edge cache, so repeat views are quick.

Architecture at a glance

Uploading and watching take different paths, so a burst of uploads never slows down people who are watching.

The optional AI description

After a video is ready, an AI service can write a one-or-two-sentence description. When someone opens the share link, a "Video insights" button appears in the corner and opens a small summary panel with it. This is an extra: ClipShift works exactly the same without it.

• How it worksOnce the video is READY, the worker picks six frames with ffmpeg, joins them into one small picture and sends it to Amazon Bedrock (model: Google Gemma 3 12B). The answer is cleaned up and saved on the video's DynamoDB record.
• Never blocks playbackThe video is marked READY first, and the AI step runs afterwards with short time limits. If the AI is slow or unavailable, nobody waits for it.
• Hides when it failsThe button only appears when a saved description exists. If the AI step fails, refuses or returns nothing useful, viewers see no button and no error.
• Privacy and honestyOnly six reduced frames (no audio, no file) are sent to an AWS-hosted model in Sydney. The panel is labelled as AI-made and can be wrong. It can be closed, and it cannot be asked questions.

What we measured

• about 2 sto repackage a compatible video (2 runs, no re-encode).
• 57 sto re-encode a 60-second HEVC clip on one worker (12 runs, 95th percentile 61 s).
• 0 → 4 → 0workers. Scale-out took about 3 minutes; scale-in came about 7.5 minutes after the last job.
• 6 min 19 sfor 12 clips of 60 seconds to be ready, including the cold start from zero workers.

Measured on 28 October 2026 in ap-southeast-2 (Sydney), with one worker size of 1 vCPU and 2 GB. These are results from our own tests, not guarantees.

Design decisions

• Direct uploadA presigned POST sends the file straight to private storage. Size and type limits are enforced by the policy.
• Asynchronous queueSQS separates uploading from processing, so bursts wait in line instead of failing.
• Scale to zeroStep scaling on queue depth runs 0 to 4 workers. The cost is a cold start of about 3 to 4 minutes.
• Remux firstCompatible H.264/AAC videos are repackaged in seconds. Anything else is converted.
• Fault tolerantDuplicate events are ignored, invalid files are marked failed, and a job that keeps failing moves to the DLQ after 3 tries.
• Graceful shutdownWhen a worker is told to stop, it finishes its current job first.
• Private origin, edge cacheThe bucket stays private behind CloudFront. Links are unguessable and repeat views are cache hits.
• Auto-expiryLifecycle rules and a 7-day expiry delete videos, which limits storage cost and privacy risk.

Built for QUT CAB432 on AWS

ClipShift is a student cloud computing project. Every box below is a real piece of the running system.

CAB432 Cloud ComputingAssessment 3 · Queensland University of Technology

Deployed on AWS Region: Asia Pacific (Sydney), ap-southeast-2. Workers are containerised with Docker.

Amazon Web ServicesDockerPythonFFmpeg

• Amazon S3 · bucketA private bucket. The browser uploads with a presigned POST, so the file never passes through our servers.
• Amazon SQS · queue + DLQEach upload adds a job. Failed jobs move to a dead-letter queue (DLQ) for inspection.
• ECS Fargate · DockerDocker workers run ffmpeg. The image is stored in Amazon ECR.
• Amazon DynamoDBStores each video's state: uploaded, processing, ready or failed.
• AWS Lambda · APIThe HTTP API runs on a Lambda function URL. No servers to manage.
• Amazon CloudFrontEdge cache for playback. An origin access identity keeps the bucket private.
• Application Auto ScalingScales workers from 0 to 4 based on how many jobs are waiting.
• Amazon Bedrock · AIRuns the Gemma 3 model that writes the video description. It is called by the worker only, never by the browser.
• Amazon ECRStores the Docker image of the worker that ECS Fargate starts.
• Amazon CloudWatchLogs and alarms. The alarms drive scaling and flag problems.

Independent student project. It is not an official QUT or AWS service and is not endorsed by either. QUT, AWS and Docker names and logos belong to their owners. Background and logo artwork was created with AI assistance. Video descriptions are generated by an AI model (Amazon Bedrock) and may contain mistakes.