inputstream.* - was kommt als Nächstes? Projekt-Vorschläge/Diskussionen

Genau Coder haben auch ein Privat-Leben und mal schauen wat uns die Zukunft so mit sich bringt.

Zitat von este

es ist schon desöfteren hier zu lesen dass daran gearbeitet wird. es dauert nur etwas

Es wäre halt schön, wenn man mal den Stand der Dinge erfahren könnte. Mehr wollte ich gar nicht erreichen.

Zitat von Ronny

Genau Coder haben auch ein Privat-Leben und mal schauen wat uns die Zukunft so mit sich bringt.

Sagt irgendwer etwas anderes? Natürlich haben sie ein Privatleben.

Ich, und ich gehe davon aus dass es noch mehr gibt, möchte nur mal den Stand der Dinge erfahren.
Nicht mehr und nicht weniger.

Da es schon seit Monaten nicht vorwärts geht (so zumindest der Eindruck) fragt man sich doch warum dem so ist.

Zitat von markot

Es wäre halt schön, wenn man mal den Stand der Dinge erfahren könnte. Mehr wollte ich gar nicht erreichen.

Sagt irgendwer etwas anderes? Natürlich haben sie ein Privatleben.

Ich, und ich gehe davon aus dass es noch mehr gibt, möchte nur mal den Stand der Dinge erfahren.
Nicht mehr und nicht weniger.

Da es schon seit Monaten nicht vorwärts geht (so zumindest der Eindruck) fragt man sich doch warum dem so ist.

Den Stand der Dinge kannst du bei Github und Co ganz genau verfolgen. Wenn sich dort nichts tun, tut sich nichts. So einfach ist es. Wenn sich niemand findet der Lust hat etwas anzugehen, gibt es niemanden der das angeht. Wenn du unbedingt etwas haben möchtest solltest du nicht darauf warten das es jemand bei Github eincheckt sondern es selbst machen oder jemanden dafür bezahlen bzw. ein Produkt kaufen welches deinen Anforderungen entspricht.

Zitat von markot

Es wäre halt schön, wenn man mal den Stand der Dinge erfahren könnte. Mehr wollte ich gar nicht erreichen.

Dann mal eine kleine Schilderung:

Der bisherige Weg war bis jetzt:

1. input (<codec> encrypted) --> 2. decrypt (<codec> decrypted) --> 3. decode (zu YUV Daten) --> 4. rendering

1+2 macht inputstream.xxx, ab 3. übernimmt dann Kodi, soweit möglich in Hardware.

Jetzt gibt Amazon vor, dass die libwidevinecdm 1,2+3 übernimmt und zwar in Software, so wie es über Chrome immer abläuft.

Inputstream.xxx kann Kodi so keine decrypted Streams mehr liefern, sondern liefert bereits dekodierte YUV Daten und genau dies kann Kodi, noch, nicht.

Wie ihr seht sind hier weitgehende Änderungen an Kodi selbst nötig, mit Änderungen an den Addons, alleine, ist es nicht getan, es wird ein zusätzlicher Dekoder

benötigt, den es noch gar nicht gibt, der inputstream.xxx wieder sagt die YUV Daten zu besorgen, damit die normale Kodi Kette eingehalten werden kann.

Ich gehe da mal von einem Timeframe von Kodi 18 Beta bis Kodi 19 aus.

@peak3d mag mich berichtigen sollte ich hier etwas falsch aufgezeigt haben.

Danke für die Info...vdr.tuxnet!

Vielen Dank vdr.tuxnet,

so ist jeder wieder auf dem Laufenden. Sieht also gar nicht gut aus... Mist aber auch...
Kodi18 ist aber ja schon in Arbeit. Nun denn...

Lukesky85...

Du hast das Thema verfehlt. Danach wurde nun echt nicht gefragt. Ich weiß echt nicht, warum sich immer Leute reinhängen müssen, die gar nichts zum Thema zu sagen haben.

Danke für die ausführliche Schilderung vdr.tuxnet.
Sind zwar keine erfreulichen Nachrichten, bringt aber Licht ins dunkle. Besteht deiner Meinung nach Gefahr, dass andere Anbeiter nachziehen? Ich meine hat die Methode, wie Amazon sie jetzt nutzt irgendwelche vorteile zum alten Verfahren?

Nur für Amazon. Man schränkt die Nutzbarkeit auf selbst definierte Methoden ein.

Das übliche Katze-Maus-Spiel

So sehe ich die Sache auch, die anderen Anbieter haben bestimmt kein großes Interesse den Kunden zu gängeln

und auf Amazon oder Google kontrollierte Hardware zu zwingen um in den vollen Genuss aller Vorteile zu kommen.

Meiner Meinung nach...es gibt ja viele...Ohne richtig greifende inputstream.adaptive... mit allen wat damit zusammenhängt...ist Kodi 17 Krypton unvollständig und dürfte somit nicht aus den Beta-Status hinaus wachsen.

Zitat von Ronny

Meiner Meinung nach...es gibt ja viele...Ohne richtig greifende inputstream.adaptive... mit allen wat damit zusammenhängt...ist Kodi 17 Krypton unvollständig und dürfte somit nicht aus den Beta-Status hinaus wachsen.

Auf was bezieht sich dieses Posting jetzt genau, bzw. zu welchem Kontext steht es jetzt?

Decrypting ist aber mMn nicht Bestandteil von Kodi. Das läuft extern. Alles was nicht verschlüsselt ist, läuft ja perfekt.

Alle anderen Versionen von Kodi haben soetwas auch nicht...dachte erst durch Inputstream sowie das decrypting wird es erst vollwertig Krypton (Abkürzung von Kryptonite) und der Hauptgedanke ging dabei an Amazon die versuchen den Kunden zu gängeln...jedenfalls wat die Hardware anbelangt.

So wie ich nach dem aktuellen Stand erkennen kann, ist grundlegend das Problem, dass Kodi mit YUV dekodierten Daten nicht umgehen kann. Ich hab mir das Repo von peak3d angesehen. Ich finde jetzt nur C/C++ Programmcode. C/C++ sowie Java hab ich schon mal gelernt, bin aber weg, weil ja... Java und Oracle... über kurz oder lang fällt die Sprache weg... C/C++ gehört meines Erachtens auf Geräte ohne OS. Gibt es Ansätze in Python? In dieser Richtung möchte ich meine Unterstützung anbieten...

Finde es toll wenn _Manfred_ sich mit Python auch mit einbringen könnte ...um halt Probleme in der Richtung vielleicht auch aus den Weg zu räumen.

Blöde Frage, aber kann man mit genug Rechenpower nicht den Stream wieder YUV encodieren um ihn dann wieder an Kodi weiterzureichen? Das wird on-the-fly nicht gehen, oder? Es wird halt einmal decodiert und dann wieder encodiert. Den Gedanken weiter zu verfolgen macht natürlich nur Sinn, wenn man dadurch vielleicht von Amazon unabhängig wird. Ansonsten einfach ignorieren

@musterzwerg Der Gedanke kam mir auch schon, würde ich das mit ffmpeg machen, schaute das ungefähr so aus:

ffmpeg -f rawvideo -vcodec rawvideo -s 1920x1080 -r 25 -pix_fmt yuv420p -i pipe:0 -c:v libx264 -preset ultrafast -qp 0 pipe:1

-s 1920x1080 -f rawvideo – Da YUV rawvideo daten ohne container sind, gibts keine header die die daten beschreiben, deswegen müssen wir das format (welches wir ja mitgeteilt bekommen sollten) selbst zu dem mix hinzufügen
-r 25 - Raw video kommt mit 25 frames die Sekunde rein
-pix_fmt yuv420p - YUV mit 3 Components/12 Bits per Pixel (Hier müsste man natürlich wissen/rausfinden was wir da an raw video rausbekommen)
-c:v libx264 -preset ultrafast - Dateigröße ist uns eher mal schnurz bei nem stream, deswegen 264 ultrafast, damit sollten wir mit "wenig(er)" Rechenleistung ne bessere Qualität als output bekommen
-qp 0 - Qualität so hoch drehen wie möglich / 51 wäre hier die maximal schlechteste

Aber auch mir stellt sich da die Frage der technischen Machbarkeit, ich hab mir inputstream.adaptive angeschaut, aber nicht mal die mögliche stelle ausmachen können, an der der decrypted Stream an Kodi übertragen wird (hier übrigens auch von meiner Stelle noch mal herzlichen dank an @vdr.tuxnet wegen der guten Erklärung).
Bei der oben angegeben stream conversion bräuchte man imho auch nicht soooooo viel Rechenleistung, wenn ich jetzt nicht von 1080 (wie oben im Beispiel angegeben), sondern 720 ausgehe sollte alles in der Größenordnung RPi3 damit klarkommen (Bauchgefühl).

Ich habe aber irgendwie das Gefühl, dass wenn es so einfach wäre dann hätten so cracks wie der @peak3d oder der @vdr.tuxnet das schon versucht...

Zitat von asciidisco

Aber auch mir stellt sich da die Frage der technischen Machbarkeit, ich hab mir inputstream.adaptive angeschaut, aber nicht mal die mögliche stelle ausmachen können, an der der decrypted Stream an Kodi übertragen wird (hier übrigens auch von meiner Stelle noch mal herzlichen dank an @vdr.tuxnet wegen der guten Erklärung).

Die Übergabe dürfte wohl hier: https://github.com/peak3d/inputst…/main.cpp#L1694 passieren. Ob man da aber nun einen Encoder "vorschalten" kann (oder überhaupt sollte), weiß ich nicht. Ich denke es wäre sicherlich keine gute Lösung.

Ich nehme mal an, dass über kurz oder lang, alle Content-Anbieter darauf bestehen werden, das widevine (oder andere) nur die Rohdaten liefert. Bin da zwar auch nur Laie aber deshalb führt meiner Meinung nach kein Weg an einer direkten Unterstützung eben dieser Rohdaten durch Kodi vorbei. Wie und ob das überhaupt möglich ist, weiß ich nicht.

Steht das Amazon Projekt jetzt eigentlich Still, bis Kodi die Voraussetzungen für den DRM liefert?
Wenn ja wäre es mal interessant zu wissen, ob derzeit an anderen Projekten, und wenn ja an welchen gearbeitet wird.

@frankr612 Das das keine gute Idee ist & sollte es überhaupt möglich sein, nur eine Behelfslösung, ist unbestritten. Und wenn, dann würde ich es auch nicht in die inputstream.adaptive direkt stecken, sondern in einen Fork o.ä.
Für viele Geräte, die den Browser Fallback nicht nutzen können, würde es halt den unterschied zwischen Content ist verfügbar oder eben nicht machen.
Wie gesagt, immer unter der Prämisse das es überhaupt geht, vllt. kann @peak3d mal sagen, ob es geht oder nicht, wenn nicht, können wir uns weitere Diskussionen sowieso sparen.