简介面向易语言开发者及多媒体/自然语言处理入门者这份资源提供了一套视频转文本的完整源码方案可直接用于学习与二次开发。项目从视频预处理、关键帧提取入手结合OCR字幕识别与ASR语音转写再通过拼写校正、语句连贯性检查等后处理完整覆盖了从视频到文字的主要技术链路并展示了在易语言中文命令环境下调用外部识别能力、优化参数的方法。压缩包共3个文件包括易语言主程序.e、HTML说明/界面文件和SWF动画演示文件整体大小6.3MB结构紧凑便于对照源码与演示理解。该资源已有194人浏览学习适合希望借助中文编程快速上手媒体处理、字幕生成或会议记录场景的读者。通过研究本项目可获得一套现成的参考实现以及OCR与ASR集成思路对后续扩展与二次开发颇具借鉴价值。1. 为什么用易语言做视频转文本一条比想象中更顺的落地路径很多人一听到“视频转文本”这个概念第一反应是Python加语音识别库。但放在Windows环境里用易语言做这个需求反而是一条被低估的捷径它不需要你搭建Python环境不需要处理一堆第三方依赖只要你会易语言的基础语法就能把一条“视频→音频→文本→字幕文件”的完整链路串起来。这个标题要解决的核心不是“怎么训练一个识别模型”而是“怎么用易语言把现成的工具和接口调度好”。视频转文本的难点从来不在算法而在工程格式怎么转、音频参数怎么设、识别结果怎么解析、长视频怎么分片。这些恰好是易语言通过命令行调用、HTTP请求和JSON解析就能全部搞定的。这条路径适合三类人第一类手里有大量本地视频想批量转出文本或字幕的办公人员第二类用易语言做自动化工具、不想引入第二门语言的开发者第三类想给自己做的播放器或剪辑工具增加字幕导出功能、又不想从零写算法的人。下面我会按“选型→核心代码→参数→避坑→进阶”的顺序把一条能落地、能复制、能踩住坑的方案完整讲透。2. 先把技术路线定下来FFmpeg提取音频、识别引擎怎么选、易语言负责什么用易语言做视频转文本第一件事不是写代码是先把链路里的每个环节拆开搞清楚谁干什么。表面上你只看到“视频进来、文本出去”中间至少隔了三个独立的步骤视频解码抽音频、音频识别成文字、文本按时间戳组装成结果。任何一步出了问题整个流程都会卡住。2.1 易语言在链路里的真实分工易语言在这条链路里扮演的角色不是“识别器”而是“调度器和组装器”。它负责三件事调用外部程序完成格式转换、把音频数据提交给识别引擎、把返回的结果解析成你想要的文本文件。这个定位非常关键很多刚上手的人会在易语言里找“现成的视频转文本命令”找了一圈发现没有于是放弃。方向从一开始就错了——易语言做得最好的部分是控制而不是算法本身。以我常用的架构举例易语言主程序里维护一个任务队列每个任务包含视频路径、输出目录、语言类型、是否需要时间戳这些信息。主程序遍历队列依次执行三个步骤第一步用命令行调用FFmpeg把视频转成符合要求的音频文件第二步把音频文件提交给识别服务第三步轮询识别结果拿到JSON之后解析并回写到TXT或SRT文件。整个过程里易语言只做流程控制和数据搬运识别的精度高低完全取决于你选的引擎和易语言本身没有关系。2.2 识别引擎三选一离线引擎、云端接口、本地服务选对识别引擎这个项目就成功了一半。目前市面上能通过易语言稳定调用的方案大致有三类各有取舍。方案类型代表形式输入要求返回数据适合场景离线开源方案本地命令行工具WAV音频文件纯文本或带时间戳文本内网环境、批量转写、无网络依赖云端APIHTTP接口音频文件或链接JSON格式含文本、时间戳、置信度中文识别率高、需要断句标点本地HTTP服务部署在自建服务器上的识别引擎HTTP请求JSON格式多台机器共用一套识别能力离线开源方案的优势是免费、私有、没有网络延迟但它对中文长音频的支持参差不齐调参逻辑也比较隐蔽网上可查的资料少。云端API识别率最高标点断句做得最好但需要联网而且并发和时长受套餐限制。本地HTTP服务是把某个识别引擎封装成服务易语言通过HTTP请求提交音频、轮询结果本质上等于自己搭了个私有云端。我在一个给内部批量转写视频的模拟项目X里用的是“本地HTTP服务”路线把识别引擎部署在某台Windows服务器上易语言客户端只管提交任务和取结果。好处是识别率有保障稳定性和速度也可控不用受制于第三方平台限流缺点是前期要花半小时部署环境。如果你只是自己用、转写量不大直接离线方案最省事一条路径跑通之后后面基本不用维护。2.3 完整调用链和数据流设计无论选哪种引擎易语言这边的数据流是一样的。我习惯先把链路图画清楚再动手省得代码写到一半才发现某个环节的数据格式对不上。视频文件进入程序后第一时间使用FFmpeg把音轨抽出来这一步的关键是统一音频格式、采样率和声道数。转出来的WAV文件作为识别引擎的输入。识别引擎处理完会返回一个JSON字符串里面包含识别结果、每句话的开始时间和结束时间。易语言拿到JSON后用“解析JSON”类库拆出字段再按需求拼成纯文本或者SRT字幕格式写文件到指定目录。错误处理要点每两个环节之间必须加验证。换句话说FFmpeg转完音频要检查文件是否存在、字节数是否大于一定大小提交识别之后要确认返回的是成功码而不是报错码。很多人第一次跑通全流程靠运气第二次发现某个视频转完音频是0字节程序直接卡死在识别环节就是因为没有在每个环节之间设置关卡。后面第五节我会专门讲这些坑。3. 用易语言写核心控制调用FFmpeg、提交识别、解析回写链路清楚了代码就顺了。这一章把三个核心步骤逐一拆开每段代码都给出可直接复制的骨架。我要事先说明这里的代码是易语言语法不是某个现成源码包的内容它是我在过往项目里反复调过的基础结构按你自己的文件路径和识别服务地址替换就能用。3.1 调用FFmpeg提取音频命令行调用与参数含义易语言调用FFmpeg最直接的方式是通过“运行”命令启动外部进程。提取音频这步的核心参数是采样率、声道数和编码格式。识别引擎最欢迎的是16kHz采样率、单声道的WAV文件这个配置在识别效果和文件体积之间最平衡。以下是代码.版本 2 子程序 提取音频, 文本型, 公开 .参数 视频文件路径, 文本型 .局部变量 命令行文本, 文本型 .局部变量 输出文件路径, 文本型 .局部变量 是否成功, 逻辑型 输出文件名固定为 temp_audio.wav放在程序目录下 输出文件路径 取运行目录 () “\temp_audio.wav” 构造 FFmpeg 命令行 -i 指定输入文件-vn 表示不要视频流-ac 1 单声道-ar 16000 采样率 -y 表示覆盖已有文件避免询问导致卡死 命令行文本 “ffmpeg -i ” 视频文件路径 “ -vn -ac 1 -ar 16000 -y ” 输出文件路径 运行并等待执行完毕参数二为真表示隐藏命令行窗口 是否成功 运行 (命令行文本, 真, 真) 如果运行成功且文件已经生成则返回文件路径否则返回空文本 如果真 (是否成功 且 文件是否存在 (输出文件路径)) 返回 (输出文件路径) 否则 返回 (“”) 如果结束 子程序结束逻辑说明这里用易语言的“运行”命令直接调用FFmpeg命令行被完整拼成字符串由系统命令行解释器执行。特别注意参数二设为了“真”这样可以隐藏控制台窗口避免用户看到一个黑框一闪而过参数三设为“真”表示程序会等待FFmpeg执行完毕才继续向下否则你这边还在转音频那边已经开始尝试读取文件必然失败。参数说明-vn是去掉视频流只保留音频能显著降低处理耗时和输出文件体积-ac 1强制转成单声道很多识别引擎对双声道音频会重复识别或产生回声干扰-ar 16000设采样率为16kHz这是语音识别领域的通用输入标准。如果源视频本身是双声道、48kHz采样率不强制转单声道和降采样识别结果出错时很难排查是引擎问题还是音频问题所以这条转换命令不要随意删减。3.2 把音频提交给识别服务HTTP上传与轮询音频转好之后下一步就是把它提交给识别引擎。如果你的识别方案是云端API这一步需要构造HTTP请求把音频文件作为二进制流POST到接口地址。如果你的方案是本地命令行工具直接调用它并传音频文件路径就行。我以HTTP请求这种通用做法为例.版本 2 .支持库 spec 子程序 提交音频识别, 文本型, 公开 .参数 音频文件路径, 文本型 .参数 接口地址, 文本型 .局部变量 请求对象, 对象 .局部变量 响应文本, 文本型 .局部变量 表单数据, 字节集 创建 XMLHTTP 对象 请求对象.创建 (“MSXML2.XMLHTTP”, ) 打开连接使用 POST 方式提交 请求对象.方法 (“open”, “POST”, 接口地址, 假) 设置请求头声明数据格式为音频二进制流 请求对象.方法 (“setRequestHeader”, “Content-Type”, “application/octet-stream”) 读取音频文件为字节集 表单数据 读入文件 (音频文件路径) 发送数据 请求对象.方法 (“send”, 表单数据) 等待服务器返回 响应文本 请求对象.读属性 (“responseText”, ).取文本 () 这里简单返回响应内容实际使用时建议先检查 HTTP 状态码 返回 (响应文本) 子程序结束逻辑说明这段代码通过MSXML2.XMLHTTP对象发起一个POST请求把音频文件的字节集作为请求体发送。识别引擎收到后会先返回一个任务ID真正的识别结果需要通过结果查询接口轮询取得。参数说明接口地址要区分“提交接口”和“查询接口”提交接口负责收文件查询接口负责取结果Content-Type根据你选择的引擎要求来设有些引擎要求application/json并附带音频的Base64编码有些支持application/octet-stream直接传二进制用错了会返回格式错误一类的提示。轮询逻辑建议每3到5秒查一次单次音频识别时间通常在10秒到1分钟之间查询太频繁会白白消耗请求额度。返回结果一般是JSON字符串里面包含状态码、识别文本、句子级时间戳。3.3 结果解析与文本回写从JSON到TXT和SRT拿到JSON字符串之后最后一步是解析和回写。易语言处理JSON建议直接用现成类库别自己写字符串截取否则字段顺序一变化你就得改代码。解析时重点关注三个字段状态码、识别的句子列表、每句的时间戳。下面是一段解析并生成TXT文本的骨架.版本 2 .支持库 spec 子程序 解析识别结果, 文本型, 公开 .参数 响应Json, 文本型 .参数 是否带时间戳, 逻辑型 .局部变量 Json对象, 对象 .局部变量 句子数组, 对象 .局部变量 索引, 整数型 .局部变量 句子对象, 对象 .局部变量 文本内容, 文本型 .局部变量 开始时间, 文本型 .局部变量 结束时间, 文本型 .局部变量 结果文本, 文本型 把 JSON 字符串加载进解析对象 Json对象.创建 (“Chilkat_9_5_0.JsonObject”, ) Json对象.方法 (“Load”, 响应Json) 检查状态码假设 0 表示成功 如果真 (Json对象.读属性 (“status”, ).取整数 () ≠ 0) 返回 (“识别失败” Json对象.读属性 (“message”, ).取文本 ()) 如果结束 获取句子数组 句子数组 Json对象.读属性 (“sentences”, ) 遍历每一句 计次循环首 (句子数组.读属性 (“Count”, ).取整数 (), 索引) 句子对象 句子数组.方法 (“Item”, 索引 1) 文本内容 句子对象.读属性 (“text”, ).取文本 () 如果真 (是否带时间戳) 开始时间 句子对象.读属性 (“start_time”, ).取文本 () 结束时间 句子对象.读属性 (“end_time”, ).取文本 () 结果文本 结果文本 “[” 开始时间 “ - ” 结束时间 “] ” 文本内容 #换行符 否则 结果文本 结果文本 文本内容 #换行符 如果结束 计次循环尾 () 返回拼接好的纯文本 返回 (结果文本) 子程序结束逻辑说明这里使用Chilkat类库作为JSON解析工具先把响应字符串加载进对象然后按字段路径取值。句子列表是数组需要先取数组长度再逐条读取。返回结果是一个拼接好的多行文本带不带时间戳由调用方决定。参数说明sentences是常见的句子列表字段名对应识别引擎里“按句切分后的结果”start_time和end_time是每句的开始和结束时间单位通常是毫秒如果你想生成SRT字幕还需要把毫秒换算成时:分:秒,毫秒的标准格式这个我在第六节给出完整换算代码。这里返回文本只是为了先跑通链路真正写文件时需要加上“写出文本”命令并指定编码建议用UTF-8编码写文件避免第三方播放器打开SRT时出现中文乱码。4. 参数决定转写质量音频参数、识别参数、任务参数一个都不能少代码跑通只是第一步转写质量高不高全看参数设置。同一个视频你用A参数跑出来可能全对用B参数跑出来可能三四句就错一句。这一章把三类关键参数讲透给你一个可以直接照抄的配置参照。4.1 音频参数为什么16kHz单声道WAV是通用安全牌很多识别引擎的模型是在16kHz采样率的音频上训练的输入音频的采样率越接近训练数据识别的正确率越高。双声道音频会让引擎把两个声道的语音混在一起如果两个声道内容不同比如左声道是人声、右声道是背景音乐识别结果会出现大量无意义的词。所以我在所有项目里都强制转换采样率16kHz单声道16位PCM编码。这个组合和电话语音通话的质量标准一致也是语音识别领域最常用的标准配置。参数配置如下参数项推荐值说明采样率16000 Hz低于8kHz识别率明显下降高于16kHz文件体积增大但效果没提升声道数1单声道双声道会产生语音混叠尤其不要用立体声编码格式PCM WAVWAV无压缩识别引擎读取最稳定MP3有损压缩会丢细节音量归一化建议开启视频里人声忽大忽小时归一化能减少漏识别静音裁剪建议开启去掉片头片尾和中间长静音避免引擎空转参数说明采样率不是越高越好16kHz已经覆盖了人类语音的绝大部分频率范围音量归一化可以在FFmpeg里用loudnorm滤镜实现但注意它会改变音频长度如果后续要做字幕时间轴对齐需要保留时间戳映射关系静音裁剪在易语言里比较难直接实现建议在FFmpeg命令行里加silenceremove滤镜。我第一次做的时候就因为没做音量归一化碰到一个背景音乐压过人声的视频识别出来的文本基本没法看后来加了滤镜效果才正常。4.2 识别参数语言类型、标点、数字规范化怎么设识别引擎的请求参数里几个关键字段直接把控着输出质量。语言类型要明确指定中文普通话、粤语、英语各有独立模型不指定时引擎会做自动检测自动检测在长音频里会频繁切换模型导致识别结果一会出现简体字一会出现繁体字。标点符号选项最好开启不带标点的纯文本在后续做字幕时断句会非常痛苦。数字规范化选项建议按需开识别“三千二百零五”还是“3205”取决于你后续的用途——如果做字幕口语化文本更好如果做搜索索引规范化数字更方便检索。参数示意参数项推荐值说明语言类型zh中文普通话不传会让引擎自动识别中英混说时可能出错标点预测开启返回结果自动补逗号、句号、问号数字格式化按需开启口语转数字或保留汉字敏感词过滤视场景开启内部工具通常不需要最大音频时长按套餐限制超长音频需要自行分片参数说明语言类型参数在不同引擎里的字段名不一样有些叫language有些叫lang但值一般是zh或cmn-hans标点预测这个能力不是所有离线引擎都支持云端API基本都支持所以对字幕质量要求高的人选云端方案更省心。数字格式化这个参数容易被忽略我做过一个给课程视频转写讲义的内部工具老师全程说“第一章节第三小节”如果开启数字格式化成123反而损失了口语中的层级信息所以这种场景要关闭数字格式化。4.3 分片与重试长视频怎么拆、超时怎么退避识别服务对单次音频时长有限制常见的是1分钟、5分钟、2小时三档。超过限制要么请求直接被拒要么后台超时。长视频必须先切分成小段音频再逐段识别最后把文本按顺序拼回来。切成多少秒合适我建议按识别服务的限制减半来切留出余量。比如限制1分钟就切30秒一段限制5分钟切2分钟一段。切太短会增加请求次数切太长容易被拒。下面是一个按时间段调用FFmpeg切割音频的易语言示例.版本 2 子程序 切割音频段, 文本型, 公开 .参数 源音频路径, 文本型 .参数 起始秒, 整数型 .参数 持续秒数, 整数型 .参数 输出路径, 文本型 .局部变量 命令行文本, 文本型 使用 ffmpeg 截取指定时间段 -ss 起始时间-t 持续时间-c copy 表示不重新编码直接复制数据流 命令行文本 “ffmpeg -ss ” 到文本 (起始秒) “ -i ” 源音频路径 “ -t ” 到文本 (持续秒数) “ -c copy -y ” 输出路径 运行 (命令行文本, 真, 真) 返回 (输出路径) 子程序结束逻辑说明切割音频的逻辑是在完整音频文件上做时间戳截取-ss放在-i前面是快速定位速度很快但时间戳精度可能偏差半秒以内-t指定持续时长单位是秒。参数说明-c copy直接复制音频数据流不做重新编码速度最快但如果你在提取音频时用了音量归一化滤镜这里就不能用-c copy因为滤镜处理过的音频没有实际切割点必须重新编码。重试机制方面每次请求失败后建议等待递增的重试间隔第一次失败等5秒第二次10秒第三次20秒最多重试3次。连续失败说明引擎或网络有问题不要无限重试否则会把自己机器的带宽打满。分片后的文本拼接要注意顺序错乱问题建议每段识别结果按起始时间排序后再拼接避免并发提交请求导致返回顺序不一致。5. 易语言视频转文本开发中的5个避坑记录现象、原因、解决办法任何技术方案坑都藏在细节里。这一章记录的5个问题都是我在真实项目中踩过的现象、原因、解决办法一行行写清楚你照着排查能省大量时间。5.1 视频里没人说话但识别出一堆文字背景音乐被当成语音现象一个只有纯音乐、没有人声的片头识别结果却吐出一堆莫名其妙的文字甚至能“认”出根本听不懂的歌词。原因识别引擎在处理音频时并不会区分人声和音乐只要达到了语音模型的触发条件就会被当成语音来识别。音乐里的旋律、鼓点、和声在某些特征上和语音的共振峰接近模型就会强行匹配出一些假词。解决在送识别前加一道人声检测或静音过滤。最简单的做法是先用FFmpeg提取音频时不做任何处理识别前用工具看音轨能量分布更实用的是在转换音频时加高通滤波器把低于300Hz的人声基频以下能量滤掉一部分或者高价滤波器滤掉高频噪声。我实际用的是高通滤波加音量归一化组合能过滤掉一部分纯音乐片段的误识别但完全无解的场景是音乐里有人声和声这种情况只能靠人工筛选。5.2 程序闪退与命令行窗口黑框闪现路径空格和权限问题现象视频文件路径带空格时FFmpeg命令执行失败甚至易语言程序直接崩溃。比如“C:\Users\张三\视频文件\我的课程视频.mp4”这种路径空格会成为命令行解析的分隔符。原因易语言的“运行”命令默认把字符串传给系统命令解释器空格会被当成参数分割点此外FFmpeg安装在系统目录时权限不够命令行窗口一闪而过你甚至看不到报错。解决所有路径必须用英文双引号包裹这是一条铁律。正确写法是把命令行文本里的路径部分改成“ffmpeg -i ” #引号 视频路径 #引号这种拼接方式。权限问题的解法是把FFmpeg程序放在易语言程序同目录或某个无权限限制的目录并把该目录加入系统环境变量PATH这样“运行”命令能直接找到程序而无需依赖系统目录。5.3 中文编码乱码GBK与UTF-8在返回结果里打架现象识别返回的中文文本在易语言的多行文本框里显示正常但写出到TXT或SRT文件后用记事本打开是乱码或者反过来命令行工具输出的中文在控制台是乱码写文件反而正常。原因易语言自带文本处理默认是GBK编码而现代识别接口返回的JSON几乎都是UTF-8编码两者直接互转就会乱码FFmpeg等控制台程序输出的信息也可能是本地代码页编码。解决统一编码策略。HTTP请求返回的文本先做编码转换把UTF-8转成GBK再显示或处理写文件时如果是SRT字幕应指定写出为UTF-8编码如果配合剪辑软件用UTF-8是通用标准。易语言处理这个问题的常见写法是“编码转换”这个库命令从UTF-8转到GBK。5.4 转写长视频时程序假死同步调用导致界面无响应现象视频长度30分钟以上程序界面点了“开始转写”之后直接变成白屏拖动窗口没反应任务管理器显示程序“未响应”。原因易语言默认是单线程你调用FFmpeg转音频、提交HTTP请求、轮询结果这些耗时操作全部在主线程里执行主线程被占用界面消息循环没法响应。解决必须使用多线程。但易语言的多线程有个讲究子程序里不能直接操作窗口组件否则会崩溃。正确做法是把耗时任务放进“启动线程”命令识别完成后通过“标签反馈事件”或“投递消息”的方式把结果传回主界面线程。参数上每个线程执行完后要手动释放线程句柄否则多次识别会导致线程被不断创建最后系统资源耗尽。我在测试时曾经一次性转写100个短视频单线程跑了两小时才完成改成4线程并发后耗时降到四十分钟界面也保持流畅。5.5 识别率突然下降音频采样率被某个环节偷偷改掉了现象同一个视频昨天识别正常今天识别结果就开始出现大量同音字错误。检查了一遍代码发现什么参数都没改。原因大概率是你FFmpeg命令行里的-ar参数因为条件判断被跳过了。比如你给不同来源的视频走了不同分支某一路分支里的命令行没有加-ar 16000或者加了-ar 44100源视频的音频是48kHz采样率结果传给识别引擎的音频是44.1kHz或48kHz识别引擎强行按16kHz模型的特性去解析语音特征全部错位。解决在提交识别前把音频文件读出来检查它的编码头采样率不对就重新转换。易语言可以读取WAV文件头的第24到28字节判断采样率编码成一个小函数每次提交前调用一次。这个方法帮我排查出过一次很隐蔽的问题某一个视频转音频时FFmpeg报错但没停止生成了一个空文件程序没检查音频字节数就提交了识别直接返回“音频文件无效”。6. 把转写结果对齐时间轴易语言按断句生成SRT字幕的进阶实现前面拿到了句子级时间戳离一份真正能用的SRT字幕只差最后一步。SRT字幕格式是字幕领域最通用的标准它的结构分四段序号、时间轴、字幕文本、空行。时间轴的格式是小时:分钟:秒,毫秒而识别引擎返回的时间戳通常是毫秒数整数所以核心工作就是把毫秒换算成标准时间轴字符串再按断句逐条写出。.版本 2 子程序 毫秒转SRT时间, 文本型, 公开 .参数 毫秒数, 整数型 .局部变量 小时, 整数型 .局部变量 分钟, 整数型 .局部变量 秒数, 整数型 .局部变量 剩余毫秒, 整数型 小时 毫秒数 3600000 分钟 (毫秒数 60000) 60 秒数 (毫秒数 1000) 60 剩余毫秒 毫秒数 1000 返回 (文本补齐 (到文本 (小时), 2, “0”) “:” 文本补齐 (到文本 (分钟), 2, “0”) “:” 文本补齐 (到文本 (秒数), 2, “0”) “,” 文本补齐 (到文本 (剩余毫秒), 3, “0”)) 子程序结束逻辑说明时间换算就是三个取整和取余操作是整数除法是取余。文本补齐是易语言的文本处理命令把数字转成指定长度的字符串不足位数左边补0。参数说明3600000是一小时包含的毫秒数60000是一分钟的毫秒数1000是一秒的毫秒数剩余毫秒需要补够3位否则时间轴显示不整齐。生成SRT的时候逐句递增序号写一行序号、一行时间轴行、一行文本内容、一行空行。有几个细节要特别注意时间轴的结束时间最好比每句的end_time长100到150毫秒人眼阅读字幕需要一点缓冲时间否则画面切换时字幕会闪跳同一屏最多两行文本超过就强制断句分片识别的临界点要检查前后两句时间是否连续间隔超过500毫秒说明中间可能漏了一段需要人工核对。进阶用法我建议加一个“关键词章节标记”功能转写完成后在文本里搜索你预先设定的章节词比如“第一章”“小结”“案例分析”命中后生成一个带章节标题的TXT索引这样长视频转写结果不用逐句翻直接跳转到对应位置。我习惯在这个功能里把关键词列表放在一个外部配置文件中易语言启动时读取这样改关键词不用重新编译程序。做这个功能最大的教训是识别引擎返回的时间戳偶尔会有一句的时间轴比下一句的还长生成SRT前必须加排序校验否则字幕软件会报“时间轴非法”。先做时间戳升序排序再做重叠修正把上一句的结束时间强制改为下一句的开始时间减一秒。项目做到这里整个易语言视频转文本工具链基本完整视频进、音频转、识别、文本出、字幕出、可检索。回看这一路踩得最重的坑其实就一句话把每个环节的输入输出格式都固定住用代码检查而非肉眼判断易语言调外部工具就是这样不怕工具多就怕环节之间脱节。希望这篇文章能帮到你少走弯路直接把有效方案落地用起来。本文还有配套的精品资源点击获取