[rpihddevice] Patch gegen Micro-Ruckler im Live-Betrieb - Neue Version

Hi Uli

Vielen Dank für den Patch!

Meine Kommentare;

• Hast du die Werte für die Buffer einfach mal erhöht oder sind die Werte irgendwie belegt?
• Wozu inkludierst du sstream und cstring?
• Kannst du mir deinen Algorithmus mal erklären? Irgendwie verstehe ich den Code nicht so ganz... ausserdem stellst du den Takt immer nur langsamer - was machst du, wenn die Daten schneller kommen als sie abgespielt werden?
• Warum greifst du auf CurrentChannel() zu? Das Device weiss ja selber am besten, ob es gerade Video und, wenn ja, welchen Codec es abspielt. Ausserdem steht die Auflösung nicht in direktem Zusammenhang mit dem Videocodec.
• Den geänderten Deinterlace-Modus werde ich mal testen.

Gruss
Thomas

Zitat von binduli

Ich muss mich entscheiden bevor der Stream beginnt, um welches Material es sich handelt.

Wenn du eine Unterscheidung von SD und HD haben möchtest dann wird das so nicht funktionieren, da du vorher nicht 100% dies sagen kannst. Das bekommst du nur über eine Streamanalyse hin. H264 heißt nicht automatisch HD!

Grüße
Martin

Hi Uli

Zitat von binduli

Nein habe ich einfach proforma mal erhöht.

Davon bin ich nicht so Fan, zumal das nichts bringen wird. Der VDR buffert selbst schon und der OMX-Scheduler sorgt dafür, dass die decodierten Videoframes solange zurückgehalten werden, bis das passende Audio-Frame kommt. Die Buffer müssen somit einfach gross genug sein, damit der Stream zuverlässig anläuft.

Zitat von binduli

Ich stelle nur am Anfang den Takt langsamer um den Puffer aufzubauen. Danach immer auf Faktor 1x. Wenn Sie schneller kommen sollen muss der Puffer herhalten. Hatte aber bisher noch keine Probleme.

Damit hast du lediglich einen Sanftanlauf implementiert und die eigentliche Taktnachführung über Bord geworfen. Der VDR soll auch nach 48h ohne Umschalten auf einem beliebigen Kanal funktionieren, ohne Daten zu verwerfen. Ich hatte bei Langzeittests mit dem "Ersten HD" nach ca. 24h das Log voller Meldungen über nicht akzeptierte TS-Pakete...

Zitat von binduli

Ich muss mich entscheiden bevor der Stream beginnt, um welches Material es sich handelt.

Das widerspricht dem Konzept des Plugins und - wenn ich das richtig verstehe - auch dem eines Ausgabedevices.

Zitat von binduli

Teste einfach mal den gesamten Patch. Dann sehen wir weiter..

Ich bin offen für Verbesserungen, aber dein Patch macht nicht was er soll. Das zu testen macht für mich deshalb keinen Sinn.

Gruss
Thomas

Zitat von binduli

Fakt ist aber, dass die Ruckler von dieser Taktnachführung stammen. Bei einem Takt von 1x gibt es auch keine Ruckler.

Wie schon geschrieben, ich bin sehr offen für Vorschläge diese zu verbessern - die aktuelle Implementation ist einfach gestrickt, scheint aber für die meisten zu funktionieren. Im übrigen stammt diese Idee nicht von mir sondern vom Autor des omxplayers.

Zitat von binduli

Fraglich wie man einen Stream bändigen will ohne diesen Takt zu verändern.

Das wird nicht möglich sein. Wenn ich richtig informiert bin, schraubt auch softhddevice am Takt der Grafikkarte. Um zwei Takte aufeinander zu synchronisieren, muss sich zwingend einer dem andern anpassen... nun ist die Frage, ob sich das Raspberry dem DVB-Takt anpasst oder umgekehrt.

Zitat von binduli

Es ist auch die Frage ob ein Strem 24 Stunden ohne Fehler laufen muss?

Es ist wohl mehr eine Frage der Einstellung, ob man "mal eben was zum laufen" bringen will, oder ob man vor hat, ein stabiles System wie den VDR durch ein nützliches Plugin zu erweitern.

Gruss
Thomas

Zitat von binduli

Es ist auch die Frage ob ein Strem 24 Stunden ohne Fehler laufen muss?

ich denke schon,
weil andere Devices es doch auch können (zumindest die, die ich soweit getestet hatte). Für den VDR in seiner primären Form als Aufnahmegerät sicher ist es nicht so essentiell, aber der RPI als Client fungiert ja meist nur als reine Bild/Ton-Ausgabe und da gäbe es vielleicht den Anwendungsfall, das bsw. ntv in der Hotellobby oder Fitnesscenter rund um die Uhr läuft.
Anders herum wäre es unschön, wenn es ein Limit geben würde und dann umgeschaltet werden müsste, um einen Fehler auszubügeln.

Hi Uli

Zitat von binduli

ich habe nochmals den Patch nach den hier gebenen Vorschlägen angepasst und hoch geladen.

So wie ich das sehe, macht der "aktuelle" Patch nur den vorherigen rückgängig...

Zitat von binduli

- Streamanalyse um zu entscheiden ob welches Material es sich handelt
- Am Anfang je nach Auflösung eine gewisse Zeit puffern

Wozu? Der OMX Video-Scheduler macht genau das...

Gruss
Thomas

Zitat von binduli

Um die Abspielkorrektur beim Start des Videos auf 0 zu setzen um heir einen kleinen Startpuffer aufzubauen.

Du meinst sicher die Abspielgeschwindigkeit. Aber das ist nicht nötig, wie ich bereits mehrfach geschrieben habe, weil der Video Scheduler die Videoframes solange zurückhält, bis die passenden Audiosamples kommen. Und die Videopakete haben genügend Vorlauf, bzw. werden vom Videodecoder genügend schnell decodiert.

Einziges Problem könnte sein, wenn im laufenden Betrieb der Audiodecoder die Audiosamples verspätet liefert. Dann kommt es im Video zu einem kurzen Ruckler, weil die aktuelle Wiedergabezeit dem Audio-Zeitstempel angeglichen wird. Um hier die Wahrscheinlichkeit zu verringern hilft aber ein Pre-Buffering auf lange Zeit nichts, das macht man besser, indem man die TARGET_LATENCY erhöht. Hier bin ich durchaus offen für Veränderungen.

Zitat von binduli

So kann ich anschliessend mit Faktor 1x abspielen und nur in Ausnahmesituationen eine Korrektur vorzunehmen.

Das ist der falsche Ansatz. Zudem verwendest du im Patch die alten Faktoren, mit denen es nachweislich zu Rucklern kommt. Richtig ist, mit laufenden Korrekturen dafür zu sorgen, dass dieser Ausnahmefall gar nie eintritt.

Ausserdem machst du deinen Buffer wieder von der Auflösung des Videostreams abhängig, was auch nicht stimmt. Wenn schon, müsste dies aufgrund des Codecs geschehen.

Gruss
Thomas

Zitat von binduli

Ich kenne natürlich die Materie nicht so gut wie du, aber meine Tests haben ergeben das ohne zusätlichen Pufferaufbau die Latenzeit auf 0 zurück gehen kann. Dies geschieht besonders bei Sender mit SD-Material, also einer Auflösung mit 720x576. daher versuche ich hier den Puffer ca 0.5 Skeunden länger zu füllen. Dnanach ist die Latenzzeit gut und es ist keine Korrektur nötig.

Dann scheint die Validierung der gemessenen Latenzzeit nicht richtig zu funktionieren - deshalb zusätzlich zu Puffern wäre Symptombekämpfung.

Zitat von binduli

Vielleicht testet du meinen diff ja mal?

Das soll jetzt keineswegs arrogant rüberkommen, aber wenn ich dem Patch bereits ansehe, dass er nicht macht was er soll, dann brauch ich ihn auch nicht zu testen.

Zitat von binduli

Insgesamt muss ich sagen dass hier schwierig ist sich einzubringen. Ich investiere inzwischen viel Zeit mit Testen aber irgendwie kommt es mir so vor als wäre meine Meinung hier nicht wirklich gefragt.

Dabei möchte ich nur die Entwicklung unterstützen.

Jeder Autor von Open Source Software ist froh um die Zeit, die andere Leute investieren um zu testen und die Rückmeldungen die er kriegt - das ist bei mir nicht anders. Und ich bin dir dankbar, dass du mich auf das Problem aufmerksam gemacht hast, und hartnäckig genug warst, damit ich mich überhaupt dazu schlau gemacht habe. Trotzdem habe ich das Gefühl, dass du meine und auch andere Antworten hier im Thread nicht aufmerksam gelesen hast und lediglich versuchst, das Problem zu verschieben statt zu lösen. Zudem sind deine Aussagen oft vage und technisch wenig konkret - das hilft mir leider wenig, da ich deine Tests und Gedanken so nicht nachvollziehen kann. Ich hoffe, du verstehst das und nimmst diese Kritik nicht persönlich!

Gruss
Thomas

Hi Uli

Zitat von binduli

Sicher werde ich auch Neuerungen testen und auch Feedback geben.

Anbei ein Patch mit einer ersten Version der neuen Taktnachführung - vielleicht magst du oder jemand anderes den mal testen. Langzeittests konnte ich noch keine machen, aber ich lass meine Beeren hier mal über Nacht laufen.

Ein paar Erklärungen:

// latency target for live mode in milliseconds
#define LATENCY_TARGET 500

TARGET_LATENCY definiert die Länge des Puffers in ms, und zwar zwischen der PTS des zuletzt angelieferten Audio/Video-Pakets und der aktuellen Wall-Clock. Ohne Korrektur liegt diese im Bereich von 200ms, ich habe sie mal auf 500ms gesetzt, um die Chance auf Audio-Dropouts zu minimieren. Bei Audio-Problemen würde ich als erstes diesen Wert versuchsweise erhöhen.

// speed correction factors for live mode
// HDMI specification allows a tolerance of 1000ppm, however on the Raspberry Pi
// it's limited to 175ppm to avoid audio drops one some A/V receivers
int cOmxDevice::s_liveSpeeds[eNumLiveSpeeds] = {
	S(0.9f), S(0.99983f), S(1.000f), S(1.00017), S(1.1)
};

Um die TARGET_LATENCY beim Start des Streams rasch zu erreichen, dienen die "äusseren" Werte. Ich habe hier +/-10% gewählt, weil hier noch Ton kommt, aber die Anpassung nicht zu lange dauert. Die "inneren" Werte dienen der langfristigen Stabilisierung der TARGET_LATENCY und sind innerhalb der maximal zulässigen Toleranz von 175ppm, mit der sich der HDMI-Takt noch dehen lässt.

Übersetzt mit "make DEBUG_LATENCY=1" schreibt das Plugin dazugehörige Traces. Hier ein Beispiel:

Dec  7 15:02:24 192 vdr: [5592] rpihddevice: AV latency =  486ms, corr =  -|  , max neg/pos corr = 1/0
Dec  7 15:02:24 192 vdr: [5592] rpihddevice: AV latency =  482ms, corr =  -|  , max neg/pos corr = 1/0
Dec  7 15:02:24 192 vdr: [5592] rpihddevice: AV latency =  479ms, corr =  -|  , max neg/pos corr = 1/0

Die Logs sollten eigentlich selbsterklärend sein. Das Zahlenpaar am Ende der Zeilen gibt an, wie oft die grossen Korrekturfaktoren gewählt wurden. Da diese nur zu Beginn benötigt werden, sollte der Wert hier entweder 0/1 oder 1/0 sein. Ist die TARGET_LATENCY mal erreicht, sollten die kleinen Anpassungen reichen, um die Drift zu kompensieren. Soweit die Theorie.

Ich freue mich auf Rückmeldungen und wünsche einen frohen zweiten Advent!

Gruss
Thomas

Hi Uli

Zitat von binduli

Aber eventuell könnte man wie von mir schon mal vorgesehen die anfängliche Geschwindigkeit auf 0 setzen um möglichst schnell auf das TARGET_LATENCY zu kommen? Dann würde zwar das Bild einen Augeblick später kommen aber man hat keine Ruckler anfangs.

Die anfängliche Geschwindigkeit lässt sich grundsätzlich schon verringern, allerdings besteht dan die Gefahr des Überschwingens. Um die aktuelle Latency zu filtern, schreibe ich die letzen n Werte in ein Array und nehme dann den Durchschnitt. Die Größe dieses Arrays müsstest du dann verkleinern, damit dieses Filterung schneller wird. Aber dadurch verringert sich auch die Stabilität, was vielleicht andere Effekte nach sich zieht... Hier ist ausprobieren angesagt.

Ein Kompromiss wäre vielleicht 0.8 bzw. 1.2, hier bleibt der Audio-Render stumm, aber die Regelung bräuchte nicht angepasst zu werden. Aber die aktuellen Werte sind erste Vorschläge, ich bin da offen für Verbesserungen.

Gruß Thomas