Beiträge von H264x

    Kleiner Tipp: Für die icudt##.dll gibt es minimalen Ersatz, wenn man etwas Plattenplatz sparen will.


    Danke :-)


    Funktionieren beide mit qaac 2.64 in 32 und 64 bit.


    Unter welchem BS wurde dies getestet?
    Ich nutze Windows 7 Professional 64-Bit
    Bin gerade am überlegen ob es an irgendwelchen fehlenden Runtime Paketen etc... liegen könnte?
    Hab seit gestern das neuste All in One Runtime Paket erst drauf gemacht:
    https://www.sereby.org/site/do…All%20in%20One%20Runtimes

    Bei StaxRip x64 Version 1.7.0.0 funktioniert leider der beigelegte qaac (Version 2.64) Audio Encoder nicht :(


    Habe verschiedene iTunes Versionen ausprobiert (jeweils mit dem Makeportable Script extrahiert)


    iTunes 12.7.1 (64-bit)
    iTunes 12.7.0 (64-bit)
    iTunes 12.6.2 (64-bit)

    und die QTFiles in den [qaac] Ordner mitbeigelegt:





    Bekomme leider die Fehlermeldung: ERROR: 193: CoreAudioToolbox.dll


    Erfolgreich waren die alten QTfiles64 von 2015,
    die ich damals bei der StaxRip x64 1.3.4.6 test Version in den [qaac] Ordner mitbeigelegt habe,
    Diese habe ich zum Test in den [qaac] Ordner von StaxRip x64 v1.7.0.0 getan
    und danach funktioniert qaac auf Anhieb :)


    Woher sollte ich das auch wissen...
    Die Traurige Nachricht aus dem Slashcam Forum ist ja erst seit gestern dem 16.11.2016 veröffentlicht worden!
    Hatte noch in Erinnerung (aus dem Jahr 2015), das er bald in Rente gehen wollte...
    Das er dann so schnell von uns Gegangen ist, hätte ich jetzt nicht gedacht.


    :heul: Herzliches Beileid :(

    Hab zu Testzwecken diese x265vfw Codec Version unter Windows 7 Pro 64-Bit installiert:
    x265vfw_x64_v120_x265b80_20160129


    Leider kann man keinen [ File ] Output mode wählen :(
    Siehe Bild...


    Warnung:
    HEVC hat im AVI Container nichts zu suchen!
    Zum Testen, habe ich mein Video mal per VFW in den AVI Container geschrieben...
    (Bitte nicht Nachmachen)



    Wärend der Encoding Abarbeitung kommt es zu mehreren Warnmeldungen
    u.a. die Unverschämte Meldung von x265vfw, das man doch den File Output aktivieren kann :D
    Geht doch nicht!


    Nach dem das Quell Video, (was nur eine Gesamt Spielzeit von einer 1 Minute hat)
    nach gefühlten 30 Minuten endlich als HEVC im AVI Container vorlag,
    war ich erstaunt über den Unglaublichen Größenunterschied zum x264 Encoding :eek:
    (Mal eben knapp 64 MB gespart)



    Könnte Jemand von euch im Englischen Doom9 Forum mal nachfragen,
    wann es ein Update für den x265vfw Codec geben wird?

    Fängst du schon wieder an, tote Pferde zu reiten? Und noch dazu in die völlig falsche Richtung?


    Die Sache ist bei mir so, das ich unter Windows 7 mit 64-Bit
    eine Fehlermeldung bei der Einbindung vom Externen x264.exe Encoder in VirtualDub erhalte!
    Das hängt mit der Pipe Geschichte zusammen mit der ich mich nicht weiter befassen möchte.
    Und bevor in der Abarbeitung vom Externen x264.exe Encoder irgendein Fehler ensteht,
    weil irgendwas in der Befehlskette nicht stimmt, verlasse ich mich lieber auf den x264vfw Codec in der File Ausgabe :)

    Es wird aufjedenfall die RAW Ausgabe benutzt und der ganze VFW Kram im AVI Container ist damit Geschichte,
    weil das Ergebnis mit dem des eigenständigen Encoders (gleichwertig anzusehen) ist.



    Und wenn du sowieso schon separate Videostreams speicherst, dann lass doch bitte jegliche VfW-Codecs weg, die vermutlich seltener aktualisiert werden und auch weniger Optionen bereitstellen als ein EXE-Encoder, und verwende stattdessen gleich die Möglichkeit, "externe Encoder" einzubinden.


    Der x264vfw bietet für meine Anwendungszwecke alle Optionen, die ich benötige :)
    Die andere Sache ist die mit der Aktualisierung!
    Okay, x264vfw ist gestern am 02.05.2016 aktualisiert worden:
    http://www.videohelp.com/software/x264-VFW
    Wenn man vom Teufel spricht ;)
    Hab mir vor ein paar Tagen die zuletzt erschienene: 264vfw Version r2538 von 02/2015 gezogen.
    Also über 1 Jahr Update Zeit hat es gebraucht.


    Den x264 Codec gibt es schon über 10 Jahre und warum erscheinen fast Wöchentlich neue Updates? (Wegen 10/12 Bit etc..)
    Das Ding müsste doch eigentlich im 8-Bit Bereich schon längst Ausgereift sein!
    Egal ob man jetzt eine Version von 2012 oder 2016 benutzt.
    Irgendwo muss es doch auch eine Grenze im ganzen Update Wahn geben? ;)

    Folgendes Beispiel

    Als ich meine MP3s im Jahre 1999 mit CBR 128 Kbps gespeichert habe,
    sind meinem Ohr bis heute keine Fehler in den Musikstücken aufgefallen.
    Warum sollte ich jetzt einen Codec aus 2016 benutzen, wenn der von 1999 eigentlich völlig ausreicht? :D


    Ich habe woanders gelesen, dass x264vfw sein Encodierergebnis auch parallel als eigene Datei herausgeben kann,
    dann wird nur ein "leeres" AVI vom Videoprogramm geschrieben, welches den Codec benutzt.
    Dann müsste das Ergebnis mit dem des eigenständigen Encoders gleichwertig sein.


    Bin gerade dabei den x264vfw Codec auszuprobieren um eine RAW ohne Container zu schreiben.
    Unter "Output mode" kann man zwischen VFW oder File wählen.
    Hab jetzt File gewählt und wollte mal wissen, was das mit den verschiedenen VFW FourCC Varianten auf sich hat?




    Und was bedeutet eigentlich die VirtualDub Hack funktion genau?
    Verstehe grob übersetzt, das wenn man die funktion Aktiviert (Haken gesetzt),
    das es zu invalid bitstreams kommen kann...





    Hab gerade gesehen, das es auch einen x265vfw Codec gibt :)
    http://forum.doom9.org/showpost.php?p=1755259&postcount=6


    Kurze frage am Rande...
    Hat jemand schon Erfahrung damit gemacht?
    Also hier gibt es schonmal 5 Sterne für den x265vfw:
    https://sourceforge.net/projec…play/?source=typ_redirect
    Sieht sehr vielversprechend aus.


    Auch hier gillt bestimmt die goldene Regel, das HEVC nichts im AVI Container zu suchen hat ;)
    So wie es schon bei AVC im AVI Container war.


    Also bitte "x264vfw" oder "x265vfw" nur für die RAW Ausgabe benutzen,
    damit das Ergebnis mit dem des eigenständigen Encoders gleichwertig anzusehen ist!!

    1. VOBInput.dll direkt zur BeSweet.exe legen;


    Gar nicht mal so einfach, diese DLL Datei noch aufzugabeln ;)


    http://dspguru.doom9.org/effects.html -> Der Link scheint tot zu sein.


    Und nach einer gefühlten halben Stunde suchen im Netz, habe ich die "VOBInput.dll" doch noch gefunden unter:
    http://www.doom9.org/index.html?/Old_news/september02.htm



    2. AVI-Datei direkt als core( -input ... ) verwenden.


    Schade, es bleibt weiterhin bei dieser Fehlermeldung hier: #58


    Code
    1. "C:\PortableApps\StaxRip_x64_1.3.4.6_test\Apps\BeSweet\BeSweet.exe" -core( -input "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi" -output "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.m4a" ) -bsn( -vbr 0.45 )"



    Dann hast du auch noch nicht getestet, ob BeSweet mit der VOBInput.dll die AVI-Datei direkt verarbeiten kann, ohne den Ton als WAV zu extrahieren.


    Könntest du mir den kompletten Befehl zur Umwandlung direkt aus dem AVI Container verraten?
    Dann teste ich das später nachträglich :)


    Aber QAAC müsste auch 24b-WAV verarbeiten.


    Das klappt einwandfrei und habe ich unter Punkt 08.) schon aufgelistet :)

    Code
    1. [U]
    2. Als Alternativen bieten sich direkt folgende Möglichkeiten an:[/U]
    3. WAV Audiospur mit EAC3to umwandeln.
    4. WAV Audiospur mit FFMpeg umwandeln.
    5. WAV Audiospur mit QAAC umwandeln.
    6. WAV Audiospur mit LameXP umwandeln.
    7. [COLOR=#008000]^^ Diese 4 können eine WAV Datei mit 24-Bit direkt zu AAC im m4a Container verarbeiten ohne dabei den Umweg über Audacity zu gehen ;)[/COLOR]

    Wie es schon hier in diesem Beitrag kurz angesprochen wurde...


    Bekomme folgende Error Meldung bei der Umwandlung mit BeSweet rein...
    http://img.xrmb2.net/images/199956.png
    Die Audiospur ist: WAV in diesem AVI Container, die ich zu AAC / m4a umwandlen möchte!



    PCM 24 bit sollte BeSweet eigentlich verarbeiten können, dachte ich.
    Mit der VOBInput.dll sogar aus der AVI heraus (klingt paradox, ist aber wahrscheinlich so). Wundert mich, dass das Probleme gibt.


    Hier nun mein Lösungsvorschlag von mir als kleines Text Tutorial :)


    01.) Beispiel Video, was für diesen Versuch genommen wurde:
    Hier ist Übrigens das Original BM Test Video dazu: http://www.file-upload.net/dow…ahme20160227MJPG.avi.html
    Solange es noch auf File-Upload online ist, kann es jeder der möchte, nach dieser Methode ausprobieren...



    02.) Demux WAV from AVI
    VirtualDub x86 or x64 > starten
    *.AVI Video öffnen
    > In meinem Beispiel: BM Test Aufnahme 20160227 MJPG 1080i.avi
    Oben in der Menüleiste auf: File > Save WAV > klicken
    WAV Datei abspeichern
    > In meinem Beispiel unter: C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.wav
    VirtualDub x86 or x64 > schließen


    03.) So sieht es dann aus, wenn die WAV seperat gespeichert ist:



    04.) MediaInfo von dieser demuxten WAV Datei durch VirtualDub:




    05.) Erster Versuch mit BeSweet diese WAV Datei (24-Bits) zu AAC [ -VBR 0.45 ] im m4a Container umzuwandeln.bat

    Code
    1. "C:\PortableApps\StaxRip_x64_1.3.4.6_test\Apps\BeSweet\BeSweet.exe" -core( -input "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.wav" -output "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.m4a" ) -bsn( -vbr 0.45 )"Pause



    06.) Fehlermeldung #58 von BeSweet zu dieser 24-Bit WAV Datei:



    07.) Meine Vermutung zur Fehlermeldung #58 von BeSweet ist...
    Wie es schon im Titeltext von diesem Beitrag steht:
    BeSweet kann keine WAV Dateien mit 24 bits umwandeln!



    08.) Mein Lösungsvorschlag dagegen lautet...


    WAV Datei mit Audacity von 24 bits zu 16 bits umwandeln:
    Audacity > starten
    *.WAV Datei öffnen
    > In meinem Beispiel: BM Test Aufnahme 20160227 MJPG 1080i.wav
    Oben in der Menüleiste auf: Datei > Ton epotieren > klicken
    WAV Datei abspeichern mit folgenden Dateityp: [ WAV (Microsoft) signed 16-bit PCM ]
    > In meinem Beispiel unter: C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i - Neu als 16-Bits.wav
    Audacity > schließen


    Code
    1. [U]Als Alternativen bieten sich direkt folgende Möglichkeiten an:[/U]WAV Audiospur mit EAC3to umwandeln.WAV Audiospur mit FFMpeg umwandeln.WAV Audiospur mit QAAC umwandeln.WAV Audiospur mit LameXP umwandeln.[COLOR=#008000]^^ Diese 4 können eine WAV Datei mit 24-Bit direkt zu AAC im m4a Container verarbeiten ohne dabei den Umweg über Audacity zu gehen ;)[/COLOR]



    09.) Nun habe ich ja in diesem Beispiel schon den Weg mit Audacity begonnen!
    Was eigentlich total überflüssig ist ;)
    Und so sieht es dann aus, wenn die 24 Bit WAV als neue Datei mit Audacity als 16-Bit WAV geschrieben worden ist:



    10.) MediaInfo von der neuen WAV Datei mit 16-Bits, dank Audacity:
    Direkt mal 6 MB gespart ;)




    11.) Gegenprobe = Neuer Versuch mit BeSweet, die neue WAV Datei mit 16-Bits zu AAC [ -VBR 0.45 ] im m4a Container umzuwandeln.bat

    Code
    1. "C:\PortableApps\StaxRip_x64_1.3.4.6_test\Apps\BeSweet\BeSweet.exe" -core( -input "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i - Neu als 16-Bits.wav" -output "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i - Neu als 16-Bits.m4a" ) -bsn( -vbr 0.45 )"
    2. Pause



    12.) Diesmal war BeSweet erfolgreich bei der Umwandlung :)



    13.) Fertig :)


    Dieser Beitrag soll verdeutlichen, das es trotzdem mit BeSweet weiter gehen kann ;)

    Betrachten wir hier mal konkret den Zweck, dass libavcodec nur einen Decoder-Thread verwenden soll....


    Also bei diese beiden "xSource" Quellen, kann man dann sagen, dass der libavcodec nur einen Decoder-Thread verwenden soll :)


    FFVideoSource("inputVideo",threads=1)
    oder
    LWLibavVideoSource("inputVideo",threads=1)


    ...weil bei manchen Kombinationen aus Container und Inhaltsvariante mehrere Threads nicht ganz zuverlässig arbeiten könnten.


    Gut das es eine Absicherung dagegen gibt ;)
    Wenn man ,threads=1 weglässt, kann was passieren, muss aber nicht.



    :eek: Gut zu wissen... e-m-b-e-d ist ja zensiert.


    Was heißt das mit "e-m-b-e-d ist ja zensiert" genau?
    Verstehe ich gerade nicht ;)


    Code
    1. Hier noch ein kleines Text Tutorial zum Screencast Video,
    2. wie man die Script Änderung per Hand vor dem Encoding Prozess in StaxRip vornehmen kann:


    https://vimeo.com/164821196


    1.) Quell Video in StaxRip per AviSynth + FFVideoSource laden:




    2.) Im Temp Ordner, den StaxRip zu jedem Video erstellt, kann man sich die Scripte vorher anschauen (Nicht dort editieren)




    3.) Wenn in der StaxRip Preview, das Video der Zeit noch nicht korrekt dargestellt wird... dann bei Schritt 4 weiter machen




    4.) Jetzt kommt die Manuelle Script Änderung in StaxRip per Hand zum Einsatz:




    5.) Zum Abgleich noch mal einen kurzen Blick in den Temp Ordner werfen um sich die Scripte anzuschauen,
    wie sie von der "Internen Script Edit Zentrale" in StaxRip verändert worden sind...
    (Hier nichts verändern! Nur zum Abgleich anschauen)




    6.) Nun sollte das Video korrekt dargestellt werden :)


    Vorsicht großes Bild
    http://img.xrmb2.net/images/638138.png

    Wieso der MediaInfo-Report als Bild?


    Angewohnheit zur besseren Übersicht (meinerseits) ;)


    Du kannst die Analyse auch im Format "Text" exportieren und hier als Code einfügen oder auf einen pastebin laden... nun gut.



    PCM 24 bit sollte BeSweet eigentlich verarbeiten können, dachte ich.
    Mit der VOBInput.dll sogar aus der AVI heraus (klingt paradox, ist aber wahrscheinlich so).
    Wundert mich, dass das Probleme gibt.


    Normalerweise kann BeSweet: WAV Dateien umwandeln...
    Vielleicht liegt es ja an der Samplingrate mit 48,0 KHz + 24 Bits, die den Error Code 58 produziert ?
    Hier ist Übrigens das Original BM Test Video: http://www.file-upload.net/dow…ahme20160227MJPG.avi.html
    Vielleicht kannst du es ja noch mal mit BeSweet testen?


    Extrahiert StaxRip dann die Tonspur falsch in eine WAV-Datei


    Das Demuxen macht StaxRip einwandfrei :)
    Neuerdings per FFMpeg Batch Befehl, statt wie bisher per VirtualDubMod (demux)
    Auch die Gegenprobe mit VirtualDub demux, wenn die WAV Datei nun aus dem AVI Container draussen ist,
    funktioniert nicht mit dem Manuellen "BeSweet" Befehlsaufruf.

    Seit der letzten Stable hat sich viel getan, ich hab ein Modultest der anzeigt wenn die Version von einem Paket nicht stimmt.


    Hab nun diese hier installiert: StaxRip_x64_1.3.4.6_test
    inkl. AviSynth+_r1849-MT-pfmod with VDubFilter x64 fix (Update)


    Der Modul Test scheint zur Zeit nicht zu funktionieren, da immer noch alle Apps als "Unknown version" ausgegeben werden...
    Weißt du was da los ist?
    Siehe auch mein Screencast Video dazu: https://vimeo.com/164111384


    In StaxRip und vielen anderen Programmen mit ordentlicher Benutzeroberfläche gibt es unzählige Funktionen die man nicht auf Anhieb findet


    Hab die Interne Script Edit Zentrale für AviSynth und oder VapourSynth nun gefunden :D


    Hab ich vor ein paar Tagen upgedatet, Lib Datei ist jetzt auch dabei.


    Nun ist es so, das bei der Version 2.22 von ffms2,
    wenn man ein Video per AviSynth + FFVideoSource öffnen möchte,
    das es komplett Grün und auf dem Kopf dargestellt wird ;)
    In meinem Beispiel war es eine AVI mit dem Blackmagic MJPG Codec als 1080i
    Abhilfe schafft hier folgende Manuelle Script Änderung per Hand:

    Zitat

    FFVideoSource("C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi", cachefile = "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i_temp\BM Test Aufnahme 20160227 MJPG 1080i.ffindex",threads=1,colorspace="YUY2")


    Nach der Script Korrektur wird es im Preview Vorschaufenster von StaxRip korrekt ausgegeben :)
    Das threads=1 ist dafür da, das es bei 64-Bit Systemen zu keinem Decoder-Thread Überlauf kommen kann, der wohl Fehler produziert.


    StaxRip erkennt dieses Video an Hand seiner Header Informationen nämlich einwandfrei :)



    Wie schon oben beschrieben,
    fehlen zur Vervollständigung noch 2 Befehle im AviSynth Script bei FFVideoSource, damit es korrekt ausgegeben werden kann.
    Siehe auch mein neustes Screencast Video dazu:

    LigH


    MediaInfo --> http://img.xrmb2.net/images/888391.png (Vorsicht großes Bild)


    stax76


    Hier noch ein paar Aufälligkeiten zur der Stable Version von StaxRip_x64_1.3.4.0
    Hab zu den Fehlern jeweils kurze Screencast Videos erstellt...
    Vielleicht weißt du ja Rat?


    1.) Unter Apps / Status wird alles als "Unknown version" ausgegeben:
    Bei der Vorherigen Version: 1.3.2.2_beta von StaxRip_x64 war der Status auf
    OK in Ordnung.




    2.) https://vimeo.com/164111709

    Bei der Version 2.21 von ffms2, bekomme ich weiterhin folgende Fehlermeldung, wenn ich ein Video per AviSynth + FFVideoSource öffnen möchte.
    Und mit VapourSynth + ffms2 stürzt StaxRip ab :(




    3.) https://vimeo.com/164111956


    Bei der Version 2.22 von ffms2, ist soweit alles in Ordnung per VapourSynth + ffms2
    Wenn man ein Video nun per AviSynth + FFVideoSource öffnen möchte,
    wird es komplett Grün und auf dem Kopf dargestellt ;)


    Nach der Manuellen Script Korrektur unter VirtualDub wurde das Video korrekt ausgegeben :)

    Code
    1. FFVideoSource("C:\Videos\BM Test Aufnahme 20160227 MJPG.avi",threads=1,colorspace="YUY2",fpsnum=25)


    Mir ist an einem anderen Beispiel Video aufgefallen,
    das StaxRip bei manchen Videos den korrekten Farbraum automatisch findet und in seinen Scripts mit einbindet:
    z.B.

    Code
    1. LWLibavVideoSource("C:\Videos\Test123.mkv", format = "YUV420P8")


    Soweit wir das hier in diesem Beitrag
    http://forum.gleitz.info/showt…979&viewfull=1#post454979
    es schon soweit kurz angesprochen haben, sollte man bestimmte Befehle bei den "xSource" Quellen noch angeben,
    damit sie vom "Farbraum" und der "Framerate" richtig erkannt werden
    und unter Windows7 mit 64 Bit, sollte man noch einen Riegel auf
    "threads=1" setzen,
    da sonst fehler passieren können, wenn mehrere
    Decoder-Threads gleichzeitig laufen...


    Bis jetzt kenne ich nur 2 "xSource" Quellen bei dem man diese Parameter setzen sollte:


    FFVideoSource("inputVideo",threads=1,colorspace="XXX",fpsnum=XX)
    LWLibavVideoSource("inputVideo",threads=1, format = "
    XXX",fpsnum=XX)


    Das wird eine große Herausforderung werden zu jedem Video die passende:
    Framerate + ColorSpace inkl. ChromaSubsampling, automatisch erkennen zu lassen,
    so das sie per FFMS2 oder L-SMASH Source richtig angewendet werden.


    Könnte man vielleicht einen kleinen Script Editor in StaxRip für die Abarbeitungs Scripte einbauen,
    bevor StaxRip mit dem Encoding Process startet?
    So könnte man sich die Haupt Scripte noch mal anschauen und Notfalls vor der Abarbeitung von Hand selber korregieren :eagerness:
    Im Temp Ordner, den StaxRip automatisch erstellt, kann man sich zwar die Scripte
    noch mal ansehen
    und auch mit einem Text Editor bearbeitung nur dann, wenn man im StaxRip Programm auf ENCODING Start drückt,
    wird das geänderte Script nicht übernommen, sondern der Ursprung des jeweilgen Scriptes wieder hergestellt.

    Folgendes ist im letzten Test Build neu:


    Vielen Dank für das Update :)
    Die Tagen kommen noch ein paar kleine Fehlermeldungen aus der Stable Version von StaxRip_x64_1.3.4.0
    Bin gerade fleißig am testen ;)
    Erstmal eins nach dem anderen...


    Bekomme folgende Error Meldung bei der Umwandlung mit BeSweet rein...
    Die Audiospur ist: WAV in diesem AVI Container, die ich zu AAC / m4a umwandlen möchte!
    "eac3to" oder "ffmpeg" oder "qaac" verrichten ihre Arbeit sauber :)


    Was ist da los mit BeSweet unter Windows 7 / 64-Bit ?