26

Sv: SVTPlay.sh

På sikt kommer SVTPlay.sh att ersättas av något annat. Även om jag nämnt detta i privata epostväxlingar tidigare så är det egentligen först nu jag bestämt mig. Det finns flera skäl till varför detta är en bra idé, men i slutändan handlar samtliga egentligen om komplexitet. Sett på litet längre sikt är den nuvarande Bourneskript-modellen inte särskilt rolig.

Detta skriver jag för att få input från er som använder skriptet innan jag på allvar sätter i gång med en omarbetning. Därför ska jag försöka att kortfattat förklara hur jag tänker.

Nya funktioner och ökande komplexitet
I framtiden finns två sätt som skriptet ska utvecklas på. Det första är att lägga till stöd för direkt uppspelning med undertexter. När den funktionen är på plats, så betraktar jag funktionaliteten gentemot SVT Play som komplett. Det andra är att lägga till samma stöd för fler sajter. Den sajt som står överst på listan, åtminstone just nu, är TV4 Play.

Utöver dessa två förbättringar måste skriptet även lära sig hämta Apple HLS-strömmar, och på sikt förmodligen även Adobe HDS. Både SVT och TV4 verkar vara på väg att ersätta eller komplettera sina nuvarande RTMP-strömmar med HDS. SVT verkar vara dem som kommit längst i den processen. Jag vet inte heller om de helt kommer fasa ut RTMP eller ej. Till skillnad från TV4 erbjuder SVT sina program även som HLS-strömmar. Dessa går redan nu att hämta med FFmpeg, så som jag beskrev i ett tidigare inlägg.

Utökningen till att kunna skrapa videor från fler sajter medför inte någon riktigt besvärlig komplicering av skriptet, eftersom den proceduren är någorlunda enkel att modularisera. Däremot ökar det mängden fula nödlösningar. SVT Play använder ju JSON, vilket är jättebra. SVTPlay.sh använder dock grep, sed och tr för att läsa JSON, och det är inte riktigt lika bra. Saken är den att TV4 i stället använder XML. Att skrapa de här XML-dokumenten från skalskript, med samma allmängiltiga verktyg som redan används, är fullt möjligt, men det känns inte riktigt bra att lägga till ytterligare en ful nödlösning. Jag skulle vilja använda något som faktiskt kan tolka JSON och XML i stället.

Värre är det med de andra två förändringarna. Slutklämmen på skriptet gör i dagsläget följande:

  1. Direkt uppspelning.

  2. Nedladdning till fil.

  3. Nedladdning till fil med samtidig uppspelning. (Typ rtmpdump -r adress | tee -f film.flv | mplayer -- -.)

  4. Cygwin kräver i flera fall specialbehandling.

Men det är inte riktigt allt. Det är inte bara RTMP-strömmar som ska kunna hämtas, utan även videor som hämtas över vanlig HTTP. I princip (om än inte i praktiken) innebär det en fördubbling av antalet möjliga slutklämmar.

När stöd för uppspelning med eller utan undertexter tillkommer så ökar komplexiteten ytterligare -- i princip (om än inte helt i praktiken) medför det att ytterligare en uppsättning av metoderna 1--4 måste till.

Lägg sedan till att stöd för HLS-strömmar kommer kräva ytterligare en uppsättning så börjar det bli obekvämt. Hur HDS-strömmar ska hanteras vet jag dessutom inte än, men det kommer sannolikt innebära att ytterligare ett (kompilerat) beroende utöver FFmpeg dras in i skriptet. Har vi otur så blir hämtning av HDS nödvändigt innan någon mindre otymplig lösning än KSV:s PHP-skript finns tillgänglig, och då kan jag mycket väl bli tvungen att skriva den själv (vilket ärligt talat är en bra bit över min förmåga).

Plattformsoberoendet
En andra aspekt av saken är i vilka miljöer skriptet används. Jag har ingen direkt koll på antalet installationer, användare eller vilka typer av unix-möbleringar det har att förhålla sig till, men kan gissa utifrån vad jag vet.

De senare versioner av skriptet som inte automatiskt kollar efter uppdateringar, gör sina manuella uppdateringskollar till en annan adress än tidigare versioner. Bineros installation av awstats visar på manuella kontroller från ungefär 20 unika ip-adresser per vecka på den adressen. (De tidigare versioner som genomför automatiska kontroller interagerar direkt med GitHub, och där har jag ingen statistik.)

Skriptet har alltså en tuff liten användarskara. Men det har även en tuff liten uppgift. Jag känner till att det används i Linux, BSD, Indiana/Solaris, Cygwin och Miraclebox-plugin. OSX/Darwin finns inte på listan över kända installationer, men det är inte omöjligt. (Varför ser Darwins logga ut som Kalle Anka med bäversvans? Jo, jag vet att det ska föreställa ett näbbdjur...)

Behövs skriptet?
Den tredje aspekten, vid sidan av komplexiteten och kompatibiliteten, är att skriptet inte ska vara överflödigt. Python-koden bakom PiratePlay är GPL3-licensierad och fritt tillgänglig. Att ersätta SVTPlay.sh med en wrapper kring PP-koden skulle innebära att installation av skriptet blev rätt krångligare, särskilt i udda unix-möbleringar. Förmodligen skulle plattformsoberoendet även minska, eftersom jag inte kan något om (programmet) Python.

Att PP är GPL3 spelar förstås också in, om än inte till samma grad som de övriga aspekterna. Om det är möjligt så är jag dock ute efter att kunna återanvända koden i SVTPlay.sh-ersättaren i program som inte kommer bli GPL-licensierade (inte minst för att GPL är i stort sett obegriplig för mig).

Slutligen är det ett absolut krav att det program som ersätter SVTPlay.sh har samma funktionalitet. Om man ersätter det nuvarande skriptet med det framtida så ska allt fortsätta fungera likadant, frånsett att det får lov att gå snabbare.

Möjliga vägar framåt
Med allt det ovanstående i åtanke är det någorlunda lätt att direkt utesluta flera språk (bl.a. C++, Caml, Lisp, Java, Ruby, Malbolge, Python) och välja ut några tänkbara kandidater. Finalisterna har blivit C, perl och scheme.

C fungerar i stort sett överallt, är relativt lätt att integrera med libs och diverse annan kod, men är tidsödande att jobba i. Dessutom är det litet för lätt att råka skjuta bort sina fötter med C, vilket gör att det inte riktigt passar min niv...*host*...stil.

Perl är också i stort sett universellt, och jag var inne på att göra skriptet i perl ett tag. Av de olika alternativen är det förmodligen perl som skulle komma närmast vad SVTPlay.sh är i dag. Möjliga frågetecken är hur CPAN-moduler egentligen fungerar på icke-datorer som Miraclebox, hur det fungerar i Cygwin eller MSYS och så vidare. Dessutom skulle valet stå mellan att fortsätta vara beroende av externa program för hämtning av videor eller att översätta programkod från kompilerade språk till perl.

Det stora bekymret är dock att jag skulle behöva lära mig perl. wink

Scheme är å andra sidan mitt favoritspråk (vilket är en fara i den här beslutsprocessen). Chicken Scheme har rätt bra plattformsoberoende och en fördel i att scheme-koden översätts till C-kod, som sedan kan kompileras statiskt med åtminstone gcc, clang och mingw. Därmed är länkning till olika bibliotek (typ librtmp) och integrering med annan kod i praktiken lika lätt som i C. Dessutom går det att köra scheme-kod som skript också.

En tydlig nackdel med scheme är att det ser nästan lika märkligt ut som Python, och har en rätt brant inlärningskurva i början.

Så, har någon tankar kring detta? Finns någon viktig aspekt jag missat? Är det något i resonemangen som inte hänger ihop som det borde?

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

27

Sv: SVTPlay.sh

Tack så mycket.
Extrahering du visade fungerade perfekt för HDS strömmar på min Solaris maskin.
Jag bor i Kalifornien så det enda sätt jag kan spela in SVT sändingar är
via svtplay. Tidigare var det enkelt med rtmpdump men jag vet att SVT gör
vad de kan för att stoppa möjligheter att ladda ner filer.

Adobe Flash player kommer inte längre att stödjas för Solaris eller andra
Unix varianter så det enda sätt vi kan spara programmen är via separata
nedladdningsprogram med curl/ffmpeg.

Jag fick kompilera upp en ny version av ffmpeg eftersom min gamla version
(från 2009) inte stödde bitstream filter 'aac_adtstoasc' men det gick bra
med den nyaste versionen (ffmpeg-0.11.1.tar.gz)

En sak jag noterade är att för nyare ffmpeg versioner spelar ordning av
argumenten viktigare roll. codec argumenten måsta komma efter "-i url" argumented
annars får man error message "unknown decoder copy". Det tog mig lite tid att inse det.
Följande ffmpeg invocation fungerar bra:

ffmpeg -i http://svtplay6n-f.akamaihd.....m3u8 -absf aac_adtstoasc -acodec copy -vcodec copy video.mp4

Jag noterade också att nedladdingen via ffmpeg går mycket snabbare än ekvivalenta filer för
rtmpdump. Undrar om det beror på stream formatet från seversidan eller på att ffmpeg
applikationen är effektivare än rtmpdump.

Jag har använt mplayer och mencoder mycker men inte så mycket ffmpeg stand-alone.
Jag är glad att se att koden fortfarande kontinuerligt utvecklas for dessa applikationer och
att de är POSIX kompatibla och enkelt att kompilera för Unix desktops.


/KarlD

Dela

28 Senast ändrad av Jesper (2012-09-10 05:39:45)

Sv: SVTPlay.sh

KarlD skrev:

Tack så mycket.
Extrahering du visade fungerade perfekt för HDS strömmar på min Solaris maskin.

Bra! (Fast det är (Apple) HLS-strömmar du hämtar då, inte (Adobe) HDS. smile)

KarlD skrev:

Jag bor i Kalifornien så det enda sätt jag kan spela in SVT sändingar är
via svtplay. Tidigare var det enkelt med rtmpdump men jag vet att SVT gör
vad de kan för att stoppa möjligheter att ladda ner filer.

Ska jag vara ärlig tror jag att det snarare är tvärtom: De gör vad de kan för att videorna ska vara så tillgängliga som möjligt. Hindren ligger i stället i att rättighetsinnehavarna ställer krav på att distributionen ska begränsas på olika sätt. (Så har jag i alla fall fått intrycket av att det är, men jag har egentligen inga direkta belägg för det...)

KarlD skrev:

Jag fick kompilera upp en ny version av ffmpeg eftersom min gamla version
(från 2009) inte stödde bitstream filter 'aac_adtstoasc' men det gick bra
med den nyaste versionen (ffmpeg-0.11.1.tar.gz)

En sak jag noterade är att för nyare ffmpeg versioner spelar ordning av
argumenten viktigare roll. codec argumenten måsta komma efter "-i url" argumented
annars får man error message "unknown decoder copy". Det tog mig lite tid att inse det.
Följande ffmpeg invocation fungerar bra:

ffmpeg -i http://svtplay6n-f.akamaihd.....m3u8 -absf aac_adtstoasc -acodec copy -vcodec copy video.mp4

Bra att veta, inte minst för att SVTPlay.sh ska varna om man kör för gamla versioner av rtmpdump/ffmpeg osv.

KarlD skrev:

Jag noterade också att nedladdingen via ffmpeg går mycket snabbare än ekvivalenta filer för
rtmpdump. Undrar om det beror på stream formatet från seversidan eller på att ffmpeg
applikationen är effektivare än rtmpdump.

Både och, kan man säga. HLS (och HDS, som vi inte kan hämta ännu) levereras över HTTP av en vanlig webbserver.

De gamla RTMP-strömmarna skickas däremot ut av en särskild mediaserver. Eftersom RTMP är ett specialprotokoll enbart avsett för strömning så matar det bara i väg data om klienten säger att den har cache-utrymme över. Om jag minns rätt så ser RTMPDump till att alltid säga att den har 10 sekunder större cache än längden på hela strömmen. (RTMP-strömmar mäts i millisekunder i stället för byte, på protokollnivå.)

Därför är det ett större steg till att införa hastighetsbegränsning på HLS-strömmar än det är för RTMP. Vissa RTMP-servrar begränsar hastigheten till strax över mediafilens bitrate, till exempel UR.se (åtminstone på radioprogrammen).

TV4:s RTMP-server försöker också vara "smart" på det här sättet, men har en irriterande vana att välja fel och ge alldeles för låg bandbredd till strömmen.

Återkom gärna om du har frågor eller tips.

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

29

Sv: SVTPlay.sh

Jesper skrev:

På sikt kommer SVTPlay.sh att ersättas av något annat. Även om jag nämnt detta i privata epostväxlingar tidigare så är det egentligen först nu jag bestämt mig. Det finns flera skäl till varför detta är en bra idé, men i slutändan handlar samtliga egentligen om komplexitet. Sett på litet längre sikt är den nuvarande Bourneskript-modellen inte särskilt rolig.

Mycket tacksam för ditt fortsatta arbete med SVTPlay. Några kommentarer följer nedan:

Jesper skrev:

Möjliga vägar framåt
Med allt det ovanstående i åtanke är det någorlunda lätt att direkt utesluta flera språk (bl.a. C++, Caml, Lisp, Java, Ruby, Malbolge, Python) och välja ut några tänkbara kandidater. Finalisterna har blivit C, perl och scheme.

C fungerar i stort sett överallt, är relativt lätt att integrera med libs och diverse annan kod, men är tidsödande att jobba i. Dessutom är det litet för lätt att råka skjuta bort sina fötter med C, vilket gör att det inte riktigt passar min niv...*host*...stil.

Jag skulle rekommendera utvecklingen av SVTPlay i standard C. Om man vill använda
gcc så stöds det för de flesta platformer jag känner till.
Text-hanteringar och diverse filtreringar är mycket smidigare i C och det blir färre beroende av externa program som grep, sed, awk, sh, tr, för vilka det ibland uppstår problem med inkompatibiliteter mellan gnu versioner och POSIX och Unix versioner.

Jag har utvecklat en del program skrivna i C som jag har portat för Linux, Android,
Solaris, Mac (och även Microsoft Windows under MSYS) och det går relativt bra. Beroenden av speciella libs och versioner kan komplicera underhållet. För SVTPlay
förmodar jag att det är främst curl, rtmpdump och ffmpeg som kommer att behövas.

I en Makefile kan man låta användaren specificera referenser till alla libs eller
program som krävs med macros tex:

RTMPDUMP="/opt/inst/local/rtmpdump-2.4/bin/rtmpdump"
RTMPDUMP_LIB="/opt/inst/local/rtmpdump-2.4/lib"

Det är också bra att göra koden flexibel så att den går att kompilera även
om man inte hara alla beroenden. Till exempel om man bara skall ladda ner
HLS-strömmar behövar man ju inte rtmpdump och därför borde man inte
behöva specificera dess referens för att få den funktionaliteten.

Jesper skrev:

Scheme är å andra sidan mitt favoritspråk (vilket är en fara i den här beslutsprocessen). Chicken Scheme har rätt bra plattformsoberoende och en fördel i att scheme-koden översätts till C-kod, som sedan kan kompileras statiskt med åtminstone gcc, clang och mingw. Därmed är länkning till olika bibliotek (typ librtmp) och integrering med annan kod i praktiken lika lätt som i C. Dessutom går det att köra scheme-kod som skript också.

Scheme är ett relativt okänt språk. För mig personligen var det längesedan jag skrev
något i ett funktionellt språk. (Chalmers hade för längesedan ML som första språk
på D-linjen). Jag vet at det går att skriva en del kul applikationer i dessa språk, men
det kan vara ganska svårt att analysera vad koden gör. Det har förmodligen hänt
mycket med Scheme under senare tid men länkning till externa libs och effektivitet
och portabilitet känns ändå osäkrare än att använda välbeprövade lösningar som C.

/KarlD

Dela

30

Sv: SVTPlay.sh

Tack för ett utförligt svar! Du har flera viktiga poänger jag måste ta med i bedömningen. Jag återkommer till frågan när jag har hunnit göra mer research och förhoppningsvis även fått in fler synpunkter. Hoppas fler svarar!

(Länka till C-libs, t.ex. librtmp, är rätt lätt i scheme-varianten jag använder: http://wiki.call-cc.org/man/4/Getting%2 … libraries-)

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

31

Sv: SVTPlay.sh

Hej !

Tack Jesper, för det PM du skickade till mig på www.miracleboxforum.net.
Jag använder en annan signatur där: Ants war .

Jag har skrivit plugin SVTPlay_download , för Miraclebox.
Där inkluderas  SVTPlay.sh som en nyckel komponent.

Jag ber att framföra ett stort tack, för det idoga arbete och mycket väl fungerande kod du skriver.

Som du beskriver, förändringar är på gång med HDS, HLS och du ser "vägs ände "med nuvarande bourne shell script.

Jag tror att en framkomlig väg är att använda Chicken Scheme.

En Miraclebox, för de som Ej vet är en Linux baserad digitalbox för TV tittande , med inspelningsfunktion.

OS: ST Linux
Processor familj: sh4
Ram minne: Varierar på olika modeller , men på min Miraclebox 9  är ca 96 MB visas med top.
Huvud applikationen som håller igång TV + inspelning, tar den största delen av minnet i anspråk.
Lagring: /var är ett jffs2 filsystem  ( komprimerande )
Utrymmer på de enklaste boxarna 4MB
På Miraclebox 9 , 30 MB.

De flesta har anslutit lagrings disk för inspelning. Det går även att lagra "plugin" där om /var utrymmet ej räcker.
Det blir lite "bök", men går.

/, /etc, /usr, /lib är Ej skrivbara.

-
Vad jag med denna beskrivning vill visa , är att om man går från ett skript som är på 24445 bytes till en
program miljö med  binärer och "shared libs" på för många MB så fungerar det  ej bra på denna typ av miljö.

-
Jag har kors-kompilerat  "Chicken scheme" , för linux-sh4 . Givetvis med flaggan -Os.
Testat på Miraclebox 9, och det verkar fungera.

Har även gcc/g++ på min Miraclebox 9, men det har EJ något som är standard , och skall nog så förbli.

Exempel:
Mitt första scheme program .
hello.scm
-
(display "Hello, world!\n")
-
# csi -s hello.scm
Hello, world!

--
Även att kompilera fungerade, för att jag har gcc på min Miraclebox 9. ( Ej std)
# csc -I/STORAGE/HDD/opt/target/usr/include hello.scm
----

Så om "native" GNU C  är för krångligt, så tror jag att Chicken scheme är en hanterlig väg.

Ha det bra !

Dela

32

Sv: SVTPlay.sh

Tack för ett utförligt svar! Fantastiskt av dig att ta dig tid och prova att kompilera.

Ännu är jag som sagt inte framme vid något beslut, ska jag kanske poängtera, men jag drabbades av ett par tankar när jag läste ditt inlägg, som jag gärna vill bolla tillbaka.

sitnok skrev:

OS: ST Linux
Processor familj: sh4
Ram minne: Varierar på olika modeller , men på min Miraclebox 9  är ca 96 MB visas med top.
Huvud applikationen som håller igång TV + inspelning, tar den största delen av minnet i anspråk.
Lagring: /var är ett jffs2 filsystem  ( komprimerande )
Utrymmer på de enklaste boxarna 4MB
På Miraclebox 9 , 30 MB.

De flesta har anslutit lagrings disk för inspelning. Det går även att lagra "plugin" där om /var utrymmet ej räcker.
Det blir lite "bök", men går. (...) Vad jag med denna beskrivning vill visa , är att om man går från ett skript som är på 24445 bytes till en program miljö med  binärer och "shared libs" på för många MB så fungerar det  ej bra på denna typ av miljö.

Jag ser det.

Vad det handlar om är alltså (mest av allt) RAM och hårddiskutrymme? Detta talar starkt till C:s fördel, men jag tänker (om möjligt) undvika C in i det längsta -- inte minst eftersom den riktning SVTPlay.sh-uppföljaren i så fall skulle gå i är som ett parallellt projekt till H.VHS. De båda skulle därmed vara tillräckligt lika för att kännas som "samma sak en gång till" för mig, men ändå inte tillräckligt lika för att programkoden skulle kunna delas mellan projekten i någon särskild utsträckning. Det skulle med andra ord komma att kännas rätt tråkigt.

Men nog om min psykologi.

Nedan är en lista över olika varianter på mer eller mindre realistiska alternativ. Den är sorterad så att det alternativ som jag gissar tar minst hårddiskutrymme plus RAM-minne i anspråk kommer först. (Och då tänker jag allt-som-allt, inklusive externa program för hämtning.)

  1. Skalskript: SVTPlay.sh fortsätter underhållas som skalskript, utan att tillföras ny funktionalitet. (Tar mindre utrymme då ffmpeg inte tillkommer.)

  2. C/libs: Skriptet ersätts av ett C-program, som med hjälp av libs självt hanterar hämtning av strömmar.

  3. Scheme/libs: Skriptet ersätts av ett Scheme-program, som hanterar hämtning av strömmar internt (alternativ 2 + Chicken).

  4. Perl? Som blir beroende av externa program för hämtning?

  5. C/externa program: Skriptet ersätts av ett C-program som inte sköter hämtning självt, utan kör externa program som ffmpeg.

  6. Skalskript: SVTPlay.sh vidareutvecklas vidare som skalskript och tillförs ny funktionalitet. (Nya beroenden tillkommer, bl.a. ffmpeg.)

  7. Scheme/externa program: Skriptet ersätts av ett Scheme-program som inte sköter hämtning självt (alternativ 5 + Chicken).

De alternativ som tar mest tid i anspråk är C-varianterna (2 och 5), och då framför allt nummer 2. De som å andra sidan tar minst tid är de skriptade som beror på externa program, dvs 1, 4, 6 och 7.

Om vi avgränsar vad vi pratar om till mycket trånga system i stil med dem du hanterar, så tror jag bara de tre första alternativen är hållbara -- men det är en ren spekulation, för jag vet (ännu) inte särskilt mycket om vare sig plattformen eller vilka möjligheter man har att minimera resursförbrukning.

Som förhållningspunkt för listan kan man använda scheme-lösningen med intern hämtare (alt. 3) som jag gissar skulle landa på mellan 5MB och 10 MB på disk, och i stort sett lika mycket i RAM vid körning. Om man väljer bort viss funktionalitet så minskar också storleken, men skillnaden mellan C och scheme är ändå tillräcklig för att ha betydelse.

Spontant tänker jag att det bästa kanske är att kombinera alternativ 1 med någon av de andra. Att inte utveckla utan bara underhålla det befintliga skalskriptet tar knappt någon tid alls. Det finns vissa ändringar jag kan göra för att öka livslängden en gnutta, som att backa till koden för gamla SVT Play och peka om skriptet mot 82.99.28.39, där SVT fortfarande publicerar program som RTMP-strömmar även när de bara finns som HDS/HLS på svtplay.se. (Men hur länge till?)

[Uppdatering: Hm, den där IP-adressen verkar redan vara på väg utför. Men kanske dyker den upp igen...]

Det kan till och med vara den enda vägen framåt för en del maskiner, eftersom FFmpeg riskerar att bli droppen för några av dem:
[output]kaja$ ffmpeg -version
ffmpeg version git-N-31885-g84ffe14, Copyright (c) 2000-2011 the FFmpeg developers
  built on Sep  5 2012 03:06:50 with gcc 4.2.1 20070719
  configuration: --enable-shared --arch=amd64 --cc=cc --disable-altivec --disable-armv5te --disable-armv6 --disable-armv6t2 --disable-armvfp --disable-debug --disable-indev=jack --disable-indev=oss --disable-iwmmxt --disable-neon --disable-outdev=oss --disable-outdev=sdl --enable-gpl --enable-libgsm --enable-libmp3lame --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-runtime-cpudetect --enable-x11grab --extra-cflags='-I/usr/local/include -I/usr/X11R6/include' --extra-libs='-L/usr/local/lib -L/usr/X11R6/lib' --mandir=/usr/local/man
  libavutil    50. 43. 0 / 50. 43. 0
  libavcodec   52.123. 0 / 52.123. 0
  libavformat  52.111. 0 / 52.111. 0
  libavdevice  52.  5. 0 / 52.  5. 0
  libavfilter   1. 80. 0 /  1. 80. 0
  libswscale    0. 14. 1 /  0. 14. 1
  libpostproc  51.  2. 0 / 51.  2. 0
ffmpeg git-N-31885-g84ffe14
libavutil    50. 43. 0 / 50. 43. 0
libavcodec   52.123. 0 / 52.123. 0
libavformat  52.111. 0 / 52.111. 0
libavdevice  52.  5. 0 / 52.  5. 0
libavfilter   1. 80. 0 /  1. 80. 0
libswscale    0. 14. 1 /  0. 14. 1
libpostproc  51.  2. 0 / 51.  2. 0
kaja$ ldd /usr/local/bin/ffmpeg
/usr/local/bin/ffmpeg:
        Start            End              Type Open Ref GrpRef Name
        000010384ec00000 000010384f01e000 exe  1    0   0      /usr/local/bin/ffmpeg
        0000103a50f59000 0000103a51361000 rlib 0    1   0      /usr/local/lib/libavdevice.so.5.0
        0000103a58773000 0000103a58bd3000 rlib 0    1   0      /usr/local/lib/libavfilter.so.3.0
        0000103a5ea6e000 0000103a5ef57000 rlib 0    3   0      /usr/local/lib/libavformat.so.15.0
        0000103a561b4000 0000103a56ff6000 rlib 0    4   0      /usr/local/lib/libavcodec.so.17.0
        0000103a5e405000 0000103a5e81e000 rlib 0    1   0      /usr/local/lib/libpostproc.so.14.0
        0000103a54be9000 0000103a55025000 rlib 0    2   0      /usr/local/lib/libswscale.so.4.0
        0000103a56ffb000 0000103a57416000 rlib 0    7   0      /usr/local/lib/libavutil.so.9.0
        0000103a4f072000 0000103a4f49a000 rlib 0    11   0      /usr/lib/libm.so.7.1
        0000103a52460000 0000103a52871000 rlib 0    8   0      /usr/lib/libpthread.so.17.0
        0000103a4f49a000 0000103a4f982000 rlib 0    1   0      /usr/lib/libc.so.66.0
        0000103a51bfa000 0000103a5212b000 rlib 0    3   0      /usr/X11R6/lib/libX11.so.15.1
        0000103a59b60000 0000103a59f71000 rlib 0    1   0      /usr/X11R6/lib/libXext.so.12.0
        0000103a55a57000 0000103a55e5c000 rlib 0    1   0      /usr/X11R6/lib/libXfixes.so.5.1
        0000103a5d8ed000 0000103a5dcfa000 rlib 0    1   0      /usr/lib/libsndio.so.4.0
        0000103a4f982000 0000103a4fd92000 rlib 0    1   0      /usr/local/lib/libbz2.so.10.4
        0000103a5c433000 0000103a5c83f000 rlib 0    1   0      /usr/local/lib/libgsm.so.1.0
        0000103a58bd3000 0000103a59047000 rlib 0    1   0      /usr/local/lib/libmp3lame.so.2.1
        0000103a51361000 0000103a51814000 rlib 0    1   0      /usr/local/lib/libschroedinger-1.0.so.3.0
        0000103a5370f000 0000103a53b27000 rlib 0    1   0      /usr/local/lib/libspeex.so.8.0
        0000103a52876000 0000103a52c8d000 rlib 0    1   0      /usr/local/lib/libtheoradec.so.1.1
        0000103a5dcfa000 0000103a5e134000 rlib 0    1   0      /usr/local/lib/libtheoraenc.so.1.2
        0000103a575e4000 0000103a57a0e000 rlib 0    1   0      /usr/local/lib/libvorbis.so.8.0
        0000103a59193000 0000103a59861000 rlib 0    1   0      /usr/local/lib/libvorbisenc.so.3.1
        0000103a5ef57000 0000103a5f3c9000 rlib 0    1   0      /usr/local/lib/libvpx.so.4.0
        0000103a5f3c9000 0000103a5f8df000 rlib 0    1   0      /usr/local/lib/libx264.so.9.0
        0000103a57a0e000 0000103a57eff000 rlib 0    1   0      /usr/local/lib/libxvidcore.so.4.3
        0000103a5055b000 0000103a50970000 rlib 0    1   0      /usr/lib/libz.so.4.1
        0000103a57eff000 0000103a5831b000 rlib 0    3   0      /usr/X11R6/lib/libxcb.so.2.3
        0000103a59f71000 0000103a5a3f3000 rlib 0    1   0      /usr/local/lib/liborc-0.4.so.4.0
        0000103a52c8d000 0000103a5319c000 rlib 0    1   0      /usr/lib/libstdc++.so.55.0
        0000103a53b27000 0000103a53f2d000 rlib 0    1   0      /usr/local/lib/libogg.so.6.2
        0000103a4fd92000 0000103a50194000 rlib 0    1   0      /usr/X11R6/lib/libpthread-stubs.so.1.0
        0000103a54056000 0000103a54459000 rlib 0    1   0      /usr/X11R6/lib/libXau.so.9.0
        0000103a55025000 0000103a5542a000 rlib 0    1   0      /usr/X11R6/lib/libXdmcp.so.10.0
        0000103a53300000 0000103a53300000 rtld 0    1   0      /usr/libexec/ld.so
kaja$ du -h /usr/local/lib/libavdevice.so.5.0 \
> /usr/local/lib/libavfilter.so.3.0 \     
> /usr/local/lib/libavformat.so.15.0 \
> /usr/local/lib/libavutil.so.9.0
40.0K   /usr/local/lib/libavdevice.so.5.0
432K    /usr/local/lib/libavfilter.so.3.0
1.0M    /usr/local/lib/libavformat.so.15.0
110K    /usr/local/lib/libavutil.so.9.0[/output]

(Om utmatningen ovan: Jag vet inte hur mycket av libav-biblioteken eller vilka andra libs som faktiskt krävs för att plocka ned HLS-strömmar. I utmaningen ovan tog jag inte med libavcodec.so, som är på hela 5,4MB, men jag tänker att man kanske slipper den...)

Den vägplan det handlar om får i sådana fall två parallella vägfiler, som ser ut ungefär så här:

  1. SVTPlay.sh får sina två sista funktioner i FFmpeg-hämtning av HLS-strömmar och samtidig uppspelning med undertexter (vilket iofs kanske inte påverkar Miraclebox). FFmpeg-stödet görs möjligt att välja bort på användarnivå, på bekostnad av att den som gör detta praktiskt taget strandsätts om/när SVT helt fasar ut RTMP. Skriptet får buggfixar i den mån någon upptäcker dem. Stöd för nya sajter tillkommer inte. (Detta är alternativ 1.)

  2. Det nya programmet utvecklas till en början så att det förlitar sig på externa program för hämtning. När programmet till slut har samma CLI-gränssnitt och funktionalitet som SVTPlay.sh så börjar arbetet med att ersätta beroenden av externa program med dynamiskt länkade bibliotek. Stöd för nya sajter tillkommer. (Detta är på sätt och vis samtliga C- eller Scheme-alternativ på samma gång.)

Med en sådan planering tänker jag att det kommer finnas en lösning som passar någorlunda väl in på varje nivå ifråga om tillgängligt disk- och minnesutrymme.

Att perl inte tagit plats i vare sig första eller andra "vägfilen" ovan beror på att det inte verkar ha några fördelar om planeringen delas upp så här. (Tänker man sig däremot att en enda lösning ska gälla för alla så är perl ett starkare kort, förutsatt att det finns förinstallerat även på de minimala systemen.)

Men nu tänker jag nästan högt för mig själv. Bäst att sluta. smile

sitnok, vad tror du om de här tankarna?

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

33 Senast ändrad av Jesper (2012-09-13 18:23:42)

Sv: SVTPlay.sh

Och som om det inte räckte med ovanstående jätteinlägg kommer ett till.

På GitHub finns en hastigt hopkrafsad prototyp för scheme-varianten. Jag behövde kolla att konceptet jag föreställt mig faktiskt var görbart (och ville ha en ursäkt att ge projektet ett namn smile).

Sparsmakat med instruktioner finns i README-filen.

Programmet skapar fungerande kommandorader för både FFmpeg och AdobeHDS.php, men AdobeHDS.php lyckas inte kombinera videosegmenten, åtminstone inte i nuvarande version.

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

34

Sv: SVTPlay.sh

Om någon ändå vill prova att ladda ned med AdobeHDS.php, som nämndes på föregående sida, så finner man adressen till manifestfilen genom att t ex aktivera web konsolen i Firefox  Ctrl Shift K och spela det aktuella programmet och filtrera efter manifest. Då kan man kopiera adressen till manifestfilen och sedan ladda ned programmet i bitar med  AdobeHDS.php.

Dela

35

Sv: SVTPlay.sh

klager: Får du kombineringen att fungera? I så fall hör jag gärna hur, så att jag kan automatisera det.

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

36

Sv: SVTPlay.sh

Kombinering?

Jag provade att ladda ned avsnitt 2 av landgång, den laddar ned 581 fragment, och slår ihop dem till en .flv fil. Fungerar mycket bra och går fort. Det finns en bra beskrivning hur man laddar ned från tv.nrk.no och det fungerar även för SVT.

http://ingvar.blog.redpill-linpro.com/2012/05/31/downloading-hd-content-from-tv-nrk-no/

Dela

37

Sv: SVTPlay.sh

Ja, sammanslagningen av segmenten har inte velat fungera när jag försökt. Men det var kanske bara tillfälligheter. Nytt försök!

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

38

Sv: SVTPlay.sh

Jag vet inte om SVT kan få för sig att kryptera de program som är regionbegräsnade, så att det ev kan bli problem med dem? Men Landgång fungerade bra.

Dela

39 Senast ändrad av Jesper (2012-09-17 20:01:07)

Sv: SVTPlay.sh

Ah, det kan vara där skon klämmer.

Skriptprototypen (https://github.com/simio/teve) är förresten så pass uppdaterad nu att den genererar hämtningskommandon för hls-, hds-, rtmp-, rtsp- och mms-strömmarna på SVT. Har av någon anledning inte hunnit till .flv över vanlig http än, vilket är var SVT:s "Klipp" brukar använda, men det händer väl snart.

Uppdatering: Att huruvida AdobeHDS.php:s hopslagning fungerar har med spridningsrestriktioner verkar stämma. Parallellt verkar det som ffmpeg landar i segfault när man försöker sig på en HLS-ström som bara får ses i Sverige. (För mig i alla fall, med FFmpeg från 20120610.)

Det betyder att vissa strömmar fortfarande inte går att hämta.

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

40

Sv: SVTPlay.sh

klager skrev:

Om någon ändå vill prova att ladda ned med AdobeHDS.php, som nämndes på föregående sida, så finner man adressen till manifestfilen genom att t ex aktivera web konsolen i Firefox  Ctrl Shift K och spela det aktuella programmet och filtrera efter manifest. Då kan man kopiera adressen till manifestfilen och sedan ladda ned programmet i bitar med  AdobeHDS.php.

Ja, det fungerade för mig med AdobeHDS.php för öppna program. Regionsbegränsade program kan jag inte komma åt
och testa eftersom jag sitter utanför Sverige. De brukade använda rtmpe protokoll för sådana program.

Dela

41

Sv: SVTPlay.sh

Känner inte till att någon lyckats hämta de regionbegränsade programmen ens från Sverige. AdobeHDS.php misslyckas irriterande nog först när samtliga segment laddats ned och ska kombineras. När man försöker hämta en regionbegränsad HLS-strömm med ffmpeg går det åt pipsvängen direkt i stället, i mitt fall med segfault.

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

42

Sv: SVTPlay.sh

Jag lade nyss till stöd för TV4 Play till prototypen. Det är fortfarande rätt experimentellt och lär gå sönder för vissa adresser. Stöd för live-strömmar ingår dock.

Däremot fungerar det inte med Premium än. Sådant stöd skulle kräva tillgång till cookies för en session inloggad på ett TV4 Play-konto med Premium aktiverat. Frågan är hur detta är lämpligast att lösa. Jag gillar inte riktigt tanken på att skriptet ska matas med inloggningsuppgifter för att på egen hand logga in, men just nu kan jag inte se att någon annan lösning blir särskild smidig på användarsidan, exempelvis att man får logga in i en webbläsare, så kollar skriptet i webbläsarens cookie jar efter en giltig session.

Några idéer?

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

43

Sv: SVTPlay.sh

Jesper skrev:

Nya funktioner och ökande komplexitet
I framtiden finns två sätt som skriptet ska utvecklas på. Det första är att lägga till stöd för direkt uppspelning med undertexter. När den funktionen är på plats, så betraktar jag funktionaliteten gentemot SVT Play som komplett. Det andra är att lägga till samma stöd för fler sajter. Den sajt som står överst på listan, åtminstone just nu, är TV4 Play.

Det finns olika sätt att minska komplexiteten. Ett vore att använda en befintlig "backend" (röv?)  som den i pírateplay.  En annan vore att definiera sig som en plugin in ett befintligt ramverk sin t ex http://code.google.com/p/get-flash-videos/

I det första fallet skulle man behöva patcha programmet ganska ordentligt, det är just nu skrivet med starka beroende till qt4 överallt. Men det verkar inte oöverkomligt, det är totalt drygt 1000 rader C++, helt hanterbart.

I det andra fallet sitter man fast i en struktur, på gott och ont. get-flash-videos är skrivet i perl, och har en föråldrad (ej HDS/HLS-kapabel) svtplay-plugin. Det har en fördel att det klarar många siter, med aktiv utveckling.


Ett tredje alernativ skulle då vara att göra allting själv: att så att säga koda både röv och huvud.  Men det borde ju vara den siste utvägen. Eller?

Jesper skrev:

Plattformsoberoendet
En andra aspekt av saken är i vilka miljöer skriptet används. Jag har ingen direkt koll på antalet installationer, användare eller vilka typer av unix-möbleringar det har att förhålla sig till, men kan gissa utifrån vad jag vet.

För att klara detta funkar ju trots allt perl hyggligt. Jag tor inte att en patched pirateplay, utan qt-beroenden skulle vara särskilt svår heller.  Nog klarar väl de flesta miljöer standard C++?!

Jesper skrev:

Att PP är GPL3 spelar förstås också in, om än inte till samma grad som de övriga aspekterna. Om det är möjligt så är jag dock ute efter att kunna återanvända koden i SVTPlay.sh-ersättaren i program som inte kommer bli GPL-licensierade (inte minst för att GPL är i stort sett obegriplig för mig).

Detta förstår jag bara inte. Vad är problemet med GPL?

Jesper skrev:

Scheme är å andra sidan mitt favoritspråk (vilket är en fara i den här beslutsprocessen). Chicken Scheme har rätt bra plattformsoberoende och en fördel i att scheme-koden översätts till C-kod, som sedan kan kompileras statiskt med åtminstone gcc, clang och mingw. Därmed är länkning till olika bibliotek (typ librtmp) och integrering med annan kod i praktiken lika lätt som i C. Dessutom går det att köra scheme-kod som skript också.

Att i en situation där det finns både ramverk som get-flash-videos och befintliga rövar som pirateplay inte bara koda om dessa helt från början, utan också göra detta i ett spåk som som är "udda". Ja, det är ju nästan en garanti för att man blir ensam på jobbet. Det är lite synd om så vore, öppen källkod handlar ju så mycket om att skapa lite kritisk massa.

Själv lutar jag åt att det bästa vore att patcha pirateplay så att det gick att köra från kommandoraden. Här har vi fördelen att själva kunna bestäma CLI-syntaxen, och inte minst att börja med något som faktiskt funkar.  Men att skriva en plugin till t ex get-flash-videos vore ju inte heller helt fel (om det inte redan hänt. så kommer ju den här HDS/HLS-problematiken att drabbe fler än svtplay där.. Fler som testar, kasnke fler som kodar...)

Förutsatt att man patchar pirateplay, så skulle ju en perl-plugin till get-flash-videos kunna använda detta... alla glada?

Dela

44

Sv: SVTPlay.sh

Svarar kort -- massor att göra. :-)

PiratePlay är skrivet i Python. PiratePlayer är däremot Qt/C++, men å andra sidan bara en frontend.

Både språket Python och hur/när deployment av Python-program fungerar vet jag inget om. Att lära mig det, och därigenom i allt väsentligt börja om på nytt, skulle ta så pass lång tid att det vore bättre om jag gjorde något helt annat i stället.

Nackdelen med Perl är att man låser in sig i beroenden av externa program. HLS- och HDS-strömmar kommer förmodligen breda ut sig, så det kommer inte räcka med rtmpdump.

Att helt börja om från början i C++ är ett alternativ, men inte just nu. Jag är mer intresserad av att göra en backend (och har egentligen redan kommit rätt långt) än en frontend. Inte minst för att jag numera är tillbaka i BSD och gör det mesta i xterm.

Problemen med GPL är flera. För H.VHS var (och är) problemet att QtWebKit kräver OpenSSL, som har en licens som är oförenlig med GPL. Det kan i och för sig lösas genom att man får installera OpenSSL för egen maskin, men på den nivån valde jag att inte lägga programmet.

Ett andra och egentligen större problem är att GPL är jättelång och obegriplig. Jag förstår inte vad den betyder. Andra gör kanske det, men inte jag.

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela

45

Sv: SVTPlay.sh

teve, programmet som ersätter SVTPlay.sh, har kommit så pass långt att det fått en egen tråd.

"It is a damn poor mind indeed which can't think of at least two ways to spell any word."

Webbplats

Dela