Sinn und Unsinn von "emergency exit"

deshalb hat Klaus den emergency exit ja auch abschaltbar gemacht.

Die Ursache für "TS packet not accepted in Transfer Mode" ist für mich ein wenig mysteriös. Solche Meldungen erhalte ich auch hin und wieder. Dann ruckelt das Bild, obwohl femon einwandfreie Empfangsqualität anzeigt. In der Situation hilft dann meist auch kein vdr-restart (mit Neuladen der DVB-Treiber), sondern ich muss den Rechner neu booten (was den Nvidia-Treiber neu lädt und den x-server neu startet). Wenn das Problem auf der Ausgabeseite (aber nicht beim entsprechenden Plugin) zu suchen ist, dann ist ein emergency exit also ohnehin keine Lösung (außer vielleicht für FF-Karten)

Zitat von Dr. Seltsam

deshalb hat Klaus den emergency exit ja auch abschaltbar gemacht.

Die Ursache für "TS packet not accepted in Transfer Mode" ist für mich ein wenig mysteriös. Solche Meldungen erhalte ich auch hin und wieder. Dann ruckelt das Bild, obwohl femon einwandfreie Empfangsqualität anzeigt. In der Situation hilft dann meist auch kein vdr-restart (mit Neuladen der DVB-Treiber), sondern ich muss den Rechner neu booten (was den Nvidia-Treiber neu lädt und den x-server neu startet). Wenn das Problem auf der Ausgabeseite (aber nicht beim entsprechenden Plugin) zu suchen ist, dann ist ein emergency exit also ohnehin keine Lösung (außer vielleicht für FF-Karten)

Das Problem liegt wohl mit Sicherheit auf der Ausgabeseite.
VDR wird das Paket nicht los und versucht es ein paarmal. Da vom gleichen Device auch Pakete in eine Aufnahme wandern sollen, hält das den ganzen Betrieb auf. Normalerweise wird ja davon ausgegangen, daß das Ausgabedevice jedes angebotene Paket sofort akzeptieren kann.

Versuch doch mal in transfer.c in der Funktion

void cTransfer::Receive(uchar *Data, int Length)
{
  if (cPlayer::IsAttached()) {
     // Transfer Mode means "live tv", so there's no point in doing any additional
     // buffering here. The TS packets *must* get through here! However, every
     // now and then there may be conditions where the packet just can't be
     // handled when offered the first time, so that's why we try several times:
     for (int i = 0; i < 100; i++) {
         if (PlayTs(Data, Length) > 0)
            return;
         cCondWait::SleepMs(10);
         }
     esyslog("ERROR: TS packet not accepted in Transfer Mode");
     }
}

den Wert 100 runterzusetzen (im Extremfall auf 1).
Irgendwann kann es dann allerdings dazu kommen, daß das Live-Bild stottert, denn kurzzeitig kann der Puffer des Ausgabedevices auch mal voll sein.
Wenn das Ausgabedevice dauerhaft blockiert, dann ist das in jedem Fall ein Fehler in der Ausgabe und sollte dort gefixt werden.

Klaus

Moin!

Zum Thema auf anderen Kanal umschalten: Es gibt im vdr die Option "letzter Kanal" oder "bestimmter Kanal". Da solltest du einen SD-Kanal einstellen, damit der vdr immer mit einem darstellbaren Kanal startet.

Geht es um deinen Backend- oder HD-vdr?
Wenn es der Backend-vdr ist:
Da hast du eine SD-FF für die Ausgabe, die nur mit MPEG2-Material umgehen kann. Die HD-Sender sind in h.264.

Wie soll eigentlich ein Output-Device reagieren, wenn es mit dem übergebenen Video nichts anfangen kann? Ich hab eine PVR350 in meinem vdr für die Ausgabe, die kann ja auch nur mit MPEG2 was anfangen. Das von dir beschriebene Problem konnte ich aber noch nie beobachten (ich nehme häufiger HD-Sendungen auf), jedenfalls kann ich mich nicht daran erinnern, wann ich eine zerstörte Aufnahme hatte. Wenn mal eine fehlte, hatte sich einfach der ganze Rechner aufgehangen (das darf er aber einmal im Jahr auch gerne tun). Ich vermute, pvr350 lässt einfach das Paket unter den Tisch fallen (bzw. der Treiber) und meldet Vollzug an den vdr. Denn den vdr interessiert es ja (noch) nicht, ob das Ausgabedevice was darstellt oder nicht.
Wie sieht es denn mit dvbsddevice bzw. dem Treiber aus? Was macht der, wenn er HD-Video bekommt?

Ob es evtl. nötig ist, die API zu erweitern, so dass der vdr das Ausgabedevice fragen kann, ob es das momentane Format überhaupt wiedergeben kann?
Das wäre aber nur dann nötig, wenn es den vdr interessieren sollte. Ansonsten müsste das Ausgabedevice bei nicht unterstütztem Video einfach dem vdr sagen "alles ok, Daten verarbeitet" und dem Benutzer auf der anderen Seite evtl. eine Meldung anzeigen "nicht unterstütztes Videoformat" (optional, nicht nötig).

Lars.

Zitat von mini73

Wie sieht es denn mit dvbsddevice bzw. dem Treiber aus? Was macht der, wenn er HD-Video bekommt?

meiner Meinung nach so, wie man es sich wünscht. Kein Bild, jedoch Ton, wenn zum Device kompatibel. So jedenfalls konnte ich das mit der 1.5 FF und bsw Einsfestival-HD oder anderen HD Sendern sehen, die nicht DVB-S2 benutzen. Also ohne Auffälligkeiten

Zitat von mini73

Wie soll eigentlich ein Output-Device reagieren, wenn es mit dem übergebenen Video nichts anfangen kann?

Ein Ausgabedevice darf den Aufrufer im Live-Modus niemals unnötig blockieren.
Es darf höchstens mal ganz kurz die Annahme verweigern, wenn sein Puffer gerade voll ist. Da die Daten in Echtzeit reinkommen und auch in Echtzeit wieder rausgehen (also dargestellt werden), kann der Puffer des Ausgabedevices nie dauerhaft volllaufen. Tut er es doch, dann hat das Ausgabedevice einen Fehler. Kann das Ausgabedevice die Daten nicht darstellen, dann soll es die Pakete, mit denen es nichts anfangen kann, verwerfen.

Klaus

Moin!

Ich hab manchmal das Phänomen, dass streamdev-server vollläuft, weil Windows-VLC nicht "schnell genug" anzeigt (Uhren mit leicht unterschiedlichem Tempo?), das macht sich dann in stotternder Wiedergabe nach 20 Minuten oder so bemerkbar. Einmal kurz Wiedergabe anhalten und wieder starten hilft natürlich.
Meiner Meinung nach kann es keinen zu keinen kleinen Puffer im Ausgabedevice geben, dann muss der eben größer eingestellt werden. Wenn das Ausgabedevice mit der Ausgabe nicht ernsthaft hinterher kommt, MUSS er Pakete verwerfen. Hilft ja nichts, es werden ja nicht weniger Daten, es kommt ja immer was nach.

Aber wir sind uns einig, dass die Ausgabe nicht ernsthaft blockieren darf. Vielleicht sollte der vdr wirklich nicht so ernsthaft darauf beharren, seine Pakete loszuwerden. Aber das prüft geronimo ja hoffentlich mit der Schleife.

Lars.

Zitat von geronimo

Wobei ...
... die SD-FF zickt nicht nur bei HD-Aufnahmen rum.
Bei manchen Sendungen von 3sat ist die Bitrate derart hoch, dass es die FF nimmer verkraftet.
Dann geht sie in Zeitlupen-Anzeige über mit völlig abstrusen Nebeneffekten (Zeitlupenton, Bildaussetzer, etc).
Klar, auch in so einem Falle sind die Aufnahmen dann Schrott.

In der Konstellation ist die FF auch bei mittleren Bitraten überfordert. Da gehen zwei Streams zum PC und einer zurück zur Karte. Dafür ist das Interface zum TMX320AV7111 zu schmalbandig.

Gruß
e9hack

Zitat von geronimo

Das heißt nicht, dass ich nicht willig wäre, bei Bedarf mitzuhelfen, aber freiwillig tue ich mir C++ nimmer an.

Du brauchst ja auch nur eine Konstante (100) zu verändern.
Stell dir halt einfach vor, es wäre Java, wenn dir das hilft die "Blockade" zu überwinden

Klaus

Moin!

Da du Debian benutzt, ist das "ganz kompliziert":

sudo apt-get update
sudo apt-get build-dep vdr
apt-get source vdr
cd vdr-<Version>

Ich hoffe mal, das Paket benutzt quilt als Patch-Management (siehst du in debian/source/format):

quilt push -a
quilt new <DenkDirEinenPatchNamenAus>.diff
quilt add transfer.c
<editiere wie oben angegeben die Schleife in transfer.c>
quilt refresh
dpkg-buildpackage -tc -uc -us
sudo dpkg -i ../vdr_1.7.<usw>.deb

Lars.

Zitat von mini73

Ich vermute, pvr350 lässt einfach das Paket unter den Tisch fallen (bzw. der Treiber) und meldet Vollzug an den vdr.

so ist es. In PlayVideo wird geprüft, ob die Pakete mit dem PES Packet Start Code (0x00 0x00 0x01) beginnen. Das dürfte nur bei mpeg2 der Fall sein.
Ist dies nicht der Fall, gibt die Funktion "return Length" an den vdr zurück, was aus Sicht von vdr für eine erfolgreiche Ablieferung steht. Die Daten werden insofern verworfen.

Zitat von kls

Wenn das Ausgabedevice dauerhaft blockiert, dann ist das in jedem Fall ein Fehler in der Ausgabe und sollte dort gefixt werden.

sowas kommt aber in der Praxis nun leider mal vor, weil ein Treiber oder das frontend (xine/ vdr-sxfe) hängt oder die Hardware bockt. Das gab es bei der SD-FF-Karte, das gibt es bei VDPAU und wahrscheinlich auch mal bei der HD-FF.
Wie war das jetzt? Schlägt der watchdog mit emergency exit nur dann zu, wenn eine Aufnahme läuft?
Sinn und Zweck des emergency exits war ja, dass durch den Neustart (und Neuladen der DVB-Treiber) die Aufnahmen nicht komplett kaputt sind. (Man hat dann zwar vielleicht eine Lücke von 30s, aber besser als nichts.)
Wenn nun "TS packet not accepted in Transfer Mode" mit Sicherheit auf der Ausgabeseite zu suchen ist (Aufnahmen dadurch also nicht kaputt gehen), dann sollte vdr m.E. in solchen Fällen keinen emergency exit durchführen. Zumindest dann nicht, wenn beim Start erkannt wurde, dass der vdr-Rechner durch einen Timer geweckt wurde. In diesem Fall sitzt ja in der Regel niemand vor dem TV, der davon profitieren könnte, dass das output-device wieder funktioniert. Mal abgesehen davon, dass ein stockendes output-device nicht unbedingt durch einen emergency-exit mit Neuladen der DVB-Treiber geheilt wird. Nach meiner Erfahrung ist manchmal ein reboot erforderlich. Wenn der Nvidia-Treiber oder der x-server hängt, ist das die schnellste Methode, die flüssige Wiedergabe wieder herzustellen.

Moin!

Um den vdr nicht vom Blockieren des Treibers abhängig zu machen, müsste PlayVideo wohl einfach nur die Daten in einen eigenen RingBuffer schreiben (blöd: schon wieder kopieren) und dann von einem anderen Thread aus das Ausgabedevice füttern. Wenn dann was hakt, muss PlayVideo (hat dann ja keinen Platz mehr im RingBuffer) das Datenpaket einfach unter den Tisch fallen lassen. Außerdem könnte es einen internen Vermerk machen, dass der Ausgabethread hängt und ein weiterer Thread (Plugin-eigener Watchdog quasi) könnte dann dafür sorgen, dass der irgendwie gekillt und neu gestartet wird (sofern möglich). Im Zweifelsfall und wenn keine Aufnahmen laufen, kann das Plugin dann auch einen Restart des vdr oder sogar ein Reboot des Rechners auslösen.

Ansonsten kann der vdr am cReceiver-Objekt, das gerade "hakt", nicht direkt erkennen, ob der für ein Ausgabedevice ist oder für eine Aufnahme. Insofern kann der emergency exit auch nicht unterscheiden.

Lars.

Zitat von mini73

Um den vdr nicht vom Blockieren des Treibers abhängig zu machen, müsste PlayVideo wohl einfach nur die Daten in einen eigenen RingBuffer schreiben (blöd: schon wieder kopieren) und dann von einem anderen Thread aus das Ausgabedevice füttern.

Also in cTransfer wird sowas garantiert nicht passieren!
Das hatten wir früher mal, und ich bin froh, daß ich das los bin.

Vielleicht kann ja doch mal jemand, der das Probem hat (oder es zumindest provozieren kann) in cTransfer::Receive() einige Versuche dazu anstellen.
Als erstes könnte man mal statt 100 einfach 1 nehmen. Dann wird jedes nicht angnommene Paket sofort verworfen. Dann könnte man mal testen, wie hoch der Zähler (i) im Normalfall läuft (wenn überhaupt). Nehmen wir mal an, er läuft normalerweise höchstens auf 5 (das wären 50ms, was bei 25fps mehr Zeit ist, als für die Anzeige eines Frames gebraucht wird) und im Fehlerfall wahrscheinlich bis auf 100. Dann könnte man hergehen und in cTransfer ein Flag einbauen, das das wiederholte Aufrufen von PlayTs() unterbindet, sobald der Zähler einmal über 5 gelaufen ist, und erst wieder zurückgesetzt wird, wenn ein Paket sofort angenommen wird.

Klaus

Moin!

Zitat von kls

Also in cTransfer wird sowas garantiert nicht passieren!
Das hatten wir früher mal, und ich bin froh, daß ich das los bin.

Da hat das ja auch nichts verloren... Das muss ja das Ausgabe-Plugin entscheiden, ob es das braucht.

Zitat von kls

Vielleicht kann ja doch mal jemand, der das Probem hat (oder es zumindest provozieren kann) in cTransfer::Receive() einige Versuche dazu anstellen.
Als erstes könnte man mal statt 100 einfach 1 nehmen. Dann wird jedes nicht angnommene Paket sofort verworfen. Dann könnte man mal testen, wie hoch der Zähler (i) im Normalfall läuft (wenn überhaupt). Nehmen wir mal an, er läuft normalerweise höchstens auf 5 (das wären 50ms, was bei 25fps mehr Zeit ist, als für die Anzeige eines Frames gebraucht wird) und im Fehlerfall wahrscheinlich bis auf 100. Dann könnte man hergehen und in cTransfer ein Flag einbauen, das das wiederholte Aufrufen von PlayTs() unterbindet, sobald der Zähler einmal über 5 gelaufen ist, und erst wieder zurückgesetzt wird, wenn ein Paket sofort angenommen wird.

Das hört sich gut an. "Leider" hab ich keine Probleme, aber vielleicht Lust, das zu schreiben. Hm, mal sehen.

Lars.

Also meine Erfahrung mit SoftHdDevice ist.

Das PlayVideoTs die Daten vom VDR ungepuffert bekommt.
PlayVideo die Daten vom VDR gepuffert bekommt.

Ich speicher die Daten in PlayVideo trotzdem in einen eigenen Ringpuffer.
Nach cSoftHdDevice::Freeze nimmt mein Device keine Daten mehr an,
sonst klappte die Pause nicht gescheit.

Wenn die Daten irgendwie suspekt sind, werden sie weggeworfen.

Johns

.