How source media gets into Pixwel — uploading a file, watching it process and auto-match to a project and asset, and tracking it to a finished file.
Ingesting is how source media enters Pixwel. When you upload a master — a ProRes video, an image, a document — Pixwel creates an ingest that uploads the file, reads its metadata, matches it to the right project and asset, and turns it into a platform file (and any encodes). If the upload relates to an order, the ingest is linked back to that work request.
The Ingests page lists everything being brought into the platform, newest first, so you can watch progress and spot anything that needs attention.
The Ingests list — each row is one uploaded file, with its project, asset, owner, linked work request, and status.
Each row is one uploaded file:
Column
What it shows
Filename
The original name of the uploaded file.
Project
The project it was matched to.
Asset
The asset it was matched to.
Owner
The person who uploaded it.
WR
The linked work request — shown as its tag (for example AUTO, DATE, Banderole, Now), or None if the file isn’t tied to an order.
Uploaded
When it was uploaded.
Size
The file size.
Status
Where it is in processing (see below).
You can narrow the list with the filters along the top — Active, Owner, Status, Project, Asset, Language, and Existing Work Request (has one or not) — search by filename, and choose how many rows to show.
Pixwel reads the filename to figure out where a file belongs. A well-formed name encodes the project, asset, language, usage, and any tags — for example:
From a name like that, Pixwel matches the project (by its file prefix), the asset, the language/country, and the relevant tags, and links the file to the matching work request revision. You can also set or correct the project and asset yourself when an ingest is waiting.
Consistent, correctly-formed filenames are what make auto-matching work. A misnamed file is more likely to land in Waiting for manual matching.
When an ingest succeeds it creates the platform file — and any encodes (transcoded versions) — attached to the matched asset, and links them back to the work request and its tag. In other words, ingesting is how a localized deliverable a vendor produced becomes a real, downloadable file sitting alongside the rest of the asset’s versions.