Audio/Video-Asynchronitäten für immer verhindern

Hi,

dann hast Du das Problem in die Aufnahme-Software verlagert, mehr nicht. Mit ein wenig "Glück" ist dann schon die Originalaufnahme asynchron

Cheers

Peter / doc

Zitat

Original von jarny
Hää!!

Dir auch Hallo...

Zitat

Hab ich jetzt was falsch verstanden? Was ist den beim VDR die 'Aufnahmesoftware'? Meinst du damit die Unterroutinen im VDR die die Audio/Video-Pakete auf die Platte schreiben?
Ich hab mich jedenfalls noch nicht mit den Sourcen des VDRs beschäftigt und werde wahrscheinlich in absehbarer Zeit auch nicht dazu kommen aber ich sehe in diesem Zusammenhang den VDR als eine 'Einheit' (intern mag er ja bestimmt modular aufgebaut sein) sprich VDR ist dafür verantwortlich was er auf die Platte schreibt. Und genau in diesem Programmteil müsste man die Sysnchronisationsroutinen einbauen.
Erklär doch mal was du mit Originalaufnahme und Aufnahmesoftware meinst!

Die Originalaufnahme ist für mich das, was ich als User als erstes anschauen / manipulieren kann, also die Daten, wie sie bei einer Aufnahme auf der Platte landen.
Die Aufnahmesoftware ist für mich das Programm, welches die Original-Daten aus der DVB-Karte filtert, und in einem definierten Format auf die Platte schreibt (also beim VDR schon mal mindestens die Konvertierung vom MPEG-TS in einen MPEG-PS durch das Programm VDR). An dieser Stelle möchtest Du eingreifen und Fehler in der Aufnahme korrigieren, wenn ich Dich richtig verstanden habe.
Damit habe ich dann den Datenstrom nicht mehr gefiltert und aufgezeichnet, sondern gefiltert, verändert und aufgezeichnet. In meinen Augen also die Originalaufnahme verändert, aber das kann man sicher auch anders/besser nennen. Wenn die Software da einen Fehler macht, dann ist die Aufnahme nicht mehr synchron (siehe unten).

Die Synchronisation in der Original Aufnahme ist übrigens 100% ok (wenn die Sender keinen Mist bauen), da muss man nicht korrigieren. Schliesslich ist das Format dafür gedacht, fehlende Daten zu akzeptieren.

Das Problem mit der Synchronisation kommt ja erst dadurch zustande, dass Du das Format ändern willst. Und dabei gehen eben die Timing Infos verloren. Die hast Du aber genau wie der VDR am Anfang des Konvertierungsvorgangs zur Verfügung, wenn die nicht in der Aufnahme drinstecken würden, dann könntest Du die Aufnahme auch nicht mehr synchron abspielen. Also hat die Aufnahmensoftware genauso viel oder wenig Infos über die Sync wie ein Konvertierungsprogramm auch. Was soll Aufnahmesoftware (also der VDR) also anders machen? Sie könnte es besser machen, aber das könnten die Konvertierungsprogramme ja auch.

Cheers

Peter / doc

Zitat

PS: Oh, ich seh grad was in deiner Sig. Du hast da ein Projekt am laufen, was sich genau damit beschäftigt. Wie ich sehe wird da natürlich auch wieder versucht die schon asynchronen Daten von der Festplatte zu synchronisieren.

Da ist ein Denkfehler, die Daten auf der Platte sind 100 %ig synchron. Siehe oben

Zitat

Wäre es nicht besser wenn man die Daten schon kurz vor dem Abspeichern synchronisiert wie in meinem ersten Post beschrieben, so dass dieser Schritt bei allen Projekten die sich mit dem Nachbearbeiten der Videodaten befassen schon erledigt ist.

Wie gesagt, das ist eine Konvertierung mit Ihren ganz eigenen Problemen... Die daten, die VDRsync rauspuckt, sollen mal von allen anderen Programmen geschluckt werden.

Ausserdem, warum gleich konvertieren, wenn Du die Daten gar nicht weiterverarbeiten willst, sondern nur anschauen? Dann brauchst Du plötzlich eine andere Hardwareaustattung für Deine Box, das fände ich nicht so lustig. Lieber mit einer (leisen) langsamen Kiste aufnehmen und mit einer (lauten) schnellen Kiste konvertieren, und zwar nur das, was ich konvertieren will.

Cheers

Peter

Es gab auch schon asychrone Aufnahmen die aber auf fehlerhafte Treiber zurückzuführen waren.

Das Hauptproblem ist nicht die Aufnahme sondern wie Doc schon sagte das anschliessende Konvertieren in andere Formate.

Hi jarny,

Zitat

Original von jarny
Hallo Doc

Ich hatte vermutet (weil ich es nicht besser weiß), dass der VDR die Daten in einem TS-ähnlichen Format wie zB. das PVA-Format auf die Festplatte schreibt. In diesem Format stecken die Synchronisationsinformationen noch drin. Das würde aber deiner obigen Aussage wiedersprechen.

Im MPEG-PS sind sie auch noch drin (s.u.)

Zitat

Wie kommen Asynchronitäten eigentlich dann zustande? Ich stell mir einen Grund zB so vor:
Durch äußere Einflüsse (schlechte Witterung, ein Vogel fliegt direkt vor den LNB etc.) geht mal zufällig ein Video- oder Audioframe verloren. Je nach Empfangslage kann das wahrscheinlich zigmal pro Stunde auftreten und der Ton würde dann gegen Ende des Films zB. ne halbe Sekunde nachhängen. Deshalb (und aus anderen Gründen) besitzen die TS-Daten ja die Timestamps, damit man feststellen kann ob ein Frame verloren gegangen ist.

Nicht nur deshalb, sonst hätte ich ja als Kabel-Nutzer das Problem niemals Audio und Video werden schon gegeneinander "versetzt" ausgeestrahlt, Audio läuft fast immer ca 250 ms nach. Weitere Fehler habe ich so gut wie nie...

Zitat

Bei der Umwandlung in ein 'normales' Mpeg2-File (ohne Sync-Informationen) hat man doch lediglich die Chance die fehlenden Frames intelligent zu ersetzen bzw. die überzähligen Frames zu entfernen. Das resultierende File ist dann nach diesen Maßnahmen synchron, obwohl keine Synchronisationsinformationen im File vorhanden sind.

"Normales" MPEG2 ist ein bisschen schwer zu definieren:

MPEG-ES (Elementary Stream): Nur Video oder nur Audio, nicht in Packete gepackt, keine Syncinfo
MPEG-PES (Packetized elementary stream): Der obige Stream in Pakete verpackt mit Zeitstempel zur Sync versehen
MPEG-PS (Program Stream): Multiplexen von 2 PES-Streams, enthält alle Video und Audio-PES eines Kanals. Timing via PTS-Zeitstempeln in den PES-Packet-Headern
MPEG-TS (Transport Stream): Mehre PS-Streams werden nochmals zerhackt, mit neuen (TS)Headern versehen und in 188 Byte Schnippseln in einen Transport Stream multiplext.

Alle Formate sind gültig und "normal".
Programme verarbeiten (wenn sie MPEG2 können) immer ES, meist auch PS. Aber nicht unbedingt das PS vom VDR, da scheint noch ein Header oder was anderes zu fehlen, da habe ich keine Ahnung warum. Evt könnte ein kleines "header generation Tool" das Problem lösen.

Zitat

Vorteil dieser 'normalen' Mpeg-Files ist, dass so ziemlich jedes Programm damit umgehen kann (ja sogar der Hardwaredekoder auf der DVB-Karte kann sie abspielen)

Prinzipiell geb ich dir Recht. Aber ich sehe die oben beschriebene Fehlerkorrektur (= Synchronisation) nicht als Veränderung an, obwohl es richtigerweise eine ist.

Ich glaube es ist kein Denkfehler, sondern ein Definitionsfehler. Wenn die Frames in den Dateien schon fehlen aber durch die Timestamps ersichtlich ist, dass sie fehlen, dann ist das nach deiner Definition 100% synchron. Leider sehen das die ganzen Programme nicht so, sonst hätte ja niemand ein Problem damit.

Alles anzeigen

Die Programme, die WIRKLICH PS einlesen können, sehen das auch so (transcode, das kommt aber wiederum nicht mit "halben" Audioframes zurecht, so wie sie manchmal an Schnitten vorkommen). Viele Programme verstehen PS aber nicht wirklich, sie können nur demuxen ohne Korrektur. x und vdrsync versuchen einen demux mit Korrektur (Ergebnis ist ES)

Zitat

Ich vertrete die Meinung, dass so ziemlich alle Programme (die irgendwas mit der Verarbeitung von Videodaten zu tun haben) normale Mpeg-Files einlesen können

s.o.

Zitat

und nur ganz wenige können TS-Streams einlesen (und dann ignorieren sie mit Sicherheit noch die Timestamp-Informationen). Wieso soll man denn alle anderen Programme an den VDR anpassen wenns doch ein Format gibt was alle verarbeiten können? Das schränkt doch die freie Programmwahl nur unnötig ein.

Ein einfacher Vergleich der Timestamps genügt doch im Prinzip um festzustellen, ob ein Audio- oder Videoframe verloren gegangen ist.
Da muss man sich halt ein paar Frames in einem Memorypuffer halten und diese entweder verwerfen (also gar nicht erst auf Platte speichern) oder Duplizieren (Mehrfach speichern) oder Stille einfügen (vorgefertigtes Frame auf die Platte speichern)
So richtig viel Rechenzeit kann das nicht kosten. Man sieht ja auch wie schnell die 'externen' Korrekturprogramme das erledigen. Dabei geht wohl die meiste Zeit drauf um das File von Platte in den Hauptspeicher zu laden und später wieder zurück. Das sind bei Files jenseits der 2GByte natürlich schon einige Minuten ohne jegliche Manipulation des Datenstroms mitgerechnet.

In meiner Sichtweise ist das auch keine echte Konvertierung (es ist und bleibt ja alles noch Mpeg2 mit gleicher Bitrate etc.). Es wird lediglich an der Verpackung etwas geändert und Fehler behoben. Konvertieren ist bei mir was anderes.

Ich hab mir dein Projekt noch nicht angeschaut, weil ich wenig Ahnung von Linux habe und der VDR bei mir erst seit ein paar Tagen zum Testen läuft (und das auf ner absoluten Hasenkiste = 233Mhz P1, 256MB, 4.3GB Platte !!!)
Du kannst das alles natürlich besser einschätzen, weil du in der Materie drinsteckst. Wenn durch die on-the-fly-Fehlerkorrektur natürlich so viel Rechenpower nötig wäre dass man keine leisen Kisten mehr aufstellen kann, dann wäre das nicht praktikabel.

Die Traumlösung wäre folgendes:
Im VDR gibts eine Einstellung: Videoformat (vdr / mpg2)
und dort kann man dann auswählen, ob man die jetzige Methode zum Speichern der Aufnahme möchte (Einstellung: vdr) oder ob man ein fehlerkorrigiertes mpg2-File (Einstellung mpg2) auf der Platte haben möchte.

Gruß
Jarny

Alles anzeigen

Ist alles machbar, aber mit viel Aufwand versehen. Was Du nicht berücksichtigst:
Manche Sender strahlen auf 3600 Sekunden Video 36001 Sekunden Audio aus. Wo verwirfst Du Frames (die 32 ms lang sind), um zu syncen? VDRsync macht das ab einer bestimmten Abweichung (48 ms), aber evt produzierst Du einen hörbaren "Drop". Das will ich in meiner Aufnahme nicht haben, in meiner konvertierten Aufnahme kann ich da nichts machen (ohne den gesamten Stream auszupacken und neu zu konvertieren).

Wenn Du ein neues Packet einschieben willst, dann bitte peinlich genau den Zeitstempel berechnen! Und darauf achten, das der Unterschied in den benachbarten Paketen nicht zu gross wird etc,pp. In einen Livestream was reinzupacken ist nicht trivial...

Der Player gibt in einem solchen Fall einfach ein wenig "Gas", und spielt Audio minimal schneller ab, bis es wieder stimmt.

Der Rechen-Aufwand für eine Realtime Konvertierung ist tatsächlich nicht so gross, jenachdem, wie man das anpackt...
Wen man allerdings wirklich sauber arbeiten will, dann kommt man um eine Dekodierung, Korrektur und Neukodierung des Audiostreams nicht herum. (macht aber weder x noch vdrsync).

Das solls mal für mich zu dem Thema gewesen sein, wenn Du einen Patch für den VDR rausschiebst, der das Problem löst, dann lass' es mich wissen Dann stelle ich sofort die Entwicklung von VDRsync ein

Beste Grüsse

Peter / doc