(Hinweis: Ich habe das Thema nicht in "PC Hard- & Software" rein, weil
es sich bei juv-rtmp... nicht um ein eigenständiges Programm, sondern
eine Bibliothek handelt, die man in eigenen java-Programmen nutzen
kann.)
Ich habe obige Bibliothek ausprobiert, um Videos von BR-Alpha
runterzuladen. Beim Vergleich mit linux-tool "rtmpdump", stellte ich
fest, dass beide funktionieren, aber juv-rtmp...jar viel langsamer ist.
Die Sourcen sind nicht frei, die Klassen sind sehr unaussagekräftig: 1 | com/smaxe/app/uv/downloader/support/q/b.class
| 2 | com/smaxe/app/uv/downloader/support/q/a.class
| 3 | com/smaxe/app/uv/downloader/support/q/f.class
| 4 | com/smaxe/app/uv/downloader/support/q/e.class
| 5 | com/smaxe/app/uv/downloader/support/q/d.class
| 6 | com/smaxe/app/uv/downloader/support/q/j.class
| 7 | com/smaxe/app/uv/downloader/support/q/c.class
|
Weiss jemand, warum juv-rtmp...jar die schnelle Internetverbindung so
ausbremst?
> Probiere es mal mit "flv movies downloader 1.43" als Firefox Plugin.
Bei BR-α (BR-Alpha) sind die Clips aber als MP4 abgespeichert.
Ausserdem brauche ich ein eigenständiges Programm.
> Probiere es mal mit einem Java Decompiler.
Wenn ich mir die Klassen-Namen anschaue, vermute ich stark, dass der
Source auch stark "obfuscated" ist, d.h. unlesbar gemacht.
(Bei den anderen smaxe-Programmen muss sogar ein Lizenz-Key gekauft
werden.)
Ich kenne leider das RTMP-Protokoll nicht und will aus Zeitgründen mich
nicht einarbeiten (Beim RTSP genauso).
Aber ich frage mich schon, ob man zum Download so einen grossen Aufwand
machen muss.
Jürgen G. schrieb:
> aber juv-rtmp...jar viel langsamer ist
Was bedeutet "viel"...?
Jürgen G. schrieb:
> Weiss jemand, warum juv-rtmp...jar die schnelle
> Internetverbindung so ausbremst?
Welche Lizenz hast du den? Evaluation? Dann schreib doch einfach mal an
den Support...
Jürgen G. schrieb:
> ein eigenständiges Programm
Es gibt doch genügend Streamdownloader, welche BS überhaupt? Was soll
die Quelle sein?
>> aber juv-rtmp...jar viel langsamer ist
>
>Was bedeutet "viel"...?
Bei einer langsamen (GPS) Verbindung sind beide ähnlich.
Bei schneller Verbindung lädt juv-rtmp...jar so lange, wie es dauern
würde, den Film anzuschauen. rtmpdump nutzt bei schneller Verbindung die
Bandbreite voll aus.
>> ein eigenständiges Programm
>
>Es gibt doch genügend Streamdownloader, welche BS überhaupt? Was soll
>die Quelle sein?
Es sollte innerhalb eines Servlet in Tomcat oder Jboss eingebunden
werden können. Aber vielleicht ist das zu hoch gegriffen.
>Welche Lizenz hast du den? Evaluation? Dann schreib doch einfach mal an
>den Support...
juv-rtmp-downloader-1.5.8.jar benötigt keine Lizenz.
(juv-rtmp-client-1.5 allerdings schon, aber das habe ich noch nicht
ausprobiert mangels Lizenz)
Ah okay, ich hatte nur den Client gefunden (da gibt es eine EvalLizenz),
zeig doch mal deinen Code (für die Freeware gibt es übrigens auch einen
Supportkontakt).
Ansonsten könnte ich mir auch gut vorstellen, das in der Freeware ggf.
der Speed gedrosselt wird.
Jürgen G. schrieb:
> Es sollte innerhalb eines Servlet in Tomcat oder Jboss eingebunden
> werden können. Aber vielleicht ist das zu hoch gegriffen.
Also von der Funktionsweise her sollte das schon klappen, wenn du mit
rtmpdump zufrieden bist könntest du aber auch einfach das aufrufen, viel
mehr Funtion bietet die Lib ja auch nicht.
Eventuell kannst du aber auch über die Buffersize noch was rausholen.
>lädt juv-rtmp...jar so lange, wie es dauern
>würde, den Film anzuschauen.
klingt aber, als wäre das absicht..
vielleicht eine Art "Gentlemen’s Agreement", "fair use" usw.
ist ja auch nicht sinn der sache, sich die Streams herunterzuladen,
sonst wären es ja keine Streams
Nachtrag:
source kann man sich ja anschauen:
http://www.smaxe.com/source.jsf?id=com/smaxe/app/uv/downloader/RtmpDownloader.java
nur basiert das ja auf eine library die NICHT frei ist ???
und auf eher auf abspielen von streams ausgelegt (der downloader ist
wohl nur ein Abfallprodukt für Werbezwecke?!)
>nur basiert das ja auf eine library die NICHT frei ist ???
>und auf eher auf abspielen von streams ausgelegt (der downloader ist
>wohl nur ein Abfallprodukt für Werbezwecke?!)
Genau.
>wenn du mit
>rtmpdump zufrieden bist könntest du aber auch einfach das aufrufen, viel
>mehr Funtion bietet die Lib ja auch nicht.
Allerdings sollte das auf einen gemieteten Server (mivitec) laufen.
(Third-party jar's in eigene war's einzubinden geht an sich schon)
> zeig doch mal deinen Code
nichts besonderes, einfach den sample-code reingeguttenbergt. 1 | RtmpDownloader downloader = new RtmpDownloader();
| 2 |
| 3 | downloader.setDebugMode(doDbg);
| 4 | final Future<Boolean> future = downloader.download(
| 5 | sServ,
| 6 | null, //connection arguments
| 7 | null, //connection configuration
| 8 | sPath,
| 9 | fnOut
| 10 | );
| 11 | while (!future.isDone()) {
| 12 | try {Thread.sleep(1000);}
| 13 | catch (InterruptedException exc) {}
| 14 | }
|
>Allerdings sollte das auf einen gemieteten Server (mivitec) laufen.
dass das (und ja, ich will da was unterstellen) vermutlich schwer
illegal wird, was du vor hast, ist dir klar ?
OT:http://www.mywot.com/en/scorecard/mivitec.de
> ist ja auch nicht sinn der sache, sich die Streams herunterzuladen,
> sonst wären es ja keine Streams
Doppelt gemoppelt. Normaler Download ist auch schon ein Stream, da er
auf TCP aufbaut, und TCP ist ein Stream-Protokoll (anstatt UDP).
Leider kenne ich mich mit RTMP oder RTSP gar nicht aus, sonst würde ich
den Sinn dieser Protokolle kennen.
Einen Downloader nachzuprogrammieren erscheint mir nicht so schwierig,
dass das TAR-file aber 220kB groß erschreckt mich schon.
(Das rtmpdump...deb Installations-File ist etwas kleiner.)
> dass das (und ja, ich will da was unterstellen) vermutlich schwer
> illegal wird, was du vor hast, ist dir klar ?
Nee, was ist daran illegal? Freie Software, wie z.B. die apache-libs in
eigene Apps einzubinden, war bisher noch nicht verboten, solange man
diese wieder unter die entsprechende Lizenz (z.B. GPL) stellt.
In meinem Fall will ich nur die Machbarkeit überprüfen und im positiven
Falle den Code selbst schreiben.
Ich halte es für möglich, dass das RTMP die Daten nicht schneller
hergibt trotz schneller Verbindung. (Warum rtmpdump das kann, ???)
In diesem Fall hätte sich das ganze Thema schon erledigt.
>Nee, was ist daran illegal
ein Küchenmesser ist auch nicht illegal, .. jemanden damit umbringen
schon..
das was du mit den heruntergeladenen Streams vor hast, wird mit
Sicherheit nicht legal sein...
wo wir also beim wort "stream" sind, ich glaube du weißt schon wie ich
das meine..
"landläufig" spricht man bei video eben von "download" oder "stream"
(auch wenn beides über tcp läuft)
> wo wir also beim wort "stream" sind, ich glaube du weißt schon wie ich
> das meine..
Nicht wirklich. Also bei Youtube gehen die videos über normales HTTP,
zumindestens gabs mal im Netz ein perl-Skript, das sich aus einer
youtube-html-Seite den flv-Url rausgefischt hat und das video per wget
lokal abgespeichert hat.
Von der Anwendungsseite sehe ich keinen Unterschied zwischen Youtube
(http-Download) und TV-Sites (rtmp-"stream").
Ich denke, dass rtmp bei Live-Sendungen sinnvoll wäre, wo zwischen
Kamera-Aufnahme und Browser-Abspielen nur ein paar Sekunden
Zeitdifferenz ist. (Niemand würde eine Fussballspiel komplett aufnehmen
und dann erst ins Netz stellen, wenn das Ergebniss schon bekannt ist).
Wobei man mit http auch den Content "on the fly" übertragen kann. D.h.
die Übertragung beginnt schon, wenn noch nicht alle Daten generiert
wurden.
Dann steht im Header nicht "content-size", sondern die Daten kommen in
kleinen Abschnitten (Chunks)
was auch immer du damit meinst..
egal..
zum thema: warum ist Geschwindigkeit überhaupt wichtig?
mach doch einfach 200 downloads parallel..
Ok, die ganze Wahrheit: :-)
> das was du mit den heruntergeladenen Streams vor hast, wird mit
> Sicherheit nicht legal sein...
Ich hatte vor, die Möglichkeit zu schaffen, wenn ich mit Smartphone/GPS
unterwegs bin, bestimmte Online-Videos zu mp3 umzuwandeln mit geringer
Datengröße.
Auf die Bildinformation kann ich oft verzichten (Nachrichtensprecher).
D.h. ich gehe auf die Site des tomcat-Servers, das Servlet scannt eine
bestimmte Nachrichten-Seite und zeigt mir alle verfügbaren Videos an.
Klicke ich eines an, holt sich das servlet dieses Video vom
Ursprungsserver, wandelt es in ein mp3 um, und liefert das mp3 zu meinen
Smartphone-Browser (1/10 der Ursprungsgröße).
Weder mp4/flv, noch mp3 werden permanent abgespeichert/archiviert.
Auch soll die tomcat-servlet-Seite nicht-öffentlich sein.
Ich müsste noch was finden wie 'ffmpeg', was mir (legal) die
Konvertierung vornimmt, was sehr viel komplizierter ist als
rtmp-Download.
Dadurch dass einige Videos auf anderen Servern gespiegelt sind, hätte
ich nicht an Rechtsverletzungen gedacht.
ja, bei 50 bit/s wird es mit mp3 aber auch eng ;-)
es heißt gpRs oder GSM
> ja, bei 50 bit/s wird es mit mp3 aber auch eng ;-)
Ja, es geht aber auch um die Datenmenge. Ich mache manchmal im Ausland
Urlaub, wo ich nicht sofort eine "einheimische" SIM-karte kaufen
will/kann.
EU-Auslands-Tarife sind seit Juli recht günstig geworden, aber
Volumen-begrenzt.
> es heißt gpRs oder GSM
GPS hat das smartphone natürlich auch, aber das meinte ich nicht in
obigen Kontext :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|
Thread beobachten
Seitenaufteilung abschalten