Beiträge von TomKeller

    Worauf beziehst du dich mit deinem Beitrag? Auf meine Aussage über Video-on-Demand!? Da war aber nirgendwo von Festplatten die Rede. Auch abseits davon wurden hier bislang keine Festplatten empfohlen. HDDs sind sowieso (unbestreitbar) am denkbar ungeeignetsten als robuster(!) Langzeitspeicher.


    Ich wollte übrigens nicht darauf hinaus, dass in Zukunft alle nur noch Streaming-Videos auf Platte archivieren. Meiner Meinung nach geht die zukünftige Entwicklung dahin, dass keiner mehr physische Datenträger zu Hause im Regal stehen hat (höchstens noch aus Sammler-Gründen), sondern dass Filme und Serien nur noch auf den Servern diverser Anbieter liegen und bei Bedarf live gestreamt werden. Netflix & Co. lassen grüßen.

    Dann wäre doch eine Speicherkarte die bessere Wahl oder?


    Auch Speicherkarten bestehen meines Wissens nicht nur aus Speicherbausteinen, sondern besitzen mindestens noch einen Schnittstellen-Controller für den Zugriff auf den Kern des Flash-Speichers. Dank simplerem Aufbau sind sie aber verständlicherweise nicht ganz so fehleranfällig wie USB-Speichersticks.


    Ein weiteres Problem bei jahrzehntelanger Lagerung ist auch noch ein Abspielgerät für den Datenträger zu haben. Diskette/VHS wird jetzt schon schwer in den meisten Haushalten, IDE-Festplatten sind auch bald weg vom Fenster, ob die nächste Version von DVD/BD abwärtskompatibel ist bleibt abzuwarten.


    Die CD gibt es immerhin schon seit fast 35 und die DVD seit beinah 20 Jahren - aktuelle BD-Player haben bislang trotzdem kein Problem mit beiden Datenträgern. Ich würde daher mal behaupten: Abspieler für die etablierten optischen Medien (sprich: CD/DVD/BD) wird es auch noch in mehreren Jahrzehnten geben. Garantien gibt's darüber hinaus natürlich trotzdem keine. Immerhin geht der Trend zunehmend Richtung Video-on-Demand-Online-Angebote, was vermuten lässt, dass optische Datenträger irgendwann mal komplett vom Markt verschwinden könnten...


    Aber vergleichbare Sorgen könntest du in einigen Jahrzehnten auch mit 'nem USB-Stick haben - schließlich kann dir niemand versprechen, dass der USB-Datenbus nicht bis dahin durch einen inkompatiblen Nachfolger abgelöst wurde. Immerhin sind ja nicht wenige frühere Schnittstellen- und Bussysteme heute schon teilweise oder komplett "ausgestorben". Und abgesehen von der Dateiformat-Frage dürfte auch ein aktuelles Linux höchstwahrscheinlich große Probleme haben, mit in mehr als 100 Jahren erscheinender Hardware zu laufen ;) .


    Mit ähnlichen Problemen haben sich übrigens auch schon Ende der 70er die Wissenschaftler rumschlagen müssen, welche die Datenplatten entwerfen sollten, die den Voyager-Sonden mitgegeben wurden:


    http://de.wikipedia.org/wiki/Voyager_Golden_Record


    Für eine private Zeitkapsel dürfte sowas aber ein "klein wenig" übertrieben sein ^^ !


    Ich bleibe aber dabei:
    Bei mehr als 100 Jahren angepeilter Lagerung würde ich immernoch am ehesten zur M-Disc raten und entweder ein etabliertes Strukturformat (z.B. eine Video-DVD- oder -Blu-ray-Struktur) wählen, oder eine Daten-Disc mit halbwegs aktuellen, etablierten Kompressionsformaten (z.B. H.264-Video + AAC-Audio im MP4-Container & JPEG-Bilder) erstellen. Da dürfte dann zumindest (im Gegensatz zu magnetischen und Flash-Speichermedien) halbwegs sicher sein, dass die Disc als Datenspeicher die Jahrzehnte überlebt. Das Risiko für Kompatibilitätsprobleme mit dem Speicher und seinem Inhalt wird sich aber in keinem Fall verhindern lassen. Daher würde ich mich an deiner Stelle vor allem auf das einzige konzentrieren, was ich beeinflussen kann: eben die Haltbarkeit.

    Sprich: am besten die Daten auf Keramik- oder Steintafeln speichern ;) !


    Wer DOCH zu USB-Sticks greift, sollte allerdings bedenken:
    Auch wenn die Daten im Flashspeicher relativ lange erhalten bleiben, kann immernoch der Controller-Chip den Geist aufgeben - und schon kommt man nicht mehr ran. Der Tipp von "Q-the-STORM" ist dahingehend also nicht zu unterschätzen... trotzdem hat man nie eine 100%ige Garantie für jahrzehntelange Defekt-Freiheit. Das ist halt der Nachteil, wenn man ein Speichermedium bevorzugt, welches selbst elektronische Bauteile aufweist, durch die es eben fehleranfällig wird...


    Wenn die M-Disc tatsächlich ihr Marketingversprechen hält (Langzeitstudien gibt's dazu ja nicht, sondern "nur" Tests, wo derartige Medien für einige Zeit extremen Witterungsbedingungen ausgesetzt werden... was sie aber sehr gut überstehen), könnte sie eventuell auch eine Überlegung wert sein - sofern der vergleichsweise geringe Speicherplatz ausreicht und die Daten wichtig/wertvoll genug sind, um sie vielleicht sogar noch an die nächste Generation weiter geben zu wollen.

    Wie gesagt: beschwere dich bei Conrad - die bezeichnen das als "Mikroschalter" mit dem Zusatz "tastend" :P .


    Ach ja - wer eine nicht allzu alte, hochwertige und zudem relativ beliebte Maus sein eigen nennt, findet übrigens bei diversen asiatischen Händlern auf eBay auch teilweise ein neues Gehäuse dafür. Hier z.B. mal eins für die Razer Deathadder:


    http://www.ebay.de/itm/281305956169


    ... oder hier auch für ein paar Logitech Mäuse:


    http://www.ebay.de/itm/151241098402


    http://www.ebay.de/itm/281220600304


    Genauso wie passende USB-Kabel:


    http://www.ebay.de/itm/150814716321


    http://www.ebay.de/itm/261256075181


    http://www.ebay.de/itm/281143521741


    http://www.ebay.de/itm/281274880327



    Letztendlich lässt sich am "Schreibtischnager" tatsächlich 'ne ganze Menge relativ kostengünstig reparieren - die Maus ist danach so gut wie neu... und das nur bei einem Drittel bis einem Fünftel des Kaufpreises einer neuen ;) .

    Dragon41
    Das selbe hatte ich damals mit meiner zweiten keine-Ahnung-wer-die-produziert-hatte Maus gemacht - allerdings mit mittlere Maustaste <-> linke Maustaste. Da waren allerdings Mikrotaster verbaut :D :



    PS: Nö-nö-nö - Conrad führt die Cherry Switches als "Mikroschalter"... also hab ich den Begriff übernommen. Mir egal, ob der 100%ig korrekt ist - denn üblicherweise suche ich auf eBay sowieso nur nach "micro switch" :P .


    Das da oben auf dem Bild hab ich allerdings tatsächlich mal als Mikrotaster kennengelernt ;) .

    Für's Reinigen ist ja auch keiner nötig ;) . Vielleicht auch ganz interessant... damit klar ist, wie das Innenleben so eines Mikroschalters aussieht:


    http://www.overclockers.com/forums/showthread.php?t=594646


    Der Federkontakt da drin ist... äh... wie lautet der technische Fachausdruck(?) - ACH JA: scheiß winzig :D . Vorsicht also, wenn man daran rum biegt (damit der mechanische Widerstand des Schalter wieder etwas besser wird) - der Federkontakt ist zwar robuster als er aussieht, kann aber durch Unvorsichtigkeit und/oder Übermut trotzdem relativ leicht zerstört werden.



    Für's Auswechseln des Mikroschalters ist ein Lötkolben allerdings leider unvermeidlich :P . Man sollte aber einen Lötkolben nehmen, wo man halbwegs die Temperatur kontrollieren kann - sprich: er muss schon an einer Lötstation hängen... bzw. in der "Not" tut's auch so ein Ultra-Billigteil, mit Temperaturregler direkt am Lötkolben selbst (eine lange Haltbarkeit sollte man davon allerdings nicht erwarten).

    Sowas hatte ich auch vor längerer Zeit bei meiner Maus...


    Meine Lösung war dann allerdings, dass ich einen identischen Mikroschalter bei eBay nachgekauft habe:


    http://www.ebay.de/itm/191182726847


    Am häufigsten sind tatsächlich solche Mikroschalter von Omron, oder eben von Huano:


    http://www.ebay.de/itm/230912914567


    ... verbaut. Ist ziemlich unproblematisch die zu kriegen und mit ein klein wenig Löterfahrung sind die auch schnell ausgewechselt. Die D2FC-F-7N(10M) Mikroschalter von Omron sind auf mindestens 10 Mio. Klicks bis zum ersten Ausfall ausgelegt, genauso wie die "blue point" Schalter von Huano.
    Von Huano gibt's außerdem noch "white point" Mikroschalter mit blauem Gehäuse, für die ganze 20 Mio. fehlerfreie Klicks garantiert werden:


    http://www.ebay.de/itm/231087934425


    Baugleiche Noname-Mikroschalter (von Conrad, Reichelt, ELV, o.ä.) gehen natürlich genauso - allerdings ist dann meist nicht ganz sicher, wie viele Klicks die mitmachen, bevor sie den Geist aufgeben... bzw. hochwertige Standard-Mikroschalter (z.B. von Cherry) garantieren üblicherweise "nur" 1 Mio. Klicks.



    Die kostenlose Reparatur-Alternative wäre:
    Du öffnest den Mikroschalter und reinigst sein Innenleben. Pusten bringt nämlich üblicherweise nichts, weil die Dinger relativ dicht verschlossen sind (was ja auch sinnvoll ist, damit kein Dreck rein kommt).
    Den defekten Mikroschalter hatte ich nach dem Ausbau mal aus reiner Neugier geöffnet (kann man mit einer Nadel vorsichtig aufhebeln). Wie sich zeigte, waren da minimale, rußartige Oxid-Ablagerungen auf den Kontakten. Sowas kriegst du halt wirklich nur weg, wenn du den Schalter auf machst.



    Eine Software-Lösung kenne ich leider nicht. Ich weiß auch nicht, ob das auf Dauer glücklich machen würde. Denn ich konnte bei mir zwar im Maus-Treiber die Doppelklick-Geschwindigkeit einstellen und somit Doppelklick-Probleme mit der defekten Maustaste vermeiden... allerdings beseitigte das lögischerweise nicht den Ärger bei jeglichen Drag-n-Drop-Aktionen (z.B. wenn man ein Fenster irgendwo hin zieht bzw. vergrößert... oder wenn man mehrere Dateien mit der Maus markieren will) und hilft erst recht nicht, wenn man in Video-, Grafik- oder Audiobearbeitungsprogrammen sorgenfrei arbeiten will.

    Im Gleitz-Forum hast sich übrigens als HQ-Variante das Digitalisieren per Panasonic DMR Festplatten-Recorder herauskristallisiert ( -> HDMI-Ausgang vom Recorder an PC-HDMI-Capturegerät... mit geeignetem HDMI-Splitter dazwischen, um HDCP raus zu filtern):


    http://forum.gleitz.info/showt…pturing-per-USB-oder-HDMI


    Diese Lösung arbeitet nämlich stabil gegenüber VHS-Jitter und liefert zudem noch die beste Bildschärfe und -qualität aller verglichenen Lösungen.

    Dann könnte man also am Protokoll des OCH's somit nie heraufinden, egal wie lange die Daten gespeichert werden, was heruntergeladen wurde. Aber wie kann man dann überhaupt 'rausfinden, daß jemand einen Film, eine Album etc. 'runtergeladen hat, um eine Abmahnung zu schicken?


    Bei P2P-Client-Software(!!!) kennen die einzelnen Clienten die IPs der anderen/verbundenen Clienten - was ja nötig ist, um untereinander Daten austauschen zu können. Um hier die IP eines Uploaders(!!!) herauszufinden, reicht es, wenn die Ermittler einen modifizierten Clienten einsetzen, der die IPs der verbundenen Clienten (die gerade Daten schicken) anzeigt. Dann muss man nur noch diese IPs nehmen und beim entsprechende Provider nachhaken, zu welcher Person die zum fraglichen Zeitpunkt gehörten.


    Bei OCHs(!!!) und Usern die von OCHs downloaden(!!!) ist das natürlich NICHT so ohne weiteres möglich. Dafür müsste erstmal der OCH die IPs aller Downloader loggen. Das machen zwar so ziemlich alle OCHs - aber auch nur, damit Freeloader nicht unbegrenzt downloaden können. Sprich: sie machen das nur um zu erkennen, ob ein und die selbe IP innerhalb eines bestimmten Zeitraums mehrere Dateien runter lädt und um dann gegebenenfalls die Wartezeit hochzusetzen. Mit Sicherheit weiß ich's zwar nicht... aber ich bezweifle, dass diese Logs über einen Zeitraum von 24 Stunden hinaus gespeichert werden. Das würde einfach keinen praktischen Sinn machen und nur Platz verschwenden.
    Doch selbst WENN diese Logs über Monate gespeichert bleiben WÜRDEN, müsste eine Anwaltskanzlei die erstmal bei OCH anfordern. Das fängt schon in dem Moment an schwierig zu werden, wo der Firmensitz des OCHs in einem Land mit eher "moderater" Rechtslage hinsichtlich Urheberrechtsverletzungen sitzt. Es liegt zudem im eigenen Interesse des OCHs, dass die Logs nicht rausgegeben werden - die wollen ja ihre zahlende Kundschaft nicht verlieren (was schnell passieren könnte, wenn sich das rumspricht). Zudem stünde der Nutzen (wie schon erwähnt) in keinem Verhältnis zu den Kosten. Ein unbekannter Downloader steht ja erstmal nur im Verdacht, EINE EINZIGE Datei heruntergeladen zu haben, für die man ihn vielleicht belangen könnte. Die Anwaltskosten allein für den Schriftverkehr zwischen Kanzlei und OCH dürften da schon deutlich ÜBER dem Streitwert liegen.


    Und darum macht es auch keinen Sinn, den Downloadern nachzustellen - das würde Rechteinhaber nämlich mehr kosten, als sie dadurch einfahren können. Ein Uploader ist einfach das bessere Ziel... da er ja den Film, oder das Album, oder die Software IN HOHER ANZAHL verteilt!!! Da geht es dann um Beträge im minimal dreistelligen Bereich - sprich: daran können Anwälte und Rechteinhaber tatsächlich auch was verdienen. Aber selbst da stehen wieder OCHs nicht im Mittelpunkt, sondern eben die P2P-Netze - einfach weil da der Kosten- und Zeit-Aufwand zum Ermitteln der IPs minimal ist.

    Gibt es eigentlich Menschen die über das Thema den Verstand verloren haben? ^^


    Der Witz an der Sache ist: das Thema "Interlacing" ist im Bereich der Videobearbeitung bei weitem nicht das komplizierteste Gebiet ;) . Und es ist nicht mal wirklich schwierig, wenn man sich schlicht und einfach klar macht, dass Interlacing nichts anderes als das hier ist:



    ... nur mit Pixelzeilen statt Fingern :rolleyes: .



    Soweit ich weiß konnte VDub damals nichts mit dem Codec anfangen...


    Das gilt nur, wenn du ein Video DIREKT IN VirtualDub öffnest... OHNE Mitwirken von AviSynth.


    Wenn du jedoch ein Video über AviSynth lädst, dann decodiert AviSynth das Video (über sein Source-Plugin) und leitet das decodierte/unkomprimierte Videobild an VitualDub weiter. VirtualDub weiß dann nicht mal, dass das ursprüngliche Video komprimiert ist, da VirtualDub ja nur das unkomprimierte Video geliefert bekommt.


    Das ist so, als ob du ein komprimiertes MPEG2-, H.264- o.ä. Video in ein unkomprimiertes AVI-Video umwandelst und das unkomprimierte AVI-Video dann in VirtualDub öffnest -> das klappt ja auch!!! Mit AviSynth passiert genau das gleiche... nur eben OHNE das Zwischenspeichern des unkomprimierten Videos als AVI-Datei.

    Nein, Du hast mich ein wenig missverstanden...


    wenn ich das avs so in VDub gelande habe, konnte ich mit dem Pfeiltasten immer ein Bild weitergehen und daran erkennen, ob es interlaced war oder prog. Bewegung nach jedem Tastendruck: Interlaced. Bewegung alles zwei Bilder: Progressiv. Bewegung mal so mal so: Anscheinend Normwandlung. Danach konnte ich dann entscheiden, wie ich das Material kodiere. Das meinte ich damit...


    Das ist doch im Prinzip schon das, was ich ich mit:

    Zitat

    Im Zweifelsfall: nur mit den eigenen Augen


    ... meinte ;) .


    Wobei es in der Praxis noch komplizierter werden kann! Zum Beispiel hast du dann bei phase-shifted interlaced Video auch nur alle zwei Bilder Bewegung, weil vom ursprünglich progressiven Ursprungsmaterial die Halbbilder um ein Frame versetzt gemischt wurden - sprich: alle geraden Bildzeilen vom ehemals progressiven Frame 1 sind mit allen ungeraden Bildzeilen aus Frame 2 verwoben -> alle geraden Bildzeilen vom Frame 2 sind mit allen ungeraden Bildzeilen aus Frame 3 verwoben -> alle geraden Bildzeilen vom Frame 3 sind mit allen ungeraden Bildzeilen aus Frame 4 verwoben -> usw.! Daher ist das Video (TROTZ Bewegung alle zwei Bilder) interlaced und hat das dafür typische Kamm-Muster. In dem Fall wäre TFM zum Deinterlacen sinnvoll, da es automatisch erkennt welche Halbbilder ursprünglich ein Vollbild bildeten, und die Halbbilder dementsprechend zusammenfügen kann.



    Und anscheinend muss ich das jetzt auch mit VDub machen. Wobei ich immer dachte dass VDub HD-Material oder x264 und so nicht nimmt.


    Ich wundere mich immer, woher der Glaube kommt, dass HD-Videos so viel anders als SD-Videos sind. Nur die Auflösung (= Pixelanzahl je Frame) ist höher - das war es dann aber auch schon. Solange man keine Software einsetzt, die an irgendeiner Stelle die Auflösung künstlich begrenzt, gibt es keinen Unterschied bei der Bearbeitung. VirtualDub könnte dementsprechend auch ein 8K-Video öffnen - das interessiert es herzlich wenig.


    Außerdem: wenn man ein Video per AviSynth-Script in VirtualDub lädt, dann erledigt AviSynth die Decodierung und NICHT VirtualDub! VirtualDub bekommt dann nur das decodierte/unkomprimierte Ergebnis von AviSynth geliefert. VirtualDub kann also das Kompressionsformat des Videos vollkommen egal sein!

    So ein Vorgehen kenne ich noch in ähnlicher Form von mpg-Material...da habe ich das, wenn ich mich recht erinnere, immer in VDub geladen.


    Das Quellformat ist dabei vollkommen egal. Das geht mit HD- und SD-Videos... mit MPEG2-, H.264-, VC1-, XviD/DivX- oder sonstigen Videokompressionsformaten... im MPG-, AVI-, MKV-, M2TS- oder anderem Container.



    Da konnte ich dann immer ein Bild weitergehen....interlaced wirkte dabei deutlich weicher...


    Danach gibt's aber kein Interlacing mehr. Bob ist ein extrem simpler Deinterlacer -> er trennt einfach die Halbbilder, skaliert sie bikubisch auf doppelt Höhe (für korrekte Vollbild-Größe) und zeigt sie nacheinander an. Die Reihenfolge, welches Halbbilder zuerst angezeigt wird, hängt dann (wie immer) davon ab, ob der interlaced Videostream TFF oder BFF vorliegt. Im Grunde ist Bob() also so ziemlich das selbe wie:


    Code
    1. SeparateFields()
    2. BicubicResize(Breite, Höhe*2)



    Verstehe ich das richtig dass ich jetzt hier ein Stück testweise so encode und später anschaue? Oder gibt es eine Möglichkeit wie oben?


    Wieso encoden? Wie oben schon geschrieben: AviSynth ist das Quellformat vollkommen egal... intern wird eh immer mit unkomprimiertem Video gearbeitet. Hauptsache ist nur, dass du ein AviSynth-Source-Plugin hast, welches das Quellvideo laden und decodieren kann -> z.B. L-SMASH. Dann erzeugst du ein Script - mit L-SMASH z.B.:


    Code
    1. LoadPlugin("C:\Pfad_zur\LSMASHSource.dll")
    2. LWlibavVideoSource("C:\Pfad_zur\Videodatei.Dateiendung")
    3. SeparateFields()


    ... lädst das dann in VirtualDub, suchst dir eine Stelle mit Kameraschwenk und blätterst dort Einzelbild für Einzelbild vorwärts. Encoden musst du dafür gar nichts.

    Im Zweifelsfall: nur mit den eigenen Augen -> indem du z.B. das fragliche Video per AviSynth lädst, per SeparateFields die verschachtelten Halbbilder trennst, dir eine Szene mit 'nem gleichmäßigen Kameraschwenk o.ä. suchst und dann schaust, ob Halbbilder doppelt (= mit gleichem Bewegungszustand) vorhanden sind und ob es da einen Rhythmus in der Wiederholung gibt. Bei ECHTEM (schon interlaced aufgenommenem) Material gibt es nämlich bei Bewegung im Bild (also eben z.B. einem Kameraschwenk) NIE zwei Halbbilder mit identischem Bewegungszustand.

    Deinterlacing macht aber IMMER Sinn, wenn das vorliegende Material ursprünglich progressiv gedreht wurde und erst nachträglich über irgendwelche obskuren Methoden zu interlaced Video verwurstet wurde. Denn dann kann man häufig die ursprünglichen(!!!) Vollbilder wieder aus den Halbbildern zusammensetzen (und das Ergebnis ist dadurch besser(!), als es die vergleichsweise dummen Automatik-Deinterlacer von TV-Geräten hinkriegen, die üblicherweise nur mehr oder minder simple Interpolationsverfahren nutzen, um die Halbbilder zu Vollbildern hoch zu rechnen).


    Nicht deinterlacen sollte man einzig und allein dann nicht, wenn das Quellmaterial schon so versaut wurde, dass sich die ursprünglichen Vollbilder nicht mehr rekonstruieren lassen... ODER wenn das Quellmaterial interlaced gedreht wurde.