Postproduktion allgemein Forum



Böser NTSC Fehler in MagicYUV und UtVideo



Fragen rund um die Nachbearbeitung, Videoschnitt, Export, etc. (div. Software)
Antworten
MLJ
Beiträge: 2193

Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von MLJ »

@All
In den Video Codecs "MagicYUV" und "UtVideo" ist ein fieser Fehler aufgetaucht der NTSC Material vom Band betrifft. NTSC VCR's haben das untere Halbbild zuerst und wenn man diese beiden Codecs dafür verwendet ist die Feldanordnung vertauscht, was bei HuffYuv und Lagarith nicht der Fall ist, die verarbeiten es korrekt. Ich habe die Autoren von MagicYUV und UtVideo schon darüber Informiert und kurze Beispiel Videos zugeschickt.

Solange das Material als "Top Field" wie bei PAL/SECAM reinkommt ist alles in Ordnung, aber kommt zuerst das "Bottom Field" dann wird es nicht richtig verarbeitet von MagicYUV und UtVideo.

Betroffene Versionen von MagicYUV und UtVideo: Alle (!)

Getestet mit NTSC VCR's von Samsung, Hitachi, Sony, Panasonic, JVC und Funai. Einigen Kollegen in USA ist das auch aufgefallen, nachdem ich ihnen vorher diese beiden Codecs empfohlen hatte. Es geht dabei NICHT um PAL 60 Material oder Geräte sondern um richtige NTSC Bandgeräte.

Um VirtualDub auszuschließen habe ich das mit anderen Capture Tools ausprobiert mit dem gleichen Ergebnis. Heute ist ja alles "Top Field First" in PAL/NTSC HD aber sobald diese beiden Codecs NTSC SD Material bekommen vom Band, kein Mini-DV, dann bekommen diese Codecs Probleme.

Merkwürdigerweise wird DV Material richtig codiert, nur vom Band gibt es mit MagicYUV und UtVideo Probleme wo HuffYuv und Lagarith keine Probleme haben und alles richtig codieren. Die Autoren von MagicYUV und UtVideo haben sich der Sache bereits angenommen und halte euch auf dem laufendem.

Nebenbei bleibt noch anzumerken, das der "v210" Codec von UtVideo auf YCbCr Systemen nicht funktioniert und nur ein grünes Bild zeigt, genauso wie der interne "v210" Codec von VirtualDub. Der Grund dürfte wohl sein, das beide "v210" Varianten von YCbCr nach RGB decodieren.

Cheers

Mickey
The little Fox.... May U live 2 C the Dawn



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

Hallo
Hab grad keinen NTSC Zuspieler an den Capturestationen.
Habe aber mit v210 keine Probleme.Zumeist setze ich hier Lagarith für ursprünglich Analoges ein.

Hast in VDub auch auf UYVY gestellt ?

UtVideo setze ich selten ein,schon eher Huffyuv_MT.
Um VirtualDub auszuschließen habe ich das mit anderen Capture Tools ausprobiert
Dann probiers mal mit Edius und da in UYVY oder YUV [YUY2] zum Bsp. über eine Canopus NX oder eine HD-Storm und da ab der Frontbay..oder liefere das Signal per Y/C oder YUV an eine BM Shuttle USB3 an den PC.

Das Blackmagic eigene Capturetool ist doch ganz zuverlässig.

Auch wenn ich direkt in Echtzeit NTSC to PAL wandle [Kramer SP-11D]
https://www.deluxecable.de/Kramer%20SP-11D/a-904035/
und mit einer BM Karte das Signal in SDI annehme,mir ist da noch nie BFF untergekommen.
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

Nachtrag

Habe auch "richtige" und echte NTSC Zuspieler...sehe aber weder "Grünbild" im Player noch dass diese Files in BFF vorliegen.

Im Header der Streams gibts auch keine Einträge obs nun in BFF / TFF oder in P vorliegen.
Viele Player aber auch NLE`s erkennen es falsch,kommt hier auch bei Edius ab und zu mal vor.
Dann legt man das File auf die Timeline und gibts Signal über die Canopus NX per Y/C oder YUV an einen echten studio-Kontrollmoni,da siehts man.

zur Sache

Zuspieler Panasonic AG
[andere Zuspieler sind auch noch vorhanden,u.A.auch ein Samsung S-VHS.

Quelle
VHS Band NTSC...Terminator 2.....Judgment Day

Signal in einen spez.DMR per FBAS...[wegen Jitter]...von da per HDMI zur
Blackmagic Studio 2 Capturekarte.

Capturetool
1x VDub 1.9.11 und 1x 1.10.4

Edius [hier auf diesem Rechner die ältere V.6.08] erkennts sofort und korrekt dass es in TFF vorliegt.

Avisynth arbeitet ja intern mit BFF...da muss man beim Einfügen natürlich TFF auswählen....da wird nichts in RGB angezeigt sondern YUV.

Anbei ein paar Screens...sind vermutlich hier nicht in der korrekten Reihenfolge anzuschauen.
Als Rar gepackt.
www.ww-consulting.ch/DL/Test_NTSC.rar

eine Frage....Könntest Du die Links zu Deinen Files die bei Dir im Player / VDub "grünfarben" angezeigt werden hochladen ?
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen



beiti
Beiträge: 5151

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von beiti »

Mal eine Verständnisfrage: Wie kann ein analoger VCR eine bestimmte Halbbildreihenfolge haben? Ich dachte, die entsteht erst, wenn es digitalisiert wird?
Interessantes rund um die Foto- und Videotechnik - fotovideotec.de
Der FotoVideoTec-Blog - fotovideotec-blog.de
Alles über Satellitenempfang - satellitenempfang.info



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

beiti hat geschrieben:Mal eine Verständnisfrage: Wie kann ein analoger VCR eine bestimmte Halbbildreihenfolge haben? Ich dachte, die entsteht erst, wenn es digitalisiert wird?
wer sagt da denn was anders ?

In DV gecapturt ists immer BFF.
Mit alten TV Karten,aber auch bei neuen Capturelösungen liegts danach immer als TFF vor.Egal ob ich einen 200 € Billigrecorder einsetze oder einen echten Feeder im 5-stelligen Bereich einsetze.

Meiner Meinung nach, sind VHS/S-VHS-Konsumer-Rekorder ala MediaMarkt und Co seinerzeit dafür gebaut worden, ein Fernsehsignal aufzuzeichnen und das aufgezeichnete Signal dann mehr oder weniger gut wiederzugeben. Als Edit-Player oder Feeder sind derlei Konsumer-Varianten sicher nur bedingt gut.

Aber ich komme vom Thema ab...bin gespannt wann ich die gewünschten Testfile beaugapfeln kann....mache jede Wette,sehe hier dann nichts von "Grünspan"

Beiti
beachte mal das Rotumrandete....Aufnahme-Schnittstart
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



WoWu
Beiträge: 14819

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von WoWu »

@Mickey

Es gibt bei Interlace kein "richtig" oder "falsch" in der Feldorder weil es dafür keine Normierung gibt und aus der analogen TV Technik stammt und nur darauf ankommt, ob Gerätehersteller die halbe Zeile "Null" berücksichtigen, oder nicht, also ob das Zählen der Zeilen bei "Null" oder Eins beginnt.
TMPGEnc z.B. benennt „A“ das obere Halbbild, während andere, wie z.B. die „Uleads“ Produkte, das untere Halbbild mit „A“ kennzeichnen.
Ampex hat 1962 damit angefangen, Fielddominanzen festzulegen. Die mechanischen Schnitte erfolgten damals auf F2. Daher mag man nun ableiten, dass F2 eigentlich die richtige Field-Order ist. Das andere „Lager“ aber hat argumentiert, die Field-Order und damit die nachfolgende Bilddominanz solle das Halbbild zeigen, das die erste sichtbare Bildzeile enthält.
In der 525- Zeilen-Technik (NTSC) beginnt der Zeilenaufbau in der Hälfte der Zeile 282 im „lower Field“ und endet in der halben Zeile 263 im „upper“ Field.
Das sind 487 digitale Zeilen. In der Praxis wird aber eine der zwei halben Zeilen nicht genutzt und es bleiben so 486 aktive Zeilen. Nur welche der halben Zeilen nicht genutzt wird, hängt nun auch wieder vom Hersteller ab.

So nutzte SGI in seiner Hardware die Zeile 20 im „upper“ Field nicht, wohingegen die ITU in ihrem Dokument R BT.656-4 empfiehlt, die Zeile 263 zu blanken. Aber 263, im Field „lower“, beginnt in der Zeile 1, im „upper“ Field.
Die meisten digitalen Formate im ATSC System, z.B DV, DVD nutzen sogar nur 480 Zeilen und lassen 6 Zeilen einfach weg, weil 486 nicht durch 16 teilbar ist, was aber für ein MPEG-Encoding nötig wäre.
Natürlich aber wieder die Frage, welche 6 Zeilen werden weggelassen?

Du siehst daran schon, dass es sich um keinen Herstellerfehler handelt, weil es den Herstellern überlassen ist, die Definition zu treffen.
Leider zieht sich das Debakel bis tief in den digitalen Bereich, obwohl die EBU in ihren Technical Recommendation R62-1998 und ITU Recomedtion BT.4702 versucht hat, dies zumindest für den 625 Zeilen Raum zu definieren.

Die Sony-DigiBeta bezieht sich auf diese Richtlinie und auf die SDI Festlegung und verlangt die ungeraden Halbbilder zuerst, also das „obere“ Halbbild, solange es sich um eine 625 Zeilen MAZ handelt.
Der DV-Standard jedoch besagt, dass immer das „untere“ Halbbild, also das „ungerade“ Field zuerst aufgezeichnet wird.
Die Sony-DVCAM-Mazen zeichnen daher mit einer andern Field-dominanz als die Digi-Beta auf und übertragen dies auch so über die Fire-Wire Schnittstelle.
Wird allerdings das Signal über SDI übertragen, ist es genau wieder umgekehrt.

Du siehst ... alles ist richtig -und doch falsch-
Bei der Feldorder musst Du heute noch überprüfen, welche Dominanz vorliegt.
Wir können nur dankbar dafür sein, dass es in REC 2020 nun endlich kein Interface Signal mehr gibt und diese leidige Thema endgültig Geschichte geworden ist.
Gute Grüße, Wolfgang

E-Book:
www.provideome.de



beiti
Beiträge: 5151

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von beiti »

Dass im Fall eines Schnittes auch ein analoger Videorecorder entscheiden muss, nach welchem Halbbild er schneidet, leuchtet ein.

Aber was passiert ganz praktisch, wenn man ein analoges Signal in einen AD-Wandler schickt? Ist in dem analogen Signal schon irgendwas drin, was dem AD-Wandler eine Halbbildreihenfolge vorgibt, oder fügt der AD-Wandler die Halbbilder immer nach seinen eigenen Vorgaben zusammen?
Oder kürzer gefragt: Wird die Halbbildreihenfolge des fertig digitalisierten Videos vom analogen Eingangssignal bestimmt oder vom Wandler?
Interessantes rund um die Foto- und Videotechnik - fotovideotec.de
Der FotoVideoTec-Blog - fotovideotec-blog.de
Alles über Satellitenempfang - satellitenempfang.info



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

WoWu hat geschrieben:@Mickey

Bei der Feldorder musst Du heute noch überprüfen, welche Dominanz vorliegt.
und genau das meinte ich oben als ich schrieb,dass hier das Signal ab Timeline von Edius über die Canopus NX per Y/C an einen echten [interlaced] Studio-Kontrollmonitor geleitet wird.
Dass man da auch noch weiteres beurteilen kann,sei nur so nebenbei erwähnt.
Oder kürzer gefragt: Wird die Halbbildreihenfolge des fertig digitalisierten Videos vom analogen Eingangssignal bestimmt oder vom Wandler?
Das habe ich mich seit jahrzehnten noch nie gefragt,DV ist hier egal mit welchem alten oder neueren Wandler,immer in BFF.
SDI immer in TFF.

Ist hier sehr wichtig immer zu wissen in welcher Fieldorder die Streams vorliegen,gebe ich in Avisynth die Fieldorder TFF nicht ein,geht Avisynth automatisch [weil intern so gehandelt] von BFF aus......Hurra wenn man das erst merkt wenn die Arbeit fast am Ende ist.
Dass im Fall eines Schnittes auch ein analoger Videorecorder entscheiden muss, nach welchem Halbbild er schneidet, leuchtet ein.
Im Beispielscreen gibts noch Schlimmeres zu lesen...und zu verstehen und dann schlussendlich richtig einzustellen.
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



WoWu
Beiträge: 14819

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von WoWu »

Der AD Wandler fügt die Halbbilder nicht zusammen. Der quantisiert nur, was er am Eingang angeboten bekommt. ... In dem Fall also Halbbilder.
Gute Grüße, Wolfgang

E-Book:
www.provideome.de



Skeptiker
Beiträge: 5874

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Skeptiker »

@WoWu:

Interessanter Beitrag (der von 22:31)!
Puhhh - was für ein Wirrwarr!

Ein kleiner Fehler ist mir aufgefallen:
WoWu hat geschrieben:... Der DV-Standard jedoch besagt, dass immer das „untere“ Halbbild, also das „ungerade“ Field zuerst aufgezeichnet wird. ...
Das untere wäre das gerade, wenn man oben mit 1 beginnt.



WoWu
Beiträge: 14819

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von WoWu »

:-))) Tja, .... wenn
Und was wäre dann die Zeile Null ?
Du siehst, es ist wirklich Schwachsinn .... und der hört bei dem Beschriebenen nicht mal auf denn bei der Erstellung einer DVD kommt es noch darauf an, auf welchem Display er dargestellt wird. Auf dem einen stimmt die Fidelerer und auf dem Röhrengerät stimmt sie nicht.

Wir sollten einfach nur froh sein, dass damit bald Schluss ist.
Gute Grüße, Wolfgang

E-Book:
www.provideome.de



Skeptiker
Beiträge: 5874

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Skeptiker »

WoWu hat geschrieben:... Wir sollten einfach nur froh sein, dass damit bald Schluss ist.
Da hast Du wohl recht! ;-)



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

Um aber wieder auf den ersten Thread zurückzukommen....
Die Autoren von MagicYUV und UtVideo haben sich der Sache bereits angenommen und halte euch auf dem laufendem.
Ja,das wäre schön.
Nebenbei bleibt noch anzumerken, das der "v210" Codec von UtVideo auf YCbCr Systemen nicht funktioniert und nur ein grünes Bild zeigt, genauso wie der interne "v210" Codec von VirtualDub. Der Grund dürfte wohl sein, das beide "v210" Varianten von YCbCr nach RGB decodieren.
Hat da ausser mir niemand mehr etwas beizutragen ?
Wäre interessant ob nur am System vom Fragensteller oder auch auf anderen Systemen nur grünes Bild angezeigt würde.
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen



MLJ
Beiträge: 2193

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von MLJ »

@Goldwingfahrer
Du hast recht, es sollte nichts ausmachen, aber das tut es. Was den "v210" Codec angeht so erscheint ein "Green Screen" nur auf reinen YCbCr Schnittsystemen. Bei "v210" von VirtualDub erscheinen die ersten 5 Frames, dann nur "Green" und die Ladezeit ist sehr lang. "v210" von UtVideo bringt nur einen "Green Screen", dann hängen meist die Systeme. Im übrigen habe ich mich auf VHS/SVHS spezialisiert und habe einen entsprechenden Park an Geräten was bestimmt nicht nur in der "200 Euro" Klasse liegt ;)

@WoWu
Ja, diese Halbbilder, nie genormt worden und jeder hat gemacht was er wollte. Ich kenne das "480" versus "486" Zeilen Problem bei NTSC, auch was "Zeile 0" betrifft. :) Wie schön waren da die DV Zeiten als alles BFF war, egal ob PAL oder NTSC ;) SD ist eben immer noch eine andere Welt.

@All
Nun, ich habe hier die Beispielvideos verlinkt. Einmal mit HuffYUV (CCESP Patch 0.2.5), Lagarith, MagicYUV und UtVideo. Die Sequenz wurde netterweise von Polygram Video USA freigegeben da ich einen ganzen Karton von denen gerade bearbeite, musste die Sequenz aber auf 20 Sekunden beschränken. Die Sequenz ist in der Länge gleich für alle verwendeten Lossless Codecs. HuffYUV-MT verhielt sich genauso wie der HuffYUV CCESP Patch 0.2.5 da er ein Derivat davon ist und auf dem gleichen Source Code basiert, wie Lagarith.

Hier die Technischen Details:
Capture Format: YCbCr 4:2:2 (YUY2)
NTSC Norm: 4.43
Frame Rate: 29.97 (Non-Drop Frame)
Resolution: 720x480
Interlaced: Yes
Field Order: BFF (Even/Lower Field First)
Audio: 48.000 Hz, 16 Bit, Stereo
Compression: MPEG Layer-3, 192 kbs
A/V Interleave: 1:1 (Every 1 Frame)

Es wurde jedesmal DIREKT die gleiche Sequenz von YUY2 nach HuffYUV, Lagarith, MagicYUV und UtVideo für sich gecaptured, keine Filter, keine RGB Konvertierung oder anderer Kram. Gecaptured mit VirtualDub (Versionen 1.6.19 -1.10.4) sowie anderen Capture Tools (Stoik, CaptureFlux, Debut, Logitech, Roxio) was das Ergebnis bei den Codecs NICHT veränderte. Alle Einstellungen in VirtualDub wurden NICHT verändert nachdem es zum ersten mal gestartet wurde, also default.

Weiterhin verschiedene Capture Sticks, Boxen, Karten, kein Unterschied. Auch andere Zuspieler haben NICHTS geändert, weder ein total billiger bis zu den teuren VCR's. Der Video Ausgang (FBAS/S-Video) hat ebenfalls nichts anderes bewirkt, auch kein abgreifen über ein Mischpult. Das ganze wurde auf einem frischem Windows 2000 (SP4), XP (SP3) und Win7 (64 Bit) probiert mit den aktuellsten DirectX Versionen (9-11) ohne zusätzlich installierte Programme, nur Windows, die Treiber für den Grabber, VirtualDub und die Lossless Codecs, einzeln und alle Lossless Codecs zusammen um auszuschließen das ein Codec einen anderen in die Quere kommt.

Alle Video Files wurden mit 7Zip (9.20) gepackt und müssen VORHER entpackt werden nach dem Download. Im Ordner "Codec Setup", ebenfalls hier verlinkt, findet ihr alle Einstellungen die bei den Codecs einheitlich verwendet wurden. Ich verwende für meine Karte wie viele meiner Kollegen die Drastic YCbCr Codecs die sich je nach anliegendem Signal am Eingang automatisch auf die richtige Field Order einstellen, jedoch verursachen die Drastic Codecs NICHT das Problem bei MagicYUV und UtVideo, da es auch bei den nativen Windows Codecs auftritt, wurde ebenfalls getestet.

Die Einstellungen der Drastic Codecs beziehen sich auf AJA, DVS und Optibase YCbCr Systeme. Liegt ein PAL/SECAM Signal am Eingang stellen sich die Drastic Codecs automatisch auf "Top Field First" und bei einem NTSC Signal auf "Bottom Field First". Nochmal: Die Drastic Codecs sind NICHT die Verursacher des Problems bei MagicYUV und UtVideo !

Eine andere Resolution als 720x480 (352x480, 360x480, 480x480, 640x480, 704x480) haben ebenfalls nichts bewirkt bei dem Ergebnis. Bin ich alleine mit diesem Problem ? Nein denn meine Kollegen und Freunde haben es ausprobiert und das gleiche Ergebnis erhalten. Das reicht von Freunden mit normalen USB Grabbern bis hin zu einigen Mastering Studios in USA.

Hier nun die Links: (Eben getestet und funktionieren)
Codec Setups
https://yadi.sk/d/9NzZJc3Hcumhx

Test Videos
https://yadi.sk/d/X5r8s7HVcurL6

Es macht übrigens auch keinen Unterschied ob die 32- oder 64 Bit Variante der Codecs eingesetzt wurde, nur so neben bei. Ich habe keine Erklärung dafür und bin mit meinem Latein am Ende da ich bereits alles an möglichen Problemen ausgeklammert habe. Ich habe alles detailliert an die Autoren von MagicYUV und UtVideo weitergegeben, jetzt sind diese am Zug. Ich bin darauf gespannt was die Experten von SlashCam heraus finden und bin auf eure Erklärungen gespannt.

Bleibt nur noch anzumerken das MagicYUV und UtVideo einwandfrei funktionieren wenn ein "Top Field First" anliegt wie bei SD PAL/SECAM und HD PAL/NTSC Material. Nur bei SD NTSC Material tritt dieses Problem bei diesen beiden Codecs auf, sonst nicht. Captured man mit HuffYUV oder Lagarith z.B. und verwendet DANN MagicYUV oder UtVideo als neue Kompression ist alles in Ordnung (!), nur eben nicht beim Capturen, da ist es eine verdrehte Welt. Würde sagen, nun seid ihr dran ;)

Cheers

Mickey

P.S.: Polygram hat diese Sequenz zwar freigegeben aber nur für Testzwecke. Schaut sie euch also an aber bitte nicht mehr.
The little Fox.... May U live 2 C the Dawn



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

Im übrigen habe ich mich auf VHS/SVHS spezialisiert
Hallo Mikey

glaube da kann ich mithalten..kennst Du noch die Anfang der 80er Jahren
in Hessen geänderten VHS Rekorder die mit doppelter Aufnahmegeschwindigkeit Filme aufgenommen hatten ?

Bin aber erst am Laden Deiner Clips und habe mir nur mal die Settings angeschaut...warum kein Fullrange,kannst ja eh nachher in der Postpro das wieder anpassen.

Und warum "288"..Screen im Anhang..ist doch nicht PAL,sondern NTSC,sollte doch da 244 eingestellt sein.

Und welches Programm für den Videoschnitt nimmst Du für
nur auf reinen YCbCr Schnittsystemen
Die meisten Grabber nehmen übrigens das Signal zumeist nur im Raum 16-235 auf.
----------------------

Nachtrag_
Bis auf den Magic kann ich alle hier am Arbeitsrechner in VDub öffnen und abspielen,den Magic habe ich auf den reinen Videorechnern,Beide sind jetzt aber an Avisynt-Scripts am werkeln.
Den Drastic wie auch ffdshow nur wenns unbedingt sein muss.
Die Idee mit dem verwenden des Drastic hatte ich im Doom9 Forum schon mal verkleckert.

Was mir auffällt.....warum capturst Du den Tonanteil in MP3 [korrekt Version MP 2.6]...der ist doch verlustbehaftet,weiter fällt mir an den 3 Clips auf dass schon bei dieser kurzen Filmlaufzeit die Länge des Audioanteils nicht zur Länge des Bildanteils passt.....okay...hier ist nur jeweils wenig...wie sieht denn das aus wenn die Filmdauer länger ist.....
Hast Du eventuell kein zeitkonstantes Signal?
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



MLJ
Beiträge: 2193

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von MLJ »

@Goldwingfahrer
80ziger Jahre.... ja, das waren Zeiten. Ich habe von diesen Teilen nur gehört wegen doppelter Geschwindigkeit aber nie probiert. Du mal probiert ? Du kommst aus Hessen ? Kleine Welt, da habe ich früher gelebt bevor ich nach Frankreich ausgewandert bin. Kennst du den OK in Offenbach und Gießen/Marburg ? Da habe ich mal einige Sachen von mir Produziert. War eine tolle Zeit, richtige Kassetten und so... ;)

"YCbCr Schnittsysteme" verarbeiten nur YCbCr (YUV) in 12 und 16 Bit, kein RGB, also alles in 12/16 Bit. Für Alpha Geschichten (32 Bit) wird das Material dann auf einem gesondertem System importiert und bearbeitet, das ganze nennt sich "Ingest System". Ich nutze das ältere Aist/Cinegy MoviePack Pro, andere die Cinegy Ingest Software, BBC z.B. und Drastic hat unter anderem die Media Reactor oder NXS Software für diese Systeme, genauso wie Acom. Weiterhin sind typische Ingest Systeme für einen direkten Playout und Vernetzung mit Servern ausgelegt damit mehrere Leute an einem Projekt gleichzeitig arbeiten können. Das Roh-Material ist dabei immer Uncompressed 12 (4:2:0) oder 16 (4:2:2) Bit.

Zu deiner Frage "Warum 288 bei HuffYUV und nicht 244 ?" ist es ganz einfach: HuffYUV betrachtet alles was über 288 Zeilen hinausgeht als Interlaced. Würde ich jetzt nur etwas mit 240 Zeilen (320x240, 352x240, 360x240) mit HuffYUV komprimieren wollen, dann müsste ich "240" statt der vorgegebenen "288" einstellen weil HuffYUV sonst die 240 Resolution als Interlaced interpretieren würde. Bei PAL/SECAM in 320x288, 352x288 und 384x288 müsste ich wieder "288" bei HuffYUV einstellen.

Die Zeilenangabe teilt HuffYUV nur mit, wenn es über diese Zeilen (288) raus geht was du bekommst, dann ist es Interlaced. Lagarith kommt ohne diesen Parameter aus und stellt sich selbst um.

Was die Einstellungen der Codecs angeht habe ich bewusst nichts außer "Interlaced" aktiviert. Die Drastic Codecs sind von sich aus auf 16-235 eingestellt und doppelt gemoppelt, was gibt das ? Genau, ein richtig schön milchiges Bild ;) Dürfte ein Alptraum werden das noch zu bearbeiten :)

So, nun gehe ich aber auf die 2 Meter, es reicht für heute und morgen ist ein langer Tag. Bin gespannt was du raus findest, man liest sich :)

Cheers

Mickey

Nachtrag: Den Audio Teil der Test Videos habe ich aus Platzgründen mit MP3 komprimiert. Gecaptured habe ich mit PCM ohne Komprimierung. In VirtualDub habe ich bei jedem Video die gleiche Sequenz selektiert, Video auf "Direct Stream Copy" gestellt und den Audioteil dabei komprimiert, mehr nicht. Alle Testvideos sind direkte Captures von YUY2 nach HuffYUV, Lagarith, MagicYUV und UtVideo, wurden also nicht erneut komprimiert sondern so, wie sie das anliegende Signal komprimieren.

Zeitsignal und Frame Rate ist konstant gewesen bei allen Videos also keine Inserted oder Dropped Frames sowie kein Audio Shift. Ich verwende den Lame 3.97 MP3 (ACM) Codec da der Fraunhofer Pro gerne die Bitrate etwas verändert, also statt 128 kbs bekommt man 127 kbs und so weiter. Nun, jetzt mache ich mich aber wirklich lang und wie gesagt, man liest sich hier im Forum :)
The little Fox.... May U live 2 C the Dawn



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

@Goldwingfahrer
80ziger Jahre.... ja, das waren Zeiten. Ich habe von diesen Teilen nur gehört wegen doppelter Geschwindigkeit aber nie probiert. Du mal probiert ?
Ja,ich habe noch 3 Stück aus dieser Zeit,hatte auch diverse Filme ab diesen Bändern zu digitalisieren.Inzwischen laufen aber alle nicht mehr,aber es gibt ja noch andere Geräte um solche seltene Aufnahmen ins digitale Zeitalter rüber zu retten.
Du kommst aus Hessen ?
Nein,wohne nicht in einem EU Land,gucke mal auf meine HP.

Rohmaterial ist hier zumeist in YUV 4:2:2 oder in UYVY 4:2:2

Mehrere Leute arbeiten hier auch nicht an einem Projekt.
Zur Anwendung gelangen Edius,[schon seit der ersten Version],Sony Vegas pro 12,Adobe CS6 [wegen der Super Zusammenarbeit mit Encore + Photoshop,After Effect] und dem Media Composer [weil früher die Schnittleute für die Nachwelt vergessen haben,die Streams richtig abzuspeichern,nämlich -nicht-in OP-Atom]

Capturegeräte,mal abgesehen von den alten Dingern,Canopus NX...HD-Storm,Viewcast Osprey,AJA Kona,Blackmagic Studio 2.
Und ein paar Zwischengeräte,von Snell & Wilcox,Kramer SP-11D und andere.
ein richtig schön milchiges Bild ;) Dürfte ein Alptraum werden das noch zu bearbeiten :)
Ein Albtraum ist das zwar zumeist nicht...wenn man das Signal von der Timeline an einem Prof.Studiokontr.Moni begutachten kann..ich geniesse es förmlich wenn andere User ihr Bild oder Ausschnitte aus einem Capture
Hochladen und ich sie dann auf den "Grauschleier" hinweisen darf.
Die Drastic Codecs sind von sich aus auf 16-235 eingestellt
das heisst ..Du "schneidest" das im Screen rot-markierte einfach weg ?
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



MLJ
Beiträge: 2193

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von MLJ »

@Goldwingfahrer
Nun, ich habe diese Probleme mit den "Roten Bereichen" nicht da diese bei mir nicht auftauchen :) Mein System ist kalibriert und die "Roten Bereiche" tauchen nur mit den nativen Codecs von Windows in VirtualDub auf, nicht mit den Drastic Codecs. Bevor ich die Drastic Codecs hatte habe ich in VirtualDub im Capture-Mode immer die beiden Begrenzungen aktiviert (Extend Luma Black Point / Extend Luma White Point) damit nichts im Weiß überstrahlt oder vollkommen im Schwarz absäuft.

Nicht alle Treiber die mit den Grabbern/Boxen mitgeliefert wurden sind optimal eingestellt, da muss man schon selbst Hand anlegen, was immer wieder bei zu hohen Gamma, Helligkeit und Kontrast Einstellungen schön zu sehen ist. Kurz um, ich schneide nichts weg da es nicht nötig ist.

Cheers

Mickey
The little Fox.... May U live 2 C the Dawn



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

Zitat MLJ
Nun, ich habe diese Probleme mit den "Roten Bereichen" nicht da diese bei mir nicht auftauchen :) Mein System ist kalibriert und die "Roten Bereiche" tauchen nur mit den nativen Codecs von Windows in VirtualDub auf, nicht mit den Drastic Codecs.
Die "roten Bereiche" sind keine Probleme.
Links rot ist der Bereich 0-16...und rechts von 235 bis 255.

Es gibt hier Zuspieler die liefern das Signal etwas über 235.
Nun will ich das ja erst nachträglich aufs richtige Level bringen zum Bsp.in Edius und nicht einfach beim Capturen "Abschneiden"

Stichwort:Drastic
Da habe ich letzthin bei einem Test so richtige Glotzaugen bekommen und ein paar silberne Haare haben sich gekringelt.
Ein Testvideo,gecapturt mit einer AJA Kona LHe [per SDI]..
der Drastic Decoder liegt ja nun "Systemweit" vor und krallt sich das Fiele.....aber der zeigt unfreundlicherweise weder den Weisswert noch den korrekten Schwarzwert im Videoschnittprogramm Edius an.
Auch nicht mit dem Hilfstool GraphStudioNext,im Player.
Hab dann den Drastic temporär deaktiviert und den DS Filter [decoder] von der AJA Website gepostet und installiert.
Fazit= Gesichtsmuskeln haben sich wieder entspannt.

Format,siehe Screen...2VUY
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



MLJ
Beiträge: 2193

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von MLJ »

@Goldwingfahrer
Die "Roten Bereiche":
Laut Avery sind das die Bereiche die "zuviel" sind und eine Übersteuerung anzeigen in VirtualDub, habe ihn vor langer Zeit mal dazu befragt. Es sind laut seiner Aussage nicht die Werte 0-16 bzw. 235-255 sondern das, was unter "0" oder über "255" raus geht. Sein Tipp war damals entweder den Capture Filter anzupassen oder "Extend Luma Black" und/oder "Extend Luma White" zu aktivieren, damit es nicht zu einer Übersteuerung kommt, also keine oder minimal "Rote Bereiche". Nun, Avery muss es wissen denn er hat VirtualDub geschrieben ;) Ich habe eine typische Histogramm Anzeige von VirtualDub hier angehängt mit den Drastic Codecs.

Zu den Drastic Codecs:
Ich habe auch schon v210/2vuy Files bekommen und verarbeitet, kann aber das Problem das du schilderst so nicht nachvollziehen. Wenn ich Files in v210/2vuy auf Festplatte abgeliefert habe, so gab es beim Kunden keine Probleme. Welche Einstellung hast du für die Hardware bei den Drastic Codecs genommen ? Möglicherweise ist da etwas anderes schief gelaufen. Edius kenne ich nur vom sehen, kann dazu also nichts sagen, aber in Premiere oder den anderen üblichen Verdächtigen war das kein Problem, auch nicht mit der Aist/Cinegy Software.

Frage: Hast du QuickTime installiert ? Wenn ja, welche Version und wie sieht das File in QuickTime aus ?

Cheers

Mickey
The little Fox.... May U live 2 C the Dawn
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

Frage: Hast du QuickTime installiert ? Wenn ja, welche Version und wie sieht das File in QuickTime aus ?
Natürlich ja....sieht genauso bescheiden aus wie bei mpc-HC.
Im Moment habe ich aber die AJA nicht mehr montiert ...mache ich mal wieder wenn mehr Zeit da ist.

Hier ein paar Screens vom besagten 2VUY File.
Bei drei Screens beachte die Mausspitze und die Anzeige im kleinen
"Capturer les Couleurs"...da französisch steht da natürlich nicht "RGB" sondern RVB....V=Verte also Grün.
www.ww-consulting.ch/DL/for_Mikey.rar
---------------------------------------

Zu der Sache mit den Leveln im VDub-Histogramm:

Keine Probleme machen wo keine sind!

Da hast Du wohl einfach was falsch verstanden - anders geht es nicht...
Natürlich sind das "die Bereiche die zuviel sind", weil sie nicht mehr angezeigt werden. Aber gespeichert als "Reserve" werden sie eben trotzdem...
Natürlich sind das "Übersteuerungen", weil sie nicht da sein *sollten* und nicht angezeigt werden, aber man kann damit Abweichungen korrigieren.

8 Bit sind 256 Werte. Bei RGB nimmt man eben 0 als Schwarz und 255 als Weiß. Bei YUV hat mans nur anders definiert - da ist eben 16 schwarz und 235 weiß (genauso bei den Sättigungsleveln der UV-Komponenten). Das wird bei der Konvertierung RGB<->YUV mit berücksichtigt.
Die "Reserve" wurde nur vorgesehen, um beim analogen Video-Capturing Abweichungen abfangen zu können, an sonsten braucht man die nicht.
Nimm eine Spielfilm-DVD und schau dir die Letterbox-Balken an: Die sind exakt "schwarz", entsprechend Y-Level 16, in RGB umgewandelt: 0. (und wenn sie tiefer als 16 liegen würden, wär's auch egal).

Schade, dass das Histogramm nur im Capture-Mode verfügbar ist, aber da kannst Du ja auch über "Source->Video file emulation" ein Videofile reinladen.

Hab mal dieses Bildchen erstellt:
http://fs1.directupload.net/images/141208/b4vxbooi.png
200x100 Pixel, links schwarz/rechts weiß, als PNG gespeichert (RGB).

Das kannst direkt im Capture-Mode als "videofile emulation" in VDub laden (VDub schluckt auch Bild-Files). Und was sieht man im Histogramm? Die Peaks sind EXAKT an den Enden des blauen Bereichs (die roten gibt's bei RGB nicht). Wenn dus jetzt in VDub z.B. als YUY2 speicherst, exakt das selbe (nur dass die Peaks jetzt bei 16 und 235 liegen, was du aber nicht siehst, da in den nun vorhandenen roten Bereichen nix ist)...

Wenn man YUV nach RGB umwandelt, wird umgekehrt alles unter 16 und über 235 einfach "abgeschnitten" und 16..235 auf 0..255 gespreitzt. Im anderen Fall umgekehrt.

VDub arbeitet also absolut korrekt. Sogar der interne "brightness/contrast"-Filter kann Werte aus den "Reserven" reinholen, wenn man den Kontrastregler leicht nach unten schiebt...nur mit dem "Levels" geht es nicht (der schneidet ab)...

=======

Was die Häckchen bei "extend luma white/black point" angeht:
Finger weg! Die machen nix anderes als den Kontrast stauchen und den YUV-Wert 0 auf 16 anheben, bzw. den YUV-Wert 255 auf 235 absenken...könntest du hinterher auch machen.
Das ist nur für "verkorkste Billig-Grabber" gedacht, die Mist produzieren (z.B. den YUV-Wert 16 fälschlicherweise auf YUV-0 legen und gar keine tatsächlichen Super-Schwarz werte liefern - da kann man damit dann den 0-Wert auf die korrekten 16 anheben).

Also: Häckchen raus, und über das tolle Histogramm freuen...alles cool, alles perfekt...
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen



dienstag_01
Beiträge: 13415

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von dienstag_01 »

8 Bit sind 256 Werte. Bei RGB nimmt man eben 0 als Schwarz und 255 als Weiß. Bei YUV hat mans nur anders definiert - da ist eben 16 schwarz und 235 weiß (genauso bei den Sättigungsleveln der UV-Komponenten). Das wird bei der Konvertierung RGB<->YUV mit berücksichtigt.
Klingt gut, ist aber falsch. Das wäre einfach nur Full Range. Ansonsten ist 16-235 auch 16-235, egal ob RGB oder YCbCr.
Mal so als kleiner Einblick:
(Ist ein kompliziertes Thema und sorgt hier immer wieder für Streit)



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

the coefficients for color conversion from and to RGB color format are different.

Warum wohl ists in Edius bei Y Cb Cr 0 bis 255 [also Superweiss[ genannt als Default.
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



dienstag_01
Beiträge: 13415

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von dienstag_01 »

Was willst du mit deiner Frage sagen?
Das ist einfach der Unterschied zwischen Legal und Full Range.
Warum was Edius als Default setzt, musst du dort nachfragen ;)



Goldwingfahrer
Beiträge: 1420

Re: Böser NTSC Fehler in MagicYUV und UtVideo

Beitrag von Goldwingfahrer »

Das ist einfach der Unterschied zwischen Legal und Full Range.
Ja so sehe ich das auch.
Aber auch dass es nicht nur -eine- Lösung gibt, also DIE NORM,denn dann gäbe es ja keine anpassbaren Einstellungen.
Digitalisierungen Normwandlungen Datenrettungen Restaurierungen



 Aktuelle Beiträge [alle Foren]
 
» Mac SSD Speed Messung?
von TomStg - Do 21:43
» Interessante Firmware-Updates für Sony Alpha 1, 7S III und 7 IV
von gammanagel - Do 21:28
» Sondergagen - Wer aufmuckt, wird nicht mehr besetzt
von stip - Do 21:25
» Neues SIGMA 50mm F1,2 DG DN | Art Objektiv wiegt 745g
von dienstag_01 - Do 21:21
» Deity Sidius TC Sync Software
von pillepalle - Do 19:58
» FCPX/Motion, DaVinci/Fusion... Tipps&Tricks
von Frank Glencairn - Do 19:25
» Nikon stellt NIKKOR Z 28-400mm f/4-8 VR Superzoom-Objektiv vor
von Jan - Do 19:16
» Red Komodo 6K + Gimbal, Advanced Ring Grip und viel Zubehör
von Sevenz - Do 19:01
» >Der LED Licht Thread<
von freezer - Do 18:53
» Was schaust Du gerade?
von Frank Glencairn - Do 18:46
» Camera Update 8.6: Viele neue Funktionen für Blackmagic Kameras
von slashCAM - Do 17:42
» Tieraufnahmen mit dem MKE600 + H1 Essential rauschen
von Swat - Do 16:06
» 4 Gründe hartes Licht zu nutzen
von ruessel - Do 15:45
» [gelöst] 3.5mm Klinkenstecker Überwurfmutter
von Skeptiker - Do 14:42
» Panasonic S5 - Allgemeine Fragen, Tipps und Tricks, Zeig deine Bilder/Videos usw.
von Darth Schneider - Do 13:49
» -SONY FX- Erfahrungsaustausch
von rush - Do 13:40
» AOC bringt 44.5" OLED-Riesenmonitor mit 98.5% DCI-P3
von MK - Do 12:07
» Adobe führt die neue Funktion "Structure Reference" in Firefly ein
von slashCAM - Do 10:54
» Exhuma - die Südkoreaner können erfolgreiche Filme drehen
von -paleface- - Do 8:46
» Was hörst Du gerade?
von roki100 - Do 0:22
» Sony A9 III im Praxistest - ein echter Überraschungscoup auch für Filmer
von Mantas - Mi 23:27
» Video Pro X stürzt beim Multi Cam Schnitt ab
von MisterX - Mi 21:47
» Uwe Boll: Wie man Filme produziert ohne pleite zu gehen!
von iasi - Mi 19:53
» Nach 7 Jahren mit der OG BMPCC finde ich das Bild noch immer schön.
von Darth Schneider - Mi 18:58
» Verschachtelte Timeline im richtigen Seitenformat
von Clemens Schiesko - Mi 18:43
» Untertitel in FCPX bei vorhandener Textdatei?
von R S K - Mi 18:34
» Deckenlicht mobil abschatten
von Frank Glencairn - Mi 17:31
» LUTs für Canon R6 Mark II
von TomStg - Mi 12:24
» RED versucht User nach Übernahme durch Nikon zu beruhigen
von dienstag_01 - Mi 11:52
» Entfesseltes Storytelling mit der Video-KI Sora?
von Frank Glencairn - Mi 5:54
» Slashcam 2001 - Das Internet vergisst nichts!
von macaw - Di 21:37
» Dehancer Pro - Filmsimulation auf höchstem Niveau
von Frank Glencairn - Di 18:54
» Wie Dune Teil 2 entstand - DoP Greig Fraser und Hans Zimmer im Interview
von iasi - Di 13:32
» 3 Body Problem - so verfilmt man heute Bücher
von stip - Di 8:30
» Neue Sora Version
von Frank Glencairn - Di 7:54