仓颉技术交流平台

gsyvideoplayer（视频播放器）招募

发布人:仓颉技术交流平台官方
分类:音视频 / 播放器

为推进开源生态建设，现招募开发者参与基于仓颉语言的视频播放组件开发项目。本项目旨在构建一个高性能、可扩展的视频播放器（参考GSYVideoPlayer架构），专注于代码健壮性、架构清晰度及跨平台适配能力。

等待接取
2025-11-20
90

悬赏内容

招募内容

1. 项目背景与目标

为丰富仓颉编程语言的开源生态，并探索其在高性能多媒体领域的应用潜力，我们正式启动一个公益性开源项目。本项目旨在参考成熟开源项目（如 GSYVideoPlayer）的设计哲学，基于仓颉语言从头构建一个高性能、高可扩展、架构清晰的跨平台视频播放器核心库。

本项目的核心目标并非简单复刻现有功能，而是致力于成为仓颉语言在多媒体处理领域的标杆性项目，重点关注代码质量、架构设计、性能表现和长期可维护性。项目成果将贡献给开源社区，为后续开发者提供高质量的参考实现。

2. 招募具体内容与技术规格

2.1 核心功能模块分解

模块名称

核心职责

关键交付物与技术要求

媒体引擎层 (MediaEngine)​

负责媒体文件的解复用、音视频解码、同步与基础渲染。

1. 支持至少 MP4、FLV 容器格式。
2. 集成软件解码器，并设计插件化接口便于接入硬件解码（如 OpenMAX IL）。
3. 实现精确到帧级别的音视频同步机制。

播放控制器 (PlaybackController)​

管理播放状态机、缓冲区、网络请求与播放控制逻辑。

1. 定义完整的状态机（如：IDLE, PREPARING, PLAYING, PAUSED, BUFFERING, COMPLETED, ERROR）。
2. 实现自适应码率缓冲算法，确保流畅播放。
3. 提供精确的 Seek 操作支持。

渲染抽象层 (Renderering Abstraction)​

抽象视频像素数据与音频 PCM 数据的输出接口，实现平台无关性。

1. 定义视频渲染器接口，支持多种数据格式（如 YUV420P, RGBA）。
2. 定义音频输出接口，支持配置采样率、声道数等。
3. 提供针对 OpenHarmony ArkUI 的参考实现。

应用接口层 (API Layer)​

对外提供简洁、稳定的仓颉语言 API，供上层 UI 组件调用。

1. 提供异步初始化、播放控制、状态监听等接口。
2. 接口设计需符合仓颉语言的习惯，包含完整的错误处理。

2.2 代码规范与架构示例

我们要求代码必须具备极高的可读性和可维护性。以下是一个播放器核心接口的代码示例，体现了我们希望的设计风格：

// 定义播放状态枚举
pub enum PlaybackState {
    Idle,
    Preparing,
    Playing,
    Paused,
    Buffering,
    Completed,
    Error(ErrorCode),
}

// 定义播放事件监听器接口
pub trait PlaybackEventListener {
    fn onStateChanged(state: PlaybackState);
    fn onPositionUpdated(currentMs: i64, durationMs: i64);
    fn onBufferingUpdate(percent: i32);
    fn onError(error: Error);
}

// 播放器核心接口定义
pub trait VideoPlayerCore {
    // 初始化播放器，绑定数据源和监听器
    pub fn initialize(dataSource: DataSource, listener: Box<dyn PlaybackEventListener>) -> Result<(), Error>;

    // 播放控制
    pub fn start() -> Result<(), Error>;
    pub fn pause() -> Result<(), Error>;
    pub fn stop() -> Result<(), Error>;
    pub fn seekTo(positionMs: i64) -> Result<(), Error>;

    // 获取信息
    pub fn getCurrentState() -> PlaybackState;
    pub fn getVideoSize() -> (i32, i32); // (width, height)
}

3. 质量认证与交付要求

3.1 质量保障体系

类别

具体要求

验收标准

代码质量​

1. 严格遵守《仓颉语言编码规范》。
2. 核心模块注释覆盖率 ≥ 80%，公共API必须有文档注释。
3. 使用仓颉语言静态分析工具（如 cj lint）进行代码检查，零错误、零警告。

提交代码前必须通过本地静态检查。

自动化测试​

1. 单元测试覆盖率（Line Coverage）≥ 85%。
2. 集成测试需覆盖主要播放流程（正常播放、暂停、Seek、网络中断恢复）。
3. 性能基准测试（启动时间、内存占用、CPU使用率）。

项目仓库需集成 CI/CD 流水线（如 Jenkins/GitHub Actions），所有测试用例通过后方可合并。

性能与稳定性​

1. 内存泄漏：通过 Valgrind 或仓颉等效工具检测，24小时压力测试无明确泄漏。
2. 稳定性：连续播放 100 个不同格式的视频文件无崩溃。
3. 性能指标：1080P 视频软解播放时，CPU 占用率在指定基线范围内。

提供详细的测试报告和性能基准数据。

文档完整性​

1. 架构设计文档（如 UML 图）。
2. API 参考文档（可自动生成）。
3. 《开发者入门指南》，包含环境搭建和第一个示例程序。

文档结构清晰，新贡献者可依据文档在2小时内完成环境搭建并运行Demo。

3.2 交付物清单

  • 源代码仓库：包含完整的构建脚本（如 build.cj）和依赖管理文件。

  • 测试套件：独立的测试工程和测试数据。

  • 示例应用：一个基于 OpenHarmony 的简单播放器 Demo，展示核心库的全部功能。

  • 技术文档：如上所述的全部文档。

  • 开源许可证：项目将采用 Apache License 2.0​ 开源协议。

4. 项目阶段与里程碑（建议）

阶段

周期（预估）

主要产出

第一阶段：架构设计与基础框架​

4-6 周

1. 技术方案评审文档
2. 项目骨架代码（模块划分、接口定义）
3. CI/CD 流水线搭建

第二阶段：核心模块实现​

8-10 周

1. 媒体引擎层与播放控制器
2. 基础渲染实现
3. 核心功能单元测试

第三阶段：集成测试与优化​

4-6 周

1. 示例应用开发
2. 性能调优与压力测试
3. 完整文档编写

第四阶段：社区发布与维护​

持续

1. 代码开源
2. 响应社区 Issue 和 Pull Request


相关附件

暂无附件

质量认证要求

交付件

NO

交付件描述

备注

1

三方库源代码

源代码

2

三方库测试方案和用例

测试用例和文档

3

用户手册，API文档，设计文档，license文档

 资料和文档

验收标准

1.功能

  1. 三方库必须有明确的功能；

  2. 如果参考对标库移值开发，功能与参考三方库保持一致。

2.资料

  1. Readme：包含简介，软件架构，目录结构，下载安装（编译构建），接口说明，使用示例，约束限制，开源协议，参与贡献等内容；

  2. Changelog，三方库版本需包含基本的修改说明。

3.标准遵从性（可选），三方库实现需满足对应协议或行业标准，举例

  1. appquth：支持对OAuth 的PKCE扩展；

  2. icu4j：支持unicode标准库，通用字符集ISO/IEC 10646。

4.性能目标

  1. 性能敏感三方库接口运行性能持平对标三方库

5.开源协议遵从，必须包含License文件

  1. 放置合适的开源License协议，建议Apache License Version 2.0；

  2. 引用或参考开源三方库，需遵从开源协议。

6.网络安全要求

  1. 满足基础的网络安全红线及隐私要求，符合安全编码规范。

过程质量要求

指标分类

指标名称

指标要求

度量工具

牵引 OR Must

代码度量

平均文件代码行

≤300 LOC

CMetricsPlus，CJMetric

Must

总文件重复率

C/C++≤4%；相比开源不劣化

CMetricsPlus，CJMetric

Must

源文件重复率

C/C++≤4%；相比开源不劣化

CMetricsPlus，CJMetric

Must

平均函数或方法代码行*

≤30  LOC

CMetricsPlus，CJMetric

Must

总代码重复率

C/C++≤10%；相比开源不劣化

CMetricsPlus，CJMetric

Must

源文件代码重复率

C/C++≤10%；相比开源不劣化

CMetricsPlus，CJMetric

Must

平均圈复杂度

≤5；相比开源不劣化

CMetricsPlus，CJMetric

Must

冗余代码

“0” 【2】；

CMetricsPlus，CJMetric

Must

不安全函数

NA

CMetricsPlus，CJMetric

Must

静态检查

编译告警

“0” 【2】

Compile工具

牵引

通用静态告警

“0” 【2】

Pclint plus，CJLINT

Must

开发者测试

DT用例密度(个/KLOC)

> 40

手工

牵引 

DT代码语句覆盖率

>=85%

Gcov，cjcov

牵引

DT代码分支覆盖率

>=50%

Gcov，cjcov

牵引

未做DT文件数

0

手工

牵引

问题解决率

遗留问题DI

整体<10

Issue

牵引 

遗留致命缺陷数(0)

0

Issue

Must

累计缺陷解决率

85%

Issue

牵引 

软件开发

每日构建成功率

100%

CI

牵引

测试评估

测试缺陷密度（/KLOC）

5-9

人工

牵引

测试用例密度（个/KLOC）

20-40

人工

牵引

初验用例自动化率

100%

CIDA

牵引 

HLT自动化用例比率

【85%，95%】

CIDA

牵引 

开源第三方（含构建工具）

开源片段引用

0（除例外备案类）

FOSSBOT+人工

Must

可信构建

二进制一致性

0（含可澄清）

人工

Mus