MPG Resizen ?

Das ist mal eine echt gute Frage !

Zitat von Shadow128

"352x288 352x576 704x576 720x576"

Das sind die zulässigen Norm-Auflösungen für eine DVD.

 528 x 576 ist eine Standard-DVB-Auflösung.

Da ich es leider auch nicht genau weiß, folgere ich einfach mal logisch, dass sich die 528 aus

352 + (1/2 * 352) = 352 + 176 = 528

ergeben. Das wäre dann quasi "Dreiviertel-D1", aber basierend auf Cropped D1, also der Reihe 704 ==> 528 ==> 352 folgend.

Zitat von Shadow128

Welche Auflösung macht bei meiner vorliegenden Auflösung mehr sinn ?
720x576 oder 352x576 ?

Ich würde folglich 704 oder 720 nehmen, da du ansonsten ein Viertel Horizontalauflösung verschenkst.

Zitat von Shadow128

Und mit welchem Programm kann man das am besten machen ?

Wenn du die Auflösung ändern willst führt kein Weg um ein Reencoding mit z.B. TMPGEnc oder CCE herum. Eigentlich sollte man ein solches File direkt in den TMPGEnc laden können (installierter MPEG-2-Filter vorausgesetzt), bei "Source Aspect Ratio" 4:3 625 line (PAL, 704x576) einstellen und als 704 x 576 encoden.

Sicherer wäre wahrscheinlich der Weg über AviSynth, mit folgenden Scripts :

Für 704 x 576 :

DirectShowSource=("C:\Video.mpg") BicubicResize(704,576)

Für 720 x 576 :

DirectShowSource=("C:\Video.mpg")
 Bicubic Resize(704,576)
 AddBorders(8,0,8,0)

Am einfachsten und schnellsten ginge es jedoch, wenn du ein Reencoding komplett umgehen würdest. Man kann sich zwar nicht sicher sein, ob das auf jedem SAP läuft und mit korrektem Aspect-Ratio angezeigt wird, aber auf den Versuch würd' ich's ankommen lassen : einfach die Quelldatei in den DVDPatcher laden und dort die "Horizontal Size" auf 704 und eventuell noch die Bitrate ändern, da DVB-MPEGS (wenn sie nicht vorher mit z.B. PVAStrumento bearbeitet wurden) immer als 15 Mbit/s-Stream ausgezeichnet sind.

Ausserdem könntest du DVDLab anstelle des TMPGEnc DVD Authors probieren; das nimmt eigentlich jede Auflösung. Es warnt zwar, dass man versucht, etwas unkonformes zu erstellen, aber normalerweise ist das Resultat trotzdem OK.

Aber wenn du es wirklich hundertprozentig DVD-konform haben willst, musst du das Quellmaterial reencoden.

ohne davon jetzt was zu verstehen, könntest Du mit dem DVDPatcher die mpgs auf ein anderes (zulässiges) Format patchen, dann authoren und die Vobs danach wieder zurückpatchen und DVD brennen.

Aber obs dann (fehlerfrei) auf dem Standalone Player läuft ? Testen würd ich sagen.

Ansonsten mal auf die DVB Profis warten oder Resizen incl. Neukodierung (Qualitätsverlust)

Zitat von BaronVlad

und die Vobs danach wieder zurückpatchen und DVD brennen.

Ich wusste ich hab' was vergessen...;)

Zitat von illCP

Ich wusste ich hab' was vergessen...;)

uups, ich hab in der Eile sogar überlesen, dass Du den DVD Patcher angesprochen hast. Schande über mich, ansonsten aber sehr schön erklärt, Christian

generell ist es bei den DVB Streams zu empfehlen, die vorher erstmal mit PVAStrumento zu demuxen. Wenn ich den kompletten Stream in den Tmpeg DVD Author lade, ist er sonst meist nicht mehr syncron.

Zitat von illCP

Das wäre dann quasi "Dreiviertel-D1"

Aber mal eine generelle Frage : wer denkt sich so'n Blödsinn eigentlich aus ? Was hab' ich eigentlich von 528 Pixeln Horizontalauflösung ? OK, ist besser als 352, aber dann könnte man sich diesen Zwischenschritt doch eigentlich komplett sparen und gleich 704/720 benutzen ?!

Oder noch schlimmer : 544 ?!? Ist mir zwar persönlich beim Streamen noch nicht untergekommen, aber laut DVDPatcher gibt's das ja als Standard-DVB-Auflösung...

Und vor allem : wie komm' ich auf 544 ? Das ist zwar Mod16, aber sonst...?! Oder sollte das etwa "Full Dreiviertel-D1" sein, und 528 ist "Cropped Dreiviertel-D1" ? Scheint mir fast so...

Zitat von Shadow128

1. Die Aufnahme ist nicht nur für mich, sondern auch mehrere Bekannte, und ich weiß nicht wie die anderen Player auf die DVD dann reagieren würden... Und hinterher dann nochmal dran rumpfuschen muss ja nicht sein...

Ja, das ist auch immer meine Befürchtung. Eine Möglichkeit wäre es natürlich, z.B. mit DVDlab Pro Beta 4 eine Multi-VTS-DVD zu erstellen mit allen DVB-Auflösungen und verschiedenen Streams und das ganze dann mal überall zu testen. Das Problem wäre nur, das man sich das Quellmaterial erstmal zusammencapturen müsste und man sich dann vermutlich immer noch nicht hundertprozentig sicher sein kann, das alle anderen Streams in Zukunft auch korrekt laufen werden.

Übrigens hoffe ich, dass du mit "für mehrere Bekannte" meinst, dass du die DVD bei mehreren Bekannten auf deren SAP's anschauen möchtest; ansonsten könnten wir hier nämlich mit den Foren-Regeln bezüglich Urheberrechts-Fragen in Konflikt kommen...

Zitat von Shadow128

2. Ich wollte eigentlich schon TMPGEnc DVD Author nehmen, weil ich mit dem halt relativ einfach meine DVD-Menüs erstellen kann (auch mit bewegten Kapitelbildern, usw...)

DVDLab ist auch ziemlich einfach zu bedienen, und vor allem wesentlich umfangreicher in den Funktionen. An deiner Stelle würd' ich's mal ausprobieren.

Zitat von Shadow128

3. Wenn ich die Methode mit dem DVDPatcher machen würde, erstellt mir TMPGEnc DVD Author in dem gepatchten Video immer hässliche grüne Streifen am Rand. Das wollt ich eigentlich auch vermeiden.

Genau sowas kann ohne Reencoding passieren...

Zitat von Shadow128

Jetzt würd ich nur gern wissen, womit es besser wäre zu reencoden ?

Ich persönlich würde den TMPGEnc nehmen, in den ich das Quellfile mit AviSynth-Script importieren würde.

Zu den DVB- und generell MPEG2-Auflösungen:

Es gibt zwei Gruppen:

Die 704-Gruppe
352x576 (DVD, CVD)
528x576 (DVB)
704x576 (DVD, DVB)

720-Gruppe
480x576 (DVB, SVCD)
544x576 (DVB)
720x576 (DVD, DVB)

Alles klar?

Zitat von Kika

Alles klar?

Jein...

Die 704er Gruppe ist soweit klar.

Aber wieso 480 in der 720er-Gruppe ? Das wären dann ja 464 plus 16 Pixel ?

Wie es in der Auflistung aussieht 352 plus 128... ?!

Stimmt das überhaupt, was ich vorher sagte, dass 544 16 Pixel schwarzen Rand hat, also quasi "Full-Dreiviertel-D1" ist ?

Zitat

Aber wieso 480 in der 720er-Gruppe ? Das wären dann ja 464 plus 16 Pixel ?

Nein, das wären 704x576 plus 16 Extra-Pixel resized zu 480x576.
Das sind ja alles Teilauflösungen der Ausgangsauflösung.

720x576 hat diese 16 Extra-Pixel, 544x576 hat dann, das es eine 3/4-D1-Auflösung von 720x576 ist, logischerweise 3/4 von 16 Extra-Pixeln, also 12.

Zitat von Kika

logischerweise 3/4 von 16 Extra-Pixeln, also 12.

Und wo kommen die fehlenden vier von 528 auf 544 her ?

Wenn du einen Stream mit 720 hast "könntest" du diesen direkt auf 480 und 544 horizontal resizen. Die Aspect Ratio würde stimmen, nebenbei werden sowieso all diese in mit ihrer PAR die 768x576 TV pixels überschreiten. Da TV aber "nur" 768 hat wird der Überschuss nicht dargestellt, SELBST wenn dein TV keine OverscanArea hätte.

Bei 704 kann man direkt auf 528, 464(MOD16) und 352 resizen, da alle auf dem TV zu 768 gestreckt (square pixels) mit einer "fast" richtigen AR erscheinen.

Es lässt sich alles von der SourcePAR und den SourceActiveTvPixels ableiten:

Beispiele für Height = 576

Width:
720 = SourcePAR = (128/117) und SourceActiveTvPixels = 702
704 = SourcePAR = (128/117) und SourceActiveTvPixels = 702
544 = SourcePAR = (512/351) und SourceActiveTvPixels = 526.5
528 = SourcePAR = (512/351) und SourceActiveTvPixels = 526.5
480 = SourcePAR = (128/78) und SourceActiveTvPixels = 468
352 = SourcePAR = (256/117) und SourceActiveTvPixels = 351

Wie du siehst haben 720 und 704 die gleichen SourceActiveTvPixels, demnach sind bei der SourceWidth z.B. DVD 720 NUR die 702 für den TV relevant. Diese 702 werden dann auf TV Par 1:1 gebracht und zwar durch Multiplizieren mit der Source PAR!

Beispiel: 720 = SourcePAR = (128/117) und SourceActiveTvPixels = 702

Rechnung, was am Tv dargestellt werden kann:
SourceWidth * SourcePAR = 720 * (128/117) = 787,69

787,69 kann vom TV NICHT komplett dargestellt werden, da nur 768px (digital gesehen) zur Verfügung stehen, selbst wenn dein TV keinen Overscan (TV Safe Area) hätte, wäre die Differenz zu 768 nicht zu sehen.
Demnach 787,69 - 768 = 19,69 Px .... diese sind quasi "Überschuss" und können vorab von der Source gecroppt werden. Und wie geht das?
19,69 / SourcePar(128/117) = 15,255 und diese bringen wir auf Mod2 = 16
Nun nehmen wir die SourceWidth(720) - 16 = 704! Und DIESE 704 von deiner Source werden NUR benötigt um am TV korrekt wiedergegeben zu werden.
Daher croppt FitCD von DVD720 Source lediglich auf DVD704 Target ... und "resized" NICHT!

Bzgl. 544 und 528.

Beide besitzen eine ActiveTvPixArea von "nur" 526.5 und haben eine PAR von 512/351.
Und da eben "nur" 526.5 bei beibehalten der richtigen AR auf 768 TVpx direkt skaliert werden können, machen 544 als DVB Sources eigentlich keinen Sinn (wenn ich das richtig verstehe), da eben 528 (MOD16) für active 526,5 Pixel vollig ausreichen, und da ja für TV gesendet wird, sind eben die activen Source Pixels relevant.

Probiers aus:
544 (Source) * 512/351 (SourcePar) = 793,52 !
793,52-768 = 25,52 ... also 25,52 px Überschuss, was TV angeht.
Nun be-croppen wir die 544 vorab um das zu kompensieren:
25,527 / (512/351) = 17,499955782 ..... Mod2 = 18
544-18 = 526 .... = eben "fast" jene oben beschriebene active Pix area.
Wenn wir nun "genau" wären, würden wir also die 544 auf 526 croppen und auf 528 wiederum skalieren. Fänd ich aber IRRSINN, da für lediglich zwei Pixel skalieren das Bild Aufgrund von Interpolation leidet.
Demnach besser 544 Source auf 528 croppen und encodieren, fertig. Resultat wären eine um 2px falsche AR ... und damit kann man leben.

Hier ein "sehr guter" Link:
http://www.uwasa.fi/~f76998/video/…onversion_table
(Immer wieder gerne als Referenz in solchen Threads genommen, .... quasi eine Resizing-Bibel)

Wenn ich FitCD betrachte, kommt am Ende das "selbe" raus. Zumal FitCD mit den selben PARs zu arbeiten scheint.

Zitat

Und wo kommen die fehlenden vier von 528 auf 544 her ?

Häh?

Oder auf Deutsch: Wie meinen?

544x576 verhält sich zu 528x576 exakt wie 720x576 zu 704x576.

Daher hatte ich das doch auch in die 720er und die 704er Gruppe unterteilt.

Bei einem korrekten 544x576er Video hat man zwei Möglichkeiten:
Croppen auf 528x576, resizen auf 704x576
Nicht croppen, direkt resizen auf 720x576

Zitat von Kika

720x576 hat diese 16 Extra-Pixel, 544x576 hat dann, das es eine 3/4-D1-Auflösung von 720x576 ist, logischerweise 3/4 von 16 Extra-Pixeln, also 12.

Oder sind es dann nur 12 + 4 Pixel wegen Mod 16 ? Weil von 528 bis 544 sind's 16 Pixel und nicht 12.

Rechne es doch einfach nach:

528/3*4=704 <- Stimmt also
aber:
544/3*4=725.333 <- Stimmt also nicht.
Korrekt wäre 540x576 gewesen. Das ist aber nicht durch 16 teilbar, also nahm man die nächste, passende Auflösung, und das ist nun mal 544x576. Daher auch die Rechenungenauigkeit. Eigentlich müsste man also bei der 544er Auflösung erst noch auf 540 croppen und dann resizen auf 720. Aber die 4 Pixel stören genausowenig wie die 2 überflüssigen bei 704 (PAL hat ja eigentlich nur 702 aktive Pixel horizontal).

@ illCP

Sehe die kalkulation oben, dort kannst du genau sehen warum und wieviel ge-croppt wird.
Kika hats mit "Gruppen" beschrieben, aber vorsicht, denn 544, 720 und 480 sind nicht im Endeffect gleich breit, wenn sie auf PAR 1:1 gebracht werden. Daher auch das vorab croppen von 544 auf 540 um auf die 720 "der gleichen Gruppe" zu kommen - wenn mans genau nimmt.

Bei der Kalkulation ist es eigentlich so, dass die Source erst auf PAR 1:1 entzerrt wird. Die Differenz (fürs Croppen) wird erreicht, wenn man von dieser entzeerten Source die ebenfalls entzerrte Target Size abzieht. Dann hast du den exakten wert fürs croppen bei PAR 1:1 ! Nun ist deine Source im Zusatand von 544 NICHT PAR 1:1 und somit musst du eben jene obige Differenz (fürs Croppen) ebenfalls wieder via Source PAR zurückstauchen. = Cropping Value welche auf die Source angewendet wird. Aber da wir mit Mod2 croppen sollten (interlaced sources sogar in der Höhe mit crop4 damit "even" crop values rauskommen, also "gerade" crop/height werte) ... kommen manchmal minimal falsche ARs raus. Und das ist nicht weiter tragisch, wie es auch Kika beschrieben hatte.