VDRsync Problemfälle gesucht! (und neue Developer-Version)

Hallo,

ich habe auf http://vdrsync.vdr-portal.de/developer.html

die nächste Developer-Version von vdrsync veröffentlicht.

Bevor ich daraus aber eine offizielle Version mache, möchte ich versuchen, die Fehlerkorrektur bei beschädigten Aufnahmen zu verbessern, ähem, einzubauen ;).

Dazu brauche ich eure Hilfe! Bitte schickt mir Schnippsel von Aufnahmen, bei denen VDRsync versagt. Dabei ist es egal, ob VDRsync ganz aussteigt, oder einfach die Audio/Video-Sync nicht stimmt.

Ich brauche meist nur ca 1 MB, um herauszubekommen, woran es liegt. Dazu muss aber der Fehler in diesem MB liegen. Wenn Ihr also die Stelle findet, ab der es schief geht (oft nach einer Bildstörung), dann schneidet doch bitte kurz vor und kurz nach der Stelle, und schickt den Schnippsel an

peter@vdr-portal.de

Wenn Ihr wollt, dann könnt Ihr mir auch gerne CDs mit Fehler-Schnippseln schicken (einfach vorher eine PM an mich).

Wenn Ihr fleissig Schnippsel schickt, dann stehen die Chancen nicht schlecht, dass ich auch was Vernünftiges auf die Beine bekomme (toitoitoi ;)).

Schon mal vielen Dank für die Mithilfe, und hier noch das Change-log der neuen Developer-Version:

Zitat

Finally a new development release (NOTE: THIS VERSION WILL NOT WORK WITH VDRCONVERT)

This time the changes focused on postprocessing options like DVD-creation.
There are again too many changes to describe them all (and I can not even remember
all), but the main improvements are (IMHO):

- Addition of the dvd-menu.pl script, that allows the creation of a DVD directory
structure with Menus, user supplied text and backgrounds etc pp. The script can also
be used without VDRsync, more info at http://vdrsync.vdr-portal.de/

- Addition of the (very ugly) vdrsync_buffer.pl helper script.
This script just takes input from STDIN and buffers up to 10 MB, pipes it out to STDOUT,
or a user supplied FIFO or file. It is used for the

on-the-fly conversion of recordings to a DVD-Structure

It is ugly, uses perl threads, and my very first attempt to write something threaded.
If you are a real programmer, please write something better and sent it to me
But: it works for me. So now you are able to convert a recording (including cutting)
straight into a DVD, no temp files, optional requanting is possible (see below). Used
when you add the option "-use-pipe".

- You can cut your recording according to a marks.vdr while processing it with VDRsync

- You can feed input via STDIN to vdrsync (-stdin). Together with the -use-pipe option
we might get close to a "realtime" conversion, at least to mpeg2 (just imagine a
streaming client piping the PS to vdrsync. This, however, does not work yet.

Ok, that are the main things. Other changes:

- it is possible to specify more than one directory on the command line
when creating a DVD. vdrsync will then create a DVD that contains every directory
as a title set. If you specify the -dvd-menu switch, you will even have Menus with
summaries etc

- it is possible to shrink the recording(s) to fit to a single DVD by
adding -fit-to-dvd option. This works also for multiple recordings on the command line

- added the possibility to generate a file that contains the main recording stats.
This might be very handy for scripting, when you call vdrsync with
-script-output=vdrsync_logfile.txt
You can simple retrieve the name=value pairs from that file.

- Switch to mplex as a default multiplexer. First of all, it accepts FIFOs as input
(I needed that for the -use-pipe Option). Second, it does not scan the Input before
starting, saving quite a bit of time. Third, it should accept Audio-Tracks that change
format in the middle of the recording. This has not been used yet, but it is something
to integrate in the future. Moreover, mplex can (must) split the output in smaller files,
which allows some other fine things (vdrrequant like cutting/shrinking in a single run)
Probably I forgot half of the changes, but this information should get you started
(at least you know what to look for...)

Have a look at the Usage Message you get when you start VDRsync without a parameter.

Alles anzeigen

Cheers

Peter

Zitat

Original von MarkusE
Hallo,

warum arbeitet die neue Version nicht mit Vdrconvert zusammen ?
Kann man das irgendwie hinkriegen, daß die zusammenarbeiten ?

Nach dem Changelog kann Vdrsync nun sehr vieles, was vorher nur Vdrconvert konnte. Ist die Idee, in Zukunft ganz auf Vdrconvert verzichten zu können ? Dazu fehlt IMHO im wesentlichen noch ein User Interface für den VDR, mit dem ich ein oder mehrere Aufzeichnungen auswählen, die Auswhl anschauen und ändern und dann das Erzeugen des Images starten kann.

Markus

Alles anzeigen

Hallo Markus,

diese Version arbeitet nicht mit vdrconvert, weil sich die Menge der Status-Meldungen drastisch reduziert hat und vdrconvert noch die ursprünglich Menge an Meldungen erwartet, um zB Informationen über die Aufnahme zu extrahieren.

Eigentlich sind alle diese Informationen sauberer erhältlich, wenn man die Option
-script-output
verwendet, aber (so weit ich weiss) ist vdrconvert noch nicht daran angepasst.

Es wird beim vollen Release wieder einen vdrconvert-Modus geben, damit man auch die nächste Version von VDRsync mit vdrconvert verwenden kann.

Was das Ersetzen von vdrconvert durch vdrsync angeht:
Es ist nicht mein Ziel, vdrconvert Konkurrenz zu machen, sondern die komplette Verabreitung von VDR-Aufnahmen unabhängig vom VDR (also auf einem anderen Rechner) zu gestatten. Dazu wir es dann auch irgendwann mal ein GUI geben, in dem man Schnittmarken setzen, DVD Menüs definieren und anderes tun kann. Soweit bin ich aber noch nicht.

Natürlich kann man auch die nächste Version gleich in den VDR integrieren, das werde ich persönlich für mich tun, und so ist es auch bei linvdr gelöst. Beispiele für die reccmds.conf und solche Dinge stehen auch auf meiner TODO Liste.

Wie vdrconvert weiter entwickelt wird, liegt natürlich bei Dimitri.

Cheers

Peter

Hallo Frank, Django, alle:

Vielen Dank für die Rückmeldungen, ich hatte schon befürchtet, dass niemand was schickt.

@ Frank: Ich habe Dir vorhin zurückgemailt, schon mal vielen Dank für das Log.

@ Django: Dem User ist es meist egal, ob er einem VDRsync Bug aufsitzt, oder ob er einen Fehler in der Aufnahme hat Deshalb möchte ich ja die Fehlerkorrektur für defekte Aufnahmen einbauen. Deine Logs sehen recht typisch für eine kleine Störung in der Aufnahme aus, und es wäre doch prima, wenn vdrsync die einfach ausbügeln würde Falls Du also das Original noch haben solltest, so wäre es super, wenn Du einfach nochmals vdrsync anwerfen könntest, und zwar mit der Option

-dump-debug-buffer

Theoretisch sollte dann eine Datei debug.buffer im aktuellen Verzeichnis abgelegt werden, die genau die Stelle enthält, an der VDRsync gescheitert ist. Diese Datei hätte ich gern

Mittlerweile habe ich mir auch eine neue Sync-Startegie ausgedacht, und zum ersten Mal bin ich mit der Idee gut zufrieden. Die ersten Schritte habe ich auch schon programmiert, aber es bleibt natürlich auch noch genug zu tun.

Und dann hoffe ich noch auf viele Testschnippsel, damit ich dann den neuen Versuch auch ordentlich testen kann

Cheers

Peter

Hi Reinhard,

die einfachste Lösung ist wahrscheinlich, die Datei zu splitten:

split  -b 780k 001.vdr split_

ergibt die Dateien split_aa, split_ab, split_ac....,. jede 780 kByte gross. Die kannst Du dann mailen und ich kann sie per "cat" wieder zusammensetzen.

Vielen Dank schon mal für die Daten

Beste Grüsse

Peter

Zitat

Original von metrio
Hi Doc,

wäre es eigentich ein Problem, beim schneiden/syncen gleich ein indexfile zu generieren und evtl. auch die Schnittmarken zu übernehmen, so dass man das im vdr ganz normal abspielen könnte?

Innerhalb von vdrsync müsstest du wenn ich das richtig sehe, das file schon vor dem multiplexen generieren. Hört sich so auf den ersten Blick nicht gerade trivial an. Am besten wäre es wohl, wenn der multiplexer das könnte?

Hi Metrio,

eigentlich denke ich nicht, dass es ein so grosses Problem wäre, ich habe allerdings die Threads nicht so genau verfolgt, in denen beschrieben wird, wie man ein MPEG2 wieder abspielbar macht.

Ein Schnelltest jetzt gerade war nicht sehr erfolgreich, weil genindex die MPEGs nicht akzeptiert hat.

Im Prinzip muss nach dem Multiplexer einfach das MPEG File gescannt werden, und zwar auf Picture-Start Flags im Video-Stream. Die Dateinummer und der Picture-Type sowie der Offset landen dann in der index.vdr. Weil man aber denn Offset braucht, geht es nur nach dem multiplexen (oder man piped die Ausgabe von mplex gleich durch eine Art "genindex").

Was mir an der Idee gefällt, ist, dass alles komplett "on-the-fly" gehen könnte. Damit kommt dann auch die andere Idee wieder ins Spiel, nämlich einen Streamdev Client für vdrsync zu schreiben; dann kann man gleich in DVD-Kompatiblem MPEG2 aufzeichnen, und der VDR kann es trotzdem abspielen

Das ist zwar noch Zukunftsmusik, aber wenn Du einen Link für mich hättest, wie man MPEG2 wieder für den VDR zugänglich machen kann, dann wären wir schon einen Schritt weiter.

Achja, eine marks.vdr muss mann nicht generieren, wenn ich mich recht erinnere, und nach dem multiplexen würde die auch nicht mehr stimmen

Cheers

Peter

Hallo,

erstmal noch ein herzliches Dankeschön für eure Problem-Aufnahme-Schnippsel.
Ich bin endlich soweit, dass alle bei mir durchlaufen. Das heisst aber noch
nicht so wahnsinnig viel, da einige von Anfang an durchliefen(?).

Wie dem auch sei, ich habe so ziemlich die gesamte Sync Engine ausgetauscht,
mir mal wieder 1000 Knoten im Kopf gemacht und wahrscheinlich doch wieder das
ein oder andere vergessen. Das Ergebnis habe ich unten angehängt.

Nun wäre es natürlich klasse, wenn ihr die Version testen könntet, und zwar an
Problem-Aufnahmen. Insbesondere unsauber geschnittene Aufnahmen und Aufnahmen
mit Bildstörungen sind interessant, wenn sie vorher unsynchron waren.

Die Änderungen im Detail (so weit ich mich erinnere):

Ich habe die Sync Engine komplett umgeschrieben, so dass sie jetzt alle 1.5
Sekunden einfach folgendes überprüft: Beim aktuellen Zeitstempel im
Video-Strom wurden XY Bilder gefunden, das entspricht YZ Sekunden. Nun wird
in jedem Audio-Strom überprüft, ob ebenfalls an dem entsprechenden
Zeitstempel YZ Sekunden Audio vorliegen. Wenn nicht, dann wird das
korrigiert. Damit sollte theoretisch innert kurzer Zeit auch jede
Verschiebung ausgeglichen werden, die durch Fehler im Video-Strom zustande
kommt. Theoretisch ist also gar kein Murks mehr möglich – theoretisch
wohlgemerkt.

Ausserdem wurden viele Bedingungen, die zum Abbruch geführt haben, entschärft:
Es gibt ein Konto mit Kill-Punkten für jeden Audio-Strom. Bei einem Fehler
gibt es 10 Punkte, bei jedem erfolgreichen Lauf wird ein Punkt abgezogen
(also max 1 Punkt alle 1.5 Sekunden). Werden 100 Punkte erreicht, wird der
Strom gelöscht (so wie bisher). Mit dem System kann man sehr viel besser
sicherstellen, das am Ende kein Müll auf der Platte steht, und dass trotzdem
ein kleiner Fehler (wie ein Audio-Puffer Leerlauf) nicht gleich zum Abbruch
führt.

Schliesslich ist das Ding schon wieder 10-20 Prozent schneller geworden,
allerdings merkt man das nur mit einer schnellen Festplatte. Die
Beschleunigung kommt dadurch zustande, dass jetzt nicht mehr für jedes Paket
eine Sub-Routine angesprungen wird, sondern die Auswertung des Video-Stroms
und das Puffern der Audio-Daten schon in der Hauptschleife stattfindet.

Last but not least: Der Schnittcode wurde so verändert, dass beim Schneiden
mit VDRsync zusätzliches Audiomaterial im Puffer landet – Dank an Patrick
Cernko für den Tipp. Das heisst, dass an Schnittstellen kein „Audio-Loch“
mehr entsteht, sondern tatsächlich das original Audiomaterial Verwendung
findet. Im Ergebnis kann ich bei den bisher verarbeiteten Aufnahmen die
Schnittstellen auf einer DVD nicht mehr wahrnehmen. Finde ich persönlich
superklasse.

Die Hilfs-Skripte vdrsync_buffer.pl und dvd-menu.pl sind bisher unverändert,
da wird sich aber im dvd-menu Teil auch noch was tun.

Ich freu' mich auf Feedback

Beste Grüsse

Peter

Hallo Saalam,

Zitat

Original von salaam
Danke erst mal, für Deine grandiose Arbeit.

Danke

Zitat

Läuft diese Version jetzt wieder mit den vdrconvert Skripten ?
Wenn nicht, warum denn ?

Danke.

Salaam

vdrconvert steht als nächstes an. Ich bin nicht so glücklich über die Art und Weise, wie vdrconvert die Ausgabe von VDrsync auswertet.

Ursprünglich war die Ausgabe chaotisch, und Dimitri musste sich die Infos zusammensuchen.

Seit einer ganzen Weile gibt es aber die Option -script-output, die alle relevanten Ausgaben zum einlesen in andere Skripte zur Verfügung stellt.

Danach hat Tom Koch ein gutes Stück Arbeit in das Skript investiert, um die Ausgaben sauberer und übersichtlicher zu gestalten. Ausserdem wurden die kryptischen Dateinamen abgeschafft, stattdessen wurde die -basename Option eingeführt.

Diese Änderungen will ich icht wieder rückgängig machen, aber ich werde versuchen, einen vdrconvert-Modus einzubauen.

Beste Grüsse

Peter