vdrconvert: Bild und Ton laufen auseinander

Zitat

Original von Kai
Ich habe in de Zwischenzeit mal ein wenig gestöbert. In ner c't stand, daß das passieren kann, wenn die GOP nicht vollständig ist. Man müsse dann Ausgleichsframes einfügen. Wie man das aber macht, haben sie nicht geschrieben.

Gibt es denn niemanden, der für das Problem eine Lösung hat? Oder zumindest ne Idee?

Ciao

Kai

Alles anzeigen

Hi Kai,

das ist recht eingenartig, VDRsync (auf das vdrconvert ja zugreift) sollte auf jeden Fall Audio-Frames einfügen, wenn zu wenig da sind. Welche Version hast Du installiert? Nutzt Du die ct Distri? Kannst Du mal einen vdrsync-Lauf "von Hand" starten und das Log hier zum Download posten?

Dann kann ich vielleicht auch mehr dazu sagen

Cheers

Peter

Hallo Kai,

Zitat

Original von Kai
Hi Doc,

Offensichtlich hat er tatsächlich zweimal probiert, Audio-Frames einzufügen. Aber irgendwie hat er nicht genug eingefügt, der Ton hängt hinterher.

Eigenartig, kannst Du mal von Hand tcmplex aufrufen und dann checken, wieviel Audio und wieviel Video tcmplex in den Spuren findet? also so:

tcmplex -i e0.mpv -p c0.mpa -m d -o Remux.mpg

Die Video-Zeit gibt tcmplex in Sekunden an, die Audio-Zeit nur in Frames, dass musst Du mit 0.024 multiplizieren, um auf die Sekunden zu kommen.

Die Werte sollten mit denen übereinstimmen, die vdrsync angegeben hat
(also für Deinen Film 284995 Audio frames und 6839.88 sec)
Wenn nicht, dann hast Du einen Bug in vdrsync gefunden, und das Einfügen hat nicht funktioniert...

Zitat

Ich verwende Suse als Grundlage und habe den Rest von Hand gestrickt.

Die vdrsync-Version ist vdrsync-0.1.2.2

Ich habe auch SuSE (und die c't Distri), Du könntest höchstens nochmal die 0.1.22dev1 Version versuchen, die ist eigentlich genau so stabil, und in einigen Details verbessert

Cheers

Peter

Hi Kai,

Zitat

Original von Kai
Hi Doc,

ich habe jetzt tcmplex von Hand ausgeführt, Parameter wie oben, nur mit dem Unterschied, daß die Videodatei bei mir nicht e0.mpv, sondern e4.mpv heißt.

In dieser vdrsync-Version heissen die Spuren noch so, wie der Fernseh-Sender sie bezeichnet, in Zukunft heissen die video.mpv und Audio0.mpa etc.

Zitat

Das Ergebnis:

Code

<SCHNIPP>
INFO:     Total time (seconds) : 6839
INFO:     Sequence start : 14250
<SCHNIPP>
INFO:     Stream length : 164191104
INFO:     Syncwords : 285054
INFO:     Frames : 285054 size 576 bytes

Wenn ich das richtig sehe, ist der Videoteil 0,88 Sekunden kürzer als von vdrsync angegeben (oder ist das nur eine Rundung bei der Darstellung?), dafür habe ich aber 59 Audioframes mehr. Macht insgesamt (*0,024 - Wieso eigentlich?) 1,416 Sekunden mehr als erwartet oder auch 6841,3 Sekunden Audio bei 6839( ,88 ) Sekunden Video.

Jetzt stellt sich natürlich wieder die Frage, liegt das an vdrsync oder an tcmplex?

Der Unterschied im Video ist auf Runden zurückzuführen, er findet 170997 Bilder a 40 ms macht 6839.88 Sekunden, also kein Problem in der Video Spur.
Audio ist allerdings problematisch, er findet wirklich zuviel Audio - es ist 99.9 % sicher, dass es sich um einen VDRsync Bug handelt
Und zwar sieht es so aus, als hätte vdrsync die eingefügten Frames nicht mitgerechnet (genau 59 laut Deinem Log). Ich werde mir den Code anschauen, und evt. eine Testversion posten...

Cheers

Peter

Hi Kai,

Ein schneller Blick hat mir gezeigt, dass wahrscheinlich eine Zeile Code fehlt:

Füge doch nach Zeile 1201 noch folgende Zeile ein:

$self->{frames_written} += $ins_frames;

also von

else {		
	my $ins_frames = insert_frames($self, $self->{time_drift});
	my $ins_time = $ins_frames * $self->{frame_ticks};
	print "Inserted $ins_frames Audio Frames ($ins_time ticks) to correct a drift of $self->{time_drift}. EXPERIMENTAL\n";
	$self->{time_drift} -= $ins_time;
}

zu

else {		
	my $ins_frames = insert_frames($self, $self->{time_drift});
	my $ins_time = $ins_frames * $self->{frame_ticks};
	print "Inserted $ins_frames Audio Frames ($ins_time ticks) to correct a drift of $self->{time_drift}. EXPERIMENTAL\n";
	$self->{time_drift} -= $ins_time;
	$self->{frames_written} += $ins_frames;
}

Lass mich wissen, ob das geholfen hat.

Cheers

Peter

Hallo Kai,

Zitat

Original von Kai
Hi Doc,

mit der Änderung ist es etwas besser geworden, wenn auch nicht viel:

Code

#tcmplex -i e4.mpv -p c0.mpa -m d -o Remux.mpg
<SCHNIPP>
INFO:   MPEG audio stream information
INFO:     Stream length : 164169792
INFO:     Syncwords : 285017
INFO:     Frames : 285017 size 576 bytes
INFO:     Frames : 0 size 577 bytes
<SCHNIPP>

Irgendwie ist immernoch eine Sekunde zu viel.

Alles anzeigen

Jetzt wird es schwierig, ich habe keinen anderen Fehler finden können.

Wahrscheinlich würde aber ein log mit den Optionen -d und -show-time-drift helfen, das wird aber zu lang zum posten.

Am besten wäre es wenn Du ein solches log komprimiert hier anhängen oder an peter@vdr-portal.de mailen würdest.

Also

vdrsync.pl -show-time-drift -d /Pfad/Zur/Amelie/ > log_fuer_doc.txt
bzip2 log_fuer_doc.txt

Cheers

Peter

Hallo Kai,

die Log Datei sagt mir, dass in der Aufnahme 2 mal eine ganze Group Of Pictures fehlt - also je 12 Bilder. Das macht dann auch die Sekunde aus, die der Ton am Schluss daneben hängt.

VDRsync erkennt das zwar, aber repariert das noch nicht.

Das hat folgenden Grund:

- ursprünglich hat VDRsync Schnitte nur anhand von Sprüngen in den Zeitstempeln erkannt, und die dürfen bis zu 0.7 Sekunden gross sein (ohne Schnitt). Also wurden alle "Lücken" kleiner als 0.7 Sekunden nicht als Schnitt betrachtet, sondern als normale Lücke, die der Standard erlaubt (und einige Sender senden auch nur selten Zeitstempel).
- Ausserdem war die Überlegung, dass niemand 0.5 Sekunden rausschneiden würde, das macht ja wenig Sinn

In der freien Wildbahn sind dann allerdings die Probleme mit "beschädigten" Aufnahmen aufgetaucht, bei denen einfach nur ein kleines Stück Video fehlt. Also habe ich angefangen, die "Time-Shift"-Erkennung einzubauen, es wird strikt überprüft, ob die das gefundene Material mit den Zeitstempeln ünereinstimmt.

Das Ergebnis dieser Überprüfung kann man mit -show-time-drift anzeigen lassen.

Im Fall von Abweichungen in der Audio-Spur wird ein Einfügen / Löschen ausgelöst, so wie Du es auch im Log sehen kannst.

Im Fall von Abweichungen in der Video-Spur wird noch gar nichts unternommen. Das wird in einer späteren Verison eingebaut werden.

Bis dahin bleiben Dir folgende Möglichkeiten:

Du kannst in Zeile 1598 den Wert ändern, ab dem ein Schnitt erkannt wird:

if (abs($ts_shift) > 90000)

zu

if (abs($ts_shift) > 40000)

Ob das Problem dadurch gelöst wird, musst Du selber ausprobieren, theoretisch sollte an der Selle ein Schnitt erkannt und eine Sync ausgelöst werden.

Theoretisch sollte die Änderung auch für andere Aufnahmen unproblematisch sein, allerdings ist die Toleranz für "schlampige" Sender damit niedriger.

Alternativ kann Dir wahrscheinlich ProjectX oder PVAstrumento helfen.

Viel Erfolg

Peter