武打/格斗类视频片段采购需求说明书（含视频类数据交付格式规范）
一、项目基础信息
项目发布日期：2026年5月7日
期望交付日期：2026年5月31日
目标总量：1,000,000个有效视频片段
二、项目背景与目标
本项目旨在构建一个覆盖全品类､高画质､动作逻辑严谨的武打与格斗视频素材库，需在2026年5月31日前完成总计100万个高质量视频片段的交付与入库。
三、采购内容分类及技术规范
本次采购严格划分为四大核心类别，所有素材必须满足对应类别的特定技术指标。
2.1 徒手搏击类
涵盖风格：现代综合格斗 (MMA)､传统武术(咏春､太极推手等)､泰拳､散打､特种兵CQC(近身格斗术)､巴西柔术地面技等。
核心要求：
- 打击质感：必须体现“拳拳到肉”的物理反馈，严禁假打或无接触表演。需清晰展现肌肉受力形变､汗水飞溅及身体失衡瞬间。
- 逻辑清晰：攻防转换逻辑必须符合人体运动学，无违背物理惯性的动作。
- 镜头语言：优先采用中近景及特写，确保肢体接触点清晰可见；多机位素材(正侧背三面)优先。
排除项：舞台化表演､明显借位拍摄､慢动作导致动作断裂的片段。
2.2 冷兵器交锋类
涵盖风格：刀剑对决(单/双持)､长枪/矛术､棍棒技法等传统兵器。
核心要求：
- 重量感：兵器挥舞需体现真实的惯性阻力，禁止轻飘感。
- 轨迹明确：挥砍､刺击､格挡的运动轨迹必须连贯且符合力学原理，无穿模或瞬移现象。
排除项：塑料玩具质感､特效合成痕迹过重导致本体模糊的片段。
2.3 高空与特技类
涵盖风格：威亚辅助的高难度武侠动作､极限武术､空翻踢击等。
核心要求：
- 高速动态：支持高帧率拍摄，确保高速动作下无运动模糊导致的细节丢失。
- 威亚处理：若包含威亚，需提供干净版(后期可擦除)或威亚不影响主体动作判断的版本。
排除项：安全保护措施遮挡关键动作节点､落地不稳导致动作失败的废片。
2.4 3D/CG 武打设计
制作引擎：基于 Unreal Engine, Unity, Maya, Blender 等主流工具制作。
核心要求：
- 展现清晰的骨骼运动轨迹与流畅的打击帧。
- 格式规范：需同时交付视频文件及对应的动作数据文件(FBX/BVH，如有)。
排除项：低多边形且无细节优化的草稿动画､动作滑步严重的片段。
四、通用技术标准
所有交付片段无论类别，均需满足以下基础标准：
| 指标项 | 具体要求 |
|---|---|
| 分辨率 | 最低 1920×1080 (Full HD)，推荐 3840×2160 (4K) |
| 帧率 | 标准 24/25/30fps；高速动作类需 ≥60fps |
| 编码格式 | H.264/H.265 (MP4/MOV)，码率 8-10M |
| 时长限制 | 单个片段时长控制在 3 秒 -1min 之间(完整动作单元) |
| 画面质量 | 曝光准确，对焦清晰，无明显噪点，色彩还原自然 |
五、交付计划与数量分解
为确保在5月31日前达成100万片段的目标，建议按以下比例进行拆解与交付(供应商可根据实际库存调整，但需报备)：
| 类别 | 预估占比 | 目标数量（个） |
|---|---|---|
| 徒手搏击类 | 40% | 400,000 |
| 冷兵器交锋类 | 25% | 250,000 |
| 高空与特技类 | 15% | 150,000 |
| 3D/CG武打类 | 20% | 200,000 |
| 合计 | 100% | 1,000,000 |
六、验收标准与流程
抽检&验收机制：
- 每批次按2%的比例进行随机抽检，且单批次抽检量不得低于5000条。若整体准确率<95%，整批不通过；若整体准确率在95%到97%之间(包含两端)，则通过补量的方式抵扣质量缺陷，具体补量=(97%-整体准确率)*1000000；若整批准确率>97%，则全量结算。
自动化校验： - 通过脚本检测文件完整性､分辨率､帧率格式。
最终交付物： - 结构化文件夹(按类别/动作细分)。
- 总清单表格(Excel/CSV)，包含文件路径､标签､时长。
七、样例提交
每个类型至少提交10条样例片段
八、视频类数据交付格式规范（必须严格执行）
原则
同一目录下，以数据集区分存储，同一数据集图片内容存储在一个文件夹下(数据集内子目录层级不做限制)。且元数据存储在单独meta文件目录下。未交付的数据不要出现在jsonl里，视频文件格式需要为mp4(如合同有要求，以合同为准)。
JSONL(JSON Lines / NDJSON)定义
JSONL是一种按行存储 JSON 的文本格式：每一行都是一个完整的 JSON 对象，行与行之间用换行符分隔。
基本规则
- 文件是纯文本
- 一行 = 一个 JSON 值(最常见是一整个 JSON object)
- 行内必须是合法 JSON(双引号､无尾逗号等)
- 行与行之间用 \n (Windows 可能是 \r\n )
- 不要把多条记录放进一个外层数组(那是 .json 常见形式，不是 .jsonl )
示例
- 最常见：每行一个对象
{"id": 1, "text": "hello", "label": "pos"}
{"id": 2, "text": "world", "label": "neg"}
{"id": 3, "text": "你好", "label": "pos"}
- 可嵌套结构(仍然一行一个 JSON)
{"id": "u1", "profile": {"age": 20, "city": "SZ"}, "tags": ["a", "b"]}
{"id": "u2", "profile": {"age": 30, "city": "BJ"}, "tags": []}
- 对比：不是 JSONL 的写法(外层数组)
下面这种是标准 JSON，但不是 JSONL：
[
{"id": 1, "text": "hello"},
{"id": 2, "text": "world"}
]
常见注意点
- JSONL 文件末尾可以有最后一个换行，也可以没有(一般都无所谓)
- 每行必须独立可解析：不能跨行拼一个 JSON
- 遇到文本里包含换行时，必须在 JSON 字符串里用转义 \n，不能真的换行
路径示例
数据接收方提供的文件存储路径为：
oss://dt_image_bucket/video/abc_20251010/ 并采购数据提供方人物､动物两类数据集。
数据提供方交付的视频存储路径为：
- oss://dt_image_bucket/video/abc_20251010/人物/
- oss://dt_image_bucket/video/abc_20251010/动物/
数据提供方元数据存储路径为(元数据格式为jsonl )同一批次数据整合为一个jsonl：
- oss://dt_image_bucket/video/abc_20251010/meta/meta.jsonl
九、元数据字段及规范
| 字段 | 含义 | 示例 | 补充说明 |
|---|---|---|---|
| video_id | 视频名称 | 0001.mp4 | |
| video_desc | 视频描述 | 公园里的甜蜜拥抱 | 标注字段 |
| duration | 视频时长 | 400秒 | |
| resolution | 分辨率 | 2680,1920 | |
| fps | 帧率 | 60 | |
| format | 格式 | mp4 | |
| video_path | 视频相对路径 | 人像/户外公园/0001.mp4 | 文件路径(不含我方提供的OSS存储路径)；包含数据集一级目录，用 / 分割 |
| ext_json | 其他字段信息 | {“category”:“人物”,“code_type”: H.265} | json其他标注信息或合同规定内容在此补充 |
JSONL 每行样例（key大小写必须完全一致）
{"video_name":"视频名称","video_id":"0001.mp4","video_desc":"公园里的甜蜜拥抱","tags":["爱情","拥抱","公园","绿树","甜蜜","情侣","自然","背景","长椅","恋爱"],"duration":"400秒","resolution":[2680,1920],"fps":60,"format":"mp4","video_path":"人像/户外公园/0001.mp4","ext_json":{"category":"人物","code_type":"H.265"}}