Beiträge von rodgar

    Also bislang gabs damit nie Probleme.
    Alle meine Videos liegen als MKV auf Platte und sind von den Datenraten genau so angepasst, daß sie nach dem umwandeln in AVCHD-Struktur entweder auf DVD9 oder DVD5 passen. Will dann mal wer ein Video auf Scheibe haben, ziehe ich das MKV entweder in multiAVCHD oder tsmuxer, wandle es um und brenne das Ergebnis. Klappte nach einigem Hin und her wegen der maximal erlaubten Bitrate von 15mbyte/s, Fake-Interlace bei progressivem Material, korrekter SAR und noch einigem anderen dann irgendwann immer tadellos...

    Aber wie es aussieht wird mein Ansinnen schon durch eine andere Sache durchkreuzt: Die IDR-Frames sind nur bei knapp 20% der Videos genau dort, wo es mit dem Schnitt gut hinhaut, bei allen anderen kann ich das komplett vergessen. Und da der Ansatz von "Lupurus"für mich überhaupt nicht funktioniert, bleibt wohl nur neu aufnehmen und encoden :(
    Kann man wohl nix machen.

    Trozdem, wie immer Danke für die Unterstützung!

    Zitat

    Wenn Du die Zeit kennst an der Du schneiden willst und IDR genau reicht, dann kannst Du auch einfach mkvmerge verwenden,.. (Global->Aufteilen->Aufteilen aktivieren->...)


    Nachdem das weder mit mencoder noch mit ffmpeg geklappt hat (Bei ffmpeg hat mkvmerge den Track nicht mehr als unterstütztes Videoformat erkannt) habe ich das mal direkt über mkvmerge probiert - wie du gesagt hast. Klappt bestens, auch wennn es doch etwas aufwendig ist :)

    Denn einfach die neue Titeleinblendung als MKV mit dem durch Global->Aufteilen nun 2ten Teil des Videos (ebenfalls MKV) zusammenzufügen scheint nicht zu gehen (MKVmerge merkt an, daß die Tracks nicht das gleiche Format besäßen). Video und Audio demuxt, audio(neu+alt) und video(neu+alt) separat per append verbunden, dann zu einem MKV gemuxt - Geht!

    Das Endvideo scheint augenscheinlich in Ordnung zu sein. Gibt es da auch eine Methode wie ich das auf etwaige Fehler testen kann, oder kann ich beruhigt sein, wenns sauber und synchron abgespielt wird. Nicht, daß dann irgendwann das böse Erwachen kommt, wenn ich das in ein paar Monaten über AVCHD bei Bekannten abspiele... Wäre unschön.

    Tom Keller
    Habe ich schon befürchtet, daß das zu naiv gedacht war. Aber ich glaube mit der Methode über split und append von mkvmerge haut das jetzt auch so hin... Danke für den Link mit der Erklärung zu IDR.

    Vielen Dank für die aktive Hilfe :)

    Code
    hört sich sehr nach kaputten Headern im RawStream an,..
    Womit hast Du den den demuxed?


    Ebenfalls mit einem GUI und zwar dem für MKVExtract. Der RawSTream direkt wieder mit MKVMerge gemuxt funktioniert allerdings einwandfrei...

    Schande über mein Haupt, ich muss gestehen, daß ich keine Ahnung davon habe, was ein IDR-Frame ist. Bei I, P und B hörts dann auch schon auf.
    Ideal wäre es natürlich, wenn es Framegenau ginge. Zur Not geht es aber auch, wenn 1-2 Sekunden Versatz besteht.

    Erläuterung:
    -------------
    In erster Linie geht es darum den Anfang von rund 30 Videos zu ersetzen. Das sind 150 Frames weiß auf Schwarz Titeleinblendungen nebst crossfade ins Video. Diese sind aufgrund von Beschriftungen von 1989 entstanden. Und jetzt habe ich bemerkt, daß diese aber manchmal offensichtlich falsch ist.
    Beispiel: April 1989 kann nicht stimmen, wenn auf dem VHS-Band mitten drin irgendwo eine Szene vom Vatertag existiert, der am 04.05.1989 war. Das ergibt sich leider nur aus dem Kontext... ja, und so muss ich nun irgendwie alle Titeleinblendungen der Videos nach diesem Tag gegen neue tauschen. Und ich höre Ligh schon sagen: "Nimms neu auf, geht schneller, ist sicherer!" :)

    Ich werde das mit ffmpeg am Montag mal testen (Danke für die Line, Selur!) ... Hab übers WE leider keinen Zugang zu den Videos.

    Das mit open-Gop klingt einleuchtend... VIeleicht ist das ja auch der Grund, wieso AVIDemux damit Probleme hat.

    Edit
    -------
    Ich habe mir gerade noch was überlegt: Wie gesagt, es geht hier um Titeleinblendungen am Anfang diverser Videos. Diese müssen ersetzt werden. Weder die Länge und Art der Einblendung noch die Länge des gesamten Videos wird dabei aber tatsächlich verändert.
    Prinzipiell müsste also garnichts geschnitten sondern nur der VideoAnfang "überschrieben" werden. Ist so etwas möglich? Also wie eine Art Ebene, die man über den Anfang des Videos legt. Oder ist das zu naiv gedacht und womöglich noch viel schwerer zu realisieren als es einfach irgendwie zu schneiden und den Anfang zu ersetzen?

    Ja, ich hätte sie auch lieber vorher geschnitten... nur sind mir leider erst im Nachhinein ein paar unschöne Dinge aufgefallen. Wäre halt nett, wenn man die noch irgendwie rausbekommt.

    Nach Selurs Zeile dachte ich zunächst es läge irgendwie am MKV womit ich Mencoder füttere, aber auch die Variante es über Raw-Video (MKV demuxt) zu versuchen - wie Selur - klappt nicht. Dort meckert Mencoder nun selber über "Invalid Seek to negative position" und das fertige h264 ist nur 724Byte groß.

    Selur
    1. Ja, 100% identisch
    2. Raw probiert, geht auch nicht... das mit ffmpeg werde ich mal versuchen (hoffentlich krieg ich das hin)
    3. Also ich muxe immer über das GUI. Im Fall von RAW achte ich halt auf die korrekten FPS und Seitenverhältnis.
    4. Ja, wenn ich denn das nächste finden könnte... Eigentlich sollte ja bei einem GOP von 25 alle 25 Bilder ein I-Frame sein, oder? Er meckert aber bei allen. 120-170 hab ich schon durch.

    Könnte das evtl. an der Mencoder-Version liegen?
    Ich nutze eine aus dem Tool: multiAVCHD. Würde in dem Zusammenhang gerne wissen, wo man eine neue Variante bekommt. In den Binaries von http://mplayerhq.hu/design7/dload.html ist die irgendwie nicht dabei.

    Schade das hieraus anscheinend nichts weiter hervorgegangen ist:
    http://forum.gleitz.info/archive/index.php/t-41408.html

    Ich würde gerne hier und da einige meiner Videos beschneiden oder miteinander verbinden, aber ohne diese komplett neu zu kodieren. Damit keine Unklarheiten aufkommen hier die Info wie die Dateien aussehen:

    Code
    GeneralUnique ID                        : 189390199236492262374150506017076190598 (0x8E7B39C027AD9FB4B4BB9960443A9D86)Complete name                    : O:\test.mkvFormat                           : MatroskaFile size                        : 293 MiBDuration                         : 13mn 42sOverall bit rate                 : 2 991 KbpsEncoded date                     : UTC 2011-07-02 18:00:53Writing application              : mkvmerge v4.8.0 ('I Got The...') gebaut am May 24 2011 03:12:58Writing library                  : libebml v1.2.0 + libmatroska v1.1.0VideoID                               : 1Format                           : AVCFormat/Info                      : Advanced Video CodecFormat profile                   : High@L4.1Format settings, CABAC           : YesFormat settings, ReFrames        : 5 framesCodec ID                         : V_MPEG4/ISO/AVCDuration                         : 13mn 42sBit rate mode                    : VariableBit rate                         : 2 800 KbpsMaximum bit rate                 : 15.0 MbpsWidth                            : 720 pixelsHeight                           : 576 pixelsDisplay aspect ratio             : 4:3Original display aspect ratio    : 4:3Frame rate                       : 25.000 fpsStandard                         : PALColor space                      : YUVChroma subsampling               : 4:2:0Bit depth                        : 8 bitsScan type                        : MBAFFBits/(Pixel*Frame)               : 0.270Stream size                      : 269 MiB (92%)Title                            : x264 2800kbps 576iWriting library                  : x264 core 115 r1995 c1e60b9Encoding settings                : cabac=1 / ref=6 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=bff / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=0 / keyint=25 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=25 / rc=2pass / mbtree=1 / bitrate=2800 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=15000 / vbv_bufsize=15000 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00Language                         : GermanColor primaries                  : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAMTransfer characteristics         : BT.470-6 System B, BT.470-6 System GMatrix coefficients              : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM, IEC 61966-2-4 601AudioID                               : 2Format                           : AC-3Format/Info                      : Audio Coding 3Mode extension                   : CM (complete main)Codec ID                         : A_AC3Duration                         : 13mn 42sBit rate mode                    : ConstantBit rate                         : 192 KbpsChannel(s)                       : 1 channelChannel positions                : Front: CSampling rate                    : 48.0 KHzBit depth                        : 16 bitsCompression mode                 : LossyStream size                      : 18.8 MiB (6%)Title                            : 1.0 AC3 192kbpsLanguage                         : German


    Ich habe versucht mich dem Thema über mencoder zu nähern, allerdings ohne Erfolg:

    Code
    mencoder test.mkv -o test.h264 -ovc copy -nosound -ss 00:00:10.00


    Müsste ja eigentlich eine copy des Videotracks ab dem nächsten I-Frame nach der 10ten Sekunde abliefern. Wenn ich nun dieses video aber mit mkv-merge muxe macht die Wiedergabe fast überall probleme (außer bei Mplayer - aber selbst da gibts am Anfang Bildfehler oder es wird zu schnell abgespielt. Ausserdem stimmt der Zeitindex nicht).

    Ich bin nicht festgelegt auf mencoder. AVIDemux habe ich auch schon probiert, aber wieder aufgegeben, weil es anscheinend nicht in der Lage ist die I-Frames in meinem Video zu finden - Daher kommt es bei MKV-Ausgabe immer wieder zur Fehlermeldung: The beginning frame is not a keyframe. Please move the A-Marker.
    Wähle ich dort als Output AVI gehts, aber das Ergebnis ist augenscheinlich das Gleiche wie mit Mencoder. Das Video läßt sich nirgends korrekt abspielen.

    Zitat

    Du prüfst also, ob das von x264 erzeugte AVC-Video (in MKV) BFF ist, indem du es mit DirectShowSource öffnest und in AviSynth die Info()-Funktion benutzt?
    Schlechte Idee.


    Merke ich auch gerade... Nutze ich LAV CUID passiert da sogar was recht seltsames, Top und Bottom-Field sind identisch und nur um eine Zeile nach unten verschoben.

    Super, sowohl der MPC-interne Decoder dekodiert es korrekt, ffdshow ebenfalls und auch der LAV CUID tut es (welcher ja sogar die fieldorder manuell einstellen läßt - ich glaub den nutze ich ab jetzt)
    Also ist CoreAVC doch das Problem... Da kauft man sich den extra weil man liest der sei der schnellste und beste und dann sowas... nur wieso erkennt der das nicht? Die TFF Videos aus meinem Camcorder spielt er ja korrekt ab.

    Bei dem ganzen Hin- und Hergeteste hab ich die Option des LAV CUID nun so geändert, daß er h264 nicht abspielen soll. Eine Ahnung wie ich nun ausserhalb von MPC an die Konfiguration rankomme um das wieder zu ändern?

    Zitat

    Es ist möglich, dass bereits beim Capturen des VHS irgendwie eine YUY2/YV12-Verwirrung stattgefunden hat. Kann ich aus der Ferne und nachträglich auch nicht nachvollziehen.


    Das ist dann definitiv so. Bin mir aber nicht sicher, wie ich das ändern soll. Der Pinnacle Dazzle liefert laut eigener Aussage YUY2. Wenn der dvCodec nun das als YV12 speichert, erklärt sich der Umstand von selbst...

    Edit:
    ------
    Ich hab mal zum Testen Cedocida und Lagarith als Aufnahmecodec gewält und dann dieses AVS mit den aufgesplitteten Luminanz und Chrominanz-Feldern angewendet. Beim Cedocida ist zwar pro Luminanz auch ein Chrominanz-Bild, aber dafür flackert die Chrominanz hell/dunkel in jedem zweiten Bild. Beim Lagarith sieht das fast genauso aus wie beim Cedocida: U und Y flackern. Wahrscheinlich liefert ffdshow dv deswegen auch das augenscheinlich schönste Bild. Sonst hätte ich am liebsten Lagarith genommen. Nervt nur, wenn dann vor allem bei ausgebrannten Bereichen ein wildes Flackern losgeht.

    LigH
    Danke für den Tipp... Ich hatte mal irgendwann AvsP hier rumschwirren. Wusste garnicht, daß es davon einen Nachfolger gibt :)

    Didée
    Dennoch vielen Dank, daß du dir dennoch die Zeit nimmst es im Ansatz zu erklären.

    Da bin ich sprachlos. Wieso ruckelt es dann bei mir? Ich nutze MPC-HC mit Haali und CoreAVC. Hier die Einstellungen von CoreAVC:
    [Blockierte Grafik: http://www.bilder-hochladen.net/files/clh5-6q-0116.jpg]

    Ich weiß nicht obs was zu bedeuten hat, aber auch avisynth zeigt das MKV (Über DirectShowSource) als BFF an. Also wenn ich es mit info() und separatefields() in VD öffne ist Frame0 das Bottom Field.

    Zitat

    Bin zwar der Meinung dass es einfacher ist, erst die richtige Fieldorder zu setzen und hinterher die richtigen Befehle zu verwenden, aber naja, jeder wie er will.


    Also assumetff(), dann tdeint order=-1 und dann 4,0,3 - Nur zur Absicherung, ob ich das auch richtig verstanden hab. mediainfo zeigt mir bei "Encoding Settings" interlaced=tff, ist das das besagte "Flag" was immer wieder erwähnt wird?

    Zitat

    Bleibt noch die Sache mit dem Croppen. Wie gesagt, durch den 10-er Crop vom oberen Rand werden bei YV12(i) effektiv die top/bottom Felder der Farbebenen miteinander vertauscht.


    Und wie verhindert man sowas? Wieso darf man nicht mit 10 croppen? Vor allem: Wieso ist das nur bei yv12 so? Und hat das nicht grundsätzlich bei mir keine Bedeutung wo die Aufnahme doch immer YUY2 ist? Oder anders: Wenn ich CoverttoYV12 erst nach dem croppen mache, dann gibts damit doch keine Probleme, oder doch?

    Was das croppen allgemein angeht bin ich mir da eh nie so sicher inwiefern ich damit was falsch mache (Vor oder nach dem Deinterlacen?) oder sich zum Schluss dadurch die Ratio ungünstig verändert. Bislang hab ich immer versucht Horizontal-Crop/5*4 zu rechnen um auf den vertikalcropp zu kommen oder andersherum - Geht natürlich nicht immer glatt. Aber wahrscheinlich ist das in euren Augen wieder Stümperei und es gibt da viel elegantere Methoden - Würde ich gerne kennen.

    Zitat

    (Vrmtl. sind beim Capturing die Chroma top/bottom-Felder miteinander verblendet worden?) Und wegen dieses Defekts hat dieser zerstörerische Crop-Befehl in Deinem Fall keine dramatische Wirkung gezeigt.


    Wie finde ich das denn heraus ob diese Verblendung der Chroma-Ebenen stattfindet, bzw. wie verhindere ich das?

    Entschuldigt wenn da so viele Fragen kommen. Bin an dem Thema sehr interessiert, da staut sich so einiges auf :)

    Aus dem Grund auch noch eine letzte:
    Wenn ich ein YV12 Video über Avisynth im MPC abspielen möchte bekomme ich immer diese Fehlermeldung:
    [Blockierte Grafik: http://www.bilder-hochladen.net/files/clh5-6r-539f.jpg
    Deswegen füge ich recht oft ganz unten ein Converttoyuy2() ein nur ums zum laufen zu bekommen... was ja offensichtlich garnicht so folgenlos bleibt wie ich immer dachte - und welches nebenbei dann dummerweise manchmal stehen bleibt (Wie beim ersten Script). Ich frage mich nur, wieso dieser AVI Decompressor YV12 nicht erkennt bzw. wie ich es ohne diesen Schritt zum Laufen bekomme.

    LigH
    Leuchtet ein. Und es tut mir leid, wenn ich da nicht die nötige Genauigkeit an den Tag lege - Wird aber sicher noch häufiger passieren - Nur zur Warnung :) Ist halt für den Laien oft recht schwer bei diesem komplexen Thema den Überblick zu behalten - Da fällt man aus Unwissenheit oder Frust schnell mal ein falsches Urteil und merkt es nichtmal. Wenn ich mich daran erinnere wie naiv ich vor ein paar Wochen an diese VHS-Aufnahmen ran gegangen bin... Hätte nie gedacht, daß da so vieles dahinter steckt und bin froh das es Leute wie euch gibt, die einem bei den haarigen Dingen weiterhelfen.

    Didée
    Ach eine Sache noch: In deinem überarbeiten Script meckert er was davon, daß "ss_x" mehr als einmal definiert wurde. Ich denke das zweite davon muss dann "ss_y" sein, ist das korrekt?
    Und noch eine evtl. in deinen Augen Dumme Frage: Was macht "Bob(0,0.5)" eigentlich genau? Ist bob() nicht annähernd das Selbe? Ich verstehe diese float b und c Sache von Bicubic Resize irgendwie nicht.
    Nochmal danke für deine ausführlichen Erläuterungen.

    Erstmal Danke für die zahlreichen Antworten... auch wenn ich finde, daß einige etwas zu scharf daher kommen.
    Nicht jeder kann das so perfekt können wie manch einer hier, also ein bißchen mehr Nachsicht bitte :D

    Selur
    Sorry, hab das falsch verstanden. Hier nochmal das Original (Wie gesagt, TFF in dv):
    http://www.multiupload.com/LHHU8E23QQ

    Didée

    Zitat

    Das Avi wird in der falschen Feldreihenfolge dekodiert, tdeint macht daraus ein vorwärts-rückwärts-Ruckel-Bobbing


    Auch wenn ich deine Meinung wirklich sehr schätze und deine Posts immer ein Fundus für mich neuen Wissens sind. In dem Punkt liegst du falsch. Um das mit Sicherheit sagen zu können brauchst du nämlich das Quellvideo, und das hab ich grad erst gepostet. tdeint(order=1) macht daraus ein hübsch flüssiges video weil die Quelle eben tatsächlich TFF ist.

    Danke für die Korrekturmaßnahmen. Hoffe nur, daß das mit dem Upsampling nicht zu langsam wird. Der kriecht ja momentan schon immer nur mit 1,8FPS daher. Deswegen war ich auch schon froh über dicke Ränder zum wegschneiden. Die bringen dann gut 0,2FPS mehr.

    Was mir nicht ganz einleuchtet: Du sagst "4,0,3 ist immer richtig, wenn die Fieldorder korrekt gesetzt ist". Aber wenn ich das oben gepostete Quellvideo (TFF) mit tdeint order=1 und 4,0,3 durchlaufen lasse, ist es zum Schluss BFF - also Fieldorder vertauscht. Oder verstehe ich da etwas völlig falsch?
    Ist es nicht so, daß wenn ich genau das Selbe Video mit 4,1,2 durchlaufen lasse, zum Schluss ein TFF-Video erhalte? Oder anders: Das Quellvideo ist TFF, muss also mit Order=1 geöffnet werden. Wenn ich die Fieldorder nicht vertauschen will, dann MUSS ich doch 4,1,2 nutzen... oder nicht? Also zummindest sieht das Video dann genauso aus wie vorher (Es ruckelt).

    In dem Zusammenhang interessiert mich natürlich auch, was denn nun vorzuziehen wäre wenn ich daraus AVCHD machen will? Ist das völlig egal ob TFF oder BFF oder gibts da irgendwelche Empfehlungen oder sogar Vorgaben?

    LigH
    Das ist aber auch schwierig... Ich behaupte doch nichts "steif und fest". Dafür weiß ich von der Materie viel zu wenig. Ich merke nur, daß mein Video ruckelt und das das irgendwas mit TFF und BFF zu tun hat. Meine Canon HF 100 Videos sind allesamt TFF und werden mit CoreAVC blendend abgespielt. Die mit x264 kodierten ruckeln danach, selbst wenn ich am Video überhaupt nichts ändere, sondern es mit der Option TFF einfach nur neu kodieren lasse. Also denke ich als Amateur "x264 macht irgendwas beim kodieren mit tff falsch!". Wie soll ich es denn prüfen? Es ruckelt nunmal und Avisynth sagt "BFF" wenn ich das Ergebnis einfach nur mit Separatefields() öffne. Da muss ich doch davon ausgehen, daß es nicht TFF gespeichert wurde. Wenn nicht, wieso wird es dann als BFF abgespielt? Ich hab es schonmal gesagt: Mag sein, daß x264 alles korrekt kodiert, aber dennoch wird es bei mir ruckelig abgespielt.

    @all
    Ruckelt das MKV (also das erste Video) bei euch nicht?

    Gerne :)
    http://www.multiupload.com/OFC6SCSQZ5
    Das ist jetzt durch dieses Script gelaufen...

    Code
    Import(".\Scripte\LimitedSharpenFaster.avs")Import(".\Scripte\TemporalDegrain.avs")AVISource("original - tff dv.avi")crop(18,10,-18,-18)TDeint(mode=1, order=1, AP=25) TemporalDegrain(gpu=true) converttoyuy2()LanczosResize(720,576)separateFields().SelectEvery(4,1,2) LimitedSharpenFaster(strength=120)weave()


    ...und danach durch megui x264 mit diesen Kommandos:

    Code
    program --level 4.1 --bluray-compat --preset slow --pass 2 --bitrate 2800 --stats ".stats" --keyint 25 --open-gop --slices 4 --vbv-bufsize 15000 --vbv-maxrate 15000 --tff --colorprim bt470bg --transfer bt470bg --colormatrix bt470bg --sar 12:11 --output "output" "input"

    Das Quell-Video ist eindeutig TFF. Ganz einfach mit assumetff() und separatefields() geöffnet - Sieht man sofort obs stimmt oder nicht.
    Dennoch wird es aber immer als BFF abgespielt - Bei dv kann ich das ja verstehen, aber nicht bei x264 zumal ich dort ja tff angebe. Meinetwegen kodiert x264 das Video vieleicht korrekt, nur was bringt mir das, wenn es von keinem Player, den ich nutze korrekt erkannt wird?
    Weder CoreAVC in MPC HC noch VLC zeigt das Video als das an was es ist, sondern spielen es als BFF - Und auch ein Umwandeln via tsmuxer in AVCHD nebst abspielen auf einem Samsung und einem LG Player zeigt wieder nur BFF. Auch Avisynth geht ohne assumetff() erstmal immer davon aus, daß es BFF ist.

    Vieleicht ist meine Frage falsch gestellt und sie müsste lauten: Wie spiele ich TFF korrekt ab!? Nur ergibt diese Frage für mich keinen Sinn, denn TFF-Videos aus meiner Canon HF 100 werden ohne Probleme mit CoreAVC, VLC und auf allen StandalonePlayern die ich im näheren Umfeld habe korrekt abgespielt. Erst wenn ich diese mit x264 wieder neu kodiere ruckelt wieder alles. Also kann es am Decoder nicht liegen.

    Zitat

    Was ich nicht so recht verstehe, ist die Diskussion um TFF/BFF.


    Ich glaube da hab ich was nicht mitbekommen. Eine Diskussion um das Thema TFF/BFF kenne ich nicht. Ich möchte nur, daß x264 TFF kodiert, wenn ich ihm das sage, mehr nicht.

    Zitat

    Vielleicht wäre ein AssumeTFF() nach AviSource() sicherer als TDeint(order=1), denn das könnte vielleicht bedeuten: Weil AviSynth keine anders lautenden Informationen von AviSource() bekommt, vermutet es BFF für den Clip, du zwingst TDeint per Parameter trotzdem zur TFF-Arbeitsweise, aber am Ende fügt Weave() immer noch unter der Annahme, der Clip sei BFF, die Halbbilder vom Reinterlacing in BFF-Reihenfolge zusammen.


    Allerdings sagt mir info() direkt vor weave() eindeutig, daß Avisynth verstanden hat, daß es sich um TFF handelt - sofern ich anstelle von selectevery(4,0,3) eben selectevery(4,1,2) nutze.

    Am Ende funktioniert es aber wie gesagt dennoch nicht - auch mit der Variante assumetff() unterzubringen. Das von x264 kodierte Video ist immer BFF. Ganz egal ob ich ihm TFF, BFF, mit oder ohne assumetff(), mit oder ohne Bluray-compat oder sonstwas gebe - Immer BFF.

    Zitat

    Immerhin sind das so viele, dass man das nachschlagen können sollte, ohne langwierig in einem Forum danach zu suchen... siehe: Encoding Video for Blu-Ray using H264/AVC - Kapitel 2.1.

    Danke für den Link, kannte ich noch nicht - Bringt mich aber leider auch nicht weiter.

    Edit:
    ------
    Kann es vielleicht daran liegen, daß mein Video im dv-codec vorliegt? Ich weiß, daß dv immer BFF ist, evtl. "sieht" x264 dies und macht deswegen automatisch BFF, egal was man ihm sagt!? ...
    ... Mit Lagarith anstelle von ffdshow dv aufgenommen - Getestet - Gleiches Ergebnis

    Zitat

    Warum Extra-Parameter für bereits im Dialog unterstützte Parameter einfügen? Musst nur genau lesen, wie sich welche vorhandene Option auf die Parameterliste auswirkt.

    Das ist mir bewusst. Nur was soll man machen, wenn besagte Optionen eben nicht in der Kommandozeile auftauchen? Das mit dem wegreduzieren bei Standardwerten ist mir ebenfalls bewusst, aber nal-hrd vbr, aud und pic-struct sind eben Standardmäßig nicht aktiv. Von daher müssten sie auftauchen. Und da sie das über die Optionen nicht tun und auch über das manuelle hinzufügen nicht tun habe ich eben genau dies gepostet...

    Und das Ergebnis ist davon ja völllig unberührt. Es ist immer BFF, egal welche Option ich wähle oder welche Custom Command Line ich einfüge.

    Irgendwie hängt es momentan mal wieder.

    Ich capture grade altes VHS-Material und bin dabei auch schon ein gutes Stück weit gekommen. So weit, daß ich nun Zeit gefunden habe mich einem Problem vom Anfang zu widmen, was mich irgendwie nicht ruhig schlafen läßt.

    Mein aufgenommenes Video ist TFF. Aber ich bekomme x264 in Megui einfach nicht dazu überredet eben in TFF zu kodieren. Bislang habe ich einfach die Fieldorder mit tdeint() und zuvor mit reversefielddominance() in Avisynth geändert und eben in BFF kodiert. Aber 1. weiß ich nicht inwiefern das wieder gegen irgendwelche Konventionen von AVCHD oder Bluray verstößt und 2. würde ich mir auf Dauer diesen Schritt gerne ersparen, zumal ich so auch anderes Material wie z.b. vom HD-Camcorder in BFF umwandeln müsste, was ja nicht Sinn und Zweck sein kann.

    Daher die Frage: Wie zwinge ich x264 dazu TFF zu kodieren?
    (Oder am Rande: Soll ich doch lieber auf 25p Deinterlacen?)

    Ich habe gelesen, daß --nal-hrd --pic-struct und --aud hierfür aktiv sein müssen. Seltsamerweise hat megui diese zwar als Optionen, aber sie werden nicht in der Command-Line angezeigt - Ein oder aus, es ändert sich nichts. Ein hinzufügen als Custom-Command-Line klappt ebenfalls nicht.

    Hier noch mein aktuelles AVS

    Und der relevante Megui Reiter (Wie man sehen kann wird unten nix von pic-struct, nal-hrd oder aud angezeigt):
    [Blockierte Grafik: http://www.bilder-hochladen.net/files/big/clh5-6p-577e.jpg]

    Zitat

    Nun ja, das heißt aber: Wenn SegmentedAviSource funktioniert, dann kann bereits AviSource("02.avi") nicht funktioniert haben. Glaube ich ...

    Das könnte wohl stimmen... Alles was ich mit AVISource geladen habe konnte zwar teilweise (mehr oder weniger Dateien gleichzeitig) in VD geöffnet werden, aber sobald es ans rendern ging, ist er irgendwann abgestürzt, mal früher mal später. DirectShowSource klappte hingegen in jeder Kombination.

    So ganz verstehe ich das aber nicht. Heißt das, daß nur das erste AVI einen "Header" oder sowas wie "Metadaten" (oder wie auch immer man das nennt) hat und alle
    folgenden nicht?
    Wenn ja, wieso kann man diese dann dennoch problemlos einzeln mit und ohne AVISource mit und ohne Script in VD öffnen und auch abspielen, nur eben nicht über AVISource neu encoden?

    Hab das mit SegmentedAVISource() mal ausprobiert... Ist ja schon eine feine Sache, vor allem weil man halt die ganzen Segmente nicht mehr auflisten muss, sondern eben nur den Hauptnamen und gut ist.
    Scheint bislang auch gut durchzulaufen, aber das Encoden geht mit 13fps dann doch 2 Frames langsamer als DirectShowSource. Dafür öffnet sich das Script in VD schneller und man kann wesentlich schneller darin "rumsuchen".

    Zitat


    AviSource("01.avi", "02.avi", "03.avi", ..., "22.avi") # nur ein Quellfilter, der mehrere Dateien öffnet

    und

    AviSource("01.avi") # mehrere Quell-Clips, die zusammengefügt werden
    \ ++ AviSource("02.avi")
    \ ++ AviSource("03.avi")
    ...
    \ ++ AviSource("22.avi")

    Ist bei mir leider kein Unterschied festzustellen. Beides stürzt ab :(

    Ich muss am Montag mal schaun ob auch einzelne Dateien während dem encoden abstürzen. Momentan bin ich ja schon froh, wenn sich das Script überhaupt korrekt in VD öffnen läßt. Durchlaufen tut bislang aber keins was mit AVISource Dateien öffnet.

    Die Nachteile von DirectShowSource klingen bedenklich. Hoffe ich bekomme die Alternative irgendwie hin.

    Das mit SegmentedAVISource könnte evtl. funktionieren. Immerhin ist es genau das, denn es wurde von VHS über VD als Segmented AVI gecaptured. Vielleicht klappt das ja.

    Die Grenzen des Machbaren... das beschreibt es sehr schön. Es ist nämlich egal wie ich es drehe und Wende. Selbst wenn das Script zummindest akzeptiert wird. Encode ich nun diese 6 Dateien stürzt VD ab. Und zwar bei allen meinen Videos. Manchmal habe ich Glück und ein einzelnes geht durch, aber meistens kommt es nichtmal 5000Frames weit.

    Aber seltsamerweise genau in dem Module, was du erwähnst. In Modul ffmpeg.

    Da ich jetzt auch nicht mehr weiterwusste bin ich wieder zurück zu DirectShowSource. Damit gehts zummindest.

    Aber das was du über ffmpegsource gesagt hast werde ich weiter verfolgen... Irgendwie muss es ja gehen :)
    Auf der anderen Seite: So schlimm finde ich das mit DirectShowSource nun auch wieder nicht oder gibts da irgendwelche gravierenden Nachteile von denen ich noch nichts gemerkt hab?

    Ich frage mich nur, wie ihr das alle macht. Ich bin doch nicht der einzige, der 50GB in Einzeldateien über Avisynth auf VirtualDub wirft und erwartet, daß etwas schönes hinten rauskommt, oder doch?
    Wenn ich da so manches Monster-Script sehe, dem ich intellektuell schon kaum mehr folgen kann, dann kann ich mir das irgendwie erst recht nicht vorstellen.

    Wenn ich das nur wüsste.
    Ich halte nichts von Codec-Packs, daher gehe ich immer sehr spartanisch vor und installiere lediglich ffdshow und CoreAVC. Nun musste ich aber noch Lagarith haben und habe zwischenzeitlich Cedocida - DV Codec installiert... Bis auf Lagarith hab ich dann einfach alles deinstalliert, den CCleaner und VIDC-Cleaner laufen lassen. Danach nur ffdshow und avisynth neu installiert und es ging...

    ABER jetzt wirds seltsam:
    Es geht zwar, aber nicht wenn ich viele Dateien gleichzeitig lade. Es handelt sich hierbei um ein Urlaubsvideo, das 3:15 stunden lang ist und aus 23 Einzelvideos besteht. Die Länge oder die Größe der Videos ist bei diesem Problem entscheidend.

    AVISource("video.avi") -> geht

    AVISource("video01.avi", "video02.avi"..... "video22.avi") -> geht nicht

    Und es wird seltsamerweise mit exakt der gleichen Fehlermeldung quittiert wie wenn der Codec nicht gefunden würde. Deshalb die Verwirrung. Ich denke letztlich hat weder CCleaner noch VIDC-Cleaner geholfen, sondern einfach, daß ich mein Script runtergeschrumpft habe auf eine einzige Zeile.

    Nun bleibt für mich natürlich die Frage, wieso das so ist.

    Ähnliches habe ich bereits in Verbindung mit SetMTMode(2) in Verbindung mit DirectShowSource() festgestellt. Exakt das Selbe Video wie oben läßt sich nicht encoden, wenn ich den Mode während dem Laden der Dateien auf 2 lasse.

    SetMTMode(2)
    DirectShowSource("video.avi")
    ...
    geht

    SetMTMode(5)
    DirectShowSource("video01.avi", "video02.avi"..... "video22.avi")
    SetMTMode(2)
    ...
    geht auch

    aber
    SetMTMode(2)
    DirectShowSource("video01.avi", "video02.avi"..... "video22.avi")
    ...
    geht nicht

    VirtualDub stürzt dann beim Encoden nach 10-20 Frames ab.

    Ich denke das sind Artverwandte Probleme, nur was steckt dahinter?

    ##############################################
    Nachtrag:
    Ich hab mal sukzessive nacheinander immer mehr Videos auskommentiert. Ergebnis: Nur die ersten 6 können hintereinander geladen werden (80867 Frames bzw. 53:55min) ohne das VD meckert es kenne den Codec nicht - Diese Videos sind im Format 720x576 ffdshow dv, jeweils 1,85GB groß und 8:59min lang. Alle weiteren können wieder ohne Probleme zusammen in einem geladen werden. Bei einem anderen Urlaubsvideo mit nur 2:15min Länge verteilt auf 16Dateien geht es problemlos.

    Sehr seltsame Angelegenheit.

    Zitat

    Vielleicht ist in der Registry die VIDC-Liste irgendwie defekt. Koepi hatte mal ein Tool geschrieben, welches leere Einträge löschen soll, weil alle nachfolgenden nicht mehr behandelt werden.

    http://forum.gleitz.info/showthread....aner-von-Koepi

    Halleluja... :cool: und ich war schon kurz davor mein System neu aufzusetzen. Vielen Dank für den Link zu diesem wunderbaren kleinen Tool!
    Jetzt geht alles einwandfrei, Lagarith, Huffyuv und dv. Nebeneffekt: Endlich ist auch die Ladeverzögerung beim öffnen des AVS in VD weg.

    Bin mir aber nicht ganz sicher ob VIDC-Cleaner oder einfach CCleaner die Arbeit erledigt hat. Habe beides direkt hintereinander ausgeführt und danach ffdshow und avisynth komplett neu installiert. Nur falls mal jemand das Selbe Problem haben sollte.