Vice studovat, mene trolit ;)
https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming
https://en.wikipedia.org/wiki/HTTP_Live_Streaming
Jedna se o terminus technikus. Sestim smir :)
Pro mě je přehrávání videa v browseru naprostá UX disaster. Kdykoli to jde, snažím se získat přímý link na soubor/použít youtube-dl/extrahovat URL HLS playlistu a použít desktopový mplayer/mpv. A pokud to nejde, tak většinou video prostě ignoruju, pokud to není něco opravdu extrémně zajímavého. Proč? mplayer/mpv poskytuje dvě pro mě zásadní funkce, které v browserech bohužel chybí:
- downmix na mono ( -af=pan=1:0.5:0.5). Stereo zvuk, když se nezanedbatelně liší kanály, je mi extrémně nepříjemný. Zkoušel jsem tohle dělat v systému na úrovni pulse audia ( pactl load-module module-remap-sink sink_name=mono channels=4 channel_map=left,right,left,right master_channel_map=left,left,right,right + v pavucontrol přepnout výstup aby používal tento filtr), což pak funguje pro všechny aplikace, i browser, ale způsobí to zhruba půlsekundový lag (nezkoumal jsem proč), takže když pak ve videu seekujete, vždycky po seeku trvá, než se začne přehrávat a celé to lagne, protože to čeká na AV sync
- změna rychlosti přehrávání. Neudržím pozornost, pokud nedostávám informace tak rychle, jak je jsem schopen zpracovávat (což v mplayeru typicky odpovídá rychlosti mezi 1.1 a 1.95, podle konkrétního řečníka a obsahu, a i z komplikovaných přednášek si odnesu víc, pokud se na ně podívám zrychleně a pak se vrátím ke kritickým částem ještě jednou, než kdybych se na to díval jednou standardní rychlostí). Browsery a javascriptové přehrávače buď neposkytují tuto možnost vůbec, nebo jen ve velmi hrubých krocích (1.25, 1.5, 2), a navíc se k tomu snaží zvuk zrychlovat nějakým algoritmem, který se snaží zachovat pitch („scaletempo“), a který je příšerný. Zrychlení tím, že to naivně zresampluje, aniž by se to snažilo měnit frekvence, mi přijde mnohem lepší.
A pak různé drobnosti, jako že klávesové zkratky na volume/seek/pause jsou pořád stejné.
Problem male hustoty informaci ve videu mam taky. Nez se vetsina recniku vykeca, tak usinam. Nejhorsi videa jsou navody na software. Nez 5 minut koukat na video, tak radeji hledam clanek, kde jednoduse napisou "kliknete semhle a pak tamhle".
Obvykle to resim preskakovanim ve videu. Podobne jako u rychlocteni, popreskakuji video abych ziskal celkovou predstavu, a pak se vracim ke konkretnim bodum ktere potrebuju pochopit do hloubky.
Ale i tak je obvykle clanek lepsi nez video.
„[...] Nez se vetsina recniku vykeca, tak usinam. Nejhorsi videa jsou navody na software. [...]“
Naprosto souhlasím a nejen v rámci práci s nějakým softwarem, ale u mě je to především o programování. Ten trend všechno cpát do video-tutoriálů, je mi opravdu proti srsti a to jak z důvodů, které píšete, tak třeba proto, že dost často na taková videa narážím, když hledám konkrétní problém v již známém prostředí. Hledejte v 10 - 30 minutovém videu o tom, co už dávno víte, tu jednu - dvě věty, které vám chybí. Něco jako ctrl+f prostě neexistuje a když si omylem zapnu na YT automaticky generované titulky, tak vidím, že i kdyby využili transkripci pro vyhledávání, stejně by tam půlka informací chyběla...
Dost často mne ve skutečnosti takové titulky matou, protože mi podstrkují úplně jiná slovíčka, než jsou skutečně řečena a jen podobně zní. Chápu, že to může být problém jen ve specializovaných doménách, jako je programování, ale tím spíš mi víc vyhovuje psaný text. Rychle přeskáčku, co znám a naopak u kódu, který používá funkce, které neznám, se na minutku zastavím a dohledám v referenci detaily, které z příkladu nemusí být zjevné.
To je taky pravda, byť tomu nepřikládám takovou důležitost, protože a) se jedná o potenciální vektor útoku (lze do HTML něco skrýt, byť jsem se s tím ještě nesetkal) a b) většinou hledám princip nebo použití API, které neznám a tam - obzvlášť v době auto-doplnění v IDE - to není IMHO zas tak velký problém...
Navíc, i když mám tu možnost copy-paste, raději si to přepíši nejen z paranoidních důvodů výše, ale i proto, že když ručně doplňuji proměnné, nutí mě to přemýšlet nad kontextem, nad tím, co všechno daný kus kódu vlastně potřebuje jako vstup a co všechno je výstup.
Presne tak. Ale vela kvalitnejsich kanalov da aj link pod video na pouzite kody, manualne upravia titulky (s tym si nie som isty, ale rozdiely su dost viditelne), alebo daju kvalitny text priamo do popisky clanku.
Uplne naprd su potom videa, kde jediny popis je len titulka videa, automaticky minus.
Uz sa mi inak stalo ze som kopiroval kratky kod z videa cez OCR :D
Totální souhlas. Osobně když to jen trochu jde, do vyhledávání jakékoli dokumentace dávám automaticky -youtube, a když to nejde, nadávám u toho jako špaček.
Videa používám hlavně na dvě věci. Jednak na VŠ přednášky, a pak pak na hledání návodů "jak pod 9 plastovými kryty a za sedmery nestandardními šrouby vyměnit nějakou triviální součástku" a v obojím případě je pro mě mnohem snadnější video stáhnout a přehrávat lokálně. (v prvním případě kvůli rychlému seeku , kdy se nepříliš dobrý net s lokálním SSD prostě nedá srovnat) a snadnému ovládání přehravače, v druhém případě někdy je potřeba najít konkrétní frame dva a to se ve webových bazmegách opravdu rozumně nedá.
Každý má svoje důvody proč používat ten svůj prohlížeč/přehrávač. Tyhle integrované ludry jsou zlo a řeším to úplně stejně, stáhnout a přehrát, jinak nezájem. Pro uživatele jen nejlepší pokud dostane data a o jejich prezentaci se postará sám, jenže dneska je trend přesně opačný, poskytovatel chce řídit prezentaci dat tak jak chce on. Pokud by úvod článku měl podchytit současnou situaci pak by měl znít: Co kdyby každá televizní stanice měla svůj vlastní televizní přijímač. Každý byl byl jiný, jinak kvalitní s jinými možnostmi a hlavně použitelný pouze na tu konkrétní stanici. Navíc by jednou týdně přiběhl kurýr odnesl si ten starý a přinesl nový, někdy lepší někdy horší, nebo by odnesl starý a místo nového jen suše konstatoval že nový bude až si do obýváku vyvedete třífázovou zásuvku.
Spíš mě udivuje, že nejmenovaný dominantní výrobce browseru si v jiných případech v podstatě dělá co se mu zachce, ale tak podstatnou věc jako videopřehrávač, která by si přímo říkala o to implementovat jednou v browseru a to pořádně, si pro youtube radši plácá v javascriptech, takže výsledek je takový že každý po světě nezávisle znovu a znovu vynalézá kolo.
No dává tohle smysl?
1. crossfeed, obsahuje to napríklad PulseEffects,... nepotrebujete potom video ani sťahovať.
2. No na YT napríklad už je možné si nastaviť vlastné tempo / rýchlosť prehrávaní. A ono není to zas taký problém, dá sa odchytiť audio/video obsah s možnosťou zmeny rýchlosti prehrávania pluginom v prehliadači, a modifikovať hodnoty, krokovania, limity, takže keď UI samotné neponúka nastaviť rýchlosť 1.27548 tak to dokážeš cez plugin. Navyše ak je nejaké video už blbo spomalene natočené, žiaľ ani po stiahnutí to moc nepomôže, a musíš pretáčať.
3. Skratky moc problém nemám v Chrome je podpora pre hardware media keys, zvuk viem meniť cez hlasitosť okna v systéme (aj klávesami).
22. 9. 2020, 13:55 editováno autorem komentáře
youtube-dl/extrahovat URL HLS
Nepoužívám youtube-dl, tak se zeptám umí zpracovat playlist který má cesty segmentů relativní? Já takový playlist musím upravovat v textovém editoru přes Nahradit, abych tam dostal tu část cesty která tam není, jinak to přehrávač otevřít nemůže. Mám problém jen s javascriptovými playlisty z Vimea, ne vždy používají tyhle. Jinak jsem se nesetkal s žádným který by nakonec přehrát nešel včetně DASH.
Kolikrát čtu, že někdo nepřehraje DASH od ČT když to jde bez problémů.
pouzivani skriptovaciho jazyka na backendu je preci naprosto normalni a bezne. PHP, Python a posledni dobou fici JS/Node.JS. Ty skriptovaci jazyky se stejne JIT kompiluji, takze rozdil ve vykonu u beznych aplikaci je zanedbatelny. A konkretne JavaScript diky asynchronnimu pristupu PHPko a Python bez asyncio porazi na plne care.
pouzivani skriptovaciho jazyka na backendu je normalni u PHP a jinych bastlu, to ze se tlaci na cenu a pak studenti VS matlaji neco v Node.js nebo PHP je proste hruza a muze se to obhajovat jakkoliv. Misto kvalitniho programu se proste udela bastl ktery se automatizovane vydeplojuje na tisicovku serveru i kdyz by jich u normalniho kodu stacilo podstatne min...
Jeden by čekal, že programovací jazyk je od toho, aby se v něm programovalo. Tzn. napíši kód v tom jazyce a pak zkompiluji nebo rovnou spustím.
Ale Pythonisti to mají asi nějak jinak - oni vlastně programují v céčku (protože jinak by to bylo moc pomalé) a pak jenom předstírají, že to je v Pythonu...
Python tedy není programovací jazyk?
standard library: https://docs.python.org/3.7/library/asyncio.html ?
A libs jako FastAPI to mají by default (https://fastapi.tiangolo.com/):
```
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
async def read_root():
return {"Hello": "World"}
```
django má od v3 support pro async taky: https://docs.djangoproject.com/en/3.1/topics/async/
videa na streamu jsem prestal sledovat, protoze nejde vypnout autoplay. dokonce sem jim to psal, ale odepsali mi ze to proberou, ale nic s tim neudelali.
po skonceni videa jsem byl zvykly vzdy procist diskuzi, takhle mi to ale preskakuje na dalsi video, coz znamena dalsi otravna urvana reklama, a kdyz kliknu na zpet tak jeste jedna reklama. to me tak znechutilo ze jsem ten web prestal pouzivat.
Prehrani dalsiho videa se da stopnout dokonce dvema zpuzoby. Prvnim je, ze kliknes nekam do FB komentaru (napr. do textoveho policka pro odpoved). Aplikace pak vyhodnoti, ze se snazis napsat komentar a neprepne te na dalsi video. Druhym zpusobem je kliknout na tlacitko "Zrusit" kdyz se objevi zaverecny odpocet, ze se pusti nove video (je to vzdy cca 10s pred koncem).
a to je prave ten problem. Provozovatel potrebuje ukazat zadavatelum reklamy ze uzivatele shledli bambilion miliard videi za tyden tudiz udela cokoliv proto aby zobrazil dalsi video. Uzivatel se obvykle chce podivat na nejake konkretni video a mozna ho okomentovat. Misto toho aby provozovatel uspokojil pozadavky uzivatele tak na nej z vysoka s**e a jde mu primarne jenom o zisk. Proc bych ja jako uzivatel mel hledat nejakou berlicku abych zustal na strance kde jsem chtel byt? Co kdyz do budoucna provozovatel zavede ze pro zruseni prechodu na dalsi video budete muset zadat vysledek nejakeho fyzikalneho vypoctu/nebo cokoliv jineho? Treba to je jeden z milionu duvod proc ignoruji Seznam...
Dle vasich rozcarovanych reakci se mi nezda, ze byste ho ignoroval :-) Nicmene, ty zpusoby tam jsou, jeden je dokonce explicitni - kliknout na tlacitko "Zrusit", kdyz jede zaverecna obrazovka vam prece dava jasnou volbu dalsi video nepoustet.
Ano, je mi jasne, ze je to pro vas nejaky krok navic. Ale tento krok vam zaruci, ze se aplikace bude chovat presne jak chcete.
A ta druha zminovana, podle vas "berlicka", se take chova jasne. Pokud ma uzivatel rozepsany komentar, rovnez se nepousti dalsi video. Jedina podminka je mit focs ve fb komentarich.
To muselo dát práce - a přitom...
Hlavní efekty to pro mě má dva:
1) Videa nejdou (alespoň ne snadno) ukládat. Což by šlo, kdyby autoři těch webu nic neprogramovali a pouze použili tag video. GUI přehrávače je součástí www prohlížečů.
2) Tzv. adaptivní streaming je dost otravná věc, když má člověk pomalejší nebo méně spolehlivou linku. Video se v náhodných intervalech rozpadá, zasekává a kostičkuje. Při klasickém řešení se tohle neděje - člověk si vybere kvalitu, která odpovídá rychlosti jeho připojení nebo si počká, až se dostatečná část videa natáhne do cache - a pak už si užívá jen nerušené sledování videa v konzistentní kvalitě.
Když už máte potřebu něco programovat, tak by bylo lepší přidat podporu pro vaše servery do youtube-dl.
1) coz bezne uzivatele vubec nezajima
2) takovy YouTube, Netflix, HBO GO, Kuki i Seznam s vami nesouhlasi a adaptivni streaming je dneska bezna vec. Pokud chcete fixni kvalitu, tak si ji v nastaveni muzete vybrat (prakticky na vsech sluzbach). Vetsina lidi to ale nedela a je spokojena s adaptivnim streamingem. On totiz prave brani tomu, aby se video zasekavalo a zmenu kvality lide vnimaji mene negativne nez preruseni prehravani
Tady jsme na Rootu. Jestli chcete běžné uživatele, tak jste ten článek měli vydat spíš na Novinkách. I když i ti běžní uživatelé už často ví, že obsah z internetu běžně mizí a chtějí mít data uložená u sebe.
Youtubue, RT a spoustu dalších pomocí youtube-dl zálohovat jde. A to jsou služby, které hostují obsah pro velkou část planety - ne jen pár milionů obyvatel tady v ČR.
Když už máte potřebu něco programovat, tak by bylo lepší přidat podporu pro vaše servery do youtube-dl.
To by bylo skvělé... ale bohužel jen pro uživatele. Provozovatel má úplně jiné zájmy a pokud řeší nástroje jako youtube-dl, tak spíš jak jejich používání zabránit. :-( Koneckonců, kdyby chtěli uživatelům umožnit si video stáhnout, aby si ho mohli pustit kdykoli, kdekoli a jakkoli, bylo by jednodušší dát tam rovnou odkaz na download.
Proč chybí implementace těch nových technologií?
Jsou tam nějaké důvody které se týkají autorských práv?
Zvažovali jste využít webtorrent aby jste odlehčilo serverům (tam by se muselo řešit aby nebyl upload u dát placených nebo omezených poskytovatelem).
Nebylo by lepší používat nějakou kvalitní implementaci progresivního stahování a formát AV1 ?
Dobrý den,
z kontextu bohužel není zcela patrné o implementaci jakých technologií zde mluvíme. O použití WebTorrent jsme vzhledem k požadovaným vlastnostem neuvažovali. Formát AV1 se jeví jako vhodný adept pro budoucí použití, jeho aktuální podpora napříč zařízeními je však zatím primárně na softwarové úrovni (jak z pohledu encodingu tak i decodingu) a tedy poměrně náročná na výpočetní výkon.
a) node bola teda riadne blba volba. na toto sa malo pouzit Go
b) pletu sa tu trochu pojmy/kontext - streamovanie videa ako je tu popisane je len stahovanie uz existujuceho video suboru ktory je len rozkuskovany na mensie segmenty v roznej kvalite. ci sa pouzije hls alebo mpeg-dash je irelevantne, mimo toho ze su to uplne primitivne jednoduche "technologie", oboje maju len manifest/playlist suborov ktory sa sekvencne stahuje. nejde teda o realny stream - jeden datovy tok. len sa to natlaci do media sourcu v javascritpe v prehliadaci a to je asi tak vsetko. keby robili realne adaptivne streamovanie kedy sa pouziva jeden datovy tok a podla rychlosti citania klientom sa automaticky prepina na vhodnejsiu kvalitu segmentov tak to uz by bolo nieco, ale tu nejde o ziaden zazrak hodny clanku. tieto primitivne tecnhologie sa pouzivaju hlavne kvoli bufferovaniu kedy sa klient moze odpojit a pripojit bez vzniku lagu v prehravani, inak by ich ISP asi rovno odstrihli.