BlueSky video publishing has more moving parts than a normal text post. The copy can be valid, the schedule can be right, and the public post can still look wrong if the video has not processed, if the aspect ratio is missing, or if the app view is still waiting for the final playback asset.
The public BlueSky documentation currently describes an MP4 upload flow through the video service. HLS-style thinking is still useful because creators need to plan around preprocessing, status polling, adaptive playback expectations, and the moment a final BlobRef is safe to attach to an approved post.
Read BlueSky's official video upload tutorial for the recommended upload, poll, and BlobRef publishing path.
The safest video workflow waits for processing
BlueSky's recommended flow is different from the fastest possible uploadBlob path. Instead of publishing first and hoping processing catches up, the safer pattern is to request service auth, upload the video to the video service, poll the job status, and only publish after the returned BlobRef is ready.
- Create a service token scoped for uploadBlob.
- Upload the MP4 to the video service endpoint.
- Poll the job until processing completes or fails.
- Attach the returned BlobRef to the final post record.
- Keep the scheduled post out of the live queue until the asset is ready.
Why videos look blurry or incomplete
Blurry playback can come from low source quality, aggressive export settings, missing dimensions, thumbnail mismatch, aspect-ratio problems, or a viewer seeing an intermediate playback state. A scheduling workflow cannot fix a bad source file, but it can keep bad assets from publishing before review.
For media-heavy launches, treat each clip as a stateful asset: exported, uploaded, processing, accepted, attached, scheduled, published, and verified. Skipping those states is how posts appear with missing cards, odd crops, or temporary playback failures.
HLS-style planning without inventing BlueSky support
Do not submit an HLS playlist to BlueSky unless current platform documentation explicitly supports that path. The public developer docs for this build document MP4 upload to a video service that processes the asset before the final post uses a BlobRef.
The practical HLS lesson is operational: upload early, poll status, preserve aspect ratio metadata, avoid last-minute media swaps, and verify the playback view before a campaign depends on the post.
What to check before scheduling a video post
- The source file opens locally and is the intended final edit.
- The aspect ratio matches the post preview and does not crop key text.
- The video service job returned a successful BlobRef.
- The post copy, facets, links, and alt text still fit the campaign.
- The fallback text-only version is ready if a time-sensitive upload fails.
Use the BlueSky content calendar template to separate video asset deadlines from publishing deadlines so clips are processed before the scheduled post window.
Where ONYX fits
ONYX should be the approval and timing layer, not a blind media uploader. Write the post, attach reviewed media, verify the asset state, schedule only after the video is ready, and keep campaign timing visible in the queue.
That workflow helps creators avoid a common BlueSky problem: treating video publishing as one click when the underlying protocol and app services treat it as upload, process, reference, and publish.