Es gibt Hatari auch als Blu-ray. Damit würdest du dir das Deinterlacen sparen, und die Bildqualität ist bei 1080p wesentlich besser.
DVD Sammlung transcodieren
-
-
Hui, da hat sich ja was angesammelt; keine Mail gekriegt, dass was Neues kam; hatte beim Ändern der Benachrichtigungsoptionen nicht auf Absenden geklickt *grummel*.
Das machst du, indem du weder --tff noch --bff verwendest. Weglassen, dann arbeitet x264 progressiv.
Hm, dann verstehe ich den Output von x264 nicht:
Code[2021-08-27][20:45:26] "C:\Program Files (x86)\Simple x264 Launcher\toolset\x64\x264_x64.exe" --output-depth 8 --crf 18.0 --preset veryfast --tune film --nr 1000 --vf crop:0,0,6,4/resize:720,576,1:1 --output C:\Users\Public\Videos\x264\Hatari.mkv --index C:\Users\Siegbert\AppData\Local\Temp\~026a09c4f17660e09837.ffindex C:\Users\Public\Videos\Todo\Hatari\Hatari.mkv [2021-08-27][20:45:26] [2021-08-27][20:45:27] ffms [info]: 720x576i 64:45 @ 25/1 fps (vfr) [2021-08-27][20:45:27] crop [info]: cropping to 714x572 [2021-08-27][20:45:27] resize [error]: swscale is not compatible with interlaced vertical resizingKein Paramter --tff, d.h. codieren als progressive, aber unten die Meldung "swscale is not compatible with interlaced vertical resizing". Bug in x264? Hier kommt übrigens auch das ffms her, das ich oben zitierte. Scheint als Library in x264 einkompiliert zu sein, um die Metadaten zu extrahieren.
Es gibt kein zweites Bild, das man wegwerfen müsste. Bei progressivem Video ist ein Vollbild zu einem Zeitpunkt aufgenommen worden; bei Interlaced sind zwei Halbbilder zu verschiedenen Zeitpunkten aufgenommen worden, wurden dann zu einem Vollbild vereint.
Was ich sehe ist, dass beim Anschauen von Einzelbildern der gerippten Datei mit MPC jedes 2. Bild identisch zum Vorgänger ist. Gaukelt mir hier MPC zwei identische Standbilder vor, die in Wahrheit aus 2 interlaced-Halbbildern zusammengesetzt sind?
Was ist denn beim Encodieren der DVD passiert, wenn der aus progressivem Filmmaterial interlaced MPEG-2 macht? Ist das danach wirklich interlactes Material, das bei meinem Rückweg deinterlaced werden muss? Oder ist das Flag nur da, um dem Standard zu entsprechen, die Bildinhalte sind aber noch progressive mit 2 identischen Bildern?
Gibt's eine bessere Methode sich das Material zur Analyse anzusehen als Einzelbilder in MPC?
DAR = Display Aspect Ratio = Breite : Höhe
SAR = Sample Aspect Ratio = entzerrte Breite (wie es dargestellt werden soll) : encodierte Breite (wie es gespeichert wurde)
andere AR-Abkürzungen: kommt drauf an, was die in dem Zusammenhang bedeuten sollen...Ok, so weit Einigkeit.
Zum Skalieren kann man AviSynth oder VapourSynth verwenden, die haben jeweils eine breite Auswahl unterschiedlicher Methoden. Ich nehme an, dass ffmpeg das auch alleine kann, kenne aber den Parametersatz nicht auswendig. Aber ffms(2) ist was anderes, ich kenne das als Quell-Plugin für AviSynth/VapourSynth, nicht als eigenständiges Programm.
Die Doku von Vapoursynth empfiehlt Bicubic, wenn man es nicht besser weiß. Ist das die Methode, die auch der TV in Hardware anwenden würde?
Wo es bei mir fehlt, sind die Colorspace-Möglichkeiten, die dort zur Auswahl stehen. Oder ist das beim Ausgangsmaterial Film dann immer derselbe, den man nehmen sollte?
Dort ist auch nichts erwähnt, ob die Ausgangsgröße irgendein Vielfaches von 2-8 sein muss. Also volle Freiheit beim Croppen auf krumme Werte? Sollte die Endgröße sich an bestimmte Beschränkungen halten?
Anstatt die variablen Ränder abzuschneiden, könnte man sie auch mit einem scharfen schwarzen Rahmen überdecken. Dann bleibt zumindest das Seitenverhältnis des Gesamtbildes gleich.
Hm, ja das könnte tatsächlich der einfachere Weg sein, die schwarzen Ränder kosten ja kaum Platz. Sollten die Schwarzen Ränder Vielfaches von irgendwas sein, damit die Grenze zum eigentlichen farbigen Bild nicht innerhalb eines Blockes liegt?
Für Videobearbeitung sollten mindestens immer 3 SSDs oder HDDs im System vorhanden sein. Den Simple x264 Launcher kannst du auf C: belassen, aber unbedingt für die Streams, einen Ordner auf ein anderes LW erstellen.
Werd ich bei meinem neuen Rechner so machen, auf der alten Kiste war die CPU der Flaschenhals.
Hatari.txt:
Das Preset: veryfast, würde ich auf „slow“ setzen. Das Tuning Film ist eigentlich für 35mm Film gedacht.
Aber wir haben ja Streams, ich glaube nicht, dass sich hierdurch Vorteile ergeben.
Aber wenn man z. Bsp. Zeichentrickfilme encodiert, dann kann man unter Tuning „Animation“ verwenden.
Angeblich sollen mit dieser Tuningeigenschaft, die Bilder flüssiger wirken.
"slow" werde ich mit dem neuen Rechner dann auch ausprobieren, bisher war "veryfast" für mich ein guter Kompromiss aus Größe und Encodierzeit.
Ob man Tuning "Film" noch verwenden sollte, wenn das Material schon durch diverse Vorbehandlung durch ist und nicht mehr der Scan direkt vom Film ist eine gute Frage.
Kann dazu jemand was sagen?
Animationsfilme habe ich keine auf DVD.
Cropping:
Mein Tipp, nicht croppen, dann wird dir auch vermutlich der Fehler nicht mehr angezeigt. Auch interlace stimmt vermutlich wieder.
Muss ich heute abend mal ausprobieren, sitze gerade nicht am Rechner für Filme.
Wenn du progressiv willst, dann musst du deinterlacen, wie du schon richtig schreibst mit QTGMC.
CUDA immer abschalten, das ist mehr für Spiele geeignet. 32 GB- oder 64 GB-RAM sind da sinnvoller.
Ob das Material wirklich interlaced ist, habe ich oben schon LigH gefragt. CUDA hat mein Rechner bisher nicht.
Kurze Frage:
Wenn du in den 70er- oder 80er Jahren Bilder mit einem Röhrenfernseher angeschaut hast, hast du dich damals über Interlacsestreifen und Banding aufgeregt. Damals wussten wir noch gar nicht, dass es so etwas überhaupt gibt.
Studio-Material war ja auch interlaced aufgenommen, also kein Problem. Gibt's Banding auch im reinen Analogbereich? Ich kann mich nur an Cross-Color/-Luminance-Probleme erinnern, die aber deutlich.
Bei Filmen kann ich mich an keine Artefakte erinnern, obwohl progressives Material als interlaced gesendet wurde. Keine Ahnung wie die das gemacht haben in der Analogwelt.
Wer braucht MPEG-2:
Eine DVD VOB-Datei ist MPEG-2. x264 im MKV-Container in deinem Fall, wird nochmals in VOB zu MPEG-2 umgewandelt.
Ist mir soweit klar. Was Pato gemeint hatte ist wohl, dass man MPEG2 als Archivformat auf Platte heute nicht mehr braucht. Deswegen scheint er auch neu zu encodieren.
Alles anzeigen/OT
"Ok wird doch Zeit auf neue Hardware zu wechseln. Auch x265 ist rein CPU-basiert ohne dass die GPU eine Rolle spielt, korrekt?"
es kommt darauf an.
- für pc gilt ein zweigleisiger weg:
. die CPU ist für videoerstellung für qualität (außerhalb) der üblichen video profile
. dekodieren bekommt diese meist auch problemlos hin
. die GPU ist bei den vordefinierten profilen effizienter und entlastet die CPU für andere aufgaben
. auch beim erstellen von videos (z.b.) streaming sind diese auch nicht mehr so schlecht
. für youtube & streaming bieten GPUs vorteile
. fürs videoarchiv sollte man vielleicht die CPU bemühen. (qualität vs. größe)
--> aufrüstung in betracht ziehen
Da reden wir glaube ich ein bisschen aneinander vorbei. Ich meinte mit x265 nicht den Standard H.265, sondern das Programm zum Encodieren. Soweit ich weiß, benutzt das keine HW-Beschleunigung. Du führst ja unten fürs Videoarchiv auch die CPU an. Da war meine Frage, ob es inzwischen qualitativ gleichwertige Encoder gibt, die GPUs benutzen und deswegen nochmal deutlich schneller sind als x265 bei vergleichbarer Qualität des Endmaterials.
Dass vergleichsweise schwachbrüstige Mobil- und Embedded-Geräte HW-Beschleunigung zum Decodieren brauchen ist klar.
Noch an Pro Jo: Bei Hatari würde ich mir die Bluray tatsächlich überlegen. Bei den meisten anderen Filmen, die auf DVD warten, würde sich die Neuanschaffung wohl nicht lohnen. Wäre auch ganz schön teuer, sind einige Schachteln voll ...
-
Ich habe mir auch einen Stream von Hatari, allerdings in voller Qualität (645 GB), erstellt.
Den Stream müsste ich nur noch für meinem USB-3-Stick zu H.264 wandeln.
Werde den komprimierten Stream auch auf die SSD von meinem Sat-Receiver speichern, dann brauche ich nicht jedesmal den DVD-Player einzuschalten.
Bei mir von der DVD, ist Hatari definitiv in interlaced. Hast du eventuell in progressiv gecaptured? Bei x264 vielleicht progressiv ausgewählt?
Es gibt auch DVD-Player, die interlace-Material in progressiv abspielen können. Die sind aber nicht billig.
Croppen:
Beim croppen, kann man folgende Werte verwenden, so dass der Encoder das ganze Bild nicht wieder neu berechnen muss.
Oben: 8 Pixel entfernen
Linke Seite: 8 Pixel wegschneiden
Unterer Bildrand: 12 Pixel entfernen
Rechte Seite: 16 Pixel wegschneiden
Das sind die Einstellungen für 4:3. Wenn du aber dein 16:9-Flag setzt, dann müsste das auch stimmen. Auf Kreis achten.
Color-Space:
Bei mir auf DVD ist Hatari in Full Range (0-255). SD-Material sollte aber immer 16-235 (BT.601) betragen.
Das ist eigentlich ein Fehler von den Hollywood-Studios. Aber egal.
Banding:
Das kann ich dir nicht sagen, ob es das auch bei analogen Farb-Signalen gab. Das könnte LigH wissen. Dafür sah man früher das Farbrauschen mehr. Zumindest bei schlechten Geräten. Color- und Luminance-Probleme, sollte man selbstverständlich korrigieren.
Ja, die 24- und 25 Vollbilder/s (progressiv) der meistens 16mm Kameras, mussten damals von den Sendern, für die Röhrenfernseher mit einem Filmscanner zu interlace gewandelt werden.
Ja klar, heutzutage nimmt man H.264- oder H.265-Codecs für Archivströme. Oder besser, professionelle 4:2:2-Codecs.
Auch klar, nur die schönsten Filme auf Blu-ray kaufen.
-
Ich habe mir auch einen Stream von Hatari, allerdings in voller Qualität (645 GB), erstellt.
Den Stream müsste ich nur noch für meinem USB-3-Stick zu H.264 wandeln.
Schick mit bitte nicht den Download-Link, ich brauche meine Internetverbindung in den nächsten Wochen auch beruflich.
Im Ernst: Was war denn da die Quelle? Hast Du Dir den 35mm-Film ausgeliehen und selber gescannt?
Bei mir von der DVD, ist Hatari definitiv in interlaced. Hast du eventuell in progressiv gecaptured? Bei x264 vielleicht progressiv ausgewählt?
Bei mir ist auch das Interlaced-Flag gesetzt, aber die Bilder sehen nicht interlaced aus, das ist ja das Merkwürdige. Ich habe die DVD einfach mit MakeMKV auf die Platte gerippt, was ja mit keiner Umcodierung verbunden ist, lediglich ein anderer Container wird benutzt.
Alles anzeigenBeim croppen, kann man folgende Werte verwenden, so dass der Encoder das ganze Bild nicht wieder neu berechnen muss.
Oben: 8 Pixel entfernen
Linke Seite: 8 Pixel wegschneiden
Unterer Bildrand: 12 Pixel entfernen
Rechte Seite: 16 Pixel wegschneiden
Das sind die Einstellungen für 4:3. Wenn du aber dein 16:9-Flag setzt, dann müsste das auch stimmen. Auf Kreis achten.
Croppen ohne Neucodierung wie geht das? Ist bisher komplett an mir vorbeigegangen, dass sowas gehen kann ...
Bei mir auf DVD ist Hatari in Full Range (0-255). SD-Material sollte aber immer 16-235 (BT.601) betragen.
Wie findest man das denn raus? Mediainfo spuckt zum Video nur das aus, keine Angaben zum Farbraum:
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Das kann ich dir nicht sagen, ob es das auch bei analogen Farb-Signalen gab. Das könnte LigH wissen. Dafür sah man früher das Farbrauschen mehr. Zumindest bei schlechten Geräten. Color- und Luminance-Probleme, sollte man selbstverständlich korrigieren.
Ich kann mir nicht vorstellen, dass Cross-Color oder -Luminance-Probleme entfernbar sind. PAL hat ja Farb- und Helligkeitsinformationen im Frequenzspektrum hintereinander übertragen. Wenn jemand mit kleinkariertem Hemd da saß, waren die notwendigen Frequenzen zur Darstellung so hoch, dass sie in den Bereich der anderen Information gelappt sind. Dort war das dann als Störung sichtbar. Zumindest habe ich das so in Erinnerung. Die Vorlesung in physikalischer Elektronik, die TV behandelt hat, ist aber etwa 30 Jahre her, kann sein, dass ich das nicht mehr so genau wiedergebe.
-
Jetzt muss ich lachen, einen Download-Link in dieser Größe, schicke ich dir selbstverständlich nicht.
645 GB bräuchte man da schon direkt von der Festplatte.
Außerdem müsste der Film noch mit einem guten 4:2:2-Codec umgewandelt werden, sonst würde dieser sicherlich in der Timeline fast nicht abspielbar sein, wegen der hohen Bitrate. Ist vom Original nicht zu unterscheiden.
Die Quelle ist ein sehr guter DVD-Player, mit dem ich die MPEG-2-Datei vom Film, nativ (mit dem 4:2:2-BM-Codec, 165 MBit/s) per YUV gecaptured habe. Auf den originalen 35mm Film, habe ich selbstverständlich keinen Zugriff. Alleine der 35mm Filmscanner, würde ein Vermögen kosten.
Deine Vollbilder:
Würdest du bitte einmal eine ca. 10 Sekunden-Sequenz von deinem Problemfilm irgendwo hochladen. Vielleicht können wir dir weiterhelfen.
In deinem Script steht:
3. [2021-08-27][20:45:27] ffms [info]: 720x576i 64:45 @ 25/1 fps (vfr, i ist definitiv interlaced.
Croppen ohne Neucodierung:
Ob das in interlace oder in progressiv ist, das liegt nicht am Interlaced-Flag.
Das Flag ist nur dazu da, dass das Bild auf 1024 x 576 Pixel auf das richtige Seitenverhältnis gedehnt wird.
Das Quellbild ist bei PAL immer 720 x 576 Pixel. Das 16:9-Flag korrigiert in diesem Fall die Bildproportionen (Seitenverhältnis).
Wenn du das Bild z. Bsp. auf 640 x 480 Pixel croppen würdest, dann müsste der Encoder das ganze Bild wieder neu berechnen, denn es fand ja eine Bildverkleinerung statt. Bei 720 (704) x 576 Pixel ist die Bildauflösung aber besser. Beim Resizen wird ja sowieso neu berechnet.
Das MakeMKV-Tool hat wohl keine „Smart Rendering-Funktion“?
Mediainfo müsste das so anzeigen:
Color space: YUV (BT.601) und Color range: Limited (16-235).
Da aber YUV bis 1920 x 1080 Pixel reicht, kann der Farbraum auch BT. 709 betragen.
YUV ist technisch besser als ein digitales Firewire-Interface bei SD-Material. Nicht zu glauben, ist aber so.
Die Cross-Color oder -Luminance-Probleme, müsste man heuzutage mit den diversen Tools, gut in den Griff bekommen.
Es sei denn, das Bildmaterial ist wirklich äußerst schlecht. Farbe, Kontrast (Flankensteilheit) und Helligkeit sind gut korrigierbar.
Ja, das karierte Hemd ist ein gutes Beispiel von dir Coco Chanel.
-
"Da reden wir glaube ich ein bisschen aneinander vorbei. Ich meinte mit x265 nicht den Standard H.265,
sondern das Programm zum Encodieren. Soweit ich weiß, benutzt das keine HW-Beschleunigung."
vielleicht,
da sollten wir nochmal differenzieren:
1. Hardwarebeschleunigung für den Encodierungs-Akt
die Programmierer tun sicher ihr möglichstes, um ihren Codec so schnell wie möglich zu bekommen.
spezielle GPU-beschleunigung wie CUDA & OpenCL konnte ich auf die schnelle nicht finden.
2. Hardwarebeschleunigung für den Decodierungs-Akt
Videos sollten natürlich auch so erstellt werden, dass die Wiedergabegeräte es ohne Probleme wiedergeben können.
man kann den Codec über die Spezifikationen optimieren, das werden aber die Hardware-Chips nicht vertragen.
bzw. die Hardwarebeschleunigung-Profile setzen dir ein Qualitätslimit.
darum sollte dieser teil der "Hardwarebeschleunigung" auch nicht aus den Augen verlieren
und fließt auch in die Wahl des Encoders mit ein.
laut deinen Text geht es primär um #1, darum steig ich hier etwas tiefer ein.
1.b
die Beschleunigung die du willst wird meist mit CUDA* oder OpenCL* umgesetzt.
(*ich weiß die Angabe ist nicht 100% richtig, aber nicht alle verwenden die Namen von den Encodereinheiten)
zu OpenCL konnte ich nichts finden, da hat noch keiner was gebaut.
da bleibt uns nur noch CUDA/NEVNC, die nur auf nVidia-Karten laufen.
hier ist eine kleine Liste auf Wikipedia, leider sind die h265 angaben unvollständig.
die Verbreitung ist gefühlt gering, da sicher irgendwelche seltsamen nVidia-Nutzungs-Lizensen* beachtet werden müssen.
(*wer dazu genaueres weiß, der möge doch bitte einen kleinen Infoblock dazu schreiben)
prinzipiell würde ich erst mal sagen, generiere dir ein Testclip, mit Problem-Szenen und teste die Qualität erst mal selber.
ab der GeForce Generation "1660/20XX Super" soll der Hardwareencoder so gut sein wie das 'medium'-Preset vom x265-Encoder
ich würde mal sagen für Live-Streaming wäre es sicher interessant
(wenn nur irgendjemand mal h265 unterstützen würde^^),
aber für Encoding die Qualität/Effiziens/Dateigröße wichtig ist, wie das Preset 'slow' oder höher bieten soll,
dann ist der x265 halt langsamer und besser.
---
ich versuche mal ein kurzes Fazit:
für potenzielles Live-Streaming, YouTube-Content oder wem die Dateigröße nicht so wichtig ist,
der kann nVidias NEVNC ruhig verwenden.
für statische Objekte wie Video-Archive oder für Leute denen Qualität/Effizienz/Speicher eine höhere Priorität hat,
die sollten sich lieber die Zeit nehmen und mit x265 in den höheren Profilen (ab 'slow') codieren.
ich hoffe ich konnte mein Halbwissen soweit sortieren,
dass du dir genügend Nährwerte, für einen Lerneffekt, herausziehen konntest.
-
Die Quelle ist ein sehr guter DVD-Player, mit dem ich die MPEG-2-Datei vom Film, nativ (mit dem 4:2:2-BM-Codec, 165 MBit/s) per YUV gecaptured habe. Auf den originalen 35mm Film, habe ich selbstverständlich keinen Zugriff. Alleine der 35mm Filmscanner, würde ein Vermögen kosten.
Meinst Du das lohnt sich? Die Fehler der Encodierung beim Erstellen der DVD sind ja trotzdem drin. Und x264 sollte das Rechnen in den Farbraum, mit dem es umgehen kann, doch automatisch machen; nur halt nicht mit dem ganzen Film auf einmal, sondern halt mit so vielen Frames wie es zum Encodieren braucht.
Deine Vollbilder:
Würdest du bitte einmal eine ca. 10 Sekunden-Sequenz von deinem Problemfilm irgendwo hochladen. Vielleicht können wir dir weiterhelfen.
http://shareplace.org/?E31CA2F013
Ist mit MKVToolnix ausgeschnitten aus dem MKV, das MakeMKV ohne Umcodieren von der DVD gerippt hat.
Das MakeMKV-Tool hat wohl keine „Smart Rendering-Funktion“?
Nope, das bringt den Film nur von Disc in einen anderen Container.
Colorspace: YUV (BT.601) und Color range: Limited (16-235).
Da aber YUV bis 1920 x 1080 Pixel reicht, kann der Farbraum auch BT. 709 betragen.
Da muss ich einsteigen, wenn ich jetzt doch mit Vapoursynth-Filtern anfange; bisher kriege ich das noch nicht sortiert. Z.B. ist doch YUV nur während der Filterei/Codiererei in Benutzung danach geht es immer auf 4:2:0; oder täusche ich mich da und man kann auch mit besserem Farbraum oder 4:2:2 in MKVs abspeichern? Wie sieht's dann mit HW-Decodierern aus, schlucken die das?
2. Hardwarebeschleunigung für den Decodierungs-Akt
Videos sollten natürlich auch so erstellt werden, dass die Wiedergabegeräte es ohne Probleme wiedergeben können.
Siehe meinen letzten Absatz oben bzgl. Farbräumen. Ich werde mal bei den Box-Foren anfragen, welche Einschränkungen die HW-Decodierer in den an die ARM-Chips angeflanschten Codecs hier haben.
die Beschleunigung die du willst wird meist mit CUDA* oder OpenCL* umgesetzt.
(*ich weiß die Angabe ist nicht 100% richtig, aber nicht alle verwenden die Namen von den Encodereinheiten)
zu OpenCL konnte ich nichts finden, da hat noch keiner was gebaut.
da bleibt uns nur noch CUDA/NEVNC, die nur auf nVidia-Karten laufen.
Das ist doof, ich liebäugele mit den AMD-APUs und die haben ja AMD-Grafik drin, nicht Nvidia. Da fängt's ja mit aktuellen Karten momentan >400EUR an. Da bleibe ich wohl doch bei x265 und CPU (wie Du ja auch oben vorgeschlagen hast).
prinzipiell würde ich erst mal sagen, generiere dir ein Testclip, mit Problem-Szenen und teste die Qualität erst mal selber.
Testclip ist erstellt (siehe Link oben) und ich habe auf doom9 einen Thread von 2015 gefunden mit Verweis auf hier, wo ein Avisynth-Skript steht mit dem das Bild in Halbbilder zerpflückt wird und so eindeutig herauszufinden ist ob es progressiv (aabbccdd), interlaced (abcde) oder Telecine ist (LigH hat damals schon in dem doom9-Thread gepostet
). Da ich eigentlich dann gleich auf Vapoursynth umsteigen wollte, versuch ich gerade mir die Toolchain dazu aufzusetzen, um die Analyse endlich vernünftig durchführen zu können. Schönes Wetter, Familie, Geburtstag, Hochzeitstag ... wird wohl nächste Woche werden. -
Danke für dein kurzes Test-Video. Interlace-Streifen sieht man wirklich nicht. Aber ich schätze, dass es doch interlaced ist.
Bei schnellen Bewegungen, wäre vermutlich mit progressiv nicht so unscharf abgebildet worden. Es zählt aber, was du mit AviSynth herausfindest.
Ich habe mir einmal mein Hatari-Video angesehen, es sieht auch so aus wie deins, hat auch keine Interlace-Streifen. Ist aber trotzdem interlaced.
Ich muss mich korrigieren. Diese 645 GByte, waren von einem 720p-Stream. Das SD-Video von Hatari hatte „nur“ 186 GByte bei 8 Bit Farbtiefe.
Bin versehenlich in eine andere Zeile geraten.
Die Bitrate mit 165 MBit/s brauchst du selbsverständlich nicht übernehmen.
Das mache ich nur für mich, da ich so bei der Weiterverarbeitung die beste Bildqualität erhalte.
Bei 4:2:2 ist es ja möglich, bis zu 200x ohne Qualitätsverlust zu rendern.
Farbraum:
Der Farbraum wird leider nicht vom originalen Video mit übernommen, diesen muss man getrennt einstellen.
Eine Art Smart Rendering-Funktion:
Dann in einen anderen Container, das sollte eigentlich nicht sein.
4:2:0:
Ja, das ist richtig, das Endprodukt ist bei SD und HD bis 1080 immer in 4:2:0. UHD und das professionelle 4k sind entweder in 4:2:2 oder sogar in 4:4:4.
Man darf aber nicht den Farbraum, mit dem Farbspektrum verwechseln. 4:2:2 ist für die weitere Bildverarbeitung gedacht.
Zum Beispiel, wenn man viel rendern muss, dass die Bildqualität gleich bleibt.
Normal ist bei SD-Video:
Farbraum 601 und Farbspektrum 16-235. Bei den Hollywood-Filmen liegen zwar viele DVDs im Farbraum 601, aber im Farbspektrum 0-255 (RGB) vor.
Das ist für SD-Material eigentlich nicht korrekt, aber mich stört das auch nicht. Ansonsten ist ausschlaggebend, wie der Camcorder aufzeichnet.
Mein Hatari Test-Video:
Habe das Video auf die Schnelle mit VDub und mit H.264 erstellt. Farbpixelversatz +1 Pixel nach rechts. Der Farbraum ist BT.601.
Das Farbspektrum habe ich bei 0-255 belassen. Hatari wurde leider in schlechter Bildqualität abgescannt.
http://shareplace.org/?83509B1913
Dein Video stimmt technisch einwandfrei. Etwas hell, aber wenn du keine weitere Videobearbeitung machen willst, dann lasse es so mit MPEG-2.
H.264 (mkv) ist aber wesentlich effektiver, da bräuchte man nur bis 3.500 Kbps.
Für eine Videobearbeitung, würde ich dann doch eine 4:2:2-Qualität bevorzugen.
-
tach auch !
Zu den unmöglichen Dateigrößen= Schwach Sinnig
Hatari vor ein paar Tagen aus dem DVB-C aufgenommen hat unter 20 GIG (mit Werbung und vor un Nachspann) Alles darüber ist Augenwischerei.
In SD siwieso. Wie sagt der große Phülosooof BergH: Man kann aus Scheisse kein Gold machen, auch wenn man es hochskaliert.
(Oder ein lauter Auspuff macht aus einer Scheisskarre nur eine LAUTE Scheisskarre)
That said. Die Bluray wird x-mal besser aussehen und auch nicht mehr, als 25-45 GIG haben.
Also lass die DVD in Ruhe und nimm das nächste Mal aus dem TV auf, oder kauf die Blúe-Ray.
Alles andere führt nur zur Klimaerwärmung ohne Gewinn beim Bild.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!