Cara Melewati Pembatasan Unduhan Video YouTube

 (blog.0x7d0.dev)
6 poin oleh GN⁺ 2023-08-15 | 1 komentar | Bagikan ke WhatsApp
  • URL file YouTube bisa didapat lewat API /youtubei/v1/player, tetapi jika diunduh apa adanya kecepatannya menjadi sangat lambat karena pembatasan unduhan tidak resmi
  • Parameter kueri n yang ditambahkan ke URL sejak pertengahan 2021 harus diubah memakai algoritme JavaScript di base.js; jika gagal, YouTube diam-diam membatasi kecepatannya
  • Bahkan setelah n diproses dengan benar, waktu unduh tetap disesuaikan dengan durasi dan ukuran video; pada contoh, video 1.5GB diunduh sekitar 4.0MB/s
  • Dengan header HTTP Range, file dapat dipecah menjadi potongan 10MB dan diambil lewat koneksi baru sehingga tiap potongan bisa diunduh cepat sebelum pembatasan diterapkan
  • File akhir harus digabung dari stream video dan audio yang disediakan terpisah dengan ffmpeg, dan yt-dlp, VLC media player, NewPipe, serta node-ytdl-core juga memakai teknik serupa

Alur mendapatkan URL file YouTube

  • URL file media yang sebenarnya dapat diambil dengan memanggil endpoint /youtubei/v1/player
  • API ini mengembalikan judul video, deskripsi, thumbnail, dan informasi format, lalu dari daftar format kita bisa memilih URL file dengan kualitas yang diinginkan
    • ID video contoh adalah aqz-KE-bpKQ
    • Isi body permintaan memuat nilai seperti videoId, context.client.clientName, dan context.client.clientVersion
    • Nilai lain dalam objek context adalah prasyarat yang diverifikasi API, dan nilai yang diizinkan dapat ditemukan dengan mengamati permintaan dari browser web
  • Jika adaptiveFormats[0].url yang diterima dari API dipakai begitu saja, unduhan akan terasa nyaris diblokir
    • Pada contoh, file 1.5GB ditampilkan di kisaran 66.7kB/s
    • Kecepatan umumnya dibatasi sekitar 40~70kB/s
    • Mengunduh penuh video 10 menit bisa memakan waktu sekitar 6 jam 30 menit

Pembatasan pertama yang dibuat oleh parameter n

  • Sejak pertengahan 2021, YouTube menyertakan parameter kueri n pada sebagian besar URL file
  • Nilai ini harus diubah dengan algoritme JavaScript di dalam base.js yang didistribusikan bersama halaman web
  • YouTube memakai nilai n seperti challenge untuk membedakan apakah klien itu resmi atau tidak
    • Jika n tidak ada atau tidak diubah dengan benar, pembatasan kecepatan unduh akan diterapkan secara diam-diam
  • Karena algoritme transformasinya diobfuskasi dan sering berubah, pendekatan reverse engineering isi skrip setiap kali bukan cara yang praktis
  • Implementasi contoh mengunduh base.js dari versi player saat ini, mengekstrak kode transformasi n, lalu menjalankannya dengan nilai n asli
    • URL base.js dicari dari halaman embed YouTube
    • Nama fungsi challenge dan isi fungsi diekstrak dengan regex
    • Fungsi transformasi dijalankan dengan Node.js vm.runInNewContext
    • Parameter n pada URL diganti dengan nilai hasil transformasi

Pembatasan kecepatan yang tetap ada setelah transformasi n

  • Jika parameter n diubah dengan benar, pembatasan ekstrem awal memang hilang, tetapi YouTube tetap menerapkan pembatasan unduhan variabel
  • Tingkat pembatasannya berubah tergantung ukuran dan durasi video, dan disesuaikan agar waktu unduh menjadi sekitar setengah dari panjang video
  • Jika file media selalu diberikan secepat mungkin, dari sudut pandang layanan streaming hal itu bisa menjadi pemborosan bandwidth yang besar
  • Pada unduhan contoh, file 1.5GB diunduh sekitar 4.0MB/s

Menerima potongan kecil dengan cepat lewat HTTP Range

  • Inti metode bypass ini adalah mengunduh file dengan membaginya ke banyak bagian kecil menggunakan header HTTP Range
  • Header Range menentukan bagian file yang akan diterima pada tiap permintaan
    • Contoh: Range: bytes=2000-3000
  • Kode contoh memproses file media dalam segmen 10MB
    • Menghapus file output yang sudah ada
    • Menghitung rentang 10MB berikutnya berdasarkan jumlah byte yang sudah diterima
    • Menambahkan header Range pada tiap permintaan dan menerima data dengan responseType: 'stream'
    • Menulis data yang diterima ke akhir file
    • Menampilkan progres, ukuran total, dan kecepatan per segmen
  • Cara ini bekerja karena butuh waktu sebelum aturan pembatasan mulai berlaku, dan segmen kecil bisa diambil sangat cepat lewat koneksi baru
  • Pada output pengujian untuk file 1464.99MB, kecepatan berikut terlihat
    • Pada 0.68%: 46.73MB/s
    • Pada 1.37%: 60.98MB/s
    • Pada 2.05%: 71.94MB/s
    • Pada 6.14%: 104.17MB/s
  • Beberapa unduhan hampir memakai penuh koneksi 1Gb/s, dan kecepatan rata-ratanya biasanya berada di kisaran 50~70MB/s, yaitu 400~560Mb/s

Penggabungan video dan audio serta implementasi yang sudah ada

  • YouTube mendistribusikan kanal video dan audio sebagai file terpisah
  • Dengan struktur ini, video HD atau UHD dapat memakai ulang file audio yang sama sehingga menghemat ruang penyimpanan
  • Beberapa video juga menyediakan kanal audio berbeda menurut bahasa
  • Pada langkah terakhir, file video dan audio digabung menjadi satu dengan ffmpeg
    • -c copy menyalin stream tanpa re-encoding
    • -map 0:v:0 memilih stream video dari input pertama
    • -map 1:a:0 memilih stream audio dari input kedua
    • Setelah penggabungan, file video dan audio sementara dihapus
  • Seluruh kode contoh disediakan sebagai youtube-download.js
  • Sejumlah proyek memakai teknik serupa untuk melewati pembatasan YouTube

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-15
Komentar Hacker News

  • Dari yang saya lihat dalam diskusi repositori yt-dlp, pembatasan ini bisa dilewati bukan dengan header HTTP Range, melainkan cukup dengan menambahkan parameter kueri range=xxx
    Bahkan ketika rentangnya ditetapkan ke seluruh file, kecepatannya kembali maksimal, dan kalau ingatan saya benar, YouTube sudah mencabut pembatasan ini
    Referensi: https://github.com/yt-dlp/yt-dlp/issues/6400

  • Saya belum pernah mencobanya di YouTube, tetapi saya pernah mengunduh video dari situs streaming yang lebih mencurigakan dengan alat pengembang web
    Kebanyakan memakai proteksi berupa membuat pernyataan debugger yang tidak bisa dilewati saat alat pengembang dibuka, lalu menjalankan kode yang banyak memakai CPU—mungkin loop tak berujung atau penambang kripto—sehingga videonya berhenti
    Yang lebih penting, kode ini juga menghapus informasi permintaan jaringan sehingga analisis traffic yang sudah dikirim sejauh ini menjadi sulit, dan “pertahankan log” di Firefox seharusnya benar-benar mempertahankan log
    Ini bukan pertahanan yang sempurna, jadi pada akhirnya tidak ada video yang gagal saya ambil, tetapi saya ingin melihat materi yang menjelaskan cara kerja ini lebih mendalam

    • Belum lama ini ada tulisan yang membahas cara menghindari metode persis seperti ini, dan solusinya sederhana sekaligus efektif: membangun ulang browser sambil mengganti nama kata kunci debugger
      Sampai-sampai terasa lucu
      https://news.ycombinator.com/item?id=36961445
    • Untuk melewati teknik anti-debugging seperti itu, Anti-Anti-Debug [0] layak dicoba
      Ini ekstensi sederhana yang dulu saya buat dalam beberapa jam karena alasan serupa
      0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...
    • Fakta bahwa halaman bisa mengetahui apakah alat pengembang terbuka terasa seperti cacat besar di sisi browser
      Halaman web seharusnya sama sekali tidak bisa mengetahui apakah alat pengembang terbuka, dan rasanya ini bisa diimplementasikan dengan benar
    • Cara yang kadang berhasil di Firefox adalah menekan shift+klik kanan pada video → This Frame → Open Frame in New Tab
      Di tab baru, alat pengembang berfungsi
    • Jika sebuah halaman mencoba mendeteksi alat pengembang browser, untuk analisis traffic yang pertama terlintas adalah mencoba Wireshark

  • Pada tahap akhir, untuk terus menonton layar, kita harus membayar dengan WorldCoin, dan WorldCoin yang tidak bisa diperdagangkan itu tampaknya hanya bisa diperoleh dengan menonton iklan
    Orb kecil yang tertanam di layar akan mengawasinya, dan jangan-jangan dulu Anda tidak benar-benar percaya ini untuk pendapatan dasar
    Masalah pendapatan dasar sudah lama diselesaikan dengan rekening bank dan know-your-customer (KYC)

    • Tidak ada hubungannya dengan mata?

  • Saya penasaran apakah akhir-akhir ini ada yang mengalami masalah pembatasan kecepatan yt-dlp
    Saya selalu menonton YouTube dengan mpv, yang secara internal memakai yt-dlp, dan sejak minggu lalu kondisinya menjadi sangat buruk
    Awalnya mulai cepat sesuai batas yang saya tetapkan di 500kB/s, tetapi setelah beberapa saat, setiap 3 detik unduhan hanya mendapat 1 detik durasi pemutaran, sehingga harus dibiarkan mengantre cukup lama sebelum diputar
    Saya memakai yt-dlp versi git, tetapi belum melihat issue terkait

    • mpv hanya mendapatkan URL video lewat yt-dlp lalu meneruskan URL itu ke ffmpeg
      ffmpeg tidak mengimplementasikan workaround terkait header Range, sehingga terkena pembatasan kecepatan
      Bisa saja membiarkan yt-dlp mengunduh langsung lalu mem-pipe hasilnya ke mpv agar diputar dari input standar, tetapi seeking ke bagian yang belum diunduh akan rusak
      Ada banyak issue terkait masalah ini di issue tracker mpv

  • YouTube terus mengubah hal-hal kecil dalam proses ini
    Dulu saya membuat alat penyunting internal untuk video YouTube, dan karena memerlukan file MP4, kira-kira setiap bulan penyunting itu rusak akibat perubahan YouTube, sehingga saya harus memakai debugger untuk melihat apa yang berubah dan menyesuaikannya

  • Sedikit menyimpang, tapi saya penasaran apakah cuma perasaan bahwa video terlihat sedikit lebih bagus saat ditonton di YouTube
    Saya mengunduh video favorit dan menontonnya di VLC atau Infuse di AppleTV, dan lewat “nerd stats” di aplikasi YouTube saya bisa memastikan bahwa yang dilihat adalah stream video/audio yang sama
    Namun sepertinya YouTube menerapkan filter yang sangat halus untuk membuat artefak kompresi berbentuk blok tampak lebih lembut
    Bukan menajamkan tepi, melainkan terasa seperti mencari area perubahan warna tanpa tepi lalu membuat artefak blok jadi kurang mencolok
    Bisa saja hanya perasaan, tetapi di YouTube layar tampak lebih hidup dan solid, sementara pada video yang diunduh terlihat artefak dan jitter yang sangat halus namun kentara di latar belakang atau bayangan, sehingga bahkan video 1440p pun kualitas akhirnya terlihat kurang bagus
    Audionya juga jelas berbeda: di YouTube volume umumnya merata, sedangkan pada video yang diunduh saya harus menaikkan volume sehingga kurang nyaman
    Saya berharap VLC atau Infuse juga melakukan pemrosesan yang membuat video terlihat lebih enak seperti YouTube, dan rasanya bukan filter warna atau ketajaman, melainkan pemrosesan seperti audio leveling yang membuat pengalaman antarkanal konsisten

    • Untuk audio, saya bisa menjawab
      Sebagian besar situs streaming seperti YouTube dan Spotify memakai sesuatu yang disebut ReplayGain
      Itu adalah tag yang menghitung volume rata-rata video atau lagu, dan dihitung pada saat unggah
      Klien resmi YouTube memakai tag itu saat pemutaran untuk menyesuaikan volume, tetapi saat diunduh tag tersebut bisa hilang, atau MKV mungkin tidak mendukung tag ReplayGain secara bawaan
    • Filter scaling yang dipakai player dan cara chroma scaling memengaruhi ketajaman
      Jika stream beresolusi asli diputar layar penuh, perbedaan pada tepi hitam-putih seharusnya hilang
      Bergantung pada sistem operasi, Anda bisa menguji perbedaannya dengan cepat berpindah di antara dua aplikasi layar penuh, dan ISO 29170-2 merekomendasikan 5Hz
      Perubahan warna bisa berasal dari color space video atau kegagalan pemrosesan profil monitor; dalam kasus ini, screenshot juga bisa terlihat berbeda dari tampilan aplikasi sebenarnya
      Jitter bisa berupa frame drop, dan jika terlihat pikselasi di tepi objek berwarna, kemungkinan itu adalah chroma upscaling nearest-neighbor
    • Satu video YouTube memiliki beberapa stream video, audio, dan gabungan
      Stream yang dipilih browser bisa berbeda dari stream yang secara default dipilih youtube-dl atau fork-nya
      Dulu untuk sementara yang dipilih secara default adalah stream gabungan terbaik, tetapi stream audio dan video terbaik yang terpisah memiliki kualitas lebih tinggi
    • Player seperti VLC bisa melakukan lebih baik, dan Anda juga bisa membuat koreksi sendiri dengan GLSL
      Saya terutama menyukai paket shader anime4k; meski berbasis machine learning, ia bisa berjalan real-time di mpv dan sepertinya juga bisa di VLC
      Sesuai namanya, ini disesuaikan untuk animasi, tetapi denoising dan deblurring-nya cukup bagus sehingga sering membuat konten YouTube lebih enak ditonton, dan tahap restorasinya menangani artefak kompresi dengan cukup baik
      Namun karena terlalu disesuaikan untuk animasi, ia tidak selalu bekerja dengan baik dan malah bisa memperburuk hasil
      https://github.com/bloc97/Anime4K/releases
    • Pipeline video browser bisa berbeda dari yang dipakai VLC
      Anda bisa membuat dokumen HTML sederhana berisi elemen video yang menunjuk ke file lokal untuk membandingkannya

  • Saya heran setiap kali YT merilis tindakan setengah-setengah lagi terhadap downloader
    GOOG juga punya Widevine, jadi saya penasaran kenapa tidak memakainya

    • Versi perangkat lunak Widevine akan sepenuhnya dibobol dalam waktu sangat singkat dan bisa dilewati bahkan dengan add-on unduhan sekali klik
      Tidak ada yang berubah bagi pengguna, sementara YouTube hanya menanggung beban operasional Widevine
      Jika memakai versi berbasis hardware, bisa muncul banyak masalah pada perangkat yang tidak didukung
    • Sepertinya YouTube tidak terlalu peduli pada pembajakan konten atau penggunaan klien pihak ketiga itu sendiri
      Yang mereka pedulikan adalah pemborosan bandwidth
      Pada situs streaming video berbasis iklan, biaya bandwidth biasanya lebih mahal daripada pendapatan, dan Google bisa membuatnya nyaris masuk akal karena punya bandwidth murah sampai bisa menekan ISP untuk peering gratis
      Pembatasan kecepatan seperti ini adalah langkah untuk menyisakan sebagian besar bandwidth bagi pengguna sungguhan, bukan untuk orang yang menyedot semua konten
    • Alasan tidak memakai Widevine adalah karena ada tahap dekripsi tambahan yang membuatnya lambat, memaksa decoding video perangkat lunak sehingga lambat, dan browser web hanya mendukung bentuk Widevine terlemah yang efektivitasnya rendah
      Ini tidak terlalu efektif untuk mencapai tujuan, sekaligus berpotensi mendorong banyak pengguna keluar dari platform
    • Alasan utamanya adalah karena itu sedikit menurunkan efisiensi cache CDN sehingga menambah biaya, dan mereka harus mengoperasikan sistem manajemen kunci tambahan
      Pada skala YouTube, mereka ingin meminimalkan sistem seperti ini sebisa mungkin
      Selain itu, hal tersebut akan menjadikan Widevine Level 3 target serangan yang sangat besar
      Pada akhirnya ini soal persamaan finansial; uang yang hilang karena pemblokiran iklan belum cukup untuk menarik sakelar Widevine, tetapi sudah cukup untuk mengambil langkah yang lebih lemah, dan pasti ada juga tekanan dari label rekaman, jadi kemungkinan akan diterapkan lebih luas dalam beberapa tahun
      Jika menebak, awalnya akan dimulai dari video yang berisi musik label atau klip studio yang terdeteksi Content ID, lalu bisa menyediakan tag opsional untuk kreator lain
      Video seperti itu lebih berguna untuk monetisasi dan tidak langsung menghilangkan seluruh keuntungan CDN
    • Google kemungkinan ingin menekan klien pihak ketiga tetapi tetap mengizinkan orang melakukan arsip
      Mengambil langkah setengah-setengah seperti ini secara diam-diam adalah solusi yang sempurna sekaligus satu-satunya untuk mencapai tujuan itu

  • Saya selalu penasaran bagaimana YouTube mendistribusikan video
    Tetap berjalan baik bahkan saat internet kacau, dan di Amerika Selatan tidak semua platform berjalan lancar, tetapi YouTube adalah platform video yang paling mulus
    Yang paling mendekati adalah Netflix, tetapi tetap jauh tertinggal

    • Mereka menempatkan server cache di dalam jaringan ISP dekat rumah Anda
      ISP juga diuntungkan, jadi mereka mengizinkannya
      Bottleneck ISP adalah koneksi dari jaringan mereka sendiri ke backbone internet yang lebih luas, dan server cache CDN besar mengurangi beban besar pada bottleneck itu
      Dokumen konfigurasi serupa milik Netflix: https://openconnect.netflix.com/

  • Pernahkah Anda mencoba mengunduh video langsung dari YouTube?
    Jika dilakukan secara manual tanpa bergantung pada youtube-dl, yt-dlp, atau situs web semacam itu, ternyata jauh lebih rumit daripada yang dibayangkan

    • Dulu sekali saya pernah mengerjakan skrip Perl untuk melakukan hal seperti itu: https://www.perlmonks.org/?node_id=636777
      Tentu saja masalah dengan skrip seperti ini adalah kita harus terus mengejar perubahan yang dibuat YouTube untuk mencegah pengunduhan video
    • Saya menanganinya dengan menyuntikkan user script secara langsung
      Jika melihat WEI, ini adalah cara yang menggunakan USER AGENT saya, yang mungkin tidak akan bertahan lama
      Alih-alih bersusah payah mengimplementasikan ulang fungsi tanda tangan, decoding n, dan pembatasan kecepatan, saya mencari player.js dengan match(/(?:player\/([a-zA-Z0-9_-]+)\/)?(?:html5player|(?:www|player(?:_ias)?))[-\.]([^/]+?)(?:(?:\/html5player(?:-new)?)?|(?:\/[a-z]{2,3}_[A-Z]{2})?\/base)\.js/), lalu melakukan grep fungsi terkait di dalamnya dan memanggilnya langsung
      Dari sudut pandang YouTube, fungsi DRM mereka sendiri yang membukakan tautan .mp4 untuk saya, jadi bisa dibilang terlihat 100% normal
    • Maksudnya menekan tombol “Download” dan membayar biaya Premium?

  • Secara teknis semuanya menarik, tetapi jika secara etis tidak hanya berpikir “persetan Google”, rasanya masuk akal untuk berhenti pada optimasi pertama, yaitu lolos pemeriksaan browser sungguhan dan mendapatkan kecepatan browser biasa
    Pada tingkat itu, Anda tidak memboroskan sumber daya YouTube lebih banyak daripada pengguna browser dengan pemblokir iklan
    Menggunakan kecepatan penuh Gb/s tanpa membayar apa pun terasa seperti menguji nasib semua pengguna pemblokir iklan
    Tentu saja, pada akhirnya mungkin memang persetan Google

    • Secara teknis semua orang membayar biaya koneksi jaringan
      Saya tidak akan sampai mengatakan bahwa menghantam YouTube dengan kecepatan maksimum itu tidak etis, tetapi saya juga tidak akan menyalahkan YouTube jika mereka mengambil langkah untuk memblokirnya
      Saya memakai ekstensi browser yang menampilkan gambar media sosial dalam ukuran asli saat kursor diarahkan ke gambar, dan Instagram pernah menampilkan peringatan aktivitas tidak wajar serta ancaman penguncian akun
      Saya memeriksa apakah ekstensi itu melakukan scraping di belakang layar, tetapi tampaknya tidak ada masalah berarti; mungkin Meta melihat urutan permintaan yang berbeda dari klien standar dan menganggapnya sebagai scraping data
      Ini adalah pengulangan aksi dan reaksi; YouTube juga akan menerapkan penangkalnya sendiri sehingga scraper kembali merespons, tetapi karena konsumsi yang sah di klien resmi tidak mungkin lebih cepat dari 2x kecepatan pemutaran, suatu saat mereka mungkin bisa membatasi unduhan sampai sekitar tingkat itu
      Namun saya tetap berpendapat bahwa pengunduhan itu sendiri tidak boleh dibatasi
      Konten sudah dilindungi oleh hukum, dan kebanyakan orang mengunduh video untuk alasan yang wajar seperti pengarsipan, analisis, atau pembuatan video ulasan
      Konten YouTube tidak dibuat dalam ruang hampa, dan setelah dipublikasikan, ia menciptakan lingkungan tempat video baru dibuat, sehingga kebebasan berkreasi ini penting
    • Saya tidak begitu yakin seberapa besar ini merupakan penyalahgunaan
      Pada akhirnya, ini hanya menerima jumlah data yang sama dalam waktu lebih singkat, jadi memakai bandwidth lebih besar tetapi juga selesai lebih cepat
      Kasus penggunaan browser biasa tampaknya disesuaikan untuk situasi umum ketika orang tidak menonton video sampai selesai
      Jika sejak awal Anda berniat menonton semuanya dan menyimpannya, sulit dikatakan bahwa itu memakan lebih banyak bandwidth Google; hanya saja overhead bisa lebih besar karena jumlah koneksi
    • Perusahaan tidak punya etika, hanya kepentingan
      Wajar saja jika saya bertindak dengan cara serupa
    • Disebut sumber daya YouTube dan Gb/s, tetapi dalam sebagian besar kasus video disajikan dari dalam jaringan ISP yang sama
      Itu karena YouTube memiliki cache di hampir semua ISP dan internet exchange point di seluruh dunia, dan mungkin merupakan CDN terbesar yang pernah dibuat
      Misalnya URL YouTube milik penulis tulisan ini mengarah ke ISP Kanada, Videotron
      https://bgp.he.net/dns/rr1---sn-8qu-t0aee.googlevideo.com
    • Secara teknis video seharusnya bisa diunduh, dan tidak boleh diblokir
      Itu perlu bahkan untuk menyimpan bukti jika seseorang menyebarkan ujaran kebencian atau menghina saya dan keluarga saya
      Memang bisa saja merekam layar dengan camcorder, tetapi itu terdengar seperti solusi zaman batu
      Misalnya, di browser pada Mac, Netflix tidak memungkinkan pengambilan screenshot, sehingga bahkan pembuatan meme yang termasuk penggunaan wajar pun telah dirampas