使用影片編碼擴充套件機器人資料集
在過去幾年中，基於文字和影像的模型效能顯著提高，這主要歸因於模型權重和資料集規模的擴大。雖然網際網路為大型語言模型（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
最後，我們沒有研究帶有深度圖的影片編碼。儘管我們確實移植了包含深度圖影像的資料集，但我們目前尚未使用該模態。
