Adobe Premiere schlechte Qualli beim exportieren

Hallo
ich habe ein Problem mit Adobe Premiere, ich habe es mir letztens gekauft und gleich ausprobiert, erst war alles prima doch als ich es auf CD gebrannt habe hat der Film plötzlich geruckt, bei kameraschwenks ist es besonders aufgefallen, als würden Bilder fehlen oder so. ich habe es auch probiert in avi oder andere Formate umzuwandel, die Qualität leidet trotzdem so stark darunter, in der Rohdatei ist allerdings alles noch schön und gleichmäßig ohne ruckeln oder so. weis jemand woran das liegt (ich benutze Adobe Premiere Elements 9 auf Windows Vista 64bit)
vielen Dank in vorraus
Merlin

hallo,
wenn du den film auf CD gebrannt hast, ist es kein wunder dass er ruckelt. brenn ihn mal auf DVD! außerdem kannst du im brennmenü einstellen ob besste qualität oder an speicherplatz anpassen. du musst mal ein wenig in den ERWEITERTEN einstellungen im brennmenü experimentieren: beim rendern sollte die 2-PASS methode eingestellt sein, als codec H264 oder MPEG-2.
viel erfolg -luedre

Was D.W. da schreibt ist unsinn. Die Zeilenreihenfolge ist bei SVCD und DVD gleich, der Effekt müßte bei bei SVCD und DVD auftreten. Und wenn es eine VCD ist kommt er gar nicht zum tragen. Selbst wenn es ein XVid oder was weiß ich ist hat der Datenträger erstmal keine Bedeutung.

Erklärung:
Viele Videoquellen der analogen Ära liefern keine Vollbilder, also bei 25FPS 25 ganze Bilder sondern versetzt 50x die geraden und 50x die ungeraden Zeilen. Das nennt man dann nicht p(progressiv) sonder i(interlaced). Die Röhren hatten damit gar kein Problem weil die Röhre an sich ganz gering nachleuchtet und somit aus den Zeilen ein ganzes Bild wird. 50i ist zwar nicht so scharf wie 25p hat aber in sehr schnellen Szenen ein flüssigeres Bild.

Stellt man diese Fieldorder (die aussagt ob zuerst die geraden oder zuerst die geraden zeilen dargestellt werden) falsch ein kommt es bei gerade vertikelen Bewegungen im Bild zu grausamen Effekten.
Es kann aber bei dir auch sein das die Bildwiederholrate gar nicht passt! Also du hast zum codieren 25FPS für PAL gewählt aber das Video hat z.B. 33FPS.

Um dir da jetzt helfen zu können müßte ich wissen woher das Video stammt! Ich kann dir versichern das es normalerweise keine sichtbaren Verschlechterungen gibt.

Am besten lädst du dir die Freeware MediaInfo und öffnest damit das Video und postest mal das Ergebniss.

hallo

Viele Videoquellen der analogen Ära liefern keine Vollbilder,
also bei 25FPS 25 ganze Bilder sondern versetzt 50x die
geraden und 50x die ungeraden Zeilen.

das hat aber im grunde nix mit „analog“ zu tun.
fernsehen und video (ob pal, ntsc oder secam) war nun mal immer schon interlaced (ich rede nicht von unkonvertiertem progressiven material).
ob analog oder digital - scheissegal.

Die Röhren hatten damit
gar kein Problem weil die Röhre an sich ganz gering
nachleuchtet und somit aus den Zeilen ein ganzes Bild wird.

ist es nicht gar so dass interlaced eben wegen der röhren so eingeführt wurde ??
die röhre hat ja nicht nur kein problem damit sondern die röhre ist ja schlicht so aufgebaut . . .

Stellt man diese Fieldorder (die aussagt ob zuerst die geraden
oder zuerst die geraden zeilen dargestellt werden) falsch ein
kommt es bei gerade vertikelen Bewegungen im Bild zu grausamen
Effekten.

aber NUR auf der röhre, nicht am pc.

grüße

Nee… wenn die Fieldorder nicht passt stellt das auch der PC falsch dar. Man sieht dann bei Schwenks die zeitliche Differenz zwischen den Zeilen.

Natürlich gibt es I nicht nur im analogen Zeitalter.

Aber wo gibt es denn noch I? Bei den öffentlich rechtlichen Sendern die mit HDTV arbeiten. Toll… die spucken teilweise 1440x1080i aus. Warum nicht gleich 720p bei 50Hz…!?

Der DVD Player gibt PAL 756Zeilen 50i aus, weil er es nicht anders kann… da ist die Logik auch ganz toll: Der Film wird in P aufgezeichnet, wird in P auf die DVD gepresst. Der DA Wandler gibt I aus und die Flach-TV`s müssen per Elektronik aus dem I wieder P machen. OK, der DVD war vorher da, dewegen „aus der analogen Zeit“ (was mit sicherheit nicht ganz korrekt ist).

hallo

Nee… wenn die Fieldorder nicht passt stellt das auch der PC
falsch dar. Man sieht dann bei Schwenks die zeitliche
Differenz zwischen den Zeilen.

hmm, hatte ich aber schon oft anders - interlaced-material sieht am pc halt immer irgendwie krumm aus, aber wenn der pc aus zwei halbbildern wieder eines darstellt ists ja egal ob deren reihenfolge mal falsch war - ob field 1 und field 2 zusammengerechnet werden oder field 2 und field 1 . . . dem progressiven bild ist das doch eigentlich wurscht . . .

Aber wo gibt es denn noch I? Bei den öffentlich rechtlichen
Sendern die mit HDTV arbeiten.

oh, viele öffentlich-rechtlichen senden (und produzieren) immer noch in 576i - aber eben in digitalen formaten.

Der DVD Player gibt PAL 756Zeilen 50i aus, weil er es nicht
anders kann…

liegt das nicht am player ?? es gibt doch nun schon länger progressive-fähige player . . . irgendwie hatte das über component zwar noch ein paar jahre gedauert bis das konsortium sich für den kopierschutz entschieden hat, aber das ist schon lange durch . . .

grüße

Wenn die Fieldorder falsch ist, ist doch zyklisch die zeitliche Differenz zwischen den Zeilen größen. Das sieht man sofort, auch am PC.

Jeder DVD kann P, ist ja auch auf 99,8% aller Kauf-DVD`s.
Aber analoges Signal wie CompositeVideo, SVideo und Scart RGB kann es nicht. Über analog Komponente bin ich mir jetzt nicht sicher. Über HDMI wird es wohl gehen…

Wenn die Fieldorder falsch ist, ist doch zyklisch die
zeitliche Differenz zwischen den Zeilen größen. Das sieht man
sofort, auch am PC.

aber die „zeitliche differenz“ ist bei einem progressiven bild wieder irrelevant - beide „zyklen“ sind doch wieder zusammengefügt.
das zusammengefügte bild zeigt beide zyklen gleichzeitig - dabei ist es meines erachtens egal ob die fieldorder vertauscht ist da im progressiven bild dann nur oben und unten vertauscht ist - nicht „vorher“ und nachher".
(davon dass ein progressiv zusammengesetzes ursprünglich interlaced-bild immer scheisse aussieht reden wir jetzzt ja nicht)

Jeder DVD kann P, ist ja auch auf 99,8% aller Kauf-DVD`s.
Aber analoges Signal wie CompositeVideo, SVideo und Scart RGB
kann es nicht. Über analog Komponente bin ich mir jetzt nicht
sicher. Über HDMI wird es wohl gehen…

komponente ist das einzige analoge signal was progressive kann.
ist ja auch nicht weiter schlimm - meines erachtens hängt es sowieso am endgerät, also an dessen fähigkeit progressive darzustellen und weniger am dvd player.

wer einen tft oder plasma oder was-weiss-ich mit composit oder svideo bedient hats sowieso entweder nicht verstanden oder wurde (wahrscheinlich in den meisten fällen) falsch bzw gar nicht beraten.
macht ja nix.
war ja billig.
wir sind ja geizig.
da ist ein gutes bild doch irrelevant.
hauptsache das ding ist schön flach.
*kopfschüttel*

grüße

Fieldorder: Ja, aber der deinterlacder der Software muss wissen welche Zeilen zueinander passen… denken wir mal wie haben Einzelbilder die aus zwei Frames bestehen. 1a & 1b ergeben jeweils ein Bild.

Dem Softwarerender muß nun mitgeteilt werden ob Das Bild zeitlich mit a oder b anfangt.

Sagen wir mal 1a (ungerade Zeilen, analog TV) wäre korrekt, aber das Bit im Header des Videos ist falsch. Dann würde der Render mit b anfangen und a dazurechnen, a ist aber zeitlich um ein paar Millisekunden vor b und der zeiltiche Ablauf passt nicht mehr.

Passiert im Bild nicht viel, ist der unterschied in der Zeitlinie nicht sichtbar… bei schnellen Bewegungen sieht es aber aus als würde der Film ganz schnell vor und zurückspringen.

OK?

Fieldorder: Ja, aber der deinterlacder der Software muss
wissen welche Zeilen zueinander passen… denken wir mal wie
haben Einzelbilder die aus zwei Frames bestehen. 1a & 1b
ergeben jeweils ein Bild.

ja

Dem Softwarerender muß nun mitgeteilt werden ob Das Bild
zeitlich mit a oder b anfangt.

theoretisch ja

Sagen wir mal 1a (ungerade Zeilen, analog TV) wäre korrekt,
aber das Bit im Header des Videos ist falsch. Dann würde der
Render mit b anfangen und a dazurechnen, a ist aber zeitlich
um ein paar Millisekunden vor b und der zeiltiche Ablauf passt
nicht mehr.

der „ablauf“ existiert aber NUR in der interlace-darstellung!
im neu erstellten progressiven bild werden beide fields (a und b) ja nicht mehr nacheinander sondern ZEITGLEICH dargestellt.
ok ?

Passiert im Bild nicht viel, ist der unterschied in der
Zeitlinie nicht sichtbar… bei schnellen Bewegungen sieht es
aber aus als würde der Film ganz schnell vor und
zurückspringen.

meines erachtens redest du hier aber immer noch von einer darstellung die interlaced ist und eben beide felder NACHEINANDER darstellt.

Hier würde die darstellung etwa so aussehen:

erst:
Field A, Zeile 1
Field A, Zeile 3
Field A, Zeile 5
usw

dann:
Field B, Zeile 2
Field B, Zeile 4
Field B, Zeile 6
usw

das ist interlaced - hier ist es extrem wichtig dass erst field A und dann field B dargestellt wird.
bin da völlig auf deiner seite.

aber - progressive wird es doch korrekterweise so dargestellt:

gleichzeitig:
Field A, Zeile 1
Field B, Zeile 2
Field A, Zeile 3
Field B, Zeile 4
Field A, Zeile 5
Field B, Zeile 4
usw

korrekt ?

und ich behaupte jetzt, vom zeitlichen problem, bei dem ansonsten ein ruckeln entsteht ist es bei progressiver darstellung EGAL ob die anordnung so aussähe:

Field B, statt Zeile 2 jetzt als Zeile 1
Field A, statt Zeile 1 jetzt als Zeile 2
Field B, statt Zeile 4 jetzt als Zeile 3
Field A, statt Zeile 3 jetzt als Zeile 4
Field B, statt Zeile 6 jetzt als Zeile 5
Field A, statt Zeile 5 jetzt als Zeile 6

der kammeffekt bleibt (fast) gleich, ein zeitliches aufeinanderfolgen ist AUFGEHOBEN . . . und somit irrelevant . .

(das wird erst wieder relevant wenn das progressive bild wieder interlaced werden soll und wieder interlaced dargestellt wird, aber das ist ja hier nicht der punkt, wir haben es doch NUR vom abbilden eines interlaced quellmaterial IN progressiver darstellung)

jetzt zumindest klarer was ich meine ?

:wink:

grüße

hallo noch mal,
ich denke die diskussion hier geht wohl etwas am thema vorbei: merli sein problem dürfte nicht die zeilenreihenfolge sein. ich denke eher an eine zu geringe bitbreite (bedingt durch die automatische umrechnung des filmes auf cd größe). eine weitere möglichkeit wäre eine zu hohe brenngeschwindigkeit so dass die fehlerkorrektur nicht mehr hinterher kommt.
leider meldet sich merlin nicht mehr zu wort.
gruß luedre

bevor das Bild P auf dem Bild dargestellt werden kann müssen doch erst die I Frames miteinander verrechnet werden! Nimmt man die zeitlich falschen zusammen kommt es zu den schon genanntem Fehler.

Die aufeinanderfolgenden Framefolge wäre dann nicht:
1a -> 1b -> 2a -> 2b -> 3a -> 3b (korrekt)
sondern
1b -> 1a -> 2b -> 2a -> 3b -> 3a (falsch)

Wenn du jetzt mal schaust, liegt bei „korrekt“ zwischen 2b und 3a 20ms… wenn man es falsch macht werden Bilder zusammengerechnet die, (wieder 2b und 3a) 80ms, also um den 4x Zeitversatz, verrechnet!

Man rechnet falsche Bildinformationen zusammen bevor diese als Vollbild dargestellt werden.

Wenn du ein Motionblur von 200ms drauf legst wird das verwischen… aber dann wird das Bild halt schlechter (weicher), das ist auch der Fall wenn man aus I einfach P macht!

http://de.wikipedia.org/wiki/Zeilensprungverfahren

andre, wir waren schon mal an einem solchen komplizierten punkt, ich glaube du übersiehst etwas, aber mir fehlen langsam die worte.

bevor das Bild P auf dem Bild dargestellt werden kann müssen
doch erst die I Frames miteinander verrechnet werden!

ja, klaro

Nimmt
man die zeitlich falschen zusammen kommt es zu den schon
genanntem Fehler.

aus I P zu machen ist IMMER ein problem, aber nur bezüglich des „kammeffekts“.
kein bild wird quasi „zu früh“ dargestellt werden.

Die aufeinanderfolgenden Framefolge wäre dann nicht:
1a -> 1b -> 2a -> 2b -> 3a -> 3b (korrekt)

nein
bei P werden ZWEI ursprüngliche halbbilder GLEICHZEITIG dargestellt (entschuldige, das gross schreiben soll kein „schreien“ sein)
also:
1a und 1b gleichzeitig
dann (40ms später)
2a und 2b gleichzeitig
usw

sondern
1b -> 1a -> 2b -> 2a -> 3b -> 3a (falsch)

wieder nein
sondern
1b und 1a gleichzeitig
dann (40ms später)
2b und 2a gleichzeitig
usw

Wenn du jetzt mal schaust, liegt bei „korrekt“ zwischen 2b und
3a 20ms…

nein, jedes frame 40ms bei progressive
bei interlaced sind es 20
erstes vollbild - beinhaltet 1a UND 1b
40ms später
zweites vollbild - beinhaltet 2a UND 2b

DARIN sind halt eben zwei bilder die einen zeitversatz von 20ms hatten - jetzt werden sie zeitgleich dargestellt.
das FALSCHE ist nur das das obere unten sein sollte, der zeitversatz von dem du sprichst ist AUFGEHOBEN weil zwei aufeinanderfolgende (halb)bilder die mal einen 20ms versatz hatten nun gleichzeitig dargestellt werden.

wenn man es falsch macht werden Bilder
zusammengerechnet die, (wieder 2b und 3a)

? 2 und 3 gehören nicht zusammen

80ms, also um den 4x
Zeitversatz, verrechnet!

die falsche fieldorder wird (wenn sie nur einmal falsch gemacht wird) niemals ein 2tes bild mit einem dritten verrechnen.

ach . . .

schönes wochenende
:wink:

Hallo noch mal
also erst mal sorry das ich noch nicht geantwortet hab, ich hatte leider bis jetzt noch keine Möglichkeit dazu.
also am brenner kann es ja eigendlich nicht liegen da das Problem ja auch besteht wenn ich das Video nur in einem anderen Format wie z.B. avi speichere. Ich habe mir mal Mediainfo runtergeladen, also hier mal von dem schon konvertierten Film wo die Streifen drinsind:

Format : AVI
Format/Info : Audio Video Interleave
Format_Commercial_IfAny : DVCPRO
Dateigröße : 52,0 MiB
Dauer : 14s 381ms
Gesamte Bitrate : 30,3 Mbps

Video
ID : 0
Format : DV
Format_Commercial_IfAny : DVCPRO
Codec-ID : dvsd
Codec-ID/Hinweis : Sony
Dauer : 14s 381ms
Bitraten-Modus : konstant
Bitrate : 24,4 Mbps
Breite : 720 Pixel
Höhe : 480 Pixel
Bildseitenverhältnis : 4:3
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 29,970 FPS
Standard : NTSC
ColorSpace : YUV
ChromaSubsampling : 4:1:1
BitDepth/String : 8 bits
Scantyp : Interlaced
Bits/(Pixel*Frame) : 2.357
Stream-Größe : 49,3 MiB (95%)

Audio
ID : 1
Format : PCM
Format-Einstellungen für Endiane : Little
Format-Einstellungen für Sign : Signed
Codec-ID : 1
Codec-ID/Hinweis : Microsoft
Dauer : 14s 381ms
Bitraten-Modus : konstant
Bitrate : 1 536 Kbps
Kanäle : 2 Kanäle
Samplingrate : 48,0 KHz
BitDepth/String : 16 bits
Stream-Größe : 2,63 MiB (5%)
Interleave, Dauer : 899 ms (26,94 Video-Frames)
Interleave, Vorlaufsdauer : 967 ms

und hier von der originaldatei:

Format : MPEG-PS
Dateigröße : 6,23 MiB
Dauer : 7s 744ms
Gesamte Bitrate : 6 753 Kbps

Video
ID : 224 (0xE0)
Format : MPEG Video
Format-Version : Version 2
Format-Profil : Main@Main
Format-Einstellungen für BVOP : Ja
Format-Einstellungen für Matrix : üblich
Dauer : 7s 600ms
Bitraten-Modus : variabel
Bitrate : 6 363 Kbps
nominale Bitrate : 9 600 Kbps
Breite : 720 Pixel
Höhe : 576 Pixel
Bildseitenverhältnis : 16:9
Bildwiederholungsrate : 25,000 FPS
Standard : PAL
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : Interlaced
Scanreihenfolge : oberes Feld zuerst
Bits/(Pixel*Frame) : 0.614
Stream-Größe : 5,76 MiB (92%)

Audio
ID : 128 (0x80)
Format : AC-3
Format/Info : Audio Coding 3
Format_Settings_ModeExtension : CM (complete main)
Dauer : 7s 744ms
Bitraten-Modus : konstant
Bitrate : 256 Kbps
Kanäle : 2 Kanäle
Kanal-Positionen : Front: L R
Samplingrate : 48,0 KHz
BitDepth/String : 16 bits
Video Verzögerung : -80ms
Stream-Größe : 242 KiB (4%)

Ich hoffe das hilft weiter und nochmal vielen Dank für die vielen Antworten

Merlin

Du hast recht!

Wenn ich aus 50i 25p mache ist es unerheblich… da die Verrechnung immer des Einzelbildes passiert.

Anders sieht es aus wenn man aus 25i 50p macht, dann muss die Fieldorder passen.

Du hast recht!

*plumps-steinvomherzenfall*

Wenn ich aus 50i 25p mache ist es unerheblich… da die
Verrechnung immer des Einzelbildes passiert.

Anders sieht es aus wenn man aus 25i 50p macht, dann muss die
Fieldorder passen.

dann unbedingt.
oder aus 50i erst 25p und dann später wieder 50i
oder
oder

grüße

hallo

Ich hoffe das hilft weiter und nochmal vielen Dank für die
vielen Antworten

mal eben schnell drübergeschaut wandelst du PAL (720x576 bei 25fps) in NTSC (720x480 bei 29,97fps um)
das ist schon mal ein fehler.
ausserdem (aber da fehlt mir die echte versuchsreihe) ist deine kompression eine 4:2:0 aus der du dann eine 4:1:1 machst.
das halte ich auch nicht für optimal, wenn auch machbar.
aber ändere erst mal die ausgabe in PAL und schau es dir noch mal an.

echte PAL zu NTSC normwandlung ist eine wissenschaft für sich die ich keinem billig-programm zutraue.
bei schlechten normwandlungen PAL zu NTSC oder andersherum entstehen gerne ruckler, womöglich ist es dass was du meintest.

viel glück
grüße

ich habs mal auf PAL umgestellt aber es war leider immernoch so :frowning:
aber danke ich lass es trotzdem jetzt immer lieber auf Pal
merlin