Vượt qua giới hạn tải xuống video YouTube

 (blog.0x7d0.dev)
6 điểm bởi GN⁺ 2023-08-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • Có thể lấy URL tệp YouTube qua API /youtubei/v1/player, nhưng nếu tải trực tiếp thì tốc độ sẽ cực kỳ chậm do giới hạn tải xuống không chính thức
  • Kể từ giữa năm 2021, tham số truy vấn n gắn trong URL phải được biến đổi bằng thuật toán JavaScript trong base.js; nếu thất bại, YouTube sẽ âm thầm giới hạn tốc độ
  • Ngay cả khi xử lý đúng n, thời gian tải xuống vẫn được điều chỉnh theo độ dài và dung lượng video; trong ví dụ, video 1,5GB được tải xuống ở khoảng 4,0MB/s
  • Nếu dùng header HTTP Range để chia tệp thành các mảnh 10MB và tải qua kết nối mới, có thể lấy nhanh từng mảnh trước khi giới hạn được áp dụng
  • Tệp cuối cùng cần ghép luồng video và âm thanh được cung cấp riêng bằng ffmpeg; yt-dlp, VLC media player, NewPipe và node-ytdl-core cũng dùng kỹ thuật tương tự

Luồng lấy URL tệp YouTube

  • URL tệp media thực tế có thể lấy bằng cách gọi endpoint /youtubei/v1/player
  • API này trả về tiêu đề video, mô tả, thumbnail và thông tin định dạng; từ danh sách định dạng có thể chọn URL tệp với chất lượng mong muốn
    • ID video ví dụ là aqz-KE-bpKQ
    • Phần thân yêu cầu chứa các giá trị như videoId, context.client.clientName, context.client.clientVersion
    • Các giá trị khác trong đối tượng context là điều kiện tiên quyết mà API kiểm tra; có thể tìm các giá trị được chấp nhận bằng cách quan sát yêu cầu từ trình duyệt web
  • Nếu dùng nguyên adaptiveFormats[0].url nhận từ API, tốc độ tải xuống chậm đến mức gần như bị chặn
    • Trong ví dụ, tệp 1,5GB hiển thị ở mức 66,7kB/s
    • Tốc độ thường bị giới hạn trong khoảng 40~70kB/s
    • Có thể mất khoảng 6 giờ 30 phút để tải hết một video 10 phút

Giới hạn đầu tiên do tham số n tạo ra

  • Kể từ giữa năm 2021, YouTube đưa tham số truy vấn n vào hầu hết URL tệp
  • Giá trị này phải được biến đổi bằng thuật toán JavaScript trong base.js được phân phối cùng trang web
  • YouTube dùng giá trị n như một challenge để phân biệt có phải client chính thức hay không
    • Nếu không có n hoặc n không được biến đổi đúng, giới hạn tốc độ tải xuống sẽ được áp dụng âm thầm
  • Thuật toán biến đổi bị làm rối mã và thay đổi thường xuyên, nên cách reverse-engineer nội dung mỗi lần là không thực tế
  • Phần triển khai ví dụ tải base.js của phiên bản player hiện tại, trích xuất mã biến đổi n, rồi chạy với giá trị n ban đầu
    • Tìm URL base.js từ trang YouTube embed
    • Dùng biểu thức chính quy để trích xuất tên hàm challenge và thân hàm
    • Chạy hàm biến đổi bằng vm.runInNewContext của Node.js
    • Thay tham số n trong URL bằng giá trị đã biến đổi

Giới hạn tốc độ vẫn còn sau khi biến đổi n

  • Khi biến đổi đúng tham số n, giới hạn cực đoan ban đầu biến mất, nhưng YouTube vẫn áp dụng giới hạn tải xuống biến thiên
  • Mức giới hạn thay đổi tùy theo dung lượng và độ dài video, và được điều chỉnh sao cho thời gian tải xuống xấp xỉ một nửa độ dài video
  • Nếu luôn phục vụ tệp media nhanh nhất có thể, đó có thể là lãng phí băng thông lớn đối với một dịch vụ streaming
  • Trong ví dụ tải xuống, tệp 1,5GB được tải ở khoảng 4,0MB/s

Tải nhanh các mảnh nhỏ bằng HTTP Range

  • Cốt lõi của cách vượt qua giới hạn là dùng header HTTP Range để chia tệp thành nhiều đoạn nhỏ rồi tải xuống
  • Header Range chỉ định đoạn tệp cần nhận trong từng yêu cầu
    • Ví dụ: Range: bytes=2000-3000
  • Mã ví dụ xử lý tệp media bằng cách chia thành các segment 10MB
    • Xóa tệp đầu ra hiện có
    • Tính đoạn 10MB tiếp theo dựa trên số byte đã nhận đến hiện tại
    • Thêm header Range vào từng yêu cầu và nhận với responseType: 'stream'
    • Ghi nối dữ liệu nhận được vào cuối tệp
    • In tiến độ, tổng dung lượng và tốc độ theo từng segment
  • Cách này hoạt động vì cần một khoảng thời gian trước khi quy tắc giới hạn được áp dụng, còn các segment nhỏ có thể được tải rất nhanh qua kết nối mới
  • Trong kết quả thử nghiệm với tệp 1464,99MB, các tốc độ sau xuất hiện
    • Tại mốc 0,68%: 46,73MB/s
    • Tại mốc 1,37%: 60,98MB/s
    • Tại mốc 2,05%: 71,94MB/s
    • Tại mốc 6,14%: 104,17MB/s
  • Một số lượt tải gần như dùng hết kết nối 1Gb/s, và tốc độ trung bình thường nằm trong khoảng 50~70MB/s, tức 400~560Mb/s

Ghép video·âm thanh và các triển khai hiện có

  • YouTube phân phối kênh video và âm thanh dưới dạng các tệp riêng biệt
  • Với cấu trúc này, video HD hoặc UHD có thể tái sử dụng cùng một tệp âm thanh, giúp tiết kiệm dung lượng lưu trữ
  • Một số video cũng cung cấp các kênh âm thanh khác nhau theo ngôn ngữ
  • Ở bước cuối, dùng ffmpeg để ghép tệp video và tệp âm thanh thành một
    • Sao chép stream mà không mã hóa lại bằng -c copy
    • Chọn stream video của đầu vào thứ nhất bằng -map 0:v:0
    • Chọn stream âm thanh của đầu vào thứ hai bằng -map 1:a:0
    • Sau khi ghép, xóa các tệp video và âm thanh tạm thời
  • Toàn bộ mã ví dụ được cung cấp tại youtube-download.js
  • Nhiều dự án dùng kỹ thuật tương tự để vượt qua giới hạn của YouTube

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-15
Ý kiến trên Hacker News

  • Theo những gì tôi thấy trong thảo luận ở kho lưu trữ yt-dlp, giới hạn này có thể được vượt qua chỉ bằng cách thêm tham số truy vấn range=xxx, chứ không phải header HTTP Range
    Ngay cả khi đặt phạm vi là toàn bộ tệp thì tốc độ tối đa cũng quay trở lại, và nếu tôi nhớ không nhầm thì YouTube đã gỡ giới hạn này rồi
    Tham khảo: https://github.com/yt-dlp/yt-dlp/issues/6400

  • Tôi chưa thử với YouTube, nhưng từng tải video từ những trang streaming đáng ngờ hơn bằng công cụ dành cho nhà phát triển web
    Phần lớn dùng kiểu bảo vệ là khi mở công cụ nhà phát triển thì tạo các câu lệnh debugger không thể bỏ qua và chạy đoạn mã ngốn nhiều CPU, có lẽ là vòng lặp vô hạn hoặc trình đào tiền mã hóa, khiến video bị dừng
    Quan trọng hơn là đoạn mã này còn xóa thông tin yêu cầu mạng, khiến việc phân tích lưu lượng đã gửi từ trước đến nay trở nên khó khăn; “giữ lại nhật ký” của Firefox thì thật sự phải giữ lại nhật ký
    Đây không phải phòng thủ hoàn hảo nên rốt cuộc tôi chưa có video nào không tải được, nhưng tôi muốn xem tài liệu giải thích sâu hơn về cơ chế hoạt động này

    • Cách đây không lâu có một bài viết đúng về việc né cách làm này, và giải pháp vừa đơn giản vừa hiệu quả: build lại trình duyệt rồi đổi luôn tên từ khóa debugger
      Buồn cười đến mức bật cười
      https://news.ycombinator.com/item?id=36961445
    • Để vượt qua những kỹ thuật anti-debugging như vậy, Anti-Anti-Debug [0] đáng để thử
      Vì lý do tương tự, đây là một tiện ích mở rộng đơn giản tôi từng làm chỉ trong vài giờ
      0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...
    • Việc trang web có thể biết công cụ nhà phát triển đã được mở tự nó đã giống như một khiếm khuyết lớn ở phía trình duyệt
      Trang web tuyệt đối không nên có cách biết công cụ nhà phát triển có đang mở hay không, và có vẻ điều đó hoàn toàn có thể được triển khai đúng
    • Một cách đôi khi hiệu quả trên Firefox là ở video nhấn shift+nhấp chuột phải → This Frame → Open Frame in New Tab
      Trong tab mới, công cụ nhà phát triển sẽ hoạt động
    • Nếu là trang cố phát hiện công cụ nhà phát triển của trình duyệt, thì để phân tích lưu lượng tôi sẽ nghĩ đến việc dùng Wireshark trước

  • Ở giai đoạn cuối, để tiếp tục xem màn hình có lẽ sẽ phải trả bằng WorldCoin, còn số WorldCoin không thể giao dịch đó sẽ chỉ kiếm được bằng cách xem quảng cáo
    Một Orb nhỏ tích hợp trong màn hình sẽ giám sát việc này; chắc bạn không thật sự tin rằng thứ đó là để phục vụ thu nhập cơ bản chứ
    Vấn đề thu nhập cơ bản đã được giải quyết từ lâu bằng tài khoản ngân hàng và xác minh khách hàng (KYC)

    • Chẳng liên quan gì đến mắt à?

  • Tôi tò mò không biết dạo này có ai gặp vấn đề giới hạn tốc độ yt-dlp không
    Tôi luôn xem YouTube bằng mpv, bên trong nó dùng yt-dlp, và từ tuần trước tình hình trở nên rất tệ
    Ban đầu nó khởi chạy nhanh đúng như mức tôi giới hạn ở 500kB/s, nhưng sau một lúc thì cứ tải 3 giây chỉ nhận được phần đủ phát 1 giây, nên trước khi xem phải để nó xếp hàng đệm khá lâu
    Tôi đang dùng bản git của yt-dlp nhưng không thấy issue liên quan

    • mpv chỉ dùng yt-dlp để lấy URL video rồi chuyển URL đó cho ffmpeg
      ffmpeg không triển khai cách né liên quan đến header Range nên bị giới hạn tốc độ
      Có thể để yt-dlp tải trực tiếp rồi pipe sang mpv để phát từ đầu vào chuẩn, nhưng việc tua đến đoạn chưa được tải sẽ bị hỏng
      Trình theo dõi issue của mpv có nhiều issue liên quan đến vấn đề này

  • YouTube liên tục thay đổi những phần nhỏ trong quá trình này
    Trước đây tôi từng làm một công cụ biên tập nội bộ cho video YouTube, cần tệp MP4, và khoảng mỗi tháng trình biên tập lại hỏng vì thay đổi của YouTube, nên tôi phải dùng debugger xem họ đã đổi gì rồi chỉnh cho phù hợp

  • Hơi lạc đề, nhưng tôi thắc mắc không biết có phải ảo giác không khi xem trên YouTube thì video trông tốt hơn một chút
    Tôi tải các video mình hay xem xuống rồi xem bằng VLC hoặc Infuse trên AppleTV, và có thể xác nhận qua “nerd stats” của ứng dụng YouTube rằng đó là cùng một luồng video/âm thanh
    Nhưng có vẻ YouTube áp một bộ lọc rất tinh tế làm cho các artifact nén dạng khối trông mượt hơn
    Không phải là nhấn mạnh cạnh, mà có cảm giác nó tìm các vùng chuyển màu không có cạnh rồi làm cho artifact dạng khối bớt nổi bật hơn
    Có thể chỉ là ảo giác, nhưng trên YouTube hình ảnh trông sống động và chắc hơn, còn video tải xuống thì ở nền hoặc vùng bóng có những artifact và rung nhẹ rất tinh tế nhưng vẫn nhận ra được, khiến cả video 1440p cũng có chất lượng cuối cùng kém hơn
    Âm thanh cũng khác biệt rõ: trên YouTube âm lượng nhìn chung đồng đều, còn video tải xuống thì phải tăng âm lượng nên bất tiện
    Ước gì VLC hoặc Infuse cũng xử lý để video dễ xem hơn như YouTube; có vẻ không hẳn là bộ lọc màu hay độ nét, mà giống một kiểu xử lý như cân bằng mức âm thanh để làm trải nghiệm nhất quán giữa các kênh

    • Về âm thanh thì có thể trả lời được
      Hầu hết các trang streaming như YouTube và Spotify dùng một thứ gọi là ReplayGain
      Đó là tag tính toán âm lượng trung bình của video hoặc bài hát, được tính tại thời điểm upload
      Client YouTube chính thức dùng tag đó để điều chỉnh âm lượng khi phát, nhưng khi tải xuống thì tag có thể bị thiếu, hoặc MKV có thể không hỗ trợ mặc định tag ReplayGain
    • Bộ lọc scaling và cách scaling sắc sai mà trình phát dùng ảnh hưởng đến độ nét
      Nếu phát luồng ở độ phân giải gốc toàn màn hình thì khác biệt ở các cạnh đen trắng lẽ ra phải biến mất
      Tùy hệ điều hành, có thể kiểm tra khác biệt bằng cách chuyển nhanh giữa hai ứng dụng toàn màn hình, và ISO 29170-2 khuyến nghị 5Hz
      Thay đổi màu có thể đến từ không gian màu video hoặc lỗi xử lý profile màn hình; trong trường hợp này ảnh chụp màn hình cũng có thể trông khác so với hình ảnh thực tế trong ứng dụng
      Rung nhẹ có thể là do rớt khung hình, và nếu thấy pixel hóa ở cạnh của vật thể có màu thì có khả năng là upscale sắc sai bằng lân cận gần nhất
    • Một video YouTube có nhiều luồng video, âm thanh và luồng tích hợp
      Luồng mà trình duyệt chọn có thể khác với luồng mà youtube-dl hoặc các fork của nó chọn mặc định
      Trước đây có một thời gian nó mặc định chọn luồng tích hợp tốt nhất, nhưng các luồng âm thanh và video tốt nhất tách riêng có chất lượng cao hơn
    • Các trình phát như VLC có thể làm tốt hơn, và cũng có thể tự tạo hiệu chỉnh mong muốn bằng GLSL
      Tôi đặc biệt thích gói shader anime4k; nó dựa trên machine learning nhưng chạy real-time trong mpv và có lẽ cũng dùng được trong VLC
      Đúng như tên gọi, nó được tinh chỉnh cho hoạt hình, nhưng khử nhiễu và khử mờ khá ổn nên thường làm nội dung YouTube trông dễ xem hơn, và bước phục hồi xử lý artifact nén khá tốt
      Tuy nhiên vì quá tối ưu cho hoạt hình nên không phải lúc nào cũng hoạt động tốt, thậm chí có thể làm tệ hơn
      https://github.com/bloc97/Anime4K/releases
    • Pipeline video của trình duyệt có thể khác với cái VLC dùng
      Có thể tạo một tài liệu HTML đơn giản chứa phần tử video trỏ tới file cục bộ để so sánh

  • Tôi ngạc nhiên mỗi lần YT lại tung ra một biện pháp nửa vời nữa để đối phó các downloader
    GOOG cũng sở hữu Widevine, không hiểu sao họ không dùng

    • Phiên bản phần mềm của Widevine sẽ bị phá hoàn toàn trong thời gian rất ngắn, rồi cả add-on tải xuống một cú nhấp cũng sẽ vượt qua được
      Người dùng chẳng thấy khác gì, còn YouTube chỉ phải gánh thêm chi phí vận hành Widevine
      Nếu dùng phiên bản dựa trên phần cứng thì có thể gây ra nhiều vấn đề trên các thiết bị không được hỗ trợ
    • YouTube dường như không quá bận tâm chuyện sao chép lậu nội dung hay dùng client bên thứ ba
      Điều họ quan tâm là lãng phí băng thông
      Với các trang streaming video dựa vào quảng cáo, chi phí băng thông thường cao hơn doanh thu, và Google chỉ vừa làm được điều đó nhờ có băng thông đủ rẻ để có thể gây sức ép buộc ISP peering miễn phí
      Các giới hạn tốc độ kiểu này là biện pháp nhằm để lại phần lớn băng thông cho người dùng thật, chứ không phải cho những người scrape toàn bộ nội dung
    • Lý do không dùng Widevine là vì nó thêm bước giải mã nên chậm, buộc giải mã video bằng phần mềm nên chậm, và trình duyệt web chỉ hỗ trợ dạng Widevine yếu nhất nên hiệu quả kém
      Nó không mấy hiệu quả để đạt mục tiêu, lại có khả năng đẩy một lượng đáng kể người dùng ra khỏi nền tảng
    • Lý do chính là nó làm giảm đôi chút hiệu quả cache CDN, gây tốn chi phí, và phải vận hành thêm hệ thống quản lý khóa
      Ở quy mô của YouTube, họ muốn giảm tối đa những hệ thống như vậy
      Ngoài ra nó sẽ biến Widevine Level 3 thành một mục tiêu tấn công cực lớn
      Rốt cuộc đây là bài toán tài chính: số tiền mất vì chặn quảng cáo chưa đủ để kéo công tắc Widevine, nhưng đã đủ để áp dụng các biện pháp yếu hơn, và hẳn cũng có áp lực từ các hãng thu âm, nên có khả năng trong vài năm tới nó sẽ được triển khai rộng hơn
      Nếu dự đoán, ban đầu họ sẽ bắt đầu với các video có nhạc của label hoặc clip studio bị Content ID nhận diện, rồi có thể cung cấp tag tùy chọn cho các nhà sáng tạo khác
      Những video đó hữu ích hơn cho kiếm tiền và cũng không làm mất lợi ích CDN cùng lúc
    • Google có lẽ muốn kiềm chế client bên thứ ba nhưng vẫn cho phép mọi người lưu trữ/archive
      Âm thầm áp dụng những biện pháp nửa vời như thế này là giải pháp hoàn hảo và cũng là duy nhất để đạt mục tiêu đó

  • Tôi luôn tò mò YouTube phân phối video như thế nào
    Ngay cả khi Internet rất tệ nó vẫn chạy tốt, và ở Nam Mỹ không phải nền tảng nào cũng hoạt động ổn, nhưng YouTube là nền tảng video mượt nhất
    Gần nhất là Netflix, nhưng vẫn còn thua khá xa

    • Họ đặt máy chủ cache bên trong mạng ISP gần nhà bạn
      ISP cũng có lợi nên họ cho phép
      Điểm nghẽn của ISP là kết nối từ mạng nội bộ của họ ra backbone Internet rộng hơn, và máy chủ cache của các CDN lớn giúp giảm đáng kể tải tại điểm nghẽn đó
      Tài liệu về cấu hình tương tự của Netflix: https://openconnect.netflix.com/

  • Bạn đã bao giờ trực tiếp tải video từ YouTube xuống chưa?
    Nếu làm thủ công, không dựa vào youtube-dl, yt-dlp hay những website kiểu đó, thì phức tạp hơn tưởng tượng rất nhiều

    • Từ rất lâu trước đây tôi từng làm một script Perl để làm việc đó: https://www.perlmonks.org/?node_id=636777
      Dĩ nhiên vấn đề của những script kiểu này là phải liên tục chạy theo các phần YouTube thay đổi để ngăn tải video xuống
    • Tôi xử lý bằng cách tự chèn user script
      Nhìn vào WEI thì đây là cách dùng USER AGENT của tôi, thứ có thể không tồn tại được lâu
      Thay vì cố gắng triển khai lại chữ ký, giải mã n và hàm giới hạn tốc độ, tôi tìm player.js bằng match(/(?:player\/([a-zA-Z0-9_-]+)\/)?(?:html5player|(?:www|player(?:_ias)?))[-\.]([^/]+?)(?:(?:\/html5player(?:-new)?)?|(?:\/[a-z]{2,3}_[A-Z]{2})?\/base)\.js/), rồi grep các hàm liên quan trong đó và gọi trực tiếp
      Từ phía YouTube, cũng có thể nói rằng hàm DRM của chính họ đang mở link .mp4 cho tôi, nên trông 100% như bình thường
    • Ý là cách bấm nút “Download” rồi trả tiền Premium ấy à?

  • Về mặt kỹ thuật thì mọi thứ đều thú vị, nhưng nếu xét về đạo đức mà không chỉ nghĩ “kệ xác Google”, thì có vẻ hợp lý khi dừng ở tối ưu hóa đầu tiên, tức là vượt qua kiểm tra trình duyệt thật để đạt tốc độ trình duyệt thông thường
    Như vậy thì cũng không lãng phí tài nguyên YouTube hơn người dùng trình duyệt chặn quảng cáo
    Dùng toàn bộ tốc độ Gb/s mà không trả bất kỳ chi phí nào có cảm giác như đang thử vận may của toàn bộ cộng đồng người dùng chặn quảng cáo
    Tất nhiên, rốt cuộc cũng có thể là kệ xác Google

    • Về mặt kỹ thuật thì ai cũng đang trả chi phí kết nối mạng
      Tôi sẽ không nói việc đập YouTube ở tốc độ tối đa là phi đạo đức, nhưng cũng sẽ không trách nếu YouTube thực hiện biện pháp chặn
      Tôi dùng một tiện ích trình duyệt để khi rê chuột lên ảnh trên mạng xã hội thì hiển thị ảnh kích thước gốc, và Instagram đã hiện cảnh báo hoạt động bất thường cùng lời đe dọa khóa tài khoản
      Tôi đã kiểm tra xem tiện ích có đang scraping ở phía sau không, nhưng có vẻ không có vấn đề gì; có lẽ Meta nhìn vào thứ tự request khác với client tiêu chuẩn rồi cho đó là scraping dữ liệu
      Đây là vòng lặp giữa biện pháp và đối sách; YouTube cũng sẽ triển khai đối sách của mình để buộc các scraper lại phản ứng, nhưng vì việc tiêu thụ hợp lệ trên client chính thức không thể nhanh hơn 2 lần tốc độ phát, nên một lúc nào đó họ sẽ có thể giới hạn tải xuống ở mức đó
      Dù vậy, tôi vẫn nghĩ bản thân việc tải xuống không nên bị hạn chế
      Nội dung vốn đã được pháp luật bảo vệ, và phần lớn người ta tải video xuống vì những lý do chính đáng như lưu trữ, phân tích, làm video review
      Nội dung YouTube không được tạo ra trong chân không; sau khi được công khai, nó tạo ra môi trường để video mới được tạo nên, vì thế tự do sáng tạo này rất quan trọng
    • Tôi không rõ đây bị lạm dụng đến mức nào
      Rốt cuộc chỉ là nhận cùng một lượng dữ liệu trong thời gian ngắn hơn, nên dùng nhiều băng thông hơn nhưng biến mất nhanh hơn
      Trường hợp dùng trình duyệt thông thường có vẻ được điều chỉnh cho tình huống phổ biến là không xem video đến hết
      Nếu ngay từ đầu đã định xem toàn bộ và lưu trữ, thì khó nói là đang ngốn thêm băng thông của Google; chỉ là overhead có thể lớn hơn do số lượng kết nối
    • Doanh nghiệp không có đạo đức, chỉ có lợi ích
      Tôi hành xử tương tự cũng là điều tự nhiên
    • Nói là tài nguyên YouTube và Gb/s, nhưng trong phần lớn trường hợp video được phục vụ ngay trong cùng mạng ISP
      Vì YouTube đặt cache ở hầu như mọi ISP và điểm trao đổi Internet trên thế giới, và có thể đây là CDN lớn nhất từng được tạo ra
      Ví dụ, URL YouTube của tác giả bài viết trỏ đến ISP Videotron ở Canada
      https://bgp.he.net/dns/rr1---sn-8qu-t0aee.googlevideo.com
    • Về mặt kỹ thuật thì phải có khả năng tải video xuống, và không nên bị chặn
      Điều đó cần thiết ngay cả chỉ để lưu lại bằng chứng ai đó phát tán lời lẽ thù ghét hoặc xúc phạm tôi và gia đình
      Cũng có thể quay màn hình bằng camcorder, nhưng nghe như giải pháp thời đồ đá
      Ví dụ, trong trình duyệt trên Mac, Netflix không cho chụp ảnh màn hình, nên ngay cả việc tạo meme thuộc phạm vi sử dụng hợp lý cũng đã bị tước mất