VDR HD Aufnahmen weiterverarbeiten

Zitat

Original von rnissl
Hi,

Genau, 90000 PTS <=> 1 Sekunde.

Bye.

Alles anzeigen

Danke, das es so einfach ist, hätte ich nicht gedacht.

Zitat

Original von Maniac
Ich hab mir vorhin testweise mal ein kleines Tool geschrieben was den PES Header ausliest. Dort teste ich Anfangs einfach auf "00 00 01", werte den Header aus. Springe anhand der Längenangabe weiter. Dann geht das ganze wieder von vorn los. Sobald er einmal nicht auf "00 00 01" stößt lass ich eine Fehlermeldung ausgeben und beende den Scan der Datei.

Also dieses Thema interessiert mich brennend, denn eigentlich darf VDR so eine Datei gar nicht schreiben.

Bye.[/quote]

Ich hab festgestellt das ich einige Aufnahmen mit diesem Problem habe. Wenn ich solche Aufzeichnungen vom VDR schneiden lasse sind sie aber mitunter weg.

Meine aktuelle VDR-Version ist 1.6.0 mit deinem Patch aus der ML. Die Aufnahmen sind aber auch teilweise mit älteren VDR Versionen und ensprechend passendem Patch durchgeführt worden.

Tach Team,
derzeit gehts ja bei HD bissel drunter und drüber ( no Iframes im datenstrom )

siehe : http://vdr-portal.de/board/thread.php?threadid=77664

Ich habe ein paar Dirty Hacks eingefügt, um falsch ausgegebene Timecodes im Nachhinein für mkvmerge akzeptabel zu machen, doll ist das nicht, spielt aber erstmal.

Da derzeit kein flüssiges Abspielen ( bei mir ) der neuen Aufnahmen nach Encoder Umstellung möglich ist, heist's erstmal Abwarten.

Die Schnittfunktion hackt derzeit irgendwo in den Datenstrom ein, da keine Iframes mehr als Schnittkanten existieren.

Grüße vom Alex

Hallöchen...

Ich hab das Script ein bisschen aufpoliert in hinsicht auf MP3 tonspuren (btw. in den files steckt üblicherweise MPEG 1 Layer 2 und nicht Layer 3 wie der dateiname suggeriert )
leider ist allerdings jetzt die AC3 stream sortierung wieder raus (bin nicht so der perl typ ) d.h. wer immer den AC3 strom mit den meisten kanälen als ersten stream haben will sollte auf nen fix von faup warten...

fazit: ORF1 HD und BBC HD sollte jetzt gehen

PS: bin leider nicht zum testen gekommen ( Olympia aufnahme läuft )
PPS: momentan ist das script auf 9 audiostreams limitert - das sollte wohl vorerst mal reichen
PPPS: nach dem fix wäre wohl nen versionswechsel auf V7 ganz gut

NACHTRAG:
hotfix für tonspuren war nötig (falscher pfad) - bitte V6e erneut laden (gilt nur für die, die V6d geladen haben)
bin grad am testen...

Hi,

also Iframes mit dem x264 encoder zu generieren ist ja scheinbar nich so schwierig (siehe x264.c)... kompliziert wirds mit dem decoder... (muss ne möglichkeit geben ein vollständiges bild zu "erkennen" nach dem anlaufen
den erstellten iframe an der richtigen stelle einzusetzen stell' ich mir auch nicht so einfach vor....

...aber von der idee her wär das mal nen anfang um wenigstens die aufnahme mit einem iframe starten zu lassen...

faup:
btw: kann das sein das, das script ab ca. 32GiB beim kopieren seehr langsam wird ? (hoffentlich liegts nicht am dateisystem ... (ext2) - ich sitz jetzt schon über 20h an 'ner 67GiB aufnahme )

Tach Team,

Zeit für Die V7, bitte mal testen. Da umfangreiche Änderungen, bestimmt auch der eine oder andere Bug :

- Die Audiospuren Zurordnung ist nun neu, sortiert wird in der Priorität :
-- 1. AC3 >= 5 Spuren
-- 2. AC3 < 5 Spuren
-- 3. mp2 deklarierte Audiospuren in ihrer Reihenfolge im Original
-- 4. mp3 deklarierte Audiospuren in originaler Folge

- Die Scriptausgaben im Normal Modus etwas übersichtlicher

CBArts :
32 GiG klingt sehr nach einer FS Grenze, ich hab mal auf den RAM geschaut, den die Tools belegen, bei einer Discovery 5 GIG Aufnahme blieb dabei alles im grünen Bereich.

Vielleicht kann mkvmerge nicht mehr als 32GIG adressieren ?
Perl selber hat ja auch die unangenehme Eigenschaft, belegten Speicher nicht wieder freizugeben, in der Cut-Engine werden aber umlaufend immer nur 16MByte Häppchen geschrieben.

Zu den iframes, ich denk, da gehts dann in Richtung teilweises Neukomprimieren ( an den Schnittkannten ), Ich bin aber nicht so tief in der h264 Struktur bewandert, um wenigstens mal in den derzeitigen Stream rein zu analysieren.

Das könnte aber interessant werden.

Grüße vom Alex

faup:
nee nur die Cut-engine hat ab ca. 30-32 GiB nur noch 1-3MiB/s geliefert demux lief mit normalem speed (matroska muss ich gleich nochmal starten (hat wegen audio-sync-reihenfolge gemotzt))
...dann wirds wohl an perl liegen ... auch egal - momentan ist speed nicht so wichtig und so große aufnahmen gibts sowieso nur zu olympia

zu den iframes:
hab mir das ganze auch nur oberflächlich angesehen - wenn man den ffmpeg/libavcodec decoder dazu bringen kann kurz vor der marke anzufangen zu dekodieren und dann zum mark mit x264 das decodierte frame in einen iframe umzuwandeln.... vielleicht reicht's dann schon das neue iframe einfach vor den nächsten frame zu setzen.... hab nur mal laut gedacht

ps: werde das neue script mal testen

NACHTRAG:
man sollte wohl so große aufnahmen vermeiden: mpeg_ps_demux liefert in den audio-sync-files nur noch murx..........(oder die aufnahme war nicht sauber)

das wollte ich nicht vorenthalten :

http://www.alice-dsl.net/schmendrick/
von hier :
http://www.movie2digital.de/thread.php?threadid=42265

Zum 32GIG Problem, ich werde ( nach Kauf einer neuen HD , tja 2 Monate alte 750 GIG is fast voll ) mal eine ellenlange testaufnahme machen und auf die Bugsuche gehen

nächtliche grüße

Alex

faup:
ich bin grad' am scheiden der 2ten aufnahme ca. 70 gibibyte - diesmal wurde die Cut-engine ab ca. 40 GiB langsam (1MiB/s) - die CPU last ist nahe bei 100% (ist mir eben erst aufgefallen) -
RAM ist noch massig frei: htop sagt 1.9% verwendet von 1GiB
liegt definitiv an perl...

btw: ich bin grad am experimentieren mit mkvmerge - es sollte möglich sein direkt von einem VDR-file in ein matroska file zu schreiben (bei MPEG-PS kann er das laut source ja auch...)

hi...

hab einen patch für mkvtoolnix geschrieben, der es ermöglicht ein vdr-file direkt ohne extra demuxen in ein matroska container zu konvertieren...
ACHTUNG: dies ist eine BETA-version D.H. ___keine___ beschwerden nach dem patchen das euer mkvmerge nich mehr richtig läuft
aber wenn ihr damit experimentieren wollt: ihr braucht mkvtoolnix version 2.20 im source (und evt. zubehör libebml-dev, matroska-dev u. mglw. andere dev-pakete) und den angehängten patch

soweit ich das ding getestet hab: mormale vdr-aufnahmen (mpeg2) sind scheinbar ok (incl. aller tonspuren)...
h264 macht, so wie's aussieht, noch probleme...

achso: keine sync garantien (das hab ich erst mal außen vor gelassen...) - der sync könnte aber ok sein (größtenteils hab ich den vorhandenen MPEG PS parser verwendet)

...hab nur seeehr wenig gesteted...
vielleicht findet noch jemand nen bug im source...

aufruf: mkvmerge -o <ausgabefile.mkv> <vdr-file>

NACHTRAG:
bei der h264 verarbeitung scheint irgendwo ein speicherleck zu sein...

NACHTRAG2:
der parser muss noch mal überarbeitet werden ... wird noch nen bisschen dauern...
(mpeg2-erkennung wurde durch die h264 korrekturen beschädigt *grr* )

NACHTRAG3:
der mpeg2 teil läuft wieder leider gibt es sync probleme (hab noch keine ahnung wie ich die löse)
...auf alle fälle funktioniert jetzt die erkennung mpeg2/h264 ganz gut... das speicherleck für h264 ist immernoch irgendwo (sollte aber niemanden vom testen abhalten )

PESFIX Version 0.2:

Ich konnte mpeg4ip mit den Patches auf MacOSX 10.5 durch den Compiler drücken, MKVToolnix als binary installiert, SDL aus den Sourcen bauen, das Script kann nun meinen 8core quälen

Ich hab alles mal in ein Archiv gepackt, MKVToolnix, SDL source und mpeg4ip source, beide sind bereit zum Bauen auf 10.5

KLICK

Seh ich das richtig, dass nur eine Instanz des Scripts gleichzeitig laufen sollte weil die tempfiles alle gleich heißen?

Könntest du da nicht die pid oder so in den Namen einbauen? Dann könnte die Box die Nacht durch einen Haufen Zeug konvertieren

EDIT: Ja, es läuft, der erste 8GB-Film ist durchgenudelt

EDIT2: Magst du nicht deinen SSEM-Patch an mpeg4ip einreichen, damit sie es eventuell in den Standard aufnehmen?

s_herzog:

Zitat

Seh ich das richtig, dass nur eine Instanz des Scripts gleichzeitig laufen sollte weil die tempfiles alle gleich heißen? Könntest du da nicht die pid oder so in den Namen einbauen? Dann könnte die Box die Nacht durch einen Haufen Zeug konvertieren großes Grinsen

jepp... kannst ja einfach 8 temp verzeichnisse machen mit 8 scripten (bin im moment mit PESFIX beschäftigt...)

Zitat

EDIT2: Magst du nicht deinen SSEM-Patch an mpeg4ip einreichen, damit sie es eventuell in den Standard aufnehmen?

nein, das halte ich für keine gute idee, da das ein reiner quick-and-dirty fix bzw. eine notlösung ist - normalerweise muss das hauptprogramm und mglw. die library völlig neugeschrieben/umgeschrieben werden um bessere performance und ein sauberen code zu liefern

der PESFIX für mkvmerge wär die bessere lösung: ist permanenter, schneller und sehr viel effizienter

@alle
hab jetzt feststellen müssen das das "speicherleck" bei mkvmerge scheinbar mit den timecodes zu tun hat (bzw. duch paket umsortierung entsteht) mal schauen ob ich das gelöst bekomme...
(d.h. wer nur video im mkv haben will sollte mit der letzten version schon arbeiten können )

ps: wenn mehrere vdr-dateien in ein mkv file konvertiert werden sollen reicht ein +
bsp: mkvmerge -o result.mkv 001.vdr +002.vdr +003.vdr usw.

Also das originale mkvmerge aus mkvtoolnix 2.0.0 für Mac (die 2.2 gibts nicht als binary-Paket) hat auch schon einen Bug, das schmiert bei mir bei bestimmten Filmen mit einem malloc, das nicht durchgeht, ab. Dabei denke ich mein Mac sollte mit 4GB genug RAM haben...

so die neue PESFIX 0.6 BETA für mkvtoolnix 2.2.0 (mkvmerge) ist fertig... (ermöglicht das direkte konvertieren von vdr-files in das matroska-format)
(ihr braucht mkvtoolnix version 2.2.0 im source (und evtl. zubehör libebml-dev, matroska-dev u. mglw. andere dev-pakete) und den angehängten patch)

sehr viele bugfixes und änderungen...

bitte testet mal auf sync bei h264 material - es sollte jetzt synchron sein
(bitte um rückmeldung - auch bei positivem ergebnis)

mpeg sollte man aber nicht umwandeln (ist zwar auch sync, aber irgendwo auf dem verarbeitungsweg gehen ein paar bytes verloren )

PS: mkvmerge erkennt jetzt auch die richtige Bildrate und schreibt sie ins file (zumindest bei vdr-files) - so weit ich das sehe verwendet mkvmerge normalerweise 25 fps als standardvorgabe was zu "Zeitlupenwiedergabe" z.b. beim mplayer führt....

CBArts

Vielen dank für den Patch. Hab bis jetzt 3 Filme konvertiert und alle sind synchron und laufen prima.

Gruss,

Stefan

Gibt's eigentlich irgendwas mit dem man solche Matroskas nachtäglich noch zurechtschnippeln kann? (Bevorzugt für Linux)

Hab jetzt so einiges durchprobiert, das Einzige das ansatzweise Ergebnisse liefert ist avidemux. Wenn man die von avidemux erzeugten mkvs anschließend noch in mmg ladet und speichert kann man sie sogar abspielen Allerdings behält es nur den Ersten Audio-Track.

http://mediacoder.sourceforge.net/download.htm

ist zwar ein windows programm läuft aber auch mit wine

müsste gehen

puuh, das erschlägt einen ja geradezu mit Einstellungen - dagegen ist ja die mencoder man-page noch harmlos

Meine bisherigen Erfolge damit halten sich noch in Grenzen - es kommt immerhin abspielbares Matroska raus, allerdings bisher ganz ohne Ton. (Es schreit immer, daß es den lame nicht öffnen kann - obwohl ich audio auf copy gestellt hab) Und die Schnittmarken scheint er zu ignorieren wenn man den video-codec auf copy stellt. Und von mehreren Tonspuren find ich da auch nirgends was.

(Testinput ist eine 10min Aufnahme von ORF1HD - 1280x720 50fps mit ac3 und mp3 Ton)

Tolle Sache mit dem mkvmerge, werde ich gleich mal ausprobieren, besonders ob auch die PCH-A110 das dann sauber abspielt

Anbei schonmal ein gentoo ebuild um den Patch zu integrieren.
Einfach ins lokale Overlay legen (HOWTO hier: http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds )
und noch ein Unterverzeichnis "files" anlegen, dort dann den Patch von CBArts als "mkvtoolnix220_PESFIX_0.6.patch" ablegen.
Dann noch das übliche digest'en des ebuild und schon ist es beim nächsten emerge integriert...

Habe jetzt ein paar Versuche mit dem HDvdrpes_to_mkv_V7.pl mit ORF1HD-Material (1280x720 50fps) hinter mir:

A/V-Sync passt (soweit man das bei Synchronisiertem Material sagen kann)

Im marks.vdr muß ich die Zeiten verdoppeln (liegt wohl an den 50fps) - aber genau passt das dann trotzdem nicht.

im info.vdr steht:
X 2 03 deu stereo deutsch
X 2 03 eng stereo englisch
X 2 05 deu Dolby Digital 2.0
V 1220202600

Im Matroska erhalte ich aber nur 2 Tonspuren, die englische "verdunstet" irgendwie.

Ich habe inzwischen auch ein paar Filme umgewandelt (mit dem gepatchten mkvmerge) und habe teilweise Probleme mit asynchronem Ton, werde aber noch ein paar mehr Tests laufen lassen und dann genaueres berichten.