2 poin oleh GN⁺ 2024-06-15 | 1 komentar | Bagikan ke WhatsApp
  • H.264, yang digunakan untuk video internet, Blu-ray, ponsel, kamera keamanan, dan drone, adalah standar kompresi video yang dikembangkan untuk mengirim video full-motion dengan bandwidth yang realistis
  • Video 1080p 60Hz tanpa kompresi mencapai sekitar 370MB/s berdasarkan perhitungan 1920×1080×60×3, sehingga disk Blu-ray 50GB pun sulit menampung lebih dari sekitar 2 menit
  • Inti kompresinya adalah kompresi lossy: mengurangi detail yang kurang terlihat, serta menurunkan jumlah data melalui transformasi ke domain frekuensi, kuantisasi, dan subsampling chroma
  • Kompresi arah waktu membagi frame menjadi I-frame, P-frame, dan B-frame, lalu merekonstruksi perubahan alih-alih seluruh frame menggunakan vektor gerak dari macroblock 16×16 piksel
  • Dalam contoh, video H.264 berdurasi 5 detik 60fps dengan 300 frame berukuran 175KB, sementara satu screenshot PNG berukuran 1015KB; video asli 1,2GB menyusut hingga 175KB

Data yang ingin dikurangi H.264

  • H.264 adalah standar codec kompresi video yang banyak digunakan di video internet, Blu-ray, ponsel, kamera keamanan, drone, dan sebagainya
  • Tujuannya adalah mengurangi bandwidth yang diperlukan untuk transmisi video full-motion
  • Banyak konsep yang dibahas di sini berlaku tidak hanya untuk H.264, tetapi juga untuk kompresi video secara umum

Mengapa video tanpa kompresi terlalu besar

  • File video tanpa kompresi yang sederhana adalah susunan buffer 2D berisi data piksel dari tiap frame, dan dapat dipandang sebagai array byte 3D dengan dua dimensi ruang dan satu dimensi waktu
  • Setiap piksel menggunakan 3 byte untuk tiga warna dasar: merah, hijau, dan biru
  • Video 1080p 60Hz menghasilkan sekitar 370MB/s data mentah dengan perhitungan berikut
    • 1920 × 1080 × 60 × 3
  • Pada ukuran ini, disk Blu-ray 50GB hanya dapat menampung sekitar 2 menit, dan pemindahan maupun penyimpanannya juga menjadi sulit

Video 5 detik yang lebih kecil daripada satu PNG

Informasi yang dibuang melalui kompresi lossy

  • H.264 adalah codec kompresi lossy, yang membuang bit yang kurang penting dan hanya mempertahankan bit yang penting
  • PNG adalah codec kompresi lossless, sehingga gambar sumber asli dapat dipulihkan bit demi bit dari gambar yang dienkode
  • H.264 tidak bekerja dengan cara memotong gambar atau membuang kuadran tertentu, melainkan mengurangi informasi detail seperti algoritme gambar lossy lainnya
  • Pada gambar contoh, detail seperti lubang pada grille speaker MacBook Pro menghilang, tetapi perbedaannya sulit disadari jika tidak diperbesar
  • Dengan tahap ini saja, gambar sudah menyusut hingga sekitar 7% dari ukuran aslinya

Entropi dan penghapusan redundansi

  • Entropi informasi adalah jumlah bit yang diperlukan untuk merepresentasikan suatu informasi, dan berbeda dari ukuran sederhana sebuah dataset
  • Ini dapat dipahami sebagai jumlah bit minimum yang diperlukan untuk merepresentasikan kemungkinan keadaan, seperti hasil lemparan koin
  • Jika 10 lemparan koin semuanya menghasilkan sisi kepala, alih-alih menulis HHHHHHHHHH, kita bisa menyatakannya lebih singkat sebagai “semua 10 kali kepala”
  • Proses ini menghapus redundansi dengan hanya mempersingkat representasi tanpa mengubah informasi itu sendiri
  • Encoder lossless tujuan umum seperti ini disebut entropy encoder

Domain frekuensi dan kuantisasi

  • Data yang berubah menurut ruang atau waktu dapat ditransformasikan ke sistem koordinat lain, dan nilai kecerahan gambar juga dapat direpresentasikan dalam domain frekuensi
  • Dalam domain frekuensi, komponen frekuensi rendah berada di dekat pusat, sedangkan komponen frekuensi tinggi berada di dekat tepi
  • Pola detail seperti grille halus pada gambar termasuk komponen frekuensi tinggi, sedangkan perubahan warna dan kecerahan yang halus termasuk komponen frekuensi rendah
  • Dengan memasking tepi gambar domain frekuensi, informasi frekuensi tinggi dapat dibuang; ketika ditransformasikan kembali ke koordinat x-y biasa, hasilnya menjadi gambar yang mirip dengan aslinya tetapi dengan detail yang berkurang
  • Mengubah ukuran mask juga memungkinkan pengaturan tingkat detail pada gambar keluaran
  • Dalam contoh, meski entropi informasinya hanya sekitar 2% dari aslinya, perbedaannya sulit disadari jika tidak diperbesar
  • Dalam kompresi lossy, proses ini disebut kuantisasi (quantization)

Subsampling chroma

  • Mata dan otak manusia sangat peka terhadap perubahan kecerahan, tetapi relatif kurang mampu membedakan perbedaan warna yang halus
  • Dalam sinyal TV, data warna RGB dikonversi menjadi Y+Cb+Cr
    • Y: luminance, pada dasarnya kecerahan hitam-putih
    • Cb, Cr: chroma, yaitu komponen warna
  • RGB dan YCbCr setara dari sisi entropi informasi
  • Pada era TV hitam-putih, hanya ada sinyal Y; ketika TV berwarna muncul, informasi warna dienkode sebagai Cb dan Cr lalu dikirim bersama Y
  • TV hitam-putih hanya melihat komponen Y, sedangkan TV berwarna menggunakan juga komponen chroma dan mengonversinya secara internal ke RGB
  • Cara yang digunakan dalam H.264 adalah menyimpan komponen Y pada resolusi penuh, sementara komponen C disimpan pada seperempat resolusi
  • Subsampling chroma membuang sebagian informasi warna untuk mengurangi bandwidth keseluruhan hingga setengah, sambil menjaga perbedaan visual tetap kecil
  • Teknik ini bukan fitur khusus H.264, dan telah digunakan luas selama puluhan tahun

Motion compensation dan kompresi arah waktu

  • H.264 adalah standar kompresi motion compensation
  • Lebih dari kompresi domain ruang dalam satu frame, H.264 menangani beberapa frame bersama-sama dalam arah waktu
  • Pada video seperti pertandingan tenis, ketika kamera tetap dan hanya bola yang bergerak, seluruh latar belakang tidak perlu disimpan setiap kali
  • Gambar biasanya dibagi menjadi macroblock 16×16 piksel, dan gerakan diperkirakan per blok ini
  • Secara garis besar ada tiga jenis frame
    • I-frame: frame yang memuat semua bit yang diperlukan untuk menyusun seluruh frame
    • P-frame: frame prediktif yang mengenkode vektor gerak tiap macroblock dari frame sebelumnya
    • B-frame: frame prediktif dua arah yang diprediksi dari frame masa lalu dan frame masa depan
  • Decoder memulai dari I-frame terakhir, lalu menyusun frame saat ini dengan menambahkan delta vektor gerak dari frame-frame berikutnya
  • Video contoh halaman utama Apple pada dasarnya berupa macroblock yang bergerak dari tiga I-frame, sehingga dapat dikompresi dengan sangat baik

Mengapa video sempat berhenti setelah diputar mundur

  • Fenomena ketika video seperti YouTube tidak langsung diputar dan sempat berhenti setelah dimundurkan beberapa detik berkaitan dengan struktur H.264
  • Saat pengguna melompat ke frame sembarang, decoder harus menghitung ulang mulai dari I-frame terdekat
  • Karena decoder harus mengakumulasi delta vektor gerak hingga frame berikutnya untuk membuat frame saat ini, biaya komputasinya besar
  • Cara ini sangat efisien secara ruang, tetapi membutuhkan komputasi untuk decoding

Tahap kompresi lossless terakhir

  • I-frame yang telah melalui tahap lossy masih menyisakan informasi redundan
  • Vektor gerak macroblock pada P-frame dan B-frame juga dapat membentuk grup dengan nilai yang sama
  • Terutama pada video uji yang layarnya mengalami panning, banyak macroblock bergerak dengan jumlah yang sama
  • Entropy encoder menangani redundansi seperti ini
  • Karena entropy encoder adalah encoder lossless tujuan umum, data masukan dapat dipulihkan

Contoh rasio kompresi

  • Video contoh asli direkam pada resolusi tidak lazim 1232×1154
  • Untuk 5 detik 60fps, ukuran aslinya sekitar 1,2GB menurut perhitungan berikut
    • 1232 × 1154 × 60 × 3 × 5
  • Video H.264 terkompresi berukuran 175KB
  • Jika dikonversi dengan analogi mobil dalam artikel, ini seperti mobil seberat 3000 pon menyusut menjadi 0,4 pon, yaitu 6,5 ons
  • Penjelasan rasio kompresi ini sangat menyederhanakan riset selama puluhan tahun, dan detail lebih lanjut dapat dilihat di H.264/MPEG-4 AVC Wikipedia Page

1 komentar

 
GN⁺ 2024-06-15
Pendapat Hacker News
  • AV1 adalah codec yang lisensinya lebih baik dan lebih ajaib
    Meta secara bertahap menjadikan stream VP9/AV1 sebagai baseline untuk streaming video: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
    Mereka juga memakai AV1 untuk panggilan video: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
    Microsoft juga mulai memakai AV1 di Teams, dan AV1 memiliki tool pengodean video yang sangat berguna khususnya untuk screen sharing: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
    Sebagian besar video yang dilihat di YouTube belakangan ini adalah VP9 atau AV1, dan H.264 hanya sesekali terlihat
    H.264 akan bertahan cukup lama, tetapi AV1 tampaknya besar kemungkinan menjadi baseline baru untuk video internet

    • Memang benar, tetapi adopsi encoding/decoding hardware belum sepenuhnya merata
      Dari sudut pandang developer, ini harus bisa diakses semua orang, tetapi saat ini kita masih menunggu sampai fitur tersebut menjangkau mayoritas pengguna
      Akan bagus jika lebih banyak pengguna membeli hardware yang memiliki encoding/decoding AV1, dan sepertinya dibutuhkan logo seperti “AV1 inside”
      Misalnya, di lini iPhone saat ini baru iPhone 15 Pro yang menyediakan decoding hardware
    • AV1 benar-benar mengerikan untuk di-encode dengan software
      Saya harus merekam video kuliah lalu mengunggahnya sebagai file 720p yang relatif kecil; videonya menampilkan orang yang bergerak perlahan di depan papan tulis putih dengan garis-garis tipis dan tajam, dalam pencahayaan yang kurang ideal, sehingga profil encoding bawaan x264 tidak cocok
      Meski begitu, setelah mengutak-atik pengaturan selama satu-dua hari, saya bisa menjalankannya semalaman setelah hari kuliah pada laptop dengan iGPU saja dari sekitar 2014, lalu mengunggah hasilnya keesokan harinya
      Sebaliknya, libaom memperkirakan rendering video 3 jam akan memakan waktu sekitar seminggu, dan nilai bawaannya terlalu buruk sehingga saya tidak punya waktu untuk bereksperimen
      Itu terjadi 4 tahun lalu, jadi mungkin sekarang sudah membaik, tetapi saya tidak berharap sampai ada keajaiban
    • Dalam ruang warna 8-bit, H.264/5 praktis hampir tidak mengalami block artifact, sedangkan AV1 sulit menghilangkannya kecuali dinaikkan ke 10-bit
      Itu tidak selalu menjadi masalah, tetapi masalah sebenarnya AV1 adalah kompresinya membutuhkan komputasi yang terlalu besar
    • Saya tidak bisa menghilangkan kesan bahwa sebagian besar video 720p yang saya lihat di YouTube dalam beberapa tahun terakhir kualitas gambarnya jauh memburuk
      Atau mungkin mata saya yang jadi lebih baik
      Akan bagus jika ada tulisan yang membahas topik ini secara mendalam
    • AV1 tidak mencapai kecepatan encoding/decoding secepat H.264
  • Tulisan terkait:
    H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - Maret 2022, 219 komentar
    H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - Mei 2019, 180 komentar
    H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - Mei 2018, 1 komentar
    H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - November 2016, 219 komentar

  • Sekarang, 8 tahun setelah tulisan itu dibuat, banyak paten H.264 akan segera berakhir, kira-kira dalam 1–2 tahun: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
    Ini tidak mengherankan mengingat versi pertama standar H.264 keluar pada 2003 dan paten biasanya berlaku selama 20 tahun
    Generasi sebelumnya, H.263 dan MPEG-4 ASP, patennya sudah berakhir dan berada di domain publik

    • Algoritma-algoritma penerusnya pada akhirnya juga akan diimplementasikan luas di hardware, dan sepertinya kita akan kembali terikat oleh masalah paten
  • Lalu bagaimana dengan H.265? Angkanya satu lebih besar, kan? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding

    • Saya sering melakukan kompresi video sebagai proyek hobi, dan kebanyakan tetap memakai H.264
      Encoding H.265 membutuhkan komputasi tambahan yang terlalu besar dibanding penghematan ukuran yang didapat
      Misalnya file yang dengan H.264 butuh 1 jam untuk diperkecil menjadi 1GB, dengan H.265 butuh 12 jam untuk menjadi 850MB
      Bergantung pada penggunaannya, versi H.264 yang dukungan kliennya jauh lebih luas mungkin tetap diperlukan
      Kalau punya sumber daya komputasi setingkat data center, atau menjalankan layanan streaming yang penghematan 150MB per video akan terakumulasi, mungkin masuk akal pindah ke H.265, tetapi dalam banyak kasus realistis sulit dibenarkan
    • Saya cukup suka HEVC/H.265
      Kualitasnya hampir setara VP9, tetapi karena masalah lisensi, sampai sekarang masih sulit diadopsi di mana-mana
      VVC/H.266 tampaknya mengalami masalah yang sama, sementara AV1 hampir sama bagusnya dan sudah diadopsi jauh lebih luas
    • H.264 terasa benar-benar berada di titik yang sangat baik dalam keseimbangan antara kompleksitas dan rasio kompresi
      Codec yang lebih baru memang mengompresi lebih baik, tetapi kompleksitasnya meningkat secara nonlinier
    • Saya punya banyak video lama berukuran besar dan berkualitas tinggi dalam berbagai format yang tidak efisien, jadi saya mengujinya, dan akhirnya semuanya saya encode ulang/transcode ke H.265
      Ukuran file menjadi jauh lebih kecil dibanding H.264
      Standarnya juga 10 tahun lebih muda daripada H.264; H.264 dari 2003, sedangkan H.265 dari 2013
    • Bagaimana dengan VVC(H.266)? https://en.wikipedia.org/wiki/Versatile_Video_Coding
  • Pada contoh “jika melempar koin 10 kali dan semuanya keluar sisi depan, tidak perlu menulis HHHHHHHHHH, cukup katakan ‘dilempar 10 kali dan semuanya sisi depan’”, sepertinya ada sedikit kompresi lossy pada string H itu

    • Sebenarnya “dilempar 10 kali dan semuanya sisi depan” jumlah karakternya lebih banyak, jadi itu pun bukan kompresi
    • Tapi kalau masing-masing diucapkan keras-keras, rasanya berbeda
  • Saya ingat saat H.264 pertama kali muncul
    Waktu itu saya sedang tergila-gila pada mplayer, jadi sering mengunduh dan membuild rilis terbaru
    Saat pertama kali mendapat file H.264, mplayer tidak bisa membacanya, jadi saya harus mengambil versi pengembangan dan membuild-nya
    Berhasil, dan saya menyadari dua hal: kualitas gambarnya luar biasa, dan Athlon 1800+ saya tidak sanggup menanganinya
    Di versi mplayer atau libavcodec berikutnya performanya meningkat besar, tetapi hari itu masih saya ingat

    • Saya juga begitu
      Sudah sangat lama saya tidak memakai mplayer, tetapi saat itu memang yang terbaik
      Dulu saya bekerja di sebuah perusahaan yang mengembangkan produk berbasis video, dan perusahaan lain di Las Vegas menjual “codec video inovatif” beserta player kepada para eksekutif kami; untuk menggunakannya kami harus menandatangani NDA
      Ketika dicoba, cara kerjanya seperti mplayer, bahkan terlalu mirip
      Setelah diselidiki 5 menit lagi, ketahuanlah semuanya, dan para eksekutif yang sudah membayar mahal kepada perusahaan itu jadi malu
      Di bidang teknologi pun, menipu pengambil keputusan nonteknis ternyata sangat mudah
      Karena mereka terlalu takut ketinggalan
      Orang pintar akan memanggil engineer yang bagus untuk evaluasi, sedangkan para korban Dunning-Kruger mengantre sambil membawa dompet
  • Ada masa ketika saya hendak meninggalkan startup yang diakuisisi pada 1999, dan saat itu saya sedang mengerjakan encoding MPEG
    Salah satu perusahaan yang saya wawancarai mengatakan mereka telah membuat metode kompresi video baru, dan setelah menandatangani NDA mereka memperlihatkan klip pendek yang di-encode/di-decode dengan codec perangkat lunak non-real-time
    Saya sedang diwawancarai sebagai orang yang akan membuat versi ASIC dari algoritme itu, dan hanya dengan melihat 1–2 menit outputnya saya sudah bisa menebak apa yang mereka lakukan
    Saya menganggap contoh yang mereka tunjukkan disesuaikan dengan kekuatan algoritmenya, lalu mengusulkan adegan yang lebih sulit, dan juga menjelaskan menurut saya metodenya seperti apa
    Mereka tidak mengonfirmasi maupun membantah, tetapi memanggil saya untuk wawancara kedua
    Pada wawancara kedua saya berbicara dengan pasangan pendiri yang menjadi CEO/CTO, dan rencana mereka ternyata bukan menjual ASIC, melainkan merahasiakan codec tersebut dan memakai ASIC untuk membangun jaringan kabel berbasis DSL guna distribusi video
    Saya berkata, “Rasanya seperti menemukan karburator yang lebih bagus lalu ingin membangun pabrik mobil untuk bersaing dengan GM,” dan mereka tidak menerimanya dengan baik
    Titik kait cerita ini dengan H.264 adalah klaim mereka bahwa “kompresi yang ada sudah mencapai batasnya, sehingga hanya codec kami yang bisa mengirim video berkualitas tinggi lewat jalur DSL”
    Saya menjawab bahwa compressor akan terus membaik, dan meskipun tidak begitu, ketika internet yang lebih cepat masuk ke rumah-rumah, ambang batas yang mereka yakini bisa mereka lampaui itu sendiri akan hilang
    Mereka mengatakan menurut hukum fisika ada batas laju bit yang bisa dikirim lewat kabel, dan batas itu sudah tercapai
    Saya tidak mendapat tawaran kerja, dan memang tidak menginginkannya
    Perusahaan itu mendapatkan uang VC tetapi tutup beberapa tahun kemudian, sementara orang lain membuat codec yang jauh lebih efisien, dan koneksi internet 2 Mbps ternyata bukan batas
    Algoritme aslinya pasti memuat banyak matematika cerdas dan kekuatan algoritmik, jadi secara teknis mereka bukan orang bodoh; mereka kurang naluri bisnis
    Diceritakan ulang seperti ini memang terdengar seperti orang sok tahu yang merasa tahu segalanya, tetapi itu salah satu dari dua kali dalam hidup saya ketika saya melihat sesuatu dan dalam hitungan detik mengetahui rahasia utamanya
    Contoh ketika saya justru bodoh jauh lebih banyak
    Algoritmenya tidak pernah dikonfirmasi, tetapi dari artefak siluet terlihat cukup jelas
    MPEG, seperti JPEG, mengompresi gambar menjadi blok-blok kecil (8x8, 16x16, dan seterusnya), yang membatasi jangkauan pemanfaatan redundansi spasial sekaligus membatasi biaya komputasi untuk menemukan redundansi tersebut
    Codec mereka tampak mirip dengan sesuatu yang diusulkan Microsoft pada akhir 1990-an untuk arsitektur grafis Talisman
    Alih-alih membaginya menjadi blok tetap, sepertinya mereka menganalisis urutan frame untuk menemukan wilayah yang konsisten secara struktural dengan batas semiacak
    Misalnya dalam pertandingan tenis, latar belakangnya cukup mendekati “benda tegar”, sehingga ketika kamera melakukan panning dan satu piksel bergerak, piksel-piksel di sekitarnya kemungkinan besar mengalami transformasi spasial yang sama
    Pemain berubah dari frame ke frame, tetapi gumpalan itu memiliki korelasi antara pencahayaan dan posisi
    Setelah mengidentifikasi wilayah seperti ini, mereka mungkin mengompresi gambar wilayah tersebut dengan cara mirip JPEG, lalu pada frame berikutnya menganalisis bagaimana suatu wilayah mengalami transformasi affine atau transformasi yang lebih umum ke frame berikutnya, dan mengodekannya dengan beberapa parameter
    Ini menjadi dasar prediksi frame berikutnya, dan jika cocok dengan baik, tidak banyak bit yang diperlukan untuk memperbaiki kesalahan prediksi

    • Saya tidak ingat nama perusahaan dan pendirinya, tetapi Google menemukannya: https://www.zdnet.com/article/high-hopes-for-video-compressi...
      Mereka menerima investasi VC sebesar 32 juta dolar dan keluar dari mode stealth pada 2002
      Saya tidak berhasil menemukan apa yang terjadi setelah itu
    • Daripada “secara teknis bukan orang bodoh”, jika mereka berasumsi ada batas keras pada efisiensi codec dan bandwidth internet, menurut saya mereka setidaknya naif secara teknis
  • Tulisannya sangat bagus, tetapi penggunaan frasa Information Entropy seolah-olah itu istilah terpisah termasuk salah satu ekspresi tipe “ATM machine” yang paling mengganggu
    Tulisannya sendiri bagus, tetapi frasanya benar-benar kuat

    • Bukankah sinyal dan noise itu tidak sama?
    • Meski begitu, menurut saya information entropy lebih menjelaskan dirinya sendiri daripada Shannon entropy
    • Jelas tidak relevan di sini, tetapi secara teknis bukankah ada juga entropi termal? Tidak selalu hanya merujuk pada informasi
  • Pada 02016, H.264 adalah keajaiban yang terikat paten di banyak negara
    Sekarang, standarnya dirilis pada Agustus 02004 setelah satu tahun proses standardisasi terbuka, paten hanya berlaku 20 tahun sejak tanggal pengajuan, dan sesuatu yang sudah dipublikasikan tidak bisa dipatenkan, jadi sebagian besar sudah kedaluwarsa atau akan kedaluwarsa dalam beberapa bulan
    Di AS ada masa tenggang satu tahun jika pengungkapannya dilakukan sendiri, tetapi jika ada pengecualian saya ingin sekali mendengarnya
    userbinator menunjuk ke https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264..., tetapi sebagian besar paten di sana memiliki tanggal prioritas setelah standar H.264 difinalkan, sehingga tidak mungkin esensial untuk implementasi H.264 itu sendiri
    Kecuali jika ada klaim bahwa pada saat standardisasi belum diketahui bahwa implementasi semacam itu mungkin dilakukan, tetapi itu kurang meyakinkan
    Yang mengejutkan adalah selama 20 tahun terakhir memang ada yang bisa disebut sedikit lebih baik, tetapi menurut pengujian saya dengan implementasi ffmpeg, tidak ada yang jauh lebih baik
    Jika status bebas paten terjamin, suka atau tidak, H.264 tampaknya sangat mungkin semakin mengukuhkan diri sebagai codec standar untuk sementara waktu
    AV1 memiliki kualitas visual yang sedikit lebih baik pada bandwidth yang sama, tetapi jauh lebih lambat, dan rentan terhadap paten yang diajukan selewat 02018

    • Jadi setelah melewati 2038 kita akan mendapatkan AV1 bebas paten!
    • Kenapa menambahkan satu 0 lagi di depan tahun?
  • “Karena meminta decoder melompat ke frame sembarang, ia harus mulai dari I-frame terdekat dan menghitung ulang penjumlahan delta vektor gerak sampai frame saat ini, sehingga berhenti sejenak” itu cerita tahun 2016
    Sekarang ini karena YouTube tahu kamu memakai Firefox