概述

· 为什么Silverstack Lab要改变？

· 介绍新的工作流概念

· 如何配置、跟踪和优化工作流

· 性能优化

· 免费测试版下载及更多注释

我们高兴地在此发布Silverstack Lab 9.0 的beta版本——它为优化数据管理引入了一个创新概念： 工作流配置器。这个概念巩固并取代了Silverstack在装载、备份和转码方面的单独向导，标志着在可用性和用户界面设计方面向前迈进了一大步。

为什么 Silverstack Lab 要改变？

令我们感到自豪的是，Silverstack技术现已成为片场及全行业专业数据管理的代名词，而且我们希望能一直保持这种状态。因此，持续倾听我们活跃用户社群的需求并如实地反思Silverstack到目前为止的发展变化至关重要。在这样做的同时，我们也确定了一些痛点的改善空间：

· 手动任务增加了心理负担。当然，目前的Silverstack成功地支持许多单独操作。然而，顾全大局和追踪每张摄影机卡的所有待办事项仍是一类非常重复乏味的手动任务，且有可能出现人为错误。

· 重复操作浪费精力和时间。数字拍摄会产生大量的素材。由于每天要处理多块摄影机卡，DIT和数据管理员就必须重复执行相同的核心操作，从而导致每张摄影机卡都需要多次点击操作。

· 依赖导致工作推迟。目前，Silverstack的一些任务要求在其他任务完成后才能开始，这导致了不必要的等待时间。

通过这些反思，我们开始构想Silverstack的梦想版本：如果用户可以将数据管理任务连接起来并预置为统一的工作流，并且一键即可开始任务，那会怎么样呢？如果这些操作完全并行运行，消除了长时间的等待和重复的手动步骤，那会怎么样呢？如果你能把精力集中在DIT工作中要求较高（且回报也较高）的职责上，而不是那些例行工序，那会怎么样呢？大约一年前，我们停止了空想，开始着手编程。

介绍新的工作流概念

好的，对我们的出发点和我们的目标是要实现什么有了更清晰的理解之后，让我们来探索一下新的工作流概念：此前，你必须使用Silverstack各类功能的单独向导，分开执行不同的操作任务（比如：装载、备份、转码、报告等）。如下方图片所示，新的用户界面允许你以自定义顺序链接你的操作，从而创建统一的工作流。当然，所有的操作都可以根据你的需要进行配置，稍后我们将对这部分进行更详细的探讨。

等你的配置都设置好了，就可以一键开始整个工作流，而且Silverstack会自动开始处理不同的操作任务。这样做时，由于我们修改了任务执行机制，组成你操作（以及最终的工作流）的不同任务便可以同时运行，并且可在片段级别上交替进行。其结果：Silverstack已经创建并上传了第一批片段的代理，同时仍然在从同一张摄影机卡装载剩余的片段。

在处理这些相互关联的流程时，保持对进展和可能发生的错误的概览更显得重要。因此，我们的新概念还包括一个新的以工作流为中心的任务视图——即使在跨不同摄影机卡的多个工作流同时运行时，它也能提供一个清晰的顶层概览。从这个顶层视图中，你可以访问单个工作流、任务和子任务，以便进行详细的分析和优化。我们将在后面的文章中详细探讨新的任务概述及其特性。

如何在新UI中配置工作流

为了帮助你顺利地过渡到新的工作流概念，让我们看一下配置过程。Silverstack 的一切操作仍然是从点击“装载”按钮开始的。这将打开一个新的UI，而在那你既可以从头配置工作流，也可以从保存的预设中进行选择。一般而言，目前可将下列操作添加到工作流中：

· 在库中导入（默认步骤）

· 备份

· 验证

· 转码

· 动态元数据提取

· 样片上传（frame.io和webgate.io）

· Ci媒体云上传

· AWS S3上载

让我们拆解一下每种操作及其在工作流中的角色。

操作1：导入库

定期装载是最小的可能工作流，从“导入库”这一步开始，然后是“备份”操作。“导入库”步骤会显示扫描进度/结果，并让你可以详细配置摄影机卡的内容如何导入库以及导入哪里。比方说，你可以为来自crash cam的片段设置重命名模式（装载时重命名），从摄影机卡中仅选择几个片段（部分装载），或者调整媒体夹名称和导入路径。

在上面的屏幕截图中，你还可以看到一个名为“导入元数据”的新功能。这个部分可让你为卡上的所有片段和文件指定通用元数据，例如摄影机索引、拍摄日期、摄制组组号或集数。然后，你可以使用这些数据自动将媒体夹放置在库概览中，或者在工作流的后续步骤中以通配符的形式放置，例如备份步骤的目标路径（或者其他，比如转码）。

操作2：备份

接下来，就是配置备份的时候了！正如你可以在下方截图中看到的，我们已经设置了两个装载目的地的备份操作：阵列存储和更替硬盘。配置页面（UI 的右侧部分）设计为可提供快速概述和总结配置细节。通过展开折叠部分，你可以访问旧Silverstack版本中已知的所有细节，例如 “目标路径通配符编辑器”或验证细节。

如果有配置问题，错误或警告现在会出现在配置页面的顶部。我们还改进了错误消息本身：它们现在包括了一个可提供更多细节或直接提供快速问题修复方式的按钮——如下方的示例所示。在这张截图中，你还可以看到一个针对更替硬盘轮转的新功能：如果你设置的目的地是离线的，但Silverstack检测到一个类似名称的可用目的地，一个新按钮可以将离线卷替换为最有可能的继承卷，让你快速修复这部分配置。

操作3：转码

借助直接链接到备份操作的转码操作，你不再需要等待备份完成才能开始转码。相反，现在只要备份目的地的第一个片段可用，转码任务就会立即启动，并与摄影机卡其余部分的备份并行运行。因此你在装载期间就会收到第一批转码文件。

让我们回到我们的示例，更详细地探索一下转码操作和可行配置。正如你在下方图片中所见，备份步骤给我们留下了两个OCF拷贝（一个在RAID上，一个在更替硬盘Travel_01上）。在配置页，你可以选择要将这两个可用资源中的哪一个用作转码的输入。

旧Silverstack Lab版本中为人熟知的转码预设现在仍用于配置所有代理文件细节，如分辨率、编解码器细节、画框线和烧入。但是，从前用于选择多个预设和目标路径的“转码向导”，现在则集成到了工作流配置器中。

 在上方描述的示例工作流中，我们设置了转码步骤来创建DNx和H264代理文件，以便从RAID存储中读取OCF，并将代理文件写入RAID。根据硬件条件的不同，你可能需要考虑将读取OCF和编写代理文件放在不同位置，以实现最佳软件性能。我们会在下方更详细地讨论同步性和性能平衡。

操作4：通过云上传和备份分发转码文件

我们工作流中的转码操作会在RAID存储中创建两种类型的代理文件。但如果我们不希望它们留存在那里，而是想尽快把它们发送给剪辑师或客户呢？此处让我们来进一步操作：在我们的示例中，添加一个“云端上传”操作——这将会把720p H264代理文件上传到Ci媒体云，而“备份2”操作则将把DNxHD代理文件复制到更替硬盘。当前我们支持以下上传平台：

 · Ci媒体云

· Webgate.io

· Frame.io（v3）

· AWS S3 Bucket（及各项兼容服务）

（未完待续……）

出处：Franz | Pomfort