Vlákno názorů k článku YouTube-DL a FFmpeg jako záloha mizejícího internetového obsahu od Heron - Asi není úplně na místě vyjmenovávat některé důvody...

  • Článek je starý, nové názory již nelze přidávat.
  • 18. 12. 2020 14:36

    Heron

    Asi není úplně na místě vyjmenovávat některé důvody pro mizení obsahu a ještě k nim psát politický komentář. Obsah prostě může zmizet z mnoha různých příčin a upřímně řečeno, blázen je spíš ten, kdo spoléhá, že to na internetu bude i po 10letech, než ten, kdo si to raději okamžitě uloží k sobě.

    Osobně "zálohuju" YT mnoho let, protože spousta kanálů se rozhodne zavřít krám (třeba i čeští kutilové, mám tu unikátní sbírku videí o opravě televizních kamer a techniky ze 60lety (AMPEX), autor jednoho dne prostě smazal svůj účet), hromadu přednášek z českých univerzit atd.

    Youtube-dl umí stahovat spoustu obsahu, je celkem dobrá rada jej prostě zkusit na libovolnou stránku s obsahem, který chcete, je velká šance, že to půjde (zná mnoho konkrétních stránek včetně českých televizí a dále zná mnoho typů přehrávačů a i z neznámé stránky dokáže vytáhnout video).

    Díky za příkaz k ffmpeg ke snímání obrazovky, já jsem si to vždy (když nebyla jiná možnost stažení), naklikal v OBS Studio.

    Někomu může pomoct moje dokumentace k ffmpeg (osobně teda nedoporučuju konvertovat audio do jiného formátu, audio zabírá velmi málo a je zbytečné mu ještě zhoršovat kvalitu) nebo trochu lepší nastavení youtube-dl.

  • 18. 12. 2020 16:34

    Jan Hrach
    Stříbrný podporovatel

    Když už jsme u snímání obrazovky, tak já používám toto:
    r=`xrandr |grep -oE "current [0-9]+ x [0-9]+," | cut -d " " -f 2-4 | tr -d ", "`
    echo Resolution: "$r"
    #r=1024x600 nebo natvrdo nastavit když chci snímat menší region
    ffmpeg -threads 2 -video_size "$r" -framerate 15 -thread_queue_size 32 -f x11grab -i :0.0+0,0 -f pulse -thread_queue_size 32 -i default -ac 1 -preset faster -acodec pcm_s16le -r 15 -crf 19 -async 1 -vsync 1 -pix_fmt yuv420p -y desktop-`date +%F-%H-%M-%S`.mkv

    Důležité byly ty různé thread_queue_size a async a tak, jinak se mi rozbíjí AV synchronizace.

    Pro „počítačový“ obsah, zejména barevný text na černém pozadí, je důležité použít pix_fmt co nepodsampluje barevné složky, jinak to pak není vidět.

    Pokud chceš nahrávat z audiovýstupu a ne z mikrofonu, tak si to po spuštění můžeš snadno přepnout v pavucontrol.

  • 18. 12. 2020 16:41

    David Ježek

    Já nejsem až takovej netopejr, ale po letech používání Opusu si dovolím tvrdit, že pro většinu lidí na většině jejich zvukových aparatur (včetně některých velmi slušných) není rozdílu mezi původním AC3 či původním 256kbit AAC a reencodingem do 112kbit Opusu. Mě prostě ten zvuk Opusu připadá ok, žádné stopy po výrazných kompresních artefaktech v předzvucích jako u MP3.

  • 18. 12. 2020 17:13

    Heron

    Nejde o netopejra, jde o to, že kvalita zvuku už tak dost často pokulhává. Jednak ti lidi nejsou zvukaři, potom první kompresi udělá už to záznamové zařízení, načež to ti lidi ještě proženou nějakýma efektama při stříhání, tj druhá rekomprese, potom se na tom ještě vyřádí YT, tj třetí rekomprese. Takže není důvod tam přidávat ještě další k tomu.

    Navíc je teda otázka, co má být účelem. Já komprimuju videa, u kterých to má smysl, typicky jsou to přednášky. H265 dovede být VELMI úsporný u statických scén. Tam lze bez problémů dosáhnout snížení velikosti na 20% bez ztráty informace. Rekord bylo jedno video, kde byla snímána jen tabule a třikrát tam vlezl přednášející a něco napsal. Tj stačily 4 snímky na celé video. "Pochopitelně" to bylo 4K 60fps, jak jinak. 8GB. Převod na h265 z toho udělal cca 100MB soubor, kde cca 80MB byl jen zvuk. V takovém případě mi fakt nedává smysl řešit ještě rekomprimaci audia.

  • 18. 12. 2020 16:51

    Michal Kubeček

    osobně teda nedoporučuju konvertovat audio do jiného formátu, audio zabírá velmi málo a je zbytečné mu ještě zhoršovat kvalitu

    Jak kdy, na youtube to tak možná bývá, ale jinak se běžně setkávám se soubory, kde má audio stream (5.1) 640 Kb/s a to už není tak málo, zvlášť když konverzí do HEVC stáhnete video na 1-1.5 Mb/s (a to není problém ani u 1080p s CRF 24-26, natož s hodnotou 32 doporučovanou v článku).

    A jak už je zmíněno v článku, občas může být důvodem pro konverzi zvuku i chybějící podpora v konkrétním přehrávači (teď jsem zrovna narazil na jeden, který odmítá EAC3.

  • 18. 12. 2020 16:56

    David Ježek

    Pěkné doplnění. Já samozřejmě do článku nedal vše do detailu. Ale právě ta (ne)podpora v různých rodinných zařízeních je ještě dnes oříšek - občas v rámci rodiny ještě dnes páchám věci do Xvidu 640×něco se 192kbit CBR MP3, protože to je prostě jediná spolehlivě fungující varianta. Ale je to už opravdu jen výjimečně.

  • 18. 12. 2020 17:20

    Heron

    natož s hodnotou 32 doporučovanou v článku

    Což je teda dost nízko. Já za minimální kvalitu považuju 28 a to ještě jen u videí, na které se nebudu koukat ale jen poslouchat (proto taky nedělám rekompresi audia). Pokud video nechci vůbec, tak ffmpeg -vn -c:a copy

    A jak už je zmíněno v článku, občas může být důvodem pro konverzi zvuku i chybějící podpora v konkrétním přehrávači (teď jsem zrovna narazil na jeden, který odmítá EAC3.

    Jasně, tak důvodů může být víc, takhle jsem dropoval hafo audio stop pro cizí jazyky. Jedno video s audiostopami pro "všechny jazyky světa", audio mělo víc než video.

  • 18. 12. 2020 17:47

    Michal Kubeček

    Mne těch 32 taky překvapilo, pro svou potřebu používám 24 tam, kde chci, aby to k něčemu vypadalo, 26 pro běžné filmy a seriály a 28 tam, kde předloha stejně nestojí za moc (např. předlistopadové filmy a seriály z iVysílání).

  • 18. 12. 2020 18:33

    David Ježek

    Přečti si tu pasáž v článku, rozepisuji to tam pro 32 - 28 - 25 podrobněji. 32 je už dost ne-bezpečné nastavení pro specifické užití.