VDR Portal

Mit -DUSE_AUDIO_DRIFT_CORRECTION ist es eher schlechter, jedenfalls nicht besser.
Mir geht es um die kurze Phase direkt nach dem Sprung, während der das Video zu langsam läuft.
Das ist im Log nicht zu sehen.

Apr 19 22:51:02 vdr vdr: audio/alsa: start delay 336ms
Apr 19 22:51:02 vdr vdr: video: decoder buffer empty, duping frame (688/686) 0 v-buf
Apr 19 22:51:02 vdr vdr: video: 9:37:55.512+8888 0 0/\ms 0 v-buf
Apr 19 22:51:03 vdr vdr: video: decoder buffer empty, duping frame (701/686) 1 v-buf
Apr 19 22:51:03 vdr vdr: video: 9:37:45.712+1344 886 0/\ms 23 v-buf
Apr 19 22:51:04 vdr vdr: video: 9:37:46.212 +844 1110 0/\ms 59 v-buf
Apr 19 22:51:05 vdr vdr: video: 9:37:46.712 +344 1118 0/\ms 85 v-buf
Apr 19 22:51:06 vdr vdr: video: 9:37:47.412 +44 1102 0/\ms 100 v-buf
Apr 19 22:51:19 vdr vdr: video: 9:38:00.392 +24 1086 0/\ms 100 v-buf
Apr 19 22:51:23 vdr vdr: video: 9:38:04.372 +4 1094 0/\ms 100 v-buf

Das Display läuft mit 50 Hz.

Mit VideoSoftStartFrames 120 (habe auch mal 360 und 1200 ausprobiert) war es nicht besser:
Start der Aufnahme: Ton von Anfang an, erst kurz Standbild, dann läuft Bild ruckelfrei.
Weiter nach Sprung: Ton von Anfang an, Bild läuft ruckelnd an, dann gleichmäßig.

Jetzt mit VideoResetStart verhält er sich nach einem Sprung wie beim Start, wobei manchmal das Bild zerfällt. Das sieht aber eher noch schlechter aus, und als Nebeneffekt hängt er jetzt vor Beginn des schnellen Vorlaufs eine Weile fest. Trotzdem vielleicht ein guter Ansatz (?).

Mit vdr-xine gibt es weder Standbild noch Ruckeln.

Ich möchte noch mal die (modifizierte) Frage aus Post 1 stellen:
Bei xine laufen Audio und Video nach jedem Sprung praktisch sofort los. Dagegen dauert es beim softhddevice einen kurzen Moment, bis das Video gleichmäßig läuft / anläuft.
Ist das eigentlich prinzipiell aufgrund der Funktionsweise des softhddevice unvermeidlich, oder besteht da noch die Möglichkeit, es grundsätzlich zu verbessern, so dass es auch praktisch sofort gleichmäßig läuft? Softhddevice und xine funktionieren ja unterschiedlich, bei xine „tickt“ ein Metronom, und Audio und Video werden jeweils ständig daran angepasst, während beim softhddevice Video an Audio angepasst wird. Muss deshalb erst mal der Ton anlaufen, und erst mit einer Verzögerung das Bild? Und wieso ist die Verzögerung nicht praktisch unmerklich (bei Aufnahmen)?
In Post 17 hattest du geschrieben: Aber um eine halbe Sekunde Pause kommst du nicht herum.
Wie kommt es, dass das bei vdr-xine geht, und bei softhddevice nicht? Das soll jetzt keine Kritik sein, sondern eine Verständnis Frage (und natürlich der Wunsch, dass es eines Tages im softhddevice geht :-) ).

Quoted from "johns"

Mich würde mal intressieren von welchen Sender die Aufnahmen sind.

z.B. Arte HD, ARD HD, ZDF HD.

Quoted from "johns"

Man braucht min. 300 - 500 ms an gepufferten Audio, weil es sonst zu Ton Aussetzer kommt.
Dann kommt noch dazu, das einige Fernsehsender das Bild vor dem Ton senden.
In besonderen die Öffentlichen Sender machen dies.

Bei einer Aufnahme müsste das Laden vom Audio in einen Puffer doch blitzschnell gehen, oder?
Bei einer Aufnahme sind die Daten ja alle schon da.

Quoted from "johns"

Will ich jetzt Ton und Bild gleichzeitig loslaufen lassen, dann muß ich 1.5s an Bild wegschmeissen oder 1.5s warten bis der Ton kommt.
Im Moment liegt der Fokus noch auf LiveTV, da bringt es nichts an Bildern wegzuschmeissen.

Das Wegschmeissen wäre mir bei einem Sprung ziemlich egal, mir kommt es ja nicht darauf an, dass er genau 10 Sekunden (oder wieviel auch immer) springt, sondern nur, dass es ein Stück vorwärts geht.
Generell wäre vermutlich ein unterschiedliches Handling von Aufnahmen und LiveTV nützlich.

Quoted from "johns"

Als Alternative könnte man die Zeit in der das Bild langsam läuft vergrößern. Dann fällt einem die Zeitluppe nicht so auf.
Aber wärend dieser Zeit ist dann der Ton nach dem Bild.

So war das auf dem Pentium3 mit xine. Das war aber auch nicht schön.
Wegschmeißen fände ich erst mal das Beste.
Und langfristig wohl eine unterschiedliche Behandlung von Aufnahmen und LiveTV.

Quoted from "johns"

Das sind genau die, wo bei der Übertragung Ton + Bild einen großen Versatz hat.

Wobei man Audiodaten wegschmeissen muß.

Existiert dieser Versatz denn noch in einer Aufnahme?

Quoted from "johns"

Wenn du Lust hast, kannst du ja mal gucken, ...

Ich habe noch mal genau drüber nachgedacht.
Die Syncronisation könnte in etwa so aussehen (Bild kommt früher als Ton):

Vpts = erste Bild pts
Apts = erste Audio pts
dpts = Vpts – Apts, A/V-Versatz
AudioPuffer = nötiger Audio Puffer
Ton startet mit der pts (Apts + Maximum(dpts, AudioPuffer))
Bild startet mit der pts (Vpts + Maximum(0, AudioPuffer – dpts)

Dann passt es von Anfang an zueinander.

Das Problem bei Aufnahmen ist eine Nebenwirkung von der Absicht, bei LiveTV gefühlt möglichst schnell umzuschalten. Um das zu vermeiden, muss auf den A/V-Versatz gewartet werden, wenn dieser größer ist als der AudioPuffer. Dann muss das Bild nicht mehr gebremst werden. Denn jetzt startet der Ton falls dpts größer AudioPuffer mit zu früher pts, nämlich sobald der Puffer voll ist, und deswegen muss das Bild gebremst werden.

Nach meinem Geschmack wäre das auch bei LiveTV angenehmer.
Falls es bei LiveTV so bleiben soll, wie es ist, wäre eine Fallunterscheidung nötig, bei LiveTV so, bei Aufnahmen so. Aber ich schätze, das ist nicht wirklich nötig, falls man bei LiveTV lieber etwas länger wartet, aber dafür einen Start mit sauberem A/V-Sync hat.

Mit folgender Methode hätte man
- Ton so früh wie möglich bei LiveTV
- Bildfluss im richtigen Tempo so früh wie möglich bei LiveTV
- guten Sync bei LiveTV und Aufnahmen

LiveTV:
Ton läuft so an wie jetzt.
Das erste Video frame wird als Standbild gezeigt bis Audio die Sync-pts (Apts + Maximum(dpts, AudioPuffer)) erreicht hat, dann läuft Video an
(eventuell muss eine Latenz fürs Video-Anlaufen berücksichtigt werden).

Aufnahme:
Der Ton wird ab Sync-pts – AudioPuffer gepuffert und startet mit der Sync-pts.
Auch das Video läuft mit der Sync-pts an
(eventuell muss eine Latenz fürs Video-Anlaufen berücksichtigt werden).

Dazu berechnet der Audio-Thread aus der vom Video-Thread übergebenen ersten Vpts die Sync-pts und übergibt sie an den Video-Thread.

Kommentare erwünscht.

Danke!!!
Kurztest: Nach einem Sprung in einer Aufnahme überspringt er jetzt das voraus laufende Audio, aber statt sofort los zu spielen, hängt er einen Moment fest.
Da besteht noch Verbesserungs Bedarf.
Und wenn man zweimal kurz hintereinander springt, ist das Verhalten wie früher.

Nachdem ich "Soft start a/v sync" aktiviert habe, geht es. 2x springen tut´s nun auch.
Besonders gut sichtbar ist es an Laufschriften oder anderen gleichmäßigen Bewegungen.
Es ist zwar noch nicht ganz so glatt wie bei vdr-xine, aber eine große Verbesserung.
vdr-xine schmeißt mehr Audio weg, und läuft sofort glatt, während bei softhddevice jetzt die Ruckelphase viel kürzer, aber noch sichtbar vorhanden ist (z.B. Arte HD).
Damit ich softhddevice wirklich gerne benutze, müsste das noch besser werden ;-)

Hallo johns,
weiß softhddevice, ob eine Aufnahme abgespielt wird oder ob LiveTV abgespielt wird?
Falls nein, würde ich dich bitten es einzubauen :-)
Falls ja, wie kann ich das benutzen?
Ich möchte gerne bei der skip-Berechnung in audio.c eine Fallunterscheidung einbauen, wenn LiveTV so wie immer, wenn Aufnahme abgespielt wird etwas anderes.
Geht das?
Dann bekomme ich nämlich den Sprung so hin, wie ich es schön finde, ohne den Rest zu verunstalten.
Und auch wenn´s den meisten egal ist, für mich ist ein "sauberer" Sprung wichtig.
Danke,
Jörg

Ok, ich habe dreimal „soft limit buffer full“ auskommentiert, bringt aber kein Verbesserung.
Was mich stört ist, dass nach einem Sprung das Video kurz in Zeitlupe abgespielt wird. Der Ton läuft sofort los. Die Aufnahme hat ca. 300 - 400 ms Audio/Video Versatz, die Zeitlupe dauert entsprechend, und mich stört das.
Wenn ich in audio.c AudioVideoReady() folgendes anwende



gibt es keine Zeitlupe mehr, sondern das Video spielt sofort los (und der Ton auch).
Das ist natürlich nur beim Springen schön, sonst eher scheußlich.
Ich weiss auch nicht genau, warum das funktioniert, habe es durch ausprobieren heraus gefunden.