A finished render is not a published video. Projector tracks the trip from one to the other with a field called stream status, and it moves through six values: pending, staged, transcoding, deploying, onstream, and error if the delivery fails. When a job reads onstream, the video is on your streaming or hosting service and people can watch it.
That trip has more steps than most people expect, and each step depends on a different piece of setup. This page explains what each stream status means, what Projector is doing while a job sits in it, and what to check when a job stops moving. If you are new to the product itself, read our overview of what Projector is first. This page assumes you know what it does and want to understand what it is telling you.
Two status fields, two different questions
Every job that Projector handles carries two statuses, and it pays to keep them apart. Render status answers the question “has the video been made?” It runs from ready through queued and processing to done, or to canceled or an error code, as our guide to Que job states explains. Stream status answers a later question: “has the video been delivered?” Our CEO, Arie Stavchansky, describes it as the deployment and distribution lifecycle of a video on its way to a streaming or hosting platform.
Both fields live in the same place, your data source. Projector reads them from a campaign in Que or from a Google Sheet. If you use a sheet, our documentation says two columns are always required, render-status and stream-status. Projector expects to find both.
The part of Projector that watches those fields is called Projection. It is the automation that looks at render and streaming status for each campaign, starts the upload at the right moment on the service you chose, and writes information from that service back into your data source. Once you turn Projection on, it keeps running until you turn it off. That last detail matters more than it sounds. If Projection is off, nothing moves, no matter how healthy the rest of your setup is.
It also helps to know what a single unit of work is called. In Projector, one job within a payload is a mission, and a payload is a collection of one or more missions. A mission can include any or all of five tasks: export the data-merged Autografs to files, transcode the output, deploy it to a storage and streaming platform, log the metadata from those platforms back to your data source, and clean up the scratch files made along the way. Stream status is the running record of where a mission stands in that list.
The six stream states, and what each one depends on
Here are the values as Arie set them out for us, in the order a healthy job passes through them.
pending: waiting to be picked up for streaming or deployment.staged: the output has been prepared for upload.transcoding: the file is being converted for delivery.deploying: Projector is actively uploading or pushing the file to the provider.onstream: the video has been deployed and is live or accessible.error: the deployment failed.
Each of those states leans on a different part of your configuration. So when a job stalls, the state it stalled in tells you which part to open. Below is each state with the setup it depends on.
Pending: is anything watching?
Pending means the job is waiting for Projector to pick it up. Projection decides when that happens, based on the render and streaming status it sees. A job whose video is still rendering has nothing to deliver yet, so it is normal for it to sit here while the render is in progress.
If a job stays pending after its render is done, check three things. Is Projection turned on? Is this Projector running on the right computer? Projector has to be installed and run on the same computer where Templater runs and where Templater’s output files are stored, so a Projector on a laptop across the room cannot see renders made on a render machine. And is the payload pointed at the data source that actually holds this job? A job in a campaign or sheet that no payload is reading will wait forever.
Arie also gave us the current minimum requirements, which are worth confirming on that machine before you dig deeper. Projector needs After Effects 2021 through 2026. On a Mac it needs macOS 11 Big Sur through macOS 26 Tahoe, on Intel or Apple silicon. On a PC it needs Windows 10 or newer, or Windows Server 2016 or newer.
Staged and transcoding: the file gets ready to travel
Staged means the output is prepared for upload. Transcoding means Projector is converting the file into the format you chose for delivery. These two states are where your Transcode settings come into play, and those settings apply to every mission in the payload.
The choices are short but they shape everything downstream. You decide whether to transcode at all, and whether to delete the original after transcoding. You pick a video codec, and that codec decides the file type of the finished video. Our documentation names H.264, the codec used by MP4, as the common choice for streaming, because it keeps quality good even on older or less powerful devices. For 30 FPS web video watched on a computer screen, our guidance puts video bitrate between 3,500 and 6,000 Kbps. Higher means better quality and bigger files. Our pixel format advice is yuv420p, and the exception is video meant for a display that is not an ordinary monitor or phone. For audio, choose AAC whenever the destination is a streaming service, since most of them require it, at 128 as a sensible bitrate.
Two settings here have side effects people miss. The first is size. You can set an output width or height, and Projector keeps the aspect ratio for you. Bigger dimensions mean bigger files, and bigger files cost more to upload, deliver and stream. If you are not sure how your audience watches, leaving size unset is a reasonable default. The second is the poster image and the GIF preview. Both are created in this stage if you ask for them. Streaming services do not use GIF previews at all, so if you make one, archive it, or it has no home. GIFs are useful when you plan to promote the videos on social media or in email, and they take time for every single video, so skip them when the only destination is a player.
A job that sits in transcoding for a long time may simply be working through a large file or a heavy setting. Projector processes missions in parallel, one per worker, where each worker is a processor core on the machine. More cores means more videos moving at once. A payload with hundreds of long videos on a small machine will spend a while here, and that is a capacity question rather than a fault.
Deploying: the handoff to the service
Deploying means Projector is uploading the file to the provider. This is the state that depends most on outside accounts, so it is where credential problems show up. You can authorize more than one streaming service in Projector and choose one for each payload. A single payload cannot send to more than one service, so if the same videos need to land in two places, that is two payloads.
Each supported service needs its own setup before deploying can work.
For Vimeo, Projector works only with paid plans, since Vimeo caps API access, storage and transfers on its free plans. You create an app in Vimeo’s developer area, note its client ID and client secret, and add https://dataclay.com/vimeo-auth as a callback URL. If you plan to use Vimeo embed presets for your branded player, know that they apply only to Unlisted videos.
For JW Player, there is no free account. Projector needs an API key, created under the v2 API credentials in your JW Player dashboard by someone with Admin permissions, plus the ID of the web player you want viewers to use.
For Frame.io, you create an access token in Frame.io’s developer area and note the folder ID, the 32-character string at the end of the address when you open the folder or project. If you are at the root of a project, click Media first to get to it.
When deploying fails, these values are the first suspects: a token that was copied wrong, a key that was replaced, a folder ID from the wrong project, or a free Vimeo account. Check the credentials for the service this payload uses before you check anything else.
Onstream: live, and written back
Onstream is the finish line. The video is deployed and people can reach it. When a mission finishes deploying, Projector writes metadata from the streaming service, the storage service or both back into your data source. That is why the campaign or sheet that started the job ends up holding the result. Your team can read one row and see that the video was made, that it was delivered, and what the service said about it. Our post on getting automated video output into a CMS or DAM covers what to do with finished videos once they exist.
Archiving runs alongside this if you turn it on. Projector can save each video, and its poster and GIF if you made them, to an S3 storage bucket that you provide, with each mission archived separately. Our documentation includes a warning worth repeating here. If you told the Transcode section to archive posters or GIFs but did not enable archiving in the Storage section, Projector skips archiving completely and ignores those settings. The files just never arrive. If your bucket is empty after a run that reached onstream, this is the first thing to check. After that, check that the bucket name matches the name in your AWS console exactly and that the region matches the bucket’s location. The folder is more forgiving. If it does not exist, Projector creates it.
Error: the delivery failed
Error means the deployment failed. It is not a render failure. The video was made. Something stopped it on the way out. So the place to look is the setup for the stage the job was in last, most often the service credentials described above. Mission Control, the part of Projector’s interface that shows each mission’s progress, shows each mission’s status, so it is a quick way to see which missions failed. If someone else needs to see the state of a payload, our documentation suggests taking a screenshot of Mission Control and sending it.
A delivery run, from first render to last onstream
Here is a scenario of our own, built from the documented behavior. A team produces 300 personalized thank-you videos for a customer event. The jobs live in a Que campaign. Templater renders them on one machine, and Projector runs on that same machine, set to send the videos to Vimeo as Unlisted, with a branded embed preset, H.264 video, AAC audio and a poster frame for each one. They also want every video, with its poster, archived to their own S3 bucket.
Before they start, they do three things that save them later. They confirm the Vimeo account is a paid one and that the app’s callback URL is set. They switch on archiving in the Storage section as well as the archive boxes in Transcode, because without it the posters would quietly go nowhere. And they decide against GIF previews, since the only destination is a player and a GIF would add time to every video for nothing.
They turn on Projection. As renders reach done, missions start leaving pending. Mission Control shows a handful at a time in transcoding, one per worker, then deploying, then onstream. Partway through, twelve missions land in error. All twelve failed in deploying. The rest of the payload is fine, which rules out the transcode settings and the renders themselves. A colleague had regenerated the Vimeo client secret that morning for another project. They update the credentials in Projector, put those twelve in a new payload chosen from the same data source, and they reach onstream. The campaign now holds every video’s delivery details, written back by Projector, and the bucket holds every video and poster.
Notice how much the states narrowed the search. Twelve errors in deploying, with everything else healthy, pointed at one thing: the handoff to the service. They did not touch the template, the data or the transcode settings, because the states had already ruled those out.
Where would this run not fit? If the same videos had to go to Vimeo and to a second service, they would need two payloads. If the render machine and the Projector machine were different computers, Projector could not reach the output files. And if they needed different transcode settings for part of the batch, for example a smaller file for one audience, they would split the work into separate payloads, because transcode settings apply to the whole payload. Our comparison of Que and Projector helps if you are still deciding which product handles which part of your pipeline.
The bottom line
Stream status is the second half of the story that render status starts. Render status tells you the video exists. Stream status tells you where it is on the way to your audience. Each value points to the setup it depends on. Pending points to Projection and the machine. Staged and transcoding point to your Transcode settings. Deploying points to the service credentials. Onstream means you are done, and an empty archive after onstream points to the Storage switch. Learn that map once and a stalled delivery stops being a mystery. If you want to see where Projector sits next to Templater and Que, start with the product pages, and if the problem is on the render side, our guide to what happens when a batch fails mid-queue picks up from there.
A few questions come up every time a team first watches a payload go out. Here are our answers.
Frequently Asked Questions
What is the difference between render status and stream status in Projector?
Render status tracks making the video, from ready through queued and processing to done, or to canceled or an error code. Stream status tracks delivering it, from pending through staged, transcoding and deploying to onstream, or to error. Both live in your data source, either a Que campaign or a Google Sheet. If you use a sheet, both columns are required. A job can be done for rendering and still be pending or deploying for streaming, so read the field that matches your question.
Why is my Projector job stuck on pending?
Start by checking that Projection is turned on, since nothing moves while it is off. Then check that the render is actually done, because there is nothing to deliver until it is. Confirm Projector is running on the same computer as Templater and its output files, and that the payload is reading the campaign or sheet that holds the job. Finally, confirm the machine meets the requirements: After Effects 2021 through 2026, and a supported version of macOS or Windows.
What does onstream mean?
Onstream means the video has been deployed to your streaming or hosting service and is live or accessible there. When a mission finishes deploying, Projector writes metadata from the streaming service, the storage service or both back into your data source. So the row or job that started the video ends up holding its delivery details. If you also turned on archiving, the video and any poster or GIF you made are saved to your S3 bucket alongside it.
Why did a job reach onstream but nothing was archived?
Check first whether archiving was enabled in the Storage section. If the Transcode section is set to archive posters or GIFs but Storage archiving is off, Projector skips archiving completely and ignores those settings. Turn on archiving in Storage, choose S3 cloud storage, and enter your credentials. Then confirm the bucket name matches your AWS console exactly and the region matches the bucket’s location. The folder is created for you if it does not exist.
Can one payload send videos to Vimeo and JW Player at the same time?
No. You can authorize several streaming services in Projector, but each payload sends to one of them. If the same videos need to appear on two services, set up two payloads, each pointed at its own service. That also lets you give each payload its own transcode, poster and privacy settings, which is useful when two services or two audiences need different files.
Does Projector work with a free Vimeo account?
No. Projector works only with paid Vimeo plans, since Vimeo caps API access, storage and transfers on its free plans. You also need to create a Vimeo app for Projector, note its client ID and client secret, and add the Dataclay callback URL to it. If deploying to Vimeo fails right after setup, check the account level and the app credentials before anything else.
Should I create GIF previews for every video?
Only if you will use them. Streaming services do not use GIF previews, so a GIF only helps when you plan to promote the videos on social media, embed them on a website or send them in email or messaging campaigns. Each GIF adds time to every video in the payload and needs storage. If you do create them, also archive them, because otherwise they have nowhere to go once the mission finishes.
