Zeitversatz im Sat-Signal?

Zitat

Original von sparkie

wieder falsch. Nochmal langsam zum Mitschreiben:

aus der Tatsache, dass unter VDPAU die Framerate des Ausgabegeraetes nicht mit der Framerate des Senders synchronisiert ist folgt keineswegs (wie faelschlich behauptet), dass die Ausgabe mit fortschreitender Zeit immer mehr hinterher hinkt. Auch dann nicht, wenn die Framerate des Ausgabegeraetes geringfuegig langsamer als die des Senders ist.

Letzter Versuch - dann gebe ich es auf:
Bei einem Ausgabegerät von VDR - und nur davon rede ich - ist die Framerate die Geschwindigkeit, mit der die Frames des VDR-Datenstroms verarbeitet werden.

Ein wachsendes Delay kann nur dadurch erklärt werden, daß die Frames langsamer konsumiert als gesendet werden.

Was ein Ausgabe-Plugin intern veranstaltet, (Verdopplung, Auslassen von Frames, Deinterlacing, Framerate der Grafikkarte) ist devicespezifisch und völlig irrelevant.

CU
Oliver

Das dürfte auch sehr hardware-spezifisch sein wenn ich das bis jetzt gesagte richtig verstehe:

Wenn das Timing passt gibts keine Probleme (so auch hier).

Wenn schneller verarbeitet wird als der stream kommt, wird es regelmässige Ruckler geben.

Wird er langsamer verarbeitet wird es problemlos gehen bis nach 20-30min (wenn halt der Puffer irgendwann überläuft). Letzteren Fall kann man dann sicher beheben mit einmal umschalten.

Wenn ich sparkie richtig verstehe sollte es systembedingt kein Problem sein, weil es ja in Vollbildern wiedergegeben wird, wer sollte denn jetzt auf den stream synchronisieren, das vdr plugin oder das frontend ? Oder ist XineLib ungeeignet einen konstanten Stream wiederzugeben ?

Zitat

Original von UFO

Letzter Versuch - dann gebe ich es auf:
Bei einem Ausgabegerät von VDR - und nur davon rede ich - ist die Framerate die Geschwindigkeit, mit der die Frames des VDR-Datenstroms verarbeitet werden.

Ein wachsendes Delay kann nur dadurch erklärt werden, daß die Frames langsamer konsumiert als gesendet werden.

Was ein Ausgabe-Plugin intern veranstaltet, (Verdopplung, Auslassen von Frames, Deinterlacing, Framerate der Grafikkarte) ist devicespezifisch und völlig irrelevant.

CU
Oliver

Alles anzeigen

Ich kann UFO hier nur zustimmen. Wenn in der Videoausgabe keine Synchronisation der PTS mit der Wandzeituhr erfolgt, bleiben alle Bilder, die empfangen wurden, im Puffer. Und das solange, bis jedes einzelne Bild abgearbeitet wurde. Wenn der Dekoder nicht mit 25FPS sondern nur mit z.B. 24,5 FPS arbeitet hast du zwangsläufig nach einer gewissen zeitlichen Versatz. Erst wenn du dem Dekoder mitteilst, dass er die Daten des Puffers verwerfen soll (was du beim Umschalten tust), wenn die Zeit nicht mehr stimmt, bekommst du wieder ein synchrones Bild.

Eigentlich müssten Pufferüberläufe auftreten, aber wenn der Cache wirklich zu groß ist, passiert das nie.

Wenn die Daten zu schnell dekodiert werden interessiert es den Dekoder nicht weiter, er muss in dem Fall solange warten, bis die nächsten Daten anstehen. Bei Video lässt er dementsprechend einfach das letzte Bild stehen, bis das nächste da ist. Wenn es zu langsam dekodiert wird, muss er irgendwann entscheiden, wie er den Datenstau behebt. Das tut er in dem er eine gewisse Tolleranz akzeptiert und alles was drüber geht, wegschmeißt. Das geht ohne Probleme, so lange der Dekoder wenigstens noch halbwegs hinterherkommt. Mehr als 5% langsamer, darfs echt nicht sein!

Synchronisieren muss das Ausgabedevice, also in dem Fall Xine.

Ich habe im Moment nichts von besagten Problemen, ich habe nur mein Verständnis des bisher besagten wiedergegeben um zu checken ob ich richtig liege. Scheinbar gibt es in schöner Regelmässigkeit entweder die einen oder die anderen Probleme und je nach Hardware mit derselben Version unterschiedliche (was man so liest).

Zitat

Originally posted by methodus
Wenn in der Videoausgabe keine Synchronisation der PTS mit der Wandzeituhr erfolgt, bleiben alle Bilder, die empfangen wurden, im Puffer. Und das solange, bis jedes einzelne Bild abgearbeitet wurde. Wenn der Dekoder nicht mit 25FPS sondern nur mit z.B. 24,5 FPS arbeitet hast du zwangsläufig nach einer gewissen zeitlichen Versatz. Erst wenn du dem Dekoder mitteilst, dass er die Daten des Puffers verwerfen soll (was du beim Umschalten tust), wenn die Zeit nicht mehr stimmt, bekommst du wieder ein synchrones Bild.

so ist es aber im xineliboutput-plugin nicht designed. Es wird im Falle Live-TV laufend der Pufferfuellstand beobachtet. Und entsprechend ein Korrekturwert fuer den Frametimer beruecksichtigt. Das erfolgt gleitend, so dass im Falle einer korrekten Implementierung an dieser Stelle ueberhaupt keine Frames verdoppelt werden oder verloren gehen. Ebenso wird hierdurch verhindert, dass der Puffer vorgehaltener Daten zu gross oder klein wird. Mag aber sein, dass bestimmte Entwicklerversionen hier Bugs hatten/haben. Ich arbeite hier mit einer xineliboutput Version + meine FRC Patches von ca. November letzten Jahres. Die FRC-Patches benoetige ich fuer SD mit SCART. Kameraschwenks sind hier sowohl auf SD und HD perfekt. Die laufende WM ist der beste Test den's dafuer gibt:) Das deckt sich auch mit den Debugausgaben. Da steht schlicht nichts drin. Im Falle von Verdoppelung/Ueberspringen von Frames wuerde hier eine Ausgabe erfolgen.

BTW:
Es macht wenig Sinn von dem Symptom 'Ruckeln' auf irgendwelche Ursachen zu schliessen. Fast alle Timingprobleme aeussern sich frueher oder spaeter durch 'Ruckeln' .

- sparkie

Zitat

Original von tomas
Ich hatte anfangs aber wirklich das Problem, dass auf den HD-Kanälen der ÖR reproduzierbar nach genau 30 Minuten Bild und Ton anfingen fürchterlich zu stottern. Nachdem ich in vdr-xine den Pufferüberwachungsmodus auf *Durchgehend* gestellt habe, läuft das auch nach 2-3 Stunden noch ohne Hänger! Meine Puffereinstellungen für die xine-lib sind mit 250/1000 am untersten Limit.

... da kann man mal wieder sehen, wie vielschichtig dieses leidige Thema ist. Die Einstellung hat bei mir "damals" das genaue Gegenteil verursacht. Damit kam es bei mir zu regelmässigen Bildaussetzern. Die waren aber anders, als das jetzige Problem: Es kam zu einem kurzen Standbild, aber der Effekt des anschließenden "schnellen Bildvorlaufs" trat dabei nicht auf. Ohne durchgehende Pufferüberwachung trat das Problem nicht auf. Ich hatte daher rnissl seinerzeit mal auf diese Einstellung angesprochen und er sagte mir, dass sie eigentlich nur für Demoschleifen gedacht wäre, nicht für normale Kanäle; normalerweise sollte eine Pufferüberwachung von 10+ Sekunden ausreichen.

Gruß
Holger

Ich gucke die WM mal auf TVR HD (1080i), mal auf BBC HD / ITV HD (1080i) oder halt ARD HD ZDF HD mit ihrem 720p. Allein das Umschalten zwischen diesen Sendern bringt eine Verzögerung des Signals von gefühlten 3-4 Sekunden auf den deutschen ÖR zu Tage, die ja alles noch mal umskalieren müssen, ich denke die britischen auch (die senden 1440x1080i, also ein auf 16:9 "gestretchtes" 4:3, auch noch mit eigenen permanent während des Spieles eingeblendeten Graphiken wie auch ARD / ZDF (HD). Auf dem rumänischen TVR HD sieht das Bild auch subjektiv am schärfsten aus, die rechnen nichts am Bild um und blenden bloß ihr Senderlogo ein...