使用视频编码扩展机器人数据集
在过去几年中，基于文本和图像的模型性能显著提高，这主要归因于模型权重和数据集规模的扩大。虽然互联网为大型语言模型（LLM）和图像生成模型提供了大量多样化的文本和图像数据源，但机器人学领域缺乏如此庞大且多样化的定性数据源和高效的数据格式。尽管像 Open X 这样的努力已经展开，但我们距离实现大型语言模型那样的规模和多样性仍有很长的路要走。此外，我们还缺乏这项工作所需的工具，例如轻量级、加载速度快、易于共享和在线可视化的数据集格式。这正是 🤗 LeRobot 旨在解决的差距。
什么是机器人学中的数据集？
在一般形式下——至少是我们端到端学习框架中感兴趣的形式——机器人学数据集通常以两种模态呈现：视觉模态和机器人本体感知/目标位置模态（状态/动作向量）。以下是其在实践中的样子：
到目前为止，存储视觉模态的最佳方式是使用 PNG 格式存储单个帧。这种方式非常冗余，因为帧之间存在大量重复。实践者不使用视频是因为加载时间可能会增加几个数量级。这些数据集通常以学术论文中各种格式发布（hdf5、zarr、pickle、tar、zip 等）。如今，现代视频编解码器可以实现惊人的压缩比——即编码视频的大小与原始未压缩帧的大小之比——同时仍能保持出色的质量。这意味着，如果压缩比为 1:20，或例如 5%（这很容易实现），你可以将一个 20GB 的数据集缩小到仅 1GB 的数据。因此，我们决定使用视频编码来存储数据集的视觉模态。
贡献
我们提出了一个简单、轻量级、易于共享（与 Hub 原生集成）且易于可视化的 `LeRobotDataset` 格式。我们的数据集平均比其原始版本小 14%（在最佳情况下可达 0.2%），同时通过保持非常好的质量水平来保持其完整的训练能力。此外，我们观察到视频帧的解码时间遵循这种模式，具体取决于分辨率
- 在名义情况下，当我们解码单个帧时，我们的加载时间与从压缩图像（png）加载帧的时间相当。
- 在有利情况下，当我们解码多个连续帧时，我们的加载时间是加载压缩图像中这些帧的时间的 25%-50%。
除此之外，我们还在构建工具，以便轻松理解和浏览这些数据集。您可以使用我们的可视化工具在以下空间中自行探索一些示例（点击图片）
aliberts/koch_tutorial
cadene/koch_bimanual_folding
但什么是编解码器？视频编码和解码到底在做什么？
本质上，视频编码主要通过两种方法来减小视频文件大小：
空间压缩： 这与 JPEG 或 PNG 等压缩图像中使用的原理相同。空间压缩利用图像的自相似性来减小其大小。例如，一段显示蓝天视频的单帧会在大片区域中具有相似的颜色。空间压缩利用这一点来压缩这些区域，而不会损失太多质量。
时间压缩： 时间压缩不是按原样存储每一帧（这会占用大量空间），而是计算每一帧之间的差异，并仅将这些差异（通常小得多）保留在编码视频流中。在解码时，通过重新应用这些差异来重建每一帧。当然，这种方法至少需要一帧参考帧才能开始计算这些差异。然而，在实践中，我们会在规则间隔放置多个参考帧。这样做的原因有很多，详细信息请参见这篇文章。这些“参考帧”被称为关键帧或 I 帧（内部编码帧）。
由于这两个想法，视频编码能够将视频文件大小压缩到可管理的程度。了解这一点后，编码过程大致如下：
- 关键帧根据用户的规格和场景变化确定。
- 这些关键帧进行空间压缩。
- 帧间图像随后作为“差异”（也称为 P 帧或 B 帧，更多信息见上述链接文章）进行时间压缩。
- 这些差异本身随后进行空间压缩。
- 来自 I 帧、P 帧和 B 帧的这些压缩数据被编码成比特流。
- 然后，该视频比特流与可能存在的其他比特流（音频、字幕）和元数据一起打包成容器格式（MP4、MKV、AVI 等）。
- 此时，可以进行额外的处理以减少压缩引起的任何视觉失真，并确保整体视频质量达到所需标准。
显然，这是对正在发生的事情的高度概括，这个过程中有许多动态部分和配置选择。因此，我们希望根据我们的需求和约束评估最佳的实现方式，为此我们构建了一个基准测试，以根据多个标准进行评估。
标准
虽然文件大小是我们决定采用视频编码的最初原因，但我们很快意识到还有其他方面需要考虑。当然，解码时间对于机器学习应用来说很重要，因为我们希望最大限度地利用训练时间而不是加载数据。质量也需要保持在一定水平之上，以免降低我们策略的性能。最后，一个不那么明显但同样重要的方面是我们编码视频的兼容性，以便能够轻松解码并在大多数媒体播放器、网络浏览器、设备等上播放。能够轻松快速地可视化我们任何数据集的内容对我们来说是必不可少的功能。
总而言之，这些是我们希望优化的标准
- 大小： 影响存储磁盘空间和下载时间。
- 解码时间： 影响训练时间。
- 质量： 影响训练准确性。
- 兼容性： 影响在不同设备和平台间轻松解码和可视化视频的能力。
显然，其中一些标准是相互矛盾的：例如，你很难在不降低质量的情况下减小文件大小，反之亦然。因此，目标是找到最佳的整体折衷方案。
请注意，由于我们特定的用例和需求，一些传统上用于媒体消费的编码设置并不完全适用于我们。一个很好的例子就是 GOP（图像组）大小。稍后将详细介绍。
指标
根据这些标准，我们相应地选择了指标。
尺寸压缩比（越低越好）：如前所述，这是编码视频的大小与其原始未编码帧集大小之比。
加载时间比（越低越好）：这是从视频解码给定帧所需的时间与从单个图像加载该帧所需的时间之比。
对于质量，我们查看了 3 个常用指标
平均均方误差（越低越好）： 解码帧与相应原始图像在所有请求时间戳上的平均均方误差，并除以图像中的像素数量，以便在不同图像尺寸之间进行比较。
平均峰值信噪比（越高越好）： 衡量信号最大可能功率与影响其表示保真度的损坏噪声功率之间的比率。PSNR 越高表示质量越好。
平均结构相似性指数衡量（越高越好）： 通过比较亮度、对比度和结构来评估图像的感知质量。SSIM 值范围为 -1 到 1，其中 1 表示完美相似。
此外，我们尝试了不同级别的编码质量，以了解这些指标在视觉上的表现。然而，视频编码旨在通过利用人类视觉感知的工作原理来吸引人眼，欺骗我们的大脑以保持一定的感知质量。这可能会对神经网络产生不同的影响。因此，除了这些指标和视觉检查之外，对我们来说重要的是还要通过 A/B 测试来验证编码是否会降低我们策略的性能。
对于兼容性，我们没有一个**度量标准**，但它基本上归结为视频编解码器和像素格式。对于视频编解码器，我们选择的三种（h264、h265 和 AV1）都很常见，不会有问题。但是，像素格式也很重要，我们后来发现例如在大多数浏览器上，`yuv444p` 不受支持，视频无法解码。
变量
图像内容和大小
我们不期望来自模拟图像数据集，或来自公寓、工厂、户外等真实世界中包含大量移动对象的图像数据集具有相同的最佳设置。同样，加载时间可能不会随图像大小（分辨率）线性变化。出于这些原因，我们对四个具有代表性的数据集进行了此基准测试：
lerobot/pusht_image: (96 x 96 像素) 具有简单几何形状的模拟，固定摄像头。aliberts/aloha_mobile_shrimp_image: (480 x 640 像素) 真实世界室内，移动摄像头。aliberts/paris_street: (720 x 1280 像素) 真实世界室外，移动摄像头。aliberts/kitchen: (1080 x 1920 像素) 真实世界室内，固定摄像头。
编码参数
我们使用 FFmpeg 对视频进行编码。以下是我们主要调整的参数：
视频编解码器 (vcodec)
编解码器（编码器-解码器）是驱动视频编码的算法引擎。编解码器定义了用于编码和解码的格式。请注意，对于给定的编解码器，可能存在多种实现。例如，对于 AV1：`libaom`（官方实现）、`libsvtav1`（更快，仅编码器）、`libdav1d`（仅解码器）。
请注意，其余编码参数根据所使用的视频编解码器有不同的解释。换句话说，与一个编解码器一起使用的相同 `crf` 值不一定转换为另一个编解码器的相同压缩级别。事实上，不同视频编解码器的默认值（`None`）也不同。重要的是，许多其他 ffmpeg 参数也是如此，例如指定关键帧频率的 `g`。
像素格式 (pix_fmt)
像素格式指定了颜色空间 (YUV, RGB, 灰度) 以及，对于 YUV 颜色空间，色度子采样，它决定了色度（颜色信息）和亮度（亮度信息）在最终编码比特流中的实际存储方式。例如，`yuv420p` 表示 YUV 颜色空间，采用 4:2:0 色度子采样。这是网络视频和标准播放最常见的格式。对于 RGB 颜色空间，此参数指定每像素的位数（例如，`rbg24` 表示 RGB 颜色空间，每像素 24 位）。
图像组大小 (g)
GOP（图像组）大小决定了关键帧在编码比特流中出现的频率。该值越低，关键帧的放置频率越高。一个需要理解的关键点是，当请求给定时间戳的帧时，除非该帧本身恰好是关键帧，否则解码器将查找该时间戳之前的最后一个关键帧，并且需要解码所有后续帧直到请求的时间戳。这意味着增加 GOP 大小将增加帧的平均解码时间，因为可供起始的关键帧更少。对于典型的在线内容，如 YouTube 上的视频或 Netflix 上的电影，每 2 到 4 秒的视频放置一个关键帧（对于 24 fps 的视频，2 秒对应于 48 的 GOP 大小）通常会带来流畅的观看体验，因为这使得该用例的加载时间可接受（取决于硬件）。然而，对于训练策略，我们需要尽可能快地访问任何帧，这意味着我们可能需要一个低得多的 GOP 值。
恒定速率因子 (crf)
恒定速率因子表示应用的损失压缩量。值为 0 表示没有信息丢失，而高值（取决于所使用的编解码器，约 50-60）表示损失很大。使用此参数而不是指定目标比特率是更好的选择，因为它可以旨在实现具有潜在可变比特率的恒定视觉质量水平，而不是相反。
| crf | libx264 | libx265 | libsvtav1 |
|---|---|---|---|
10 |
|
|
|
30 |
|
|
|
50 |
|
|
|
此表总结了我们研究中尝试的不同值
| 参数 | 值 |
|---|---|
| vcodec | libx264, libx265, libsvtav1 |
| pix_fmt | yuv444p, yuv420p |
| g | 1, 2, 3, 4, 5, 6, 10, 15, 20, 40, None |
| crf | 0, 5, 10, 15, 20, 25, 30, 40, 50, None |
解码参数
解码器
我们测试了 torchvision 的两种视频解码后端
pyav（默认）视频阅读器
时间戳场景
鉴于视频解码的工作方式，一旦关键帧被加载，后续帧的解码速度会很快。这当然受到编码过程中 `-g` 参数的影响，该参数指定了关键帧的频率。考虑到我们在机器人策略中的典型用例可能需要不同随机位置的几个时间戳，我们希望通过以下场景来复制这些用例：
1_frame：1 帧，2_frames：2 个连续帧（例如[t, t + 1 / fps]），6_frames：6 个连续帧（例如[t + i / fps for i in range(6)]）
请注意，这与观看电影等典型用例显着不同，在电影中，每一帧都从头到尾按顺序加载，并且可以接受 `g` 的较大值。
此外，由于某些策略可能会请求间隔几帧的单个时间戳，因此我们还有以下场景：
2_frames_4_space：2 帧，中间有 4 个连续帧的间隔（例如[t, t + 5 / fps]），
然而，由于 `pyav` 中视频解码的实现方式，我们无法进行精确的查找，因此在实践中，此场景与 `6_frames` 基本相同，因为 `t` 和 `t + 5 / fps` 之间的所有 6 帧都将被解码。
结果
进行这项研究后，我们从 v1.6 版本开始切换到不同的编码。
| 代码库版本 | v1.5 | v1.6 |
|---|---|---|
| vcodec | libx264 |
libsvtav1 |
| 像素格式 | yuv444p |
yuv420p |
| g | 2 |
2 |
| crf | None (=23) |
30 |
我们通过 AV1 编码获得了更高的质量，同时使用了更兼容的 `yuv420p` 像素格式。
大小
我们在所有数据集的总大小上实现了约 14% 的平均压缩比。我们的大多数数据集都缩小到其原始大小的 40% 以下，有些甚至低于 1%。这些差异可归因于这些数据集源自的各种格式。文件大小缩减最大的数据集通常包含未压缩的图像，这使得编码器的时空压缩能够大幅减小其大小。另一方面，图像已经使用某种形式的空间压缩（例如 JPEG 或 PNG）存储的数据集，其文件大小缩减幅度较小。其他因素，例如图像分辨率，也会影响视频压缩的效率。
表 1：数据集大小比较
| 仓库 ID | 原始 | 我们的 (v1.6) | 比例 (我们的/原始) |
|---|---|---|---|
| lerobot/nyu_rot_dataset | 5.3MB | 318.2KB | 5.8% |
| lerobot/pusht | 29.6MB | 7.5MB | 25.3% |
| lerobot/utokyo_saytap | 55.4MB | 6.5MB | 11.8% |
| lerobot/imperialcollege_sawyer_wrist_cam | 81.9MB | 3.8MB | 4.6% |
| lerobot/utokyo_xarm_bimanual | 138.5MB | 8.1MB | 5.9% |
| lerobot/unitreeh1_two_robot_greeting | 181.2MB | 79.0MB | 43.6% |
| lerobot/usc_cloth_sim | 254.5MB | 23.7MB | 9.3% |
| lerobot/unitreeh1_rearrange_objects | 283.3MB | 138.4MB | 48.8% |
| lerobot/tokyo_u_lsmo | 335.7MB | 22.8MB | 6.8% |
| lerobot/utokyo_pr2_opening_fridge | 360.6MB | 29.2MB | 8.1% |
| lerobot/aloha_static_pingpong_test | 480.9MB | 168.5MB | 35.0% |
| lerobot/cmu_franka_exploration_dataset | 602.3MB | 18.2MB | 3.0% |
| lerobot/unitreeh1_warehouse | 666.7MB | 236.9MB | 35.5% |
| lerobot/cmu_stretch | 728.1MB | 38.7MB | 5.3% |
| lerobot/asu_table_top | 737.6MB | 39.1MB | 5.3% |
| lerobot/xarm_push_medium | 808.5MB | 15.9MB | 2.0% |
| lerobot/xarm_push_medium_replay | 808.5MB | 17.8MB | 2.2% |
| lerobot/xarm_lift_medium_replay | 808.6MB | 18.4MB | 2.3% |
| lerobot/xarm_lift_medium | 808.6MB | 17.3MB | 2.1% |
| lerobot/utokyo_pr2_tabletop_manipulation | 829.4MB | 40.6MB | 4.9% |
| lerobot/utokyo_xarm_pick_and_place | 1.3GB | 54.6MB | 4.1% |
| lerobot/aloha_static_ziploc_slide | 1.3GB | 498.4MB | 37.2% |
| lerobot/ucsd_kitchen_dataset | 1.3GB | 46.5MB | 3.4% |
| lerobot/berkeley_gnm_cory_hall | 1.4GB | 85.6MB | 6.0% |
| lerobot/aloha_static_thread_velcro | 1.5GB | 1.1GB | 73.2% |
| lerobot/austin_buds_dataset | 1.5GB | 87.8MB | 5.7% |
| lerobot/aloha_static_screw_driver | 1.5GB | 507.8MB | 33.1% |
| lerobot/aloha_static_cups_open | 1.6GB | 486.3MB | 30.4% |
| lerobot/aloha_static_towel | 1.6GB | 565.3MB | 34.0% |
| lerobot/dlr_sara_grid_clamp | 1.7GB | 93.6MB | 5.5% |
| lerobot/unitreeh1_fold_clothes | 2.0GB | 922.0MB | 44.5% |
| lerobot/droid_100* | 2.0GB | 443.0MB | 21.2% |
| lerobot/aloha_static_battery | 2.3GB | 770.5MB | 33.0% |
| lerobot/aloha_static_tape | 2.5GB | 829.6MB | 32.5% |
| lerobot/aloha_static_candy | 2.6GB | 833.4MB | 31.5% |
| lerobot/conq_hose_manipulation | 2.7GB | 634.9MB | 23.4% |
| lerobot/columbia_cairlab_pusht_real | 2.8GB | 84.8MB | 3.0% |
| lerobot/dlr_sara_pour | 2.9GB | 153.1MB | 5.1% |
| lerobot/dlr_edan_shared_control | 3.1GB | 138.4MB | 4.4% |
| lerobot/aloha_static_vinh_cup | 3.1GB | 1.0GB | 32.3% |
| lerobot/aloha_static_vinh_cup_left | 3.5GB | 1.1GB | 32.1% |
| lerobot/ucsd_pick_and_place_dataset | 3.5GB | 125.8MB | 3.5% |
| lerobot/aloha_mobile_elevator | 3.7GB | 558.5MB | 14.8% |
| lerobot/aloha_mobile_shrimp | 3.9GB | 1.3GB | 34.6% |
| lerobot/aloha_mobile_wash_pan | 4.0GB | 1.1GB | 26.5% |
| lerobot/aloha_mobile_wipe_wine | 4.3GB | 1.2GB | 28.0% |
| lerobot/aloha_static_fork_pick_up | 4.6GB | 1.4GB | 31.6% |
| lerobot/berkeley_cable_routing | 4.7GB | 309.3MB | 6.5% |
| lerobot/aloha_static_coffee | 4.7GB | 1.5GB | 31.3% |
| lerobot/nyu_franka_play_dataset* | 5.2GB | 192.1MB | 3.6% |
| lerobot/aloha_static_coffee_new | 6.1GB | 1.9GB | 31.5% |
| lerobot/austin_sirius_dataset | 6.5GB | 428.7MB | 6.4% |
| lerobot/cmu_play_fusion | 6.7GB | 470.2MB | 6.9% |
| lerobot/berkeley_gnm_sac_son* | 7.0GB | 501.4MB | 7.0% |
| lerobot/aloha_mobile_cabinet | 7.0GB | 1.6GB | 23.2% |
| lerobot/nyu_door_opening_surprising_effectiveness | 7.1GB | 378.4MB | 5.2% |
| lerobot/aloha_mobile_chair | 7.4GB | 2.0GB | 27.2% |
| lerobot/berkeley_fanuc_manipulation | 8.9GB | 312.8MB | 3.5% |
| lerobot/jaco_play | 9.2GB | 411.1MB | 4.3% |
| lerobot/viola | 10.4GB | 873.6MB | 8.2% |
| lerobot/kaist_nonprehensile | 11.7GB | 203.1MB | 1.7% |
| lerobot/berkeley_mvp | 12.3GB | 127.0MB | 1.0% |
| lerobot/uiuc_d3field* | 15.8GB | 1.4GB | 9.1% |
| lerobot/umi_cup_in_the_wild | 16.8GB | 2.9GB | 17.6% |
| lerobot/aloha_sim_transfer_cube_human | 17.9GB | 66.7MB | 0.4% |
| lerobot/aloha_sim_insertion_scripted | 17.9GB | 67.6MB | 0.4% |
| lerobot/aloha_sim_transfer_cube_scripted | 17.9GB | 68.5MB | 0.4% |
| lerobot/berkeley_gnm_recon* | 18.7GB | 29.3MB | 0.2% |
| lerobot/austin_sailor_dataset | 18.8GB | 1.1GB | 6.0% |
| lerobot/utaustin_mutex | 20.8GB | 1.4GB | 6.6% |
| lerobot/aloha_static_pro_pencil | 21.1GB | 504.0MB | 2.3% |
| lerobot/aloha_sim_insertion_human | 21.5GB | 87.3MB | 0.4% |
| lerobot/stanford_kuka_multimodal_dataset | 32.0GB | 269.9MB | 0.8% |
| lerobot/berkeley_rpt | 40.6GB | 1.1GB | 2.7% |
| lerobot/roboturk* | 45.4GB | 1.9GB | 4.1% |
| lerobot/iamlab_cmu_pickup_insert | 50.3GB | 1.8GB | 3.6% |
| lerobot/stanford_hydra_dataset | 72.5GB | 2.9GB | 4.0% |
| lerobot/berkeley_autolab_ur5* | 76.4GB | 14.4GB | 18.9% |
| lerobot/stanford_robocook* | 124.6GB | 3.8GB | 3.1% |
| lerobot/toto | 127.7GB | 5.3GB | 4.1% |
| lerobot/fmb* | 356.5GB | 4.2GB | 1.2% |
*这些数据集包含我们格式中未包含的深度图。
加载时间
得益于视频编码，我们的加载时间在分辨率方面得到了显著改善。这在解码多个连续帧的有利场景中尤其明显。
| 1 帧 | 2 帧 | 6 帧 |
|---|---|---|
 |
 |
 |
总结
我们的研究的全部结果可在此电子表格中查看。下表显示了在 `g=2` 和 `crf=30` 的情况下，使用 `backend=pyav` 并在所有时间戳模式（`1_frame`、`2_frames`、`6_frames`）下的平均结果。
表 2：视频大小与图像大小之比（越低越好）
| 仓库 ID | 百万像素 | libx264 | libx265 | libsvtav1 | ||
|---|---|---|---|---|---|---|
| yuv420p | yuv444p | yuv420p | yuv444p | yuv420p | ||
| lerobot/pusht_image | 0.01 | 16.97% | 17.58% | 18.57% | 18.86% | 22.06% |
| aliberts/aloha_mobile_shrimp_image | 0.31 | 2.14% | 2.11% | 1.38% | 1.37% | 5.59% |
| aliberts/paris_street | 0.92 | 2.12% | 2.13% | 1.54% | 1.54% | 4.43% |
| aliberts/kitchen | 2.07 | 1.40% | 1.39% | 1.00% | 1.00% | 2.52% |
表 3：视频和图像加载时间之比（越低越好）
| 仓库 ID | 百万像素 | libx264 | libx265 | libsvtav1 | ||
|---|---|---|---|---|---|---|
| yuv420p | yuv444p | yuv420p | yuv444p | yuv420p | ||
| lerobot/pusht_image | 0.01 | 25.04 | 29.14 | 4.16 | 4.66 | 4.52 |
| aliberts/aloha_mobile_shrimp_image | 0.31 | 63.56 | 58.18 | 1.60 | 2.04 | 1.00 |
| aliberts/paris_street | 0.92 | 3.89 | 3.76 | 0.51 | 0.71 | 0.48 |
| aliberts/kitchen | 2.07 | 2.68 | 1.94 | 0.36 | 0.58 | 0.38 |
表 4：质量（mse：越低越好，psnr 和 ssim：越高越好）
| 仓库 ID | 百万像素 | 数值 | libx264 | libx265 | libsvtav1 | ||
|---|---|---|---|---|---|---|---|
| yuv420p | yuv444p | yuv420p | yuv444p | yuv420p | |||
| lerobot/pusht_image | 0.01 | 均方误差 (mse) | 2.93E-04 | 2.09E-04 | 3.84E-04 | 3.02E-04 | 2.23E-04 |
| 峰值信噪比 (psnr) | 35.42 | 36.97 | 35.06 | 36.69 | 37.12 | ||
| 结构相似性指数 (ssim) | 98.29% | 98.83% | 98.17% | 98.69% | 98.70% | ||
| aliberts/aloha_mobile_shrimp_image | 0.31 | 均方误差 (mse) | 3.19E-04 | 3.02E-04 | 5.30E-04 | 5.17E-04 | 2.18E-04 |
| 峰值信噪比 (psnr) | 35.80 | 36.10 | 35.01 | 35.23 | 39.83 | ||
| 结构相似性指数 (ssim) | 95.20% | 95.20% | 94.51% | 94.56% | 97.52% | ||
| aliberts/paris_street | 0.92 | 均方误差 (mse) | 5.34E-04 | 5.16E-04 | 9.18E-03 | 9.17E-03 | 3.09E-04 |
| 峰值信噪比 (psnr) | 33.55 | 33.75 | 29.96 | 30.06 | 35.41 | ||
| 结构相似性指数 (ssim) | 93.94% | 93.93% | 83.11% | 83.11% | 95.50% | ||
| aliberts/kitchen | 2.07 | 均方误差 (mse) | 2.32E-04 | 2.06E-04 | 6.87E-04 | 6.75E-04 | 1.32E-04 |
| 峰值信噪比 (psnr) | 36.77 | 37.38 | 35.27 | 35.50 | 39.20 | ||
| 结构相似性指数 (ssim) | 95.47% | 95.58% | 95.11% | 95.13% | 96.84% | ||
策略
我们通过在我们的格式上训练一些策略，验证了这种新格式不会影响训练策略的性能。这些策略的性能与在图像版本上训练的策略性能相当。
图 1：在 pusht 数据集上进行 Diffusion 策略的训练曲线
图 2：在 aloha 数据集上进行 ACT 策略的训练曲线
策略也已在 AV1 编码的数据集上进行训练和评估，并与我们之前的参考（h264）进行比较
- 在 pusht 上进行扩散
- 在 aloha_sim_transfer_cube_human 上进行 ACT
- 在 aloha_sim_insertion_scripted 上进行 ACT
未来工作
视频编码/解码是一个庞大而复杂的主题，我们在此只触及了皮毛。以下是我们本次实验中未涉及的一些内容：
对于编码，存在此基准测试中未包含的其他编码参数。特别是
-preset允许选择编码预设。这表示一组选项，可以提供一定的编码速度与压缩比。如果未指定此参数，则对于 libx264 和 libx265，它被认为是 `medium`，对于 libsvtav1，它被认为是 `8`。-tune允许优化编码的某些方面（例如，电影质量、实时等）。特别是，可以使用 `fast decode` 选项来优化编码比特流以实现更快的解码。- 双Pass编码也值得研究，因为它提高了质量，尽管它可能会显著增加编码时间。请注意，由于我们主要关注解码性能（因为编码只在上传数据集之前完成一次），因此我们没有测量编码时间，也没有任何关于编码的指标。使用单Pass编码没有造成任何问题，并且在本次基准测试中没有花费大量时间（前提是使用 `libsvtav1` 而不是 `libaom` 进行 AV1 编码）。
这些参数和其他参数的更详细和全面的列表可在编解码器文档中找到
- h264: https://trac.ffmpeg.org/wiki/Encode/H.264
- h265: https://trac.ffmpeg.org/wiki/Encode/H.265
- AV1: https://trac.ffmpeg.org/wiki/Encode/AV1
同样，在解码方面，存在其他解码器，但未在当前的基准测试中实现。举例如下：
torchcodectorchaudioffmpegiodecordnvc
最后，我们没有研究带有深度图的视频编码。尽管我们确实移植了包含深度图图像的数据集，但我们目前尚未使用该模态。
