Decoder für ARM: Mission Accomplished!

[Klaus_Dieter]

Hallo zusammen,

seit ein paar Tagen kann ich auf meinem armv5-Rechner den OTR-Decoder erfolgreich nutzen und Filme dekodieren.
Der Weg dahin führt über eine speziell gepatchte qemu-user Version.

Zum Selberbauen (optional) - das qemu-binary ist auch im Torrent für den Folgeschritt enthalten

den Git tree klonen: git://github.com/rth7680/qemu.git
in den branch elfload-vdso wechseln (git checkout elfload-vdso)
qemu übersetzen: ./configure --disable-kvm --disable-tools --target-list=x86_64-linux-user; make -j2; make install


Pflicht:

per ldd alle Bibliotheken auf einem 64bit-System zusammenkopieren, die von otrdecoder genutzt werden. (ich hab da mal was vorbereitet: siehe torrent: http://kdserv.dyndns.org/2013-09-09-otr-chroot.tar.bz2.torrent) - nehmen wir mal an, das wurde alles in /mnt/data/otr entpackt.
sudo mkdir -p /usr/local/share/qemu; sudo cp /mnt/data/otr/usr/local/share/qemu/vdso-linux-x64.so /usr/local/share/qemu
dekodieren geht nun mit /mnt/data/otr/bin/qemu-x86-64 -L /mnt/data/otr /mnt/data/otr/bin64/otrdecoder-64 -e Mailadresse -p Passwort -i INPUTdatei -o OUTPUTPFAD


=> Fertig.

Das ganze ist nicht sonderlich schnell, aber auf meinem System mit verschlüsselten Festplatten kriege ich pro Stunde etwas mehr als 1,5GB Daten dekodiert. Für den Heimgebrauch ist das also ausreichend.
Unter https://kdserv.dyndns.org/mediawiki/index.php/Blog:Kdblog/otrdecoder_f%C3%BCr_ARM ist die Beschreibung ebenfalls erreichbar. Bei Feedback & Korrekturen wird diese Version nachgebessert.

[Klaus_Dieter]

Der verlinkte torrent enthält das Gesamtpaket, sodass man nichts kompilieren muss. Das heißt:
* otrdecoder-64 für x86-64
* alle dafür benötigten Libraries für x86-64
* qemu-x86_64 für ARM
* vdso.so, die für qemu benötigt wird - ebenfalls für ARM

[jumper89]

Sieht nach einer interessanten Lösung aus. Schnelligkeit sollte egal sein, wenn es z.B. auf einem Raspberry Pi automatisiert über Nacht läuft.
Hab mir die gezippte Datei gerade runtergeladen und werde es die nächsten Tage mal auf dem Raspberry Pi ausprobieren :)

[Klaus_Dieter]

Man beachte das qemu-Paket: Das ist ein Emulator, damit kann man x86er-Code auf einer anderen Plattform, in diesem Fall ARM, ausführen. Die Überschrift ist also ein bisschen missverständlich: Hier geht es nicht um einen ARM-Decoder, sondern um einen Weg, den x86er-Code auf einer anderen Plattform (als ARM) laufen zu lassen.
stimmt. Weil ich die selbe ARM-Kiste nutze um die Dateien per torrent herunterzuladen verifiziere ich die otrkeys vorm dekodieren nicht. Die Geschwindigkeit reicht locker.

Der Decoder schaut nirgends automatisch nach, ob otrkeys vorliegen sondern muss manuell gestartet werden.
Das lässt sich aber einfach per cron bauen oder bei Bedarf direkt ins Torrent-Programm integrieren.
Ich nutze ein tägliches cron-script, welches im rtorrent-Ausgabeverzeichnis nachschaut ob otrkeys dekodiert werden müssen.

[Klaus_Dieter]

freut mich, dass es prinzipiell schonmal klappt.
Mehr Geschwindigkeit erreichst Du wahrscheinlich, wenn Du qemu nochmal für armv6 übersetzt. Aber auch hier stellt sich die Frage, was der Flaschenhals ist.
Wahrscheinlich ist, dass es der Zugriff auf die Daten ist, beim raspi ist usb2 soweit ich mich erinnere gar nicht mal so schnell...
Du könntest mal schauen, ob top Dir beim dekodieren sagt, dass Deine CPU ausgelastet ist...

[jumper89]

Der Flaschenhals scheint also wirklich der Usb-Port zu sein.
Ich hatte meine OtrKey Datei auf der SD Karte selber gespeichert und es war trotzdem so langsam. Aber möglicherweise ist die Verbindung auch nicht viel schneller als USB?....

[gerk]

Ich hab mal die Lesegeschwindigkeit übers Netzwerk getestet und kam auf maximal 5MB/s von der SD-Karte und 3MB/s von der Festplatte wobei die NTFS formatiert ist. Somit kann die Lesegeschwindigkeit die eigentliche Bremse nicht sein. Selbst bei 1MB/s sollten 500MB unter 10 Minuten gehen.

Nochwas zu meinem Connection-Problem: Irgendwas muss ich falsch gemacht haben. Ich habe mich bis auf zwei Punkte an die Anleitung gehalten:
Ich hab das ganze Paket übrigens nicht unter /mnt sondern /opt installiert (warum eigentlich /mnt?).
Ich musste qemu und ort-decoder Ausführrechte geben.
Allerdings sehe ich nicht wo diese Änderungen die Funktion beeinträchtigen könnten.

[Alex2108]

Danke für die Anleitung und für das bereitstellen der Dateien :)

Auf meinem raspberry pi scheint die CPU das Problem zu sein. 0% Idle und über 90% für qemu sowohl beim verifizieren als auch dekodieren, müsste ich mal schauen ob selbst compilieren für den pi etwas mehr leitung bringt, dafür ist dann sicher über Weihnachten mal Zeit.
Dauer ca. 30 min mit dekodieren und verifizieren von Eingabe und Ausgabe bei 328MB.

@Klaus_Dieter (oder sonst jemand mit passendem script^^): gibt es das erwähnte script zum automatischen prüfen auf neue dateien irgendwo? Es muss ja nicht jeder alles neu erfinden...

[hillibilly]

Vielen Dank an Klaus_Dieter für das Paket und vielen Dank an Alex2108 für die kompilierte Version von qemu-x86_64 für den raspberry pi.
Ich konnte mit Eurer Hilfe eben meinen ersten OTR-key auf meinem raspberry pi dekodieren.

Wie schon gesagt, man wird keine Geschwindigkeitsrekorde brechen aber mein raspberry pi hat als Arbeitstier 24h/7Tage pro Woche Zeit um Keys zu dekodieren.
Wenn ich jetzt noch das Schneiden hinbekomme ... ein Traum!:)

Gruss
hillibilly

[Klaus_Dieter]

was meinst Du mit dem script zum prüfen auf neue Dateien?
Ich hab den ganzen Prozess automatisiert, allerdings ist mein Setup sehr speziell, weil es darauf aufbaut, dass die Maschine auf der das läuft überlastet sein darf.
s gibt also ein cron-script, dass
* in rtorrent die Dateien aufräumt (altes löschen)
* aktuelle neue torrents runterlädt und rtorrent übergibt
* fertig geladene torrents automatisch dekodiert, cutlist runterlädt und schneidet
* nicht sofort geschnittene otrkeys immermal wieder prüft ob es nicht doch eine cutlist gibt
* bei share ratio 1,8 automatisch das seeden stoppt

Das ganze ist ziemlich weit ins System integriert und nutzt einige Dienste:
* cron
* atd
* eine eigene JAva-Anwendung
* shellscripte
* Python-Bibliotheken für rtorrent
* manuelle Konfiguration von ordnern für rtorrent, sodass fertige otrkeys in einem eigenen Pfad landen
* den ganzen multicut.sh Kram (ffmpeg, x264, ffms, mediainfo, bc, awk, sed)

Bislang habe ich mir nicht die Zeit genommen, das mal so aufzuschreiben, dass man das sauber nachvollziehen und das setup wiederholen kann, weil ich mir auch nicht sicher bin, ob das in Anbetracht der Komplexität überhaupt sinnvoll ist. Die meisten der einzelnen Bausteine sind kleine shell-schnipsel, die an den richtigen Ort müssen.
z.B. das nachsehen ob otrkeys in einem Ordner liegen ist über eine simple for-schleife realisiert, die dann das decoder-script und im anschluss das cut-script ausführt. das ist sicherlich sinnvoller, als den gesamten Biotop nachzubilden, den ich hier aufgebaut hab.

[hillibilly]

Hallo Klaus_Dieter,

super dass Du dich nochmal meldest.
So ähnlich wie Du das beschreibst habe ich das auch vor, demnach verstehe ich auch dass die kleinen Scriptschnipsel sehr individuell sind. Ich werde weiter an meinem workflow basteln und diesen wird hinterher wahrscheinlich auch kein anderer einfach nachvollziehen können.
Wichtig sind ja vor allen Dingen das Herunterladen, Decodieren und Schneiden alle Dateioperationen dazwischen sind ja recht einfach mit Shell-Scripts zu automatisieren.
Vielen Dank nochmal für Deine Arbeit und das Teilen mit dem Forum.

Gruss
hillibilly

[hillibilly]

Hallo Jonny007MKD,

das hatte ich vergessen zu schreiben. Meine Dekodierung führe ich mittlerweile auch mit pyropeters otrtool aus. Bei mir hat der Raspi eigentlich genug Zeit, aber schneller ist immer besser. Wer weiß wofür ich die freien Ressourcen in Zukunft noch nutzen möchte.

Ich habe multicutmkv.sh und die Zusammenstellung von Klaus_Dieter bisher nur runtergeladen und kurz reingeschaut, aber noch nichts ausprobiert. Wenn Du da schon weiterkommst bin ich für Hilfestellung immer dankbar (dann im ARM-AVI-schneide-Thread). Ich versuche immer mir alles selbst anzulesen aber an einigen Stellen scheiter ich dann doch. Ein wichtiger Faktor ist dabei natürlich auch die Zeit.

Gruss
hillibilly

[hillibilly]

Hallo Tommer,

hast Du auch die Pakete libcurl3 und libmcrypt4 installiert? Mit den beiden installierten Paketen lief pyropeters otrtool in der komplilierten Version für RasPi von Jonny007MKD ohne Probleme.

Gruss
hillibilly

[Tommer]

Hallo hillibilly,
da hab ich dann wohl zuviel von meinem Pi erwartet. Funktioniert das unter Openelec (/XBMC) genauso?:
sudo apt-get install libcurl3
Danke und Gruß

[Tommer]

Funktioniert das unter Openelec (/XBMC) genauso?:
sudo apt-get install libcurl3
Warum kann man denn hier seine eigenen Beiträge nicht editieren?...
Habe jedenfalls festgestellt, dass openelec bzw. xbmc so abgespeckte Varianten sind, dass es da nicht mal einen Paketmanager gibt. Sofern man die Packages also nicht statisch im otrtool linken kann (oder das einer übernehmen könnte ;-)), wird das wohl nichts werden bei mir.

[hillibilly]

Hallo Tommer,

tut mir Leid, aber damit bin ich raus. Ich habe Raspbian installiert und somit einfach apt-get benutzt. Da ich auch Linux-Anfänger bin kann ich Dir da leider nicht weiterhelfen.

Gruss
hillibilly

[Tommer]

Danke trotzdem! Vielleicht installier ich mir mal ein Raspbian nebenher und versuch das otrtool statisch gelinkt zu kompilieren.
Gruß