Solution: Video app

​

Scenario

• Recording and uploading from iOS and Android over unstable mobile networks, with large files resuming after a drop.
• Automatic conversion of every upload, including vertical video, into several qualities for any device.
• Playback in the app’s own player on the web, iOS, and Android, with thumbnails for the feed.
• Moderation of user-generated content before it reaches other users.
• Status updates for the creator while the video processes.
• Delivery limited to the markets where the publisher holds the distribution rights, with regional data handling for the audience.
• Control of costs while the audience and the library grow.

                                  +-----------------------------+
Phone: record --> TUS upload ---> |  Gcore storage              |
                                  |  + transcoding + moderation |--> Gcore CDN --> Web and mobile players
                                  +-----------------------------+    HLS

​

Outcome and benefits

• Reliable mobile upload: the resumable TUS protocol continues from the last uploaded segment after an interruption.
• Any player, any screen: every video is transcoded into an adaptive bitrate ladder, with an HLS link that web and mobile players accept.
• Fast publishing: playback starts when the first rendition is ready, while higher qualities continue to process.
• Built-in moderation: AI tasks detect NSFW content and nudity in uploaded videos via AI-Moderation.
• Usage-based cost: transcoding up to 1080p at 30 FPS is free, while storage and delivery are billed by usage.

​

Architecture

 Mobile app (iOS, Android)                     App back end
 records video                                 (holds the API token)
        |                                           |
        |  1. asks to upload  --------------------> |  creates the video entry
        | <-------- upload server + session token --|  (Gcore API)
        |                                           |
        |  2. TUS upload (resumable)                |
        v                                           |
 +--------------------------------------------+     |
 |  Gcore Video Streaming                     |     |
 |  Storage + transcoding to ABR renditions   | --> |  3. webhook: status
 |  AI moderation (NSFW, nudity)              | <-- |     moderation task
 +--------------------------------------------+     |
        |                                           |
        v                                           |
 Gcore CDN: HLS                                    |
        |                                           |
        v                                           |
 Web and mobile players  <-- playback URLs ---------+

​

Step 1. Create the video entry

• The upload response contains the list of upload servers, of which the app uses one with active: true, and a session token that is valid for 4 hours.
• The back end sends the server, the session token, the video ID, and the client ID to the app, and it keeps the API token on the server. The Gcore Python and Go SDKs wrap these calls.
• The optional client_user_id and client_entity_data fields tag the video with the creator, and the video list can be filtered by them.

​

Step 2. Upload from the phone with TUS

• The app sends the upload to Gcore and never handles the API token. When the session expires or the upload server rejects it, the app asks its own back end for a new session.
• Gcore accepts many containers and codecs for VOD, including the mobile formats MP4, MOV, and 3GP. The input parameters list the formats and the recommended limits.
• An existing video library enters by URL with origin_url or through the support-assisted batch migration.

​

Step 3. Transcode and track the status

• A video is viewable when at least one rendition is ready, and the manifest returns 404 before that. Lower qualities finish first, so the app publishes the video at viewable and the player adapts as more renditions appear.
• A video is ready when all renditions are complete, and each rendition in converted_videos has its own status and error description.
• Webhooks report every status change of a video to one endpoint, which support configures. Each event is sent once and is not retried, so the back end checks the video through the API after downtime.

​

Step 4. Moderate user content (optional)

• The back end creates a moderation task for the uploaded video through the API and reads the result when the task completes.
• Each result lists the flagged frames with a confidence score, and Gcore excludes results below 30%. The app decides the threshold at which a video is blocked or sent to a human reviewer.
• The analysis runs on keyframes, so an object that appears only between keyframes isn’t detected.
• The back end keeps the video hidden until the check completes and then sets its visibility in the app’s own database.

​

Step 5. Play on web and mobile

• On the web, the app plays the HLS URL in hls.js, and Safari plays it natively.
• On iOS and Android, the app passes the same HLS URL to the native player.

​

Step 6. Add thumbnails and subtitles

• The first automatic screenshot is often black, so the app lets the creator choose another screenshot with screenshot_id or upload a poster.
• AI subtitles transcribe the audio automatically. The subtitles are available through the API.

​

Step 7. Manage videos and creators

• The API changes the name, description, and poster of a video and moves it between directories, which can represent categories or channels.
• Deleting a video removes its renditions, subtitles, and screenshots permanently, and Gcore sends a video_delete webhook, as described in delete videos. Storage is billed at the peak of the month, so a deletion lowers the next month’s value only.
• The source file of an existing video can’t be replaced, so an edited video is uploaded as a new entry and the app points the feed to the new ID. Gcore deletes the uploaded original after transcoding, so an app that offers re-editing keeps its own copy.
• Each video has its own video ID, which is attached to the video and cannot be changed. The source file of an existing video can’t be updated either, so to replace a video, the app deletes the previous one and uploads a new one, which gets a new video ID.
• The account model keeps all creators in one Gcore account, because strict isolation exists only between separate accounts, and client_user_id separates creators inside the app.

​

Step 8. Restrict and protect videos

• The back end signs the playback URL after it checks the viewer, and one secure token covers the manifest and all segments of the video.
• The custom CDN resource adds country, referrer, IP, and user-agent policies on top of tokens. A country policy allows delivery only in the markets where the publisher holds the distribution rights, and a change takes about 5-15 minutes to apply.

​

Step 9. Plan costs and scale

• A trial account has limits on storage, transcoding, and delivery, so the app switches to the active PAYG plan before launch.
• The processing queue has no length limit, and the processing time grows with the video length, from seconds for a short clip to tens of minutes for a long recording.
• Enterprise plans add committed volumes, premium encoding, and premium support for dedicated events, which the account manager arranges.
• Statistics for unique viewers and watching duration are measured at the CDN for any player and can be filtered by client_user_id, while likes, comments, and feed ranking stay in the app’s own database.

​

Availability summary