Download videoer fra blob URL'er

#0: Blot til information ...

Tak for det, så ved man det.

#1
Selv tak, og stadig blot til information:

Måske tænker nogle: Kan man selv opsætte en blob server?
Svaret er ja, men blob URL'er genereres i browserens API, og ikke på serveren. Derfor er svaret, på en måde, også nej.

I henhold til youtube-dl, så benytter youtube-dl det her fantastiske program ffmpeg. Tilsammen er det derfor muligt at downloade medie filer fra blob URL'er, uanset om medie filen er fragmenteret eller ej, fordi blob URL'ens Playlist henviser til dem. Er de fragmenterede, vil youtube-dl og ffmpeg samle den til en.

De her playlist filer (fx m3u8), henviser til fragmenterede dele af den samlede medie fil, eksempelvis med *.ts extension.

Hvis blob URL'en ikke indeholder en playlist fil, så er det sandsynligt mede filen ikke er fragmenteret. I det tilfælde, virker en browser installeret Download Manager formentlig.

I teorien kan VLC det samme som youtube-dl, men det har jeg ikke testet.

Blob er et akronym for Binary Large OBject

Typisk er der to slags m3u8-filer. Den første er master.m3u8. Her listes de forskellige versioner af videoen, fx opløsning, bitrate, sprog mv.

Hver af disse versioner er et nyt link til index.m3u8. Det er i denne at de enkelte fragmenter findes. Typisk varer hvert fragment 10 sekunder, men det kan variere. Det vil dog altid fremgå af index-filen.

Undertiden kan filerne hedde noget andet end master og index, men det er de mest benyttede navne.

For ondemand-videoer findes alle fragmenter allerede hvorfor videoen kan optages nærmest lige så hurtigt som båndbredden og serveren tillader. For live-videoer præsenteres et rullende "vindue" af fx 3 fragmenter som derefter kan hentes ned. Så indlæses index-filen igen, og man får et nyt sæt fragmenter som er klar. På den måde fortsættes det indtil man stopper afspilningen/optagelsen eller live-udsendelsen slutter.

I nogle tilfælde, som fx NRK TV, er det rullende vindue på flere timer. Således er det muligt på NRK at se/optage en film fra start selv om man kommer en time for sent ind i den. Den funktion har DR TV desværre ikke.

TV4ever virker ved bl.a. at sniffe disse m3u8-url'er fra videoerne. Dvs. den opretter nogle event-handlere på den indbyggede browser og bliver orienteret om alle requests af bestemte typer og filnavne, heriblandt m3u8 og adskillige andre. Det kan fx også være undertekster. Så henter den masterfilen og vælger den ønskede båndbredde. Ud fra dette hentes den korrekte index-fil hvori alle fragmenterne er listede. Disse hentes så via ajax-kald fra javascript og gemmes via chrome.fileSystem API'et.

Nogle gange er videofragmenterne krypterede, men nøglen fremgår af m3u8-filerne. Så det er lidt som at låse døren og hænge nøglen på dørhåndtaget.

Deciderede streamingtjenester som Netflix benytter dog deciderede krypteringsplugins som fx Widevine og disse er til gengæld ikke sådan at danse med. Mig bekendt er Netflix' kryptering aldrig blevet brudt, og de forskellige torrents der ligger rundt omkring som stammer fra Netflix er normalt fremstillet med HDMI-grabbere.

En glimrende gennemgang af #3.

Imidlertid kan det undertiden være nødvendigt at benytte en manuel metode, eksempelvis med en HDMI grabber #3 allerede omtaler.

Her et eksempel med en medie fil fra JetLoad (der er flere), hvor en HDMI grabber ikke er nødvendig.

Det er kun dokumentation på at det virker på baggrund af beskrivelserne.
https://www.dropbox.com/s/d4yyxif2pvii648/a-manual-download-from-a-blob…

Det her med at downloade med browserens dev værktøj er ikke konsistent. Det er ikke muligt at beskrive metoder der altid gælder.

Eksempelvis er det ikke nødvendigt altid at benytte playlisten (*.m3u8). Nogle gange kan man bruge en af *.ts filerne. Det kan være en fordel hvis man oplever timeout med playlisten. Sker det, får man ikke hele medie filen downloadet.

Sandsynligheden for at downloadet afbrydes, er måske mindre hvis man bruger en af *.ts filerne. Det kan oven i købet være nemmere, ved blot at åbne *.ts filen i en browser fane (helt uden youtube-dl).

Imidlertid, hvis man downloader en *.ts, skal den efterfølgende konverteres til fx *.mp4 eller *.mkv m.f., med dit foretrukne værktøj.

Det er pudsigt du nævner det. Fordi jeg er netop ved, at konvertere .ts filer, der er hentet med TV4Ever, som ligger i min Google Drive, til MP4 med HandBrake. Jeg bruger HandBrake til ripping af DVD og konvertering af filer. Det er et super godt program med en god brugerflade og avancerede funktioner.

Jeg konverterer .ts filerne og gen-uploader dem til Google Drive, da .ts filer ikke er mulige, at afspille i Google Drive. M4v, MKV, og MOV filer er heller ikke mulige, at afspille i Google Drive, ligesom FLAC heller ikke er det.

#6
Handbrake er også min favorit. Det er et virkeligt godt program.
Man kan også installere ffmpeg (nødvendigt med youtube-dl), eller downloade MystiQ Video Converter AppImage herfra. Der er også en macOS version: https://www.pling.com/p/1340589/#files-panel

Til YouTube kan man også bruge Clipgrab, hvis man gerne vil have en grafisk YouTube downloader.

#5: Eksempelvis er det ikke nødvendigt altid at benytte playlisten (*.m3u8). Nogle gange kan man bruge en af *.ts filerne. Det kan være en fordel hvis man oplever timeout med playlisten. Sker det, får man ikke hele medie filen downloadet.

Kan du ikke lige forklare nærmere hvad du mener?

#7: Det er pudsigt du nævner det. Fordi jeg er netop ved, at konvertere .ts filer, der er hentet med TV4Ever, som ligger i min Google Drive, til MP4 med HandBrake.

Jeg bruger mest ffmpeg. Det er lynhurtigt og nemt. Jeg bruger dette lille script som bør ligge et sted i path'en:

#!/bin/bash
for f in $*
do
filename=$(basename "$f")
extension="${filename##*.}"
basename="${filename%.*}"
ffmpeg -i $filename -acodec copy -vcodec copy -bsf:a aac_adtstoasc $basename.mp4
touch -r $filename $basename.mp4
done


touch-sætningen gør at mp4-filen får samme tid som den oprindelige ts-fil.

Jeg bruger scriptet således:

ts2mp4 minfil.ts

eller

ts2mp4 *.ts

#9: Kan du ikke lige forklare nærmere hvad du mener?
Jo. Hvis websitets server levere fragmenterne (*.ts) meget langsomt, så kan der ske det at sitet afbryder forbindelsen med *.m3u8 før download er færdigt. Youtube-dl skriver noget i retning af fejlmeddelsen: Site is Gone. Det medfører at mediefilen mangler de sidste *.ts filer, og derfor er mindre end forventet.

Hvis man så prøver et download med en af *.ts filerne, istedet for *.m3u8, så downloader den alligevel hele mediefilen, men i et lidt højere tempo, således at filen er komplet. Ulempen er så at *.ts filen er inkompatibel med visse devices ( fx TV med flere), og efterfølgende derfor skal konverteres.

#10: Hvis man så prøver et download med en af *.ts filerne

Det er nok her jeg ikke forstår hvad du mener. Hvordan downloader man med en af ts-filerne?

#10: Ulempen er så at *.ts filen er inkompatibel

Den ændrer ikke kompatibilitet uanset hvordan du downloader ts-filen. Mange enheder har rigtignok problemer med TS, men det er nu uanset hvordan du får fat i filen.

#11: Det er nok her jeg ikke forstår hvad du mener. Hvordan downloader man med en af ts-filerne?
På samme måde som med m3u8 i browserens dev værktøj, blot med en af ts istedet. m3u8 er jo en playlist, med info om resten af filen, men ts fragmenterne indeholder også henvisninger til den samlede mediefil.

Jeg tror jeg nogenlunde kan replikere et eksempel, hvis ønsket, men fordi download kan tage timer, så ikke i fuld udstrækning. Desværre optog jeg ikke problemet med en sådan afbrudt forbindelse, da jeg oplevede det.

Imidlertid, hvis du forsøger med et link til henholdvis *.m3u8 og *.ts, så vil du se stor forskel i youtube-dl's output. Det har med nedenstående at gøre.

#11: Den ændrer ikke kompatibilitet uanset hvordan du downloader ts-filen. Man enheder har rigtignok problemer med TS, men det er nu uanset hvordan du får fat i filen.
Det er korrekt, men ffmpeg, som youtube-dl benytter, konvertere ikke ts mediefilerne on the fly. Det gør den med m3u8. Fordi ffmpeg ikke konvertere *.ts on the fly, og browsernes dev værktøj heller ikke gør, kan det være forklaringen på den lidt højere download hastighed, der muligvis medfører at serveren ikke timeout'er.

Før eksempelvis et TV's medieklient kan vise *.ts filen, så skal den konverteres. Dit bash i #9 er glimrende.

#12: På samme måde som med m3u8 i browserens dev værktøj, blot med en af ts istedet.

Altså at bruge ts-filen sammen med youtube-dl i stedet for m3u8-filen?

#12: ts fragmenterne indeholder også henvisninger til den samlede mediefil.

De indeholder ikke direkte nogle henvisninger da det er rå videodata. Men youtube-dl kan sikkert snildt gætte sig frem til de rigtige filer da de jo er nummereret sekventielt.

#12: Det er korrekt, men ffmpeg, som youtube-dl benytter, konvertere ikke ts mediefilerne on the fly. Det gør den med m3u8. Fordi ffmpeg ikke konvertere *.ts on the fly, og browsernes dev værktøj heller ikke gør, kan det være forklaringen på den lidt højere download hastighed, der muligvis medfører at serveren ikke timeout'er.

Ja det lyder sandsynligt. Hvis jeg tvinger ffmpeg til at lade output være mp4 i stedet for ts, går det meget langsommere. Så der er rimelig meget overhead når der konvereres on the fly

#12: Før eksempelvis et TV's medieklient kan vise *.ts filen, så skal den konverteres.

Nogle er bedre end andre. Min gamle WD TV Live boks klarer TS filer glimrende, selv med undertekster. Til gengæld er det mega langsomt at spole ind i videoen fordi TS ikke indeholder tidskoder, så jeg konverterer som regel til mp4 alligevel.

Det er også de manglede tidskoder der gør at VLC ikke kan vise TS med undertekster med mindre man bruger parametren --demux ffmpeg

#12: Før eksempelvis et TV's medieklient kan vise *.ts filen, så skal den konverteres.

Nogle er bedre end andre. Min gamle WD TV Live boks klarer TS filer glimrende, selv med undertekster. Til gengæld er det mega langsomt at spole ind i videoen fordi TS ikke indeholder tidskoder, så jeg konverterer som regel til mp4 alligevel.

Det er også de manglede tidskoder der gør at VLC ikke kan vise TS med undertekster med mindre man bruger parametren --demux ffmpeg

#13: De indeholder ikke direkte nogle henvisninger da det er rå videodata. Men youtube-dl kan sikkert snildt gætte sig frem til de rigtige filer da de jo er nummereret sekventielt.
Jeg er svar skyldig, for jeg ved ganske enkelt ikke nok. Kun at jeg pr observation oplever at det fungere i de relative få forsøg jeg har erfaret.

Noget andet er logikken i on fly conversions og download hastigheder.

Det er, som du nævner, ikke muligt at vide hvad der er kompatibelt med et eller andet device. Kun bedst praksis. Den er PT x.264 mp4/mkv e.g, men vil formentlig være x.265 (HEVC) i fremtiden.

Eksterne subtitles filer i andet end USB tilslutninger på et TV, fx medieservere, kan være helt umulige, med mindre underteksterne er hardcoded. Det slipper man udenom med HDMI, eller TV's USB, men det er noget helt andet. Et nyere TV's USB har formentligt ingen problemer med eksterne undertekst filer.

Hvis TV er HDMI forbundet med en computer, så kan VLC udmærket vise eksterne undertekster (fx *.srt), såvel som *.ts (ts muligvis med renderingsbesvær - blandt andet, men ikke kun, fordi ts ikke indeholder tidskoder). Det har ikke noget med mediefilen at gøre. Undertekst filen forstår heller ikke medie filens tidskoder. Hvis ikke de er tilpassede, så er de out of sync.

Alligevel, blot til information, så skal *.srt være formateret som UTF-8. Er den ikke det, så vil underteksten ikke virke efter hensigten (der vil ske udfald (viser ikke alle linjer i srt filen)).

Det har derfor ikke noget med TS video renderingen af gøre. Den viser sig ved at ts mediefilen vises forkert, indtil den er ordentligt indlæst. Der går typisk 5 - 10 sekunder, før videoen ser normal ud. Indtil da ligner den en animation. Mange devices kan ikke håndtere sådan noget.

Den bedste cross platform tekst editor jeg kender til korrekt subtitle formatereing, er Sublime Text. Sublime Text kan nemt gemme en SRT i UTF-8 formatet, og således sikre at underteksten virker. UTF-8 kan muligvis forvirre forståelsen om subtitles ...

Noget andet, der nok også er lidt off-topic, så vil en embeded undertekst (ikke hardcoded) i en *.mkv container, heller ikke fungere på visse TV, med mindre visningen er håndteret af fx VLC med en HDMI forbindelse, eller som du nævner, en WD TV Live boks, som jeg ikke ved et klap om.

#13: De indeholder ikke direkte nogle henvisninger da det er rå videodata. Men youtube-dl kan sikkert snildt gætte sig frem til de rigtige filer da de jo er nummereret sekventielt.
Jeg tror ikke det er youtube-dl der samler segmenterne til en fil, men ffmpeg der gør det. Youtube-dl benytter ffmpeg som en del af funktionen.

#!/bin/bash
# This script need to be copied to the directory containing the segments as it is
# Then run the script

# The movie segmentes need to be listed within a text file as:
# to use ffmpeg for merging the segments to one movie file

# Example of an segment file: "00000001.segment" as a part of the fragmented movie file
# Such segments may be named as something completely different

# Make the list:
ls > list.txt

# Insert single quotes sign before and after the segment names in all the lines (This may not be needed):
sed -i~ -e "s/^/'/;s/$/'/" list.txt

# Insert the word "file" (followed by a "space") as the first word in every line:
sed -i -e 's_.*_file &_' list.txt

# Merge all segments into one movie using ffmpeg:
ffmpeg -safe 0 -f concat -i list.txt -vcodec copy -acodec copy merged-movie.mp4

$SHELL

Der er visse streaming sites (HLS - Http Live Streaming), der ikke virker hvis man aktivere dev-tools i browseren. Et sådant site kan være NETU. Downloads ser derfor umulige ud. Imidlertid findes der en metode, så det alligevel er muligt, men PT kun med Windows 10.

Kort sagt fungere det sådan, at man skal installere et program i Windows OS og en udvidelse i Chrome (i Developer Mode). Navnet på programmet er ikke nævnt her. Programmet indeholder filerne fra Chrome's dev-tools, således at sites som fx NETU, ikke deaktivere downloads. Segmenterne downloades til programmets alternative cache, istedet for Chrome's cache.

Et sådan program er PT ikke tilgængeligt med Linux, og så vidt jeg ved, heller ikke med Wine e.g..

Hvis man således har downloadet segmenterne, fungere det ovenstående bash i Linux (macOS m.f.). Imidlertid er det ikke nødvendigt hvis man har Windows 10 installeret (fx virtuelt), fordi programmet selv samler segmenterne med ffmpeg.

Imidlertid er der stadig samme server timeout problem som beskrevet i #10, hvis download hastigheden er for langsom.

OBS: For at forhindre at serveren timeout'er, kan løsningen være at lade videoen køre i browseren, mens man downloader segmenterne.

#16: Der er visse streaming sites (HLS - Http Live Streaming), der ikke virker hvis man aktivere dev-tools i browseren. Et sådant site kan være NETU. Downloads ser derfor umulige ud. Imidlertid findes der en metode, så det alligevel er muligt, men PT kun med Windows 10.

Har du et eksempel på et site der ikke virker med dev-tools aktiveret?

Og hvad er NETU? En googling gør mig ikke klogere.

Dobbeltpost

#17: Har du et eksempel på et site der ikke virker med dev-tools aktiveret?
NETU.tv er kun et af flere. Et andet er waaw.tv;

https://waaw.tv/watch_video.php?v=cGVtT3ZrL0NDbHhLNVZkVHBqYUFWNWZDNjdrO…

Bemærk hvordan sitet pauser debuggeren, og derefter skriver: Dont open Developer Tools

Jeg skal huske at nævne, at det ikke er muligt direkte at henvise til videoer der benytter NETU.tv's services. Det skal ske gennem tredjepart sites, der benytter NETU's streamings service.

Hvis man forsøger, får man meddelsen: We can't give you what you want ... Jeg vil også lige nævne, at det flyder med potentielle malware links på flere af sådanne tredjepart sites. Derfor skal man have paraderne oppe, og er mest grunden til jeg er forsigtig med at indsætte links til dem.

Imidlertid kan jeg henvise til et sådant tredjepart site, men ovenstående link burde være nok, og det ser sikkert nok ud. Alligevel er waaw.tv accessoriseret med kinesere (https://www.56.com/), og det er ikke kun Corona virus de spreder ...

#19: Bemærk hvordan sitet pauser debuggeren, og derefter skriver: Dont open Developer Tools

Jeg må indrømme at de har gjort livet besværligt for brugere af udviklerkonsollen, men helt umuligt er det nu heller ikke. Med lidt cowboytricks i konsollen lykkedes det mig på et kvarters tid at grave m3u8-url'en frem. Men linket er kortlivet og dur sikkert ikke når dette læses.

Fremgangsmåden er at man åbner terminalen og følger call-stacken når man får debugger-kommandoen der pauser konsollen. Så skal man slå local overrides til som tillader at lave permanente ændringer af JS-filer. De to steder hvor debugger kaldes skal man så lave en tidlig return fra funktionen. Så skal der søges i requests (Ctrl-F) efter "Dont open" hvorefter der laves samme trick (tidlig return). Der gemmes. Derefter genindlæses siden. Pga. local overrides er det den redigerede version der loades og ikke den originale. Nu skal man ikke forledes til at tro at m3u8-filer nødvendigvis hedder noget med m3u8. Så der skrives mime-type: i netværksfilteret hvorefter der vises en oversigt over loadede mime-types. Så vælger man den der hedder noget med mpeg. Herefter vises kun request af denne mime-type. Så vil man finde m3u8-url'en.

Måske er det nemmere bare at fyre op under wireshark?

#20: Måske er det nemmere bare at fyre op under wireshark?
Tak for din tid, og måske er det nemmere med Wireshark, bare for sportens skyld.

Du kan kikke på Ant-Downloader, der PT kun virker i fuld udstrækning med Windows. Jeg har testet den på en VM og den virker.

https://www.ant.com/video-downloader/ff-installed

Men der er også et problem, som jeg endnu ikke ved om sker på en hardware installation. Det er at downloaderen disrupter Network Manager på Linux hosten, og ikke kun det, men nogle gange afbryder interforbindelsen på alle LAN maskinerne. Det sker på et tidspunkt, der variere fra hvert forsøg.

Heldigvis er det nemt nok at få internettet til at virke igen, ved at afslutte VM og genstarte Network Manager, men det fortæller også lidt om hvor lidt der skal til for at lægge et LAN ned.

Jeg synes lige jeg vil nævne det, hvis du prøver på en VM, og oplever det samme.

Edit:
Nu har jeg forsøgt med en HW installeret Windows, og det gik glat igennem. Derfor tror jeg problemet med en VM skyldes emuleringen. Derfor er mission lidt accomplished.

Linux har ikke noget tilsvarende som Ant.com Video Downloader, idet mindste som jeg kender til. Måske er det projekt for en programmør?

Flyttet til: https://www.linuxin.dk/node/22796