Dann liegt es nicht am Softlimit.
Mit "15 * 20 * 90" erzwinge ich 15 Videoframes a 20ms Puffer für das Video.
Das sind ca. 300ms. Damit werden die Videodecoder gefüllt, ohne diesen
Versatz sind die Videopuffer zuhäufig leer gelaufen. Der Start über die
Anzahl der Videopuffer hat nicht zuverlässig funktioniert. Was ja bei Aufnahmen
schnell gegangen wäre.
Dann müssten aber "0 * 20 * 90" vernünftig funktionieren.
Ich muß doch noch einbauen, wenn die Videopuffer zu leer sind, der Ton knackst.
Johns
Dann müssten aber "0 * 20 * 90" vernünftig funktionieren.
Upps? Da hast du sicher was anderes gemeint.
Gerald
Man hätte auch einfach "0" schreiben können oder ganz weglassen.
Wenn Ton genau richtig startet, dann sollte auch Video richtig starten.
Johns
Man hätte auch einfach "0" schreiben können oder ganz weglassen.
Ach so, das hatte mich verwirrt, sorry,
Gerald
Das verstehe ich nicht, man müsste mit 0 Video und Audio im Sync haben.
Mir ist aufgefallen das bei einigen (fast allen) Sendern die Audio Daten vor
den Video Daten kommen. Damit ich dann Video sofort losläuft, überspringe
ich diese Audiodaten.
Mit -DDEBUG sollte eigentlich alle wichtigen Informationen im Syslog stehen.
Um Wiedergabe zuerkennen:
int Poll(int timeout) wird nur bei Aufnahmen und DVD Wiedergabe aufgerufen.
Dort setze ich bereits das Flag "VideoClearClose", damit bei der Wiedergabe
die Sprünge nicht nachlaufen.
Das könntest du verwenden. (Mußt es natürlich erstmal global verfügbar machen).
Johns
Bei den speed up / slow down Messages siehe: [Softhddevice] cant'render mixer: An invalid handle value was provided
gibts auch einen Patch im Thread.
Ich habe ein Audio/Video Sync Fenster von -15 - 45ms = 60ms.
Scheinbar gibt es in der Verarbeitungskette doch größere Schankungen.
Meine Vermutung ist immer noch, daß wenn der Wert Y in "XX+Y v-buf" schwankt,
ein Rechenfehler vorliegt. Schwankungen von Y sollten den A/V Sync nicht verändern.
Johns
Stimmt, warum hat der dann funktioniert?
s/15 * 90/35 * 90/
s/45 * 90/65 * 90/
in video.c ergibt 40ms größeres Zeitfenster. Je nach A/V Sync Vorlieben auch nur eins oder größere Werte.
Johns
@ johns:
ich habe hier eine durchgehende, ungeschnittene Aufzeichnung auf Platte, die zwei Sendungen (deutschspachige Reportagen, keine Synchronisation) enthält. Das erste ist leicht asynchron, und zwar sowohl beim Stereo- als auch ac3-Ton. Bei der anschließenden zweiten Sendung stimmt dann die Synchronität wieder. Ich glaube allerdings nicht, dass die erste Sendung tatsächlich so asynchron ausgestrahlt wurde.
Das ist kein grundsätzliches Problem von softhddevice, denn mit dem xine-Plugin hatte ich sowas früher auch. Manche Sendungen waren aufs Verrecken nicht synchron abspielbar.
Was machen kommerzielle Geräte da anders, die dieses Problem nicht haben?
Kann ich hier auch bestätigen.
@ johns:
ich habe hier eine durchgehende, ungeschnittene Aufzeichnung auf Platte, die zwei Sendungen (deutschspachige Reportagen, keine Synchronisation) enthält. Das erste ist leicht asynchron, und zwar sowohl beim Stereo- als auch ac3-Ton. Bei der anschließenden zweiten Sendung stimmt dann die Synchronität wieder. Ich glaube allerdings nicht, dass die erste Sendung tatsächlich so asynchron ausgestrahlt wurde.
Das ist kein grundsätzliches Problem von softhddevice, denn mit dem xine-Plugin hatte ich sowas früher auch. Manche Sendungen waren aufs Verrecken nicht synchron abspielbar.
Was machen kommerzielle Geräte da anders, die dieses Problem nicht haben?
Das Problem geht schon damit los, daß ffmpeg/libav überhaupt keine gescheiten Timestamps (Zeitstempel) liefert.
Siehe AV_INFO: "/\ 240ms". Hier schwanken die Timestamps schon 240ms. Habe auch schon Logs mit 540ms gesehen.
Wobei bei den 720p Sendern diese nicht vorhanden sind.
Schau mal ins Log ob dir bei den AV_INFO Ausgaben etwas auffällt.
Wobei natürlich Stereo und AC-3 verschiedene Verzögerungen benötigen können.
Sollte dies identisch sein. Dann könnte die Verzögerung generell schon etwas danebenliegen
und nur bei der einen Sendung verstärkt auffallen.
Und dann gibts immer die lieben Sender, die schon sowas einfaches kaputt bekommen.
Johns
Soweit ich das schon sagen kann, ist es mit dem von -15/45 auf -35/65 vergrösserten Regelinterval deutlich besser!
Diese Regelschleife sollte es gar nicht geben.
Wenn der Bereich verlassen wird, dann sollte sich nur eine Veränderung um 20ms (50hz) ergeben.
Und selbst wenn es jetzt 1 Frame (20ms) irgendwo hängen bleibt sollte noch genug Reserve vorhanden sein.
Johns
ZitatSchau mal ins Log ob dir bei den AV_INFO Ausgaben etwas auffällt.
Wobei natürlich Stereo und AC-3 verschiedene Verzögerungen benötigen können.
Sollte dies identisch sein. Dann könnte die Verzögerung generell schon etwas danebenliegen
und nur bei der einen Sendung verstärkt auffallen.
Und dann gibts immer die lieben Sender, die schon sowas einfaches kaputt bekommen.
das sieht völlig normal aus:
Dec 25 23:53:43 ubuntuvdr1 vdr: [1156] [softhddev]SetPlayMode: 1
Dec 25 23:53:43 ubuntuvdr1 vdr: [2590] dvbplayer thread started (pid=1156, tid=2590)
Dec 25 23:53:43 ubuntuvdr1 vdr: [2590] resuming replay at index 32280 (0:21:31.06)
Dec 25 23:53:43 ubuntuvdr1 vdr: [2591] non blocking file reader thread started (pid=1156, tid=2591)
Dec 25 23:53:43 ubuntuvdr1 vdr: audio/alsa: using device 'default'
Dec 25 23:53:43 ubuntuvdr1 vdr: codec: buggy ffmpeg/libav
Dec 25 23:53:43 ubuntuvdr1 vdr: audio/alsa: start delay 336ms
Dec 25 23:53:43 ubuntuvdr1 vdr: audio/alsa: using ac3 device 'default'
Dec 25 23:53:43 ubuntuvdr1 vdr: audio/alsa: start delay 336ms
Dec 25 23:54:19 ubuntuvdr1 vdr: [2591] non blocking file reader thread ended (pid=1156, tid=2591)
Dec 25 23:54:19 ubuntuvdr1 vdr: [2590] dvbplayer thread ended (pid=1156, tid=2590)wenn ich diese Sendung durch Project X jage, wird dort festgestellt:
--> AC-3/DTS Audio on PID 0x132
-> check CRC of AC-3 / MPEG-Audio L1,2
-> delete CRC in MPEG-Audio Layer1,2
-> add frames
Audio PTS: first packet 08:00:03.705, last packet 08:25:10.777
Video PTS: start 1.GOP 08:00:07.198, end last GOP 08:25:09.398
-> adjusting audio at video-timeline
-> src_audio: AC-3, CM, 2/0(2.0), dn -22dB, 48000Hz, 448kbps @ 00:00:00.000
!> missing syncword @ 82274305, @ 00:24:25.696
!> found syncword @ 82276320
!> missing syncword @ 82500321, @ 00:24:29.024
!> found syncword @ 82500816
!> 1 frame(s) (32ms) inserted @ 00:24:29.088
audio frames: wri/pre/skip/ins/add 46894/0/0/1/0 @ 00:25:00.608 done...
---> new File: '/video/DVD/demux/[0]/00001.ac3'32ms ist nicht viel, und es wundert mich, dass ich das überhaupt so deutlich wahrgenommnen habe. Es gibt hier aber einen Unterschied zur nächsten Sendung in gleichem ts-Aufnahmefile, die lippensynchron war:
Man beachte, dass hier "inserted" wurde.
Bei der lippensynchron abgespielten 2. Sendung ist die Differenz viel größer, jedoch werden hier die Frames am Ende angefügt ('added'):
--> AC-3/DTS Audio on PID 0x132
-> check CRC of AC-3 / MPEG-Audio L1,2
-> delete CRC in MPEG-Audio Layer1,2
-> add frames
Audio PTS: first packet 08:30:31.289, last packet 08:44:58.617
Video PTS: start 1.GOP 08:30:34.438, end last GOP 08:44:59.438
-> adjusting audio at video-timeline
-> src_audio: AC-3, CM, 2/0(2.0), dn -22dB, 48000Hz, 448kbps @ 00:00:00.000
!> 17 frame(s) (544ms) added @ 00:14:24.448
audio frames: wri/pre/skip/ins/add 27031/0/0/0/17 @ 00:14:24.992 done...
---> new File: '/video/DVD/demux/[0]/00001.ac3'Zitat
Das Problem geht schon damit los, daß ffmpeg/libav überhaupt keine gescheiten Timestamps (Zeitstempel) liefert.
ist das den Entwicklern bekannt bzw. gibt es einen offenen Bugreport?
In deinem Log sind keine AV_INFO Einträge:
Dec 26 02:25:27 i3-530 vdr: video: 20:29:03.042 +31 1123 0/\ms 85+6 v-buf
Dec 26 02:26:27 i3-530 vdr: video: slow down video, duping frame
Dec 26 02:26:27 i3-530 vdr: video: 20:30:03.022 +11 1091 0/\ms 77+7 v-bufDie +31 bzw +11 sind der aktuelle A/V Abstand,
Die +6 v-buf bzw. +7 v-buf sind die aktuelle Anzahl der Videoframes im Ausgabepuffer.
Bei unterschiedlichen Frames, könnte der A/V Abstand nicht passen.
Siehe oben, dort wird eine Frame verdoppelt obwohl es nicht nötig ist.
Was Project X da repariert ist der Abstand von Video + Audio im Stream.
Dies gleiche ich durch Video und Audio Puffer aus und halte so einen "konstanten"
Ton-Bild Abstand.
Intressant ist, daß dies scheinbar schon so vom Sender kommt.
Ich habe mich schon über vereinzelte Tonaussetzer gewundert.
Zitat
ist das den Entwicklern bekannt bzw. gibt es einen offenen Bugreport?
Ich habe es aktuell nicht verfolgt, aber in der Vergangenheit gab es hier
viele Veränderungen.
FFmpeg unterstützt best_effort_timestamp welche vielleicht ein gutes
Ergebnis liefern. Nur wurde dies nicht von libav unterstützt und ich
habe es deshalb nicht verwendet.
Wie man es aktuell am Besten verwendet sieht man im ffplay Code.
Im obigen Log siehst du "0/\ms", was bedeutet das die PTS 0 ms schwanken
und somit hier keine Fehlerquelle vorhanden sein kann.
Johns
In deinem Log sind keine AV_INFO Einträge
hätte ich dazu noch irgendeine Option aktivieren müssen, oder zeigt das Fehlen, dass das Plugin nichts zum Loggen gefunden hat? Die von Dir geposteten Infomeldungen kenne ich ansonsten; bei Live-TV sind sie auch präsent. Nicht aber beim Abspielen dieser Aufnahme.
ZitatWas Project X da repariert ist der Abstand von Video + Audio im Stream.
Dies gleiche ich durch Video und Audio Puffer aus und halte so einen "konstanten"
Ton-Bild Abstand.
wenn ich es richtig verstehe, ist der Puffer aber ein fixer Wert, während der Abstand aber variabel ist und vom Sender bzw. der einzelnen Sendung abhängt:
ZitatIntressant ist, daß dies scheinbar schon so vom Sender kommt.
Ich habe mich schon über vereinzelte Tonaussetzer gewundert.
Siehst Du denn keine Möglichkeit, sowas im Plugin zu erkennen und zu berücksichtigen?
Nur wurde dies nicht von libav unterstützt und ich
habe es deshalb nicht verwendet.
Du könntest den Support für libav entfernen und allen Ubuntu-Leuten die Empfehlung von FFmpeg weitergeben. Und zwar soll diese Repo Abhilfe schaffen https://launchpad.net/~jon-severinsson/+archive/ffmpeg
Siehe auch: http://ffmpeg.org/download.html
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!