YouTube video indirme kısıtlamasını aşma

 (blog.0x7d0.dev)
6 puan yazan GN⁺ 2023-08-15 | 1 yorum | WhatsApp'ta paylaş
  • YouTube dosya URL'si /youtubei/v1/player API'siyle alınabiliyor, ancak doğrudan indirilirse gayriresmî indirme kısıtlaması nedeniyle hız aşırı derecede düşüyor
  • 2021 ortasından itibaren URL'ye eklenen n sorgu parametresi, base.js içindeki JavaScript algoritmasıyla dönüştürülmeli; bu başarısız olursa YouTube sessizce hızı kısıtlıyor
  • n doğru işlense bile indirme süresi video uzunluğu ve boyutuna göre ayarlanıyor; örnekte 1.5GB videonun yaklaşık 4.0MB/s hızla indirildiği görülüyor
  • HTTP Range başlığı ile dosya 10MB parçalar hâlinde bölünüp her biri yeni bağlantıda alınırsa, kısıtlama devreye girmeden önce her parça hızlıca alınabiliyor
  • Nihai dosya, ayrı sunulan video ve ses akışlarının ffmpeg ile birleştirilmesiyle elde ediliyor; yt-dlp, VLC media player, NewPipe ve node-ytdl-core da benzer teknikler kullanıyor

YouTube dosya URL'sini elde etme akışı

  • Gerçek medya dosyası URL'si /youtubei/v1/player uç noktasına yapılan çağrıyla alınabiliyor
  • Bu API; video başlığı, açıklama, küçük resim ve format bilgilerini döndürüyor, format listesinden istenen kalitedeki dosya URL'si seçilebiliyor
    • Örnek video ID'si aqz-KE-bpKQ
    • İstek gövdesinde videoId, context.client.clientName, context.client.clientVersion gibi değerler yer alıyor
    • context nesnesindeki diğer değerler, API'nin doğruladığı önkoşullar ve bunların izin verilen değerleri web tarayıcısı istekleri gözlemlenerek bulunuyor
  • API'den alınan adaptiveFormats[0].url doğrudan kullanılırsa indirme pratikte engellenmiş gibi yavaşlıyor
    • Örnekte 1.5GB dosya 66.7kB/s civarında görünüyor
    • Hız genellikle 40~70kB/s aralığına kısıtlanıyor
    • 10 dakikalık bir videonun tamamını indirmek yaklaşık 6 saat 30 dakika sürebiliyor

n parametresinin oluşturduğu ilk kısıtlama

  • 2021 ortasından bu yana YouTube çoğu dosya URL'sine n sorgu parametresi ekliyor
  • Bu değer, web sayfasıyla birlikte dağıtılan base.js içindeki JavaScript algoritmasıyla dönüştürülmeli
  • YouTube, n değerini resmî istemci olup olmadığını ayıran bir challenge gibi kullanıyor
    • n yoksa ya da doğru dönüştürülmemişse, indirme hızına sessizce kısıtlama uygulanıyor
  • Dönüştürme algoritması obfuscate edildiği ve sık sık değiştiği için, her seferinde içeriği tersine mühendislikle çözmek pratik değil
  • Örnek uygulama, mevcut oynatıcı sürümünün base.js dosyasını indirip n dönüştürme kodunu çıkardıktan sonra orijinal n değerini verip çalıştırıyor
    • YouTube embed sayfasından base.js URL'si bulunuyor
    • Regex ile challenge fonksiyonunun adı ve fonksiyon gövdesi çıkarılıyor
    • Node.js vm.runInNewContext ile dönüştürme fonksiyonu çalıştırılıyor
    • URL'deki n parametresi dönüştürülmüş değerle değiştiriliyor

n dönüşümünden sonra da kalan hız kısıtlaması

  • n parametresi doğru dönüştürüldüğünde ilk aşırı kısıtlama ortadan kalkıyor, ancak YouTube yine de değişken bir indirme kısıtlaması uyguluyor
  • Kısıtlama düzeyi video boyutu ve uzunluğuna göre değişiyor; indirme süresi, video süresinin yaklaşık yarısı olacak şekilde ayarlanıyor
  • Medya dosyasının her zaman mümkün olan en yüksek hızda verilmesi, akış hizmeti açısından büyük bir bant genişliği israfı olabilir
  • Örnek indirmede 1.5GB dosya yaklaşık 4.0MB/s hızla alınıyor

HTTP Range ile küçük parçaları hızlı alma

  • Aşma yönteminin özü, HTTP Range başlığı ile dosyayı birden çok küçük aralığa bölerek indirmek
  • Range başlığı, her istekte alınacak dosya aralığını belirtir
    • Örnek: Range: bytes=2000-3000
  • Örnek kod, medya dosyasını 10MB segmentlere bölerek işliyor
    • Mevcut çıktı dosyası siliniyor
    • Şu ana kadar alınan bayt sayısına göre sıradaki 10MB aralığı hesaplanıyor
    • Her isteğe Range başlığı ekleniyor ve responseType: 'stream' ile alınıyor
    • Gelen veri dosyanın sonuna ekleniyor
    • İlerleme, toplam boyut ve segment başına hız yazdırılıyor
  • Bu yöntem, kısıtlama kuralının uygulanmasının zaman alması ve küçük segmentlerin yeni bağlantılarda çok hızlı alınabilmesi nedeniyle çalışıyor
  • Test çıktısında 1464.99MB dosya için şu hızlar görülüyor
    • %0.68 noktasında: 46.73MB/s
    • %1.37 noktasında: 60.98MB/s
    • %2.05 noktasında: 71.94MB/s
    • %6.14 noktasında: 104.17MB/s
  • Bazı indirmeler 1Gb/s bağlantının neredeyse tamamını kullanacak düzeydeydi; ortalama hız ise genellikle 50~70MB/s, yani 400~560Mb/s aralığındaydı

Video ve sesi birleştirme ve mevcut uygulamalar

  • YouTube, video ve ses kanallarını ayrı dosyalar olarak dağıtıyor
  • Bu yapıda HD veya UHD videolar aynı ses dosyasını yeniden kullanabildiği için depolama alanından tasarruf edilebiliyor
  • Bazı videolarda dile göre farklı ses kanalları da sunuluyor
  • Son aşamada ffmpeg ile video dosyası ve ses dosyası tek bir dosyada birleştiriliyor
    • -c copy ile yeniden kodlama olmadan akışlar kopyalanıyor
    • -map 0:v:0 ile ilk girdinin video akışı seçiliyor
    • -map 1:a:0 ile ikinci girdinin ses akışı seçiliyor
    • Birleştirme sonrası geçici video ve ses dosyaları siliniyor
  • Tüm örnek kod youtube-download.js olarak sunuluyor
  • Birçok proje, YouTube kısıtlamalarını aşmak için benzer teknikler kullanıyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-15
Hacker News yorumları

  • yt-dlp deposundaki tartışmada gördüğüm kadarıyla bu sınırlama, HTTP Range başlığıyla değil, yalnızca range=xxx sorgu parametresi eklenerek aşılabiliyordu
    Aralığı tüm dosyayı kapsayacak şekilde ayarlasanız bile yine en yüksek hız geri geliyordu; yanlış hatırlamıyorsam YouTube bu sınırlamayı zaten kaldırdı
    Kaynak: https://github.com/yt-dlp/yt-dlp/issues/6400

  • YouTube’da denemedim ama daha şüpheli streaming sitelerindeki videoları web geliştirici araçlarıyla indirdiğim oldu
    Çoğu, geliştirici araçları açılınca atlanamayan debugger ifadeleri oluşturan ve CPU’yu yoğun kullanan kodlar — muhtemelen sonsuz döngüler ya da kripto para madencileri gibi şeyler — çalıştırıp videoyu durduran türden bir koruma kullanıyor
    Daha önemlisi, bu kod ağ isteği bilgilerini de siliyor; böylece o ana kadar gönderilen trafiği analiz etmeyi zorlaştırıyor. Firefox’un “günlükleri koru” özelliği gerçekten günlükleri korumalı
    Kusursuz bir savunma değil; sonuçta indiremediğim video olmadı, ama bunun nasıl çalıştığını daha derinlemesine açıklayan bir kaynak görmek isterim

    • Kısa süre önce tam olarak bu yöntemi aşan bir yazı yayımlandı ve çözüm basit olduğu kadar etkiliydi: tarayıcıyı yeniden derleyip debugger anahtar sözcüğünün adını değiştiriyorlar
      Güldürecek kadar iyiydi
      https://news.ycombinator.com/item?id=36961445
    • Bu tür anti-debugging tekniklerini aşmak için Anti-Anti-Debug [0] denemeye değer
      Benzer bir nedenle, eskiden birkaç saat içinde yaptığım basit bir uzantı
      0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...
    • Geliştirici araçlarının açık olup olmadığının anlaşılabilmesi bile tarayıcı tarafında büyük bir kusur gibi geliyor
      Bir web sayfası geliştirici araçlarının açık olup olmadığını asla öğrenememeli; bunu düzgün şekilde uygulamak mümkün olmalı
    • Firefox’ta bazen işe yarayan yöntem, videonun üzerinde shift+sağ tık → This Frame → Open Frame in New Tab seçmek
      Yeni sekmede geliştirici araçları çalışıyor
    • Tarayıcı geliştirici araçlarını tespit etmeye çalışan bir sayfaysa, trafiği analiz etmek için önce Wireshark kullanmak akla geliyor

  • Son aşamada ekranı izlemeye devam etmek için WorldCoin ile ödeme yapmanız gerekecek; alınıp satılamayan bu WorldCoin’i de ancak reklam izleyerek kazanabileceksiniz gibi görünüyor
    Ekrana gömülü küçük Orb bunu denetleyecek; bunun gerçekten temel gelir için olduğuna inanmamışsınızdır herhalde
    Temel gelir sorunu banka hesabı ve müşteri tanıma (KYC) ile çoktan çözülmüştü

    • Gözlerle hiçbir ilgisi yok mu?

  • Son zamanlarda yt-dlp hız sınırlaması sorunu yaşayan var mı merak ediyorum
    YouTube’u hep mpv ile izliyorum; içeride yt-dlp kullanıyor ve geçen haftadan beri durum çok kötüleşti
    Başta 500kB/s ile sınırladığım kadar hızlı başlıyor ama bir süre sonra 3 saniyelik indirmeyle yalnızca 1 saniyelik oynatma verisi geliyor; bu yüzden oynatmadan önce uzun süre kuyruğa alıp bekletmem gerekiyor
    yt-dlp’nin git sürümünü kullanıyorum ama ilgili bir issue görmedim

    • mpv, yt-dlp ile yalnızca video URL’sini alıp bu URL’yi ffmpege veriyor
      ffmpeg, Range başlığıyla ilgili geçici çözümü uygulamadığı için hız sınırına takılıyor
      yt-dlp’nin doğrudan indirmesini sağlayıp bunu mpvye pipe ederek standart girdiden oynatmak mümkün, ama henüz indirilmemiş bir bölüme sarma bozuluyor
      mpv issue tracker’ında bu konuyla ilgili çok sayıda issue var

  • YouTube bu süreçte küçük şeyleri sürekli değiştiriyor
    Eskiden YouTube videoları için dahili bir düzenleme aracı yapmıştım; MP4 dosyası gerekiyordu ve yaklaşık ayda bir YouTube değişiklikleri yüzünden editör bozuluyor, debugger ile neyin değiştiğini bulup uyarlamam gerekiyordu

  • Konu biraz yan yola sapacak ama YouTube’da izleyince videonun çok az daha iyi görünüyor olması bana mı öyle geliyor merak ediyorum
    Sevdiğim videoları indirip VLC’de ya da AppleTV’de Infuse ile izliyorum; YouTube uygulamasındaki “nerd stats” ile aynı video/ses akışını izlediğimi doğrulayabiliyorum
    Ama YouTube sanki blok tipi sıkıştırma artefaktlarını daha yumuşak gösteren çok ince bir filtre uyguluyor gibi
    Kenarları keskinleştirmiyor; daha çok, kenar olmayan renk geçiş bölgelerini bulup blok tipi artefaktları daha az fark edilir hâle getiriyor gibi
    Yanılıyor da olabilirim ama YouTube’da görüntü daha canlı ve tok görünüyor; indirilen videoda ise arka planlarda veya gölgelerde çok ince ama fark edilir artefaktlar ve titremeler görünüyor, bu yüzden 1440p videonun bile nihai görüntü kalitesi daha kötüymüş gibi duruyor
    Seste de fark belirgin: YouTube’da ses genelde dengeli, ama indirilen videoda sesi açmak gerekiyor ve bu rahatsız edici
    VLC ya da Infuse’un da YouTube gibi videoyu daha iyi gösteren bir işlem yapmasını isterdim; bu sanki renk ya da keskinlik filtresinden çok, kanallar arası deneyimi tutarlı kılan ses seviyesi dengeleme gibi bir işlem

    • Ses kısmına yanıt verebilirim
      YouTube ve Spotify gibi çoğu streaming sitesi ReplayGain denen şeyi kullanır
      Bu, videonun ya da şarkının ortalama ses seviyesini hesaplayan bir etikettir ve yükleme sırasında hesaplanır
      Resmî YouTube istemcisi oynatma sırasında sesi ayarlamak için bu etiketi kullanır; ancak indirirken etiket düşmüş olabilir ya da MKV ReplayGain etiketlerini varsayılan olarak desteklemiyor olabilir
    • Oynatıcının kullandığı ölçekleme filtresi ve renk farkı ölçekleme yöntemi keskinliği etkiler
      Özgün çözünürlüklü akışı tam ekranda oynatırsanız siyah-beyaz kenarlarda farkın ortadan kalkması gerekir
      İşletim sistemine bağlı olarak iki tam ekran uygulama arasında hızlıca geçiş yapıp farkı test edebilirsiniz; ISO 29170-2, 5Hz önerir
      Renk değişimi, video renk uzayından ya da monitör profili işlemesinin başarısız olmasından kaynaklanabilir; bu durumda ekran görüntüsü gerçek uygulama görüntüsünden farklı görünebilir
      Titreme kare düşmesi olabilir; renkli nesnelerin kenarlarında pikselleşme görüyorsanız bunun en yakın komşu renk farkı yükseltmesi olma ihtimali vardır
    • Tek bir YouTube videosunda birden fazla video, ses ve birleşik akış bulunur
      Tarayıcının seçtiği akış ile youtube-dl veya çatallarının varsayılan olarak seçtiği akış farklı olabilir
      Eskiden bir süre en iyi birleşik akışı varsayılan olarak seçiyordu, ama ayrık en iyi ses ve video akışları daha yüksek kalitelidir
    • VLC gibi oynatıcılar daha iyisini yapabilir; GLSL ile istediğiniz düzeltmeyi kendiniz de oluşturabilirsiniz
      Özellikle anime4k shader paketini seviyorum; makine öğrenimi tabanlı ama mpv üzerinde gerçek zamanlı çalışıyor ve VLC’de de çalışır gibi
      Adından anlaşılacağı gibi animasyona göre ayarlanmış olsa da gürültü giderme ve bulanıklık giderme tarafı fena değil; YouTube içeriklerini çoğu zaman daha iyi görünür hâle getiriyor ve restorasyon aşaması sıkıştırma artefaktlarıyla oldukça iyi baş ediyor
      Ancak animasyona fazla göre ayarlandığı için her zaman iyi çalışmıyor, hatta görüntüyü kötüleştirebiliyor
      https://github.com/bloc97/Anime4K/releases
    • Tarayıcının video pipeline’ı, VLC’nin kullandığından farklı olabilir
      Yerel bir dosyayı işaret eden video öğesi içeren basit bir HTML belgesi oluşturup karşılaştırabilirsiniz

  • YT’nin indiricilere karşı her seferinde yine yarım yamalak bir önlem dağıtmasına şaşırıyorum
    GOOG’un Widevine’ı da var; neden kullanmadığını merak ediyorum

    • Widevine’ın yazılım sürümü çok kısa sürede tamamen kırılır ve tek tıkla indirme eklentileriyle bile aşılır
      Kullanıcı açısından değişen bir şey olmaz, YouTube sadece Widevine işletme yükünü üstlenmiş olur
      Donanım tabanlı sürümü kullanırsa desteklenmeyen cihazlarda çok sorun çıkabilir
    • YouTube, içeriğin korsan kopyalanmasını ya da üçüncü taraf istemci kullanılmasını başlı başına pek umursamıyor gibi
      Umursadığı şey bant genişliği israfı
      Reklam tabanlı video streaming sitelerinde bant genişliği maliyeti genelde gelirden daha pahalıdır; Google bunu ancak ISP’lere ücretsiz peering için baskı yapabilecek kadar ucuz bant genişliği elde ettiği için ayakta tutabiliyor
      Bu tür hız sınırlamaları, tüm içeriği kazıyanlara değil gerçek kullanıcılara bant genişliğinin çoğunu bırakmaya yönelik bir önlem
    • Widevine kullanmamasının nedeni, ek bir şifre çözme aşaması getirip yavaş olması, yazılımsal video çözmeyi zorlayıp yavaş olması ve web tarayıcılarının yalnızca etkisi zayıf olan Widevine’ın en zayıf biçimini desteklemesi
      Hedefe ulaşmakta da pek etkili değilken ciddi sayıda kullanıcıyı platform dışına itme olasılığı yüksek
    • Ana neden, CDN önbellek verimliliğini biraz düşürerek maliyet yaratması ve ek bir anahtar yönetim sistemi çalıştırmayı gerektirmesi
      YouTube ölçeğinde bu tür sistemleri mümkün olduğunca azaltmak isterler
      Ayrıca Widevine Level 3’ü çok büyük bir saldırı hedefi hâline getirir
      Sonuçta bu bir finans denklemi; reklam engellemeden kaybedilen para henüz Widevine anahtarını çevirecek kadar değil, ama daha zayıf önlemler almaya yetecek kadar oldu ve plak şirketlerinden de baskı vardır; bu yüzden birkaç yıl içinde daha geniş dağıtılması muhtemel
      Tahminim, önce Content ID’ye takılan plak şirketi müzikleri ya da stüdyo klipleri içeren videolarla başlar; diğer üreticilere de isteğe bağlı bir etiket sunulabilir
      Bu videolar para kazanmada daha kullanışlıdır ve CDN avantajını bir anda kaybettirmez
    • Google muhtemelen üçüncü taraf istemcileri caydırmak, ama insanların arşivlemesine izin vermek istiyor
      Sessizce böyle yarım yamalak önlemler almak, bu hedefe ulaşmanın kusursuz ve tek çözümü

  • YouTube’un videoları nasıl dağıttığını hep merak etmişimdir
    İnternet berbatken bile iyi çalışıyordu; Güney Amerika’da her platform düzgün çalışmazken YouTube en akıcı video platformu
    Ona en yakın olan Netflix ama o bile epey geride

    • Evinize yakın ISP ağı içine önbellek sunucuları yerleştiriyorlar
      ISP’nin de çıkarına olduğu için buna izin veriyor
      ISP’nin darboğazı, kendi ağından daha geniş internet omurgasına çıkan bağlantıdır; büyük CDN’lerin önbellek sunucuları bu darboğazdaki yükü ciddi biçimde azaltır
      Netflix’in benzer kurulumuna dair belge: https://openconnect.netflix.com/

  • YouTube’dan hiç doğrudan video indirmeyi denediniz mi?
    youtube-dl, yt-dlp ya da bu tür web sitelerine güvenmeden bunu elle yapmaya kalkınca, sanıldığından çok daha karmaşık oluyor.

    • Çok uzun zaman önce buna benzer bir iş yapan bir Perl betiği üzerinde çalışmıştım: https://www.perlmonks.org/?node_id=636777
      Elbette bu tür betiklerin sorunu, YouTube’un video indirmeyi engellemek için değiştirdiği şeyleri sürekli takip etmek zorunda kalmanız.
    • Ben doğrudan bir kullanıcı betiği enjekte ederek hallediyorum.
      WEI’ye bakınca, uzun ömürlü olmayabilecek kendi USER AGENT’ımı kullanma yöntemi bu.
      İmzayı, n çözmeyi ve hız sınırlama fonksiyonunu yeniden uygulamaya uğraşmak yerine player.js dosyasını match(/(?:player\/([a-zA-Z0-9_-]+)\/)?(?:html5player|(?:www|player(?:_ias)?))[-\.]([^/]+?)(?:(?:\/html5player(?:-new)?)?|(?:\/[a-z]{2,3}_[A-Z]{2})?\/base)\.js/) ile bulup, içindeki ilgili fonksiyonları grep’leyerek doğrudan çağırıyorum.
      YouTube açısından kendi DRM fonksiyonu benim için .mp4 bağlantısını açtığından, bunun %100 normal göründüğü bile söylenebilir.
    • “Download” düğmesine basıp Premium ücreti ödemekten mi bahsediyorsunuz?

  • Teknik olarak bunların hepsi ilginç, ama etik açıdan yalnızca “Google’ın canı cehenneme” diye düşünmüyorsanız, ilk optimizasyonda, yani gerçek tarayıcı kontrolünden geçip normal tarayıcı hızını elde etme noktasında durmak makul görünüyor.
    Bu kadarı, YouTube kaynaklarını reklam engelleyici kullanan bir tarayıcı kullanıcısından daha fazla boşa harcamak anlamına gelmez.
    Hiçbir ücret ödemeden tam Gb/s hızını kullanmak ise tüm reklam engelleyici kullanıcılarının şansını zorlamak gibi geliyor.
    Elbette nihayetinde yine Google’ın canı cehenneme de denebilir.

    • Teknik olarak herkes ağ bağlantısının maliyetini ödüyor.
      YouTube’a azami hızla yüklenmenin etik dışı olduğunu söyleyecek kadar ileri gitmem, ama YouTube bunu engelleyecek önlemler alırsa da suçlamam.
      Sosyal medya görsellerinin üzerine gelince özgün boyutunda gösteren bir tarayıcı eklentisi kullanıyorum; Instagram anormal etkinlik uyarısı ve hesabı kilitleme tehdidi gösterdi.
      Eklentinin arka planda scraping yapıp yapmadığını kontrol ettim ama sorunlu bir şey görünmüyordu; muhtemelen Meta, standart istemciden farklı bir istek sırası görüp bunu veri scraping’i olarak değerlendiriyor.
      Bu, önlem ve karşı önlemlerin tekrarı; YouTube da kendi karşı önlemlerini uygulayıp scraper’ların yeniden karşılık vermesine yol açacaktır, ama meşru tüketim resmî istemcide oynatma hızının 2 katından daha hızlı olmayacağı için bir noktada indirmeyi o seviyeye kadar sınırlayabileceklerdir.
      Yine de indirmenin kendisinin kısıtlanmaması gerektiğini düşünüyorum.
      İçerik zaten yasalarla korunuyor ve çoğu insan videoları arşivleme, analiz etme, inceleme videosu üretme gibi makul nedenlerle indiriyor.
      YouTube içeriği boşlukta üretilmiyor; yayımlandıktan sonra yeni videoların yapılacağı ortamı oluşturduğu için bu yaratma özgürlüğü önemli.
    • Bunun ne kadar kötüye kullanım sayıldığından pek emin değilim.
      Sonuçta aynı miktarda veriyi yalnızca daha kısa sürede alıyorsunuz; yani daha fazla bant genişliği kullanıyor ama daha hızlı ortadan kayboluyor.
      Normal tarayıcı kullanım senaryosu, videonun sonuna kadar izlenmediği yaygın duruma göre ayarlanmış gibi.
      Baştan itibaren tamamını izleyip saklama niyetindeyseniz, bunun Google’ın bant genişliğini daha fazla tükettiğini söylemek zor; yalnızca bağlantı sayısı nedeniyle ek yük daha yüksek olabilir.
    • Şirketlerin etiği değil, yalnızca çıkarları vardır.
      Benim de benzer şekilde davranmam doğal.
    • YouTube kaynakları ve Gb/s deniyor ama çoğu durumda video aynı ISP ağı içinden sunuluyor.
      Çünkü YouTube’un neredeyse dünyadaki tüm ISP’lerde ve internet değişim noktalarında cache’i var; bugüne kadar yapılmış en büyük CDN olabilir.
      Örneğin yazının sahibinin YouTube URL’si Kanada ISP’si Videotron’u işaret ediyor.
      https://bgp.he.net/dns/rr1---sn-8qu-t0aee.googlevideo.com
    • Teknik olarak videolar indirilebilmeli ve bu engellenmemeli.
      Birinin nefret söylemi yaydığına ya da bana ve aileme hakaret ettiğine dair kanıt bırakmak için bile bu gerekli.
      Ekranı bir kamerayla çekmek de mümkün, ama Taş Devri’nden kalma bir çözüm gibi geliyor.
      Örneğin Mac’te tarayıcıda Netflix’in ekran görüntüsü alınamıyor; bu yüzden adil kullanım kapsamındaki meme üretimi bile elimizden alınmış durumda.