Beiträge von peak3d

license_key (die URL) bleibt leer, da die im PlayReady Protection header steht.
Die holt sich inputstream.adaptive selbsständig raus.

wenn du aktuelles PlayReady hast, kann es sein, dass es schon funktioniert bei dir.
@jojo muss aber ein paar Zeilen ändern im skygo addon

Ach, gut das du das gefunden hast, das habe ich im [definition='1','0']log[/definition] gar nicht gesehen, muss aber auch gestehen, dass ich nicht der Android Profi bin.

Und ja, DRM geht nur mit Surface. Vlt. werden bald einige DRM geschützten Sachen ohne gehen (muss ich mich drum kümmern), aber Netflix braucht es defintiv.

wenn ich im kodi build Ordner make binary-addons ADDONS=inputstream.adaptive" mache (vor make apk), passiert das eigentlich automatisch alles.
Du musst dann nichts händisch kopieren. Ich sehe das Problem aber irgendwie da nicht, weil das Lizenzhandling ja funktioniert.

Hast du zwischenzeitlich noch mal kodi-agile gepulled? Da sind noch ein paar Anpassungen reingekommen, die aber wahrscheinlich nichts mit deinem problem zu tun haben.

ach, mach Release anstelle [definition=12,4][definition='1','3']Debug[/definition][/definition] in -DCMAKE_BUILD_TYPE=[definition='1','3']Debug[/definition]

Zitat von Maven

Ist sonst noch was zu beachten?

Ich mache einen anderen Schritt 9.

$ cd $HOME/kodi-krypton
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=[definition=12,4][definition='1','3']Debug[/definition][/definition] -DCMAKE_TOOLCHAIN_FILE=$HOME/arm-linux-androideabi-4.9-vanilla/android-21-release/Toolchain.cmake -DENABLE_INTERNAL_FFMPEG=OFF $HOME/kodi-krypton
make -j8
make apk

probiers mal

Ich habe es gestern abend noch erfolgreich genutzt.

Zitat von Maven

zu 1.) NDK r12b; SDK r25.2.3

zu 2.) http://paste.ubuntu.com/24503273/

Ich nutze SDK24 zum Bauen, ob es daran liegt kann ich nicht wirklich sagen, das [definition='1','0']log[/definition] hat für mich leider keine Erleuchtung gebracht. NDK12b deckt sich mit meiner Version.
Ich bekomme morgen eine Shield und kann dort auch mal testen, soweit ich jedoch weiss, sind aber schon ein paar Leute mit der shield und agile erfolgreich unterwegs.

Bis ich das Material habe, kannst du ja mal mein aktuelles build versuchen, damit grenzen wir ein, ob es am build oder am device liegt:
https://www.dropbox.com/s/o3r6sqni6omv…-debug.apk?dl=0

Zitat von Maven

Wenn ich per Kodi DRM-geschützten Content abspielen möchte, dann bekomme ich nur ein Bild, das grau ist.
Tonausgabe funktioniert einwandfrei.

@Maven wann hast du kodi-agile vom Fernetmenta/kodi-agile master branch gezogen?

Edit: gerade gesehen im [definition='1','0']log[/definition], du bis sehr aktuell unterwegs.
Also Punkt ist, dass aus irgendeinem Grund ffmpeg zum kodi dekodieren verwendet wird.
Ich versuch nochmal was zu erkennen

Edit2:

1.) welche NDK Version und welche SDK Version?
2.) adb logcat -c, danach einen Film anspielen, danach pastebinit adb logcat -d

Zitat von L0RE

hab noch keine Aussage bekommen wie das ausschaut im offiziellen Repo wegen drm part ob das erlaubt ist

Ich kläre das mal

@L0RE was hälst du davon das 7TV addon von bromix im offiziellen kodi repo mit deinem 7TV addon zu ersetzen?

Edit: Bin gestern wieder auf die bromix version reingefallen

Zitat von infinity

Netflix hat ja bis heute glaub ich nur die Wetek Hub, nVidia Shield und Xiamo Mi Box freigeschaltet, oder?

Wie oben erwähnt, nur wenige Produkte bringen die entsprechenden Treiber mit, um 4K Inhalte mit Widevine L1 / PlayReady SL3000 zu verarbeiten.
Es ist weniger Netflix, welche den Content verhindern, sondern die fehlende DRM Implementierung der Boards.

Netflix liefert 4K Content nur für ausgewählte geräte, da nur diese geräte es abspielen können.

Zitat von CvH

Ist die Implementierung in Android an Android HW gebunden ? Bzw muss man wahrscheinlich einen DRM Chip verbaut haben !?

Android bringt von Haus aus nur DRM level 3 mit, das ist S/W decrypt + decode, also das, was libwidevine kann.

Sobald es um höhere DRM level geht, die decrypt / decode auf h/w Basis erfordern / ermöglichen, muss der Device Hersteller ran.
Wetek produkte z.B. werden immer mit Widevine Level 1 / PlayReady SL2000 / 3000 ausgeliefert. Das sind dann Treiber, die AMLogic für die entsprechenden Boards gebaut hat.
Diese Treiber arbeiten im ARM spezifischen TEE Environment und sollen dafür sorgen, dass keiner an die Daten rankommt.

@asciidisco seh ich genauso, die ultimative Lösung wäre, das linaro den part fertig macht und DRM im linux kernel existiert.
Die Gerätehersteller müssen dann genau wie unter android die gerätespezifische Implementierung vornehmen (ARM / AMLogic z.B.)

Wir haben ja derzeit das Problem, das libwidevine kein sicheres h/w decoding bietet.
Das ist aber weniger die Faulheit von google, das ist halt technisch bedingt.
Um DRM sicher zu machen, braucht es Bereiche in der Hardware und auch auf Treiber Ebene.

Mit libwidevine sind wir bereits im Grenzbereich angekommen, nur noch starke CPU's schaffen das decoden von dem Material, welches da ist und kommt.
HEVC (h.265) benötigt noch mehr Rechenpower und es ist quasi aussichtslos, das mit libwidevine zu lösen (daher wird der codec auch gar nicht in libwidevine angeboten)

Ich bin selbst gespannt, wie sich das alles weiterentwickelt, leider hat Android in diesem Bereich derzeit die Nase vorne.
Solange kein namhafter Hersteller von Smart-TV auf Linux geht und DRM + linux vorantreibt, seh ich schwarz für die Linuxe von heute.

DRM (zumindest der low-level Teil) muss vom Konzept her eigentlich ins Betriebssystem, genau wie es von Android vorgelebt wird.
Nur so ist es möglich, die sicheren Bereiche / Techniken des Systems / der Hardware nutzen zu können.

Ich persönlich sehe eher LibreElec z.B. als Widevine / playready Lizenzhalter, und LE muss sich darum kümmern, dass das DRM sicher ist.
Blaupausen für Linux gibt es schon (linaro).

Was in Kodi dann reinkommt ist eine API, welche dieses DRM verwendet, genau wie es derzeit mit Android MediaDRM umgesetzt ist.

Nur mal aus technischer Sicht:

wenn @helle636 schreibt, dass es mit amcodec / K16 funktioniert, dann sollte es auch mit mediacodec funktionieren.
Dass die h/w das Video schafft ist ja laut seiner Schilderung "bewiesen".

Ich finde es etwas abwegig, direkt mit neuer Box zu argumentieren.

Ein kodi [definition='1','0']log[/definition] mit aktiviertem Video component debug wäre mal interessant (hatte oben schon jemand geschrieben)
Ohne das wird das hier nur rumgerate blieben.

@cyraxx

1. 11:36:55.904 T:4424 DEBUG: AddOnLog: InputStream Adaptive: Searching for decrypters in: C:\Users\Henry\AppData\Roaming\Kodi\cdm
2. 11:36:55.906 T:4424 DEBUG: AddOnLog: InputStream Adaptive: "C:\Users\Henry\AppData\Roaming\Kodi\cdm\ssd_wv.dll": Das angegebene Modul wurde nicht gefunden.

Diese libssd_wv.dll musst du da noch plazieren, die findest du im git repo von @vdr.tuxnet

Zitat von vdr.tuxnet

Das ist genau der Fehler der mit allen libwideviecdm Libs größer 1.4.8.903, zusammen mit dem inputstream.adaptive Master und den SkyGo Livestreams und Maxdome, auftritt.

Das ist ja erstmal der download des manifests.
Zu diesem Zeitpunkt ist noch wirklich nichts mit DRM oder libwidevine erfolgt, da ich ja Informationen aus dem manifest brauche, um überhaupt mit libwidevine zu reden.

Zu diesem Zeitpunkt wurde noch nicht einmal versucht die libwidevine zu laden.

Zitat von earthwalkerx

An widevine version dachte ich auch schon, aber bin davon ausgegangen dass es die korrekte wäre, wenn ich nach 'howto' gehe.

CCurlFile::Open failed with code 404 for http://live247-s.akamaihd.net/live/232442_232443/24bulihd01.isml/Manifest|acceptencoding=gzip&seekable=0

Das findet alles noch weit vor dem ganzen DRM gedöns statt.
Kann es sein, dass da einfach noch nix lief um die Uhrzeit?

Zitat von infinity

Das mit HLS klingt gerade, inbesondere in Bezug auf die momentanen langsamen IPTV Umschaltzeiten (HLS) in Krypton, interessant. Ist die HLS Umsetzung auch noch für Krypton vorgesehen, oder ist das alles für Agile bzw. Leia dann?

Ich denke nicht, dass irgendwas von den aktuellen Sachen, an denen ich dran bin, den Weg zurück nach Krypton finden wird.