Konvertierung H.264 zu MPEG2 beschleunigen?

    Mahlzeit,
    ich habe mal eine Frage bezüglich des Encodens von h264 zu Mpeg2.
    Und zwar bin ich gerade dabei das Hochzeitsvideo eines Kollegen von 1080p (1920x1080) h264 nach Mpeg2 zu wandeln damit man daraus ne schöne DVD machen kann (die auch die Oma auf ihrem DVD Player gucken kann).

    Dazu verwende ich AviSynth und HCEnc mit dem "Best" Profil.

    Leider kriecht das ganze mit guten 20FPS auf meinem 3,2GHz Q6600 Quadcore dahin (oder ist das normal?).
    Ich habe schon des öfteren gelesen das hier wohl Avisynth der Flaschenhals ist, gibt es da ne möglichkeit das zu ändern?

    Mein Avisynth Script ist dabei sehr übersichtlich da es nicht anderes macht als das ganze zu resizen:

    Code
    AVCSource("Hochzeit.dga")
Lanczos4Resize(720,576)

    Gibt es da ne möglichkeit das ganze zu Beschleunigen z.B. mit Avisynth MT, oder gibt es ne ganz andere möglichkeit wie ich den HCEnc füttern kann?

    Bin für jede Info dankbar.

    Ich finde 20 fps bei einem laufenden MPEG2-Encoder, der so gründlich arbeitet wie der HC, ziemlich normal. Höchstwahrscheinlich ist weniger die Decodierung der AVC-Quelle, sondern die Encodierung in MPEG2 im "Best"-Profil hauptsächlich für die Beschäftigung der CPU verantwortlich.

    Wie sind denn die einzelnen Kerne so ausgelastet?

    Also wenn Sie gleichmäßig ausgelastet sind dann hab ich so 25% pro Kern (schwankt halt aber im Mittel kommts hin), und das finde ich doch schon ein wenig mager.

    Der DVD Rebuilder ist da wesentlich besser wenn ich ihn mit dem HC laufen lasse, aber der splittet meines Wissens das Video vorher ja auch in mehrer Teile die parallel berechnet werde.

    Experiment.

    Quelle: AVC 1080p @ 10mbps

    Avisynth: Spline16Resize(720,576)

    HCEnc: 2-pass / profile "best" / Bitrate avg=8000 max=9900 / Rest auf Default

    CPU: i7-860 (@stock, 4C8T)


    Ärschdens:

    Code
    AVCSource("1080p.dga")Spline16Resize(720,576)

    HCEnc:
    pass1 = 34.2 fps
    pass2 = 33.8 fps


    Zwoidens:

    Code
    ffMpegSource2("1080p.mp4")
Spline16Resize(720,576)

    HCEnc:
    pass1 = 80.0 fps
    pass2 = 67.0 fps


    DGAVCDec ist ...

    1) veraltet,

    2) fehlerhaft,

    3) laaangsaaaam

    Zitat von darkside40

    akzeptiert FFMpegSource2 sogar MP4 und MKV als Source.

    Aus persönlicher Erfahrung ist es sogar ratsam, ffmpegsource2 wann immer möglich mit mkvs zu füttern statt mit ts oder m2ts. Seit dem leide ich weniger unter Decoderfehlern oder sporadischen Zwillingsbildern.

    Bei so einem minimal-Script: nein, da bringt das nur eine marginale Verbesserung, wenn denn überhaupt.

    ... schnell ausprobiert: pass1= keine Änderung, pass2= von 67fps auf 68fps.

    Ob dieses eine FPS jetzt wirklich vom MT kommt? Oder doch eher "Messungenauigkeit" .... ? :D


    Wenn da noch irgendwelche "nennenswerten" Filter mitspielen, dann lohnt sich MT. Aber bei einfachem Source-Resize-Return tut sich da eher wenig.

    .
    .
    .

    (D.Graft hat letzhin mal Multithreading mit "Tweak(sat=0.0)" ausprobiert. Weiß nicht, ob er wirklich erwartet hat, dass seine 1080p-Geschwindigkeit von 250 fps auf 1500 fps (6Core) ansteigt .... ) :D :rolleyes:

    Jupp, hat er ... "ffmpeg-MT", von dem bin ich auch ausgegangen. Gibt wohl auch Compiles die single-threaded arbeiten, die sind höchstscharweihnlich auch wieder langsamer ... hab ich aber noch nie probiert.

    Kommt drauf an, wer welchen Quellcode compiliert hat. Entferne mal ffms.dll komplett aus dem /Plugins-Ordner, packe die MT-DLL in ein separates Verzeichnis, und probiere manuelles Laden per

    LoadCPlugin("x:\pfad\ffms2.dll")

    bzw.

    Load_stdcall_Plugin("x:\pfad\ffms2.dll")


    Weil, wenn es die C-Plugin-Variante ist ... diese Plugins sind mit Auto-Loading inkompatibel.

    Hast du die FFmpegSource r412 build 2 herunter geladen?
    Dann nur mit LoadCPlugin..
    Du solltest vielleicht deine ersten Gehversuche mit einem Stable Build versuchen (2.14).
    Tweaken kannst du immer noch.
    Bei mir läuft die MT Version 2.14 einwandfrei unter 32bit.

    Also ich habe die Stable MT (32bit) von der Google Code Webseite genommen.
    Mit LoadCPlugin funktioniert es nicht, da sagt mir HCEnc nur das es sich nicht um ein C Plugin handelt, genauso bei Load_stdcall_Plugin.

    Also Avisynth Version zeigt mit HCEnc übrigens 2.5.8.5 mit Creation Date 12-11-2010 an, und HCEnc hat Version 0.25.
    Vielleicht hat es aber uch damit zu tun das ich Windows 7 x64 nutze?

    Edit:
    Okay scheinbar hat es daran gelegen das ich noch nen alte ffindex Datei bei meinem Video liegen hatte.
    Habe gerade ne neue mit dem ffindex Tool aus den MT Paket erstellt, und jetzt funktioniert es.

    Macht es eigentlich nen Unterschied das ich das Video nur per ffvideosource laden kann, statt mit ffmpegsource2?
    Übrigens jetzt läuft der Encode mit gut 49FPS.

    Zitat von darkside40


    Okay scheinbar hat es daran gelegen das ich noch nen alte ffindex Datei bei meinem Video liegen hatte.


    Oops, ja. Die Index-Datei sollte schon mit der gleichen Version erstellt werden. Kennt man ja auch von DGIndex/DGDecode ...


    Zitat

    Habe gerade ne neue mit dem ffindex Tool aus den MT Paket erstellt, und jetzt funktioniert es.


    Hurra! :)


    Zitat

    Übrigens jetzt läuft der Encode mit gut 49FPS.


    Hurra! :cheers:


    Zitat

    Macht es eigentlich nen Unterschied das ich das Video nur per ffvideosource laden kann, statt mit ffmpegsource2?


    Eigentlich sollte das schon gehen, hmh ... liegt die "ffmsindex.exe" im gleichen Ordner wie die "ffms2.dll"? Das muss sie nämlich.

    Die Funktion "FFmpegSource2" gibt es nur, wenn das Import-Skript "FFMS2.avsi" eingebunden wird. Diese fasst FFIndex (wenn nötig), FFVideoSource und FFAudioSource zusammen, und bietet vollen Zugriff auf die Parameter der Teilfunktionen in der eigenen Parameterliste, mit Automatik als Standardbelegung.

    Wenn du nur das Video alleine brauchst, benutze FFVideoSource.
    __

    "Bessere Qualität" ist immer Ansichtssache.

    Es gibt "schärfere" Skalierungsfunktionen, die aber den Nachteil haben, dass das "Gibbssche Phänomen" (siehe Wikipedia) die Komprimierbarkeit verschlechtert, Aliasing (flimmernde Muster bei sehr langsamer Bewegung) und Kanten-Ringing (Überschärfe) hervorrufen kann. Manche mögen das, andere finden es unnatürlich.

    Code
    blankclip(width=800,height=600,color=$404040)
addborders(160,120,0,0,color=$CCCCCC)


a1 = lanczos4resize(320,240)
a2 = spline16resize(320,240)


interleave(a1,a2)

    Wenn man *alle* Resizer durchprobiert, stellt man fest, dass die Unterschiede gerade beim Herunterskalieren sehr klein ausfallen.

    Es wird sicher akademische Beispiele geben, mit denen man die Nachteile des einen oder anderen Resizers schön anschaulich demonstrieren kann (z.B. Tunnel-Spirale, oder typische Anisotropie-Demonstrationen mit feinen Mustern, die sich perspektivisch verjüngen).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden