• Ich habe den Text schon richtig verstanden.
    Entscheidend ist folgendes, was ich bereits erwähnte ;)

    Zitat von Check It Out

    Schau einfach in die DV-Norm (EN 61834-2), Punkt 7.8: "Jeder komprimierte Makroblock hat 77 Bytes Daten".


    Da steht es schwarz auf weiss und bietet keine Interpretationsmöglichkeiten.

    Liebe Grüße

    Check It Out

  • Im Durchschnitt hat ein Macroblock 77 Bytes. Aber nicht jeder Makroblock ist auf 77Bytes festgelegt!

    Zitat

    Variable length coding (VLC) distributes coded data throughout a fixed encoded data structure. In the context of the DV specification, a PAL system employs a video frame containing 1620 macro blocks, whereas an NTSC system employs a video frame containing 1350 macro blocks. Each macro block comprises four luminance (Y) discrete cosine transformation (DCT) blocks, and two chrominance (Cr and Cb) DCT blocks. The total picture elements in a video frame are divided into 60 super blocks for PAL, and 50 super blocks for NTSC. Each super block consists of 27 macro blocks. Furthermore, a video segment comprises 5 macro blocks from various areas within the video frame. The macro blocks in the video frame are shuffled by forming video segments. On average, each macro block is compressed from 384 to 77 bytes. This shuffling process averages out the frequency characteristics of the data and hence reduces the degree of difficulty of compression.

    http://209.85.129.104/search?q=cache…en&ct=clnk&cd=1

    D.h. Bildflächen beeinflussen sich gegenseitig.
    Die Makroblöcke werden nicht einzeln auf 77Bytes gepresst. Das wäre ja viel zu einfach und würde die komplexität von DV ja garnicht erklären oder rechtfertigen.

  • Check It Out: man sollte sich nicht immer auf nur eine einzige Quelle verlassen.
    Und cedocida kannst Du ruhig glauben, er ist der Autor des gleichnamigen DV-Codecs.


    Off-Topic
    cedocida: ich werde demnächst nocheinmal versuchen, den Bug zu reproduzieren.

  • Zitat von scharfis_brain

    Check It Out: man sollte sich nicht immer auf nur eine einzige Quelle verlassen.


    Wenn die DV-Norm diese Quelle ist, dann darf man sich schon darauf verlassen, denke ich. :D

    Mal ein Auszug:

    Zitat

    7.8 Die Anordnung eines komprimierten Makro-Blocks

    Ein komprimiertes Videosegment besteht aus fünf komprimierten Makro-Blocks. Jeder komprimierte Makro-Block hat 77 Bytes Daten. Die Anordnung des komprimierten Makro-Blocks muß sein, wie in Bild 37 gezeigt. Die Bereiche Y0, Y1, Y2, Y3, CR und CB sind als komprimierte Datenbereiche definiert, und jeder von Y0, Y1, Y2 und Y3 besteht aus 112 Bits, und jeder von CR und CB besteht aus 80 Bits.


    Also nicht nur die Makroblöcke haben eine feste Größe, sondern auch die sechs Blöcke mit 4x14 Bytes und 2x10 Bytes. Hinzu kommen noch 4 Bits für den Zustand des komprimierten Makro-Blocks (STA) und 4 Bits für die Quantisierungsnummer (QNO), also das noch fehlende Byte zu den insgesamt 77 Bytes.

    Genauer kann ich nicht mehr werden und Ihr dürft mir schon glauben :cheers:

    Liebe Grüße

    Check It Out

  • Zitat

    Die Europäische Norm EN 61834-2:1998 hat den Status einer Deutschen Norm.

    Diese Norm enthält die deutsche Übersetzung der Internationalen Norm IEC 61834-2


    Mir liegt nur die deutsche Übersetzung vor, die stimmt aber ;)

    Liebe Grüße

    Check It Out

  • Ganz sicher? denn sämtliche andere Quellen, die ich durchforste sprechen vom Gegenteil:
    Das Videosegment hat konstante Datenrate, aber die Makroblocks sind variabel.

    Auch mein Sample spricht eindeutig dagegen, dass jeder Makroblock gleich viele daten enthält.
    Das wirft ja das ganze DV-konzept über den Haufen!

    Und selbst wenn ich nach den von Dir zitierten Auszügen suche, finde ich NIX.

  • Hier noch ein paar Anmerkungen zur eigentlichen Problematik, kommt zwar etwas spät, aber es gibt ja noch real life ...

    Check It Out

    ... Du scheinst ja die Weisheit mit Löffeln gegessen zu haben, aber glaube mir, Dein Auftritt hier ist keine Glanzleistung.

    Der nachfolgene Nachschlag ist für simone.i bestimmt, übergehe ihn einfach, denn Du weißt es bestimmt wieder besser ...

    @ simone.i

    PAR Angaben basieren auf dem > ITU-R BT.601 < Standard. Dieser wurde eingeführt, um analoge Videosignale in digitale Informationen umzusetzen.
    Der Standard geht sowohl bei PAL als auch bei NTSC von 702 horizontalen Pixeln. Da 702 keine mod 4 konforme Matrizen ermöglicht, wurde dieser Wert auf 704 erhöht.
    Die dazu gehörenden PAR betragen bei 4:3 PAL 12/11 = 1.091 oder 128/117 = 1.094
    Bei 16:9 PAL ist der korrekte Wert 16/11 = 1,4545.

    Dieser Standard wurde mit der Einführung der rein digitalen Bildbearbeitung (Quell- und Zielformat digital) nicht vollständig übernommen, vielmehr darf bei 4:3 PAL die PAR jetzt auch 64/60 = 1,0667 betragen und 16:9 anamorphes PAL verwendet jetzt auch 64/45 => 1,4222.

    Praktisch jede Hobbyschnittsoftware verwendet 1,0667 bzw. 1,4222, professionelle Schnittsysteme bieten aber den alten ITU-Standard auch an.

    720 horizontale Pixel wurden deshalb gewählt,damit die SMW (Sampling Matrix Width) genau 52,33333 usec beträgt.
    Mit 702 Pixeln wäre sie exact 52.0 usec, 702 ist aber nicht mod4 fähig => Probleme mit diversen Encodern.

    Ein Player zeigt 4:3-Material in einem Raster von 768 x 576 Pixeln an, ein 720x576-Pixel-Video erzeugt einen ARS (Aspect Ratio Signalling),
    wobei die 720 horizontalen Pixel auf virtuelle 768 Pixel durch Multiplikation mit 1.0667 gespreizt werden. Dadurch erscheint ein Kreis rund, während er im "echten" 720x576-Format leicht horizontal gestaucht bzw. in die Höhe gestreckt erscheinen würde.

    Ein Raster von 768x576 Pixeln kommt bei der DV-Videobearbeitung grundsätzlich nicht real vor. DV-Kameras liefern sowohl im Fullscreen 4:3 als auch im anamorphen 16:9-Modus 720x576 Pixel, das gilt auch z.B. für DVCPRO, DVCPRO-50 .

    Das non-anamorphe SD 16:9 Widescreen Bild besteht aus 1024x576 Pixeln. Ein Player schaltet beim Erkennen dieses Formats automatisch auf dieses Verhältnis um. Eine Spaltenanzahl von z.B 1050 Spalten ist nicht vorgesehen, weil dieser Wert nicht mit einer 2-er Potenz darstellbar ist => 2^10 = 1024 => 2^11 = 2048 ...

    Will man das 4:3-DV-Format nach 16:9 konvertieren, dann gibt es zwei Möglichkeiten:

    1) Pillarbox-Verfahren
    2) Crop-Resize-Verfahren

    Beim Pillarboxverfahren (darum geht es ja zur Zeit) muß man unterscheiden zwischen DV-Video und 4:3-Einzelbildern von einer digitalen Photokamera. Letztere liefert quadratische Pixel, während DV leicht "gequetscht" ist (PAR...)

    4:3-Einzelbilder von (den meisten) digitalen Photokameras bieten von Hause aus ein Seitenverhältnis von 1,333, also 768x576, 1536x1152, 3072x2304 mit PAR = 1.0 , diese Bilder passen nicht 1:1 in das Raster 720x576 (1.25:1).

    Da die virtuelle horizontale Basis eines 720-Pixelbildes 768 Pixel ist, muß das reale 768-Pixelbild entweder auf 720 h-Pixel herunterscaliert oder die 720 Pixel des DV-Streams auf 768 h-Pixel hochskaliert werden. Danach weisen beide Quellen die gleiche PAR auf, im ersten Fall 1.0667 und im zweiten Fall 1.0, d.h. im zweiten Fall sind die Pixel quadratisch. Die Quellen können danach zusammengeschnitten werden.

    Aufbauend auf Fall 2 (quadratisch), können die DV und Einzelbilder mit jeweils 128 schwarzen (oder auch in anderer Farbe) Spalten auf
    1024 Pixel ergänzt werden und man erhält non-anamorphe 16:9-Quellen mit einem PAR=1.0.

    Ist die Schnittsoftware in der Lage, non-anamorphes Material zu verarbeiten, können die Quellen unmittelbar importiert werden. Ist sie das nicht, dann müssen die Quellen manuell nach anamorph skaliert werden (z.B. mit AVISynth), d.h. sie müssen horizontal wieder so gestaucht werden, daß aus 1024 Spalten 720 (DV-Format) werden, denn dieses Format kann jede Schnittsoftware verarbeiten.

    Wohlgemerkt: Das 16:9-Format mit PAR=1.0 dient hier lediglich als Zwischenstufe innerhalb einer Videobearbeitung zur späteren Erstellung eines normgerechten anamorphen SD 16:9 Formats.

    Dieser Weg ist der ganz genaue ... Man kann aber auch die PAR vernachlässigen und gleich von 720 h-Pixeln ausgehen. Diese Möglichkeit habe ich im ersten Post gewählt, weil ich nicht sicher war, ob die PAR-Problematik für den/die Fragesteller(in) im ersten Anlauf schon von Nutzen gewesen wäre. Mein Hinweis auf AVISynth hätte eigentlich für die Spezialisten genügen sollen zu erkennen, daß da u.U. noch mehr hätte nachkommen können.

    To whom it may concern:

    Bemerkungen wie Blödsinn, Schwachsinn und selbstgefällige Prozentkorinthenkackereien sind kein guter Stil.
    Wenn man von etwas keine Ahnung hat, dann sollte man dies nicht in dieser Form kundtun, so etwas negiert das Niveau und hält andere in Zukunft davon ab, Hilfesuchenden unter die Arme zu greifen.

    Ich melde mich deshalb aus diesem Thread ab.

    SixdeeBee

  • Für den interessierten Leser mag vielleicht auch das folgende Dokument (von Sony, die mitunter an der Entwicklung von DV nicht ganz unschuldig sind) hilfreich sein: http://www.sony.ca/dvcam/pdfs/dvcam%20format%20overview.pdf
    insbesondere Seite 19 (bzw. pdf-Dokument Seite 21). Dort ist sehr anschaulich beschrieben wie die komprimierten Daten im Segment verteilt werden.
    Die Verwirrung kommt wahrscheinlich auch deshalb zustande, weil unter dem Begriff "compressed Macroblock" in der Spec. eben die 77Byte im DIF-block bezeichnet werden, genau genommen dort aber auch die komprimierten Daten aus anderen Macroblöcken vorhanden sein können.

    Check It Out
    Mir liegen sowohl die deutsche Übersetzung als auch die englische und französische Variante vor. Die stimmen auch alle! Du verstehst sie nur in diesem Punkt nicht richtig. Genauer möchte auch ich nicht mehr werden, Du "darfst mir schon glauben".

  • @ scharfis_brain
    Habe im Anhang mal die Passagen aus der DV-Norm abfotografiert.

    Variabel sind nur die Quantisierungen. Allein dadurch entsteht die unterschiedliche Qualität in entsprechenden Samples. Der große Textauszug vor ein paar Beiträgen beschreibt, dass so lange quantisiert wird, bis 77 Byte entstehen. Die Effizienzsteigerung entsteht aus der beliebigen Zusammenfassung gleicher bzw. ähnlicher Quantisierungen in 5er-Makroblöcken.


    @ SixdeeBee
    Ich wollte eigentlich nur Fehler richtigstellen. Beleidigt habe ich dabei nicht.

    Die Antworten an simone.i wurden im Thread bereits gegeben:
    - wurde DV in 4:3 aufgenommen, die DVD auch so erstellen. Bei richtiger TV-Einstellung gibt es am 16:9-Flach-TV links und rechts schwarze Balken.

    - wird DV in echtem 16:9 aufgenommen, die DVD auch in 16:9 erstellen. Gibt Vollbild am 16:9-Flach-TV.

    - wird DV in Pseudo 16:9 aufgenommen, kann man umrechnen. Wer sich aber nicht auskennt, sollte es lassen und am TV aufzoomen. Ansonsten für Anfänger zu viel Arbeits- und Zeitaufwand, sowie Fehlerquelle (interlace resize u.a.)

    - hat man den seltenen Fall, dass man gemischte DV zu einer DVD bzw. einem einzigen Film zusammenstellen will, so muss man das 4:3-Material entsprechend umrechnen. Sollte man vermeiden.


    Schade, dass niemand auch nur ein Minimum an falschen Einlassungen zugibt :nein:

    @ cedocida

    Und was sollte ich an der Aussage "Jeder Makro-Block hat 77 Bytes an Daten" und zugehörigem "Bild 37" in der Norm falsch verstanden haben?

  • Zitat

    Variabel sind nur die Quantisierungen. Allein dadurch entsteht die unterschiedliche Qualität in entsprechenden Samples.


    Aber wieso sollte sich dann die Qualität bzw. Quantisierung in der Bildmitte bei meinen Samples ändern?

    Erklärs mir!
    1) Warum ist das Letterbox-Bild mit schwarzen Balken von besser Qualität in der Bildmitte, als das 4x3 Vollbild.
    2) Und warum ist das Letterbox-Bild mit den rauschenden Balken von schlechterer Qualität in der Bildmitte, als das 4x3 Vollbild?
    3) Wieso sollte der DV-Encoder bei fester Datenmenge pro Makroblock in der Bildmitte bei meinen Testbeispielen
    eine andere Quantisierung wählen, wenn doch der Bildinhalt in der Bildmitte bitidentisch ist?!?

    Wenn es keine dynamische Verteilung der Datenmenge über die fünf geshuffelten Makroblocks gäbe, sollte es keinen Unterschied geben.
    Es gibt aber einen, also ist auch die Datenmenge pro Makroblock variabel.

  • Check It Out
    Liest Du eigentlich auch das, was Du anhängst (in "DV.rar", DV1.png)
    Dort ab Absatz 7.9 ist es doch genau beschrieben!!!
    Ich verstehe wirklich nicht, warum sich der Knoten in Deinen Gedankengängen nicht lösen will - das grenzt ja schon fast an "Lernresistenz"

    SixdeeBee
    In Deinen Berechnungne steckt IMHO ein Fehler - hier muss ich Check_it_Out in der folgenden Aussage zustimmen:

    ...
    Da hat 4:3-DV übrigens ein 128/117 Pixelseitenverhältnis, also ~1,094 (720 Pixel werden zu 788 Pixel entstreckt, nicht zu 768).
    Und 16:9-DV hat ~1,4587 (720 Pixel werden zu 1050 Pixel entstreckt, nicht zu 1024).
    ...



  • tach auch !

    SixdeeBee

    Da ich diese Worte benutzt habe, sei mir eine zusätzliche Bemerkug gestattet.
    Ich ging beim Ausgangspost von einer 08/15 4:3 DV CAM aus.
    Aus diesem Bild ein anamorphes 16:9 Bild zu kreiiren, nur weil 16:9 hip ist,
    halte ich für *hüstel* sagen wir unnötig kompliziert.

    Um Dein Schnittprogramm dazu zu bewegen das einheitlich zu machen ,
    halte ich es für angemessen.
    Imho haben aber 99% der User diese Problem überhaupt nicht, weil sie genau 1 Cam und das Material daraus haben.
    Anfängern diesen doch sehr komplizierten Weg zu beschreiben halte ich für wenig zielführend.

    Bei ECHTEM 16:9 kann man so vorgehen.

    Aus der PAR/DAR/% Debatte habe ich mich schon immer rausgehalten.
    ;)

    Gruss BergH

  • Ich habe jetzt einen ruhigen Augenblick gefunden, in dem ich mich in die DV-Spezifikation, insbesondere den angesprochenen zusätzlichen Punkt 7.9 etwas einlesen konnte.
    Die Blöcke, Makroblöcke und Videosegmente haben zwar eine vorgegebene Größe, deren Inhalt kann aber bei entsprechender Komplexität "überlaufen" und wird in den "unterforderten" Bereichen aufgefangen. Die reinen Daten eines Makroblocks können so zB größer als 77 Bytes sein, werden aber in 77 Byte Häppchen unterteilt.

    Für mich ist das eine neue Erkenntniss und daher möchte ich mich bei scharfis_brain und cedocida für die Geduld bedanken. "Lernresistent" will ich schon gar nicht sein. ;)

    Ich hatte mir erst letztes Jahr im Herbst in der Bibliothek der TU München sämtliche verfügbaren Spezifikationen kopiert (DV, MPEG1/2, DVD usw) und danach "überflogen".
    Dabei habe ich Punkt 7.9 bei DV - wahrscheinlich wegen des ganzseitigen Anordnungsalgorithmus :D - falsch verstanden, dahingehend, dass der nur dafür verantwortlich sei, wie die zusammengehörigen Makroblöcke in Videosegmenten ausgewählt werden.

    Soweit ich das jetzt sehe, können Blöcke, Makroblöcke und Videosegmente "überlaufen". Erst Superblöcke bilden einen einheitlichen Abschluss. Was sich wo befindet steht dabei jeweils in einem Datensynchronisationsblock.
    Vielleicht hilft das auch Anderen. :)

    Zitat von cedocida

    Genauer möchte auch ich nicht mehr werden


    Das ist eben oft das Problem, wenn man gute Informationen bekommen möchte. An einem Punkt stoppen die Quellen im Internet "zugleich". Gut, manchmal ist man selber auch betriebsblind. ;)

    Liebe Grüße

    Check It Out

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!