Welche Encoder-Einstellungen für DV-Camcorderaufnahmen als "Master"?

  • Moin!

    Will meine ca. 40 Stunden DV-Camcorderaufnahmen, die seit Jahren mit allen anderen Fotos usw. auf der Festplatte in der Sammlung liegen (als Original DV-AVI - Einzelclips) jetzt doch etwas platzsparender ablegen.

    Ich lege keinen Wert mehr drauf die "Originale" zu behalten. Ich möchte sie als H.264 im Bereich 6-8 MBit/s encoden. Das reicht ja wohl. Und wenn ich in 20 Jahren unbedingt noch einen Film von Kursfahrt-Videos aus den 2000ern zusammenschneiden will (was ich nicht denke :ani_lol:), dann kann ich das auch von den MP4-Videos als Quelle tun.
    Und der Aldi-Camcorder (Samsung-Gerät) von damals war auch nicht unbedingt was ganz so tolles was Bild und Ton angeht (ziemlich "verwaschen")...
    Ich muss denke ich keine DV-AVIs in miesem PAL aufheben, die ne Bitrate haben so hoch wie 4K-Videos vom Super-Handy...das ist doch echt Platzverschwendung...
    (Die Kamera und die Kassetten sind längst über den Jordan - hatte das alles 2009 in den PC überspielt)

    Format soll original 720x576 / 4:3 / Interlaced bleiben.
    Encoding wird mit XMedia Recode gemacht.

    Habe mal testweise eins als ~6 MBit/s ABR encodet und in VirtualDub mit dem Original verglichen. Also sich sehe selbst im Original-DV die JPEG-Artefakte. Und das H.264 ist bei der Bitrate finde ich völlig ausreichend. Die Unterschiede sind marginal.

    Was soll ich nehmen?

    MP4 / H.264 / quality based 16 oder 18 (dass so in etwa 6-8 MBit/s bei rauskommen) / Interlaced BFF

    Und Audio als MP3 / VBR 2 / 192-265 kBit/s?
    Oder lieber AAC? Oder AC3?
    Oder doch FLAC? (in MKV statt MP4)?
    [OPUS wäre wohl optimal! :grübeln:]

    (DV-Ton ist überwiegend 32 kHz PCM statt 48 kHz - aber das ist ja egal...)

    Was soll ich nehmen? Will das i5-Ultrabook am Wochenende durchbrummen lassen..."CPU 100%" :D

    Was verliere ich sonst dabei (außer "minimal" Qualität)? Der DV-Timecode geht natürlich verloren, aber das macht ja nichts, da Scenalyzer die Einzelclips ja mit Timestamp im Dateinamen erstellt hat (ich hab hinterher nur die Syntax abgeändert)...

    8 Mal editiert, zuletzt von Gubel (4. Februar 2017 um 01:26)

  • Habe mich jetzt doch für MP3 192-320 kBit/s entschieden.
    MP4, H.264 8 Mbit/s, BFF interlaced, MP3 Audio.

    Habe auch herausgefunden, dass die Einstellung "Tune Grain" im H.264-Encoder dem Bild ganz gut tut - der Encoder "blurred" dann nicht. Man sieht normal dann eher "Kästchen", aber nicht bei ~8Mbit/s.

    So...das Lenovo i5-Ultrabook darf dann jetzt mal 2 Tage auf 100% "durch blasen"...:D

  • tach auch !

    Nein, nein,nein, nein und nö.

    DV ist schon komprimiert und hat einen "schwachen Farbraum" . Was das ist fragst Du bitte die Experten hier.
    Nebenbie ist es interkllaced BFF (Bottom Field First). Jede weitere Kompression verschwendet Qualy. Bei den heutigen HD Preisen (Das Gigabyte zu 35 cent.) ist der Strom zur Umwandlung schon fast teurer.(Das war ein Witz).

    Mein Rat : Lass es so wie es ist.

    Gruss BergH

  • Hmm...
    Inzwischen ist der Rechner bei 92%...

    Finde ich ist Ansichtsache...vorher waren alles zusammen ca. 450GB, danach ca. 150.

    Ich habe vor meine ganze Foto/Video-Sammlung mal auf einen Cloud-Dienst hochzuladen - da will ich nicht über 1 TB kommen...
    Dann muss ich mich mir mal für ne Woche den VDSL-Anschluss bei meinem Onkel "ausborgen" und dann ist das oben...

    Ich habs doch genau verglichen...ist wirklich "MARGINAL"... Früher haben die Leute DV als MPEG2 4Mbit/s (DVD) archiviert oder auf VHS überspielt...
    Wenn du wüsstest, was diese Medion-Kamera für ein "Matsch-Bild" liefert - da ist nicht viel zu verlieren.

    Zitat

    DV ist schon komprimiert und hat einen "schwachen Farbraum"


    Ich weiß ich weiß...aber schlechter wird er auch nicht mehr...

    Zitat

    Nebenbie ist es interkllaced BFF (Bottom Field First).


    Jop! Bleibt es auch!

    Und das DAR-Verhältnis habe ich auf 1,3636... eingestellt (bei XMR muss man die DAR angeben). DV-Camcorder haben nämlich definitiv ITU-4:3 (also 12:11-PAR)...NICHT "Generic-PAR".

    Zitat

    Umwandlung schon fast teurer.(Das war ein Witz).


    Ja...:lol: - 1-2 kWh gehen dafür drauf!
    Der Läppi hat ein 65W-Netzteil - wenn der Akku voll ist zieht er vielleicht 50W - und rennt 2-3 Tage...;)

    2 Mal editiert, zuletzt von Gubel (7. Februar 2017 um 00:05)

  • Ich habe meine DVs als DVD umcodiert, auf DVDRs gebrannt und jetzt kann ich die, und zwar 1:1, auf eine BDR brennen, da rückwärts kompatibel (man soll nur den PS nach TS umwandeln). Was kommt danach, die 4k BD, wird wahrscheinlich nicht mehr kompatibel.
    Aber wichtiger als die Formatfrage ist die Qualität der Arbeit, Sch... bleibt Sch.. auch oder besonders in High Definition :)

  • Noch was dazu...weil bergh mir da so schwer von abgeraten hatte...

    Ist längst abgeschlossen und ich habe mich von den Original-DVs getrennt.
    Encodiert mit ca. 8 MBit/s ABR, interlaced BFF, Preset "slow", Tune "Grain". Audio ABR 192kBit/s AAC.

    Ich hatte das Original und die Encodings einzelbildweise auf 200%-Ansicht nebeneinander verglichen und mir Konturen, Farb-Flächen und dunkle rauschende Stellen GENAU angesehen.
    Die Unterschiede sind SEHR sehr gering - auf den ersten Blick gar nicht zu sehen. Ich finde DV->DV sogar schlechter als DV->H.264 mit diesen Einstellungen...
    Somit ist das alles nur noch knapp 1/3 so groß.
    ...und das Argument, das dann (falls ich das irgendwann nochmal wollen sollte) nicht mehr so gut schneiden zu können zieht bei heutigen CPUs gerade bei komprimiertem SD-Material einfach nicht mehr...

  • Die Existenz einer GOP-Struktur mit P- und B-Frames ist die Einschränkung der Fähigkeit, Material verlustlos (ohne Decodieren und Encodieren) an beliebiger Position schneiden zu können. Mit CPU-Generationen hat das gar nichts zu tun. DV hat überall Keyframes, da kann man immer überall schneiden. Bei H.264 aber gibt es GOP-Grenzen nur alle paar Sekunden; wer da irgendwo schneidet, hat nach dem Schnitt das Problem, dass sich abhängige Frames auf ein Referenz-Frame bezieht, das nun weggeschnitten ist. Die Folge wären Decodierfehler. Einfach vorstellen kann man sich das in etwa, wenn man an eine Aussage wie "Ich hab zwei mehr als du!" denkt: Wer nicht weiß, wieviel der andere hat, kennt von beiden die Anzahl nicht.

    Nachträgliches Schneiden wird dann also nur möglich sein, indem man H.264-Video zunächst decodiert – und wenn es nur die GOP ist, durch die man schneiden will ("Smart rendering"); und dann wird man beim späteren erneuten Encodieren dort Qualität verlieren.

  • Moin!

    Das ist mir soweit ja schon klar. Klar, sowas wie "Smart Rendering", also "reines Schneiden", bzw. nur da neu codieren, wo man Effekte oder Titel einsetzt - DAS geht nicht mehr...es muss neu codiert werden dafür.
    Ich meinte eher, dass der Rechenaufwand, H.264 zu decodieren und neu zu rendern bei SD heute rechentechnisch doch ein Witz ist...

    Alte Foto-Digicams von vor 10 Jahren oder so haben ja oft in VGA als MJPEG-AVI gefilmt (meist mit PCM-Ton im 11 kHz :hm:). Das war auch Frame-Basiert, und für die gebotene Auflösung riesengroß. Heute wird ja praktisch nur noch in H.264 gefilmt (SD-Camcorder, Handys, moderne Digicams, usw... GoPro's...) - alles direkt als H.264.
    Deswegen ist das Neu-Rendern beim Editieren auch nix neues mehr...

    Warum sollte ich dann ausgerechnet altes SD-Material von einer Aldi-(Samsung-)-DV-Cam mit sowieso "mäßiger" Qualität als Frame-basierte "Riesen-Files" aufheben...;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!