Erst mal herzlichen Glückwunsch zum 0.5ten Geburtstag!
Nun zu einem Hauptgrund, warum ich zwar softhddevice ab und zu ausprobiere, aber nicht produktiv zu laufen habe. Das liegt daran, dass ich häufig schnell durch Aufnahmen springe (mit +10 sec Sprüngen). Nach jedem Sprung dauert es aber eine Weile bis Audio und Video syncron sind. Wenn ich viel springe, höre/sehe ich also die meiste Zeit asyncron. Das mag ich nicht.
Mit xine ist das ganz anders. Dort sind Audio und Video nach jedem Sprung sofort syncron. Soweit ich xine versteh, liegt das daran, dass dort ein Metronom „tickt“, und Audio und Video jeweils ständig daran angepasst werden. Dagegen wird beim softhddevice Video an Audio angepasst (oder war es anders herum?), und es dauert (bei meinen letzten Versuchen noch vor der Audio Erweiterung) jeweils einige Minuten, bis sich der Versatz minimiert hat.
johns: 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 sehr schnell syncronisiert?
[softhddevice] Audio Video Syncronisation
-
-
(mit +10 sec Sprüngen).
Bevor eventuell wieder unnötige Anpassungen gemacht werden, muss ich darauf hinweisen, dass hier eindeutig am VDR rumgebastelt wurde. Eine Minute mit der gelben bzw der grünen Taste ist normal.
-
Also prüfe erstmal ob du den letzten Stand hast. Ich denke 0.5.0 sollte aber reichen.
Wenn ja, kann es sein das die 10s Sprung einfach zuwenig sind.
Ab 5s Unterschied zwischen Ton und Bild versuche ich keine Syncronisation mehr.
Wenn jetzt 5s gepuffer werden könnten die 10s genau innerhalb dieses Bereichs fallen.Das Problem bei Aufnahmen liegt am VDR. Ich weiß ich sollte es mal als Bug reporten, aber ich habe keine Lust.
VDR knallt die Puffer vom Plugin einfach voll und da meine Puffer sehr groß sind, sind schnell ein paar Sekunden in den Puffern.in video.c 2*
in
ändern. Dann sollte bei größeren Unterschieden noch syncronisieren.Wobei, wenn ich mir die Sache jetzt überlege, sollte dies keinen Unterschied machen.
Egal wieviel gepuffert wurde, die aktuelle Zeitstempel sollten immer gleich sein.Es könnte mit der ganz aktuellen Version weg sein. Da vorher noch alte Zeitstempel in den Puffern waren.
Ich springe hier +- 30s und da funktioniert es.
Johns
-
also ich springe hier auch regelmäßig mit 1/3 +-10s und hier synct das innerhalb einer Sekunde, kann ich so nicht bestätigen.
Betrieben mit Ton über hdmi, passthrough, GT430
Christian
-
allerdings kann ich die Beobachtung von fnu bestätigen, dass der Audiosync auf SD generell grottenschlecht ist. Bin wieder zurück auf eine Version vom 7.4., das ist besser wenn auch nicht perfekt.
Kann jemand eine Version nennen wo die Grundfunktionen eines modernen DVB Frontends, sprich: Stabilität, Umschaltverhalten, Ruckelfrei, Audiosync bei HD und SD, einwandfrei sind, an den anderen Funktionen hab ich kein interessen: back to Basics!
Christian
-
warum nicht die plugin paketsourcen nehmen
dann immer einen schritt zurück :
http://projects.vdr-developer.…gin-softhddevice.git/log/paket mit den neuen (altären) sourcen bauen, und testen ab welchen commit es besser wird ?
<<---smartass
EDIT: komisch hier will es einfach nicht schlecht laufen, egal ob aktuelle oder ältere version
-
du machst es btw einem aber auch nicht einfacher Holger, da du im Paket nicht die snapshoot Version übernimmst, so damit sie unter Plugins wie bei anderen angezeigt wird. Da steht immer nur was von .5 oder .5.1 jetzt
Wie kann ich denn aus dem git einen speziellen Snapshot auschecken?
Christian
-
wir haben im paket leider schon die version auf 0.6.0 erhöht .... lässt sich leider nicht rückgängig machen.
aber das ist beim lokalen bauen ja egal.du kannst doch direkt hier:
http://projects.vdr-developer.…3db31fc01365ebd3c3cd5d4e6im "commit" das ganze runterladen :
-
doch eigentlich schon :
eben von hier :
http://projects.vdr-developer.…gin-softhddevice.git/log/master branch
-
doch eigentlich schon :
eben von hier :
http://projects.vdr-developer.…gin-softhddevice.git/log/master branch
und wo steht da was vom 0.6?wenn du git kompilierst wird artig diese Revision im Pluginmenu angezeigt, da weiß jeder was drin ist
http://projects.vdr-developer.…plg-softhddevice/activity
Christian
Das mit dem commit im Ganzen runterladen kannte ich nicht, danke
-
sag ich doch, wir haben da einen fehler gemacht (nicht der erste) daher ist das paket schon in der zukunft.
wenn man aber in den plugin einstellungen nachsieht ist es bei 0.5.1sobald johns die version auf 0.6.0 erhöht passt es doch wieder ... also was solls
-
also ich dachte eher an ne Versionierung wie 0.5.1-8039e8ae, da die Pakete fast im 2 Tagesrythnus kommen reden alle nur über Äpfel und Birnen, und johns der arme Wicht weiß auch nicht wie er die Kommentare zu bewerten hat...
Christian
Kannste aber vergessen da die git Resvisionen nicht aufsteigend sind, also vergiss es
-
Versuch doch erstmal den Audiodelay im Setup zu verstellen oder über Macros:
Code@softhddevice Blue 1 3 decrease audio delay by 10ms @softhddevice Blue 1 4 increase audio delay by 10ms
Dann Ergebis posten, bis jetzt habe ich nur ganz am Anfang einen Hinweiss auf den delay bekommen.
z.b. so SAT1 Astra +40ms
oder alle 768i +40ms 720 ok 1080i ok
ein genereller Versatz geht auf TV und A/V Receiver zurück.
wenn nur SDTV zu HDTV versetzt ist, dann liegt es an den internen Puffern.Johns
-
CKone
neeee ....
das ist paketphilosophie.
ich kenn mich da auch nicht aus. du weisst doch ich bin krankenpfleger.
wenn ich in der pflege manchmal solange überlegen würde wie die softwareentwickler (ausgenommen johns/mini73)
wäre die hälfte meiner klienten warscheinlich schon im himmel.so sieht es grade aus:
0.6.0.git20120419
so wäre es richtig :
0.5.1.git20120419
wenn ich jetzt heute nochmal ein paket bauen würde so:
0.5.1.git20120419.1016
ich geh davon aus, das nach dem punkt ist die uhrzeit
so mach ich das immer. und das auch nur weil es mir niemand gezeigt hat, wie es besser geht.
oder anders, bisher gibt es ja auch kaum jemanden der es machen will.@all sorry für offtopic
-
Hier noch eine Ergänzung zu meinem ersten Post, ein Log mit USE_AUDIORING.
Er ist nach 2 Sek. (01:02:49) bei +38, und nach 15 Sek. (01:03:02) fängt die Regelschleife an (18 -> -1 -> +6 -> -13 -> +6 -> -13 .....).Apr 19 01:02:47 vdr vdr: audio/alsa: start delay 336ms
Apr 19 01:02:47 vdr vdr: video: decoder buffer empty, duping frame (351/33309) 1 v-buf
Apr 19 01:02:47 vdr vdr: video: 4:18:04.945+8888 0 0/\ms 1 v-buf
Apr 19 01:02:48 vdr vdr: video: 4:19:04.765 +278 1117 0/\ms 49 v-buf
Apr 19 01:02:49 vdr vdr: video: 4:19:05.525 +38 1125 0/\ms 61 v-buf
Apr 19 01:02:50 vdr vdr: video: 4:19:06.525 +38 1085 0/\ms 60 v-buf
Apr 19 01:02:51 vdr vdr: video: 4:19:07.525 +38 1093 0/\ms 60 v-buf
Apr 19 01:02:52 vdr vdr: video: 4:19:08.525 +38 1125 0/\ms 62 v-buf
Apr 19 01:02:53 vdr vdr: video: 4:19:09.525 +38 1134 0/\ms 61 v-buf
Apr 19 01:02:54 vdr vdr: video: 4:19:10.525 +38 1118 0/\ms 59 v-buf
Apr 19 01:02:55 vdr vdr: video: 4:19:11.525 +38 1126 0/\ms 59 v-buf
Apr 19 01:02:56 vdr vdr: video: 4:19:12.525 +38 1134 0/\ms 61 v-buf
Apr 19 01:02:57 vdr vdr: video: 4:19:13.525 +38 1118 0/\ms 61 v-buf
Apr 19 01:02:58 vdr vdr: video: 4:19:14.525 +38 1102 0/\ms 59 v-buf
Apr 19 01:02:59 vdr vdr: video: 4:19:15.525 +38 1086 0/\ms 60 v-buf
Apr 19 01:03:00 vdr vdr: video: 4:19:16.525 +38 1094 0/\ms 60 v-buf
Apr 19 01:03:01 vdr vdr: video: 4:19:17.525 +38 1102 0/\ms 61 v-buf
Apr 19 01:03:02 vdr vdr: video: 4:19:18.505 +18 1134 0/\ms 64 v-buf
Apr 19 01:03:03 vdr vdr: video: 4:19:19.505 +18 1142 0/\ms 64 v-buf
Apr 19 01:03:04 vdr vdr: video: 4:19:20.505 +18 1126 0/\ms 63 v-buf
Apr 19 01:03:05 vdr vdr: video: 4:19:21.505 +18 1110 0/\ms 62 v-buf
Apr 19 01:03:06 vdr vdr: video: 4:19:22.485 -1 1118 0/\ms 61 v-buf
Apr 19 01:03:14 vdr vdr: video: 4:19:30.485 +0 1086 0/\ms 62 v-buf
Apr 19 01:04:26 vdr vdr: video: 4:20:42.485 +1 1112 0/\ms 63 v-buf
Apr 19 01:05:01 vdr vdr: video: 4:21:17.485 +2 1081 0/\ms 61 v-buf
Apr 19 01:05:36 vdr vdr: video: 4:21:52.485 +3 1122 0/\ms 62 v-buf
Apr 19 01:06:11 vdr vdr: video: 4:22:27.485 +4 1091 0/\ms 62 v-buf
Apr 19 01:06:47 vdr vdr: video: 4:23:03.485 +5 1140 0/\ms 61 v-buf
Apr 19 01:07:22 vdr vdr: video: 4:23:38.485 +6 1109 0/\ms 61 v-buf
Apr 19 01:07:46 vdr vdr: video: 4:24:02.465 -13 1086 0/\ms 56 v-buf
Apr 19 01:07:59 vdr vdr: video: 4:24:15.465 -12 1094 0/\ms 63 v-buf
Apr 19 01:08:36 vdr vdr: video: 4:24:52.465 -11 1079 0/\ms 62 v-buf
Apr 19 01:09:10 vdr vdr: video: 4:25:26.465 -10 1112 0/\ms 62 v-buf
Apr 19 01:09:43 vdr vdr: video: 4:25:59.465 -9 1089 0/\ms 60 v-buf
Apr 19 01:10:19 vdr vdr: video: 4:26:35.465 -8 1090 0/\ms 61 v-buf
Apr 19 01:10:57 vdr vdr: video: 4:27:13.465 -7 1131 0/\ms 64 v-buf
Apr 19 01:11:29 vdr vdr: video: 4:27:45.465 -6 1100 0/\ms 63 v-buf
Apr 19 01:12:07 vdr vdr: video: 4:28:23.465 -5 1117 0/\ms 60 v-buf
Apr 19 01:12:43 vdr vdr: video: 4:28:59.465 -4 1118 0/\ms 60 v-buf
Apr 19 01:13:14 vdr vdr: video: 4:29:30.465 -3 1103 0/\ms 62 v-buf
Apr 19 01:13:52 vdr vdr: video: 4:30:08.465 -2 1120 0/\ms 64 v-buf
Apr 19 01:14:28 vdr vdr: video: 4:30:44.465 -1 1097 0/\ms 62 v-buf
Apr 19 01:14:59 vdr vdr: video: 4:31:15.465 +0 1130 0/\ms 62 v-buf
Apr 19 01:16:14 vdr vdr: video: 4:32:30.465 +1 1084 0/\ms 62 v-buf
Apr 19 01:16:49 vdr vdr: video: 4:33:05.465 +2 1101 0/\ms 61 v-buf
Apr 19 01:17:25 vdr vdr: video: 4:33:41.465 +3 1102 0/\ms 62 v-buf
Apr 19 01:17:57 vdr vdr: video: 4:34:13.465 +4 1119 0/\ms 56 v-buf
Apr 19 01:18:36 vdr vdr: video: 4:34:52.465 +5 1096 0/\ms 62 v-buf
Apr 19 01:19:11 vdr vdr: video: 4:35:27.465 +6 1089 0/\ms 62 v-buf
Apr 19 01:19:38 vdr vdr: video: 4:35:54.445 -13 1114 0/\ms 63 v-buf
Apr 19 01:19:48 vdr vdr: video: 4:36:04.445 -12 1122 0/\ms 57 v-buf
Apr 19 01:20:22 vdr vdr: video: 4:36:38.445 -11 1107 0/\ms 61 v-buf
Apr 19 01:20:57 vdr vdr: video: 4:37:13.445 -10 1124 0/\ms 63 v-buf
Apr 19 01:21:35 vdr vdr: video: 4:37:51.445 -9 1117 0/\ms 63 v-buf -
Ich habe jetzt mit der vorletzten und letzten Version des softhddevice nochmal genau beobachtet, was mich stört. Es ist vor allem die erste Phase nach einem Sprung, in der das Video verlangsamt ausgegeben wird. Von xine bin ich es gewöhnt, dass sofort nach einem Sprung das Video im richtigen Tempo läuft, und auch syncron zum Audio. Beim Abspielen von Aufnahmen liegen ja auch die Daten schon vor, und man muss auf nichts warten.
Wäre es nicht möglich, dem softhddevice das auch beizubringen? -
Sollte gehen bzw. ist alles vorhanden.
Um sofort schnell loszulaufen gibt es "softhddevice.SoftStartSync = 0" in setup.conf.
Dann wird ein zugroßer Audiopuffer weggeschmissen, wenn das Video bereit ist.
Aber um eine halbe Sekunde Pause kommst du nicht herum.Die Regelschleife kann von "-DUSE_AUDIO_DRIFT_CORRECTION" kommen, deshalb habe ich die Audiodriftkorrektur noch nicht als Default gemacht.
Bzw. muß noch mal genau verfolgen was passiert und wenn nötig noch die Zeitstempel korrigieren.Johns
-
SoftStartSync disablen hat bei Aufnahmen keinen merkbaren Unterschied gemacht. Beim Zappen schon.
Auch mit default Makefile tritt das beschriebene auf.
Wenn du das hinkriegst, weiß ich das sehr zu schätzen! -
Dann prüfe bitte, ob bei dir "-DUSE_AUDIO_DRIFT_CORRECTION" hilft.
Johns
-
Zitat
....D und SD, einwandfrei sind, an den anderen Funktionen hab ich kein interessen: back to Basics!
Ich befuerchte leider auch , das SoftHdDevice eines Tages von DVD installiert werden musst und bei
http://distrowatch.com/ gelistet wird, wenn es so weitergeht.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!