在今日, 有着这样一个高星项目, 它是, 输入关键词后, 能借助AI全自动生成短视频的项目, 且是一个有着6.5万Star的开源项目。好多读者问, 这玩意儿究竟是怎样达成的, 其中的各个部件是如何连接而成的?这篇就拆开说。先说整体架构是标准的 MVC 结构三层分得很清楚视图层, 所撰写的呈现在网络上视觉化交互界面部分, 全然纯粹, 无需进行前端代码的编写操作。控制层 接口所有操作都有对应的 RESTModel模型层: 有着核心地位的业务逻辑, 其中涵盖了 AI 调用这一环节, 还有视频处理这一操作, 以及字幕生成这一行为。两个入口• 将webui/Main.py进行操作, 以此来启动Web界面, 该Web界面的端口为8501。• 启动, API服务, 其端口为8080, 由main.py来进行。本质上 Web 界面也是在调 API 只是一个前端壳子。第一关大模型怎么生成文案就在这一块儿, 其抽象的完成状况相当之不错。本项目制定了一个具备一致性的LLM接口, 随后呢, 每一个模型平台分别去予以实现。调用逻辑大概是这样# 伪代码简化版def (, , ): f请你创作一个关于{}的视频脚本。要求- 语言{}- 段落数{}- 每段对应一个视频片段约5-10秒- 只输出旁白文案不要标题和注释.()各异的LLM、、通义千问……均达成同一个接口, 业务层不会察觉到底层运用的是哪一家模型。这般的设计于工程方面极为简洁纯粹, 更换模型无需改动核心代码。按流程来说, 关键词到文案这一步, 一般是整个流程当中速度最快的, 能够在1至2秒钟便可得出结果。第二关素材搜索和匹配在文案生成完毕之后, 系统会从每一段文案之中抽取出关键词, 接着前往素材库进行搜索。支持两个主要来源API, 其质量处于最高水平, 搜索结果精准无误, 然而却需要去注册免费的 API Key。API——备选也是免费的视频量大。搜索的逻辑是依照段落进行的, 假定文案划分成了6段, 那就去搜索6组素材, 每组从中取出多个候选, 随后依据时长的需求来裁剪拼接。要是你存在本地素材目录, 那么系统会针对本地视频文件构建索引, 随机进行抽取且切片, 以此来防止重复运用同一段画面。存在这样一个技术细节是值得去说的, 它发生在这一步——视频时长对齐。每一段文案配音大约是多少秒, 与之对应的视频素材就要裁剪到多少秒, 只有这样最后的拼接在一起总时长才能够对得上。而这个对齐逻辑是通过做才得以实现的:# 视频片段裁剪到指定时长clip ().(0, )第三关TTS 配音这一步是把文案转成语音。项目内置了多个 TTS 引擎Edge TTS微软 Azure, 它是免费的, 其速度快, 同时音质算得上不赖, 并且它还是默认的那个选项, 它具备几十种语音, 其中中英文都涵盖, 而且使用时并不需要去申请API Key。Azure 付费质量更高适合对配音有要求的场景。其他支持接入自定义 TTS 接口。在生成音频以后, 系统会对每段文案所对应的音频时长予以记录, 该时长数据会被传递至后面的字幕生成以及视频对齐步骤, 其中所有时间轴的基准皆是音频。第四关字幕生成字幕这块是整个项目里最有意思的工程设计之一。两种模式权衡不同在 edge 模式下, 是通过直接利用 TTS 生成音频之际的时间戳信息来反向推导字幕的, 它的速度快到极致, 原因是并不需要进行额外的语音识别操作, 且时间戳是由 TTS 服务直接予以提供的。采用 --large-v3 这种方式, 针对生成的音频来开展语音识别工作, 继而去重新生成那种带有时间标记的字幕。尽管过程绕了这么一下子, 也就是先运用 TTS 进行语音的合成, 接着再通过 ASR 识别回去, 然而其具备的优势在于, 字幕和音频之间的对齐精准程度更高, 对于语速出现变化以及停顿等各类情况的处理显得更为自然。对于字幕渲染来说, 所采用的方式是呢: 针对每一个帧, 依据时间戳去判定当下应该要显示哪一条字幕, 之后, 再将对应的文字给绘制上去。而字体、颜色、描边以及其位置, 都是在这一特定步骤当中加以处理的。第五关合成输出所有素材准备好之后 负责把一切拼在一起视频轨 ...音频轨TTS 配音字幕轨逐帧文字渲染叠加在视频上背景音乐单独音轨音量混合最终输出时调用 做编码支持 H.264输出 mp4。这一步会使 GPU 加速NVENC、Intel QSV、AMD AMF生效, 要是有显卡, 那么编码速度会快出许多, 要是没有显卡, 使用 CPU 软编码也能够运行, 只是速度会慢一些。批量生成的实现逻辑这个功能值得单独说因为它不是简单的「跑多次」。每一次进行批量生成的时候, 文案是各自独立重新去生成的, 每一回调用LLM, 得出的结果是不一样的, 素材是各自独立随机抽取的, 配音能够选不同的声线。最终你能够对比多个版本, 挑选出最合适的去发布。任务队列是背后实现时所用到的, 每个生成请求会被投进队列里, 然后以异步并发的方式去执行, Web 界面则会对进度状态进行轮询。整个技术栈的选型逻辑回过头去查看此项项目的技术选型, 每一个步骤都挑选了那种恰恰够用并且具备最小复杂度的方案:组件选型为什么Web 界面纯 不需要前端工程师API异步自带文档 生态最佳视频处理封装 API 友好字幕渲染成熟的图像处理库字体支持全语音识别-的量化加速版速度是原版 4 倍不存在过度设计, 未引入, 也未涉及消息队列, 仅仅只是一个服务去运行所有事情。就个人部署而言, 这属于正确的选择。值得学的地方如果你是开发者 这个代码库有几个地方值得学众多语言模型的抽象表现为, 同一个接口适配十几个模型平台, 此模式的实现具备规范性, 因而能够直接应用于其他项目之中加以使用的。涉及到耗时操作的视频生成, 采用了一项这样的模式, 即运用异步任务去处理, 同时在前述处理过程中, 前端通过轮询进度的方式以获取相关情况, 此模式在众多 AI 类型的应用里面都具备适用性, 这种模式被称为异步任务加上进度推送。具有针对不同硬件的编码参数配置, 存在 GPU/CPU 分支处理, 这般部分的经验积累并不常见的之事, 被应用于参数调整这一过程当中了 , 参数调整是在项目里所进行的。6.在其拥有5万Star的背后, 存在着这样一个全栈应用, 它的工程质量并非处于较低水平。其架构并非复杂, 然而涉及每个环节的选型以及串联, 均做得极为清爽利落。对于那些心怀想要了解「AI应用究竟怎样实现落地」想法的开发者而言, 此代码库相比众多教程, 在价值层面远高出许多。