Beiträge von libdev

Ich sehe in beiden repos (http://github.com/mapfau / http://github.com/liberty-developer) eine 1.2.3.

https://github.com/liberty-develo…addon.xml.in#L4

Zitat von vdr.tuxnet

Hast du da eine Idee wie es zu dem Fehler kommt ?

Inputstream >= 1.2.2 unterstützt EnableStreamAtPTS nicht mehr, genau so wie die aktuelle kodi version.
Das ist gerade etwas unschön mit den versionen / änderungen

Wenn ihr also die aktuelle kodi nightly nehmt (die kein EnableStreamAtPTS mehr hat, da gab eis einen merge in kodi am 01.08, irgendwann morgends), und das aktuelle inputstream, sollte alles klappen.

B.t.W.: Auch das Windows dll problem sollt mit der nightly von heute vom Tisch sein, inputstream unter win32 linked expat nun statisch.

OK, thx, ich schau mir das mal an...

Zitat von frankr612

Wäre eigentlich eine Implementation von HDS oder HLS wie bei mpd und smoothstream möglich, also inklusive DRM content?

Wüsste jetzt erstmal nicht, warum das nicht klappen sollte.
Wahrscheinlich würde ich dann aber mal diese ganzen Varianten (mpd / smoothstream / HLS ...) in ein inputstream.wollmilchsau zusammenfügen, da eigentlich immer nur der Parser unterschiedlich ist.

ihr könnt ja gerne mal eine f4m datei hier posten oder mir als PM zukommen lassen.
Dann werfe ich mal einen Blick drauf - das was ich bisher gesehen habe ist es lediglich ein format, welches implementiert werden müsste.

Inhalt / Konzept scheint analog mpd / smoothstream zu sein.

Prima, das freut mich!

Zitat von humiboy

Gib es jetzt etwa vielleicht doch Hoffnung inputstream Stream Addons wie SkyGo.. in Android zum laufen zu bekommen?

Das ist zumindest das Ziel. Schaun wir mal was geht, wenn die libwidevinecdm.so unter android läuft, sollte das schon klappen.

So, da sind nun bei den binary kodi addons ein Haufen #ifdef droid rausgefallen, und der notwendige PR ist seit heute drin.

inputstream.mpd / smoothstream laufen nun also erstmal mit freien, nicht encrypteten dash streams auch unter android.
Beide Addons sind (noch) nicht in den nightlies drin, müssen also selbst kompiliert werden.

Wenn jemand mal ein bisschen rumspielen will, dann kann derjenige mal eine libssd_wv für android kompilieren und versuchen, ob die ARM libwidevinecdm.so ggf. sogar unter android läuft.
Wenn ich das noch richtig in Erinnerung habe, hat diese lib keine weiteren dependencies zu anderen systemkomponenten.

Zitat von Scree

TL;DR:
ERROR: AddOnLog: InputStream MPEG DASH: Could not open / parse mpdURL wird geworfen und ich weis nicht mehr woran es liegen könnte.

So langsam bin ich mit meinem Latein (und meinen Nerven) am Ende. Hat wer nen Tip für mich?

Oder sollte ich das ganze System nochmal neu aufsetzen? Vielleicht gleich mit Libreelec?

Bitte füge einfach das ganze [definition='1','0']log[/definition] an - das, was hier entscheidend ist, fehlt zur Analyse, und zwar der Zeitpunkt, zu dem inputstream.mpd gestartet wird.

Zitat von popy

Und auch mit 720p Aussetzer!
Der Leitung ist "fad", die Spikes sind 10mbps, also noch genug Luft nach oben.

Ab nun amazon das Problem ist oder dein Netzwerk, das gilt es nun für dich herauszufinden.
Laut [definition='1','0']log[/definition] ist es recht eindeutig:

22:03:45 T:9168   DEBUG: AddOnLog: InputStream MPEG DASH: Download http://s3.lvlt.dash.eu.aiv-cdn.net/d/1$AOAGZA014O5RE,5638885E/videoquality$1080p/prod/040d/2fd4/fec4/4d10-a9d1-e48ef12656d1/7d115ee6-8d1d-4425-aae6-ec9ab46e45c0_video_11.mp4/range/264699588-266062543 finished, average download speed: 476724.0000
22:03:45 T:9168   DEBUG: CurlFile::Open(120DEB58) http://s3.lvlt.dash.eu.aiv-cdn.net/d/1$AOAGZA014O5RE,5638885E/videoquality$1080p/prod/040d/2fd4/fec4/4d10-a9d1-e48ef12656d1/7d115ee6-8d1d-4425-aae6-ec9ab46e45c0_audio_8.mp4/range/11397346-11462522
22:03:45 T:9168   DEBUG: AddOnLog: InputStream MPEG DASH: Download http://s3.lvlt.dash.eu.aiv-cdn.net/d/1$AOAGZA014O5RE,5638885E/videoquality$1080p/prod/040d/2fd4/fec4/4d10-a9d1-e48ef12656d1/7d115ee6-8d1d-4425-aae6-ec9ab46e45c0_audio_8.mp4/range/11397346-11462522 finished, average download speed: 458903.1586
22:03:45 T:9168   DEBUG: CurlFile::Open(120E0D90) http://s3.lvlt.dash.eu.aiv-cdn.net/d/1$AOAGZA014O5RE,5638885E/videoquality$1080p/prod/040d/2fd4/fec4/4d10-a9d1-e48ef12656d1/7d115ee6-8d1d-4425-aae6-ec9ab46e45c0_video_11.mp4/range/266062544-267504154

download speed: 476724.0000. Das ist in Byte/sek, also ca. 3.8 MBIT/s. Das ist für qualitativ hochwertige 720p Streams zu wenig.

Zitat von kt82

Hallo jojo,mich würde deine Quelle interessieren...
Ich habe irgendwie kein Projekt dazu entdecken können.

einfach netfilx msl googeln, dann kommt: https://github.com/Netflix/msl

Zitat von david.copperfiel

Eigentlich müsste kodi alle Codecs von YT beherrschen. Er spielt zumindest vp9 und opus ab.

in inputstream.mpd ist vp9/opus zumindest freigegeben (seit geraumer Zeit) und die Packete sollten somit eigentlich an kodi weitergeschickt werden.
Bisher komplett ungetestet.

Zitat von Razzee

Ehrlich gesagt habe ich Fernets aussage an der Stelle bisher immer anders verstanden. Und zwar, dass das eher damit zusammen hängt, dass Android "soweit" hinter dem Videoplayer rewrite hinter her hängt. Sprich die Player-Implementierung muss auf Stand gebracht werden an der Stelle. Aber ich kann gerne mal versuchen ihn die Tage zu fragen, wie er das meinte.

Ich glaube das ist reiner Pragmatismus: Kein maintainer = verschenkte Zeit. Ist ja irgendwie auch was Wahres dran.
Wenn jemand nun damit starten würde, die ganzen #ifdef ANDROID im Kodi code mit einem plattformübergreifenden Konzept zu ersetzen, stehen bestimmt alle Türen für Android offen.

Brauchen ist hier glaube ich nicht die Frage, sondern eher, ob du inputstream.mpd nutzen willst.

Das liegt ganz bei dir - da inputstream.mpd ja für YT läuft (so mein letzter Kenntnisstand), musst du ja nicht mehr viel implementieren.
Du musst das Manifest einfach übergeben.

Vorteil wäre, dass du von zukünftigen Entwicklungen (adaptive Bitrate switching) profitierst.
Das wird wahrscheinlich nicht so in kodi implementiert werden.

Zitat von bennySB

Ich bin gerade mal mein Kodi-Verzeichnis am Sichern um eine Nackte Version ohne störende Addons etc. auf zu spielen, dann kann ich es dir zukommen lassen.

Edit:

Im ANhang für dich die Log-Datei. Falls du noch mehr brauchst, dann melde dich gerne bei mir.

Thx....

Kann mir jemand ein kodi [definition='1','0']log[/definition] mit debug [definition='1','0']log[/definition] enabled eines kodi starts posten?
habe kein Android, wollte aber mal die ganzen Pfade vergleichen (linux / android)

Danke!

OK, für skygo / smoothstream gibt es eine Erklärung (und gleich einen bugfix)
Dies erklärt aber nicht die Probleme bei .mpd.

Fix kommt in wenigen minuten, ssd_wv library

Edit: Pushed. @vdr.tuxnet sorry für die Mühen, könntest du bitte ssd_wv noch einmal bauen?

@Jinwelches [definition='1','0']log[/definition]?

Zitat von wobi86

Tritt bei mir auch auf. Aktuell setze ich manuell auf gesehen. Lässt sich da was machen oder ist es einfach so mit inputstream, dass Kodi nicht "merkt" dass abgespielt wurde!?

inputstream ist zu "doof" um da eine Rolle zu spielen. Mit dem von mir eingesetzten "AddonScriptorDE addon" wird der "gesehen Status auf jeden Fall korrekt verarbeitet (teilweise gesehen / komplett gesehen)
Welche Komponente das nun setzt (amazon plugin oder kodi (was ich eher vermute) oder ob der Status von amazon kommt (???) wird wahrscheinlich @Sandmann wissen

Zitat von vdr.tuxnet

mit den aktuellen AddOn's 1.2.0 treten bei mir Probleme auf, Streams starten nicht, Kodi verabschiedet sich ohne eindeutige Meldung im Log.

Ich habe jetzt keine Ahnung ob es am Inputstream AddOn, am Decrypter oder am Video Addon liegt, da ich bis jetzt keine Zeit zum debuggen gefunden habe,

Debuglogs kann ich erst am Wochenende nachreichen, eventuell ist hier jemand, bei dem auch Probleme auftreten und der zeitnah Logs einreichen kann.

neben einem [definition='1','3']Debug[/definition] [definition='1','0']log[/definition] wäre für mich ein crashdump (callstack) wahrscheinlich interessanter.
Soweit ich mich erinnere, wird der ja auch von kodi bei Abstürzen angelegt.