docs
元数据要求

元数据要求

这些插件（服务，services）基本上是原始（raw）的。从二进制的角度而言，我们真正知道的只是它们的名字和类型（生产器 producer、消费器 consumer、滤镜 filter、转场 transition）。然而，应用程序需要能够收集更多信息。目前，一些应用程序只是把元数据（metadata）构建进它们自己的应用里，可能通过源代码，或者通过某种形式的配置文件。本文的目的就是为了解决这个问题。

需求（Requirements）

  • 一个 schema（结构定义） —— 一套标准的结构和一组字段名，以便应用程序能够自动处理它。换句话说，docs/services.txt 是不够的。
  • 对模块作者友好。这意味着它可以是一个随模块一起提供的文本文件，对于一组静态的服务和属性来说，这显然是简单而容易的。然而，有些服务是通向另一个模块化系统（如 ladspa 或 frei0r）的桥梁。在这种情况下，模块需要能够在运行时以编程方式提供元数据。同样，在这种场景下它也应当是简单而便捷的。
  • 应当是可选的 —— 一个应用可以使用它了如指掌的模块，而不必因为缺少元数据就被框架过滤掉。
  • 包含足够的信息以让应用生成一个 UI —— 既包括服务浏览器，也包括服务编辑器。
  • 为参数包含默认值
  • 满足未来对动画的需求（带有关键帧 key frame 和插值的可变属性），以取代当前各服务各自实现动画的体系。

设计（Design）

  • 一个模块可以针对它的每一个服务调用 mlt_repository_register_metadata。

  • 该模块会向 mlt_repository_register_metadata 提供一棵属性（properties）树。

  • 框架会负责释放元数据属性的内存，因此模块不必担心它们的生命周期。

  • 为 mlt_properties_load 增加一个 mlt_properties_parse_yaml 变体，以便模块可以在 YAML (opens in a new tab) 的一个极小子集中编写它的元数据。我不想给框架添加一个 XML 解析器。我可以使用现有的 mlt_properties_load，但其文件格式本身就已经类似 yaml 了。而且我更喜欢 yaml 而不是 xml 以及别的东西。当然，没有什么能阻止模块使用它自己的 xml 解析器，但我不想把解析器的依赖需求加到一个框架服务（mlt_properties）上。

  • 为 mlt_properties 增加 YAML Tiny (opens in a new tab)（请务必阅读）支持。

  • 记住，模块并不一定要有一个代表其元数据的 yaml 文件。这一切都可以以编程方式完成。

  • 模块可以把它的元数据文件安装到 $(datadir)/<module>/metadata/

  • 模块可以使用 mlt_environment(“MLT_DATA”)/<module>/metadata/<locale>.yml 来加载它的元数据文件

  • schema 版本 —— 万一 schema 发生变化，应用可以被设计得更具灵活性

  • 服务实现版本

  • 标签（tags）的分类学：Audio, Video, Luminance, Chrominance, Frequency, Wipe, Distortion, Delay, Amplifier, Pitch, Bandpass, Spectral, Lowpass, Highpass, Comb, Utility, Waveshaper, Generator, Equalizer, Flanger, Compressor, Limiter, Expander, Oscillator, Measurement, Gate, Simulator, Reverb, Filter, Chorus, Notch, Phaser, Allpass, Modulator, Dynamics, Mixer, Motion, Interlace, Temporal, Size, Transform, Resample, Noise, Sharpness

  • Dublin Core Elements v1.1：identifier, creator, contributor, language, title, description, type

  • 国际化（i18n）：

    • 使用 gettext 所支持的 ISO 639-1 代码
    • glib 的 g_get_language_name() (opens in a new tab) 包含了从环境中获取此信息的代码。
    • 框架会向 mlt_metadata 回调提供这份区域名称（locale names）列表。

  • API：

    • 框架暴露一个 mlt_repository_metadata( service_type, service_name ) 函数用于查询和查找元数据。它返回 mlt_properties。
    • 框架期望能够提供元数据的模块包含一个 mlt_metadata 回调。* 这套系统使得模块不必在加载时注册元数据，从而减少启动时间。
    • mlt_metadata 回调会以一个以 null 结尾的字符串数组的形式提供 service_type、service_name 和 locales。
    • 元数据应连同区域代码一起缓存在仓库（repository）中。
    • 提供预设（presets）的模块必须实现 mlt_presets 回调，该回调接收一个 service_type 和 service_name 作为参数并返回一个 mlt_properties。
    • 预设的 schema 待定（TBD）

  • 控件（widget）的分类学：knob, slider, radio, checkbox, spinner, combo, menulist, listbox, color, textbox, timecode, fileopen, filesave, curve, color, font, rectangle（用于 mlt_geometry）

  • 如果 icon/filename 是相对路径，那么它是相对于 $(datadir)（$datadir 例如 /usr/share/mlt）

  • 当前的 MLT Tiny YAML 实现仅支持 2 个空格字符作为缩进！

MetadataSchema
MetadataYamlSample
melted 测试元数据 Schema