Wieso gibt Handbrake Filme als rechteckige 720 Pixel aus?

[Praeburn]

Hallo,

vorne weg, damit ich nicht gleich was falsch verstanden habe und davon ausgehend ein Problem konstruiiere, das keines ist:
Röhren-TVs haben rechteckige Pixel, weshalb in eine Zeile 720 rechteckige Pixel passen.
LCD-Screens haben quadratische Pixel. Würde man nun hier die rechteckigen anzeigen, dann würden die rechteckigen zu quadraten gequetscht und ein Kreis würde eirig aussehen, oder?

So. Jetzt schmeiße ich in Handbrake eine DV-Datei 720 (analoges VHS) rein.
Bei den "picture presets" gibt Handbrake an:
Quelle: 720x...
Output: 704x...
Anamorph: 769x...

Wie man hier http://www.slashcam.de/artikel/Grundlagen/Pixelverhaeltnisse-und-woher-sie-kommen.html lesen kann, wurden mal, um PAL and NTSC anzupassen den ursprünglichen 702 Pixeln 18 hinzugegeben (bei NTSC welche abgezogen). Das ergibt dann den auf einem Röhren-TV nicht sichtbaren Overscan-Bereich.
Aus obigem folgere ich also. Handbrake hat den Overscan-Bereich abgeschnitten, weshalb er auf 704 kommt (alles zwischen 702 und 704 scheint ok zu sein).

Die 704 wären also immer noch die rechteckigen Pixel für den Röhren-TV. Aber wieso macht Handbrake einen "output" von 720 (repektive 704), wenn es doch auf dem LCD des Mac oder auf einem Flatscreen angeschaut werden soll???

Müsste dort bei Output nicht auch 768 stehen?

Öffne ich die Datei in Mediainfo steht dort 720x...
Mache ich die Datei auf und lege das Bild über ein Video von demich angezeigt bekomme, dass es 768x... gespeichert wurde, dann sind die beiden Filme aber deckungsgleich. Ist ja auch komisch.

So, wieso steht da jetzt noch bei Anamorph was von 768x...? Ich dachte anamorph heißt bloß, dass ein 16:9 Bild zusammengequetscht wird auf ein 4:3 Bild und man so weniger Speicherplatz bei der Satelitenübertragung (oder auf DVD) verliert. Der Player entzerrt es dann wieder.

Will mir Handbrake nun sagen, es hat die Datei mit rechteckigen Pixeln (704x...) abgespeichert und entzerrt es auf 769x...? Kann ja nicht sein, denn die rechteckigen Pixel müssen ja quadratisch werden und es müssen neue Pixel hinzugerechnet werden für den Mac/PC/Flatscreen.

FRAGE: wieso sagt Handbrake der output wäre 720 (DV-PAL "rechteckige" "analoge" Röhren-TV Pixel), wenn das Bild der fertig konvertierten Datei auf dem Mac aber scheinbar in 768 angezeigt wird, das nehme ich zumindest an von dem was ich sehe. (oder machen Quicktime und VLC das?).

 

[cifera]

Hast du in der Horizontale schwarze Pixel weggeschnitten (bekommen)? Dann würde es erklären, warum bei Output 704 steht (weil es ein Vielfaches von 16 sein muss und bei 720 - x die nächst kleinere Stufe 704 ist). Dann hat DV PAL ein Seitenverhältnis von 1150/1053 (nach ITU-R BT-601), also werden die 704 mit 1,092 multipliziert und du kommst auf die 769 Pixel auf welche die Breite gestreckt wird (real die 704 Pixel), um das richtige Seitenformat des Bildes zu erreichen.

 

[Praeburn]

Ja genau. Du meinst links und rechts, oder? Das meinte ich mit Overscan-Bereich, wobei ich das dann etwas blöd ausgedrückt habe. Also im ursprünglichen Overscan-Bereich liegen ein bisschen Farbe und ein bisschen schwarz (keine Bookends, nur minimale schwarze Streifen). Die hat er natürlich weggeschnitten, weil er gesehen hat, das dort kein Bild ist.

Was ich aber nicht verstehe ist: ich dachte, ich brauche auf dem LCD eine Zieldatei, die grob 768x... ist. 720x... bzw. 704x... scheint doch noch das zu sein, was ich bräuchte, wenn ich vorhätte auf nem Röhrenmonitor abzuspielen, oder?
Oder wird die Datei zwar als 720 bzw. 704 abgespeichert (weil es anamorph abgespeichert wurde), aber QT streckt es auf 768 bzw. 769, wenn es abgespielt wird. Ich hoffe, das macht dann auch ein Flatscreen so.
Ich hoffe auch, das rafft jede Software und es werden nachher nicht fälschlich wirklich 720/704 angezeigt, also gequetscht.

 

[pmau]

http://www.animemusicvideos.org/guides/avtech3/theory-videoaspectratios.html

Hier ist es auch nochmal erklärt.

Die "Datenpunkte" im Stream (um nicht Pixel zu sagen, können mit SAR nochmal skaliert werden und ergeben zusammen mit PAR den eigentlichen DAR Wert
Das Beispiel auf der Seite ist relativ einleuchtend, wiedergeben könnte ich es aber nicht.

Der Punkt ist das im Videostream halt keine Pixel vorliegen. Die dekodierten Daten werden ja auch noch interpoliert (scaliert).
Dadurch ergibt sich dieser komplizierte Mix aus 3 Werten.

Im Extrem kann man einen 160x160 Datenpixel-Stream so kodieren, dass der er optimal auf 16:9 ausgegeben wird aber bei 4:3 dem Letterboxing unterliegt.

 

[Praeburn]

Danke für den Link.
Der SAR-Wert steht aber ja gar nicht im Handbrake settings-window. Im Prinzip steht in dem verlinkten Text doch:
"ja, PCs brauchen 768x, aber mach dir keine Sorge, mach einfach alles in 720x. Die Software macht es dann schon richtig, während dem Abspielen auf dem PC/Mac/LCD-Flatscreen, sodass du beim Schauen kein gequetschtes Bild mehr hast."
Wieso kann ich dann aber z.B. bei iMovie und bei mpegstreamclip für h.264 zwischen 720x und 768 wählen. Wenn es eh ohne Bedeutung ist und der PC aus dem 720 immer selber das richtige während dem Abspielen errechnet.

Der Punkt ist das im Videostream halt keine Pixel vorliegen.

Ja, also muss ich das Video nicht von 720 nach 768 wandeln, sondenr ich muss in die Datei die Info reinstecken: "spiele Daten als 768 ab". Aber dann ist immer noch nicht klar, warum Handbrake einen output von 720 erzeugen will. Dann würde das nämlich heißen, dass der output keine festgelegte Darstellung hat und lediglich durch ein Flag in der Datei vorgegeben wird. Man könnte also theoretisch das Flag weglassen und Abspielgeräte/Software produzieren, die eine Wahltaste haben, mit der man wählen kann (oder besser erkennt sie sleber den angeschlosssenen Monitor und gibt trifft die Wahl), wie die Daten interpretiert/scaliert werden sollen.

Nochmal die Signalkette:
Privatvideo oder analoges Satellitensignal (anno tubak) 4:3 auf VHS ---> über A/D-Wandler in iMovie abgespeichert ---> "Auflösung" ist jetzt 7xx? (dachte 720) ---> soll nun mit Handbrake für den LCD-Monitor gewandelt werden ---> "Auflösung" wird jetzt 7xx (dachte 768) ?

Ich kapier jetzt grad gar nichts mehr. Man kann nun wirklich nicht sagen, ich hätte es nicht versucht.

 

[oneOeight]

also du solltest wohl noch mal ganz von vorne anfangen und vor allem mal die unterscheidung röhren/lcd tv und deren pixel form vergessen
danach beschäftigst du dich mal mit dem begriff anamorphe bildaufzeichung…

 

[Praeburn]

Wieso steht denn dann überall was von rechteckigen und quadratischen Pixeln und das Röhren deshalb 720x brauchen und LCDs 768???

Dass ich den Artikel anamorphe Bildaufzeichnung schon gelesen habe, geht doch aus meinem ersten Post hervor, wo ich schrieb, dass ich dachte man nimmt anamorph, um BEI DER ÜBERTRAGUNG (DVB-S/C/T) oder auf DVD, die Informationen eines 16:9 Bildes in ein 4:3 zu quetschen, so kann man den schwarzen Bereich des 4:3 Bildes bei der Übertragung ausnutzen und Platz sparen. 16:9 wird also so von links und rechts zusammengedrückt, dass es nach oben und unten "überquillt". So bekomme ich die gleiche Menge an Infos in ein 4:3 Bild, ohne dass ich Übertragungs"platz" verschwende.

Ich hab den ganzen Scheiß scon 10x gelesen. Mich darauf hinzuweisen, dass ich es nochmal lesen soll, macht doch ehrlich gesagt dann keine Sinn, oder? Außerdem geht doch aus meinen Posts hervor, dass ich mich damit beschäftigt habe.

Nochmal, wieso sagen die Onlien Tutorials, dass ich für den Laptop 768 brauche und deshalb die 720 von der VHS-Kassette umrehcnen muss? Wieso macht aber Handbrake trotzdem 720 draus? Wieso ist auf dem Laptop das 720 Bild Deckungsgleich mit einer anderen mp4-Datei, in deren Formatinfos steht, dass es sich um 768 handelt???
Die Frage hab ich oben mehrmals gestellt und die Frage ist mir immer noch nciht beantwortet worden. Sie wird es auch nicht, wenn ich noch 10x alle gängigen Texte die jeder gerne verlinkt und die ich schon selber gefunden habe, lese.

Ist wirklich nicht bös gemeint, aber wenn ich offensichtlich zu dumm bin, dann muss man es mir so erklären, dass ich als Dummer es verstehe und nicht sagen, ich soll die Texte nochmal lesen, die ich schon gelesen habe.

 

[oneOeight]

manche sachen muss man mehrmals lesen, bis man die versteht
das mit den pixel formen und deren auswirkung leitet dich doch zum seitenverhältnis.
da hast du einmal das seitenverhältnis in dem das video material gespeichert ist (die 720xY) und wie es dargestellt werden soll (768xY).
handbrake kann da auch nicht mehr daten raus zaubern. außer man skaliert das video material und rechnet es also auf das seitenverhältnis um, ist aber unnötig, weil man nur das seitenverhältnis für die darstellung in der datei speichern muss.
durch die anamorphe kodierung werden daher aus deinen 720 in der datei die korrekten 768 bei der darstellung.

bei video material von DVD/VHS bekommst es immer in 720xY, denke deine mp4, die du zum vergleich ran gezogen hast, statt das material auf einer HD quelle, die runter gerechnet wurde.

 

[Praeburn]

OK, Danke, das heißt also, es kommt auf jeden Fall richtig raus. So, wie du es jetzt nochmal zusammengefasst hast, hab ich es jetzt glaube ich auch verstanden. Ist dennoch die Frage, warum dann mpegstreamclip wissen will, ob man es nach 720 oder 768 gewandelt haben will (das Ergebnis sieht auch unterschiedlich aus). Achso, weil man bei mpegstreamclip ja nicht anamorph wählen kann.

Ich verstehe es jetzt so, das man den Begriff rechteckige Pixel nur eingeführt hat, um zu erklären, warum aus dem falschen Teiler 720:4 x 3 ≠ 567 rauskommt.
Das mit den rechteckigen Pixeln behaupten übrigens auch andere, siehe hier https://www.macuser.de/forum/thema/285320-Aufloesung-von-PAL-720x576-oder-768x576 Wichtig ist dann der Begriff "Darstellungsauflösung" (was dann wiederum die DAR aus dem anderen Link sind). Statt es 768xY abzuspeichern, kann man durch anamorph quasi der Datei sagen, dass die vorliegenden 720xY eben 768xY dargestellt werden soll, damit das Verhältnis 4:3 wieder stimmt. (Auf dem Röhren-TV ist es automatisch 4:3 weil das 720x in der Breite eben sowieso aufgrund der analogen Technik breiter als die tatsächlichen 720 dargestellt werden.

OK. Danke nochmal.