Text-To-Video-AI: A Python Pipeline That Assembles Shorts From a Topic String

The Problem It Solves: A Topic String In, A Captioned Short Out

Most text-to-video tooling stops at a clip. You get five or eight seconds of generated footage and then you are on your own for the script, the voiceover, the caption timing, the background music and the final cut. Text-To-Video-AI targets the whole assembly instead. The README frames the output as YouTube Shorts, Instagram Reels and TikTok videos, and the usage line is a single argument: python app.py "Your topic here", writing rendered_video.mp4. The intended user is someone who wants a repeatable batch process for short-form video rather than a research notebook for a diffusion model. That distinction matters, because the repository is a Jupyter Notebook project by primary language but the documented entry point is a Python script, and the interesting code is orchestration rather than model inference. If you are looking for a weights-level text-to-video implementation to train or ablate, this is not that. If you are looking for something that takes a headline and returns a vertical file with burned-in captions, the README describes exactly that.

The Pipeline Stages and What Each One Actually Calls

The README lists the stages as features, and read together they describe a linear data flow. First an LLM writes the script, with a provider switch between OpenAI, Groq and Google Gemini. Then text-to-speech renders the voiceover, using EdgeTTS or ElevenLabs. Then speech-to-text recovers word-level timing for captions, using Whisper or Deepgram. B-roll comes from Pexels, described as automatic fetching of relevant background video. Separately, the AI video generation stage calls Muapi, whose base URL is configured as MUAPI_BASE_URL=https://api.muapi.ai and whose model is selected with MUAPI_VIDEO_MODEL. The sample videos in the README describe a concrete combination: local EdgeTTS voiceover, whisper-timestamped local word captions, Suno AI background music, and Veo3 AI B-roll segments. Note what that implies about the speech-to-text stage. Caption timing is derived from the rendered audio rather than from the script text, which is the right call if you want captions that survive TTS pacing, and it costs you a transcription pass. The README also mentions a React/Remotion composition engine behind the sample videos, which is where caption styling and orientation are applied. The README does not document the Remotion layer in any depth, so treat that as an area to read the source for rather than something you can configure from .env alone.

Getting It Running: Prerequisites, .env Keys and the One Command

The README gives a short install path. You need Python 3.8 or newer, FFmpeg and ImageMagick, with a separate INSTALL_WINDOWS.md for Windows users. Then clone, install and copy the environment template: git clone https://github.com/SamurAIGPT/Text-To-Video-AI.git, cd Text-To-Video-AI, pip install -r requirements.txt, cp .env.example .env. After editing .env, run python app.py "Your topic here". The configuration is entirely environment-variable driven, and three keys select the providers: LLM_PROVIDER takes openai, groq or gemini; TTS_PROVIDER takes edgetts or elevenlabs; STT_PROVIDER takes whisper or deepgram. Only the Pexels key is marked as always required, which is a useful signal about how the project is wired: the B-roll stage has no free fallback. Video settings are a single orientation switch, VIDEO_ORIENTATION=portrait for 1080x1920 or landscape for 1920x1080, and the README recommends portrait for shorts. Captions have their own block, with CAPTIONS_ENABLED, CAPTION_FONT_SIZE, CAPTION_FONT_COLOR, CAPTION_FONT_FACE, CAPTION_STROKE_WIDTH, CAPTION_STROKE_COLOR and CAPTION_POSITION, which accepts center, top, bottom, bottom_center, bottom_left or bottom_right. Voice selection for the free path is a single key, EDGETTS_VOICE, with examples such as en-US-JennyNeural and en-GB-RyanNeural. The AI video stage needs MUAPI_API_KEY and MUAPI_VIDEO_MODEL. The README's model list is long and spans vendors: Google Veo variants, xAI Grok, ByteDance Seedance, Wan, LTX, Kling, Vidu, OpenAI Sora and MiniMax. That list is the part most likely to age badly, since it is a catalogue of third-party endpoints rather than anything this repository controls.

Where the Design Bites: API Dependencies, Cost and Thin Documentation

The README states plainly that the premium API is the recommended option, and that is worth taking at face value rather than reading as marketing. The local path is a chain of external services. Pexels is mandatory. The LLM stage needs a key from one of three vendors. Any AI-generated B-roll goes through Muapi, which means per-model pricing and per-model availability that this repository does not set. If you switch MUAPI_VIDEO_MODEL to a higher tier such as a pro or 1080p variant, you have changed your cost profile with one line and no local warning. The free configuration is genuinely free at the voice and caption stages, since EdgeTTS and Whisper are marked as free, but free stops at the B-roll and AI video boundaries. A second limitation is documentation depth. The README documents keys and model names but not the Remotion composition, not the failure behaviour when Pexels returns nothing relevant for an obscure topic, and not what happens when a Muapi job times out mid-render. Third, the project has no retrieved releases, so there is no changelog to check before you upgrade. If you are running this in a pipeline that other people depend on, you are pinning versions yourself. None of these are fatal, but they mean the honest description is a glue layer over paid APIs, not a self-contained generator.

When a Direct API Call Beats This Repository

The obvious alternative is the hosted API the README itself points to at docs.vadoo.tv, which the README describes as no installation required and production-ready. The difference in approach is not quality of output, it is where the orchestration lives. With the local repository you own the script, the voice selection, the caption font and position, the orientation, and the choice of underlying video model, and you can edit any stage. With the hosted endpoint you send a request and receive a video, and you get whatever defaults the service sets. There is a second comparison worth making, which is doing the stages yourself. If you already have an LLM key and a TTS key, the parts of this project that are hardest to replace are the caption timing pass and the Remotion composition, since those are where the visual polish lives. If your output does not need word-level captions, the value of adopting this repository drops sharply and a short script calling your LLM and TTS vendors directly is a smaller thing to maintain. The README's own framing supports that reading: it presents the API as the shortcut and the local install as the option for people who want the pieces.

Licence, Maintenance and Upgrade Surface

The licence is MIT, which is permissive and places few obligations on how you reuse or redistribute the code. It does not cover the services the code calls. Your Pexels usage, your LLM vendor terms, your ElevenLabs or Deepgram terms and the Muapi model terms each carry their own conditions, and those are the ones that will constrain commercial use of the output. Nothing in the README addresses rights in the generated footage or the fetched B-roll, so that is a question for each provider rather than for this repository. On maintenance, the last push recorded is 2026-08-24 and no releases were retrieved, so there is no versioned artifact to track. The practical upgrade surface is the model list. Because MUAPI_VIDEO_MODEL is a string passed to a third-party endpoint, a model being renamed or retired upstream is a breaking change you discover at runtime, not at install time. Treat the supported-model list in the README as a snapshot and re-check it against Muapi's own documentation before you build anything on a specific model name. This is not legal advice; if you plan to publish the output commercially, read the terms of each provider you enable.

Who Should Adopt It, and What to Check First

The fit is narrow and clear. You want narrated vertical shorts produced from a topic string, you are willing to install FFmpeg and ImageMagick, you want to control caption styling through CAPTION_FONT_SIZE and CAPTION_POSITION rather than accept a template, and you are comfortable that the video-generation stage is a paid API call. The project suits that. It does not suit anyone who needs a locally run generative model, anyone who needs documented failure handling before they put it in front of paying users, or anyone who needs a stable pinned release to upgrade against, because none were retrieved. Two setup options sit outside the local install: a Colab notebook, Text_to_Video_example.ipynb, for running in the browser, and the hosted API for skipping setup entirely. Start with the Colab notebook if you only want to see the output shape before installing anything. If you go local, the first thing to confirm is that your Pexels key returns usable footage for your actual topic, since that stage has no fallback and a weak result there will define the video more than any caption setting will.

Editorial conclusion

Adopt it if you want a self-hosted, MIT-licensed assembly line for narrated vertical shorts and you are comfortable editing a .env file and installing FFmpeg plus ImageMagick. Do not adopt it if you expect a model checkpoint you can fine-tune, or if you need frame-level control over the generated footage: the AI video stage is a Muapi API call, so quality and cost track the model string you set in MUAPI_VIDEO_MODEL. Before committing, verify three things in your own environment: that your chosen MUAPI_VIDEO_MODEL is still listed as supported, that your Pexels key returns results for your topic, and that the Whisper or Deepgram timing path you selected produces captions that line up on a full-length render.

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. SamurAIGPT/Text-To-Video-AI on GitHub