Beiträge von TDT/TOT

LigH
Danke, ich hatte nicht gesehen, dass so etwas geht.

Viele Grüße

Hallo zusammen,

ich filme immer noch, ich lese immer noch und benutze das Programm auch immer noch.

Viel Spaß: DateCodeSub 2.0

LigH: Danke für den Hinweis: Man lernt eben nie aus. Mit diesem Zahlenformat hatte ich noch nicht zu tun.

Jetzt grüble ich natürlich verzweifelt, was die Leute bei der Festlegung des HDV-Formats (wohl auch schon beim DV-Format) veranlasst haben könnte, dieses Zahlenfomat zu wählen. Mit google bin ich nicht zu einem abschließenden Ergebnis gekommen. Kann man auf diese Weise Auslesefehler vom Band reduzieren? Oder ist es so einfacher, die Zahlen auf dem Kamera-Display darzustellen, weil sich die Kameraelektronik immer nur ein Halb-Byte schnappen muss und ohne weitere Berechnung die richtige Dezimal-Zahl hat?

Für Hinweise bin ich dankbar.

Ich muss noch einmal nachbessern: Ich habe erst jetzt bei der Bearbeitung meiner Aufnahmen aus 2010 gemerkt, dass der Camcorder die Jahreszahl wie manch andere Werte auch sehr merkwürdig speichert: auf $09 folgt nicht etwa $0A, sondern $10, was dezimal umgerechnet 16 ergibt.

Weil ich aber nur wegen Sony nicht unbedingt 6 Jahre meines Lebens verpassen wollte, habe ich das Programm berichtigt: DateCodeSub

Das ist keine HDDV-Kamera und mit dieser Kamera kann mein Programm daher (im Automatik-Modus) nicht funktionieren. Meines Wissens nimmt die Kamera im AVCHD-Format (MPEG4) auf. Bigotti hat hierzu oben geschrieben, dass die Daten bei diesem Format als Bitmap im Stream enthalten sind und über OCR ausgelesen werden müssen. Vielleicht kann bigotti Dir ja helfen (oder Du benutzt den halbautomatischen Modus meines Programms). Mehr kann ich leider nicht für Dich tun.

Viele Grüße

CCat21: Welche Kamera?

Ich muss nachbessern: Die Kamera kennt auch die Blende 2.0 (gespeichert in den bytes $8c/$9d/$ae (140/157/174) mit dem Wert: c8 (200)).
Im Programm ergänzt: DateCodeSub 2.0

auvida:
Es ist genau das passiert, was ich befüchtet habe: Die Canon-Camcorder speichern die Zeitdaten anders als die Sonys und die Fehlermeldung ist im Grunde keine Fehlermeldung: Den Wert 17:71:01 kann man in der Tat nicht in einen Datumswert umwandeln. Ein Testfile nützt mir nichts. Ich bräuchte eine Tabelle (ähnlich der, die ich aufgestellt habe), aus der sich ergibt, wo und wie die Zeitdaten von den Canons gespeichert werden. Eine solche Tabelle wird man nur dann aufstellen können, wenn man auch die Kamera hat.

DateCodeSub 2.0 ist fertig und kann heruntergeladen werden (DateCodeSub 2.0). Das Programm holt sich die Zeitangaben jetzt direkt aus den m2t-Dateien, und zwar auch dann, wenn der Transport-Stream Videos mit verschiedenen Aufnahmezeiten enthält. Außerdem können (auf Wunsch) auch die Kameraeinstellungen in denselben oder einen weiteren Untertitel geschrieben werden. Das Programm funktioniert mit meinem Sony HDR-HC7 einwandfrei. Ich habe nur das ungute Gefühl, dass DateCodeSub nicht mit allen m2t-Dateien klarkommen wird, weil ich fürchte, dass der Ort und die Art der Datenspeicherung hersteller-, wenn nicht gar modell-spezifisch sind. Vielleicht funktioniert das Programm ja wenigstens mit allen Sony-HDV-Kameras. Das kann man nur ausprobieren; im schlimmsten Fall stürzt das Progamm einfach ab. Helfen kann ich dann nicht mehr, denn selbst wenn ich einen Beispiel-Transport-Stream von einer anderen Kamera, die im HDV-Modus aufnimmt, hätte, glaube ich nicht, dass man die Daten allein aus dem Stream und ohne Kamera und deren Darstellung auf dem eigenen Display austüfteln kann.

Ich habe viele, viele dutzend Probe-Aufnahme machen müssen, um folgende Ergebnisse herauszubekommen (bitte nicht fragen, warum alle Werte immer gleichlaufend in 3 bytes gespeichert werden: Ich weiß es nicht):

Die Blende wird - wie bigotti schon richtig festgestellt hat - in den bytes $8c/$9d/$ae (140/157/174) gespeichert.

Dabei bedeuten die Werte:

fe (254) 18 (Close)
dc (220) 11
d8 (216) 8
d6 (214) 6,8
d4 (212) 5,6
d2 (210) 4,8
d0 (208) 4,0
ce (206) 3,4
cc (204) 2,8
ca (202) 2,4
c7 (199) 1,8

Größere und kleinere Werte sowie Werte dazwischen kennt der Camcorder nicht.

Der Belichtungsmodus (auto/manual) wird gespeichert in den bytes $8d/$9e/$af (141/158/175): Werte >= $41 (65) bedeuten manuelle Belichtungseinstellung, Werte darunter (01-07) stehen für die automatische Belichtung.

Die letzte Ziffer zeigt die Signalverstärkung (Gain) an:

x1 = 0 db
x2 = 3 db
x3 = 6 db
x4 = 9 db
x5 = 12 db
x6 = 15 db
x7 = 18 db

Die Einstellungen zum Weiß-Abgleich werden gespeichert in den bytes $8e/$9f/$b0 (142/159/176).

Dabei bedeuten die Werte:

1f (031) auto
64 (100) außen
61 (097) innen
5f (095) direkt

Ob und ggfs. wo Eingaben zur Weißwertverschiebung gespeichert werden, konnte ich nicht herausfinden (wohl nicht: der Camcorder selbst zeigt sie auch nicht an).

Die bytes $92/$a3/$b4 (146/163/180) speichern die Steady-Shot-Funktion:
$7f (127) bedeutet ein, $ff (255) aus (in diesem Punkt bin ich mir nicht ganz sicher: Wenn ich die Stead-Shot-Funktion abschalte, stehen die bytes zuverlässig auf $ff; wenn ich die Funktion einschalte, wird in der Regel, aber nicht immer $7f angezeigt; ich vermute daher, dass hier gespeichert wird, ob der Steady-Shot eingegriffen hat, nicht, ob er generell aktiviert war).

Die Verschlusszeit wird gespeichert in den bytes $98/$a9/$ba (152/169/186):
dabei bedeuten die Werte:

9f (159) 1/3
50 (080) 1/6
28 (40) 1/12
65 (101) 1/25
33 (051) 1/50
d5 (213) 1/60
19 (025) 1/100
ea (234) 1/120
bc (188) 1/150
83 (131) 1/215
5e (094) 1/300
42 (066) 1/425
2f (047) 1/600
1c (028) 1/1000
17 (023) 1/1250
10 (016) 1/1750
0b (011) 1/2500
08 (008) 1/3500
05 (005) 1/6000
03 (003) 1/10000

Irgendeine Logik habe ich in diese Zahlen nicht bringen können.

Demzufolge wertet DateCodeSub in der Version 2.0 folgende Kameraeinstellungen aus und kann damit genau das in den Untertitel einfügen, was auch der Camcorder auf dem Display anzeigt:

Blende/Verschlusszeit/Gain/Steady-Shot (ein/aus)/AutoExposure (ein/aus)/WhiteBalance (auto/out/in/direct)

Als sehr nützlich bei meiner Suche hat sich der "DVB transport stream analyser" erwiesen. Dieser ist zwar - wie der Name schon sagt - eigentlich für DVB-Streams geschrieben; wenn man die zu untersuchenden Dateien aber vorübergehend von *.m2t in *.ts umbenennt, schluckt das Programm auch die m2t-Dateien. Das Programm hat eine kleine Macke: Es schließt die geöffneten Dateien - jedenfalls auf meinem Vista-System - nicht ordnungsgemäß: Wenn man eine Datei geöffnet und wieder geschlossen hat, erhält man beim erneuten Versuch, die Datei einzulesen, die Fehlermeldung, die Datei werde gerade verwandt und könne nicht geöffnet werden. Es hilft dann nur noch, das TSR-Programm komplett zu beenden und wieder neu zu starten. Da der Programm-Autor scheinbar keine Homepage hat, gebe ich hier einfach den google-link aus dem edv-tipp wieder: TSR-google-link

bigotti, Du bist ein Schatz!

Ich werde mir das auf jeden Fall genau ansehen. Es kann nur etwas dauern, weil ich die Ergebnisse an einer Reihe von Aufnahmen prüfen muss.

Man findet in der Tat so gut wie keine Informationen (sonst hätte ich nicht gefragt). Ich habe z.B. die Seite https://localhost/www.hdv-info.org gefunden. Da findet man dann einen Link 'HDV Format Main Specification', freut sich wie ein Kind ... und bekommt eine Art einseitiges Reklameblättchen.

Der Autor von HDVInfo hatte ja wohl auch ursprünglich einmal vor, den Source-Code zu veröffentlichen, hat dann aber aus lizenzrechtlichen Gründen einen Rückzieher gemacht.

Warum eine derartige Geheimniskrämerei um ein (noch dazu aussterbendes) Format gemacht wird, ist mir ein Rätsel.

Viele Grüße und vielen Dank.

Mir würde der Source-Code von einem der Programme (HDVSplit, HDVInfo oder HDVDataMon) sehr weiterhelfen, weil ich mir dann ansehen könnte, wie die Programme die Daten aus den m2t-Dateien herausholen. Nach diesem Code habe ich aber vergeblich gesucht. Ich glaube, ich werde einfach einmal eine Anfrage an Sony richten.

Whow!
Dann haben die AVCHD-Dateien natürlich ein völlig anderes Kaliber als die HDV-Dateien. Das bedeutet ja, dass der Camcorder selbst den Bitmap-Stream bei der Aufnahme erzeugt und dieser Stream auch beim Schneiden erhalten bleibt (?). Die Camcorder-Hersteller hätten also wirklich etwas dazu gelernt und würden den DateCode jetzt in einer Weise liefern, mit der man richtig was anfangen kann. Ich glaube, ich brauche einen neuen Camcorder (es ist ja bald Weihnachten;)).
Eine Beispieldatei kann ich liefern (Beispiel). Ich habe versucht, die Datei so kurz wie möglich zu halten (schneller ist mein Daumen auf dem Aufnahmeknopf nicht mehr und ein 'Stück' kann ich nicht liefern, denn das ist ja das nächste Problem der HDV-Aufnahmen: Die m2t-Dateien kann ich nicht schneiden und wenn ich diese Dateien demultiplexe und dann schneide, sind die Metadaten weg).

Die kurze Aufnahme beinhaltet aber alle Infos:

HDVDataMon zeigt mit an:

Aufnahmedatum:
2009-08-29 17:03:06
Timecode:
0:43:40:02
Kamera-Daten:
Steady ON AutoWB ExpAuto F3.4 1/50 +0dB

Alles richtig.

Hallo bigotti5,

vielen Dank für die Antwort. Bei den HDV Streams muss es anders sein, und zwar schon deshalb, weil ein so winziges Programm wie der HDVDataMon (unter 30 kb!) nicht nur Datum und Uhrzeit, sondern auch noch die Kameraeinstellungen auslesen kann. In einem solchen Programm kann keine OCR stecken. Ich bin mir ziemlich sicher, dass das genaue Datum und die Uhrzeit in 8 bytes im Header der einzelnen Pakete in den m2t-Dateien steckt und dass es sich um irgendeine Abwandlung eines julianischen Datums handelt (die *.modd-Dateien speichern auch eine solche Abwandlung: Es ist ein julianisches Datum mit der Besonderheit, dass die Zeitzählung erst am 01.01.1900 beginnt). Der Transport Stream packet analyser zeigt mir ja auch den Header meiner m2t-Dateien an, behauptet aber steif und fest, die Zeitangaben seien nicht vorhanden, d.h. Sony speichert die entweder an einer anderen Stelle oder in einer anderen Form als dies bei den DVB-Dateien der Fall ist. Ich bin mir auch nicht ganz sicher, ob das bei Deinen AVCHD-Dateien ursprünglich anders ist, denn das Ergebnis, das auf Deiner Festplatte landet, hängt ja auch vom Import-Programm ab. Vielleicht ist Dein Programm ja so komfortabel, dass es beim Import die gelesenen Daten direkt als Bitmaps rendert, denn in diese Form müssen alle Untertitel vor der Erstellung der DVD ohnehin gebracht werden. Bei mir macht das eben DVD-Lab pro nach dem Import der srt-Dateien. Darf ich fragen, welches Programm Du zum Import benutzt?

Hallo zusammen,

seit Jahren suche ich nach einer Möglichkeit, den DateCode von HDV-Aufnahmen als Untertitel für eine DVD zu importieren, jetzt bin ich scheinbar fündig geworden: DVMP Pro 4 (http://www.dvmp.co.uk) verspricht, dies zu können. Ausprobieren konnte ich das nicht, weil der Demo-Version ausgerechnet der Meta-Daten-Export fehlt. Allerdings finde ich es auf der einen Seite auch wieder etwas übertrieben, 40 US$ für ein umfangreiches Programm auszugeben, um dann nur eine einzige Funktion des Programms zu benutzen, und auf der anderen Seite sind mir die Ausgabe-Optionen mit fünf fest vorgegebenen Varianten auch zu unflexibel.
Deshalb habe ich mir ein eigenes kleines Windows-Programm für den Import geschrieben: Anwender mit einem Sony-Camcorder, die den mitgelieferten Picture Motion Browser (PMB) zum Überspielen der Videos auf den Computer benutzen, können sich Untertitel-Dateien im verbreiteten SubRip-Format (*.srt) mit Datum, einer fortlaufenden Uhrzeit und 1 bis 2 frei belegbaren Zeilen im Stapelbetrieb aus den *.modd-Dateien, die der PMB beim Import automatisch erzeugt, erstellen. Damit alle Anderen aber nicht traurig sind, habe ich einen "halbautomatischen" Modus in das Programm eingebaut: Wenn man dem Programm das Aufnahmedatum, die Start-Uhrzeit und die Dauer eines Video-Clips angibt, erstellt das Programm aus diesen Angaben eine *.srt-Untertitel-Datei mit diesen Daten und einer fortlaufenden Uhrzeit, deren Aktualisierungs-Intervall zwischen 1 und 60 sec. frei wählbar ist, und zwar selbst dann, wenn das Video gar keinen DateCode enthält.
Das Progamm steht hier zum Download zur Verfügung: DateCodeSub. Das Programm benötigt keine Installation, wohl aber .NET Framework 3.5 und sollte im Übrigen mit allen Windows-Versionen, die diese Voraussetzungen erfüllen, funktionieren. Eine kurze Beschreibung habe ich dazugepackt.

Selbstverständlich würde ich die notwendigen Informationen zum Datum und zur Uhrzeit der Aufnahme lieber direkt aus den m2t-Dateien herausholen, aber an dieser Stelle komme ich nicht weiter: Ich habe meine m2t-Dateien vor und zurück durchsucht und komme nicht darauf, wie die Zeit-Daten dort gespeichert sind. Dabei müssen sie in den Transport-Streams enthalten sein. HDVSplit, HDVDataMon und der PMB können sie auslesen (der PMB zeigt die Daten nämlich auch dann an, wenn ich die dazugehörigen modd-Files lösche). Ich hatte schon gehofft, mein Problem mit dem MPEG-2 Transport Stream packet analyser (http://www.pjdaniel.org.uk/mpeg/index.asp) lösen zu können, aber der befasst sich mit ISO/DVB transport streams (*.ts) und die scheinen (jedenfalls mit dem Zusatz-Header) anders gestrickt zu sein, als die m2t-Streams vom Camcorder. Jedenfalls zeigt mir dieses Programm an, meine m2t-Dateien enthielten gar keine TDT/TOT-Informationen, was aus den schon geschilderten Gründen nicht sein kann.

Hat vielleicht noch irgendjemand eine Idee?