Soweit ich weiß kann Intel NUC kein HDR.
Muss auch keine NUC sein, kann auch ein normaler Windows Rechner sein, hauptsache er hat HDMI 2.0 / HDCP2.2 (meine BilligGraKa hat das nicht) und es lässt sich Netflix in Edge in 4K + HDR abspielen.
Wenn es hier jemanden gibt, das zu Hause stehen hat, dann kommen wir vlt. weiter.
Wenn man eine 50tender hat gebe ich bei max 50000000 an und bei min ? 40000000 ?
Wenns gut läuft prima, Punkt ist aber, dass die CDN's manchmal diese Bandbreite nicht hergeben.
Ich habe Min auf 4Mio stehen, das reicht um libCURL richtig messen zu lassen. Max ist 0 (unlimited)
Ich versuche mich gerade an HDR, brauche dazu jemanden, der ne intel NUC kaby lake hat die 4K+HDR in der App oder im Edge browser kann.
Bitte melden 
Nur eigentlich sollte die Einstellungen 0 in inputstream.adaptive ja unbegrenzt bedeuten
Ne, 0 heisst das was gemessen würde nehmen, egal ob es unter Min ist.
Problem ist, dass libCURL bei kleinen Dateien eine ungenaue Download-Zahl ermittelt, wenn das einmal passiert ist, ist man in den Streams mit minimal-Auflösung gefangen.
Muss ich mir mal Gedanken zu machen, wie ich das löse.
Bis dahin setzt als Min irgendwas, was bei uch Min ist. 1MB/sek (also 1000000) z.B.
Ich habe mal amazon firetv 3 (also diese neue kleine Kiste mit S905V) am 4K fernseher getestet.
positiv:
- 4K GUI + videos ist flüssig
- DRM ist drauf und Netflix 4K in kodi geht
negativ:
- Refreshrate switching defekt (nur 59.9Hz) (ich denke da wird irgendwann ein Update kommen)
- Audio wird auch bei Stereo dem receiver als 6-Kanal gemeldet, Ton kommt aber nur aus 2 Kanälen.
In Summe macht die Kiste einen guten Eindruck.
@rbuehlma baust du kodi / inputstream.adaptive selber?
Wenn so, kannst du ja schon mal kodi mit dem PR bauen, den ich eingestellt habe, ich stelle dir dann noch nen inputstream.adaptive patch zur verfügung zum testen.
ne, wenn Du magst Film ich mal ab wie es bei mir rüber kommt und stelle es heute abend ein.
Ggf. solltest du mal eine LE mit aktuellem kodi master versuchen, da ist ein neues FFmpeg drin, welches ggf. das demuxen der streams "richtig" macht und richtige timing Werte liefert.
Anhand von deinem ersten [definition='1','0']log[/definition] ist das Problem klar erkennbar, aber wie gesagt, das sieht bei mir ganz anders aus im [definition='1','0']log[/definition].
Hier mal ein Auszug, wie bei mir die Packete angeliefert werden:
07:23:33.041 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 168447, dts_in: 14.6400[141AE0], pts_in: 14.8800[146F40], overflow:0
07:23:33.042 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 105441, dts_in: 14.6800[1428F0], pts_in: 14.8000[145320], overflow:0
07:23:33.140 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 88562, dts_in: 14.7200[143700], pts_in: 14.8400[146130], overflow:0
07:23:33.174 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 167923, dts_in: 14.7600[144510], pts_in: 15.0000[149970], overflow:0
07:23:33.240 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 104150, dts_in: 14.8000[145320], pts_in: 14.9200[147D50], overflow:0
07:23:33.241 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 89085, dts_in: 14.8400[146130], pts_in: 14.9600[148B60], overflow:0
07:23:33.274 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 167652, dts_in: 14.8800[146F40], pts_in: 15.1200[14C3A0], overflow:0
07:23:33.275 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 102746, dts_in: 14.9200[147D50], pts_in: 15.0400[14A780], overflow:0
07:23:33.374 T:3881825264 DEBUG: CAMLCodec::AddData: sz: 88419, dts_in: 14.9600[148B60], pts_in: 15.0800[14B590], overflow:0Auch dein zweites Video läuft bei mir gut.
Wenn das auch mit neuem LE nicht rund läuft, solltest du dich ans LE forum wenden.
Kodi seitig sieht für mich alles Ok aus (und für diesen Part bin ich zuständig)
LE hat ziemlich viele patches, auch im Video chain, es kann also theoretisch auch sein, dass es daran liegt.
Bei meinen Tests mit kodi18 master auf odroid C2 sieht alles gut aus.
Das snippet, welches du bereitgestellt hast, läuft auf deiner Umgebung wirklich nicht rund?
gerne , wenn interesse dann PM an mich , ich versende dann den Link
Datei angekommen, ich brauch jedoch ein bisschen dafür, muss meinen C2 erstmal wieder flott machen....
Du kannst ja mal eine Sequenz von ~10 sek. rausschneiden und hier zur Verfügung stellen zwecks Analyse.
18:18:26.514 T:545816813792 DEBUG: CAMLCodec::Decode: ret: 4, sz: 0, dts_in: 18442240474082.1797[D8360], pts_in: 18442240474082.1797[D8360], adj:0, ptsOut:7.3200, amlpts:658800, idx:362, timesize:1.8800
18:18:26.545 T:545816813792 DEBUG: CAMLCodec::Decode: ret: 4, sz: 58736, dts_in: 18442240474082.1797[D9170], pts_in: 9.8800[D9170], adj:0, ptsOut:7.3400, amlpts:660600, idx:363, timesize:1.9600
18:18:26.556 T:545816813792 DEBUG: CAMLCodec::Decode: ret: 4, sz: 0, dts_in: 18442240474082.1797[D9170], pts_in: 18442240474082.1797[D9170], adj:0, ptsOut:7.2800, amlpts:655200, idx:364, timesize:2.0000
18:18:26.567 T:545816813792 DEBUG: CAMLCodec::Decode: ret: 4, sz: 0, dts_in: 18442240474082.1797[D9170], pts_in: 18442240474082.1797[D9170], adj:0, ptsOut:7.3000, amlpts:657000, idx:365, timesize:1.9600
18:18:26.614 T:545816813792 DEBUG: CAMLCodec::Decode: ret: 4, sz: 0, dts_in: 18442240474082.1797[D9170], pts_in: 18442240474082.1797[D9170], adj:0, ptsOut:7.3600, amlpts:662400, idx:366, timesize:1.9200
Die mkv Container erzeugen manchmal falsche Infos ob sie DTS oder PTS beinhalten (mkv kann nur entweder / oder)
Bei dir scheint es so, als ob diese Info nicht stimmt, oder die rames für sich nicht richtig sortiert sind.
Wir gehen davon aus, dass aus dem Dekoder die PTS Werte aufsteigend rauskommen, tun sie hier aber nicht durchgängig.
Ich denke es macht aber Sinn, dies in deinem Addon zu lösen.
Ich überlege mir was dazu....
Wird es denn in Zukunft noch soetwas geben...wobei "bitrate switching" dann vorhanden ist?
Klaro, ich habe mich in den letzten Tagen wieder gedanklich damit beschäftigt, also geht es bald los....
Z.B) InputStream Adaptive: Download http://s3.ll.dash.eu.aiv-cdn.net/d/..._video_1.mp4 finished, average download speed: 629395.3723
Das sind nur 629kb/s... könnte bisschen wenig sein für den Stream. Bin aber kein Experte.
Genau, zum Ende hin nimmt die Download-Geschwindigkeit rapide ab, am Anfang war die irgendwo ~1-1,5MB(yte) /sek, aber zum Ende hin halt zu schwach.
Grund kann a.) an deine Anbindung / Netzwerkkonfiguration oder b.) Prbleme beim cdn (amazon) sein.
P.S.: Ich finde auch 1.5MB/sek eher schwach, und da noch kein bitrate switching implementiert ist, werden solche Schwankungen nicht abgefangen.
so eine ähnliche Frage habe ich auch schon gestellt, kam aber keine Antwort, Anfänger werden hier ignoriert, ich denke du wirst dich selber durchkämpfen müssen.
Wenn ihr die kodi [definition='1','0']log[/definition] Datei mit [definition=12,4][definition='1','3']Debug[/definition][/definition] Ausgaben anhängt, steigt die Wahrscheinlichkeit einer Antwort um ein Vielfaches.
11:06:05.099 T:140327184758528 ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <class 'requests.exceptions.SSLError'>
Error Contents: HTTPSConnectionPool(host='www.skygo.sky.de', port=443): Max retries exceeded with url: /sg/multiplatform/web/json/landingpage/33.json (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",),))
Traceback (most recent call last):
File "/root/.kodi/addons/plugin.video.skygo.de/default.py", line 62, in <module>
nav.listPath(params['path'])
File "/root/.kodi/addons/plugin.video.skygo.de/navigation.py", line 656, in listPath
r = requests.get(skygo.baseUrl + path)
File "/root/.kodi/addons/script.module.requests/lib/requests/api.py", line 72, in get
return request('get', url, params=params, **kwargs)
File "/root/.kodi/addons/script.module.requests/lib/requests/api.py", line 58, in request
return session.request(method=method, url=url, **kwargs)
File "/root/.kodi/addons/script.module.requests/lib/requests/sessions.py", line 508, in request
resp = self.send(prep, **send_kwargs)
File "/root/.kodi/addons/script.module.requests/lib/requests/sessions.py", line 618, in send
r = adapter.send(request, **kwargs)
File "/root/.kodi/addons/script.module.requests/lib/requests/adapters.py", line 506, in send
raise SSLError(e, request=request)
SSLError: HTTPSConnectionPool(host='www.skygo.sky.de', port=443): Max retries exceeded with url: /sg/multiplatform/web/json/landingpage/33.json (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",),))
-->End of Python script error report<--Ist das Problem, ich bin sicher, dass hier bald jemand mit einer Lösung schreibt.
Ein Versuch könnte auf jeden Fall sein, export SSL_CERT_DIR=/etc/ssl/certs/ im Terminal aufzurufen
Bin ganz schön ratlos, da eigentlichtm nichts am System geändert wurde und dennoch geht es plötzlich nicht mehr.
Du kannst einfach ein [definition=12,0]debug[/definition] [definition='1','0']log[/definition] hier zur Verfügung stellen.
Ok, verstanden, also Cookie Auth haben wir auch schon mal umgesetzt, ich glaube es war pvr.zattoo.
Wenn derjenige, der sich mit dem addon dann beschäftigt, diesbezüglich Fragen hat, einfach melden.....
Um ehrlich zu sein verstehe ich hier nur Bahnhof 
- Was ist der Akamai Token?
- Was ist die damalige HLS Variante?
- Wie bist du auf die m3u8 playlist gekommen? Ist die Bestandteil der HDS Diskusion?
Ich bin kein BlizzCon User, daher weiss ich Null was vorliegt, bzw. was hier gewünscht ist.
Das Einzige, was sich mir hier gerade erschliesst ist: Du bist irgendwie in der Lage, an die f4m Datei zu kommen, ja?
Wie es damit dann weitergeht, habe ich noch nicht erkennen können, sorry.
Nimm doch einfach die dash version aus dem JS:
"http://aod-dash-ww-live.akamaized.net/usp/auth/vod/p…dd107c166921633"
Da kommt ein shönes DASH manifest zurück, welches so direkt abspielbar sein sollte.
