การหลีกเลี่ยงข้อจำกัดการดาวน์โหลดวิดีโอ YouTube

 (blog.0x7d0.dev)
6 คะแนน โดย GN⁺ 2023-08-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สามารถได้ URL ไฟล์ของ YouTube ผ่าน API /youtubei/v1/player แต่ถ้าดาวน์โหลดตรง ๆ ความเร็วจะช้ามากเพราะ ข้อจำกัดการดาวน์โหลดแบบไม่เป็นทางการ
  • ตั้งแต่กลางปี 2021 เป็นต้นมา พารามิเตอร์คิวรี n ที่ติดมากับ URL ต้องถูกแปลงด้วยอัลกอริทึม JavaScript ใน base.js หากล้มเหลว YouTube จะจำกัดความเร็วอย่างเงียบ ๆ
  • แม้จะจัดการ n ได้ถูกต้อง เวลาดาวน์โหลดก็ยังถูกปรับให้สอดคล้องกับความยาวและขนาดของวิดีโอ โดยในตัวอย่าง วิดีโอ 1.5GB ถูกดาวน์โหลดที่ราว 4.0MB/s
  • หากใช้เฮดเดอร์ HTTP Range แบ่งไฟล์เป็นชิ้นละ 10MB แล้วรับผ่านการเชื่อมต่อใหม่ จะสามารถดึงแต่ละชิ้นได้อย่างรวดเร็วก่อนที่ข้อจำกัดจะเริ่มทำงาน
  • ไฟล์สุดท้ายต้องนำ สตรีมวิดีโอและเสียง ที่ให้มาแยกกันมารวมด้วย ffmpeg และ yt-dlp, VLC media player, NewPipe, node-ytdl-core ก็ใช้เทคนิคคล้ายกัน

ขั้นตอนการได้ URL ไฟล์ YouTube

  • URL ไฟล์สื่อจริงสามารถดึงได้ด้วยการเรียก endpoint /youtubei/v1/player
  • API นี้ส่งคืนชื่อวิดีโอ คำอธิบาย thumbnail และข้อมูล format โดยสามารถเลือก URL ไฟล์คุณภาพที่ต้องการจากรายการ format ได้
    • ID วิดีโอตัวอย่างคือ aqz-KE-bpKQ
    • body ของคำขอมีค่าอย่าง videoId, context.client.clientName, context.client.clientVersion
    • ค่าอื่น ๆ ในอ็อบเจกต์ context เป็นเงื่อนไขตั้งต้นที่ API ตรวจสอบ และสามารถหาค่าที่อนุญาตได้จากการสังเกตคำขอของเว็บเบราว์เซอร์
  • หากใช้ adaptiveFormats[0].url ที่ได้จาก API ตรง ๆ การดาวน์โหลดจะช้าจนแทบเหมือนถูกบล็อก
    • ในตัวอย่าง ไฟล์ 1.5GB แสดงความเร็วระดับ 66.7kB/s
    • โดยทั่วไปความเร็วจะถูกจำกัดไว้ที่ 40~70kB/s
    • การดาวน์โหลดวิดีโอ 10 นาทีจนเสร็จอาจใช้เวลาประมาณ 6 ชั่วโมง 30 นาที

ข้อจำกัดแรกที่พารามิเตอร์ n สร้างขึ้น

  • ตั้งแต่กลางปี 2021 เป็นต้นมา YouTube ใส่ พารามิเตอร์คิวรี n ไว้ใน URL ไฟล์ส่วนใหญ่
  • ค่านี้ต้องถูกแปลงด้วยอัลกอริทึม JavaScript ใน base.js ที่แจกมาพร้อมหน้าเว็บ
  • YouTube ใช้ค่า n คล้ายกับ challenge เพื่อแยกแยะว่าเป็นไคลเอนต์ทางการหรือไม่
    • หากไม่มี n หรือไม่ได้แปลงอย่างถูกต้อง จะมีการจำกัดความเร็วดาวน์โหลดแบบเงียบ ๆ
  • อัลกอริทึมการแปลงถูกทำให้เข้าใจยากและเปลี่ยนบ่อย ดังนั้นวิธี reverse engineering เนื้อหาในแต่ละครั้งจึงไม่ใช่วิธีที่ใช้งานได้จริง
  • ตัวอย่างการ implement จะดาวน์โหลด base.js ของเวอร์ชัน player ปัจจุบัน ดึงโค้ดแปลง n ออกมา แล้วรันโดยใส่ค่า n เดิมเข้าไป
    • หา URL ของ base.js จากหน้า embed ของ YouTube
    • ใช้ regular expression ดึงชื่อฟังก์ชัน challenge และ body ของฟังก์ชันออกมา
    • รันฟังก์ชันแปลงด้วย vm.runInNewContext ของ Node.js
    • แทนที่พารามิเตอร์ n ใน URL ด้วยค่าที่แปลงแล้ว

ข้อจำกัดความเร็วที่ยังเหลือหลังแปลง n

  • เมื่อแปลงพารามิเตอร์ n ได้ถูกต้อง ข้อจำกัดรุนแรงในตอนแรกจะหายไป แต่ YouTube ยังคงใช้ ข้อจำกัดการดาวน์โหลดแบบแปรผัน อยู่
  • ระดับข้อจำกัดจะแตกต่างกันตามขนาดและความยาวของวิดีโอ โดยถูกปรับให้เวลาดาวน์โหลดอยู่ที่ประมาณครึ่งหนึ่งของความยาววิดีโอ
  • หากให้บริการไฟล์สื่อด้วยความเร็วสูงสุดเสมอ สำหรับบริการสตรีมมิงแล้วอาจเป็นการสิ้นเปลือง bandwidth อย่างมาก
  • ในตัวอย่างการดาวน์โหลด ไฟล์ 1.5GB ถูกดาวน์โหลดที่ประมาณ 4.0MB/s

รับชิ้นส่วนเล็ก ๆ อย่างรวดเร็วด้วย HTTP Range

  • หัวใจของวิธีหลีกเลี่ยงคือการใช้เฮดเดอร์ HTTP Range แบ่งไฟล์ออกเป็นช่วงเล็ก ๆ หลายช่วงเพื่อดาวน์โหลด
  • เฮดเดอร์ Range ระบุช่วงของไฟล์ที่จะรับในแต่ละคำขอ
    • ตัวอย่าง: Range: bytes=2000-3000
  • โค้ดตัวอย่างแบ่งไฟล์สื่อเป็น segment ขนาด 10MB เพื่อประมวลผล
    • ลบไฟล์ output เดิม
    • คำนวณช่วง 10MB ถัดไปจากจำนวน byte ที่ได้รับมาจนถึงปัจจุบัน
    • ใส่เฮดเดอร์ Range ในแต่ละคำขอและรับด้วย responseType: 'stream'
    • เขียนข้อมูลที่ได้รับต่อท้ายไฟล์
    • แสดงความคืบหน้า ขนาดรวม และความเร็วของแต่ละ segment
  • วิธีนี้ทำงานได้เพราะกฎจำกัดต้องใช้เวลาสักพักก่อนจะถูกนำมาใช้ และ segment ขนาดเล็กสามารถรับได้เร็วมากผ่านการเชื่อมต่อใหม่
  • ในผลการทดสอบ สำหรับไฟล์ 1464.99MB พบความเร็วดังนี้
    • จุด 0.68%: 46.73MB/s
    • จุด 1.37%: 60.98MB/s
    • จุด 2.05%: 71.94MB/s
    • จุด 6.14%: 104.17MB/s
  • การดาวน์โหลดบางครั้งใช้ การเชื่อมต่อ 1Gb/s ได้เกือบเต็ม และความเร็วเฉลี่ยมักอยู่ในช่วง 50~70MB/s หรือ 400~560Mb/s

การรวมวิดีโอ·เสียงและ implementation ที่มีอยู่

  • YouTube แจกจ่าย ช่องวิดีโอและเสียง เป็นไฟล์แยกกัน
  • โครงสร้างนี้ช่วยประหยัดพื้นที่จัดเก็บ เพราะวิดีโอ HD หรือ UHD สามารถใช้ไฟล์เสียงเดียวกันซ้ำได้
  • วิดีโอบางรายการยังให้ช่องเสียงที่แตกต่างกันตามภาษา
  • ในขั้นตอนสุดท้าย จะใช้ ffmpeg รวมไฟล์วิดีโอและไฟล์เสียงเป็นไฟล์เดียว
    • ใช้ -c copy เพื่อคัดลอก stream โดยไม่ re-encode
    • ใช้ -map 0:v:0 เพื่อเลือก stream วิดีโอจาก input แรก
    • ใช้ -map 1:a:0 เพื่อเลือก stream เสียงจาก input ที่สอง
    • หลังรวมแล้วให้ลบไฟล์วิดีโอ·เสียงชั่วคราว
  • โค้ดตัวอย่างทั้งหมดมีให้ที่ youtube-download.js
  • หลายโปรเจกต์ใช้เทคนิคคล้ายกันเพื่อหลีกเลี่ยงข้อจำกัดของ YouTube
    • yt-dlp: เป็น fork ภาษา Python ของ youtube-dl และมี JavaScript interpreter ของตัวเองสำหรับแปลงพารามิเตอร์ n
    • VLC media player
    • NewPipe
    • node-ytdl-core

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-08-15
ความคิดเห็นบน Hacker News

  • จากที่เห็นในการอภิปรายในรีโพซิทอรี yt-dlp ข้อจำกัดนี้เลี่ยงได้เพียงแค่เติม พารามิเตอร์คิวรี range=xxx ไม่ใช่ HTTP Range header
    แม้จะกำหนดช่วงเป็นทั้งไฟล์ ความเร็วสูงสุดก็กลับมาอีกครั้ง และถ้าจำไม่ผิด YouTube ได้ยกเลิกข้อจำกัดนี้ไปแล้ว
    อ้างอิง: https://github.com/yt-dlp/yt-dlp/issues/6400

  • ยังไม่เคยลองกับ YouTube แต่เคยใช้ เครื่องมือนักพัฒนาเว็บ ดาวน์โหลดวิดีโอจากเว็บสตรีมมิงที่น่าสงสัยกว่านั้น
    ส่วนใหญ่พอเปิดเครื่องมือนักพัฒนา เว็บจะสร้างคำสั่ง debugger ที่ข้ามไม่ได้ แล้วรันโค้ดที่กิน CPU หนัก ๆ อาจเป็นลูปไม่รู้จบหรือเครื่องขุดคริปโต เพื่อทำให้วิดีโอหยุด
    ที่สำคัญกว่านั้นคือโค้ดนี้ยังลบข้อมูลคำขอเครือข่าย ทำให้วิเคราะห์ทราฟฟิกที่ส่งไปจนถึงตอนนั้นได้ยาก และ “Preserve log” ของ Firefox ก็ควรจะรักษาล็อกไว้จริง ๆ
    มันไม่ใช่การป้องกันที่สมบูรณ์แบบ สุดท้ายก็ไม่เคยมีวิดีโอไหนที่ดาวน์โหลดไม่ได้ แต่อยากเห็นเอกสารที่อธิบายหลักการทำงานนี้ให้ลึกกว่านี้

    • ไม่นานมานี้มีโพสต์ที่หลบวิธีแบบนี้ได้พอดี และวิธีแก้ก็เรียบง่ายแต่ได้ผล: สร้างเบราว์เซอร์ใหม่โดยเปลี่ยน ชื่อคีย์เวิร์ด debugger ไปเลย
      ถึงกับขำออกมา
      https://news.ycombinator.com/item?id=36961445
    • ถ้าต้องการเลี่ยงเทคนิค anti-debugging แบบนั้น Anti-Anti-Debug [0] ก็น่าลองใช้
      เป็นส่วนขยายง่าย ๆ ที่เคยทำขึ้นในไม่กี่ชั่วโมงด้วยเหตุผลคล้ายกัน
      0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...
    • แค่การที่เว็บเพจรู้ได้ว่าเครื่องมือนักพัฒนาถูกเปิดอยู่หรือไม่ ก็รู้สึกเหมือนเป็นข้อบกพร่องใหญ่ฝั่งเบราว์เซอร์แล้ว
      เว็บเพจไม่ควรมีทางรู้ได้เลยว่าเครื่องมือนักพัฒนาเปิดอยู่หรือไม่ และน่าจะทำให้ถูกต้องได้
    • วิธีที่บางครั้งใช้ได้ใน Firefox คือกด shift+คลิกขวา บนวิดีโอ → This Frame → Open Frame in New Tab
      ในแท็บใหม่ เครื่องมือนักพัฒนาจะทำงานได้
    • ถ้าเป็นเพจที่พยายามตรวจจับเครื่องมือนักพัฒนาของเบราว์เซอร์ สำหรับการวิเคราะห์ทราฟฟิก สิ่งแรกที่นึกถึงคือใช้ Wireshark

  • ในขั้นสุดท้าย ถ้าจะดูหน้าจอต่อไปคงต้องจ่ายด้วย WorldCoin และ WorldCoin ที่แลกเปลี่ยนไม่ได้เหล่านั้นก็น่าจะหาได้ด้วยการดูโฆษณาเท่านั้น
    Orb ขนาดเล็กที่ฝังอยู่ในหน้าจอจะคอยตรวจสอบเรื่องนี้ และคงไม่ได้เชื่อจริง ๆ หรอกนะว่านี่ทำไปเพื่อรายได้พื้นฐาน
    ปัญหารายได้พื้นฐานถูกแก้ด้วยบัญชีธนาคารและการยืนยันตัวตนลูกค้า (KYC) มานานแล้ว

    • ไม่เกี่ยวอะไรกับตาเลยเหรอ?

  • สงสัยว่าช่วงนี้มีใครเจอปัญหา การจำกัดความเร็ว yt-dlp บ้างไหม
    ปกติดู YouTube ผ่าน mpv ตลอด ซึ่งภายในใช้ yt-dlp และตั้งแต่สัปดาห์ที่แล้วสภาพแย่มาก
    ตอนแรกเริ่มได้เร็วเท่าที่ตั้งลิมิตไว้ที่ 500kB/s แต่ผ่านไปสักพัก ดาวน์โหลด 3 วินาทีได้ข้อมูลสำหรับเล่นแค่ 1 วินาที เลยต้องปล่อยให้บัฟเฟอร์รอนานมากก่อนเล่น
    ใช้ yt-dlp เวอร์ชัน git อยู่ แต่ไม่เห็นอิชชูที่เกี่ยวข้อง

    • mpv ใช้ yt-dlp เพื่อดึงแค่ URL วิดีโอ แล้วส่ง URL นั้นต่อให้ ffmpeg
      ffmpeg ไม่ได้ implement วิธีเลี่ยงเกี่ยวกับ Range header จึงโดนจำกัดความเร็ว
      สามารถให้ yt-dlp ดาวน์โหลดโดยตรงแล้ว pipe ไปให้ mpv เล่นจาก standard input ได้ แต่การ seek ไปยังช่วงที่ยังไม่ได้ดาวน์โหลดจะพัง
      ใน issue tracker ของ mpv มีอิชชูเกี่ยวกับเรื่องนี้อยู่มาก

  • YouTube คอยเปลี่ยนรายละเอียดเล็ก ๆ ในกระบวนการนี้อยู่เรื่อย ๆ
    สมัยก่อนเคยทำเครื่องมือแก้ไขภายในสำหรับวิดีโอ YouTube ซึ่งต้องใช้ไฟล์ MP4 และประมาณเดือนละครั้งตัวแก้ไขจะพังเพราะ การเปลี่ยนแปลงของ YouTube จนต้องใช้ดีบักเกอร์ตรวจว่าอะไรเปลี่ยนไปแล้วปรับให้เข้ากัน

  • นอกเรื่องนิดหนึ่ง แต่สงสัยว่าเป็นแค่ความรู้สึกไปเองหรือเปล่าที่พอดูบน YouTube แล้ววิดีโอดูดีกว่านิด ๆ
    ผมดาวน์โหลดวิดีโอที่ดูบ่อย ๆ มาดูด้วย VLC หรือ Infuse บน AppleTV และจาก “nerd stats” ในแอป YouTube ก็ยืนยันได้ว่าเป็นสตรีมวิดีโอ/ออดิโอเดียวกัน
    แต่เหมือนว่า YouTube ใส่ฟิลเตอร์ที่ละเอียดมาก ๆ เพื่อทำให้อาร์ติแฟกต์จากการบีบอัดแบบเป็นบล็อกดูนุ่มลง
    ไม่ใช่การเน้นขอบ แต่ให้ความรู้สึกเหมือนมันหาบริเวณที่มีการเปลี่ยนสีแต่ไม่มีขอบ แล้วทำให้อาร์ติแฟกต์แบบบล็อกสังเกตเห็นได้น้อยลง
    อาจเป็นแค่ผมคิดไปเองก็ได้ แต่บน YouTube ภาพดูสดและแน่นกว่า ส่วนวิดีโอที่ดาวน์โหลดมาจะเห็นอาร์ติแฟกต์และการสั่นยิบ ๆ ที่ละเอียดมากแต่สังเกตได้ในพื้นหลังหรือเงา ทำให้แม้วิดีโอ 1440p ก็ยังดูเหมือนคุณภาพสุดท้ายด้อยกว่า
    ออดิโอก็ต่างกันชัดเจน โดย YouTube โดยทั่วไปมีระดับเสียงสม่ำเสมอ แต่ไฟล์ที่ดาวน์โหลดมาต้องเร่งเสียงขึ้น ซึ่งไม่สะดวก
    อยากให้ VLC หรือ Infuse ประมวลผลภาพให้ดูดีขึ้นแบบ YouTube ด้วย และดูเหมือนไม่ใช่ฟิลเตอร์สีหรือความคมชัด แต่เป็นการประมวลผลคล้าย audio leveling ที่ทำให้ประสบการณ์ระหว่างช่องต่าง ๆ สม่ำเสมอ

    • เรื่องออดิโอตอบได้
      เว็บไซต์สตรีมมิงส่วนใหญ่อย่าง YouTube และ Spotify ใช้สิ่งที่เรียกว่า ReplayGain
      มันเป็นแท็กที่คำนวณระดับเสียงเฉลี่ยของวิดีโอหรือเพลง และคำนวณตอนอัปโหลด
      ไคลเอนต์ YouTube อย่างเป็นทางการใช้แท็กนั้นเพื่อปรับระดับเสียงตอนเล่น แต่ตอนดาวน์โหลดแท็กอาจหายไป หรือ MKV อาจไม่รองรับแท็ก ReplayGain โดยค่าเริ่มต้น
    • ฟิลเตอร์สเกลภาพ และวิธีสเกล chroma ที่เพลเยอร์ใช้มีผลต่อความคมชัด
      ถ้าเล่นสตรีมที่ความละเอียดต้นฉบับแบบเต็มจอ ความต่างบนขอบขาวดำควรหายไป
      แล้วแต่ระบบปฏิบัติการ คุณอาจทดสอบความต่างได้โดยสลับไปมาระหว่างแอปเต็มจอสองตัวอย่างรวดเร็ว และ ISO 29170-2 แนะนำ 5Hz
      ความเปลี่ยนแปลงของสีอาจมาจาก color space ของวิดีโอหรือการจัดการโปรไฟล์จอภาพที่ล้มเหลว ซึ่งในกรณีนั้นสกรีนช็อตก็อาจดูต่างจากภาพจริงในแอป
      การสั่นยิบ ๆ อาจเป็นเฟรมตก และถ้าเห็นพิกเซลแตกบริเวณขอบของวัตถุที่มีสี ก็อาจเป็น nearest-neighbor chroma upscaling
    • วิดีโอ YouTube หนึ่งรายการมี สตรีมวิดีโอ·ออดิโอ·รวม หลายแบบ
      สตรีมที่เบราว์เซอร์เลือกอาจต่างจากสตรีมที่ youtube-dl หรือ fork เลือกเป็นค่าเริ่มต้น
      สมัยก่อนช่วงหนึ่งมันเลือกสตรีมรวมที่ดีที่สุดเป็นค่าเริ่มต้น แต่สตรีมออดิโอและวิดีโอที่แยกกันคุณภาพสูงสุดจะมีคุณภาพดีกว่า
    • เพลเยอร์อย่าง VLC สามารถทำได้ดีกว่านี้ และคุณยังสร้างการปรับแต่งที่ต้องการเองด้วย GLSL ได้ด้วย
      โดยเฉพาะผมชอบชุดเชดเดอร์ anime4k ซึ่งแม้จะอิง machine learning แต่รันแบบเรียลไทม์ได้ใน mpv และก็น่าจะใช้กับ VLC ได้
      ตามชื่อแล้วมันปรับมาสำหรับแอนิเมชัน แต่การลด noise และ deblur ทำได้ดี จึงมักทำให้คอนเทนต์ YouTube ดูดีขึ้น และขั้นตอน restore ก็จัดการอาร์ติแฟกต์จากการบีบอัดได้ค่อนข้างดี
      แต่เพราะมันจูนมาสำหรับแอนิเมชันมากเกินไป จึงไม่ได้ทำงานดีเสมอไป และบางครั้งอาจทำให้แย่ลงด้วย
      https://github.com/bloc97/Anime4K/releases
    • วิดีโอไพป์ไลน์ ของเบราว์เซอร์อาจต่างจากที่ VLC ใช้
      ลองสร้างเอกสาร HTML ง่าย ๆ ที่มีองค์ประกอบ video ชี้ไปยังไฟล์โลคัลแล้วเปรียบเทียบดูได้

  • แปลกใจทุกครั้งที่ YT ปล่อยมาตรการครึ่ง ๆ กลาง ๆ อีกชุดใส่ downloader
    GOOG ก็มี Widevine อยู่แล้ว เลยสงสัยว่าทำไมไม่ใช้

    • Widevine เวอร์ชันซอฟต์แวร์จะถูกเจาะจนหมดภายในเวลาอันสั้นมาก และแม้แต่ add-on ดาวน์โหลดแบบคลิกเดียวก็จะเลี่ยงได้
      ผู้ใช้จะไม่เห็นอะไรเปลี่ยนไป ส่วน YouTube ก็แค่ต้องแบกรับภาระการดูแล Widevine
      ถ้าใช้เวอร์ชันที่อิงฮาร์ดแวร์ ก็อาจเกิดปัญหามากมายบนอุปกรณ์ที่ไม่รองรับ
    • ดูเหมือน YouTube ไม่ได้ใส่ใจมากนักกับการละเมิดลิขสิทธิ์คอนเทนต์หรือการใช้ไคลเอนต์ของบุคคลที่สามในตัวมันเอง
      สิ่งที่ใส่ใจคือ การสิ้นเปลืองแบนด์วิดท์
      สำหรับเว็บสตรีมวิดีโอที่พึ่งโฆษณา โดยทั่วไปต้นทุนแบนด์วิดท์จะแพงกว่ารายได้ แต่ Google มีแบนด์วิดท์ราคาถูกมากพอถึงขั้นกดดัน ISP ให้ทำ peering ฟรีได้ จึงพอทำให้โมเดลนี้อยู่ได้
      การจำกัดความเร็วแบบนี้เป็นมาตรการเพื่อเหลือแบนด์วิดท์ส่วนใหญ่ไว้ให้ผู้ใช้จริง ไม่ใช่คนที่ดูดคอนเทนต์ทั้งหมดไป
    • เหตุผลที่ไม่ใช้ Widevine คือมันเพิ่มขั้นตอนถอดรหัส ทำให้ช้าลง บังคับให้ถอดรหัสวิดีโอด้วยซอฟต์แวร์ซึ่งช้า และเว็บเบราว์เซอร์รองรับได้แค่ รูปแบบ Widevine ที่อ่อนที่สุด ซึ่งได้ผลน้อย
      มันไม่ได้มีประสิทธิภาพนักในการบรรลุเป้าหมาย แถมมีโอกาสสูงที่จะผลักผู้ใช้จำนวนมากออกจากแพลตฟอร์ม
    • เหตุผลหลักคือมันทำให้ ประสิทธิภาพแคช CDN ลดลงเล็กน้อยจนเกิดต้นทุน และต้องดูแลระบบจัดการคีย์เพิ่มเติม
      ในสเกลของ YouTube พวกเขาอยากลดระบบแบบนี้ให้มากที่สุด
      อีกทั้งยังทำให้ Widevine Level 3 กลายเป็นเป้าหมายโจมตีขนาดใหญ่มาก
      สุดท้ายแล้วนี่เป็นสมการทางการเงิน เงินที่เสียไปจากการบล็อกโฆษณายังไม่มากพอให้กดสวิตช์ Widevine แต่ก็มากพอให้ใช้มาตรการที่เบากว่านี้แล้ว และคงมีแรงกดดันจากค่ายเพลงด้วย จึงมีโอกาสจะถูกนำไปใช้กว้างขึ้นในอีกไม่กี่ปี
      ถ้าจะคาดการณ์ ตอนแรกคงเริ่มจากวิดีโอที่มีเพลงของค่ายหรือคลิปสตูดิโอซึ่งถูก Content ID จับได้ก่อน แล้วอาจให้แท็กแบบ opt-in แก่ครีเอเตอร์รายอื่น
      วิดีโอแบบนั้นมีประโยชน์ต่อการสร้างรายได้มากกว่า และไม่ทำให้เสียข้อได้เปรียบของ CDN ไปพร้อมกันทั้งหมด
    • Google น่าจะอยากกดการใช้ไคลเอนต์ของบุคคลที่สาม แต่ยังยอมให้คน เก็บอาร์ไคฟ์ ได้
      การใช้มาตรการครึ่ง ๆ กลาง ๆ แบบเงียบ ๆ เช่นนี้เป็นทางออกที่สมบูรณ์แบบและเป็นทางเดียวเพื่อบรรลุเป้าหมายนั้น

  • สงสัยมาตลอดว่า YouTube แจกจ่ายวิดีโออย่างไร
    ต่อให้อินเทอร์เน็ตแย่ก็ยังทำงานได้ดี และในอเมริกาใต้ไม่ได้ใช่ว่าทุกแพลตฟอร์มจะทำงานดี แต่ YouTube เป็นแพลตฟอร์มวิดีโอที่ลื่นที่สุด
    ที่ใกล้เคียงที่สุดคือ Netflix แต่ก็ยังตามหลังอยู่มาก

    • วาง เซิร์ฟเวอร์แคช ไว้ในเครือข่าย ISP ใกล้บ้าน
      ISP ก็ได้ประโยชน์ จึงยอมให้ทำ
      คอขวดของ ISP คือการเชื่อมต่อจากเครือข่ายของตนออกไปยัง backbone อินเทอร์เน็ตที่กว้างกว่า และเซิร์ฟเวอร์แคชของ CDN รายใหญ่ช่วยลดภาระส่วนใหญ่ตรงคอขวดนั้น
      เอกสารเกี่ยวกับโครงสร้างคล้ายกันของ Netflix: https://openconnect.netflix.com/

  • เคยลองดาวน์โหลดวิดีโอจาก YouTube โดยตรงไหม?
    ถ้าลองทำ ด้วยมือ โดยไม่พึ่ง youtube-dl, yt-dlp หรือเว็บพวกนั้น จะพบว่าซับซ้อนกว่าที่คิดมาก

    • นานมากแล้ว ผมเคยทำสคริปต์ Perl สำหรับเรื่องแบบนี้ไว้: https://www.perlmonks.org/?node_id=636777
      แน่นอนว่าปัญหาของสคริปต์แบบนี้คือ ต้องคอยไล่ตามสิ่งที่ YouTube เปลี่ยนอยู่เรื่อย ๆ เพื่อกันไม่ให้ดาวน์โหลดวิดีโอได้
    • ผมจัดการด้วยการฉีด user script เข้าไปเอง
      ถ้าดูจาก WEI นี่เป็นวิธีที่ใช้ USER AGENT ของผมเอง ซึ่งอาจอยู่ได้ไม่นาน
      แทนที่จะพยายามเขียนฟังก์ชันถอดรหัสลายเซ็น, n และฟังก์ชันจำกัดความเร็วขึ้นมาใหม่ ผมหา player.js ด้วย match(/(?:player\/([a-zA-Z0-9_-]+)\/)?(?:html5player|(?:www|player(?:_ias)?))[-\.]([^/]+?)(?:(?:\/html5player(?:-new)?)?|(?:\/[a-z]{2,3}_[A-Z]{2})?\/base)\.js/) จากนั้น grep ฟังก์ชันที่เกี่ยวข้องในนั้นแล้วเรียกใช้โดยตรง
      จากมุมมองของ YouTube ก็พูดได้ว่าฟังก์ชัน DRM ของตัวเองกำลังเปิดลิงก์ .mp4 ให้ผม ดังนั้นจึงดูเหมือนปกติ 100%
    • หมายถึงวิธีกดปุ่ม “Download” แล้วจ่ายเงิน Premium น่ะหรือ?

  • ในเชิงเทคนิคทั้งหมดนี้น่าสนใจ แต่ถ้าในเชิงจริยธรรมไม่ได้คิดแค่ว่า “เอาให้ Google เจ็บแสบไปเลย” การหยุดไว้ที่การปรับให้เหมาะที่สุดขั้นแรก คือ ผ่านการตรวจสอบว่าเป็นเบราว์เซอร์จริงและได้ความเร็วระดับเบราว์เซอร์ทั่วไป ก็ดูสมเหตุสมผล
    แค่นั้นก็ไม่ได้สิ้นเปลืองทรัพยากรของ YouTube มากกว่าผู้ใช้เบราว์เซอร์ที่บล็อกโฆษณา
    การใช้ความเร็วเต็มระดับ Gb/s โดยไม่จ่ายอะไรเลยให้ความรู้สึกเหมือนกำลังลองเสี่ยงโชคแทนผู้ใช้ที่บล็อกโฆษณาทั้งหมด
    แน่นอน สุดท้ายมันก็อาจเป็นเรื่องเอาให้ Google เจ็บแสบอยู่ดี

    • ในเชิงเทคนิค ทุกคนต่างก็จ่ายค่าเชื่อมต่อเครือข่ายอยู่แล้ว
      ผมคงไม่ถึงกับบอกว่าการยิง YouTube ด้วยความเร็วสูงสุดเป็นเรื่องผิดจริยธรรม แต่ก็จะไม่ตำหนิ YouTube หากเขาออกมาตรการป้องกัน
      ผมใช้ส่วนขยายเบราว์เซอร์ที่เมื่อเอาเมาส์ชี้รูปบนโซเชียลมีเดียแล้วจะแสดงภาพขนาดต้นฉบับ แต่ Instagram เคยขึ้นคำเตือนกิจกรรมผิดปกติและขู่ว่าจะล็อกบัญชี
      ผมตรวจสอบว่าส่วนขยายนั้นแอบสแครปข้อมูลเบื้องหลังหรือไม่ แต่ก็ดูไม่มีปัญหาอะไร และ Meta น่าจะมองลำดับคำขอที่ต่างจากไคลเอนต์มาตรฐานแล้วตัดสินว่าเป็นการสแครปข้อมูล
      มันเป็นวงจรของมาตรการและมาตรการโต้กลับ YouTube เองก็คงจะใช้วิธีรับมือของตัวเอง ทำให้สแครปเปอร์ต้องโต้กลับอีก แต่การบริโภคอย่างชอบธรรมไม่น่าจะเร็วกว่า 2 เท่าของความเร็วเล่นบนไคลเอนต์ทางการ ดังนั้นสักวันหนึ่งก็น่าจะจำกัดการดาวน์โหลดไว้ประมาณนั้นได้
      ถึงอย่างนั้น ผมก็คิดว่าไม่ควรจำกัดการดาวน์โหลดโดยตัวมันเอง
      เนื้อหาถูกกฎหมายคุ้มครองอยู่แล้ว และคนส่วนใหญ่ดาวน์โหลดวิดีโอด้วยเหตุผลที่สมเหตุสมผล เช่น เก็บถาวร วิเคราะห์ หรือทำวิดีโอรีวิว
      คอนเทนต์บน YouTube ไม่ได้ถูกสร้างขึ้นในสุญญากาศ และหลังจากเผยแพร่แล้ว มันก็สร้างสภาพแวดล้อมให้เกิดวิดีโอใหม่ ๆ ดังนั้น เสรีภาพในการสร้างสรรค์ นี้จึงสำคัญ
    • ผมไม่ค่อยแน่ใจว่านี่นับว่าเป็นการใช้งานเกินควรแค่ไหน
      สุดท้ายก็แค่รับข้อมูลปริมาณเท่าเดิมในเวลาที่สั้นลง ใช้แบนด์วิดท์มากขึ้นแต่ก็หายไปเร็วขึ้น
      กรณีใช้งานเบราว์เซอร์ทั่วไปดูเหมือนถูกปรับให้เข้ากับสถานการณ์ปกติที่คนดูวิดีโอไม่จบ
      ถ้าตั้งใจจะดูทั้งหมดและเก็บไว้ตั้งแต่แรก ก็ยากจะบอกว่าเป็นการกินแบนด์วิดท์ของ Google มากขึ้น เพียงแต่อาจมีโอเวอร์เฮดมากกว่าเพราะจำนวนการเชื่อมต่อ
    • บริษัทไม่มีจริยธรรม มีแต่ ผลประโยชน์
      ดังนั้นผมจะทำคล้าย ๆ กันก็เป็นเรื่องธรรมชาติ
    • แม้จะพูดถึงทรัพยากรของ YouTube และระดับ Gb/s แต่ในกรณีส่วนใหญ่ วิดีโอถูกส่งมาจากภายในเครือข่าย ISP เดียวกัน
      เพราะ YouTube มีแคชอยู่กับ ISP และจุดแลกเปลี่ยนอินเทอร์เน็ตแทบทุกแห่งทั่วโลก และอาจเป็น CDN ที่ใหญ่ที่สุดเท่าที่เคยมีมา
      ตัวอย่างเช่น URL YouTube ของผู้เขียนชี้ไปยัง ISP Videotron ในแคนาดา
      https://bgp.he.net/dns/rr1---sn-8qu-t0aee.googlevideo.com
    • ในเชิงเทคนิค ควรสามารถดาวน์โหลดวิดีโอได้ และไม่ควรถูกบล็อก
      อย่างน้อยก็เพื่อเก็บหลักฐานในกรณีที่มีใครเผยแพร่ถ้อยคำแสดงความเกลียดชัง หรือดูหมิ่นผมกับครอบครัว
      จะใช้กล้องวิดีโอถ่ายหน้าจอก็ได้ แต่ฟังดูเหมือนวิธีแก้ปัญหายุคหิน
      ตัวอย่างเช่น บนเบราว์เซอร์ของ Mac นั้น Netflix ไม่อนุญาตให้ถ่ายสกรีนช็อต ทำให้แม้แต่การ ทำมีม ซึ่งเข้าข่ายการใช้งานโดยชอบธรรม ก็ยังถูกพรากไป