yt-dlp: najbardziej przydatne narzędzie w moim workflow, które nie ma nic wspólnego z AI
Każdy film, który zapisuję do notatek, przechodzi przez jeden program z wiersza poleceń. Dlaczego najtańszy tryb to ten, w którym w ogóle nie pobierasz wideo, gdzie to się sypie i co musiałem sobie wyjaśnić w kwestiach prawnych.
Większość rzeczy, które dziś archiwizuję — filmy, wykłady, kursy — jako pierwszy krok przechodzi przez jeden program. Nie ma w nim żadnej AI. Nie ma interfejsu webowego. Nazywa się yt-dlp i jest narzędziem wiersza poleceń, które pobiera obraz i dźwięk z sieci.
Ostatnio krąży po Instagramie sporo rolek w stylu „najbardziej przydatne narzędzie na GitHubie, którego nikt ci nie pokazuje”. Liczby w nich zgadzają się lepiej, niż się spodziewałem — ale kilka rzeczy mówi się tam swobodniej, niż powinno. Więc to sprawdziłem i opisałem, jak go realnie używam.
Co się w tych twierdzeniach zgadza
„Ponad 180 000 gwiazdek na GitHubie.” Zgadza się. Na 12 sierpnia 2026 ma ich 183 998. To plasuje go wśród najbardziej ogwiazdkowanych repozytoriów, jakie w ogóle istnieją.
„Public domain, nikt tego nie posiada.” Prawie. Licencja to The Unlicense, która zaczyna się zdaniem „This is free and unencumbered software released into the public domain.” Więc „wypuszczone do domeny publicznej” to uczciwy opis. Tyle że „nikt tego nie posiada” brzmi ładnie retorycznie, a prawnie jest nieprecyzyjne — w niektórych jurysdykcjach, na przykład w Niemczech, praw autorskich zrzec się nie można. Dokładnie dlatego Unlicense zawiera jeszcze zapasową licencję permisywną i wyłączenie rękojmi, zamiast polegać wyłącznie na tym oświadczeniu. W praktyce: bardziej nieograniczone to już właściwie być nie może.
„Pobierze nawet całą playlistę jednym poleceniem.” Zgadza się, i jest to jeszcze prostsze, niż się mówi — na playlistę nie trzeba żadnego przełącznika. Po prostu podajesz mu URL playlisty, a on pobiera ją w całości. Przełączniki są od czegoś odwrotnego: --no-playlist, kiedy chcesz tylko ten jeden film z linku, który wskazuje na oba.
„Wideo razem z dźwiękiem.” Domyślnie tak — odpowiada to -f bestvideo*+bestaudio/best. Haczyk, o którym nie mówi żadna rolka: do połączenia obrazu z dźwiękiem potrzebujesz ffmpeg. Bez niego yt-dlp po cichu wraca do pojedynczego, wstępnie zmiksowanego strumienia, co zwykle oznacza gorszą jakość. Nic o tym nie krzyczy, po prostu dostajesz gorszy plik.
Tryb, którego używam najczęściej: w ogóle nie pobierać wideo
To rzecz, której w tych rolkach nikt nie pokazuje, a przy moim zastosowaniu jest najbardziej przydatna.
Kiedy robię notatki z filmu, ten film nie jest mi potrzebny. Potrzebuję transkrypcji. A ta na YouTube w większości przypadków już istnieje — albo od autora, albo wygenerowana automatycznie.
Więc kombinacja, którą odpalam praktycznie non stop:
yt-dlp --skip-download --write-sub --write-auto-sub --sub-lang en --sub-format vtt <URL>
--skip-download oznacza, że nie pobierze się ani bajt wideo. Wypada z tego wyłącznie plik z napisami. Żadnych gigabajtów, żadnego miejsca na dysku, żadnego rachunku za transkrypcję.
To jest ta różnica, którą warto zapamiętać: jeśli wysyłasz filmy z YouTube do jakiegoś speech-to-text, najpierw sprawdź, czy napisy nie są już gotowe. W większości przypadków są. Zero złotych, gotowe natychmiast, a przy napisach robionych przez człowieka też dokładniejsze niż ASR.
Do tego biorę metadane:
| Przełącznik | Co dostaję |
|---|---|
--write-sub | Napisy od autora filmu |
--write-auto-sub | Napisy generowane automatycznie, gdy tych pierwszych nie ma |
--write-info-json | Metadane: tytuł, kanał, długość, data, liczba wyświetleń |
--skip-download | Nic z mediów nie zostaje pobrane |
Jeden praktyczny szczegół, na który się natknąłem: napisy automatyczne powtarzają linijki w kółko. VTT z YouTube jest pełne duplikatów, bo każda linijka jest przerysowywana. Zanim wyślesz to dalej, warto wyrzucić znaczniki czasu, tagi <...> i następujące po sobie identyczne linijki. Bez tego przetwarzasz jakieś trzy razy więcej tekstu, niż trzeba.
Gdzie to się sypie
Obsługiwanych serwisów są tysiące i YouTube, TikTok, X oraz Twitch działają. Ale nie każdy ekstraktor jest w tej samej kondycji, a autorzy sami piszą o tym na liście.
Najsłabszy jest Instagram. Główny ekstraktor nie jest wprawdzie oznaczony jako zepsuty, ale instagram:user — ten od profili — ma przy sobie adnotację „(Currently broken)”. Instagram ma też zdecydowanie najwięcej otwartych issues, w tym brakujący dźwięk w rolkach z muzyką oraz powracające problemy z cookies i limitami zapytań. W praktyce: na Instagram potrzebujesz cookies z przeglądarki, a co jakiś czas to po prostu przestaje działać. Sam wolę do tego gallery-dl, który z postami, karuzelami i rolkami radzi sobie w jednym przebiegu bardziej niezawodnie.
W przypadku TikToka jako zepsute oznaczone są ekstraktory poboczne (tiktok:effect, tiktok:sound, tiktok:tag), główny jest w porządku. Ekstraktor do X nadal nazywa się wewnętrznie twitter.
Ogólna zasada, która z tego wynika: ekstraktor to zależność od cudzego HTML-a i może się zepsuć w dowolny wtorek. Jeśli opiera się na tym coś, co musi działać, wymaga to nadzoru i planu na ten tydzień, w którym padnie.
youtube-dl kontra yt-dlp
Krótka uwaga, bo ciągle trafiam na poradniki, które polecają to pierwsze. yt-dlp jest forkiem youtube-dl (przez etap pośredni youtube-dlc). Różnica w praktyce: youtube-dl nie wydał nowej wersji od grudnia 2021, podczas gdy yt-dlp wypuścił wersję 2026.07.04 w zeszłym miesiącu i dostaje commity na bieżąco. Jeśli poradnik mówi ci „zainstaluj youtube-dl”, ma cztery i pół roku.
Część prawna, którą rolki pomijają
Tego nie chciałbym przeskakiwać, bo obchodzi się to dość systematycznie.
Pobieranie z YouTube narusza jego regulamin — z wyjątkiem funkcji, które YouTube sam do tego oferuje, jak tryb offline w Premium. To nie jest przestępstwo, to kwestia umowna, ale to realny warunek i zdanie „to narzędzie jest legalne” go nie załatwia. Instagram, TikTok i X mają analogiczne zakazy zautomatyzowanego dostępu.
Warto znać też historię. 23 października 2020 RIAA wysłała do GitHuba takedown na podstawie §1201 DMCA (obchodzenie zabezpieczeń technicznych) wymierzony w youtube-dl, a GitHub w ciągu mniej więcej jednego dnia wyłączył repozytorium razem z forkami. EFF napisała potem GitHubowi, dlaczego ta konstrukcja z obchodzeniem zabezpieczeń jest błędna, i 16 listopada 2020 GitHub przywrócił repozytorium — wraz z funduszem na obronę deweloperów i przepracowaną procedurą dla §1201. yt-dlp był wtedy jeszcze zbyt młody, żeby stać się celem, ale dziedziczy dokładnie tę samą prawną kalkulację.
Jak rozwiązuję to u siebie, trzy zasady:
- Własne treści, treści licencjonowane, domena publiczna albo Creative Commons. Pokrywa to zdecydowaną większość tego, do czego realnie tego potrzebuję.
- Cookies z zalogowanego konta tylko do rzeczy, do których mam dostęp w sposób uprawniony — i nigdy po to, żeby dostać się do czegoś niepublicznego. Tu przebiega granica między szarą strefą a czymś, czego obronić się nie da.
- Pobranie czegoś nie oznacza nabycia praw do tego. Zrobienie transkrypcji cudzego filmu na własne notatki to co innego niż publikowanie tego materiału dalej. Narzędzie jest neutralne, użycie już nie.
Dlaczego w ogóle o tym piszę
Bo ta rolka miała rację w jednej rzeczy, choć nie w tej, którą podkreślała: najbardziej przydatnym narzędziem w moim workflow z AI jest narzędzie, w którym żadnej AI nie ma.
Cała ta inteligentna część — streszczenia, notatki, wyszukiwanie w nich — działa tylko wtedy, gdy dane wejściowe leżą na dysku i mają postać tekstu. A ta nudna część, która je tam dostarcza, to wciąż ten sam program z wiersza poleceń, którego nikt nie wrzuca na slajdy.
Zweryfikowane 12 sierpnia 2026 wobec źródeł pierwotnych: repozytorium yt-dlp (liczba gwiazdek przez GitHub API), LICENSE, lista obsługiwanych serwisów, historia wydań, takedown od RIAA, EFF o przywróceniu repozytorium. Liczby gwiazdek i issues się zmieniają; traktuj je na dzień weryfikacji. Ten tekst nie jest poradą prawną.