Puh, der Tread hat ja ein paar schnelle Kurven hinter sich. Weil ich aber ein paar mal wohl anders als gemeint verstanden worden bin, vielleicht noch ein paar Richtigstellungen:
Ich bin durchaus nicht der Meinung, p liesse sich nicht übertragen.... ich bin nur der Meinung 1080p ergibt im HDV Umfeld ziemliche Probleme mit der Bandbreite. 720p ist ja nun seit den ersten tagen von HD überhaupt kein Thema und auch genügend Chips können das native erledigen.
Aber eben bei 1080p wird die Luft eben ziemlich dünn.
Nach wie vor ist für mich der Chip noch der Schlüssen zur Erkenntnis, wie wohl übertragen wird. Bei Ein-chip Lösungen darf man nie den Auflösungsverlust durch die Farbmaske aussen vor lassen. Und so ergeben sich meist schon realistische Anhaltspunkte die auf die Übertragung schliessen lassen.
In Bezug auf Canon F Format hat die Hochschule für Fernsehen und Film München -Abteilung II Technik Tests angestellt und kommt auch zu dem Schluss, dass rd. 2x 800 Zeilen statt der sonst üblichen 540 Zeilen für ein Bild herangezogen werden.
ich habe längst aufgehört, mich auf die Angaben von (wie auch aufgeführt) Test´s im Internet zu verlassen. Bunte Bilder und viel Schall und Rauch.
Also, ohne den Thread noch mal aufleben zu lassen, die Ausgangsfrage ging eigentlich um p oder i und das Ãœbertragen.
Dazu kann man eigentlich nur sagen, dass MPEG (und darum geht es bei HDV) eigentlich nur den Bitstream definiert und es keine Möglichkeit gibt, einem Decoder irgend eine Besonderheit mitzuteilen.
Daher werden die Signale auch eigentlich nicht als irgendwie mysteriös übertragen, entweder ist es HDV 1 oder 2 und dafür sind die Pakete, die übertragen werden genau definiert ... das hat auch nur noch wenig mit i oder p zu tun. Ist es eben nichts, was HDV1 oder 2, ist es eben ein anderes Format, dass nur vom Decoder gelesen werden kann, wenn der Decoderhersteller dieses Format unterstützt. Unterstützt er aber nur den Standard, so ist keine Garantie dafür da, dass solche Formate auch lesbar sind.
Daher mein Ansatz, solche Formate wie 1080p erst genau unter die Lupe zu nehmen, bevor man etwas glaubt ... Einen neuen Trick hat sich JVC einfallen lassen, als sie anfang 2008 die Modelle HD5 und HD6 herausgebracht haben.
Da wird in den Beschreibungen dick gedruckt darauf hingewiesen, dass die Kamera 1080p ausgeben kann und nur ganz versteckt in den Texten ist dann zu lesen, dass dies lediglich eine de-interlacede Version einer 1080i Aufzeichnung ist.
bei den 720 hingegen würde ich bei dem heutigen Stand der Technik nun wirklich jedes p glauben. (ausser 24, weil es dafür eigentlich auch keine Spezifikation gibt). Aber das ist nun wieder ein anderes Thema.
Bei den neuen JVCs soll es sogar noch skuriler sein! :D
Die CCDs sollen progressiv ausgelesen werden.
Aber es wird reinterlaced und als 50i ausgegeben.
Wer progressiv haben will muss HDMI benutzen. Dafür wird das Bild wieder deinterlaced!
Aber, wie gesagt, glaub nur, was verlässlich recherchiert ist. Die meisten Tests sind das Papier nicht wert, auf dem sie stehen. Leider werden die Firmen immer intransparenter mit den Infos und die Marketingstrategen immer lauter. Aber die Tester in den bunten Zeitschriften und den Internetforen wissen auch nicht mehr, als die Marketingstrategen ihnen einreden. daher muss immer Plausibilität dabei sein. Oder eben gute Leute, die die teile in die Hand nehmen und selbst bei anerkannt guten Leuten geschehen noch Fehler (siehe A.J.W. und das nicht erkannte Auflagemaß der EX1). Nur das ist bereits ein anderes Niveau als diese Zeilenfüller-Tests.
Aber bei 1080p bleibt es wirklich noch eine ganze Weile spannend, was den Firmen da wohl noch so einfällt ... immer erst nachrechnen....
Schade eigentlich, dass es so gekommen ist.
Ich bekomme jetzt langsam Lust, mir das eine oder andere M2T mal genauer anzusehen. Ich würde jetzt wirklich gern mal wissen, was in "meinem" m2t GENAU drin ist. frames, fields, timecode pro field, Zeilen, ... Am liebsten würde ich's mir wirklich field für field ansehen. Hat einer eine Idee für ein Tool?
Ja klar, MPEG2 Sezifikationen und Implementierungsanweisung. Gibt es bei MPEG. 1.433 Seiten. Jedes Bit ist da definiert:
Das ist das Schöne bei Standards.
Viel Spaß
deepbluetube hat geschrieben:Am liebsten würde ich's mir wirklich field für field ansehen. Hat einer eine Idee für ein Tool?
Ein Transport-Stream selbst ist eher uninteressant, interessanter sind die darin verpackten Streams (Audio, Bild, usw.)
Zwei Fields werden immer zu einem Frame zusammengefasst und auch zusammen komprimiert. Daher ist das Frame die kleinste zeitliche "Bildeinheit".
Die Syntax des Bitstreams ist veröffentlicht, daher steht solch einem Tool prinzipiell nichts im Wege. Der Aufwand ist jedoch nicht zu unterschätzen, insbesondere wenn man sich erst noch in die Spezifikation(en) einarbeiten muss.
WoWu hat geschrieben:
Ich bin durchaus nicht der Meinung, p liesse sich nicht übertragen.... ich bin nur der Meinung 1080p ergibt im HDV Umfeld ziemliche Probleme mit der Bandbreite. 720p ist ja nun seit den ersten tagen von HD überhaupt kein Thema und auch genügend Chips können das native erledigen.
Aber eben bei 1080p wird die Luft eben ziemlich dünn.
Es geht um 1080p bei 25/30fps? Das können auch "Consumer" Kameras mit progressivem Bildwandler.
Eine HV20 hat einen progressiven CMOS Bildwandler. Die Kamera hat einen progressiven 25fps-Modus. Lediglich für die HDV-Kompression wird ein progressiver Frame wie ein Frame aus zwei Halbbildern behandelt.
Und woher sollen die 1920x1080 native kommen ? Bei der Auflösung, egal ob in zwei Hälften oder nicht liegt man schon ohne Ton und Metadaten deutlich über 25 Mbit/s .... HDV hört aber spätestens bei 25 MBit/s auf .... was hat die DV20 als Datenrate ? ...
Ausserdem darf man sich von den 2,8 oder 2,9 MPix nicht ins Boxhorn jegen lassen... für die Bayer-Maske gehen dabei schon mal rd. 40% runter .. was bleibt, 1,7 MPix .... reicht also hinten und Vorn nicht.
..... Nicht auf die Marketingsprüche reinfallen ....
WoWu hat geschrieben:Und woher sollen die 1920x1080 native kommen ?
Vom verbauten CMOS natürlich. Laut Spezifikation werden 2,070,000 Pixel im 16:9 Betrieb verwendet. 1920 mal 1080 = 2073600.
WoWu hat geschrieben:
Bei der Auflösung, egal ob in zwei Hälften oder nicht liegt man schon ohne Ton und Metadaten deutlich über 25 Mbit/s .... HDV hört aber spätestens bei 25 MBit/s auf .... was hat die DV20 als Datenrate ? ...
Was hat Auflösung mit der Datenrate eines Transport- bzw. Aufzeichnungsdatenstromes zu tun? -> Erstmal nichts.
Und falls die interne "Datenrate" der noch unkomprimierten Bilddaten gemeint ist: Die liegt selbstverständlich deutlich über der Datenrate der erzeugten MPEG-2 Datei.
WoWu hat geschrieben:Ausserdem darf man sich von den 2,8 oder 2,9 MPix nicht ins Boxhorn jegen lassen... für die Bayer-Maske gehen dabei schon mal rd. 40% runter .. was bleibt, 1,7 MPix .... reicht also hinten und Vorn nicht.
Nun geht es auf einmal über die Vor- und Nachteile von 1-Chip gegenüber 3-Chip Kameras? Ich dachte es geht hier um angeblich nicht handhabbare Datenmengen progressiver 25fps Aufnahmen?
Also nun lass uns doch nicht wieder bei Null anfangen:
Lesen hilft:
Farbmaske von der Chipauflösung abziehen.
Das hat nichts mit Vor- oder Nachteilen von 1-Chip oder 3-Chip zu tun.
Die Mühle hat eben nur ein Chip und wenn Du die Aufteilung der Farbmaske abziehst, kommst Du nicht mal mehr auf die erforderliche Auflösung ... schliesslich macht die Kamera ja nicht ur Schwarz-weiss.
Was hat Auflösung mit der Datenrate eines Transport- bzw. Aufzeichnungsdatenstromes zu tun? -> Erstmal nichts.
Mann Du bist gut .... natürlich hat die Datenrate was mit dem TS zu tun:
1920x1080 in 8 Bit + 1/2 Chroma in 8 Bit + Ton + Metadaten ..... das will doch schliesslich alles transportiert sein.
Selbst wenn die kamera intern mit 4:4:4 arbeiten würde, nutzt es Dir absolut nichts, wenn Du aus der FW nur müde 25 Mbit rausbekommst.
Aber bitte, das ist hier auch schon 1929x1081-mal behandelt worden ... bitte nachlesen ...
WoWu hat geschrieben:
Farbmaske von der Chipauflösung abziehen.
Es geht in dieser Diskussion NICHT um erfassbare Details, sondern um zu verarbeitende Pixel! Für die weitere Bildverarbeitung - und darum ging es bisher - ist es völlig egal, ob die 1920x1080 RGB-Pixel mit Hilfe von drei Sensoren, einem Sensor oder einem Testbildgenerator erzeugt werden.
WoWu hat geschrieben:
1920x1080 in 8 Bit + 1/2 Chroma in 8 Bit + Ton + Metadaten ..... das will doch schliesslich alles transportiert sein.
Selbst wenn die kamera intern mit 4:4:4 arbeiten würde, nutzt es Dir absolut nichts, wenn Du aus der FW nur müde 25 Mbit rausbekommst.
Wenn man die (verlustbehafteten) Kompressionsstufen vergisst, kommt man natürlich zu seltsamen Ergebnissen.
Der Kompessionsfaktor von MPEG ist ja nun kein Geheimnis mehr oder meinsst Du, dass sie den für 1920x1080 hochgesetzt haben oder plötzlich mit 37er GoPs arbeiten ?
WoWu hat geschrieben:Der Kompessionsfaktor von MPEG ist ja nun kein Geheimnis mehr oder meinsst Du, dass sie den für 1920x1080 hochgesetzt haben oder plötzlich mit 37er GoPs arbeiten ?
Tut mir leid, es werden Zusammenhänge gesucht, wo keine sind. Daher nur noch ein paar knappe Anmerkungen:
Erstens: Der Kompressionsfaktor von MPEG ist nicht fix. Zweitens: Wenn man ihn anpasst, tut man dies nur selten über die Group of Pictures. Drittens: Das verwendete Aufzeichnungsformat HDV 1080 hat eine ganz klar definierte Auflösung und Transportstromdatenrate, dem hat sich der MPEG-Encoder zu unterwerfen. Und Viertens: Das hat alles nichts mehr mit progressiv oder interlaced zu tun.
Erstens: Der Kompressionsfaktor von MPEG ist nicht fix.
Nein, aber im HDV Standard mit 18:1 festgelegt.
Zweitens: Wenn man ihn anpasst, tut man dies nur selten über die Group of Pictures.
Deswegen hat HDV 1 auch eine GoP von 6 und HDV 2 eine von 16..... weil man solche sachen, wie Du sagst nicht über die GoP regelt.
Vorschlag: Reich´einen Verbesserungsvorschlag bei MPEG ein, wenn Du es besser machen kannst.
Drittens: Das verwendete Aufzeichnungsformat HDV 1080 hat eine ganz klar definierte Auflösung und Transportstromdatenrate, dem hat sich der MPEG-Encoder zu unterwerfen.
Sag ich doch ... nur dass der MPEG Standard, anders als der im heimischen Computer sitzende Encoder keine Möglichkeiten vorsieht, Abweichungen vom Standard mitzuteilen.
Du hast es hier mit einem fest vorgeschriebenen Standard zu tun und nicht mit einer Bastelecke für Programmierer.
Und Viertens: Das hat alles nichts mehr mit progressiv oder interlaced zu tun
Das hab ich auch nicht gesagt, es geht lediglich um die Datenrate bei 1920x1080 bei den gegebenen Parametern für HDV.
Ich weiss nicht, warum Du also immer auf i oder p abhebst. Dein sensor gibt das wie beschrieben schon gar nicht mehr her.
Und jetzt fang nicht wieder mit 1-chip oder 3-chip an .... Die Mühle hat nun mal nur einen Chip, macht aber damit Farbe .. also muss man die Auflösung auch damit berechnen ...
Im Bedarf: Grundlagen Bildsensor nachlesen.
Anonymous hat geschrieben:
Nein, aber im HDV Standard mit 18:1 festgelegt.
Ich bin recht zuversichtlich, dass dort nirgens 18:1 steht, sondern ein Anteil an der Gesamtdatenrate festgelegt wird. Die MPEG-Kompression darf bestimmt auch höher sein, dann werden eben Füllbits hinzugefügt...
Anonymous hat geschrieben:
Deswegen hat HDV 1 auch eine GoP von 6 und HDV 2 eine von 16..... weil man solche sachen, wie Du sagst nicht über die GoP regelt.
Richtig, tut der Encoder in der Regel auch nicht. Warum nun manchmal kürzere GoPs verwendet werden, und wann längere, und wieso und warum was wann sinnvoll ist, könnte ich jetzt zwar motivieren, aber da Du ja sowieso irgendwo Einspruch erheben wirst, werde ich es lieber lassen.
Anonymous hat geschrieben:
Vorschlag: Reich´einen Verbesserungsvorschlag bei MPEG ein, wenn Du es besser machen kannst.
Ahja.
Anonymous hat geschrieben:
Sag ich doch ... nur dass der MPEG Standard, anders als der im heimischen Computer sitzende Encoder keine Möglichkeiten vorsieht, Abweichungen vom Standard mitzuteilen.
Der "Standard" für den Heim-PC soll erlauben Abweichungen vom Standard mitzuteilen? Das wäre ja ein toller Standard, sozusagen ein selbstbeschreibender...
Anonymous hat geschrieben:
Du hast es hier mit einem fest vorgeschriebenen Standard zu tun und nicht mit einer Bastelecke für Programmierer.
Der Encoder ist nie vorgeschrieben. Auch bei keinem MPEG-Format. Nur der Aufbau des Bitstroms. Was das der Vergleich mit einer Bastelecke soll, ist mir ein Rätsel.
Anonymous hat geschrieben:
Das hab ich auch nicht gesagt, es geht lediglich um die Datenrate bei 1920x1080 bei den gegebenen Parametern für HDV.
Ich geb's beinahe auf. 1920 -> Downsampling -> 1440, das muss wegen HDV bei dieser Kamera zuerst geschehen. Dann MPEG...
Das hat aber erstmal nichts mit dem Bildsensor zu tun...
Nein, ich geb's auf.
Anonymous hat geschrieben:
Ich weiss nicht, warum Du also immer auf i oder p abhebst. Dein sensor gibt das wie beschrieben schon gar nicht mehr her.
Ich glaube, nichts von dem, was ich sagen wollte, ist angekommen. Aber lassen wir es.
Immerhin haben wir uns jetzt bald im Kreis gedreht und über Dinge gesprochen, von denen erst gar keine Rede war.
Nein, gar kein Einspruch .... ich verstehe nur nicht, warum Du HDV neu erfinden willst und noch nicht von Leonardo Chiariglione ins Expertenteam berufen worden bist.
Natürlich gibt es andere Mittel als die GoP um Bandbreiten zu verändern. Wie Du aber siehst, ist dies durchaus ein probates Mittel.
Die MPEG-Kompression darf bestimmt auch höher sein, dann werden eben Füllbits hinzugefügt...
Welchen Sinn würde das machen , ausser zur Bildverschlechterung beizutragen.
Der "Standard" für den Heim-PC soll erlauben Abweichungen vom Standard mitzuteilen?
Das war nicht auf den Standard bezogen aber Du kannst natürlich jede beliebige Abweichung vom Standard programmieren, solange Du Dir auch den entsprechenden Decoder dafür bastels ...
Nur ein, dem Standard entsprechender Decoder kapiert das dann nicht mehr.
Der Encoder ist nie vorgeschrieben. Auch bei keinem MPEG-Format. Nur der Aufbau des Bitstroms.
Der Decoder ergibt sich zwangsläufig aus der Definition des Bitstreams. Lediglich die Implementierung ist nicht bis ins letzte Detail vorgeschrieben. Allerdings werden "gute" Implementierungen immer mit der Referenzimplementierung des abgeglichen.
Bevor Du mir Unwissen unterstellst, solltest Du Selbstkritik üben:
Allein den Begriff "Bandbreite" verwendest Du sowas von schwammig. Den Abstand zweier Frequenzen kannst Du in dem Zusammenhang ja eher nicht meinen, ich vermute daher Du meinst Ãœbertragungsrate oder Datenmenge/s.
GoPs haben damit nicht viel zu tun. Eine größere GoP kann lediglich die Kompressionseffiziens verbessern und zu einer höheren Bildqualität führen, da mehr Redundanzen ausgenutzt werden können. Große GoPs haben aber auch Nachteile. Aber all dies hast Du nicht geschrieben.
Die eigentliche adaptive Datenratensteuerung geschieht in der Regel über die Quantisierung.
WoWu hat geschrieben:Nein, gar kein Einspruch .... ich verstehe nur nicht, warum Du HDV neu erfinden willst und noch nicht von Leonardo Chiariglione ins Expertenteam berufen worden bist.
Kannst mich ja gerne vorschlagen.
WoWu hat geschrieben:
Die MPEG-Kompression darf bestimmt auch höher sein, dann werden eben Füllbits hinzugefügt...
Welchen Sinn würde das machen , ausser zur Bildverschlechterung beizutragen.
Der Sinn wäre, die vorgeschriebene Datenrate einzuhalten, um dem Standard zu entsprechen.
WoWu hat geschrieben:
Das war nicht auf den Standard bezogen aber Du kannst natürlich jede beliebige Abweichung vom Standard programmieren, solange Du Dir auch den entsprechenden Decoder dafür bastels ...
Nur ein, dem Standard entsprechender Decoder kapiert das dann nicht mehr.
Wenigstens ein Punkt, bei dem wir Ãœbereinstimmung erreicht haben.
WoWu hat geschrieben:
Der Decoder ergibt sich zwangsläufig aus der Definition des Bitstreams.
Nicht unbedingt komplett, in eher unkritischen Bereichen, wo sich Fehler nicht akkumulieren können (mehrfache Kompression/Dekompression einmal aussser Acht gelassen), kann man auch Freiräume lassen.
Hallo, ihr dreht eich da im Kreis und macht die Geschichte an HDV fest was unter Umständen die Sicht auf andere Möglichkeiten leicht verzerrt.
Da ja die HD Cams von JVC besonders die neuen HD5 und 6 Modelle immer zitiert werden.
Die JVC Cams besonders die neuen Unterliegen nicht mehr den HDV Specs und haben einen einzigen Modus um HDV Konforme Files zu schrieben die via Firewire zur Weiterverarbeitung abgelegt werden. Alle anderen Filetypen besonders die neue LOW Variante die auch auf SD Medium aufgezeichnet werden kann unterliegt nicht den HDV Specs.
Und es ist ein großer fehler zu meinen das sich die Mpeg Codecs an dem HDV Standard orientieren müssen. Vielmehr ist der HDV Spezifizierte Ableger ein Part der Mpeg Specs sprich ein Preset dessen. Selbiges gilt für die AVCHD Krücke die sich nach allen Seiten offen am h264 part x orientiert.
Das können und wollen der Hersteller liegt nicht an deren Möglichkeiten sondern eher an deren Willen und warum soll ich Wollen wenn ich Cams mit dieser Leistung um ein vielfaches des Preises der Consumercams an den Mann bringen muss.
Absolut richtig ... nur Eingangs ging es einmal hier einmal darum, 1080p in HDV zu übertragen und das Thema war dann in die Komponenten A die HV 20 hat keinen Chip der 1080p zulässt und B selbst wenn es ginge, passt es nicht in HDV.
Ich gebe Dir völlig Recht, dass HDV eine ziemlich überflüssige Limitierung darstellt und dass es sicher weitere, andere vernünftige Verfahren gäbe, Qualität an den Kunden zu bringen.
Nur die Hersteller wollen natürlich auch Planungssicherheit und die damit verbundene Marktakzeptanz und nicht nur bei den Kunden, sondern auch bei den Firmen, die das Format unterstützen.
Kunden, wie die Broadcaster wollen damit erreichen, nicht länger von nur einem Lieferanten abhängig zu sein, was ich gut verstehe.
Ich denke, dies sind die Gründe, weshalb Standards geschaffen werden.
Dass aber die Hersteller auch daran interessiert sind, den Schritt zu einer guten Qualität durch entsprechend viele "Innovationsschritte" zu unterteilen hat letztlich etwas mit Gewinnmaximierung zu tun. Das mag ja auch seine Berechtigung haben. Mein einziger Vorwurf besteht darin, dass sie den Kunden einfach nur Dinge auf der Verpackung vorgaukeln, die nicht enthalten sind.
Das Problem bei den "weiterreichenden" Formaten ist eben die Frage, wer unterstützt die Formate ..?
Siehe auch die aktuelle Diskussion der EX1 .... ohne die Sony-eigene Software läuft da wenig ... und die ist kritikwürdig genug. Nun stell dir so etwas einmal im breiten Consumerkreis vor.
Daher denke ich auch, dass die H.264 Variante (nicht AVCHD) von MPEG deutlich besser (weil erheblich weiter) spezifiziert ist als MPEG2 und die Verbesserungsschritte innerhalb des Standards schneller möglich sind.
(Wenn denn dann endlich auch einmal 1080p50 definiert werden würde).
Von proprietären Lösungen halte ich nicht besonders viel, weil sie sich morgen schon wieder ändern können und alte Versionen häufig nicht mehr gepflegt werden. Dem gegenüber stehen eben solche Lösungen wie MPEG2, an dessen Verbesserung über 15 Jahre gearbeitet wurde, mit dem Resultat, dass es dato kaum mehr etwas zu verbessern gibt und eine maximale Qualität bei voller Kompatibilität erreicht worden ist.
Siehe auch die aktuelle Diskussion der EX1 .... ohne die Sony-eigene Software läuft da wenig ... und die ist kritikwürdig genug. Nun stell dir so etwas einmal im breiten Consumerkreis vor.
Nun aber das haben wir doch schon wenn ich die AVCHD Files von Sony mit denen der Panas vergleiche. Vegas selbst hat in den Anfängen der Avchdunterstützung nur die SonyFiles bedient da sie sich von denen der Panas sehr wohl unterschieden.
Und es ist wie es ist MPEG2 hatte und noch seine Zeit vor sich und h264AVC ist im Kommen aber durch die momentane Leistung der Systeme max. als Archiv u. Distributionsformat seine Berechtigung.
Und es ist nun Klar wie Kloosbrühe, die Cams können auch 1080p nur dürfen sie nicht in dieser Preisklasse, den ich als Hersteller werde mir meinen Profilinienast nicht absägen. ProfilinienAst super Wort wie meine*gg
Anonymous hat geschrieben:Und es ist nun Klar wie Kloosbrühe, die Cams können auch 1080p nur dürfen sie nicht in dieser Preisklasse, den ich als Hersteller werde mir meinen Profilinienast nicht absägen. ProfilinienAst super Wort wie meine*gg
Jesses, deine Sätze gehören aber auch deinterlaced!
Na und? Im Fernsehen wird ja auch alles wiederholt ...
@ TheBubble - die Semiprofessionelle HDV Sony HDR FX 7 benutzt zb einen Cleavid CMOS Sensor mit 1080x960 (steht in internen Sony Unterlagen), man könnte ja vorher auch denken das sie einen 1440 oder 1920er CMOS hat. Ich habe keine genauen Kenntnisse was Canon bei der HV 20 & 30 wirklich für einen Sensor einsetzt - es muss aber kein 1920er sein.
Es wäre schon ungewöhnlich warum die 3x teurere Sony einen deutlich schlechteren CMOS als die HV 20 & 30 hat. Ich glaube die Firmen flunkern mit uns ein wenig....
"flunkern" war nun wirklich sehr freundlich ausgedrückt ... und zeugt von viel Nachsicht. Ich wäre in der Wahl meiner Begriffe, wie Du weist, nicht so nachsichtig.
@ Gast
Nun aber das haben wir doch schon wenn ich die AVCHD Files von Sony mit denen der Panas vergleiche. Vegas selbst hat in den Anfängen der Avchdunterstützung nur die SonyFiles bedient da sie sich von denen der Panas sehr wohl unterschieden.
Gerade das ist ja der Kern dessen, was zuvor beschrieben wurde.
AVCHD ist nicht der Standard !!!!!! Darin machen die Firmen so ziemlich was sie wollen und benutzen nur Teile aus dem Standard.
Und das ist gerade der kern des Mangels !!!
MPEG4/H.264-AVC ist der Standard.
Aber solange es noch Redakteure, sei es bei Zeitschriften oder im Internet gibt, die in ihren Texten den Unterschied nicht kennen und Camcorder, die zwar H.264 unterstützen, nicht aber die proprietären AVCHD Formate, quasi als nicht standardkonform bezeichnen, wird es wohl noch eine Weile dauern, bis wir wirklich über einheitliche und verlässliche Qualitäten verfügen.
aber durch die momentane Leistung der Systeme max. als Archiv u. Distributionsformat seine Berechtigung.
Lass Dir doch so einen Quatsch nicht einreden. Das ist Pfeiffen im Wald und ein gefährliches Gemisch aus Unkenntnis und Hoffnung, dass alles so bleibt, wie es einmal war.
Und es ist wie es ist MPEG2 hatte und noch seine Zeit vor sich
Also, wenn ich das richtig verstanden habe meinst Du, MPEG2 sei erst richtig im Kommen ?
Na, ich weiss nicht ob soviel Optimismus dann auch seine Erfüllung finden wird. Schau Dir mal die Palette der aktuellen Modelle an .... ausser einem neuen Gehäuse für die HV30 hat es ein neues Modell in HDV im Consumerbereich von Sony gegeben.
Vielleicht noch hier und da ein anderes Modell, das sich jetzt hier nicht so vergenenwärtigt aber die überwiegenden Neuerscheinungen kamen im MPEG4-Bereich.
Die Zeit hat es bereits gezeigt, wohin der Trend geht ...
Aber Herr WoWu das bestreitet doch kein Mensch. Es ist doch keine Frage das es einen Umschwung geben in Richtung h264AVC aber es unterliegt alles einer gewissen Zeitspanne und für den Otto Normalverbraucher ist es eben so wie schon beschrieben. Die Cams sind da nur die Schnittmöglichkeiten eben noch nicht wie sie in Preis/Zeit/LeistungsVergleich sein sollten. Selbiges hatten wir schon bei der Umstellung vom SD zum HD Format auf HDV Specs basierend. Das die Hersteller die Cams in Richtung AVCHD Cardbasierend produzieren liegt doch Hauptsächlich am Unwissen der Konsumenten und der Möglichkeit die Kosten niedrig zu halten. Stöbert man die Foren durch sind die Beiträge voll von Usern dieser neuen Cam Generation die mit den AVCHD Cams noch immer das Problem haben das sie nicht wissen was sie mit dem Rohmaterial machen sollen und sie plötzlich von den Kosten überollt werden bei der Anschaffung der Zusatzhardware und Software.
Anfang 2007 waren die Leute mit einem E6600 Dualcore Uptodate. Heute stellt sich heraus das du dich mit einem Quadcore abmühen musst das du in der Timeline die FullHd AVCHD Files in RT bearbeiten kannst und das selbst bei nur einer Spur.
Sei es darum Du hast recht es wird kommen und die Leute werden kaufen wie ich auch nur bis dahin hat meine neue HDV Cam schon den Geist aufgegeben.
Und es stimmt auch im Consumerbereich werden von Sony vermutlich keine neuen Mpeg2 basierenden Cams mehr entwickelt aber in der Pro Liga schon und Sony und Canon sind Gott sei Dank nicht die einzigen Hersteller.
Anonymous hat geschrieben:
Stöbert man die Foren durch sind die Beiträge voll von Usern dieser neuen Cam Generation die mit den AVCHD Cams noch immer das Problem haben das sie nicht wissen was sie mit dem Rohmaterial machen sollen und sie plötzlich von den Kosten überollt werden bei der Anschaffung der Zusatzhardware und Software.
Gut, die hätten sich aber auch vor dem Kauf informieren können - seit geraumer Zeit predigen wir die Probleme mit der Bearbeitbarkeit im Fall von AVCHD.
Anonymous hat geschrieben:
Anfang 2007 waren die Leute mit einem E6600 Dualcore Uptodate. Heute stellt sich heraus das du dich mit einem Quadcore abmühen musst das du in der Timeline die FullHd AVCHD Files in RT bearbeiten kannst und das selbst bei nur einer Spur.
Ja, das ist ein enormes Problem - das 1920er AVCHD ist halt nochmals schwerer bearbeitbar als das 1440er AVCHD, und die Leute wollen halt auch immer gerne nativ schneiden. Und die Intermediate codecs sind ihnen halt auch immer ein Greuel - hauptsache, es ist kein Band mehr, hauptsache, man ist modern unterwegs. Das Gejammere kommt dann nach dem Kauf.
Anonymous hat geschrieben:
Und es stimmt auch im Consumerbereich werden von Sony vermutlich keine neuen Mpeg2 basierenden Cams mehr entwickelt aber in der Pro Liga schon und Sony und Canon sind Gott sei Dank nicht die einzigen Hersteller.
HDV wird sich schon noch eine Zeit halten, bevor die letzten HDV-Camcorder vom Markt verschwinden werden sich halt viele noch eindecken, vermutlich mit Geräten wie einer HV30.
Jan hat geschrieben:Ich habe keine genauen Kenntnisse was Canon bei der HV 20 & 30 wirklich für einen Sensor einsetzt - es muss aber kein 1920er sein.
Die HV20 hat einen CMOS der 3 Megapixel-Klasse mit Farbmaske. Welche Farbmaskenanordnung zum Einsatz kommt, weiss ich leider nicht. Bei 1920x1080 Aufnahmen werden davon ungefähr 2 Megapixel verwendet (die übrigen Pixel befinden sich ober- und unterhalb der Aufnahme und können im Fotomodus eingesetzt werden).
wolfgang hat geschrieben:... das 1920er AVCHD ist halt nochmals schwerer bearbeitbar als das 1440er AVCHD, und die Leute wollen halt auch immer gerne nativ schneiden. Und die Intermediate codecs sind ihnen halt auch immer ein Greuel - hauptsache, es ist kein Band mehr, hauptsache, man ist modern unterwegs. Das Gejammere kommt dann nach dem Kauf.
HDV wird sich schon noch eine Zeit halten, bevor die letzten HDV-Camcorder vom Markt verschwinden werden sich halt viele noch eindecken, vermutlich mit Geräten wie einer HV30.
Genau so werde ich es aus den weiter oben geschilderten Gründen auch machen! Es lebe HVD und die HV30!!
i7-920, 12 GB, NVidia GTX 750 TI 2 GB , 3x WD7500 750 GB, LG GGW-H20LRB, 2x Samsung 2443 FW 1920x1200 - Win7/64, Vegas Pro 13 - Canon HF G30, Sony HC9, Canon HV20
_____________________________________
Gruß kowi
Anonymous hat geschrieben:Profis arbeiten mit allem... ( aber nicht mit HDV)
Troll Gefasel, das bereits seit geraumer Zeit Off Topic ist. Eröffne doch einen neuen Thread für Pixelzähler und die Profis, die über Consumerformate gern ablästern. Und registrier dich bitte, damit man dich mal zu fassen kriegt, "Gast".
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
