这次我们不讨论某个一键包或生成模型而是一个更具研究味的话题LLM 能不能真的参与视频编码工具的设计。题目很直接Can LLMs Design Video Coding Tools? A Case Study on Planar Mode。简单说这是把大语言模型当成“算法设计助手”让它基于视频编码标准里的某个具体工具——Planar Mode平面模式——去生成实现、优化代码、参数组合甚至跑通性能验证。为什么选 Planar Mode因为它数学定义清晰、实现相对简单、又是 HEVC/VVC 帧内预测的基础模块非常适合用来测试“LLM 设计视频编码工具”这件事到底靠不靠谱。如果你关心的是LLM 在工程落地里除了写论文、写文案还能不能干点硬核算法活或者你是视频编码方向的开发者、研究生、算法工程师想看看 AI 辅助编码工具设计的完整实验思路这篇文章可以直接收藏。本文会从核心能力、可行性路径、环境准备、实验流程、测试验证、性能观察、常见问题到最佳实践给你一套可复用的研究框架。1. 核心能力速览能力项说明项目类型交叉研究LLM 视频编码工具设计研究对象Planar ModeHEVC/VVC 帧内预测中的平面模式核心问题大语言模型能否生成、优化、验证视频编码工具LLM 参与方式代码生成、代码优化、参数搜索、测试用例生成、解释文档视频编码参考软件HMHEVC Test Model、VTMVVC Test Model硬件要求CPU 编码测试即可本地 LLM 推理需 GPU云端 API 可不依赖本地 GPU显存占用本地 7B 模型约需 6-8GB 显存API 调用不占本地显存开发语言Python实验调度、C/C编码器集成批量能力支持批量请求 LLM 生成候选方案批量编码测试接口支持 OpenAI 风格 API / 本地 Ollama API适合场景算法研究、编码器优化探索、AI 辅助程序设计实验从这张表能看出这个方向并不需要特别高的硬件门槛。没有大显存显卡时用云端 API 也能完成全流程实验本地跑 7B 模型也足够处理 Planar Mode 这种小模块的生成任务。2. 为什么选 Planar Mode 作为 LLM 设计实验的突破口视频编码标准里工具很多帧内预测有多种模式、变换、量化、熵编码、环路滤波、运动估计……如果直接让 LLM 去设计一个完整的编码器那既不现实也难以评估。Planar Mode 是很好的起点。2.1 Planar Mode 到底做什么Planar Mode 主要用于帧内预测核心思想是假设当前块内部的像素亮度沿水平和垂直方向平滑变化。它的预测值由四个角的参考像素决定通过对顶部和左侧参考样本做双向线性插值得到。在 HEVC 的 HM 参考软件里Planar 预测的 C 实现通常长这样简化示意// 简化版 Planar 模式预测实际代码需要考虑像素位深和边界填充 for (int y 0; y height; y) { for (int x 0; x width; x) { int top refTop[x]; // 上方参考像素 int left refLeft[y]; // 左侧参考像素 int dr refTop[width]; // 右上参考 int dl refLeft[height]; // 左下参考 pred[y][x] ((width - 1 - x) * left (x 1) * dr (height - 1 - y) * top (y 1) * dl (width height)) / (2 * (width height)); } }2.2 为什么适合 LLM 设计定义明确公式固定参数只有块尺寸和参考像素输入输出确定方便自动验证。依赖少不涉及复杂的帧间参考、运动矢量、上下文建模LLM 生成代码时不容易“跑飞”。可量化评估接入 HM 后可以直接测 BD-Rate、PSNR、编码时间效果好坏一目了然。有优化空间尽管 Planar 本身简单但可以通过查找表、SIMD 指令、近似计算等方式优化也允许 LLM 探索不同整数精度策略。实验周期短对比完整编码器单模块改动编译快、测试序列短适合快速迭代。所以Planar Mode 是一个“麻雀虽小、五脏俱全”的实验平台。如果 LLM 能在这个小工具上做出有效设计那么未来扩展到更复杂工具就有了基础。3. LLM 设计视频编码工具的可行路径说清楚“能不能”先要梳理“怎么做”。LLM 可以嵌入到编码工具设计的多个环节。3.1 代码生成与变体构造给 LLM 一段原始 Planar 实现要求它生成不同优化变体比如改用移位代替除法使用查表法去掉边界判断内联展开循环使用 SIMD 指令SSE/AVX改成定点整数运算。每次生成都是一个候选设计。这种方法的优势是LLM 训练语料中包含大量视频编码开源代码和优化技巧它知道常见的编码器写法。3.2 代码解释与行为分析LLM 可以输入一段不熟悉的 Planar 实现让它解释每个步骤、指出潜在的数据依赖、数值溢出风险。这在阅读 HM/VTM 源码时特别有用能帮研究者快速定位需要修改的函数。3.3 参数搜索与决策建议Planar 虽然公式固定但在不同编码配置下可能有不同的近似实现策略。LLM 可以分析实验数据给出参数调整建议例如哪些块尺寸下近似误差可接受参考像素滤波强度如何与原 Planar 平衡搜 range 还是直接率失真优化这一层不是直接生成代码而是用 LLM 的推理能力辅助研究决策。3.4 测试用例生成视频编码工具设计完成后需要一个验证集。LLM 可以生成测试用的输入数据、边界条件、随机块以及对应的预期输出。这为自动化验证提供很大便利。3.5 端到端优化流水线完整流程可以设计成一个闭环LLM 生成候选实现 - 编译到 HM/VTM - 跑标准测试序列 - 提取 BD-Rate / 编码时间 - 反馈给 LLM - LLM 修改代码这个流水线本质上是用 LLM 当搜索算子在代码空间里做优化。比传统遗传编程更直观因为 LLM 生成的代码风格接近人类易读且容易调试。4. 环境准备与前置条件无论你是想复现实验还是想设计自己的 LLM 辅助编码实验都需要准备两块环境LLM 运行环境和编码器测试环境。4.1 操作系统与编译器建议 Linux 或 macOSWindows 也能跑但编译 HM/VTM 稍麻烦编译器需要支持 C14 或更高版本推荐 GCC 9 / Clang 10CMake 3.13 以上用于构建 HM/VTM磁盘空间至少留 20GB包含参考软件、测试序列、模型缓存。4.2 LLM 接入方式两种主流方式云端 APIOpenAI、DeepSeek、通义千问等提供 API无需本地 GPU按 token 计费。适合批量生成时快速调用。本地模型使用 Ollama、vLLM 加载 7B 参数模型如 Qwen2.5-7B、Llama3.1-8B需要一块 8GB 以上显存的显卡量化后可以降到 6GB。推荐实验初期先使用云端 API因为代码生成的批量请求很多本地模型在速度和思维链方面可能不如大 API 模型稳定。4.3 视频编码参考软件如果以 HEVC 为基准下载 HMHEVC Test Model如果以 VVC 为基准下载 VTM。必须能正常编译并跑出标准测试结果。以 HM 为例git clone https://vcgit.hhi.fraunhofer.de/jvet/HM.git cd HM/build cmake .. -DCMAKE_BUILD_TYPERelease make -j8编译后会在bin目录下生成TAppEncoder和TAppDecoder。4.4 测试序列从标准测试序列中挑选低分辨率如 Class C/D几组即可。Planar 模式改动对高分辨率影响可能不明显先用小序列快速验证功能再用大序列测率失真性能。Python 环境建议安装numpy、pandas、matplotlib用于分析编码日志和绘图。5. 实验设计与部署流程这里给出一个从零开始的实验框架你不需要照搬但核心步骤可以复用。5.1 目标定义明确你要改进的指标无损替换新 Planar 实现必须与原实现输出完全一致如果不允许误差有损近似允许微小误差换取速度或压缩率提升。对于 LLM 设计实验建议先做“无损替换”验证 LLM 是否能正确重构实现再进行“有损优化”。5.2 提示词模板设计LLM 的产出质量高度依赖提示词。一个通用模板你是视频编码专家。下面是 HEVC Planar 预测函数的 C 代码。 请生成一个功能等价的优化版本要求 1. 保持像素位深为 8bit 2. 不允许使用浮点运算 3. 不能改变边界像素处理逻辑 4. 要处理块尺寸 4x4 到 64x64 5. 输出代码完整可编译。 原始代码 ...这里的关键是“约束给足”。LLM 一旦缺少约束容易生成风格飘逸的代码。5.3 自动编译与单元测试对 LLM 生成的代码不能直接扔进 HM 里跑先做单元验证。你可以用 Python 把 C 代码编译成共享库跑随机块对比原实现和生成实现的输出。import ctypes import numpy as np # 假设已经将 LLM 生成的 planer 实现编译为 libplanar.so lib ctypes.CDLL(./libplanar.so) lib.planar_predict.restype None def run_planar(top, left, width, height): out np.zeros((height, width), dtypenp.uint8) lib.planar_predict( top.ctypes.data_as(ctypes.POINTER(ctypes.c_uint8)), left.ctypes.data_as(ctypes.POINTER(ctypes.c_uint8)), out.ctypes.data_as(ctypes.POINTER(ctypes.c_uint8)), width, height ) return out如果输出和 HM 原始实现完全一致则认为通过单元测试。5.4 集成到 HM/VTM单元测试通过后把 LLM 的候选实现替换到 HM 源码的对应函数中。注意修改点不要影响其他预测模式。然后重新编译。5.5 编码测试与 BD-Rate 计算使用标准编码配置设置不同的 QP通常 22、27、32、37分别用原始编码器和修改后的编码器编码同一个测试序列记录输出码流和重建 PSNR。用bd-rate工具如jvet-analysis或自己写脚本计算 BD-Rate衡量压缩效率变化。如果 BD-Rate 接近 0 且编码时间下降说明这个 LLM 设计是有效的。5.6 迭代优化 loop把测试结果反馈给 LLM上次生成的代码编码时间下降了 5%但 BD-Rate 增加了 0.3%。 请在保持 BD-Rate 增幅不超过 0.1% 的前提下进一步优化速度。 建议关注整数乘法和除法开销。这样循环迭代就构成了 LLM 驱动搜索的闭环。6. 功能测试与效果验证6.1 功能测试矩阵测试项测试方法通过标准编译通过在 HM 工程中编译无 errorwarning 可忽略输出一致性随机块输入对比原实现和候选实现像素级相同边界块测试4x4、8x8、16x16、32x32、64x64全部一致多样本测试100 万随机块最大绝对误差 1若允许近似编码器运行编码 Class D 序列 1s 片断不崩溃无越界解码一致性编码后解码比较 YUV若无损替换则完全一致6.2 编码效率测试对每个 QP 进行编码记录总比特率kbpsYUV 平均 PSNRdB编码时间s然后计算 BD-Rate。如果 BD-Rate 为负表示同质量下码率更低压缩效率提升如果接近 0表示 LLM 生成实现与原实现性能相当如果正值说明有损失。6.3 复杂度和内存变化观察LLM 生成代码时经常引入查表或循环展开需要统计编码时间变化率CPU 占用峰值变化增加 static table 后内存占用增量。建议用perf stat或编码器自带的计时模块。6.4 稳定性测试连续跑 5 轮编码观察时间和输出码流是否稳定。LLM 生成代码如果包含未初始化变量可能造成偶数轮输出不一致。这一步非常关键。7. 接口 API 与批量任务这个研究场景天然适合批量调用 LLM 接口。比如你想让 LLM 生成 20 个不同优化方向的 Planar 实现人工复制粘贴效率太低要用脚本批量请求。7.1 批量生成候选代码Python 调用 OpenAI 兼容接口import openai import time client openai.OpenAI(api_keyYOUR_API_KEY, base_urlhttps://api.deepseek.com) def generate_planar_variant(prompt): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个视频编码算法专家只输出C代码不要多余解释。}, {role: user, content: prompt} ], temperature0.7, max_tokens1200 ) return resp.choices[0].message.content prompts [ 请使用SIMD优化Planar预测函数输出完整C代码支持4x4到64x64块, 请用查表法替代Planar预测中的除法输出完整C代码, # ... 更多变体 ] results [] for i, p in enumerate(prompts): try: code generate_planar_variant(p) results.append(code) print(f[{i1}/{len(prompts)}] success) except Exception as e: print(f[{i1}/{len(prompts)}] error: {e}) time.sleep(1) # 简单限速7.2 批量编译与测试每生成一个代码就写入独立文件调用 GCC 编译成共享库然后跑单元测试和编码测试。可以用一个 Python 脚本管理整个流水线import subprocess import tempfile def compile_and_test(code: str, top: np.ndarray, left: np.ndarray): with tempfile.TemporaryDirectory() as tmpdir: src_path f{tmpdir}/planar.c with open(src_path, w) as f: f.write(code) # 编译为动态库 compile_cmd fgcc -shared -fPIC -O2 -o {tmpdir}/libplanar.so {src_path} ret subprocess.run(compile_cmd, shellTrue, capture_outputTrue) if ret.returncode ! 0: return False, ret.stderr.decode(utf-8) # 之后用 ctypes 加载并测试逻辑略 return True, ok7.3 任务队列与失败重试当候选方案较多时建议用简单的队列脚本读入 CSV 格式的 prompt 列表每个 prompt 生成代码 - 编译 - 单元测试 - 编码测试记录每个阶段的状态pending / running / success / failed失败超过 2 次的 prompt 直接跳过并写入日志最终生成汇总表格方便对比。这样批量任务不会因为单条失败而中断整个实验。8. 资源占用与性能观察8.1 LLM 推理开销使用云端 API 时本地无显存压力但会消耗 token。一次生成约 2000 token 的代码费用通常很低但 100 次迭代就是 20 万 token。建议把历史对话压缩只保留关键约束和上一次反馈。如果使用本地模型以 Qwen2.5-7B 量化版为例加载到 Ollama 后显存占用约 6GB 左右实际以本机为准。生成一次代码的延迟约在几秒到十几秒取决于显卡和上下文长度。8.2 编码器测试资源HM/VTM 编码是纯 CPU 任务不同测试序列资源占用差异很大Class D如 BasketballPass1080p 部分帧单线程编码约占用 1-2GB 内存Class B如 Kimono1会更耗时建议先用小块序列做功能验证再用大序列做最终对比。并行做 5 个 QP 编码时建议限制任务并发数否则容易耗尽 CPU。8.3 性能观察方法用nvidia-smi看 LLM 推理时的显存用htop看编码器的 CPU/内存占用用编码器自带的Encoder Time日志记录编码耗时对比原始 HM 和修改版 HM 的总耗时和峰值内存。如果本地显存不够优先考虑 API 方式如果编码序列过大导致内存不足降低分辨率或减少总帧数。9. 常见问题与排查方法问题现象可能原因排查方式解决方案LLM 生成代码无法编译提示词中缺少头文件或类型定义查看编译日志补充#include、typedef等必要声明输出与原实现不一致位深处理错误、边界像素未处理好打印前几行像素对比检查参考像素坐标是否越界编码器运行崩溃内存越界或数组索引溢出用gdb或 AddressSanitizer检查块尺寸 64x64 时查表索引范围BD-Rate 异常增加近似误差过大逐 QP 对比 PSNR改用更高精度整数运算或查表位宽API 批量请求超时并发请求过多 / 模型负载高查看 HTTP 响应状态码降低并发数、增加time.sleep间隔编译产物链接失败函数命名与 HM 不一致查看链接错误符号保持函数名与 HM 调用一致实验迭代不收敛反馈给 LLM 的信息太少检查反馈文本是否包含具体数值把 BD-Rate 和时间变化量化写入 prompt本地 LLM 显存不足模型太大或未量化ollama ps查看占用换 4bit 量化版本或减小输入上下文10. 最佳实践与使用建议在动手做这类实验前有些工程习惯值得先养成。10.1 先从“改一行代码”开始不建议一上来就让 LLM 重写整个预测模块。先让它重构一个函数比如把除法改成移位然后你手工验证建立信任。之后再逐步放开让它设计复杂变体。10.2 把验证做成自动化每一步 LLM 输出都要有脚本自动验证编译是否通过、输出是否一致、编码是否无崩溃。这能快速过滤掉大多数低质量方案减少人工 review 的工作量。10.3 提示词要版本化同一个功能提示词写法不同LLM 表现差异很大。把提示词存成 Markdown 或 JSON记录每次实验使用的版本方便复现和调优。{ prompt_version: 1.2, task: planar_optimize, constraints: [ 8bit depth, no floating point, no boundary behavior change ], feedback_metric: bd_rate, target: bd_rate_change 0.1% }10.4 关注合法性即使只是实验也要注意不要修改编码器后去掉版权声明如果使用开源参考软件 HM/VTM修改后发布需遵循相应开源许可如 BSD-ishLLM 生成的代码如需商用建议先做代码许可证审查不能想当然认为 AI 生成代码没有版权问题人脸或敏感内容测试序列只能在授权范围内使用不要传播。10.5 留足实验记录写清楚每个候选实现来自哪个模型、哪个 prompt、哪次迭代。用 CSV 记录每次编码的 QP、码率、PSNR、时间。这份记录既是论文素材也是排查问题的依据。11. 总结与下一步回到最初的问题LLM 能否设计视频编码工具从 Planar Mode 这个案例看答案是“有机会”。Planar 模块定义清楚、验证方便LLM 完全可以承担代码生成、参数建议、优化迭代中的一部分工作。但“能设计”不等于“能自动搞定一切”它更接近一个会写代码的助手需要配合高度自动化的测试流水线才能真正沉淀出可用的编码优化。如果你想尝试建议先跑通一个最小闭环用 API 生成一段 Planar 优化代码单元测试通过后编码一个 30 帧的小序列对比 BD-Rate。这个闭环跑通后再扩展批量生成、多种优化方向。最容易踩的坑有两个一是提示词约束不够导致代码风格漂移、无法集成二是缺少自动化验证人工检查效率极低。下一步可以探索的方向包括把 Planar 推广到 DC 模式或角度模式用 LLM 设计整个帧内预测的快速算法或者在更复杂的变换和熵编码模块上实验。配套的评估体系要逐步完善最终才能回答“LLM 在多大规模、多大复杂度的编码工具上能真正发挥作用”。
LLM能设计视频编码工具吗？以Planar Mode为例的深度实验
这次我们不讨论某个一键包或生成模型而是一个更具研究味的话题LLM 能不能真的参与视频编码工具的设计。题目很直接Can LLMs Design Video Coding Tools? A Case Study on Planar Mode。简单说这是把大语言模型当成“算法设计助手”让它基于视频编码标准里的某个具体工具——Planar Mode平面模式——去生成实现、优化代码、参数组合甚至跑通性能验证。为什么选 Planar Mode因为它数学定义清晰、实现相对简单、又是 HEVC/VVC 帧内预测的基础模块非常适合用来测试“LLM 设计视频编码工具”这件事到底靠不靠谱。如果你关心的是LLM 在工程落地里除了写论文、写文案还能不能干点硬核算法活或者你是视频编码方向的开发者、研究生、算法工程师想看看 AI 辅助编码工具设计的完整实验思路这篇文章可以直接收藏。本文会从核心能力、可行性路径、环境准备、实验流程、测试验证、性能观察、常见问题到最佳实践给你一套可复用的研究框架。1. 核心能力速览能力项说明项目类型交叉研究LLM 视频编码工具设计研究对象Planar ModeHEVC/VVC 帧内预测中的平面模式核心问题大语言模型能否生成、优化、验证视频编码工具LLM 参与方式代码生成、代码优化、参数搜索、测试用例生成、解释文档视频编码参考软件HMHEVC Test Model、VTMVVC Test Model硬件要求CPU 编码测试即可本地 LLM 推理需 GPU云端 API 可不依赖本地 GPU显存占用本地 7B 模型约需 6-8GB 显存API 调用不占本地显存开发语言Python实验调度、C/C编码器集成批量能力支持批量请求 LLM 生成候选方案批量编码测试接口支持 OpenAI 风格 API / 本地 Ollama API适合场景算法研究、编码器优化探索、AI 辅助程序设计实验从这张表能看出这个方向并不需要特别高的硬件门槛。没有大显存显卡时用云端 API 也能完成全流程实验本地跑 7B 模型也足够处理 Planar Mode 这种小模块的生成任务。2. 为什么选 Planar Mode 作为 LLM 设计实验的突破口视频编码标准里工具很多帧内预测有多种模式、变换、量化、熵编码、环路滤波、运动估计……如果直接让 LLM 去设计一个完整的编码器那既不现实也难以评估。Planar Mode 是很好的起点。2.1 Planar Mode 到底做什么Planar Mode 主要用于帧内预测核心思想是假设当前块内部的像素亮度沿水平和垂直方向平滑变化。它的预测值由四个角的参考像素决定通过对顶部和左侧参考样本做双向线性插值得到。在 HEVC 的 HM 参考软件里Planar 预测的 C 实现通常长这样简化示意// 简化版 Planar 模式预测实际代码需要考虑像素位深和边界填充 for (int y 0; y height; y) { for (int x 0; x width; x) { int top refTop[x]; // 上方参考像素 int left refLeft[y]; // 左侧参考像素 int dr refTop[width]; // 右上参考 int dl refLeft[height]; // 左下参考 pred[y][x] ((width - 1 - x) * left (x 1) * dr (height - 1 - y) * top (y 1) * dl (width height)) / (2 * (width height)); } }2.2 为什么适合 LLM 设计定义明确公式固定参数只有块尺寸和参考像素输入输出确定方便自动验证。依赖少不涉及复杂的帧间参考、运动矢量、上下文建模LLM 生成代码时不容易“跑飞”。可量化评估接入 HM 后可以直接测 BD-Rate、PSNR、编码时间效果好坏一目了然。有优化空间尽管 Planar 本身简单但可以通过查找表、SIMD 指令、近似计算等方式优化也允许 LLM 探索不同整数精度策略。实验周期短对比完整编码器单模块改动编译快、测试序列短适合快速迭代。所以Planar Mode 是一个“麻雀虽小、五脏俱全”的实验平台。如果 LLM 能在这个小工具上做出有效设计那么未来扩展到更复杂工具就有了基础。3. LLM 设计视频编码工具的可行路径说清楚“能不能”先要梳理“怎么做”。LLM 可以嵌入到编码工具设计的多个环节。3.1 代码生成与变体构造给 LLM 一段原始 Planar 实现要求它生成不同优化变体比如改用移位代替除法使用查表法去掉边界判断内联展开循环使用 SIMD 指令SSE/AVX改成定点整数运算。每次生成都是一个候选设计。这种方法的优势是LLM 训练语料中包含大量视频编码开源代码和优化技巧它知道常见的编码器写法。3.2 代码解释与行为分析LLM 可以输入一段不熟悉的 Planar 实现让它解释每个步骤、指出潜在的数据依赖、数值溢出风险。这在阅读 HM/VTM 源码时特别有用能帮研究者快速定位需要修改的函数。3.3 参数搜索与决策建议Planar 虽然公式固定但在不同编码配置下可能有不同的近似实现策略。LLM 可以分析实验数据给出参数调整建议例如哪些块尺寸下近似误差可接受参考像素滤波强度如何与原 Planar 平衡搜 range 还是直接率失真优化这一层不是直接生成代码而是用 LLM 的推理能力辅助研究决策。3.4 测试用例生成视频编码工具设计完成后需要一个验证集。LLM 可以生成测试用的输入数据、边界条件、随机块以及对应的预期输出。这为自动化验证提供很大便利。3.5 端到端优化流水线完整流程可以设计成一个闭环LLM 生成候选实现 - 编译到 HM/VTM - 跑标准测试序列 - 提取 BD-Rate / 编码时间 - 反馈给 LLM - LLM 修改代码这个流水线本质上是用 LLM 当搜索算子在代码空间里做优化。比传统遗传编程更直观因为 LLM 生成的代码风格接近人类易读且容易调试。4. 环境准备与前置条件无论你是想复现实验还是想设计自己的 LLM 辅助编码实验都需要准备两块环境LLM 运行环境和编码器测试环境。4.1 操作系统与编译器建议 Linux 或 macOSWindows 也能跑但编译 HM/VTM 稍麻烦编译器需要支持 C14 或更高版本推荐 GCC 9 / Clang 10CMake 3.13 以上用于构建 HM/VTM磁盘空间至少留 20GB包含参考软件、测试序列、模型缓存。4.2 LLM 接入方式两种主流方式云端 APIOpenAI、DeepSeek、通义千问等提供 API无需本地 GPU按 token 计费。适合批量生成时快速调用。本地模型使用 Ollama、vLLM 加载 7B 参数模型如 Qwen2.5-7B、Llama3.1-8B需要一块 8GB 以上显存的显卡量化后可以降到 6GB。推荐实验初期先使用云端 API因为代码生成的批量请求很多本地模型在速度和思维链方面可能不如大 API 模型稳定。4.3 视频编码参考软件如果以 HEVC 为基准下载 HMHEVC Test Model如果以 VVC 为基准下载 VTM。必须能正常编译并跑出标准测试结果。以 HM 为例git clone https://vcgit.hhi.fraunhofer.de/jvet/HM.git cd HM/build cmake .. -DCMAKE_BUILD_TYPERelease make -j8编译后会在bin目录下生成TAppEncoder和TAppDecoder。4.4 测试序列从标准测试序列中挑选低分辨率如 Class C/D几组即可。Planar 模式改动对高分辨率影响可能不明显先用小序列快速验证功能再用大序列测率失真性能。Python 环境建议安装numpy、pandas、matplotlib用于分析编码日志和绘图。5. 实验设计与部署流程这里给出一个从零开始的实验框架你不需要照搬但核心步骤可以复用。5.1 目标定义明确你要改进的指标无损替换新 Planar 实现必须与原实现输出完全一致如果不允许误差有损近似允许微小误差换取速度或压缩率提升。对于 LLM 设计实验建议先做“无损替换”验证 LLM 是否能正确重构实现再进行“有损优化”。5.2 提示词模板设计LLM 的产出质量高度依赖提示词。一个通用模板你是视频编码专家。下面是 HEVC Planar 预测函数的 C 代码。 请生成一个功能等价的优化版本要求 1. 保持像素位深为 8bit 2. 不允许使用浮点运算 3. 不能改变边界像素处理逻辑 4. 要处理块尺寸 4x4 到 64x64 5. 输出代码完整可编译。 原始代码 ...这里的关键是“约束给足”。LLM 一旦缺少约束容易生成风格飘逸的代码。5.3 自动编译与单元测试对 LLM 生成的代码不能直接扔进 HM 里跑先做单元验证。你可以用 Python 把 C 代码编译成共享库跑随机块对比原实现和生成实现的输出。import ctypes import numpy as np # 假设已经将 LLM 生成的 planer 实现编译为 libplanar.so lib ctypes.CDLL(./libplanar.so) lib.planar_predict.restype None def run_planar(top, left, width, height): out np.zeros((height, width), dtypenp.uint8) lib.planar_predict( top.ctypes.data_as(ctypes.POINTER(ctypes.c_uint8)), left.ctypes.data_as(ctypes.POINTER(ctypes.c_uint8)), out.ctypes.data_as(ctypes.POINTER(ctypes.c_uint8)), width, height ) return out如果输出和 HM 原始实现完全一致则认为通过单元测试。5.4 集成到 HM/VTM单元测试通过后把 LLM 的候选实现替换到 HM 源码的对应函数中。注意修改点不要影响其他预测模式。然后重新编译。5.5 编码测试与 BD-Rate 计算使用标准编码配置设置不同的 QP通常 22、27、32、37分别用原始编码器和修改后的编码器编码同一个测试序列记录输出码流和重建 PSNR。用bd-rate工具如jvet-analysis或自己写脚本计算 BD-Rate衡量压缩效率变化。如果 BD-Rate 接近 0 且编码时间下降说明这个 LLM 设计是有效的。5.6 迭代优化 loop把测试结果反馈给 LLM上次生成的代码编码时间下降了 5%但 BD-Rate 增加了 0.3%。 请在保持 BD-Rate 增幅不超过 0.1% 的前提下进一步优化速度。 建议关注整数乘法和除法开销。这样循环迭代就构成了 LLM 驱动搜索的闭环。6. 功能测试与效果验证6.1 功能测试矩阵测试项测试方法通过标准编译通过在 HM 工程中编译无 errorwarning 可忽略输出一致性随机块输入对比原实现和候选实现像素级相同边界块测试4x4、8x8、16x16、32x32、64x64全部一致多样本测试100 万随机块最大绝对误差 1若允许近似编码器运行编码 Class D 序列 1s 片断不崩溃无越界解码一致性编码后解码比较 YUV若无损替换则完全一致6.2 编码效率测试对每个 QP 进行编码记录总比特率kbpsYUV 平均 PSNRdB编码时间s然后计算 BD-Rate。如果 BD-Rate 为负表示同质量下码率更低压缩效率提升如果接近 0表示 LLM 生成实现与原实现性能相当如果正值说明有损失。6.3 复杂度和内存变化观察LLM 生成代码时经常引入查表或循环展开需要统计编码时间变化率CPU 占用峰值变化增加 static table 后内存占用增量。建议用perf stat或编码器自带的计时模块。6.4 稳定性测试连续跑 5 轮编码观察时间和输出码流是否稳定。LLM 生成代码如果包含未初始化变量可能造成偶数轮输出不一致。这一步非常关键。7. 接口 API 与批量任务这个研究场景天然适合批量调用 LLM 接口。比如你想让 LLM 生成 20 个不同优化方向的 Planar 实现人工复制粘贴效率太低要用脚本批量请求。7.1 批量生成候选代码Python 调用 OpenAI 兼容接口import openai import time client openai.OpenAI(api_keyYOUR_API_KEY, base_urlhttps://api.deepseek.com) def generate_planar_variant(prompt): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个视频编码算法专家只输出C代码不要多余解释。}, {role: user, content: prompt} ], temperature0.7, max_tokens1200 ) return resp.choices[0].message.content prompts [ 请使用SIMD优化Planar预测函数输出完整C代码支持4x4到64x64块, 请用查表法替代Planar预测中的除法输出完整C代码, # ... 更多变体 ] results [] for i, p in enumerate(prompts): try: code generate_planar_variant(p) results.append(code) print(f[{i1}/{len(prompts)}] success) except Exception as e: print(f[{i1}/{len(prompts)}] error: {e}) time.sleep(1) # 简单限速7.2 批量编译与测试每生成一个代码就写入独立文件调用 GCC 编译成共享库然后跑单元测试和编码测试。可以用一个 Python 脚本管理整个流水线import subprocess import tempfile def compile_and_test(code: str, top: np.ndarray, left: np.ndarray): with tempfile.TemporaryDirectory() as tmpdir: src_path f{tmpdir}/planar.c with open(src_path, w) as f: f.write(code) # 编译为动态库 compile_cmd fgcc -shared -fPIC -O2 -o {tmpdir}/libplanar.so {src_path} ret subprocess.run(compile_cmd, shellTrue, capture_outputTrue) if ret.returncode ! 0: return False, ret.stderr.decode(utf-8) # 之后用 ctypes 加载并测试逻辑略 return True, ok7.3 任务队列与失败重试当候选方案较多时建议用简单的队列脚本读入 CSV 格式的 prompt 列表每个 prompt 生成代码 - 编译 - 单元测试 - 编码测试记录每个阶段的状态pending / running / success / failed失败超过 2 次的 prompt 直接跳过并写入日志最终生成汇总表格方便对比。这样批量任务不会因为单条失败而中断整个实验。8. 资源占用与性能观察8.1 LLM 推理开销使用云端 API 时本地无显存压力但会消耗 token。一次生成约 2000 token 的代码费用通常很低但 100 次迭代就是 20 万 token。建议把历史对话压缩只保留关键约束和上一次反馈。如果使用本地模型以 Qwen2.5-7B 量化版为例加载到 Ollama 后显存占用约 6GB 左右实际以本机为准。生成一次代码的延迟约在几秒到十几秒取决于显卡和上下文长度。8.2 编码器测试资源HM/VTM 编码是纯 CPU 任务不同测试序列资源占用差异很大Class D如 BasketballPass1080p 部分帧单线程编码约占用 1-2GB 内存Class B如 Kimono1会更耗时建议先用小块序列做功能验证再用大序列做最终对比。并行做 5 个 QP 编码时建议限制任务并发数否则容易耗尽 CPU。8.3 性能观察方法用nvidia-smi看 LLM 推理时的显存用htop看编码器的 CPU/内存占用用编码器自带的Encoder Time日志记录编码耗时对比原始 HM 和修改版 HM 的总耗时和峰值内存。如果本地显存不够优先考虑 API 方式如果编码序列过大导致内存不足降低分辨率或减少总帧数。9. 常见问题与排查方法问题现象可能原因排查方式解决方案LLM 生成代码无法编译提示词中缺少头文件或类型定义查看编译日志补充#include、typedef等必要声明输出与原实现不一致位深处理错误、边界像素未处理好打印前几行像素对比检查参考像素坐标是否越界编码器运行崩溃内存越界或数组索引溢出用gdb或 AddressSanitizer检查块尺寸 64x64 时查表索引范围BD-Rate 异常增加近似误差过大逐 QP 对比 PSNR改用更高精度整数运算或查表位宽API 批量请求超时并发请求过多 / 模型负载高查看 HTTP 响应状态码降低并发数、增加time.sleep间隔编译产物链接失败函数命名与 HM 不一致查看链接错误符号保持函数名与 HM 调用一致实验迭代不收敛反馈给 LLM 的信息太少检查反馈文本是否包含具体数值把 BD-Rate 和时间变化量化写入 prompt本地 LLM 显存不足模型太大或未量化ollama ps查看占用换 4bit 量化版本或减小输入上下文10. 最佳实践与使用建议在动手做这类实验前有些工程习惯值得先养成。10.1 先从“改一行代码”开始不建议一上来就让 LLM 重写整个预测模块。先让它重构一个函数比如把除法改成移位然后你手工验证建立信任。之后再逐步放开让它设计复杂变体。10.2 把验证做成自动化每一步 LLM 输出都要有脚本自动验证编译是否通过、输出是否一致、编码是否无崩溃。这能快速过滤掉大多数低质量方案减少人工 review 的工作量。10.3 提示词要版本化同一个功能提示词写法不同LLM 表现差异很大。把提示词存成 Markdown 或 JSON记录每次实验使用的版本方便复现和调优。{ prompt_version: 1.2, task: planar_optimize, constraints: [ 8bit depth, no floating point, no boundary behavior change ], feedback_metric: bd_rate, target: bd_rate_change 0.1% }10.4 关注合法性即使只是实验也要注意不要修改编码器后去掉版权声明如果使用开源参考软件 HM/VTM修改后发布需遵循相应开源许可如 BSD-ishLLM 生成的代码如需商用建议先做代码许可证审查不能想当然认为 AI 生成代码没有版权问题人脸或敏感内容测试序列只能在授权范围内使用不要传播。10.5 留足实验记录写清楚每个候选实现来自哪个模型、哪个 prompt、哪次迭代。用 CSV 记录每次编码的 QP、码率、PSNR、时间。这份记录既是论文素材也是排查问题的依据。11. 总结与下一步回到最初的问题LLM 能否设计视频编码工具从 Planar Mode 这个案例看答案是“有机会”。Planar 模块定义清楚、验证方便LLM 完全可以承担代码生成、参数建议、优化迭代中的一部分工作。但“能设计”不等于“能自动搞定一切”它更接近一个会写代码的助手需要配合高度自动化的测试流水线才能真正沉淀出可用的编码优化。如果你想尝试建议先跑通一个最小闭环用 API 生成一段 Planar 优化代码单元测试通过后编码一个 30 帧的小序列对比 BD-Rate。这个闭环跑通后再扩展批量生成、多种优化方向。最容易踩的坑有两个一是提示词约束不够导致代码风格漂移、无法集成二是缺少自动化验证人工检查效率极低。下一步可以探索的方向包括把 Planar 推广到 DC 模式或角度模式用 LLM 设计整个帧内预测的快速算法或者在更复杂的变换和熵编码模块上实验。配套的评估体系要逐步完善最终才能回答“LLM 在多大规模、多大复杂度的编码工具上能真正发挥作用”。