[iptv] m3u, stream, radio Erweiterung

Zitat von fiveten_59

I cant' resolve the problem "undefined symbol: SSL_connect"

Everything compiles but then start fails? And also a difference between Ubuntu 22.04 and Fedora 40? Sounds strange...

Hmm. After checking the Makefile the liibs ssl and crypto does not exists,

Could you please check if everything works, if you change the Makefile (Line 57)

LIBS = $(shell curl-config --libs) -lssl -lcrypto

This is of course an error. I only want to check if there does not exists another problem.

Zitat von fiveten_59

In any case I don't understand why and where the plugin call to the libraries

Many m3u URLs uses https therefore the ssl libraries are needed. I now believe that the SSL libraries have been implicitly linked on my system. e.g. via curl. But more important is, that it works now.

ldd /usr/lib/x86_64-linux-gnu/libcurl.so
    libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f1001905000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f1001400000)

Zitat von Alexandro77

Could you please make a PKGBUILD for arch?

Doesn't already exists a PKGBUILD for arch? I don't have arch and no knowledge about creating a PKGBUILD.

To make it easier, i created a release tag v2.6.0. The latest VDR api is 2.6.9. The samples are not yet copied, because they are new.

Zurück zu den Änderungen:

- der PidScanner existierte in den Sourcen, wurde aber überhaupt nicht aufgerufen. Die Einstellung P=1 in der channels.conf hatte keine Auswirkungen. Das wurde geändert.

- Die Bestimmung der Audio-Pids wurde verbessert (nutzt dazu den PidScanner bei der Einstellung P=1)

- Die M3U Samples (channels.conf) wurden soweit verbessert/geändert, daß keine Obsolete Channels mehr auftauchen.

Was stört mich noch?

- Die Radio-Channels werden abgespielt, aber das letzte Bild des TV bleibt stehen. Ich denke darüber nach, ein Bild aus dem Radio-Plugin zu übernehmen oder ein schwarzes Bild anzeigen zu lassen.

- Es gibt noch einen schweren Fehler beim Wechsel von einem Radio-Channel zu einem M3U-Channel. Mein Ausgabedevice (softhdcuvid) läuft Amok, Puffer laufen über, Bild und Ton sind eine Katastrophe.... Meine Vermutung ist, daß ich die Ausgabedevice-Puffer löschen muss, so wie ich es auch im web-Plugin machen musste. Das probiere ich noch.

Das ist zum Haare raufen - aber sowas von.

Der Wechsel von RADIO nach M3U macht Probleme. Umgekehrt funktioniert alles, auch Wechsel innerhalb des Protokolls geht einwandfrei (RADIO -> RADIO, M3U -> M3U und auch M3U -> RADIO). Und der Wechsel von RADIO -> DVB -> M3U funktioniert.

Das ist auch unabhängig vom Ausgabedevice. Probiert habe ich softhdcuvid, softhddevice und softhdodroid.

Ich kann das Problem einfach nicht lokalisieren. Es sieht alles gut aus und bisher habe ich keine Änderung gefunden, die irgendwie ein anderes Verhalten erzeugt und mehr Hinweise gibt - egal welche.

Auch ein blindes Huhn findet mal ein Korn. Den Code mit Ausgaben gepflastert bis eine Unregelmäßigkeit aufgefallen ist.

Mehrere Threads, die sich die Variablen gegenseitig überschreiben und damit einen inkonsistenten Zustand erzeugen.

Jetzt muss ich nur noch überlegen, wie ich die Locks vernünftig setze.

Zitat von jojo61

Bei mir kann der ffmpeg den Parameter -mpegts_flags nit nicht. Wird das wirklich gebraucht ?

Ich habe den mal rausgenommen und bisher keine Probleme gefunden.

Das Kanalwechsel-Problem sollte auch beseitigt sein.

Das Gegenstück zum Protocol RADIO wurde implementiert: STREAM.

Damit kann man direkt eine URL eines Videostreams angeben, wenn das Format eben nicht m3u ist.

Z.B. habe ich bei mit in der channels.conf sowas stehen:

TEST:600:S=1|P=1|F=STREAM|U=http%3A//localhost/test_stream|A=1:I:0:256:257:0:0:22:1:222:0

und der Apache liefert die Video-Datei aus.

FILE kann nur lokale Files ohne Webserver

HTTP kann nur HTTP und z.B. kein HTTPS.

CURL ist vom Namen her eher unglücklich, weil es auf RTSP spezialisiert ist.

Insgesamt denke ich, daß viele Fälle abgedeckt sein sollten. Mal simpel, mal aufwendiger.

Was mich aber wirklich stört, das das Audio bei M3U manchmal asynchron ist. Mein Standardsender KIKA mit 3 Audiostreams ist da immer ein guter Test. Ein Wechsel der Audiospur oder ein Wechsel des Kanals hilft manchmal. Sehr seltsam. Eine Option, eine bestimmte Audiospur auszuwählen wäre vielleicht auch eine Option.

Also entweder ist FFmpeg mit dem Realtime-Muxen etwas überfordert, zumal das sehr zeitkritisch ist, oder die m3u passt nicht.

Mein Plan sieht vor, mal bei vlc zu schauen, was da so möglich ist.