Bitrate anpassen

Die Bitrate ist ja auch das einzige, was hierbei überhaupt nicht interessiert.

Bei allem anderen kann VirtualDub jedoch etwas arg wählerisch sein. Da kann es schon einen wesentlichen Unterschied machen, ob RGB24, RGB32, YUY2 oder YV12 aus AviSynth herauskam und danach durch den Xvid-Codec komprimiert wurde. Obwohl beide Videos Xvid sind, also eigentlich zueinander kompatibel, weigert sich VirtualDub, weil es angeblich mit unterschiedlicher Bittiefe entstanden ist: Dem Hinweis "opaque" (= deckend, nicht-transparent) zufolge könnte es daran liegen, dass dein Image-Skript RGB32 ausgegeben hat, und das erzeugte AVI deshalb 32 bits pro Pixel als Farbtiefe gespeichert hat, während das andere Video wahrscheinlich aus YV12 entstanden ist und wahrscheinlich 12 bit im Header gespeichert hat. Völlig irrelevant, diese Information. Aber für VirtualDub ein Grund, sofort aufzugeben.

Vielleicht hängst du an dein Skript noch "ConvertToYV12(interlaced=false)". Aber das ist keine Garantie, dass es klappt.

über die Datenrate würde sich Virual Dub nicht beschweren,..
'.BilinearResize(720,1280)' sollte das nicht 1280,720 sein?

Zitat

Sonst schein alle gleich zu sein, außer dass eine Video mit sound ist und das andere nicht (möchte später das Gesamtergebnis besprechen) - kann es auch daran liegen?

Ja

Zitat

Also was muss ich machen damit die Videos aneinander gehängt werden können?

Detailierte MediaInfo-Analyse der beiden Videos posten.

Da du beide anscheinend im Modus "Video - Full processing" encodiert hast (anstatt "Video - Fast recompress"), haben beide "24 bit" als Farbtiefe, daran lag es also wohl nicht. Und was in dem Zusammenhang "opaque" bedeuten soll, ist mir auch nicht mehr klar, denn Transparenz ist da wohl nicht vorhanden (sonst wären es 32 bit). Um das zu klären, müsste man wohl Avery Lee (den Autor von VirtualDub) persönlich fragen.

28 fps ist übrigens etwas sehr merkwürdig, wer macht denn so was?! Aber das hat nichts mit der Ursache zu tun. Und die grauenhaften Blöcke stammen wohl aus der ursprünglichen Aufnahme, da rettet eine Recodierung mit 4 Mbps nun wirklich nichts.

Mit AviSynth würdest du wohl die Videos verbinden können, denn AviSynth decodiert immer, es müsste also am Ende sowieso neu encodiert werden. Und dabei könnte man vielleicht noch versuchen, die Verblockung etwas zu filtern (auch wenn ich da nicht gerade große Hoffnungen wecken will).

Edit: Als allererstes: SUPER löschen ! Der ist Super-Müll.

Erst mal stimme ich LigH zu. mit Avisynth das Ganze zusammenzufügen ist weit besser als das was du da vorhast.
Und genau das ist das Problem. Die Vorgehensweise.

Also bevor du irgentwas was nach Xvid konvertierst, baue doch mal ein "anständiges" avs Script zusammen.
In welchem Format ist denn das Quellvideo (vor dem umkonvertieren nach Xvid !)
Wenn ich mir die Szene anschaue die du geposted hast, vermute ich mal 'ne Handycam oder Pocket Kamera. Des weiteren vermute ich, macht diese Aufnahmen in AVC. Mit PCM Sound - mono ... (hab auch so Eine).
Wie auch immer, am Besten sowas mit FFMpegSource öffnen. Aber Achtung, der aktuelle Load schein einige Bugs bei der Decodierung zu haben. D.h. auf eine ältere Version umsteigen (r588 kann ich da empfehlen) oder DG's tools benutzen. Dann mußt du den Container (warscheinlich .mov oder .mp4) demuxen.
Gehen wir mal davon aus das FFMpegSource funktioniert:

LoadPlugin("c:\video tools\ffmpegSource-r644\ffms2\ffms2.dll")


pic=ImageSource("IMAG0136.jpg",0,29,fps=30).Spline64Resize(1280,720).ConvertToYV12()
v=FFVideoSource("myVideo.mov")


v++pic


return(last)

Die Pfade zu den Dateien mußt du natürlich anpassen.

In meinem Beispiel bin ich davon ausgegangen das das Quellvideo 30fps hat. Mediainfo kann die sagen ob das stimmt.
Des weiteren habe ich das Bild (nur) eine Sekunde stehen lassen -> wiederhole Bild "IMAG0136.jpg" 30 mal (von 0 bis 29). Wenn du es länger stehen lassen willst mußt du den Wert 2 anpassen. Die fps müssen identisch mit den fps des Quellvideos sein !
Und auch der Farbraum! Der ist bei so ziemlich allen Pocket Kameras mittlerweile YV12 wobei bei .jpg's meist RGB24 oder RGB32 verwendet wird. Deshalb das Convert auf YV12.

Mit dem "++" hängst du einfach beide Clips aneinander. Verwendest du avisynth 2.6 ist das "return(last)" wohl mittlerweile obligatorisch, sonst kann's schiefgehen.

Nix gegen Xvid, aber so ganz Zeitgemäß ist das nicht mehr. Da würde ich auf jeden Fall zu x264 raten. Vor allem bei HD Video!

Ich meinte eigentlich diese Art von Blöcken:

[Blockierte Grafik: http://frupic.frubar.net/shots/24520.png]

Das sind eindeutig "Kompressionsartefakte". Und die sind wohl schon im Original, aus dem du dieses Bild herausgeholt hast.

Zitat von Tima22

Des Weiteren war dieses video mit SUPER zu AVI reencoded

Das kann natürlich ein Grund für die Verblockungen sein, die Recodierung mit schlecht gewählten Optionen.

Wäre gut wenn man das Original mal hätte.

Der Super Encoder versaut das System würde ich nicht einsetzen.
Wenn schon das Ganze in einen AVI-Kontainer dann aber nur in einen Intermediate.

Projekteinstellung= 1440 x 1080
http://666kb.com/i/c21eqzxab1437az1c.jpg

Hm, könntest du die 13.5 MB irgentwo mal hochladen damit wir sie "auseinandernehmen" können

@Rest: Es ist mir absolut neu das AVC variable Framerate unterstützt ... ist das richtig so ?

Ach na ja – auch AVI unterstützt VFR in Grenzen: "kgV" fps und "1 Frame + x-1 D(rop)-Frames" zur Verlängerung der Anzeigedauer auf x/fps Millisekunden.

Ok, sobald ich zu Hause bin schau ich's mir an ...

So, ich hab mir's man angesehen. Was die Framerate angeht ist das echt komisch ... Je nach verwendetem Took kommt hier was anderes raus.
So wie ich das sehe macht es am meisten Sinn bei 25fps zu bleiben. Ich habe also nun folgendes Script benutzt:

LoadPlugin("C:\Program Files (x86)\Video Tools\ffms2-r644\ffms2.dll")


i=ImageSource("D:\Video\work\IMAG0135.jpg",0,124,fps=25).Spline64Resize(720,1280).ConvertToYV12()
v=FFVideoSource("VIDEO0029.3gp").AssumeFPS(25,1,true)


v++i


return(last)

Wie du siehst habe ich die fps auf 25 gesetzt. D.h. das Video wird unabhängig von der Anzahl der Frames mit konstant 25 Bildern pro Sekunde angezeigt.
(Das macht AssumeFPS(fps,FPSdenom,resampleAudio)
Nun, das ist alles kein Ding da du ja keinen Ton dabei haben willst. Denn genau das ist der "kritische Punkt" wenn man nicht die exakte Framrate weiß.
Wenn kein Ton dabei ist dann ist es egal, solange es nur flüssig läuft. Kommt jetzt der Ton hinzu - und versucht man den auch noch syncron zum Bild zu halten - wird's schwierig.
Denn der dritte Parameter sagt aus ob der Ton angepasst werden soll oder nicht. Denn wenn die original fps niedriger sind als die durch AssumeFPS festgelegten, dann wird der Ton beschleunigt -> die Frequenzen werden höher. Setzt du den parameter auf "false" wird nichts angepasst. Dann läuft aber die Bild/Ton Sync komplett auseinander.

Hier ist mein Beispiel (ohne Ton) -> http://www.mediafire.com/?tw01t4h3k2tiowt

Zitat

Wenn kein Ton dabei ist dann ist es egal, solange es nur flüssig läuft.

Hi may24
Dein Video läuft genauso wenig flüssig wie mein gestriger Test.Schau mal ins Bild wenn das Auto vorbei "zuckt"

Ich hab das Ganze mit Quicktime geöffnet und dann in Tiff Einzelframes abgespeichert.Die Einzelbilder auf die Timeline eines Videobearbeitungsprogramms gelegt [Bildfolge 1/25 Sek.]und bin dann Bildweise vorgehüpft.
Da fehlen ein paar Frames ums flüssig ablaufen zu können.

Werds aber noch probieren wenn etwas freie Zeit vorhanden ist mit anderen Tools.

Man müsste die Kamera mal per HDMI an den TV anschliessen und schauen ob dann wirklich alles flüssig abläuft.
Wär dies so dann so.....gäbe es auch die Möglichkeit den Stream per HDMI direkt ins Schnittprogramm einzulesen.
Nur so ne Idee......
----------------

Nachtrag:
Soeben mal das File in Sorenson Squeeze 7 reingelegt.
Beim Abspielen,also Einzelbildweise vorhüpfen stelle ich fehlende Frames fest,zwischen
1:13 zu 1:14
1:15 zu 1:16
1:18 zu 1:19
1:22 zu 1:22
........
am besten sieht man es bei 2:02 zu 2:03

2.Nachtrag:

Auch in MainConcept reference V.2.2.xx fehlen die gleichen Zwischenframes.

Zitat

könnte wohl daran liegen, dass die mittlere Framerate bei 28 FPS liegt, und assumed bei 25 - so fehlen einige frames ... denke ich mal

In diesem Falle nicht.Wenn ein DirectShowplayer das Video nicht mal flüssig abspielen kann,bringts mir nichts wenn ich über die Krücke" zu Einzelbild in Tiff codiere.
Es wird nur langsamer [25] oder etwas schneller [30] abgespielt.

Schau doch mal das hochgeladene Video an........das Auto macht einen Riesensatz aus dem Bildstream nach links.

Codiere doch mal Dein File mit Quicktime in Einzelbilder und lege es auf die Timeline und schaue wie das fahrende,nein falsch...hüpfende Auto für Sprünge macht.;-)

Zitat

Und ich bin mit dem Ergebnis ehrlich nicht zufrieden

Das wäre ich auch nicht.......sofort wieder umstellen

Zitat

wurde wohl anch einem systemupdate automatisch eingestellt.

An der Kamera ?

Hast beim abspielen,Kamera an den TV, eine flüssige Bildfolge.......dann kann der Film gerettet werden,ansonsten ......

Das JPG aus Beitrag 13 ist zwar ganz passabel.