Ich möchte meine alten VHS-Videos digitalisieren. Dazu nutze ich neben einem guten Videorekorder eine Blackmagic Infinity Pro. Zur Bildstabilisierung habe ich mit auch mal einen DMR zugelegt. Leider sind einige Videos inzwischen schon so schlecht das die Digitalisierung immer wieder aussetzt, auch wenn ich den DMR dazwischen schleife. Der Grund dürfte wohl hauptsächlich in den Sync-Signalen liegen. Ich denke man müsste die kompletten Signale, ausser dem eigentlichen Zeilensignal "einfach" nur neu erzeugen und mit den Nutzdaten umschalten. Dadurch bleibt das eigentliche Bild natürlich schlecht, aber zumindest liese es sich genau so auch digitalisieren und dann ggf. mit Digitalfiltern nachberbeiten. Vom Prinzip her arbeiteten ja die früheren Macrovision-Killer so. Leider scheitert selbst der Klassenprimus dieser Teile, der Elro VL300 an dieser Aufgabe. Ein wenig Hoffnungsvoll habe ich dann nach dem EVL VKD 7002 gesucht aus dessen Beschreibung hervorging "Der VKD 7002 eliminiert zuverlässig alle derzeit bekannten Kopierschutz-Störimpulse auf Videokassetten. Im Gegensatz zur üblichen Ausblendtechnik schaltet der VKD 7002 gezielt die sichtbare Bildinformation durch, während sämtliche übrigen Signale bearbeitet bzw. neu generiert werden." Leider sind die Geräte nicht mehr erhältlich und das Thema ELV ist so eine eigene Sache für sich... Beitrag "Entwickelt und produziert ELV wirklich selbst Chips?" Aber vom Prinzip her wäre das genau was ich suche. Nun ist dieses Teil aus dem Jahre 1996 und inzwischen gibt es ja zum Glück ganz andere Möglichkeiten für uns Hobby-Elektroniker :-) Hat jemand eine Idee wie man das z.B. mit einem Arduino als Steuereinheit aufbauen könnte? Ich müsste sowohl PAL als auch NTSC Signale erzeugen können. Vom Grundprinzip kann man es ja so machen wie bei den alten Macrovision-Dekodern, das Eingangssignal kommt über eine Puffer-Stufe auf einen Umschalter (4053) welcher zwischen Eingangssignal und Sync-Signalen hin- und herschaltet. Über eine Sync-Impulserkennung am Eingangssignal (welche man ja sogar ggf. mit einem in einem uC enthaltenen A/D Wanlder erkennen könnte, oder aber ganz klassisch mit LM1881 und NMI am uC) wird dann zwischen vom uC neu erzeugtem Sync-Signal und dem Video-Nutzsignal umgeschaltet, sodass sich am Ausgang auf jeden Fall immer ein sync-sauberes Bild ergibt. Der Ausgang wird dann nochmal mit einer kleinen Verstärkerschaltung versehen (Darlingtonstufe oder OpAmp). Ich muss leider zugeben das ich was das Thema FBAS-Signal angeht ein ziemlicher Laie bin und da etwas Nachhilfe gebrauchen könnte. Man muss ja auf jeden Fall H-Sync Impulse erzeugen vor dem Start jeder Zeile und unten am Bildende einen V-Sync-Impuls. Dann gibt es da noch die Halbbilder (odd/even Felder) die auch irgendwie erkannt werden müssen. Und was sonst noch?
:
Bearbeitet durch User
Beim CCIR Signal (also, das was wir PAL nennen), gibt es zwei Halbbilder mit je 312,5 Zeilen. Das heisst, das beide Bilder eine halbe Zeile haben - das grösste Problem beim Erzeugen eines kompatiblen Rasters. Ein Mikrocontroller muss das also im Blick behalten. Mit einem Timer, der in 64µs abläuft und eine PWM von 4µs erzeugt, hat man eigentlich bis auf die letzte Zeile schon mal das HSync erledigt. Der Timer muss einmal pro Frame synchronisiert werden und zählt am besten die Zeilennummer mit, um seine eigene Periodendauer für die letzte Zeile anzupassen und auch, um die ersten 25 Zeilen für die Austastlücke zu produzieren. Das Synchronisieren könnte man mit einem LM1881 machen, muss aber seine Eigenarten im Blick behalten. Es gibt nur einen Composite Sync Ausgang und das Burstgate, das zu spät kommt. Allerdings hilft der VSync Ausgang und auch das Even/Odd Signal für die Frameerkennung. Man braucht also einen Umschalter, der zwischen dem Synclevel und dem Videosignal wechselt, um ein eigenes Synchronraster einzublenden. Ein 4053 sollte das können. Das Vertikalsync ist etwas komplexer, dazu guckt man sich am besten mal die Beschreibung des CCIR Signals etwas genauer an. Generell sollte es für einen MC nicht schwierig sein, man sollte aber die Timerhardware benutzen, weils sonst jittert. Auch darf man den Inhalt der Zeile und vor allem den Burst nicht beschädigen, weil sont die Farbe leidet oder abschaltet.
:
Bearbeitet durch User
Matthias S. schrieb: > Man braucht also einen Umschalter, der zwischen dem Synclevel und dem > Videosignal wechselt, um ein eigenes Synchronraster einzublenden. Ein > 4053 sollte das können. Nicht alleine. Man braucht auch einen Video-Buffer dahinter. Früher(tm) gab es von Maxim eine ganze Baureihe von Video-Multiplexern (z.B. MAX453), die also praktisch 405x und Buffer in einem Gehäuse vereint haben, die haben sowas recht leicht gemacht, waren allerdings auch relativ teuer. Leider gibt es die schon ewig nicht mehr zu kaufen. > Generell sollte es > für einen MC nicht schwierig sein Die Generierung eines vollständigen PAL- oder NTSC-Frame ist tatsächlich selbst mit einem AVR8 relativ leicht machbar. Aber leider ist das nur weniger als die halbe Wahrheit. Das Problem ist nämlich, dass man ja nicht frei generieren kann, sondern sich natürlich auf die Quelle synchronisieren muß, deren Payload man schließlich in diesen Frame einblenden will. Und da wird das Bein mit einem AVR8 doch recht dicke... Wie willst du dich damit genau genug auf den Farbburst der Quelle synchronisieren? Das ist theoretisch und praktisch völlig unmöglich. Auch mit einem µC in der 100MHz-Klasse ist das noch fast unmöglich. Was man da braucht, ist Hardware, nämlich einen recht komplexen Taktgenerator mit vielen, teils sogar recht widersprüchlichen Anforderungen. Die Entwicklung dieses Teils ist der eigentliche Aufwand bei der Sache. Dagegen verblasst alles andere völlig.
Angehängte Dateien:
-
vsync.png
5,4 KB
c-hater schrieb: > Nicht alleine. Man braucht auch einen Video-Buffer dahinter. Früher(tm) Warum denn? Was bietet der Buffer für Vorteile und vor allem wie arbeitet der? Kann ja doch eigentlich nur digital sein, also A/D wandeln, speichern und wieder D/A wandeln? Und vermutlich würde man das heute eher alles direkt im uC machen? Und reichte es eine Zeile zu buffern, oder ein Feld oder ein ganzes Bild? > Die Generierung eines vollständigen PAL- oder NTSC-Frame ist tatsächlich > selbst mit einem AVR8 relativ leicht machbar. Aber leider ist das nur Ich finde natürlich extrem viel zu diesem Thema im Netz, so viel das ich es kaum einordnen kann was davon hilfreich ist oder nicht. Ich will auch nicht einfach was nachbauen sondern schon gern verstehen was ich da tue :-) Von Rhode+Schwarz habe ich was gefunden was ganz gut ausschaut: https://www.rohde-schwarz.com/at/file/fernseh-standards_0756-6981-11.pdf Was hälst Du davon als Grundlage/Refernz zu diesem Thema? > Das Problem ist nämlich, dass man ja nicht frei generieren kann, sondern > sich natürlich auf die Quelle synchronisieren muß, deren Payload man Das mit der Phasenverschiebung der Signale hab ich noch nicht gechecket, nur eine Ahnung was damit verbunden ist. Aber wenn ich einfach dafür sorge das der Burst (hier geht es wohl schon los damit, oder?) und auch das gesamte analoge Signal so kommen wie es ist, sollte es doch passen? Oder müssen die Zeilen auch untereinander synchron sein? Um mal am Bild zu bleiben (ein beliebiges aus den tausenden rausgefischt), was sieht man darin? Im unteren Teil die letzten Zeilen des 1. Halbbilds, das sind dann ja H-Sync Signale, richtig? Und der Bildinhalt hört da mit Zeile 310 auf und ab 311 bis 313 kommen dann diese ominösen 2,5 Zeilen (5 Pulse), dann kommen 2,5 Zeilen (5 Pulse) mit einem inverterten H-Sync die wohl dem Gerät den Wechsel zum 2. Halbbild und somit den Strahlrücklauf anzeigen? Aber braucht es dafür nicht sogar 1 ms, was helfen da 12µs?
:
Bearbeitet durch User
Olli Z. schrieb: > Leider sind > einige Videos inzwischen schon so schlecht das die Digitalisierung immer > wieder aussetzt Ich würde einfach eine Auswahl treffen und die dann entsorgen. In der Regel sind alte Videos oder Schmalfilme weder qualitativ noch regiemäßig der Bringer, so daß sich eine Archivierung lohnen würde. Es sei denn, Du willst viel Geld und Zeit darin investieren, um alte Geräte zu kaufen oder etwas selber zu entwickeln. Die Erfolgsaussichten würde ich eher als gering einschätzen. Es sind ja keine wertvollen Gemälde, die man restaurieren lassen kann.
c-hater schrieb: > Man braucht auch einen Video-Buffer dahinter. Ich vermute mal, es ist ein (Strom-)verstärker gemeint, weil man die 4053 ja nicht so hoch belasten kann mit einer 75 Ohm Senke. Also noch einen Emitterfolger dahinter, um das Ziel treiben zu können. c-hater schrieb: > sondern > sich natürlich auf die Quelle synchronisieren muß Ja sicher. Olli möchte das mit einem LM1881 machen, ich hatte dafür z.B. auch den BA7046F verwendet. c-hater schrieb: > Wie willst du dich damit genau genug auf den Farbburst der Quelle > synchronisieren? Das ist theoretisch und praktisch völlig unmöglich. Das will hier niemand. Olli will lediglich die Synchronsignale verbessern und in die Videozeile nicht eingreifen. Deswegen ja der 4053, der nur die Syncsignale einblendet und für Burst und Bildinhalt wieder auf die Originalquelle zurückschaltet. Übrigens ist das natürlich nicht unmöglich. Eines meiner Wahnsinnsprojekte aus den 90ern war ein TimebaseCorrector für eine Zeile. Das Dings arbeitete mit synchronen 17,74 Mhz als Takt (4*Fsc), gewonnen aus dem Burst, dann vervierfacht. Damit wurde dann ein schneller 8-Bit ADC (AD9048), ein Zeilenspeicher mit HM63021 und ein Flash DAC angetrieben. Der HM63021 hat direkt Burst und Farbdaten gespeichert und hatte getrennte Schreib- und Leseregister und -zähler. Olli Z. schrieb: > Was hälst Du davon als Grundlage/Refernz zu diesem Thema? Ich halte das für recht brauchbar, wenn man das nicht von früher kennt. Man sieht doch ganz gut, wie es aussehen muss und kann danach prorgrammieren. @PeDa: Wir kennen jatzt schon lange deinen Abscheu gegen ältere Technik. Musst du das in jedem Thread wiederholen?
:
Bearbeitet durch User
Matthias S. schrieb: > Mit einem Timer, der in 64µs abläuft und eine PWM von 4µs erzeugt, hat > man eigentlich bis auf die letzte Zeile schon mal das HSync erledigt. Das nützt gar nichts, mangels PLL wäre der Jitter zu hoch, das Bild krisselt. Elektor hatte in 11/97 einen VideoCopyProcessor mit einem EPM7032 drin, heute mangels Beschaffbarkeit des programmierten Bausteins natürlich nutzlose Schaltung. So, wie derzeit alle alten Videorecorder weggeschmissen wrrden, wurde ich einen weggeschmissenen Macrovisionsdecoder suchen und gar nix neu bauen. Wer den LM1881 hat, ist natürlich schon mal gut dran.
MaWin schrieb: > Das nützt gar nichts, mangels PLL wäre der Jitter zu hoch, das Bild > krisselt. Gute Erfahrungen habe ich mit dem 74HC4046 gemacht.
c-hater schrieb: > 4053 sollte das können. Falls sich jemand das wirklich antun möchte: Ich habe noch einige FST3253 im TSOP16. Die sind deutlich schneller und niederohmiger als die Standard 4053 und besser dafür geeignet. Gegen Porto kommen die dann im Briefumschlag. Google findet unter "Macrovison decoder" etliche Beispiele für erprobte Schaltungen, zu 99% ohne Prozessor.
MaWin schrieb: > Das nützt gar nichts, mangels PLL wäre der Jitter zu hoch, das Bild > krisselt. Wenn man die Hardware PWM benutzt, jittert da nix. Es gibt genügend Beispiele im Netz, wie man mit einem AVR ein stabiles PAL Bild erzeugt, da jittert es auch nicht. Man darfs nur nicht per Software machen, weil die Antwortzeit auf einen IRQ schwankt. MaWin schrieb: > Wer den LM1881 hat, ist natürlich schon mal gut dran. Sowas muss man sowieso benutzen. Wie erwähnt, wäre der BA7046 noch besser, weil der eine PLL für HSync an Bord hat und auch während V-Sync nicht aussetzt. Der LM1881 hat ja gar keinen H-Sync Ausgang, sondern nur CSync. Peter D. schrieb: > Gute Erfahrungen habe ich mit dem 74HC4046 gemacht. Auch eine gute Idee.
Moin, Wenn man wirklich noch das Beste aus einem verhauten Videosignal heutzutage rausholen moechte, dann wuerd' ich hergehen, und das FBAS stracks ueber einen "dummen" ADC mit entsprechend hoher Samplingfrequenz und Bitbreite digitalisieren und erstmal in ein (grosses) File schreiben. Der Rest ist dann Software. Also: Die ganze Takterkennerei, PAL-Dekodierung, ... Guenstig waer's, wenn man mehrere ADC-Kanaele haette, dann erschlaegt man AV-Sync Probleme gleich mit. Sonst wird das noch etwas tricky. Gruss WK
Matthias S. schrieb: > mit einem AVR ein stabiles PAL Bild Das Bild kommt von einem VCR und wird daher etwas Jitter mitbringen. Den muss der Sync-Regenerator mitmachen. Sonst sieht es grauslig aus. Ohne PLL läuft das nicht.
Georg G. schrieb: > Das Bild kommt von einem VCR und wird daher etwas Jitter mitbringen. Dir fehlt die Information, das Olli einen Panasonic NV-FS200 VHS mit integriertem TimeBase Corrector hat. Der sollte ein quarzstabiles Signal liefern. Das ist zwar kein vollständiger Framebuffer wie in prof. Geräten, bietet aber immerhin den Speicher für eine Zeile mit Fifo.
:
Bearbeitet durch User
Ich habe noch so eine "Bildverbesserungsbox" im Fundus. Ich kann die ja mal aufschrauben und hineinsehen was da so bestueckt ist.
Georg G. schrieb: > c-hater schrieb: >> 4053 sollte das können. Nein, das ist falsch zitiert, das schrieb nicht ich.
Matthias S. schrieb: > Ich vermute mal, es ist ein (Strom-)verstärker gemeint, weil man die > 4053 ja nicht so hoch belasten kann mit einer 75 Ohm Senke. Also noch > einen Emitterfolger dahinter, um das Ziel treiben zu können. Ja, das ist auch praktisch in allen Schaltungen der Video-Limiter so gemacht, mal mehr mal weniger komplex. Manchen reicht ein Transistor, andere nehmen einen Emitter-Folger und wieder andere einen OpAmp für diese Aufgabe. Was hier im den Kontext aber gemeint war ist ein VIDEO-Buffer, also nicht eine Komponente die in der Lage ist ein analoges Signal zu speichern und wiederzugeben.
Matthias S. schrieb: > c-hater schrieb: >> Man braucht auch einen Video-Buffer dahinter. > > Ich vermute mal, es ist ein (Strom-)verstärker gemeint Ganz genau. Ich dachte, allein der Verweis auf die ollen MAX453 würde das hinreichend klarstellen. > Ja sicher. Olli möchte das mit einem LM1881 machen Der ist nicht genau genug, um auf den Farbburst zu synchronisieren. Genau deshalb gibt den Burst ja überhaupt im Signal, die "alten" Synchronsignale aus der S/W-Zeit alleine reichten nicht für Farbe. Um das klarzustellen: Der Farbburst IST auch ein Synchronsignal, der gehört nicht zum Bildinhalt, sondern dient als Referenz, um den Bildinhalt decodieren zu können. > Das will hier niemand. Um die späten Varianten dieser Macrovision-Scheisse entfernen zu können, musst du das aber können. Das einfache Ausblenden der Pseudo-Syncs reicht nur für die ersten Macrovisionen-Versionen, bei den späteren kamen noch ein paar fiesere Tricks dazu...
MaWin schrieb: > Matthias S. schrieb: >> Mit einem Timer, der in 64µs abläuft und eine PWM von 4µs erzeugt, hat >> man eigentlich bis auf die letzte Zeile schon mal das HSync erledigt. > > Das nützt gar nichts, mangels PLL wäre der Jitter zu hoch, das Bild > krisselt. Dieser Zusammenhang ist mir einfach nicht klar. Warum müssen die HSync Pulse untereinander phasengleich sein? Ich dachte genau dafür sind die Pulse da, damit es immer wieder schon von neuem startet... > Elektor hatte in 11/97 einen VideoCopyProcessor mit einem EPM7032 drin, > heute mangels Beschaffbarkeit des programmierten Bausteins natürlich > nutzlose Schaltung. Den bekommt man schon noch, aber woher die Software? ;-) > So, wie derzeit alle alten Videorecorder weggeschmissen wrrden, wurde > ich einen weggeschmissenen Macrovisionsdecoder suchen und gar nix neu Leider nicht, denn wie oben eingangs genannt habe ich schon den besten dieser Art gekauft und auch er macht keine Verbesserung hier.
Georg G. schrieb: > Google findet unter "Macrovison decoder" etliche Beispiele für erprobte > Schaltungen, zu 99% ohne Prozessor. Und leider zu 100% untauglich...
Matthias S. schrieb: >> Wer den LM1881 hat, ist natürlich schon mal gut dran. > Sowas muss man sowieso benutzen. Wie erwähnt, wäre der BA7046 noch > besser, weil der eine PLL für HSync an Bord hat und auch während V-Sync Ich habe mir jetzt mal ein paar dieser Chips bestellt, zum rumexperimentieren. Schaden kannst nicht :-) Aber vielleicht magst Du mir noch mal näher bringen in wie weit der BA aufgrund des PLL die Sache besser macht als der LM? Vielleicht habe ich aber auch PLL nicht verstanden...
Dergute W. schrieb: > heutzutage rausholen moechte, dann wuerd' ich hergehen, und das FBAS > stracks ueber einen "dummen" ADC mit entsprechend hoher Samplingfrequenz > und Bitbreite digitalisieren und erstmal in ein (grosses) File Tja, Du wirst lachen aber genau so hatte ich mir das anfangs auch vorgestellt und das war auch der Grund sich eine Blackmagic Karte zu kaufen. Aber wie ich erkennen musste können das selbst diese teuren Karten nicht.
Matthias S. schrieb: > Georg G. schrieb: >> Das Bild kommt von einem VCR und wird daher etwas Jitter mitbringen. > Dir fehlt die Information, das Olli einen Panasonic NV-FS200 VHS mit > integriertem TimeBase Corrector hat. Der sollte ein quarzstabiles Signal > liefern. Das ist zwar kein vollständiger Framebuffer wie in prof. > Geräten, bietet aber immerhin den Speicher für eine Zeile mit Fifo. Ich habe, trotz das ich das Servicemanual besitze keinen Schimmer wie das TBC darin realisiert ist. Ob das nur eine Zeile oder ein ganzes Bild kann? Was natürlich stimmt ist das wenn man einfach ein statisches Sync-Raster über die Videosignale legt, das es da bei Gleichlaufschwankungen vom VCR schlimmer wird und man Teile abschneidet. Da muss also eine gewisse Dynamik mit rein, aber ist das am Ende dann nicht ein Henne/Ei Problem? Was ich so erreichen könnte wäre ja maximal die "Reparatur" einer einzelnen Zeile, sprich mit dem Sync-Sep kann ich erkennen das eine Zeile startet, dann schalte ich um, warte bis kurz vor dem Burst, schalte wieder zu und warte bis zum Zeilenende. Das ganze würde aber doch nur funktionieren wenn das analoge signal wenigstens vom Sync-Sep. gut erkannt wird.
xyz schrieb: > Ich habe noch so eine "Bildverbesserungsbox" im Fundus. > Ich kann die ja mal aufschrauben und hineinsehen was da > so bestueckt ist. Das wäre sehr hilfreich! Ich kann auch gern mal die "Interna" von dem Elro VL300 posten.
Würde es helfen wenn ich als Anschauung mal versuche ein paar dieser schlechten Videostellen mit dem Speicher-DSO aufzunehmen und hier zu posten? Nur das man mal sieht und diskutieren kann was so grottenschlecht an dem Signal ist das es ein Digitizer nicht rafft?!
Moin, Olli Z. schrieb: > Würde es helfen wenn ich als Anschauung mal versuche ein paar dieser > schlechten Videostellen mit dem Speicher-DSO aufzunehmen und hier zu > posten? Nur das man mal sieht und diskutieren kann was so > grottenschlecht an dem Signal ist das es ein Digitizer nicht rafft?! Schaden kanns ganz sicher nicht, also immer her damit :-) Olli Z. schrieb: > Tja, Du wirst lachen aber genau so hatte ich mir das anfangs auch > vorgestellt und das war auch der Grund sich eine Blackmagic Karte zu > kaufen. Die Blackmagic Karte kann nix dazu, wenn du dir was falsches vorstellst. Ich geh' mal stark davon aus, dass die wie 99%+eps aller Videograbberkarten einen ADC hat, der auf Video spezialisiert ist, also z.b. schon analoge Klemmschaltungen, AGC, PAL/NTSC/SECAM-Decoder etc. drinnen hat. Gruss WK
c-hater schrieb: > Um das klarzustellen: Der Farbburst IST auch ein Synchronsignal, der > gehört nicht zum Bildinhalt, sondern dient als Referenz, um den > Bildinhalt decodieren zu können. Au weia sag mal hast du dich schon mal näher mit dem Farbsignal befasst? Pal ist aus dem NTSC aus Amerika entstanden. Beides verwenden einen IQ Modulator um aus den Signalen R-Y und B-Y das Farbsignal zu erzeugen. Dazu dient als Träger in den beiden Modulatoren I und Q ein 4,433MHz Signal, welches zwischen I und Q Modulator um 90° verschoben ist. Da es bei den Modulatoren es sich um DSB Modulatoren handelt wird der Farbträger selbst unterdrückt. Empfängerseitig wird der Farbhilfsträger wieder neu erzeugt und Phasenrichtig den beiden I-Q Demodulatoren zugefügt. Der Burst dient ausschließlich dazu den Farbhilfsträger zu synchronisieren. Das Pal unterscheidet sich vom NTSC darin, das von Zeile zu Zeile die Phase des Q Trägers und auch des Burstes um 180° gedreht wird. Dadurch mitteln sich Farbtonfehler die auf dem Übertragungswege entstehen können aus und werden in Farbsättigungsfehler umgewandelt, welche weniger kritisch sind. Ralph Berres
Olli Z. schrieb: > Aber vielleicht magst Du mir noch mal näher bringen in wie weit der BA > aufgrund des PLL die Sache besser macht als der LM? Der BA7046 hat im Gegensatz zum LM1881 einen Oszillator mit an Bord, der mit dem H-Sync verkoppelt ist und auch während des V-Sync beinhart weiter auf H-Sync synchronisiert und nicht aus dem Tritt kommt. Der LM1881 hat keinen Oszillator und auch keinen Ausgang exklusiv für H-Sync, sondern nur einen C-Sync, in dem auch das V-Sync Signal auftaucht. Das H-Signal am BA7046 ist vom Timing her sehr exakt und ist wirklich genauso lang wie das originale Signal. Ich habe gerade einen FBAS auf YPbPr (Component) damit gebaut, um meinen Digital Betacam Rekorder mit Analogsignalen zu füttern, weil SDI hier noch nicht angekommen ist. c-hater schrieb: > Das einfache Ausblenden der Pseudo-Syncs > reicht nur für die ersten Macrovisionen-Versionen, bei den späteren > kamen noch ein paar fiesere Tricks dazu... Die fiesen Tricks sind Fake Synchronsignale in den Zeilen der Austastlücke, die sie auch mit den Überpegeln im Bildinhalt füllen. Das habe ich auf einer recht aktuellen DVD so beobachtet. Auch deswegen ist der BA7046 gut, weil die PLL darauf nicht reagiert, weil sie aus dem Fangbereich der PLL rausfallen. Der LM1881 ist ein simples Amplitudensieb und fällt auf die Fakesignale rein. Für Makrovision reicht es, die ersten 23-25 Zeilen des Bildes durch saubere Synchronsignale und Schwarzpegel als Bildinhalt zu ersetzen. @Olli: Wenn du ein billiges Panasonic WJ-AVE5 findest, könntest du da zuschlagen. Ralph B. schrieb: > Der Burst dient ausschließlich dazu den Farbhilfsträger zu > synchronisieren. So ist es und er gehört untrennbar zum Bildinhalt (und nicht zum Synchronrahmen), denn die Phasenlage der Farbsignale dieser Zeile sind mit der Phase des Bursts für diese Zeile verkoppelt. Auch die Amplitude des Bursts ist festgelegt auf 25% des max. Chromapegels und kann so als Referenz dienen.
:
Bearbeitet durch User
Olli Z. schrieb: >> mangels Beschaffbarkeit des programmierten Bausteins natürlich >> nutzlose Schaltung. > > Den bekommt man schon noch, aber woher die Software? ;-) Was mag 'programmierten Bausteins' heissen ? Olli Z. schrieb: > Dieser Zusammenhang ist mir einfach nicht klar Wenn man während der Sync-Zeiten das Originalsignal ausblendet und stattdessen einen selbst erzeugten Sync einblendet, zittert das Bild um den Jitter des Versatzes zwischen Syncpulsen und Bildinhalt. Und bei 4us/64us bekommt er einen Jitter, er muss schon eine PLL laufen lassen.
MaWin schrieb: > zittert das Bild um > den Jitter des Versatzes zwischen Syncpulsen und Bildinhalt. Welchen Teil von 'eingebauter Timebase Corrector' möchtest du denn nochmal erklärt haben? Der Pansonic liefert ein jitterfreies Signal durch den integrierten TBC.
Ralph B. schrieb: > c-hater schrieb: >> Um das klarzustellen: Der Farbburst IST auch ein Synchronsignal, der >> gehört nicht zum Bildinhalt, sondern dient als Referenz, um den >> Bildinhalt decodieren zu können. > Der Burst dient ausschließlich dazu den Farbhilfsträger zu > synchronisieren. Genau das schrieb ich doch!
Matthias S. schrieb: > Ralph B. schrieb: >> Der Burst dient ausschließlich dazu den Farbhilfsträger zu >> synchronisieren. > > So ist es und er gehört untrennbar zum Bildinhalt Ja und nein. Ja in genau dem Sinne, wie auch H- und V-Sync "untrennbar" zum Bildinhalt gehören. Nein in dem Sinne, dass es halt "nur" die Referenz für den Bildinhalt darstellt, aber nicht den Bildinhalt selber. Bezüglich der Farbdecodierung spielt der Burst exakt die Rolle, die die Syncs für den Bildaubau spielen. Eben das Signal, das der Empfänger nutzt, um seinen Generator mit dem des Senders zu synchronisieren. Genau so, wie der V-Sync die Vertikalablenkung synchronisiert und der H-Sync die Horizontalablenkung, synchronisiert der Burst den Generator für den Hilfsträger. Das ist alles ein und dasselbe Prinzip, nämlich eine PLL. Und nein: der Burst gehört nicht zum Bildinhalt. Und ja, er kann regeneriert werden. Und ja: für die späten Macrovision-Versionen MUSS er sogar regeneriert werden (also eigentlich natürlich nicht "für", sondern "gegen").
Matthias S. schrieb: > Welchen Teil von 'eingebauter Timebase Corrector' möchtest du denn > nochmal erklärt haben? Der Pansonic liefert ein jitterfreies Signal > durch den integrierten TBC. Ich beziehe mich auf eine allgemeine Verwendung des Verfahrens, z.B. vor einem Fernseher oder zwischen Recoder und Recorder.
> die "Interna" von dem Elro VL300 posten.
Naja, so viel Arbeit wollte ich da nicht hineinstecken.
Eher mal nach den verbauten Kaefern und deren Anzahl...
Dann kann man zumindest abschaetzen ob es was taugt.
Ralph B. schrieb: > Pal ist aus dem NTSC aus Amerika entstanden. Beides verwenden einen IQ > Modulator um aus den Signalen R-Y und B-Y das Farbsignal zu erzeugen. Sorry, ich habe leider rein garnichts von dem verstanden was Du da mit viel Mühe erklärt hast... nur Fragezeichen auf meiner Stirn :-)
Olli Z. schrieb: > Sorry, ich habe leider rein garnichts von dem verstanden was Du da mit > viel Mühe erklärt hast... nur Fragezeichen auf meiner Stirn :-) Guggstu: https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/Repet_14.pdf Gruss WK
Hier kann man sich auch mal schlau machen: https://www.elektroniktutor.de/geraetetechnik/ffs_empf.html Der Witz ist die Übertragung der R-Y und B-Y Signale und deren Modulation auf den 4,43MHz Farbträger. Die Übertragung des Y Signals wurde vom S/W Fernsehen übernommen und G-Y ergibt sich aus der Summenbildung. Das ganze ist trickig und die Erfinder haben sicher Respekt verdient. Man stelle sich vor, das in den ersten Farbglotzen das auch alles noch mit Röhren gemacht wurde - der reine Horror.
:
Bearbeitet durch User
Olli Z. schrieb: > wieder aussetzt, auch wenn ich den DMR dazwischen schleife. > > Der Grund dürfte wohl hauptsächlich in den Sync-Signalen liegen. Ich > denke man müsste die kompletten Signale, ausser dem eigentlichen > Zeilensignal "einfach" nur neu erzeugen und mit den Nutzdaten > umschalten. SAA 1043 oder 1044 generieren diese Signale. Videosignale vom VCR sind ja, die Zeitbasis betreffend "mechanisch erzeugt". Sie haben Zeitfehler als auch Phasensprünge. Der DMR korrigiert einiges, scheint aber bei Phasensprüngen zwischen den Halbbildern überfordert zu sein. Um einen neuen Syncrahmen für die Videosignale zu generieren muss zunächst der Syncgenerator damit exact und mit Abweichungen < 1mmm am Bildschirm übereinstimmen, also etwa auf 64 ns genau = 1/1000 der Zeilendauer bei PAL. Das war unsere Anforderung an TV-Geräte, die ja die Zeitkonstante der Horizontalsynchronisierung auf "kurz" umschalten mussten. Die Phasensprünge, die ja i.a. im nicht dargestellten Bildbereich liegen, wird nicht erforderlich sein. Mit diesen Signalen müsste man dann in den DMR gehen, der dann zumindest nicht mit den Phasensprüngen fertig werden muss. Sehr viel Arbeit. Müssen wohl unersetzliche Kassetten sein.
Angehängte Dateien:
-
elro_vl300_pcb.jpg
240 KB -
elro_vl300_detail.jpg
430 KB
Leider haben sich die Hersteller des Elro VL300 alle Mühe gegeben ihre Kunst zu verbergen, die ICs sind allesamt sauber abgeschliffen. Aber immerhin sind einige zu erkennen, aber nichts was aussähe wie ein µC. Schade das man so garnichts über die interne Funktionsweise dieses Gerätes in Erfahrung bringen kann...
:
Bearbeitet durch User
Rudi D. schrieb: > Sehr viel Arbeit. Müssen wohl unersetzliche Kassetten sein. Naja, für ein gut erhaltenes WJ-AVE5 zahlt man nicht viel: https://www.ebay.de/sch/i.html?_nkw=WJ-AVE5&_sacat=0 Das Ding würde so gut wie alle Probleme lösen - und der Farbbalkengenerator ist auch schon drin.
Angehängte Dateien:
-
IMG_5615.JPG
280 KB -
IMG_5617.JPG
330 KB -
VOLTCRAFT72_1.gif
18 KB -
VOLTCRAFT81_2.gif
20 KB -
VOLTCRAFT81_3.gif
18 KB -
VOLTCRAFT81_4.gif
19 KB -
VOLTCRAFT81_5.gif
21 KB -
VOLTCRAFT81_6.gif
20 KB -
VOLTCRAFT81_7.gif
20 KB
Hier mal ein paar Beispiele. Das am Fernseher noch ganz gut erkennbare Bild sorgt beim DMR (Panasonic 545) als auch in der Blackmagic Pro nur für ein schwarzes Bild. Ab und zu "zuckt" mal ein Bild durch, aber ansonsten keine Chance. Die DSO-Screenshots sind von verschiedenen Zeilen aus diesem Bildstrom (NTSC). So auf den ersten Blick schauen die ja nicht wirklich grottenschlecht aus. Achja Kopierschutz ist da keiner drauf, das ist ein Band aus einer Videokamera. Was mich auch etwas stutzig macht ist das es keinen Unterschied gibt ob ich am Videorekorder TBC an oder aus habe. Sowohl optisch als auch signaltechnisch sehe ich da keine Verbesserung.
:
Bearbeitet durch User
Olli Z. schrieb: > VOLTCRAFT72_1.gif Also, das ist eindeutig Kopierschutz. In einer normalen Zeile darf es kein Signal geben, was unter den Schwarzpegel geht. Das ist eindeutig ein böses Signal. Wenn mein Digibeta Recorder sowas sieht, tastet er dunkel und die Blackmagic Karte wird genauso reagieren. Ich bin allerdings sonst sehr entäuscht von den Bildern dieses DSO. Man kann ja nicht mal eindeutig sehen, ob ein Burst vorhanden ist oder nicht. Das ist auf meiner alten Hameg Kiste sehr viel eindeutiger.
Matthias S. schrieb: > Also, das ist eindeutig Kopierschutz. In einer normalen Zeile darf es > kein Signal geben, was unter den Schwarzpegel geht. Das ist eindeutig > ein böses Signal. Aber wie sollte das gehen? Das ist ein mit einer Videokamera aufgenommenes Video. Die DSO Bilder sind auch nicht alle von den gezeigten Bildern, gut möglich das sich da ein zwei andere druntergemogelt haben, z.b. von einem Standbild mit Rauschen drin. > Wenn mein Digibeta Recorder sowas sieht, tastet er dunkel und die > Blackmagic Karte wird genauso reagieren. Hm, ich kann auch nochmal ein anderes nehmen, selbst aufgenommen vom TV anno 1986. > Ich bin allerdings sonst sehr entäuscht von den Bildern dieses DSO. Man > kann ja nicht mal eindeutig sehen, ob ein Burst vorhanden ist oder > nicht. Das ist auf meiner alten Hameg Kiste sehr viel eindeutiger. Ich hab noch ein Rigol, das ist etwas besser. Für so Wald und Wiesen Sachen taugte mir das Volcraft bislang immer. Was genau willst Du denn sehen? Dann kann ich von den Partien bessere Bild machen.
:
Bearbeitet durch User
Olli Z. schrieb: > Aber wie sollte das gehen? Das ist ein mit einer Videokamera > aufgenommenes Video. Tja, weiss ich nicht. Aber dieses Oszillogramm sieht haargenauso aus, wie das, welches ich neulich auf der DVD mit Kopierschutz in der Austastlücke gesehen habe. Wenn das auf deinen Aufnahmen öfter vorkommt, wundert mich jedenfalls nicht, das sich die Grabberkarte weigert. Olli Z. schrieb: > Was genau willst Du denn > sehen? Nichts bestimmtes. Ich finde das eben krakelig und Chroma sieht wie ein Pixelbrei aus. Kann aber sein, das ich zu viel auf mein Röhrenoszi geguckt habe.
Ich wollte die Idee nochmal aufgreifen anstelle sich aufwändiger Elektronik Sync-Signale zu basteln oder zu reparieren doch einfach gleich das Videosignal "roh" zu digitalisieren und nachträglich aufzubereiten. Die reine Digitalisierung eines ca. 4,5 MHz Signales bedarf ca. 9 Msa/s, bei einer Auflösung von 8 Bit wäre das ein Datenstrom von ca. 9 Mbyte/s. Das schafft jeder popelige USB 1.0 :-) Selbst höhere Auflösungen sollten kein größeres Problem darstellen. Das Problem entsteht dann aber im Computer wenn man die digitale Aufzeichnung dann interpretieren und in etwas sinnvolles umwandeln möchte...
Olli Z. schrieb: > DMR (Panasonic 545) der kann DVD RAM und speichert als MPG das kann locker vom PC verarbeitet werden ohne den Umweg über den Grabber!
Der VCP7001 von ELV generiert auch neue Synchronimpulse und entfernt den Kopierschutz. Mit TDA-Schaltkreisen. Hier ab den 54er Seiten: https://nvhrbiblio.nl/biblio/tijdschrift/Radio%20Bulletin/1989/Radio%20Bulletin%201989-05-OCR.pdf
:
Bearbeitet durch User
Moin, Olli Z. schrieb: > Die reine Digitalisierung eines ca. 4,5 MHz Signales bedarf ca. 9 Msa/s, > bei einer Auflösung von 8 Bit wäre das ein Datenstrom von ca. 9 Mbyte/s. > Das schafft jeder popelige USB 1.0 :-) Selbst höhere Auflösungen sollten > kein größeres Problem darstellen. Naja, bisschen mehr als 9MSamples/sec taeten nicht schaden. 13.5 waeren ein ueblicher Wert. Und 10bit/sample waere wohl auch kein Luxus. Je hoeher, desto besser hat man die Dreckeffekte im Griff. Mit entsprechendem Equipment koennte man sogar das AV-Syncproblem erschlagen, indem man ganz oldschool den Ton auf die entsprechenden Ton-ZFs (sollten eben die jeweiligen Normfrequenzen sein, damit's spektral gut passt) umsetzt und zusammen mit dem Videosignal digitalisiert. Dann ist die Synchronitaet schon in den Rohdaten festgenagelt. > Das Problem entsteht dann aber im Computer wenn man die digitale > Aufzeichnung dann interpretieren und in etwas sinnvolles umwandeln > möchte... Sowas hatte ich mal vor 25 Jahren noch beim Studieren mal als Schnapsidee. Hatte aber keinen schnellen ADC und auch festgestellt, dass die 30pol. 256k*9 SIMMs, die ich da grad' rumfliegen hatte, auch nicht so recht schnell genug fuer sowas gewesen waeren. Vom TTL-Friedhof aussenrum garnicht zu reden... Also isses nix geworden damals. Aber wenn einem prinzipiell die Farbuebertragungsverfahren, Videonormen und digitale Signalverarbeitung liegen, sollte das schon machbar sein. Wird halt wahrscheinlich noch nix clone-fertiges auf Github rumfliegen... Gruss WK
Dergute W. schrieb: > Sowas hatte ich mal vor 25 Jahren noch beim Studieren mal als > Schnapsidee. Hatte aber keinen schnellen ADC und auch festgestellt, dass > die 30pol. 256k*9 SIMMs, die ich da grad' rumfliegen hatte, auch nicht > so recht schnell genug fuer sowas gewesen waeren. Vom TTL-Friedhof > aussenrum garnicht zu reden... > Also isses nix geworden damals. Als Werkstudent hatte ich vor 36 Jahren als Lagerarbeiter gewerkelt in einem Entwickerlager und sehnsüchtig auf die 9-bit ADC mit 50ns geschaut, Stückpreis rund 3000,-DM für das Projekt TV-Kassette Glasfaser FernsehStudio Verteilung in die großen Städte. Es waren zwar 166 Stk. gekauft worden für 43 Geräte, ich bekam aber trotzdem keinen.
Dergute W. schrieb: > Aber wenn einem prinzipiell die Farbuebertragungsverfahren, Videonormen > und digitale Signalverarbeitung liegen, sollte das schon machbar sein. Wie schon gesagt, habe ich das vor etwa 25 Jahren schon mal gemacht, mit AD9048, HN63021 Zeilenspeicher und einem DAC von AD, den ich im Moment nicht im Kopf habe. Aus Synchrongründen habe ich mit phasenstarr mit dem Burst verkoppelten 17,734 Msps (also 4*Fsc) gesampelt. Im Prinzip die gleiche Schaltung, die Panasonic als TBC in den NV-FS200 gebaut hat, den Olli benutzt. Der ADC war damals allerdings schweineteuer, aber ich war jung und hatte das Geld :-P Die beiden zentralen Platinen habe ich heute gerade in einer Kiste gesehen, kann ich gerne mal fotografieren. Der Trick war der HN63021, ein Fifo 8-Bit SRAM mit getrenntem Schreib- und Lesezähler und getrenntem Datenein- und Ausgang. Der Sinn der Schaltung war einfach: Wenn man 2 Videorecorder mit V-Sync verkoppelt hatte, konnte man so mischen und überblenden.
Sicher wäre ein 4fach Oversampling nicht zu hoch gegriffen, 40-60 Mega-samples-per-second mit 10 Bit ist wohl das was hier als Standard zu sehen wäre und heutzutage auch fast nichts mehr kostet. Ein ADV7182 z.B. Obwohl der auch wieder sowas hat "Rovi™ (Macrovision) copy protection detection". Aber da wären wir wieder mitten in der Frage der Selektion. Es gibt reichlich spezialisierte Video ADCs, die aber sicher wieder auf div. Normen basieren und mir am Ende doch nur wieder Matsche liefern weil sie mit den "fiesen" Signalen nicht umgehen können. Oder eben ganz bewußt keine solchen, sondern Universal-Wandler, aber dann eben volle Signalrückgewinnung über Algorithmen. In meinem Fall muss ich nichts in Echtzeit machen, wo die spezialisierten Chips klar im Vorteil sind. Aber mir mangelt es leider an der Möglichkeit entsprechende Software selbst zu entwickeln und was "fertiges", wenigstens in Form einer Library konnte ich bislang auch nicht finden.
:
Bearbeitet durch User
Olli Z. schrieb: > und was > "fertiges", wenigstens in Form einer Library konnte ich bislang auch > nicht finden. Dann kauf doch das WJ-AVE5. Ich kann dir versichern, das es zuverlässig Müll entfernt und ist billiger als alles, was du selber baust. Der Haken ist lediglich, das Prüfzeilen und VITC dran glauben müssen. Das ist hier auf dem Digi-Beta schade, aber für dich vermutlich wurscht.
:
Bearbeitet durch User
Dergute W. schrieb: > Guggstu: > https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/Repet_14.pdf das ist wirklich ein sehr gutes Dokument. Habe ich mir sofort abgespeichert. Ralph Berres PS wer hat denn hier an der Schriftgröße gedreht. Ich fince es ist viel schlechter lesbar.
:
Bearbeitet durch User
Matthias S. schrieb: > @Olli: Wenn du ein billiges Panasonic WJ-AVE5 findest, könntest du da > zuschlagen. Ich will ja nichts unversucht lassen, also bin ich Deinem Rat gefolgt. Kommt nächste Woche, dann mal schauen...
Olli Z. schrieb: > Ich wollte die Idee nochmal aufgreifen anstelle sich aufwändiger > Elektronik Sync-Signale zu basteln oder zu reparieren doch einfach > gleich das Videosignal "roh" zu digitalisieren und nachträglich > aufzubereiten. Nun, das ginge natürlich. > Das Problem entsteht dann aber im Computer wenn man die digitale > Aufzeichnung dann interpretieren und in etwas sinnvolles umwandeln > möchte... Nein, was sollte da für ein Problem entstehen? Du musst dann doch nur vollständig dasselbe in Software erledigen, was bei alternativen Ansätzen die Hardware erledigt und das, was in alternativen Ansätzen ggf. schon in Software geschieht, weiterhin in Software tun. Also ich sehe da irgendwie kein besonderes Problem. Außer: DU kannst das wohl nicht, weil du eigentlich rein garnix von der Sache verstehst... Daran kannst nur du etwas ändern...
Matthias S. schrieb: > Dann kauf doch das WJ-AVE5. Ich kann dir versichern, das es zuverlässig > Müll entfernt und ist billiger als alles, was du selber baust. Der Haken So, habe so ein Teil gekauft und heute ausprobiert: Es macht in der Tat genau das was Du sagst, ich kann nun wirklich ALLES aufnehmen, inkl. Störungen etc. Perfekt! :-) Jetzt muss ich nur noch einen Weg finden das Teil NTSC-Kompatibel zu machen. Das Problem ist wohl das der Videorekorder zwar NTSC-576i ausgibt, der Mischer aber sicher PAL-675i erwartet. Daher kommt unter dem normalen Bild noch das Zeugs was man normal nicht sieht und danach fängt vermutlich das nächste Halbbild an, was er noch einen Teil anzeigt. Jedenfalls scheint das die Chroma durcheinander zu bringen, die Aufnahme tendiert dann immer zwischen normal, übersättigt und schwarz/weiss. Ich vermute also das der Mischer mit NTSC nicht umgehen kann. Daher brauche ich dann wohl einen Wandler von NTSC auf PAL, oder das gleiche Mischer-Modell aber für den USA-Amerinkanischen Markt? Damals war das ja noch nicht so mit Firmwareverfügbarkeit, aber vermutlich gibt es den AVE5 auch mit NTSC-Firmware.
Olli Z. schrieb: > Daher kommt unter > dem normalen Bild noch das Zeugs was man normal nicht sieht und danach > fängt vermutlich das nächste Halbbild an, was er noch einen Teil > anzeigt. Das kannst du z.B. dadurch verhindern, das du den zweiten Kanal (Schwarz) mit horizontalem Wipe dazu benutzt, den unteren Rand zu maskieren. Man kann das Pult, wenn man das Servicemanual hat, auch auf NTSC umstellen, aber das ist recht fummelig, weil das dicke ICs mit mehreren hundert Beinen sind. Die Chips sind aber darauf vorbereitet. Leider sind die Manuals im Internet so gut wie unbrauchbar, weil nicht lesbar. Man kann übrigens intern einen Jumper setzen, dann macht das Pult als zusätzliche Hintergrundfarbe den Farbbalken.
:
Bearbeitet durch User
Angehängte Dateien:
Das Servicemanual habe ich mir natürlich als erstes runtergeladen und
ebenfalls die ganzen Hinweise auf NTSC/PAL darin gefunden.
Meine erste Hoffnung, das sich das intern einfach mit einem Jumper
umstellen lässt, zerplatzte damit schnell... schade. Aber die zweite
Überlegung war sich noch so ein Teil zu kaufen (aktueller Marktwert so
um die 40,- €) und das auch NTSC umzubauen und natürlich zu kalibrieren.
Das scheint mir mittels der SM gut möglich weil alles sehr gut
beschrieben ist. Meine Version ist gut lesbar, leider aber nur ein Scan
und damit nicht durchsuchbar. Etwas mühselig. Du sagst die im Internet
sind unbrauchbar, schließe ich daraus richtig das Du im Besitz einer
Original Papierform bist?
Die andere Option wäre sich auf dem US-Markt umzuschauen wo exakt dieses
Gerät mit derselben Bezeichnung als NTSC verkauft wurde. Es muss
irgendwo in der Modellnummer einen Hinweis darauf geben ob das PAL oder
NTSC ist. Bei meinem ist hinten ein "/G" dran, was sicher NICHT
"Germany" bedeutet ;-)
Das mit dem Wipe teste ich mal. Aber vermutlich wird das nur
ausgangsseitig etwas bewirken, sprich ich habe die untere Matsche halt
einfach nicht mit drauf, aber eingangsseitig im Buffer wird sie sein.
Ich poste gleich mal ein Bild. Meine Befürchtung dabei ist das die
Elektronik halt 625 Zeilen erwartet und somit nach den 525 NTSC-Zeilen
einfach weitermacht und das VSync irgendwie ignoriert und somit die
austastlückensignale sowie Zeilen des nächsten Halbbildes dort drin
stehen. Somit würde dann dieses Halbbild kaputt sein und evtl. auch das
Chroma durcheinander kommen.
Das würde die teils merkwürdigen Regenbogeneffekte im Bild erklären. Das
die Farbe immer mal in der Sättigung schwankt.
> Man kann übrigens intern einen Jumper setzen, dann macht das Pult als
zusätzliche Hintergrundfarbe den Farbbalken.
Das klingt sehr interessant, kannst Du mir die Position/Namen von dem
Jumper nennen?
Olli Z. schrieb: > schließe ich daraus richtig das Du im Besitz einer > Original Papierform bist? Ja. Der gleiche bei Panasonic arbeitende Verwandte, der mir damals das Pult aufgeschwatzt hat, hat mir auch das Manual besorgt. Olli Z. schrieb: > kannst Du mir die Position/Namen von dem > Jumper nennen? Im Moment leider nein. Ich habe gestern das Manual gewälzt, um den Jumper zu finden, war aber erfolglos. Ich muss also das Pult aufschrauben. Den Tipp hatte ich damals von einem Pana Techniker. Heute ist das WJ-AVE5 für die Video-Glitcher interessant, da gibt es jede Menge Mods. Aber über den Jumper fand ich nichts im Netz.
Ich werde das Thema "Umbau zu NTSC" mal lieber in einem eigenen Thread fortführen: Beitrag "Panasonic WJ-AVE5 (PAL) auf NTSC umbauen" Vielleicht mag ja der ein oder andere was konstruktives dort dazu beitragen? Würde mich freuen!
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.