Beiträge von CooCooC

    Die Quelle ist ein sehr guter DVD-Player, mit dem ich die MPEG-2-Datei vom Film, nativ (mit dem 4:2:2-BM-Codec, 165 MBit/s) per YUV gecaptured habe. Auf den originalen 35mm Film, habe ich selbstverständlich keinen Zugriff. Alleine der 35mm Filmscanner, würde ein Vermögen kosten.

    Meinst Du das lohnt sich? Die Fehler der Encodierung beim Erstellen der DVD sind ja trotzdem drin. Und x264 sollte das Rechnen in den Farbraum, mit dem es umgehen kann, doch automatisch machen; nur halt nicht mit dem ganzen Film auf einmal, sondern halt mit so vielen Frames wie es zum Encodieren braucht.

    Deine Vollbilder:

    Würdest du bitte einmal eine ca. 10 Sekunden-Sequenz von deinem Problemfilm irgendwo hochladen. Vielleicht können wir dir weiterhelfen.

    http://shareplace.org/?E31CA2F013

    Ist mit MKVToolnix ausgeschnitten aus dem MKV, das MakeMKV ohne Umcodieren von der DVD gerippt hat.

    Das MakeMKV-Tool hat wohl keine „Smart Rendering-Funktion“?

    Nope, das bringt den Film nur von Disc in einen anderen Container.

    Colorspace: YUV (BT.601) und Color range: Limited (16-235).


    Da aber YUV bis 1920 x 1080 Pixel reicht, kann der Farbraum auch BT. 709 betragen.

    Da muss ich einsteigen, wenn ich jetzt doch mit Vapoursynth-Filtern anfange; bisher kriege ich das noch nicht sortiert. Z.B. ist doch YUV nur während der Filterei/Codiererei in Benutzung danach geht es immer auf 4:2:0; oder täusche ich mich da und man kann auch mit besserem Farbraum oder 4:2:2 in MKVs abspeichern? Wie sieht's dann mit HW-Decodierern aus, schlucken die das?

    2. Hardwarebeschleunigung für den Decodierungs-Akt

    Videos sollten natürlich auch so erstellt werden, dass die Wiedergabegeräte es ohne Probleme wiedergeben können.

    Siehe meinen letzten Absatz oben bzgl. Farbräumen. Ich werde mal bei den Box-Foren anfragen, welche Einschränkungen die HW-Decodierer in den an die ARM-Chips angeflanschten Codecs hier haben.

    die Beschleunigung die du willst wird meist mit CUDA* oder OpenCL* umgesetzt.

    (*ich weiß die Angabe ist nicht 100% richtig, aber nicht alle verwenden die Namen von den Encodereinheiten)

    zu OpenCL konnte ich nichts finden, da hat noch keiner was gebaut.

    da bleibt uns nur noch CUDA/NEVNC, die nur auf nVidia-Karten laufen.

    Das ist doof, ich liebäugele mit den AMD-APUs und die haben ja AMD-Grafik drin, nicht Nvidia. Da fängt's ja mit aktuellen Karten momentan >400EUR an. Da bleibe ich wohl doch bei x265 und CPU (wie Du ja auch oben vorgeschlagen hast).

    prinzipiell würde ich erst mal sagen, generiere dir ein Testclip, mit Problem-Szenen und teste die Qualität erst mal selber.

    Testclip ist erstellt (siehe Link oben) und ich habe auf doom9 einen Thread von 2015 gefunden mit Verweis auf hier, wo ein Avisynth-Skript steht mit dem das Bild in Halbbilder zerpflückt wird und so eindeutig herauszufinden ist ob es progressiv (aabbccdd), interlaced (abcde) oder Telecine ist (LigH hat damals schon in dem doom9-Thread gepostet :-) ). Da ich eigentlich dann gleich auf Vapoursynth umsteigen wollte, versuch ich gerade mir die Toolchain dazu aufzusetzen, um die Analyse endlich vernünftig durchführen zu können. Schönes Wetter, Familie, Geburtstag, Hochzeitstag ... wird wohl nächste Woche werden. :-)

    Ich habe mir auch einen Stream von Hatari, allerdings in voller Qualität (645 GB), erstellt.

    Den Stream müsste ich nur noch für meinem USB-3-Stick zu H.264 wandeln.

    Schick mit bitte nicht den Download-Link, ich brauche meine Internetverbindung in den nächsten Wochen auch beruflich. ;-)

    Im Ernst: Was war denn da die Quelle? Hast Du Dir den 35mm-Film ausgeliehen und selber gescannt?

    Bei mir von der DVD, ist Hatari definitiv in interlaced. Hast du eventuell in progressiv gecaptured? Bei x264 vielleicht progressiv ausgewählt?

    Bei mir ist auch das Interlaced-Flag gesetzt, aber die Bilder sehen nicht interlaced aus, das ist ja das Merkwürdige. Ich habe die DVD einfach mit MakeMKV auf die Platte gerippt, was ja mit keiner Umcodierung verbunden ist, lediglich ein anderer Container wird benutzt.

    Croppen ohne Neucodierung wie geht das? Ist bisher komplett an mir vorbeigegangen, dass sowas gehen kann ...

    Bei mir auf DVD ist Hatari in Full Range (0-255). SD-Material sollte aber immer 16-235 (BT.601) betragen.

    Wie findest man das denn raus? Mediainfo spuckt zum Video nur das aus, keine Angaben zum Farbraum:

    Standard : PAL

    Color space : YUV

    Chroma subsampling : 4:2:0

    Das kann ich dir nicht sagen, ob es das auch bei analogen Farb-Signalen gab. Das könnte LigH wissen. Dafür sah man früher das Farbrauschen mehr. Zumindest bei schlechten Geräten. Color- und Luminance-Probleme, sollte man selbstverständlich korrigieren.

    Ich kann mir nicht vorstellen, dass Cross-Color oder -Luminance-Probleme entfernbar sind. PAL hat ja Farb- und Helligkeitsinformationen im Frequenzspektrum hintereinander übertragen. Wenn jemand mit kleinkariertem Hemd da saß, waren die notwendigen Frequenzen zur Darstellung so hoch, dass sie in den Bereich der anderen Information gelappt sind. Dort war das dann als Störung sichtbar. Zumindest habe ich das so in Erinnerung. Die Vorlesung in physikalischer Elektronik, die TV behandelt hat, ist aber etwa 30 Jahre her, kann sein, dass ich das nicht mehr so genau wiedergebe. :-)

    Hui, da hat sich ja was angesammelt; keine Mail gekriegt, dass was Neues kam; hatte beim Ändern der Benachrichtigungsoptionen nicht auf Absenden geklickt *grummel*.


    Das machst du, indem du weder --tff noch --bff verwendest. Weglassen, dann arbeitet x264 progressiv.

    Hm, dann verstehe ich den Output von x264 nicht:

    Code
    1. [2021-08-27][20:45:26] "C:\Program Files (x86)\Simple x264 Launcher\toolset\x64\x264_x64.exe" --output-depth 8 --crf 18.0 --preset veryfast --tune film --nr 1000 --vf crop:0,0,6,4/resize:720,576,1:1 --output C:\Users\Public\Videos\x264\Hatari.mkv --index C:\Users\Siegbert\AppData\Local\Temp\~026a09c4f17660e09837.ffindex C:\Users\Public\Videos\Todo\Hatari\Hatari.mkv
    2. [2021-08-27][20:45:26]
    3. [2021-08-27][20:45:27] ffms [info]: 720x576i 64:45 @ 25/1 fps (vfr)
    4. [2021-08-27][20:45:27] crop [info]: cropping to 714x572
    5. [2021-08-27][20:45:27] resize [error]: swscale is not compatible with interlaced vertical resizing

    Kein Paramter --tff, d.h. codieren als progressive, aber unten die Meldung "swscale is not compatible with interlaced vertical resizing". Bug in x264? Hier kommt übrigens auch das ffms her, das ich oben zitierte. Scheint als Library in x264 einkompiliert zu sein, um die Metadaten zu extrahieren.

    Es gibt kein zweites Bild, das man wegwerfen müsste. Bei progressivem Video ist ein Vollbild zu einem Zeitpunkt aufgenommen worden; bei Interlaced sind zwei Halbbilder zu verschiedenen Zeitpunkten aufgenommen worden, wurden dann zu einem Vollbild vereint.

    Was ich sehe ist, dass beim Anschauen von Einzelbildern der gerippten Datei mit MPC jedes 2. Bild identisch zum Vorgänger ist. Gaukelt mir hier MPC zwei identische Standbilder vor, die in Wahrheit aus 2 interlaced-Halbbildern zusammengesetzt sind?

    Was ist denn beim Encodieren der DVD passiert, wenn der aus progressivem Filmmaterial interlaced MPEG-2 macht? Ist das danach wirklich interlactes Material, das bei meinem Rückweg deinterlaced werden muss? Oder ist das Flag nur da, um dem Standard zu entsprechen, die Bildinhalte sind aber noch progressive mit 2 identischen Bildern?

    Gibt's eine bessere Methode sich das Material zur Analyse anzusehen als Einzelbilder in MPC?

    DAR = Display Aspect Ratio = Breite : Höhe
    SAR = Sample Aspect Ratio = entzerrte Breite (wie es dargestellt werden soll) : encodierte Breite (wie es gespeichert wurde)
    andere AR-Abkürzungen: kommt drauf an, was die in dem Zusammenhang bedeuten sollen...

    Ok, so weit Einigkeit.

    Zum Skalieren kann man AviSynth oder VapourSynth verwenden, die haben jeweils eine breite Auswahl unterschiedlicher Methoden. Ich nehme an, dass ffmpeg das auch alleine kann, kenne aber den Parametersatz nicht auswendig. Aber ffms(2) ist was anderes, ich kenne das als Quell-Plugin für AviSynth/VapourSynth, nicht als eigenständiges Programm.

    Die Doku von Vapoursynth empfiehlt Bicubic, wenn man es nicht besser weiß. Ist das die Methode, die auch der TV in Hardware anwenden würde?

    Wo es bei mir fehlt, sind die Colorspace-Möglichkeiten, die dort zur Auswahl stehen. Oder ist das beim Ausgangsmaterial Film dann immer derselbe, den man nehmen sollte?

    Dort ist auch nichts erwähnt, ob die Ausgangsgröße irgendein Vielfaches von 2-8 sein muss. Also volle Freiheit beim Croppen auf krumme Werte? Sollte die Endgröße sich an bestimmte Beschränkungen halten?

    Anstatt die variablen Ränder abzuschneiden, könnte man sie auch mit einem scharfen schwarzen Rahmen überdecken. Dann bleibt zumindest das Seitenverhältnis des Gesamtbildes gleich.

    Hm, ja das könnte tatsächlich der einfachere Weg sein, die schwarzen Ränder kosten ja kaum Platz. Sollten die Schwarzen Ränder Vielfaches von irgendwas sein, damit die Grenze zum eigentlichen farbigen Bild nicht innerhalb eines Blockes liegt?


    Für Videobearbeitung sollten mindestens immer 3 SSDs oder HDDs im System vorhanden sein. Den Simple x264 Launcher kannst du auf C: belassen, aber unbedingt für die Streams, einen Ordner auf ein anderes LW erstellen.

    Werd ich bei meinem neuen Rechner so machen, auf der alten Kiste war die CPU der Flaschenhals.

    Hatari.txt:

    Das Preset: veryfast, würde ich auf „slow“ setzen. Das Tuning Film ist eigentlich für 35mm Film gedacht.

    Aber wir haben ja Streams, ich glaube nicht, dass sich hierdurch Vorteile ergeben.

    Aber wenn man z. Bsp. Zeichentrickfilme encodiert, dann kann man unter Tuning „Animation“ verwenden.

    Angeblich sollen mit dieser Tuningeigenschaft, die Bilder flüssiger wirken.

    "slow" werde ich mit dem neuen Rechner dann auch ausprobieren, bisher war "veryfast" für mich ein guter Kompromiss aus Größe und Encodierzeit.

    Ob man Tuning "Film" noch verwenden sollte, wenn das Material schon durch diverse Vorbehandlung durch ist und nicht mehr der Scan direkt vom Film ist eine gute Frage.

    Kann dazu jemand was sagen?


    Animationsfilme habe ich keine auf DVD.

    Cropping:

    Mein Tipp, nicht croppen, dann wird dir auch vermutlich der Fehler nicht mehr angezeigt. Auch interlace stimmt vermutlich wieder.

    Muss ich heute abend mal ausprobieren, sitze gerade nicht am Rechner für Filme.

    Wenn du progressiv willst, dann musst du deinterlacen, wie du schon richtig schreibst mit QTGMC.

    CUDA immer abschalten, das ist mehr für Spiele geeignet. 32 GB- oder 64 GB-RAM sind da sinnvoller.

    Ob das Material wirklich interlaced ist, habe ich oben schon LigH gefragt. CUDA hat mein Rechner bisher nicht.

    Kurze Frage:

    Wenn du in den 70er- oder 80er Jahren Bilder mit einem Röhrenfernseher angeschaut hast, hast du dich damals über Interlacsestreifen und Banding aufgeregt. Damals wussten wir noch gar nicht, dass es so etwas überhaupt gibt.

    Studio-Material war ja auch interlaced aufgenommen, also kein Problem. Gibt's Banding auch im reinen Analogbereich? Ich kann mich nur an Cross-Color/-Luminance-Probleme erinnern, die aber deutlich. :-)

    Bei Filmen kann ich mich an keine Artefakte erinnern, obwohl progressives Material als interlaced gesendet wurde. Keine Ahnung wie die das gemacht haben in der Analogwelt.

    Wer braucht MPEG-2:

    Eine DVD VOB-Datei ist MPEG-2. x264 im MKV-Container in deinem Fall, wird nochmals in VOB zu MPEG-2 umgewandelt.

    Ist mir soweit klar. Was Pato gemeint hatte ist wohl, dass man MPEG2 als Archivformat auf Platte heute nicht mehr braucht. Deswegen scheint er auch neu zu encodieren.


    Da reden wir glaube ich ein bisschen aneinander vorbei. Ich meinte mit x265 nicht den Standard H.265, sondern das Programm zum Encodieren. Soweit ich weiß, benutzt das keine HW-Beschleunigung. Du führst ja unten fürs Videoarchiv auch die CPU an. Da war meine Frage, ob es inzwischen qualitativ gleichwertige Encoder gibt, die GPUs benutzen und deswegen nochmal deutlich schneller sind als x265 bei vergleichbarer Qualität des Endmaterials.


    Dass vergleichsweise schwachbrüstige Mobil- und Embedded-Geräte HW-Beschleunigung zum Decodieren brauchen ist klar.


    Noch an Pro Jo: Bei Hatari würde ich mir die Bluray tatsächlich überlegen. Bei den meisten anderen Filmen, die auf DVD warten, würde sich die Neuanschaffung wohl nicht lohnen. Wäre auch ganz schön teuer, sind einige Schachteln voll ... :-)

    Ok wird doch Zeit auf neue Hardware zu wechseln. Auch x265 ist rein CPU-basiert ohne dass die GPU eine Rolle spielt, korrekt?

    Zu Problem 1: Ja, das kommt vor. MPEG2-Encoder für DVDs sind meist auf "interlaced, TFF" eingestellt, selbst wenn sie progressive Videoinhalte encodieren. Nur zur Sicherheit. Damit man nicht aus Versehen mal vergisst, ausgeschaltetes Interlacing wieder einzuschalten, wenn doch mal Interlaced-Material zu encodieren wäre, denn das wäre katastrophal, von der Qualität her. Aber x264 kommt damit klar. Dieser Encoder verwendet, wenn --tff (oder --bff) zum Aktivieren des Interlaced-Encodings verwendet wird, den PAFF-Algorithmus, der encodiert nicht die gesamte Bildfläche, sondern abschnittsweise nur dort im Interlaced-Modus, wo das wirklich vorteilhaft ist. Ohne den Parameter wird überall progressiv encodiert.

    Hm, d.h. ich sollte den --tff Parameter angeben? Wie verwende ich dann das Scaling von x264 wenn swscale kein Interlacing mag?

    Ich kann keinen Parameter in x264 finden, der sagt, "vertrau mir, das ist progressive" und dann auch "progressive" in die Metadaten schreibt. Muss man für diese Umwandlung dann doch auf ein Avisynth-/Vapoursynth-Skript zurückgreifen? Müsste man dabei dann das jeweils zweite Bild wegschmeißen, da es ja denselben Inhalt zeigt? Ich meine ich hätte das vor Urzeiten mal probiert und das Ergebnis hätte sehr ruckelig ausgesehen.

    Zu Problem 3: Da ist unklar, ob du dich auf den Stauchungsgrad (1024:720 = 64:45) oder das Seitenverhältnis, und hier auf das des Gesamtbildes (1024:576=16:9) oder des interessanten Bildanteils beziehst. Ein Seitenverhältnis von 2,4:1 oder auch 2,35:1 wäre jedenfalls eine Art Kino-Seitenverhältnis, da müsstest du selbst auf einer 16:9-DVD noch eine recht breite Letterbox oben und unten im encodierten Video haben, also mehr als nur 2-4 Pixelzeilen wegschneiden wollen.

    Nachdem ich mir das alles nochmal angeschaut habe: Ich glaube ich will skalieren auf 1024:576=16:9 mit PAR 1:1.

    IMDB gibt als Original-Verhältnis 1,85:1 an und das ist ja recht nah an 16:9. Die 2,40:1 hat Mediainfo ausgespuckt, keine Ahnung woher das da kommt. Kann man im VOB der DVD nachschauen, ob das da fälschlicherweise drin steht und so von MakeMKV übernommen wurde?


    Ich habe nicht gleich gesehen, dass 64:45 = 16:9 ist, mangelnde Erfahrung :-). Mediainfo schreibt als DAR 16:9, ffms 64:45, hmmm. Ist Dein Begriff Stauchungsgrad dasselbe wie FAR (mit der Definition von Posting #2 hier)?


    Zu den angehängten Screenshots von MPC und VLC:

    Gesamtbild und interessantes Bild sind nahezu identisch. Obwohl 1,85:1 eigentlich etwas breiter als 16:9 ist, sind trotzdem am rechten Rand 6 schwarze Pixel (die ich wegcroppen wollte; unten sind wieder 2 Pixel wabbeliges Bild, die ich auch croppen wollte --> 714x572; ausgehend von denen wolte ich dann mit PAR 1:1 hochskalieren).

    Interessanterweise sagt MPC bei derselben MKV-Datei 2,35:1 (siehe Anhang). Berechnen die das aus anderen Daten? Und Mediainfo rundet dabei (trotz der Schreibweise 2,40)?

    MPC scheint mir das in den Metadaten angegebene Originalverhältnis von 2,35:1 bei der Wiedergabe zu benutzen, das ist aber eindeutig in die Breite gezogen. VLC stellt es schmaler dar, sieht ok aus; wie kriege ich denn raus welches Seitenverhältnis VLC tatsächlich benutzt?

    Genau wegen solchen Problemen (wie hier bei MPC) versuche ich auf PAR 1:1 zu kommen.


    Was ich in "Problem 3" meinte: Ich hätte für PAR 1:1 auf 1024x576 resizen müssen, habe aber dummerweise

    "resize:720,576,1:1" benutzt.


    Wie sollte ich jetzt weiter vorgehen: swscale mag auch "resize:1024,576,1:1" nicht, hab's gerade probiert. Ausweg Avisynth/Vapoursynth?

    Subjektiv: Jein, zumindest mit so geringen Verlusten, dass man sie nicht bemerkt.

    Sorry, wenn ich mich hier an den Thread dranhänge, aber meine Ausgangssituation ist ähnlich wie beim Thread-Starter: Ziel ist, DVD per MakeMKV auf Platte, allerdings keine Serien sondern Kinofilme!


    Was ich gemacht habe: Die MKVs (der MakeMKV-Output) in den Simple X264-Launcher von Mulder und die Optionen von x264 gesetzt: CRF 18, Tuning "Film", Profile unrestricted, NR 1000 und Croppen; aber dabei gibt's ein paar Probleme ...


    Erstmal: Warum so wie da oben beschrieben?

    • Ich bin ein eher unkritischer Bildbetrachter (LigH hat aus meiner Sicht da vollkommen recht), das was mir aber komischerweise störend auffällt und was ich gerne weg hätte sind die unruhigen Ränder (meist 2-4 Pixel an 1 oder 2 Seiten) bei vielen Filmen, deswegen das Croppen; daraus folgt natürlich unweigerlich das Encodieren, noch verstärkt durch das Argument von Pato.
    • Abspielen soll den finalen Film am Ende dann eine der Linux-PVRs (Dreambox und die ganzen Nachahmer). Die und der TV können inzwischen 4K. Die haben auch kein Problem mit ungewöhnlichen Seitenlängen, die beim Croppen entstehen, also schneide ich normal auch die schwarzen Ränder weg (bei den gestörten Rändern ist das Schwarz nach dem Croppen ja ohnehin weg).

    So jetzt aber zu den Problemen:

    Problem 1:

    Der erste Rip war "Hatari" und der ist als TFF markiert (siehe Log). Aber der Resize auf PAR 1:1 und übliche Seitenlängen schlägt fehl mit "swscale is not compatible with interlaced vertical resizing". Wie sage ich x264, dass das TFF nicht stimmt, sondern dass das Material progressive ist und er es dann auch so encoden soll? (2 aufeinanderfolgende Bilder sind jeweils identisch, keine Interlace-Kämme zu sehen)

    Im Thread hier sagte ja jemand, dass SD immer als interlaced markiert ist (warum das denn?). Also würde diese Frage ja bei jedem Rip auftauchen.


    Problem 2:

    Soll man beim Encodieren resizen? Was ich diesem Thread entnehme, macht das die Hardware inzwischen ganz gut (oder ging's dabei nur ums Upscaling, nicht aber ums Rescaling?). Aber irgendwie fühle ich mich wohler mit PAR 1:1, nicht dass doch irgendein Algo auf die Idee kommt bei Abweichung davon etwas Tolles machen zu müssen; ist das abwegig?


    Problem 3:

    Falls resizen, auf welche Werte? Muss es was von mod2 bis mod16 sein? Das meine Werte im obigen Fall Schrott sind, ist mir beim Anschauen der Mediainfo-Daten jetzt auch aufgefallen, da sollte ja am Schluss ein Verhältnis von 2,4:1 rauskommen laut Mediainfo. Woher nimmt ffms eigentlich die PAR 64:45, die kann ich in Mediainfo nirgendwo sehen (und ich komm mit den Werten auch nicht auf 2,4:1)?



    Wenn die obigen Punkte geklärt sind, habe ich dann noch ein paar weitere Punkte, die mir auch so durch den Kopf gegangen sind:

    • Der NR-Filter in x264 soll nicht berühmt sein, aber da ich auf vergleichsweise alter HW arbeite haben Avisynth-Skripte in der Vergangenheit die Sache immer deutlich verlangsamt. Wenn das heute mit Vapoursynth (multithreading, 64bit, wenn ich das richtig verstanden habe?) anders ist, wäre das nochmal einen Versuch wert. Wenn die Ryzen5 mit APU kommen wird's dann auch Zeit für neue Hardware (oder sollte man von x264 weg und Codieren heutzutage von einer Grafikkarte erledigen lassen?).
    • Ein weiteres Argument warum ich mal zum Recodieren übergegangen bin war Interlacing. Im AVS-Forum hat mal einer Unterschiede bei kritischem Material gezeigt (schräge Streben vor einer Treppe, diagonaler Kameraschwenk) und die Artefakte bei den gängigen Methoden waren krass. Ich meine es war qtgmc das hier so herausragte, kann mich aber auch täuschen; ist lange her und ich finde den Thread gerade nicht mehr. Hat die Hardware hier auch aufgeholt und macht ein Deinterlacen beim Encodieren überflüssig?
    • Ein anderes Artefakt was mir häufig auffällt ist Banding. Ich weiß nur nie woher es eigentlich stammt. Würde Encodieren mit 10bit hier helfen, um zumindest bei diesem Schritt kein (zusätzliches) Banding zu erzeugen?
    • Benutzt Ihr eigentlich inzwischen x265 statt x264?
    • Kann SW-Re-/Upscaling theoretisch irgendwas besser als Hardware? Die Stimmung hier im Trend war ja ganz klar gegen Upscaling beim Encodieren.

    Dateien

    • Hatari.txt

      (2,92 kB, 9 Mal heruntergeladen, zuletzt: )
    • mediainfo.txt

      (8,27 kB, 10 Mal heruntergeladen, zuletzt: )
    Zitat von FreaQ

    Nein stimmt nicht mehr.
    Die aktuelle version unterstützt neben CCE SP 2.50, 2.6x auch 2.7x.


    Tatsächlich, mit der Version läuft es zusammen mit CCE 2.70 :)


    Wie verhält sich denn das jetzt mit BatchCCEWS vs. CCEfront/Batchencode? Sind letztere eher standalone-Tools oder einfach Alternativen zum BatchCCE? Können die irgendwas mehr oder weniger als BatchCCE, denn aus irgendeinem Grund sind sie ja wohl entwickelt worden?


    Ciao
    CooCooC

    Zitat von Gleitz

    Das wichtigste wurde schon gesagt. Die Zukunft ist BatchEncodeM2V.
    BatchCCEWS wird nicht mehr weiter entwickelt und daher fehlt die Unterstützung von SP 2.70 und Basic generell.


    Stimmt das noch? In ScenAid gibt es nämlich einen Menüpunkt BatchCCE und einen BatchEncodeM2V und letzterer spuckt die Meldung aus der Programmierer habe dessen Support eingestellt, und man erhält zusätzlich einen Verweis auf die Seite von BatchCCE. Dummerweise unterstützt dessen letzte Alpha immer noch nicht den "CCE 2.70", sodaß ich momentan noch keinen Weg gefunden habe, der Big3-Anleitung zu folgen, wenn man nur die neueste CCE-Version hat.


    Sind "Batchencode" und CCEfront momentan die Tools der Wahl? Wie fügen die sich dann in das Big3-Schema ein? Ich habe z.B. bisher nicht gefunden, wie ich dort angeben kann, daß mein Material progressiv ist (halt PAL mit fälschlich gesetztem Interlace-Flag). GOP 15 würde ich auch gerne vorgeben, weiß aber nicht genau wo. *seufz*


    Nur als Nebenbemerkung: Arbeitet ihr eigentlich alle unter Win mit Admin-Rechten? Die meisten Tools in der Big3-Anleitung haben Schwierigkeiten, wenn man sie als Admin installiert und dann als eingeschränkter User nutzen will. Im Forum konnte ich dazu nix finden (die Suchfunktion ist aber auch zum Abgewöhnen oder wie erreiche ich eine AND-Verknüpfung der Suchbegriffe oder die Suche nach einer festen Phrase?)


    Ciao
    CooCoo