编码风格指南
风格
规则并不多，但以下是一些总体偏好：
- 我们偏好左花括号与语句起始处在同一行（函数除外）
- 缩进应使用四个空格
- 不要用 “this” 作为私有上下文结构的名称。而应选用能描述 对象类型的名称（例如 filter 或 producer）
- 不要与 null 比较。优先用 “if ( pointer )” 而不是 “if ( pointer != NULL )”
- 函数名应全部小写，单词之间用下划线分隔
src/framework 中的代码是这些风格偏好的良好示例。
在提交之前，代码应当用 clang-format 格式化，使用项目根目录下的 .clang-format 文件。“ninja clang-format” 是运行它的便捷方式。
约定
- 框架和 libmvcp 头文件中的注释必须使用 C 风格，而不是 C++ 风格。
- 生产器应当校验自己的输入，失败时返回 NULL。
- 滤镜或转场应当在调用 mlt_frame_get_image() 之前 表达它想要的图像格式。只要目标是 yuv422、rgb24 或 rgb24a， 并且你使用了 imageconvert 滤镜（通常经由 loader 生产器及其 loader.ini 文件），它就应当能收到自己所请求的格式。
- 不要向 stdout 写消息。stdout 保留给那些可以被重定向的输出流： 例如 consumer_libdv 中的原始 DV。请使用 mlt_log API。 对于快速、粗糙、临时性的东西，你可以使用 fprintf( stderr )。
流程
- 修改一个服务模块时，务必更新对应的元数据（.yml）文件。
- 提交前测试该 yml 能通过校验
- 新增一个服务模块时，务必创建对应的元数据（.yml）文件。
- 没有恰当元数据的新服务模块将不会被接受。
- 在每次发布后的第一个提交中，以及在一次新发布即将开始之前，都要 递增 ./configure、mlt.h 和 melt.1 中的版本号。这样我们就能 追踪是否有人在使用源码仓库中尚未发布的版本。