Einige Fragen zur 352x576 Auflösung

[valoron]

Hallo zusammen,
da ich heute endlich meinen NEC bekommen habe fange ich nun an mit der DVD-Erstellung zu experimentieren: Es haben sich nun einige Fragen ergeben mit denen ich mich im Vorfeld schon auseinandergesetzt habe aber bisher nichts passendes fand:

1. Was für Bitraten haben sich so bei der 352er Auflösung etabliert.
Bei einigermassen guten Input-Streams habe ich bisher bei der SVCD Averagebitraten zwischen 1900 und 2440 benutzt. Da die 352x576er Auflösung von der Bildgrösse zwischen der VCD und der SVCD hängt, müsste doch eine etwas niedrigere Bitrate möglich sein.
2. Das Croppen und Resizen: Bisher habe ich bei der SVCD brav rechts und links Ränder von jeweils 16 abgeschnitten, ist das bei der 352er und der 704er Auflösung auch nötig? Die 576 habe ich demnach nach der Formel Input/4 x 3 gerechnet, natürlich nur bei 16/9 auf 4/3. Gilt diese Faustformel weiterhin?
3. Wenn ich nacher fertige .m2v und .mp2 vorliegen habe soll ich sie muxen oder erledigt dass dann das Authoringprogramm ( Habe Filmbrennerei ersteigert ist aber noch nicht da)

Nun ja, würde mich freuen wenn jemand ein paar Tips zu den Fragen hätte!! Und frohe Ostern!

[bergH]

tach auch !

1.) Bitraten etwa linear zur Pixelzahl
352*288 =11**
352*576 = ?
480*576 = 1100-3500 (O.K. das ist ein Witz)
704*576 =
720*576 =
Hängt unheimlich vom Material ab, interlaced , oder nicht ruhig, Action usw.

2.) Nimm FitCD was Du da machst kann bei einem , oder zwei Spezialfällen passen, passt aber mit Sicherheit nicht immer.
UNd richtiges Resizen ist bei 352 NOCH WICHTIGER als alles andere.[Sagt Onkel Kika]

3.) Ist je nach Authoringprogramm verschieden.
Einige nehmen beides muxen aber trotzdem neu, wenn sie MPG fertig gemuxed bekommen.
_________________
Gruß BergH

[shh]

> 1.) Bitraten etwa linear zur Pixelzahl

Muss ich korrigieren.
Wenn wegen nur einer Pixelzeile mehr eine zusätzliche (macro)block-Zeile encodet werden muss, kann das massiv an bitrate "saugen". "Etwa linear" kann das also nicht sein, weil man ja dauern einen sprunghaftebn Anstieg bei einem zusätzl. slice hat.

Man sollte die bitrate lieber bzgl der encodeten blocks (8x8)betrachten. (Macroblocks (16x16) werden zum Grossteil kompensiert; sie fallen nicht so ins Gewicht)
Deswegen gibts in FitCD Anzeigen für bps/block und den Kompressionsgrad (der im Grunde das gleiche aussagt).

Mein persönlicher Geschmack:
("gutes", progressives Quellmaterial. zB DVD):
Sehr gute Quatität: Kompressionsgrad 1:36 - 1:39
Gute Qualität: 1:39 - 1:41
Passable Qualität: 1:41 - 1:43
Alles drüber sieht i.a. nicht mehr besonders aus. Da müsste man schon massiv mit Filtern und Matrizen experimentieren.

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[bergH]

tach auch !

Zustimm.
Meine Erklärung etwa linear war für Anfänger.
SHH hat natürlich recht , soooo einfach ist es nicht.
Nur was ein Macroblock ist weiß ich , aber was zum Geier ist ein Slice

Und muß ich das wisssen ?
Wo es so ein geiles Programm wie FitCD / Fit2Disc gibt !
Nööö!

   
_________________
Gruß BergH

[shh]

> Meine Erklärung etwa linear war für Anfänger.

Uups, bin ich etwa schon wieder zu pingelig?

> aber was zum Geier ist ein Slice

Eine Reihe Macroblocks.

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[[RaZoR]]

wegen diesem macroblock und fit2disc teil...
wird die qualität besser wenn ich auf block optimized stelle (bzw. macroblock)? ich hab bisher immer den regler auf "no optimization" gehabt.

[Kika]

Dabei wird das Bild verkleinert und mit schwarzen Rändern aufgefüllt. Somit muss weniger Bild encodet werden, was meistens Bitrate spart. Besonders, wenn man sehr viel Video auf eine Disk quetschen will ist das sinnvoll.

Zu den Betrachtungen der Komprimierung. Es stimmt schon, was shh schreibt, nämlich, dass letzendlich die Komprimierung der Blocks über die Qualität entscheidet. Ein "klein wenig" spielt aber auch ein anderer Mechanismus von MPEG da mit herein: die Bewegungssuche. Wer z.B. glaubt, für ein halb so großes Bild auch mit der Hälfte an Bitrate auskommen zu können, der irrt.
Der Grund ist, dass beim kleineren Bild die Informationen "gestaucht" werden. Somit gibt es insgesamt weniger Chancen, zwei Bildteile in Blockgröße zu finden, die identisch bzw. nahezu identisch sind. Dieses Aufspüren nahezu gleicher Bildteile ist aber einer der wichtigsten Mechanismen bei MPEG. Und dieser Effekt spielt auch bei Bewegungen mit - beim 352er Bild benötigt die gleiche Seitwärtsverschiebung eines Objekts weniger Pixel als beim 704er Bild, findet also auf engerem Raum statt. Die Bewegungssuche wird dadurch arg behindert, so dass die Kompensation häufiger zum Einsatz kommt.