YouTube वीडियो डाउनलोड सीमा को बायपास करना

 (blog.0x7d0.dev)
6 पॉइंट द्वारा GN⁺ 2023-08-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • YouTube फ़ाइल URL /youtubei/v1/player API से मिल सकता है, लेकिन उसे सीधे डाउनलोड करने पर अनौपचारिक डाउनलोड सीमा के कारण स्पीड बेहद धीमी हो जाती है
  • 2021 के मध्य के बाद URL में जुड़ने वाले n query parameter को base.js के JavaScript algorithm से बदलना पड़ता है; असफल होने पर YouTube चुपचाप स्पीड limit कर देता है
  • n को सही तरह से handle करने के बाद भी डाउनलोड समय वीडियो की लंबाई और आकार के हिसाब से adjust होता है; उदाहरण में 1.5GB वीडियो लगभग 4.0MB/s पर डाउनलोड हुआ
  • HTTP Range header से फ़ाइल को 10MB टुकड़ों में बांटकर नई connection से लिया जाए, तो limit लगने से पहले हर टुकड़ा तेज़ी से fetched किया जा सकता है
  • अंतिम फ़ाइल के लिए अलग-अलग दिए गए वीडियो और ऑडियो streams को ffmpeg से merge करना पड़ता है; yt-dlp, VLC media player, NewPipe और node-ytdl-core भी मिलती-जुलती technique इस्तेमाल करते हैं

YouTube फ़ाइल URL पाने का flow

  • वास्तविक media file URL /youtubei/v1/player endpoint call से लाया जा सकता है
  • यह API वीडियो title, description, thumbnail और format जानकारी लौटाता है, और format list से इच्छित quality का file URL चुना जा सकता है
    • उदाहरण video ID aqz-KE-bpKQ है
    • request body में videoId, context.client.clientName, context.client.clientVersion जैसी values शामिल होती हैं
    • context object की दूसरी values वे preconditions हैं जिन्हें API verify करता है, और web browser request observe करके allowed values ढूंढी जाती हैं
  • API से मिले adaptiveFormats[0].url को सीधे इस्तेमाल करने पर डाउनलोड लगभग बंद जैसा धीमा हो जाता है
    • उदाहरण में 1.5GB file 66.7kB/s स्तर पर दिखी
    • speed आम तौर पर 40~70kB/s तक सीमित रहती है
    • 10 मिनट का वीडियो पूरा लेने में लगभग 6 घंटे 30 मिनट लग सकते हैं

n parameter से बनने वाली पहली limit

  • 2021 के मध्य के बाद YouTube अधिकतर file URLs में n query parameter शामिल करता है
  • इस value को web page के साथ distribute होने वाले base.js के JavaScript algorithm से transform करना पड़ता है
  • YouTube n value को official client होने या न होने को अलग करने वाले challenge की तरह इस्तेमाल करता है
    • n न हो या सही तरह transform न हो, तो download speed limit चुपचाप लागू हो जाती है
  • transformation algorithm obfuscated होता है और अक्सर बदलता है, इसलिए हर बार content को reverse engineer करने वाला तरीका practical नहीं है
  • example implementation वर्तमान player version का base.js डाउनलोड करता है, n transformation code extract करता है, फिर original n value डालकर उसे चलाता है
    • YouTube embed page से base.js URL ढूंढता है
    • regex से challenge function name और function body extract करता है
    • Node.js के vm.runInNewContext से transformation function execute करता है
    • transformed value से URL का n parameter replace करता है

n transformation के बाद भी बची हुई speed limit

  • n parameter को सही तरह transform करने पर शुरुआती extreme limit हट जाती है, लेकिन YouTube अब भी variable download limit लागू करता है
  • limit का स्तर वीडियो के size और length के हिसाब से बदलता है, और download time को वीडियो length के लगभग आधे के आसपास fit किया जाता है
  • अगर media file हमेशा जितनी जल्दी संभव हो उतनी जल्दी serve की जाए, तो streaming service के लिए यह बड़ा bandwidth waste हो सकता है
  • example download में 1.5GB file लगभग 4.0MB/s पर डाउनलोड हुई

HTTP Range से छोटे टुकड़े तेज़ी से लेना

  • bypass method का core HTTP Range header से फ़ाइल को कई छोटे ranges में बांटकर download करना है
  • Range header हर request में प्राप्त किए जाने वाले file range को specify करता है
    • उदाहरण: Range: bytes=2000-3000
  • example code media file को 10MB segments में बांटकर process करता है
    • मौजूदा output file delete करता है
    • अब तक मिले bytes के आधार पर अगला 10MB range calculate करता है
    • हर request में Range header डालता है और responseType: 'stream' के रूप में लेता है
    • मिले data को file के अंत में append करता है
    • progress, total size और per-segment speed print करता है
  • यह तरीका इसलिए काम करता है क्योंकि limit rules लागू होने में समय लगता है, और छोटे segments नई connection पर बहुत तेज़ी से मिल सकते हैं
  • test output में 1464.99MB file पर ये speeds दिखीं
    • 0.68% point: 46.73MB/s
    • 1.37% point: 60.98MB/s
    • 2.05% point: 71.94MB/s
    • 6.14% point: 104.17MB/s
  • कुछ downloads ने 1Gb/s connection का लगभग पूरा इस्तेमाल किया, और average speed आम तौर पर 50~70MB/s, यानी 400~560Mb/s range में रही

वीडियो・ऑडियो merge और मौजूदा implementations

  • YouTube वीडियो और ऑडियो channels को अलग files के रूप में distribute करता है
  • इस structure में HD या UHD video वही audio file reuse कर सकता है, जिससे storage बचती है
  • कुछ videos language के हिसाब से अलग audio channels भी provide करते हैं
  • अंतिम चरण में ffmpeg से video file और audio file को एक में merge किया जाता है
    • -c copy से re-encoding के बिना streams copy किए जाते हैं
    • -map 0:v:0 से पहले input का video stream चुना जाता है
    • -map 1:a:0 से दूसरे input का audio stream चुना जाता है
    • merge के बाद temporary video और audio files delete की जाती हैं
  • पूरा example code youtube-download.js के रूप में दिया गया है
  • कई projects YouTube limits bypass करने के लिए मिलती-जुलती techniques इस्तेमाल करते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-15
Hacker News की राय

  • yt-dlp repository की चर्चा में जो देखा, उसके मुताबिक यह limitation HTTP Range header से नहीं, बल्कि सिर्फ range=xxx query parameter जोड़ने से भी bypass हो सकती थी
    Range को पूरे file पर set करने पर भी फिर से maximum speed मिल रही थी, और अगर मुझे सही याद है तो YouTube ने यह limitation पहले ही हटा दी थी
    संदर्भ: https://github.com/yt-dlp/yt-dlp/issues/6400

  • YouTube पर तो नहीं आज़माया, लेकिन ज़्यादा संदिग्ध streaming sites के videos मैंने web developer tools से download किए हैं
    ज़्यादातर protection ऐसी होती है कि developer tools खोलते ही न skip हो सकने वाला debugger statement बनाया जाता है और CPU-heavy code—शायद infinite loop या cryptocurrency miner जैसा कुछ—चलाकर video रोक दिया जाता है
    ज़्यादा अहम बात यह है कि यह code network request की जानकारी भी मिटा देता है, जिससे अब तक भेजे गए traffic का analysis मुश्किल हो जाता है, और Firefox का “Preserve logs” सच में logs preserve करना चाहिए
    यह कोई perfect defense नहीं है, इसलिए आखिरकार ऐसा कोई video नहीं रहा जो download न हो पाया हो, लेकिन मैं इसके काम करने के तरीके को और गहराई से समझाने वाली material देखना चाहूंगा

    • कुछ समय पहले ठीक इसी तरीके से बचने पर एक post आई थी, और solution simple होते हुए भी effective था: browser को फिर से build करते समय debugger keyword का नाम बदल देना
      हंसी आ जाए ऐसा था
      https://news.ycombinator.com/item?id=36961445
    • ऐसी anti-debugging techniques को bypass करने के लिए Anti-Anti-Debug [0] आज़माया जा सकता है
      इसी तरह की वजह से मैंने पहले कुछ घंटों में बनाया हुआ एक simple extension है
      0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...
    • यह अपने आप में browser side की बड़ी खामी जैसा लगता है कि किसी page को पता चल सकता है कि developer tools खुले हैं या नहीं
      developer tools खुले हैं या नहीं, यह web page को कभी पता नहीं चलना चाहिए, और लगता है इसे ठीक से implement किया जा सकता है
    • Firefox में कभी-कभी काम करने वाला तरीका यह है कि video पर shift+right-click → This Frame → Open Frame in New Tab दबाएं
      नए tab में developer tools काम करते हैं
    • अगर page browser developer tools detect करने की कोशिश कर रहा हो, तो traffic analysis के लिए सबसे पहले Wireshark इस्तेमाल करने का विचार आता है

  • अंतिम चरण में screen देखते रहने के लिए WorldCoin से payment करना पड़ेगा, और वह non-tradable WorldCoin शायद सिर्फ ads देखकर ही कमाया जा सकेगा
    screen में embedded छोटा Orb इसकी निगरानी करेगा, और आपने सच में तो यह नहीं माना था कि यह basic income के लिए है
    basic income की समस्या तो bank accounts और customer verification (KYC) से बहुत पहले हल हो चुकी थी

    • आंखों से कोई लेना-देना नहीं है?

  • सोच रहा हूं कि क्या इन दिनों किसी को yt-dlp speed limit की समस्या हो रही है
    मैं हमेशा mpv से YouTube देखता हूं, जो internally yt-dlp इस्तेमाल करता है, और पिछले हफ्ते से हालत बहुत खराब हो गई है
    शुरुआत में यह मेरे 500kB/s पर limit किए जाने जितनी तेज़ी से शुरू होता है, लेकिन थोड़ी देर बाद 3 सेकंड download करने पर सिर्फ 1 सेकंड playback मिलता है, इसलिए play करने से पहले काफी देर queue में लगाकर रखना पड़ता है
    मैं git version का yt-dlp इस्तेमाल कर रहा हूं, लेकिन इससे जुड़ा issue नहीं देखा

    • mpv yt-dlp से सिर्फ video URL लेता है और वह URL ffmpeg को दे देता है
      ffmpeg ने Range header से जुड़ा workaround implement नहीं किया है, इसलिए speed limit में फंस जाता है
      yt-dlp से सीधे download कराकर उसे mpv में pipe करके standard input से play कराया जा सकता है, लेकिन अभी download न हुए हिस्से पर seek करना टूट जाता है
      mpv issue tracker में इस problem से जुड़े कई issues हैं

  • YouTube इस process में छोटी-छोटी चीजें लगातार बदलता रहता है
    पहले मैंने YouTube videos के लिए internal editing tool बनाया था, जिसके लिए MP4 file चाहिए थी, और लगभग हर महीने YouTube changes की वजह से editor टूट जाता था, इसलिए debugger से देखना पड़ता था कि क्या बदला है और उसके हिसाब से adjust करना पड़ता था

  • थोड़ा अलग मुद्दा है, लेकिन सोच रहा हूँ कि क्या यह मेरा भ्रम है कि YouTube पर देखने पर वीडियो बहुत थोड़ा बेहतर दिखता है
    मैं अपने पसंदीदा वीडियो डाउनलोड करके VLC या AppleTV के Infuse पर देखता हूँ, और YouTube ऐप के “nerd stats” से पुष्टि कर सकता हूँ कि वही वीडियो/ऑडियो स्ट्रीम चल रही है
    लेकिन लगता है कि YouTube कोई बहुत subtle filter लगाता है जिससे blocky compression artifacts ज़्यादा smooth दिखते हैं
    यह edges को sharpen करने जैसा नहीं है; बल्कि ऐसा लगता है कि जहाँ edges नहीं हैं, वहाँ color transition वाले areas ढूँढकर blocky artifacts को कम noticeable बनाता है
    हो सकता है यह भ्रम हो, लेकिन YouTube पर स्क्रीन ज़्यादा vivid और solid दिखती है, जबकि downloaded वीडियो में background या shadows में बहुत subtle लेकिन दिखने वाले artifacts और हल्का jitter दिखता है, इसलिए 1440p वीडियो भी final quality में कम अच्छे लगते हैं
    ऑडियो में भी फर्क साफ़ है: YouTube पर volume आम तौर पर uniform रहता है, लेकिन downloaded वीडियो में volume बढ़ाना पड़ता है, जो असुविधाजनक है
    अच्छा होगा अगर VLC या Infuse भी YouTube की तरह वीडियो को बेहतर दिखाने वाली processing करें; यह color या sharpness filter से ज़्यादा channels के बीच experience consistent बनाने वाली audio leveling जैसी processing लगती है

    • ऑडियो के बारे में जवाब दे सकता हूँ
      YouTube और Spotify जैसी ज़्यादातर streaming sites ReplayGain नाम की चीज़ इस्तेमाल करती हैं
      यह वीडियो या गाने की average loudness calculate करके बना tag होता है, और upload के समय calculate किया जाता है
      Official YouTube client playback के दौरान उस tag का उपयोग करके volume adjust करता है, लेकिन download करते समय tag छूट सकता है, या MKV शायद ReplayGain tags को default तौर पर support न करता हो
    • Player द्वारा इस्तेमाल किया जाने वाला scaling filter और chroma scaling method sharpness को प्रभावित करते हैं
      Original resolution stream को fullscreen में चलाने पर black-and-white edges पर फर्क गायब हो जाना चाहिए
      Operating system के हिसाब से, दो fullscreen apps के बीच जल्दी switch करके फर्क test किया जा सकता है, और ISO 29170-2 5Hz की सलाह देता है
      Color changes वीडियो color space या monitor profile processing failure से आ सकते हैं, और इस case में screenshot actual app screen से अलग दिख सकता है
      Jitter frame drops हो सकता है, और अगर colored objects के edges पर pixelation दिखे तो यह nearest-neighbor chroma upscaling होने की संभावना है
    • एक YouTube वीडियो में कई video, audio, और combined streams होती हैं
      Browser जो stream चुनता है और youtube-dl या उसके fork द्वारा default में चुनी जाने वाली stream अलग हो सकती है
      पहले कुछ समय तक default रूप से best combined stream चुनी जाती थी, लेकिन अलग-अलग best audio और video streams की quality ज़्यादा होती है
    • VLC जैसे players बेहतर कर सकते हैं, और GLSL से आप अपनी पसंद की correction खुद भी बना सकते हैं
      मुझे खास तौर पर anime4k shader pack पसंद है; यह machine learning based है, लेकिन mpv में real time चलता है और शायद VLC में भी चल सके
      नाम के मुताबिक यह animation के लिए tuned है, लेकिन noise removal और deblurring ठीक हैं, इसलिए YouTube content को अक्सर देखने में बेहतर बना देता है, और restoration stage compression artifacts को काफ़ी अच्छे से handle करता है
      हालांकि यह animation के लिए बहुत ज़्यादा tuned है, इसलिए हमेशा अच्छा काम नहीं करता और कभी-कभी उल्टा खराब भी कर सकता है
      https://github.com/bloc97/Anime4K/releases
    • Browser का video pipeline VLC द्वारा इस्तेमाल किए जाने वाले pipeline से अलग हो सकता है
      Local file की ओर point करने वाले video element वाला एक simple HTML document बनाकर compare किया जा सकता है

  • हर बार जब YT downloaders के खिलाफ फिर कोई आधा-अधूरा measure deploy करता है, तो हैरानी होती है
    GOOG के पास Widevine भी है, फिर इस्तेमाल क्यों नहीं करता, यह सोचता हूँ

    • Widevine का software version बहुत कम समय में पूरी तरह crack हो जाएगा और one-click download addons से भी bypass हो जाएगा
      Users के लिए कुछ नहीं बदलेगा, और YouTube पर केवल Widevine चलाने का operational burden आएगा
      Hardware-based version इस्तेमाल करने पर unsupported devices में बहुत सारी problems हो सकती हैं
    • लगता है YouTube को content piracy या third-party clients इस्तेमाल करने से अपने-आप में ज़्यादा फर्क नहीं पड़ता
      उसे जिसकी चिंता है वह bandwidth waste है
      Ad-based video streaming sites में आम तौर पर bandwidth cost revenue से ज़्यादा होती है, लेकिन Google ने इतनी सस्ती bandwidth हासिल कर ली है कि वह ISPs पर free peering का दबाव डाल सके, इसलिए यह मुश्किल से viable बनता है
      ऐसी speed limits का मकसद सारे content को scrape करने वालों के बजाय actual users के लिए bandwidth का ज़्यादातर हिस्सा बचाकर रखना है
    • Widevine इस्तेमाल न करने की वजह यह है कि इसमें decryption step add होता है, इसलिए slow है; software video decoding को force करता है, इसलिए slow है; और web browsers केवल कम असरदार Widevine के सबसे कमजोर रूप को ही support करते हैं
      Goal हासिल करने में भी यह बहुत effective नहीं है, और बड़ी संख्या में users को platform से बाहर धकेलने की संभावना काफ़ी है
    • मुख्य वजह यह है कि यह CDN cache efficiency को थोड़ा घटाकर cost बढ़ाता है, और एक extra key management system चलाना पड़ता है
      YouTube के scale पर ऐसे systems को जितना हो सके कम रखना चाहेंगे
      साथ ही, यह Widevine Level 3 को बहुत बड़ा attack target बना देगा
      अंततः यह financial equation है; ad blocking से होने वाला नुकसान अभी Widevine switch दबाने जितना नहीं है, लेकिन weaker measures लेने जितना हो गया है, और record labels का pressure भी होगा, इसलिए अगले कुछ वर्षों में इसके ज़्यादा व्यापक रूप से deploy होने की संभावना है
      अनुमान लगाऊँ तो शुरुआत में Content ID से पकड़े गए label music या studio clips वाले videos से होगी, और दूसरे creators को opt-in tag दिया जा सकता है
      ऐसे videos monetization के लिए ज़्यादा उपयोगी हैं और CDN का फायदा एक साथ नहीं खोएँगे
    • संभव है Google third-party clients को रोकना चाहता हो, लेकिन लोगों को archive करने देना चाहता हो
      चुपचाप ऐसे आधे-अधूरे measures लेना उस goal को हासिल करने का perfect और इकलौता solution है

  • मैं हमेशा सोचता था कि YouTube वीडियो कैसे deliver करता है
    Internet खराब होने पर भी यह ठीक चलता था, और South America में हर platform ठीक से नहीं चलता, लेकिन YouTube सबसे smooth video platform है
    सबसे करीब Netflix है, लेकिन वह भी काफ़ी पीछे है

    • आपके घर के पास वाले ISP network के अंदर cache servers deploy किए होते हैं
      ISP को भी फायदा होता है, इसलिए वे allow करते हैं
      ISP का bottleneck उसके अपने network से बड़े internet backbone तक जाने वाला connection होता है, और बड़े CDN के cache servers उस bottleneck से बड़ा load हटा देते हैं
      Netflix की similar setup documentation: https://openconnect.netflix.com/

  • क्या आपने कभी YouTube से सीधे वीडियो डाउनलोड करने की कोशिश की है?
    youtube-dl, yt-dlp या ऐसी websites पर निर्भर किए बिना manual तरीके से करने पर यह उम्मीद से कहीं ज़्यादा जटिल है

    • बहुत पहले मैंने ऐसा काम करने वाली एक Perl script पर काम किया था: https://www.perlmonks.org/?node_id=636777
      बेशक, ऐसी scripts की समस्या यह है कि YouTube वीडियो डाउनलोड रोकने के लिए जो बदलाव करता है, उनका लगातार पीछा करना पड़ता है
    • मैं सीधे user script inject करके इसे handle करता हूँ
      WEI को देखें तो यह मेरे USER AGENT का इस्तेमाल करने वाला तरीका है, जो शायद लंबे समय तक न चले
      signature, n decoding और rate-limit function को फिर से implement करने की कोशिश करने के बजाय, player.js को match(/(?:player\/([a-zA-Z0-9_-]+)\/)?(?:html5player|(?:www|player(?:_ias)?))[-\.]([^/]+?)(?:(?:\/html5player(?:-new)?)?|(?:\/[a-z]{2,3}_[A-Z]{2})?\/base)\.js/) से ढूँढता हूँ, फिर उसके अंदर relevant functions को grep करके सीधे call करता हूँ
      YouTube के नज़रिए से कहा जा सकता है कि उसका अपना DRM function मेरे लिए .mp4 link खोल रहा है, इसलिए यह 100% normal जैसा दिखता है
    • क्या आपका मतलब “Download” button दबाकर Premium का पैसा देने वाले तरीके से है?

  • तकनीकी तौर पर यह सब दिलचस्प है, लेकिन अगर नैतिक रूप से सिर्फ “Google की ऐसी की तैसी” ही नहीं सोच रहे हैं, तो पहली optimization—यानी actual browser check पास करके normal browser speed पाने—तक रुक जाना reasonable लगता है
    इतना करने से आप ad-blocking browser user की तुलना में YouTube resources ज़्यादा waste नहीं कर रहे होते
    बिना कोई cost दिए पूरी Gb/s speed इस्तेमाल करना, ad-blocking users की पूरी किस्मत को आज़माने जैसा लगता है
    हालांकि अंत में बात फिर भी Google की ऐसी की तैसी वाली हो सकती है

    • तकनीकी रूप से, सभी लोग network connection की cost दे रहे हैं
      YouTube को maximum speed से hit करना मैं अनैतिक तो नहीं कहूँगा, लेकिन अगर YouTube इसे रोकने के उपाय करता है तो उसे दोष भी नहीं दूँगा
      मैं एक browser extension इस्तेमाल करता हूँ जो social media images पर mouse hover करने पर उन्हें original size में दिखाता है, और Instagram ने abnormal activity warning और account lock की धमकी दिखा दी
      मैंने check किया कि extension background में scraping तो नहीं कर रहा, लेकिन कोई खास समस्या नहीं दिखी; शायद Meta standard client से अलग request order देखकर इसे data scraping मानता है
      यह action और counter-action की दोहराई है, और YouTube भी अपने countermeasures implement करेगा ताकि scrapers फिर जवाबी उपाय करें, लेकिन legitimate consumption में official client पर playback speed के 2x से ज़्यादा तेज़ी से चलने की जरूरत नहीं होती, इसलिए कभी न कभी वह download को उसी हद तक limit कर पाएगा
      फिर भी मेरा मानना है कि download को अपने-आप में limit नहीं किया जाना चाहिए
      content पहले से ही कानून द्वारा protected है, और ज़्यादातर लोग archiving, analysis, review videos बनाने जैसे जायज़ कारणों से videos डाउनलोड करते हैं
      YouTube content vacuum में नहीं बनता, और publish होने के बाद यह नए videos बनने का माहौल बनाता है, इसलिए यह creative freedom महत्वपूर्ण है
    • मुझे ठीक-ठीक नहीं पता कि यह कितना abuse है
      आखिर वही amount of data कम समय में receive किया जा रहा है, इसलिए bandwidth ज़्यादा लगती है लेकिन जल्दी खत्म भी हो जाती है
      normal browser use case शायद उस आम स्थिति के लिए tuned है जहाँ लोग video अंत तक नहीं देखते
      अगर शुरू से ही पूरा देखने और archive करने का इरादा है, तो यह कहना मुश्किल है कि इससे Google की bandwidth ज़्यादा खपत होती है; हाँ, connection count की वजह से overhead ज़्यादा हो सकता है
    • companies के पास ethics नहीं, सिर्फ interests होते हैं
      मेरे लिए भी वैसा ही behave करना स्वाभाविक है
    • YouTube resources और Gb/s कहा जाता है, लेकिन ज़्यादातर मामलों में video उसी ISP network के अंदर serve होता है
      क्योंकि YouTube ने दुनिया भर के लगभग सभी ISPs और internet exchange points पर caches रखे हैं, और यह अब तक बना सबसे बड़ा CDN भी हो सकता है
      उदाहरण के लिए, लेखक का YouTube URL Canada ISP Videotron की ओर point करता है
      https://bgp.he.net/dns/rr1---sn-8qu-t0aee.googlevideo.com
    • तकनीकी रूप से videos डाउनलोड किए जा सकने चाहिए, और इसे रोका नहीं जाना चाहिए
      यह इसलिए भी ज़रूरी है कि कोई hate speech फैला रहा हो या मुझे और मेरे परिवार को insult कर रहा हो, तो उसका evidence रखा जा सके
      screen को camcorder से record किया जा सकता है, लेकिन वह stone-age solution जैसा लगता है
      उदाहरण के लिए, Mac के browser में Netflix screenshot लेने नहीं देता, इसलिए fair use के अंतर्गत आने वाला meme creation तक छीन लिया गया है