HLS läuft per LAV-Filter, aber nicht als TS Stream - Debugmöglichkeiten?

[Constantin]

Hallo zusammen,

 

ich habe einen HLS-Stream, den ich per "Wiedergabe > URL öffnen" problemlos wiedergeben kann. Lege ich den Stream aber als TS Stream an, meldet der DVB Source Filter für Video und Audio "No data / Unconnected".

User-Agent per ?addhr= setzen habe ich auch schon probiert, leider ohne Erfolg. Auch TransEdit empfängt keine Daten ("Tuning Error").

 

Die M3U8 hier zu posten, wird wahrscheinlich nicht viel bringen - der Stream ist mit personalisierten Hashes in der URL versehen (keines dieser illegalen IPTV-Angebote, keine Sorge - aber eben kein öffentlicher Stream, sondern nur über Authentifizierung erreichbar). Hier trotzdem mal eine "anonymisierte" Version:

 

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=2316800,CODECS="avc1.66.41,mp4a.40.2",RESOLUTION=1280x720
http://example.com/path/smil:XXXXXXXX/chunklist_b2316800.m3u8?diverse=parameter&zur=authentifizierung
#EXT-X-STREAM-INF:BANDWIDTH=1664000,CODECS="avc1.100.32,mp4a.40.2",RESOLUTION=1280x720
http://example.com/path/smil:XXXXXXXX/chunklist_b1664000.m3u8?diverse=parameter&zur=authentifizierung
#EXT-X-STREAM-INF:BANDWIDTH=714000,CODECS="avc1.100.30,mp4a.40.2",RESOLUTION=640x360
http://example.com/path/smil:XXXXXXXX/chunklist_b714000.m3u8?diverse=parameter&zur=authentifizierung
#EXT-X-STREAM-INF:BANDWIDTH=414000,CODECS="avc1.100.30,mp4a.40.2",RESOLUTION=480x270
http://example.com/path/smil:XXXXXXXX/chunklist_b414000.m3u8?diverse=parameter&zur=authentifizierung
#EXT-X-STREAM-INF:BANDWIDTH=64000,CODECS="mp4a.40.2"
http://example.com/path/smil:XXXXXXXX/chunklist_b64000.m3u8?diverse=parameter&zur=authentifizierung

Es ist also nichts verschlüsselt - auch nicht in den Chunklists selbst. Diese sehen übrigens z.B. so aus:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:3606
#EXTINF:7.04,
dateiname_b2316800_3606.ts?diverse=parameter&zur=authentifizierung
#EXTINF:5.039,
dateiname_b2316800_3607.ts?diverse=parameter&zur=authentifizierung
#EXTINF:5.705,
dateiname_b2316800_3608.ts?diverse=parameter&zur=authentifizierung
#EXTINF:5.906,
dateiname_b2316800_3609.ts?diverse=parameter&zur=authentifizierung
#EXTINF:7.041,
dateiname_b2316800_3610.ts?diverse=parameter&zur=authentifizierung
#EXTINF:5.906,
dateiname_b2316800_3611.ts?diverse=parameter&zur=authentifizierung
#EXTINF:5.905,
dateiname_b2316800_3612.ts?diverse=parameter&zur=authentifizierung
#EXTINF:6.607,
dateiname_b2316800_3613.ts?diverse=parameter&zur=authentifizierung

Jetzt kommt das interessanteste: Lege ich direkt die URL einer Chunklist als TS Stream an, dann funktioniert es! Am Bild-/Tonformat kann es also auch nicht liegen!

 

Der Server sendet wohl auch zusätzlich Cookies zur Authentifizierung mit - kann das evtl. ein Problem für den DVBViewer verursachen?

 

Gibt es für mich irgendwelche Möglichkeiten, das selbst zu debuggen? Zu sehen, was der DVBViewer zurückbekommt, wo er stehen bleibt, was ihm nicht "schmeckt"?

 

Viele Grüße

Connum

[Griga]

1 hour ago, Constantin said:

ich habe einen HLS-Stream, den ich per "Wiedergabe > URL öffnen" problemlos wiedergeben kann. Lege ich den Stream aber als TS Stream an, meldet der DVB Source Filter für Video und Audio "No data / Unconnected".

 

Im ersten Fall ist also unter Einstellungen -> Filter kein Eintrag "DVB Source" zu sehen?

 

1 hour ago, Constantin said:

Der Server sendet wohl auch zusätzlich Cookies zur Authentifizierung mit - kann das evtl. ein Problem für den DVBViewer verursachen

 

Bei HLS-Wiedergabe mit dem DVBViewer Filter bzw. via TS Stream werden Cookies schlicht ignoriert. Wenn der Server voraussetzt, dass der Client bei nachfolgenden Requests ein zuvor übergebenes Cookie (z.B. mit einer Session ID oder einer Authentifizierung) zurücksendet, bekommt er es nicht und wird dann womöglich streiken. Bislang hatten wir noch nie mit einem solchen Fall zu tun. Deshalb ist kein Cookie-Handling implementiert.

 

Falls bei dir Cookies erforderlich sind, könnten wir die Gelegenheit nutzen und das ergänzen. Dann wärst du allerdings als Tester gefordert.

 

1 hour ago, Constantin said:

Gibt es für mich irgendwelche Möglichkeiten, das selbst zu debuggen?

 

Ja. Indem du den DVBViewer im Debug-Modus laufen lässt (wer hätte das gedacht? ). Also indem du ihn über die entsprechende Verknüpfung im Startmenü -> DVBViewer (-> Support) -> DVBViewer Pro (Debug Mode) startest oder mit dem Kommandoparameter -debug. Dabei wird die Kommunikation mit dem Server sehr ausführlich im DVBViewer.log (siehe Konfigurationsordner) aufgezeichnet - also nicht lange laufen lassen, das gibt viel Holz! Wenn der Server eine Request wegen fehlender Authentifizierung ablehnt, würde man dort z.B. eine Server-Antwort wie

 

HTTP/1.1 401 Unauthorized

 

oder

 

HTTP/1.1 403 Forbidden

 

finden. Eine Liste der HTTP-Statuscodes findet sich bei Wikipedia. Eventuell kannst du Ergebnisse, die du nicht öffentlich machen willst, mir auch als PM senden. Grundsätzlich ist jedoch das Forum vorzuziehen, da das Thema auch andere interessieren könnte.

[Constantin]

Hi Griga,

 

danke schon mal für deine schnelle Antwort! Debug-Modus, ok, da hätte ich drauf kommen können! Das werde ich mir mal anschauen.

 

Zu deiner Rückfrage:

Quote

Im ersten Fall ist also unter Einstellungen -> Filter kein Eintrag "DVB Source" zu sehen?

 

Ja, so ist es. Stattdessen habe ich einen Eintrag mit dem URL-Pfad, der dann den Dialog des LAV Splitters öffnet.

 

Ich bin inzwischen schon etwas weiter! Ich lasse jetzt die kompletten Requests und das Cookie-Handling durch ein Proxyscript auf meinem lokalen Webserver laufen. D.h. ich parse die m3u8-Listen und verändere die URLs darin so, dass auch diese wieder über das Script laufen. Im VLC oder per "URL öffnen" im DVBViewer klappt das auch immer noch wie es soll (VLC ging übrigens vorher nicht, da wohl der Anbieter den VLC User Agent blockiert hat - aber dank Proxy-Script, das sich als normaler Browser ausgibt, geht das nun). Also kann es an den Cookies auch nicht liegen, denn mit denen hat der DVBViewer jetzt ja gar nichts mehr zu tun.

 

Ich habe dann mal alle Requests auf das Script loggen lassen. Hierbei fällt auf:

- die playlist.m3u8 wird angefordert

- die chunklist wird angefordert

- jetzt sollten die .ts angefordert werden, stattdessen wird aber nochmal die playlist angefordert (ich nehme an, als retry weil irgendwas nicht so ist, wie es der DVBViewer erwartet)

 

Jetzt (oder vermutlich eher morgen/am Wochenende) werde ich mal den Debug-Modus mit Log anschauen, ob ich dabei schlauer werde.

 

Ansonsten kann ich dir gerne auch mal die Files zukommen lassen, ggf. auch ein TS zur Analyse. Ich spiele auch gerne das Versuchskaninchen für euch, vielleicht hilft das auch mal jemand anderem weiter!

 

Viele Grüße

Connum

 

[Constantin]

Hi Griga,

 

ich habe vorhin den Debug-Modus laufen lassen und geschaut, was im Log steht, wenn ich versuche, den Stream abzuspielen.

Hier ist ein Verbindungsdurchlauf, danach fängt es wieder von vorne an:

 

18.05.17 20:12:45.224 TfrmMain             SetTuner         Start
18.05.17 20:12:45.226 TFileDevice          RunDevice        
18.05.17 20:12:45.226 TfrmMain             AllocateHardware TS Stream Device
18.05.17 20:12:45.226 TfrmMain             SetTuner         Found usable hardware
18.05.17 20:12:45.226 TFileDevice          SetTuner         TType: 6, Freq: 0, Symrate: 3858055473, LOF: 39511, Tone: 0, Pol: 0, DiseqC: 0, FEC: 0, APID: 0, VPID: 0, PMT: 0, SID: 0, TID: 0, NID: 0, SatMod: 0, DiseqCVal: 19722, Flags: 24
18.05.17 20:12:45.226 TFileDevice          StopDevice       
18.05.17 20:12:45.226 TFileDevice          CloseDevice      
18.05.17 20:12:45.228 TShoutcastStream     Connecting to    **********
18.05.17 20:12:45.228 TShoutcastStream     Request Header   
GET ********** HTTP/1.1
Host: localhost:8088
User-Agent: DVBViewer Pro 6.0
Icy-MetaData: 1

18.05.17 20:12:47.776 TShoutcastStream     Received header  
HTTP/1.1 200 OK
Date: Thu, 18 May 2017 18:12:45 GMT
Server: Apache/2.4.17 (Win32) OpenSSL/1.0.2d PHP/5.6.15
X-Powered-By: PHP/5.6.15
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Accept-Ranges: bytes
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, User-Agent, If-Modified-Since, Cache-Control, Range
Access-Control-Allow-Methods: OPTIONS, GET, POST, HEAD
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Date, Server, Content-Type, Content-Length
Cache-Control: no-cache
Vary: Accept-Encoding
Age: 0
Connection: close
Set-Cookie: **********; Path=/; HttpOnly
Content-Length: 2456
Content-Type: application/x-mpegurl

18.05.17 20:12:47.776 TShoutcastStream     ==========       THTTPStream.Create succeeded

18.05.17 20:12:47.776 TShoutcastStream     Check for playlist application/x-mpegurl
18.05.17 20:12:47.776 TShoutcastStream     Reading playlist content M3U

[an dieser Stelle steht der Inhalt der ersten Playlist, siehe oben]

18.05.17 20:12:47.776 TShoutcastStream     Connecting to    **********
18.05.17 20:12:47.778 TShoutcastStream     Request Header   
GET ********** HTTP/1.1
Host: localhost:8088
User-Agent: DVBViewer Pro 6.0
Icy-MetaData: 1

18.05.17 20:12:48.141 TShoutcastStream     Received header  
HTTP/1.1 200 OK
Date: Thu, 18 May 2017 18:12:47 GMT
Server: Apache/2.4.17 (Win32) OpenSSL/1.0.2d PHP/5.6.15
X-Powered-By: PHP/5.6.15
Access-Control-Expose-Headers: Date, Server, Content-Type, Content-Length
Cache-Control: max-age=1
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: OPTIONS, GET, POST, HEAD
Access-Control-Allow-Headers: Content-Type, User-Agent, If-Modified-Since, Cache-Control, Range
Age: 0
Accept-Ranges: bytes
Connection: close
Set-Cookie: **********; Path=/; HttpOnly
Content-Length: 3786
Content-Type: application/x-mpegurl

18.05.17 20:12:48.141 TShoutcastStream     Wrong content-type application/x-mpegurl
18.05.17 20:12:48.144 TFileDevice          StopDevice       
18.05.17 20:12:48.144 TFileDevice          CloseDevice      

Es wird also nicht mal der Inhalt der chunklist geparst, weil angeblich der Content-Type application/x-mpegurl nicht stimmt...

Kann es sein, dass der DVBViewer hardcoded nur eine initiale m3u8-Datei erwartet, die direkt Einträge zu .ts-Dateien enthält, und mit der mehrstufigen Aufteilung von m3u8-Dateien nichts anfangen kann?

 

Dann müsstet ihr das nur so anpassen, dass anhand des Content-Types so lange geparst wird, bis man auf .ts-Dateien stößt, oder sehe ich das falsch?

[Griga]

Der DVBViewer erkennt HLS an der Dateierweiterung .m3u8 in der URL. Bei einer anderen nimmt er zunächst Internetradio an (TShoutcastStream-Klasse wird instantiiert). Falls der vom Server gemeldete Mime Type nicht passt, prüft er auf einen Transportstream. Falls das auch nicht hinhaut, gibt er auf und delegiert es an den LAV Sourcefilter.

 

Deshalb besagt das obige Log, dass es sich nicht um eine URL mit .m3u8 handelte. Sieht etwas nach .m3u aus (ohne 8). In dem Fall nimmt der DVBViewer an, dass es sich um eine in eine Playliste verpackte Internetradio-Adresse handelt. Sowas liefern viele Sites mit Internetradio-Sammlungen (z.B. vtuner.com).

 

Da du die URL bislang nicht angegeben bzw. in dem Log entfernt hast, kann ich im Moment nicht mehr dazu sagen.

 

21 minutes ago, Constantin said:

Kann es sein, dass der DVBViewer hardcoded nur eine initiale m3u8-Datei erwartet, die direkt Einträge zu .ts-Dateien enthält

 

Voll daneben vermutet.

 

[Constantin]

Das war der rettende Hinweis, dass der DVBViewer nach dem Dateinamen geht statt nach dem Mime type! Ich habe jetzt meine index.php, die die Authentifizierung vornimmt,  in index.m3u8 umbenannt und per htaccess als php passen lassen - und die Streams laufen!

 

Mich wundert es zwar, dass es mit einem anderen Stream, den ich ähnlich laufen lasse, auch ohne das funktioniert hat, aber egal, Hauptsache es geht jetzt. 

 

Jetzt habe ich noch Probleme damit, dass nicht immer die beste Qualität ausgewählt wird und ganz stabil läuft es auch noch nicht, aber das bekomme ich sicher auch noch irgendwie in den Griff.

 

Morgen probiere ich nochmal aus, ob es jetzt nicht auch ohne alles durch das Script zu schleusen funktioniert - ggf. müsste ich dann tatsächlich auf das Angebot zurückkommen, das mit den Cookies zu testen.

 

Vielen Dank!