DIVX/DVD/SVCD Erzeugung mittels vdrsync

Hi zusammen,

ich bin beim surfen über folgende Website gestolpert:

http://www.home.zonnet.nl/panteltje/dvd/index.html

Dort steht:

Zitat

tcmplex-panteltje-0.3.tgz
tcmplex-pantelje, audio video multiplexer from the transcode distribution,
re-wrote it for 8 audio channels, this version fixes an AC3 bug and supports files > 2GB.

Was ja an sich schon mal interessant für die DVD Erzeuger mit PW sein könnte. Für diese Diskussion interessanter ist aber:

aus der Datei CHANGES:

Zitat

0.2
Applied patch by Dan Scholnik for video files > 2 GB.

Some other change that may affect scripts you have made:
In the 0.1 release I set video_delay_ms to zero (from 180) in params.c
for DVD.
This because if you did enter delay in the command line it would
start at zero!

Now the video delay specified in the command line is ADDED to the
180 ms.
The 180 ms seems to be the value that causes zero delay between picture
and sound in the DVD players.

So: -D 180,0 now creates a 360 ms delay for video, and the audio will
be 180 ms early in the picture.
Not sure this is the best way, but for consistency, if one adds a delay of
say -D 90, you would expect video to be 90 ms late, not early

This will break old scripts you may have, in those cases simply substract
180 for -D x, or , if x becomes negative because of that, set it to zero
and add the difference.

Alles anzeigen

Es sieht also so aus, also ob tcmplex immer einen delay von 180 ms einmuxt. Dimitri erzeugt
seine DIVX-CDs aus den einzelnen streams ohne mplexen, wenn ich seine Skripte richtig in
Erinnerung habe.
Weil nicht gemplext wurde, ist auch kein 180 ms delay drin. MeMeD mplext erst, und zwar
noch mit der Option "-m d" => 180 ms delay. mencoder scheint das nicht zu korrigieren, evt ist
das des Rätsels Lösung

cheers

doc

Hi Dimitri,

ich glaube, wir haben uns missverstanden

Ich wollte nicht vorschlagen, die tcmplex Version zu ändern, sondern nur auf eine modifizierte Version hinweisen, die 8 Audiostreams verarbeitet.

Ausserdem (und wichtiger!) glaube ich, dass mit dem delay, den tcmplex einbaut (oder eben nicht einbaut), die unterschiedlichen Erfahrungen zu erklären sind, die Du und MeMeD bei der DIVX-Produktion gemacht habt.

Wenn tcmplex also beim DVD-mplexen Audio um 180 ms verschiebt, Video aber nicht, dann ist es natürlich ein Unterschied, ob ich einen mplex Schritt im Skript habe oder eben nicht. 2divx wandelt den Audiostream in MP3 und muxt ihn per

mencoder -aoc copy -audiofile

ein. MeMeD erzeugt einen DVD-kompatiblen Stream mit tcmplex und wandelt das MPEG-File, was hinten rauskommt, mit mencoder um.

Deshalb vielleicht ein Shift bei Ihm, aber nicht bei Dir.

Ein Delay von -16 oder -5 ist sehr speziell, sind das ms, die Du da angibst? Das ist kaum zu sehen, da ja schon ein Bild 40 ms benötigt. Und syncen kann man auch nur einen Audioframe genau, also 32 ms bei AC3 oder 24 ms.

Im Prinzip könnte vdrsync den nicht korrigierten Shift rausgeben, der wird ja schliesslich berechnet, aber der ist nach jedem Schnitt anders, deshalb macht das keinen Sinn.

Falls ich was nicht verstanden haben sollte, dann hilf mir doch bitte noch mal auf die Sprünge

Cheers

doc

Hi zusammen,

dimitri und MeMeD

Hey, was Ihr zusammenbaut ist wirklich genial. Wenn die ganze Sache ein Plugin-Paket geworden ist, dann ist das für mich DAS Killerplugin schlechthin.... per OSD Konvertierungen in alle möglichen Formate starten, und dabei mit der Fernbedienung noch die Parameter justieren können -

Ich habe leider in nächster Zeit viel um die Ohren, werde aber trotzdem versuchen, das ganze möglichst mit zu testen, und natürlich auch die neue "vdrsync-engine" fertigzustellen.

@ Dimitri

Vielen Dank für das Skript in der PM, ich hatte es leider übersehen:(

@ MeMeD

Kannst Du den Plugin-Code mal posten oder per PM senden?

Cheers

doc

Hallo,

als erstes was zum -ignore:

den -ignore Schalter habe ich ursrpünglich eingebaut, um Audio-Spuren rauszuwerfen. Erst
später kam dann auch bei mir die Idee, den Schalter für Audio-Extraktion zu nutzen. Allerdings
habe ich das bisher nicht über ignore gemacht, sondern über

-dump-payload

Kurze Erklärung:

Der -ignore Schalter veranlasst, das PES-Pakete, die zu einem "ignore-Stream" gehören, sehr früh
verworfen werden, also sobald der Stream "erkannt" wird. Vorteil: Geschwindigkeit.
Ignore wird automatisch für Streams gesetzt, mit denen vdrsync nix anfangen kann, zB Teletext.
Ich habe hier kein Teletext bzw war zu faul, auch noch die PIDs rauszufummeln.
Nachteil: wenn man den Videostream "ignored", dann kann man gegen nichts synchronisieren.
vdrsync bricht ab, sobald es versucht, die Audiospuren zu syncen.
Das hat mich persönlich allerdings nie gestört, weil das reine Extrahieren einer Audiospur mit

-ignore e0,c1,c2,bd -dump-payload 99999999

für die erste Audiospur ohnehin schneller ging. Das hat allerdings wiederum schwere Nachteile, die
mir erst nach eurem Feedback aufallen:

• vdrsync verwirft beschädigte (= "halbe") AudioFrames, wie sie VDR beim schneiden manchmal
  erzeugt. Die Option "-dump-payload" schreibt diese allerdings mit raus, so dass es dem
  nachfolgenden Programm überlassen bleibt, dass zu fixen. Gar nicht gut
• Wenn man nur die Audiospur extrahieren möchte, um sie anschliessend wieder mit dem Video
  zusammen zu bringen, dann synct vdrsync die Audiospur nicht mit dem Video (ist ja ein dump, also
  ("roh wie sie kommen auf die Platte").

Lösung: Sehr kleine Anpassungen in vdrsync, die das rausschreiben einer gsyncten Audiospur
ermöglichen, auch wenn Video ignoriert wird. Es handelt sich nur um ein Verlagern der Abfrage
PSEUDO-CODE
If ignore stream then next
/PSEUDO-CODE
von der Stream Identifizierung zu der Stelle, an der die Daten tatsächlich rausgeschrieben werden.
Vorteil: vdrsync würde gesynct(!) und gefixt (!) die Audiospuren schreiben
Nachteil: Es dauert länger, allerdings immer noch schneller als ein "normaler" vdrsync Durchlauf.
Wer will testen? (Wie mplayer bei geschnittenen Aufnahmen "dumped" weiss ich nicht, ob mit oder ohne "Fix" von kaputten Frames)

@ Dimitri

Es sieht so aus, als hättest Du einen Bug gefunden, bei mir funktioniert

./vdrsync -ingore c1,c2,bd

völlig ok. Der Parameter Parser ist allerdings auch noch als rudimentär einzustufen, vielleicht
verstolpert sich vdrsync an der Stelle. Wie sieht der vdrsync-Aufruf genau aus?

Achja, die intermediate Version, die ich in der PM verlinkt habe, kann auch ein Verzeichnis als
Parameter akzeptieren - überfälliges Feature, das ich nicht erwähnt habe :wand. Also ist es nicht
mehr nötig, alle .vdr Files einzeln anzugeben. Wenn man Verzeichnisse und Dateien mischt, dann
gibt es Murks, aber ich wollte die alten Optionen nicht löschen. Konkret:

vdrsync /PATH/001.vdr /PATH/002.vdr -OPTION

sollte funktionieren, ebenso

vdrsync /PATH/ -OPTION

@ Anonymous
zu der Download Section:
Fände ich recht gut, weil ich selber nicht den wirklichen Ueberblick habe, wer wo wie weit ist. Für
vdrsync selber gibt es dank Dimitri eine rudimentäre Homepage, die ich eigentlich erst
ankündigen wollte, wenn ich die "neue" sync-engine fertig habe. So schnell, wie Ihr alle mit
Ideen und Vorschlägen seid, kann ich allerdings ohnehin eine "stable" Homepage vergessen
zu den Install-Paketen:
Ursprünglich hatte ich gehofft, Mitstreiter für vdrsync selber zu finden, mittlerweile finde ich das,
was hier abgeht noch viel besser. Es ist allerdings auch noch viel schwerer zu koordinieren, d.h. im
Moment macht jeder, was er toll findet - freie Software eben
Mein Ziel wäre im Moment für das gesamte Projekt:

• vdrsync soweit zu verbessern, dass es (fast) immer funktioniert. Ich denke, das ist schon nicht
  so schlecht, weiss aber selber, dass noch einige Sachen"wackeln"
• Die Integration mit Dimitris Skripts zu optimieren, d.h. vdrsync tut, was es soll, ohne Kopfstand
  für Dimitris Skripts. Bsp: Es ist totaler Blödsinn für skripts, dass vdrsync die Video-Datei eX.mpv
  nennt, anstatt einfach Video.mpv. Für die Entwicklung und fürs debuggen war das ok, aber jetzt
  muss jedes Skript selber nachsehen, ob es e0, e4 oder e7 war, was der Sender als Video
  ausgestrahlt hat - das ist möglich, aber Murks. Ich traue mich aber kaum noch, das zu ändern,
  weil die Skripte das sowieso schon abfangen - hmmmmmmm, was jetzt?
• Auf mittlerfristige Sicht ist ein Paket mit Installations-Skript/Anleitung mein Ziel, ich würde auch
  versuchen, ein install zu schreiben (allerdings in Perl ;)), momentan fehlt allerdings sowohl Zeit als
  als auch eine stabile Grundlage. Abwarten.... bis jetzt kommt alles beser, als geplant
  

  
  

Und jetzt bin ich viiiiiiiieeeeellll zu müde, um noch was anderes zu schreiben....

Cheers

doc

Hi ernie,

Zitat

worin liegt eigentlich der unterschied zwischen 1-pass und 2-pass verfahren um ein divx zuerzeugen?

kurze Antwort:

2-pass dauert doppelt so lange, die Qualität ist viel besser

Längere Antwort:

Wenn Du ein DIVX im 1-pass Modus erzeugst, dann haben alle Szenen gleich viel Speicher-Platz zur Verfügung, damit die von Dir angegebene Bitrate eingehalten wird. Dabei spielt es keine Rolle, ob Du eine bewegte Szene mit vielen Wechseln hast, oder ein Standbild.
Deshalb bekommen Standbilder eigentlich zu viel Speichplatz eingeräumt, und bewegte Szenen zu wenig.

Im 2-pass Modus wird erst der ganze Film analysiert, indem er schon mal konvertiert wird. Dabei wird aber nicht das DIVX-File auf die Platte geschrieben, sondern ein log, in dem der encoder festhält, wie "gut" sich jede Szene komprimieren lässt. Im zweite Durchgang wird dann das Movie mit Hilfe des logs optimal konvertiert, also mehr Platz für Action und weniger für ruhige Szenen. Das Ergebnis ist viel besser, aber es dauert auch doppelt so lange.

Cheers

doc