Ein von cDevice abgeleitetes Device kann MakePrimaryDevice() implementieren, wenn es in dem Fall, dass es das primäre Device wird, etwas spezielles machen will, sollte diese Funktion aber selber nicht aufrufen.
StopReplay() kann es aufrufen, da diese Funtion nicht virtual ist, ich sehe aber den Sinn darin nicht und rate davon ab.
Ein "Stummschalten" des Ausgabeplugins ist in VDR nicht offiziell vorgesehen, somit ist wohl alles in dem Zusammenhang ein "Hack" ;-).
stoppt also die Wiedergabe von VDR.
Das XineLibOutput-Plugin stoppt die Wiedergabe auch, wenn den Player verbindet/entfernt. Das scheint wohl nötig zu sein, wenn man das primäre Device wechseln will.
Das Plugin wird beim Verbinden des Players primär und gibt den Status auf, wenn man den Player schließt.
Gedacht ist das um von zB. der FF-Karte auf XineLibOutput umzuschalten und zurück.
Wie die das intern gelöst haben, weiß ich aber nicht.
Nur der aktuelle Player sollte das aus seinem Thread heraus tun, "alle zu jeder Zeit" auf keinen Fall.
Audio und Video gehen ja in verschiedene Devices, also sollte es wohl keine Probleme machen, wenn einer Audio und der andere Video abspielt. Probleme würde ich erwarten, wenn mehrere das gleichzeitig tun, denn dann könnte es z.B. passieren, dass die Daten ineinander verschachtelt werden, was ziemlich sicher Fehler ergäbe.
Audio und Video gehen also ins gleiche Device
Stimmt, da hatte ich wohl was falsch in Erinnerung.
Ich kenne die Interna des Radio-Plugins nicht, aber deiner Frage entnehme ich, dass es wohl asynchron zum eigentlichen Player Video-Daten schickt. Vielleicht könnte es ein cStatus-Objekt implementieren und auf ChannelSwitch() bzw. Replaying() reagieren und das Senden der Video-Daten beenden?
Das macht es bereits. Ich habe es umgebaut und es sollte jetzt richtig sein. Aber danke, meine Frage hat sich damit geklärt 
Don’t have an account yet? Register yourself now and be a part of our community!
