Bugfixek:
- Az új URL-formátum lekezelve.
Letöltések:
- FreeBSD AMD64
- Linux AMD64 GTK2
- Linux AMD64 Qt5
- Linux i686
- OpenBSD AMD64
- Solaris AMD64
- Manual
- Online manual
(Az SHA1 ellenőrzőösszegeket a letöltőoldalon kiírja a rendszer.)
- TCH blogja
- A hozzászóláshoz be kell jelentkezni
- 350 megtekintés
Hozzászólások
Örülök, hogy látlak.
- A hozzászóláshoz be kell jelentkezni
Boccs, ha offtopik, de volna egy azért többé-kevésbbé idekapcsolódó kérdésem:
Ha egy konkrét YT videóhoz azonos felbontás (pl. 480p), és konténer (pl. mp4) mellett van külön olyan protokollos változat h. HTTPS meg olyan h. DASH, és a HTTPS-nek alacsonyabb bitrate van megadva mint a DASH-nél, akkor a DASH-es változat letöltése jobb minőségű videót fog eredményezni? Vagy a többlet adat az a DASH sztríming overhead-je miatt van, és az értékes videó tartalom az végeredményben ugyanakkora ebben a fajtában is, mint a csupasz HTTPS-es változatnál? Azaz archiválás célra inkább a látszólag alacsonyabb bitrate-es HTTPS-es protokollú változatot érdemes letölteni egy adott videóból? Illetve mintha azt is olvastam volna, h. a DASH sok fragment-ból fűzi össze az eredményt. Azaz ha menet közben valamelyik fragment letöltésében hiba csúszott be, akkor a végeredményben artifaktolást okozhat, amibe sok lejátszó akár bele is fagyhat?
- A hozzászóláshoz be kell jelentkezni
A DASH nem protokoll, hanem streaming technika, ami ugyanúgy HTTP-n/HTTPS-en keresztül streamel.
A konkrét tartalom minőségének viszont semmi köze nincs ahhoz, hogy hogy adják oda; ugyanaz a videó ugyanaz a videó marad, akár HTTP-n, akár FTP-n, akár torrenten keresztül töltöd le. Ha a DASH-es felálláshoz jobb bitrátát ajánl fel a YT, akkor elméletileg jobb lesz, bár ez is függ jópár más dolgotól; hogy mást ne is mondjak: a codec-től, mert pl. egy MPEG2 videó hiába bír valamivel magasabb bitrátával, mint az OGM-es párja, valószínűleg rosszabb képminőségű lesz.
Ami pedig a fragment letöltésébe csúszott hibát illeti: abba nem belefagyni kell, hanem újra letölteni; ezt csinálja a yt-dlp és a YTFE is az EDL videóknál...bár a DASH technikát konkrétan nem ismerem, most hallottam róla először (a YT-n eddig nem találkoztam vele), így nem tudom, hogy ott is chunklist van-e és újrakérhető, vagy sequential streaming és ami elveszett, az elveszett...de akkor sem belefagyni kell, hanem vagy hibát dobni és leállni, vagy megkérdezni a júzertől, hogy mi legyen.
- A hozzászóláshoz be kell jelentkezni
1) ugyanabból az MP4 - AVC-s videóból van eltérő bitrate-es verzió HTTPS és DASH metódusra.
2) A belefagyás a hibásan letöltött és összemuxolt eredmény után a videóplayer-bem jelentkezés-re értettem. Azaz ha a fragment letöltés során látszólag letöltötte a yt downloader az adott szeletet, de hibásan. Azaz látszólag "kilóra" megvan a videó, de a tartalmába hiba csúszott.
- A hozzászóláshoz be kell jelentkezni
1) Akkor értelemszerűen a magasabb bitrátájú jobb minőséget ad.
2) Ha a DASH nem ad a szeletekhez ellenőrzőösszeget, ami alapján validálni lehet a letöltött tartalmat, az egy elég szomorú koncepciós hiba. Ha viszont ad, akkor az egyrészt letöltő még szomorúbb implementációs hibája, hogy nem validálja, másrészt a videoplayer csúnya bugja, hogy belefagy. Az érthető, hogy hibás tartalom esetén nem tudja kirajzolni rendesen a képet, de akkor vagy skippelje a frame-eket, vagy dobjon hibát. Ha pedig a letöltött szelet úgy károsodott, hogy nem detektálható a károsodás (nem lesz a decoding alatt túlírás, stb.), akkor meg érthetetlen, hogy miért fagy bele, hiszen valid a tartalom, csak épp garbage... Ha a tartalom hibás, de valid, senki nem hibáztathatja a playert, hogy szemetet rajzol ki pár másodpercig, ha egyszer szemét van ott; de a belefagyás az bug.
- A hozzászóláshoz be kell jelentkezni
BTW, egyébként már van 1.18.3 is, pár apróbb bugfix-szel, meg most már a mujs nevű JS interpretert is megtalálja (ha az általa nézett könyvtárakban van).
- A hozzászóláshoz be kell jelentkezni