Beiträge von jones1913

Super daß du hier vorbeischaust stax, da kann ich es mir sparen mein Anliegen umständlich auf englisch zu verfassen :cool:.

Folgendes: Wenn ich mit der neuesten Version ein AVS Script lade (source auf automatik, standard x264 template) welches Video und Audio per LWLibAVSource bereitstellt,
dann ploppt bei einigen Bearbeitungsschritten immer wieder das Statusfenster mit der Meldung "Index LWLibavVideoSource" auf:

- direkt nach dem laden des Quellscripts 2x
- beim aktivieren/deaktivieren von Avisynth filtern
- beim aufrufen/schließen des crop Dialogs
- wenn man den Job startet

Beim laden eines Scripts welches einen anderen Quellfilter, zb. DirectshowSource enthält, passiert das nicht.

Gute Anleitung, sowas hab ich auch mal eine Zeit lang genutzt. Das macht aber nur Spaß mit nem ausreichend schnellen USB Stick sonst wird jede Softwareinstallation und jedes Systemupdate zur Geduldsprobe.

Jedenfalls, wenn man öfter mal USB Sticks in Virtualbox als Festplatte einbinden will, gibt es ein Tool was das ganze etwas vereinfacht:

http://reboot.pro/files/file/339-virtual-machine-usb-boot/

Ich hab vor kurzem mal versucht den QTGMC mit AVS+ MT zum laufen zu kriegen. Und er lief, aber dummerweise nur mit 1/3 der Geschwindigkeit von AVS 2.6 MT.
An Plugin .dlls hatte ich mir die neuestem MT-fähigen Versionen rausgesucht und die ganzen SetFilterMTMode() Anweisungen, wie von Ultim empfohlen, per Autoload-Script eingebunden.
Aber weil das Ergebnis so schlecht war hab ich mich dann nicht mehr weiter damit beschäftigt. Vieleicht lags nur an einem Plugin was mit AVS+ nicht ganz rund läuft...

Zitat von H264x

Es gibt ein geniales & günstiges Videoschnittprogramm für 12,48€ gerade im Angebot, namens: Xilisoft Video Cutter,
womit man Videos Verlustfrei (inkl. SmartRendering Technologie?) schneiden kann...
Die OTR Videos, funktionieren damit einwandfrei. Nochmal danke an Goldwingfahrer, fürs Testen.
Werde es erst später im laufe des Tages, selber ausprobieren können!

Wenn du OTR-Videos (oder generell AVIs mit H264 oder xVid drin) schneiden willst warum nimmst du dann nicht Cutana?
Das wird mehr oder weniger aktiv weiterentwickelt (der Autor arbeitet gerade an einer Cross-Platform Version),
ist Freeware (aber nicht Open Source) und ist ein guter Ersatz für ColdCut. Zum schneiden benutzt wird x264vfw und xvid mit VirtualDub.

Gubel
Gute Zusammenfassung.
Auch wenn mich das Thema hier an sich nicht so sehr interessiert, macht es doch Spaß solche detaillierten Artikel zu lesen.

Ab jetzt können mehrere Dateien oder Verzeichnisse gleichzeitig geöffnet werden:

http://www.mediafire.com/folder/qc84j3132cvnp/BeHappy

Auf das Extension-System hab ich nur mal einen kurzen Blick geworfen.
... ist schon ziemlich "ausgefeilt", aber ich werd mir was überlegen.

Ich denke mal wenn man einen Schieberegler in das Konfigurationsfenster reinquetscht müsste das ausreichen.
Mit den Radiobuttons wählt man einen Modus (CBR, VBR..) und mit dem Regler den Wert.

Dropdown Menüs oder Checkboxen sind natürlich sinnvoll um gewisse globale Einstellungen anzuzeigen, aber je mehr Elemente man aus der xml lesen,
dem Fenster dynamisch hinzufügen, sinnvoll anordnen und mit Werten füllen muss, desto komplizierter wird das alles auch.

Ich werd demnächst noch mal drüberschauen, vieleicht geht es einfacher als gedacht. Aber ich verspreche erstmal nichts :cool:.

Zitat

Was gleich irgendwie als "noch fehlend, bitte implementieren" auffällt: Wenn man schon Multithreading nutzen will, um mehrere Audiodateien zu konvertieren, möchte man vielleicht auch gleich den gesamten Inhalt eines Verzeichnisses, oder wenigstens mehrere ausgewählte Dateien...

Darauf hatte ich auch schon einen Blick geworfen, habs dann aber vorerst sein gelassen, weil der gesamte Quellcode konsequent auf single-job erstellung und abarbeitung ausgerichtet ist.
Ich werd mir etwas überlegen, wie man das umsetzen kann ohne allzu viel in der GUI zu verändern.

Zitat

Vielleicht kriegst du noch L-SMASH Works (LwLibavAudioSource) und QAAC unter (seit kurzem unterstützt QAAC auch avs-Dateien direkt per AviSynth Interface). Störend bei L-SMASH Works könnte lediglich sein, dass Indexdateien erzeugt werden, wenn das nicht explizit verhindert wird (cache=false).

Mit dem Plugin-System hab ich mich noch gar nicht weiter beschäftigt. Die oben genannten existieren ja bereits als Extensions.
Störend sind natürlich die halbe Milliarde RadioButtons beim QAAC Plugin. Das würde sich schon lohnen das als natives Encoder Plugin einzubauen.
Alternativ könnte man auch das Extension-System erweitern um Schieberegler...

Danke soweit für die Rückmeldung.
Dann werd ich das heute Abend mal im englischen doom9 reinstellen.

Und hat schon jemand getestet?
Ich war mir anfangs nicht sicher ob es eine gute Idee ist, AviSynth Skripte parallel laufen zu lassen.

Sind da (theoretisch) Probleme zu erwarten? Kommt das vielleicht drauf an ob das Quellfilter Plugin thread-safe ist oder so?

Zitat

Wenn du dich noch nicht mit dimzon abgesprochen hast, ob deine Änderungen vielleicht mal in das ursprüngliche Projekt übernommen werden, wäre es möglicherweise besser, deine Variante auch erst mal unter einem eigenen Namen (z.B. "BeHappy-MT") anzubieten, denke ich.

MT währe wohl etwas irreführend, da das ganze nichts mit der AviSynth-MT Implementierung zu tun hat.
Es werden ganz einfach nur mehrere AviSynth Skripte parallel gestartet mit dem dazugehörigen Encoder hinten dran.

In letzten 4 Jahren hat offenbar keiner mehr daran gearbeitet und ich wusste anfangs nicht, ob das was ich vorhab überhaupt zu einem Resultat führt.
Deshalb hab ich keinen Sinn darin gesehen mit irgendjemandem vorher darüber zu reden und das an die große Glocke zu hängen.

Letztens hab ich mal ein paar Tonspuren mit BeHappy umgewandelt und da ist mir aufgefallen, dass das doch relativ lange dauern kann, während sich mein Achtkernprozessor mit ~15% Auslastung quasi langweilt.
Mehrere BeHappy Instanzen gleichzeitig laufen lassen funktioniert zwar, ist aber unbequem zu handhaben.

Also hab ich kurzerhand die Möglichkeit eingebaut, die Jobs parallel abzuarbeiten. Im Idealfall läuft das ganze nun deutlich schneller ab unter Auslastung mehrerer Rechenkerne.
In meinen Tests konnte ich keine Stabilitätsprobleme feststellen, es scheint soweit unproblematisch zu sein.

Nebenbei hab ich gleich noch die GUI ein wenig modernisiert und ein paar Nervtöter rausgeschmissen oder verbessert.
(zB. die sinnfreien Kontext-Menü-Buttons, das zu kleine Log-Fenster, der monströse Preview-Button...)

Rückmeldungen über Stabilität oder Bugs wären super...

Zwischenablage-2.pngZwischenablage-7.png

DL: http://www.mediafire.com/folder/qc84j3132cvnp/BeHappy

HappyEncoding!

Die Angaben im x265 wiki wurden inzwischen etwas präzisiert.

Kurz gesagt, wenn man das:

SET(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER   x86_64-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)
SET(CMAKE_ASM_YASM_COMPILER yasm)
SET(CMAKE_CXX_FLAGS "-static-libgcc -static-libstdc++ -static -O3 -s")
SET(CMAKE_C_FLAGS "-static-libgcc -static-libstdc++ -static -O3 -s")
SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "-static-libgcc -static-libstdc++ -static -O3 -s")
SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "-static-libgcc -static-libstdc++ -static -O3 -s")

in die cmake Konfigurationsdatei schreibt bekommt man eine fertig statisch gelinkte und gestrippte .exe serviert.

Der make Aufruf verkürzt sich damit drastisch auf:

cmake -DCMAKE_TOOLCHAIN_FILE=config-file.cmake ../../source

Hach, wenn doch nur alles so einfach wäre... :ani_lol:

Zitat

was zeigt MediaInfo bei echtem MVC an?

Also die Zeile "Format-Profil : Stereo High@L4.1 / High@L4.1" weist auf jeden Fall auf MVC hin.
Ist zumindest bei den paar MVC-Schnipseln die ich hier hab auch so.

Ansonsten ist mir eigentlich kein Fernseher bekannt der MVC vom USB-Laufwerk direkt wiedergeben kann.
Half-SBS ist da meistens das Maximum (wenn überhaupt).

da der Download Link tot war, nutze ich die Gelegenheit für ein Mini-Update:

Zitat

0.60
- added new drag and drop field "extract audio to mp4"

Dachte strippen ist schon im Buildprozess mit drin, wieder was gelernt. :rock:
32bit Version bauen funktioniert jetzt auch, ka was da anfangs alles schiefgelaufen ist.
Lohnt sich aber fast gar nicht mehr, kriegt man ja schon an jeder Ecke hinterhergeschmissen die builds (sogar meine Mutter kompiliert den Kram schon ).

Übrigens:

strip --strip-all x265.exe && upx -9 -v -k --brute x265.exe

603.648 Bytes (64bit)

Wer bietet weniger? :D:D:D

Die option "static-libgcc" war das Problem, mit nur "-static" funktioniert es.
Komischerweise funktioniert es nur mit Konfigurationsdatei, wenn ich die ganzen Parameter an der bash mit übergebe schlägt das ganze immer fehl ... egal.

Also so gehts bei mir:

cmake -G "Unix Makefiles" -DENABLE_SHARED:BOOLEAN=OFF -DCMAKE_CXX_FLAGS="$CXXFLAGS -static" -DCMAKE_C_FLAGS="$CFLAGS -static" -DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake ../../source

"toolchain-x86_64-w64-mingw32.cmake" in "x265/build/linux" :

SET(CMAKE_SYSTEM_NAME Windows)SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)SET(CMAKE_RANLIB x86_64-w64-mingw32-ranlib)SET(CMAKE_ASM_YASM_COMPILER yasm)

Die .exe ist zwar knapp 9MB groß, aber lässt sich starten. Müsste vieleicht noch komprimiert werden oder so...

x265 [info]: HEVC encoder version 0.9+125-84d31cb2aeab
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1

*Hüstel* Funktions- und Speedtests stehen übrigens noch aus

Stimmt, hab jetzt auch gesehen, daß x265 cmake verwendet.

Da ich mich zur Zeit für meinen neuen stromspar-PC wieder mal mit Linux beschäftige hat mich das jetzt auch mal interressiert.

Die Prozedur ist sogar im x265 Wiki beschrieben.
Also entweder die cross-Parameter per Konfigurationsdatei übergeben oder in der Kommandozeile.

Dummerweise führt die beschriebene Vorgehensweise bei mir immer zu folgender Fehlermeldung:

-- cmake version 2.8.12.2-- The C compiler identification is GNU 4.8.2-- The CXX compiler identification is GNU 4.8.2-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc -- brokenCMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message):  The C compiler "/usr/bin/i686-w64-mingw32-gcc" is not able to compile a  simple test program.  It fails with the following output:  /usr/bin/i686-w64-mingw32-gcc  CMakeFiles/cmTryCompileExec1890825961.dir/testCCompiler.c.obj -o  cmTryCompileExec1890825961 -rdynamic  i686-w64-mingw32-gcc: Fehler: nicht erkannte Kommandozeilenoption  »-rdynamic«

Keine Ahnung ob es an der 32bit mingw Version liegt...

Ich hab dann einfach die "toolchain-x86_64-w64-mingw32.cmake" aus "x265/build/msys" nach "x265/build/linux"
kopiert und dann hats so funktioniert:

cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake ../../source

wenn man die dll nicht braucht dann geht auch:

cmake -G "Unix Makefiles" -DENABLE_SHARED:BOOLEAN=OFF -DCMAKE_CXX_FLAGS="$CXXFLAGS -static-libgcc" -DCMAKE_C_FLAGS="$CFLAGS -static-libgcc" -DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake ../../source

Ein kurzer Versuch die .exe unter Windows zu starten scheiterte aber kläglich mit "unable to load libgcc-1.dll" oder so ähnlich.
Wahrscheinlich stimmt da noch was nicht mit den cmake Parametern.

Du brauchst ein cross compiler environment zb. "mingw-w64".

In manches Distros ist das in den Paketquellen zu finden, oder man baut sich das selbst zb. von hier.
Kompiliert wird dann mit dem Konfigurationszusatz "--cross-prefix=i686-w64-mingw32-".

Hier ist das ganze an FFmpeg etwas genauer beschrieben. Prinzipiell sollte sich diese Vorgehensweise auf x265 übertragen lassen.

Die A-Serie Prozessoren mit integrierter Grafikeinheit und max 4 CPU-Kernen sind halt eher für Büro und Multimediaanwendungen, Gaming usw gemacht.

Laut den bisher veröffentlichten AMD Roadmaps werden die die aktuellen FX CPUs noch mindestens bis 2015 die Stellung halten.
Die FX-8xxx CPUs sind aber mM nach noch hervorragend für Videoencoding geeignet und haben bei x264 Benchmarks immer die obersten Plätze belegt, nur geschlagen durch x-fach teurere Intel Modelle.

Der etwas höhere Energieverbrauch spielt eigentlich nur eine Rolle, wenn man den Rechner rund um die Uhr unter Vollast laufen lässt.
Dann bräuchte man wohl eine Amortisationsrechnung oder sowas.

Zitat

Was ist der Unterschied ob ich 1920x1080 von einer Satanlage oder vom PC sende ? Wenn über HDMI angeschlossen sollte das gleich sein. Es ist nur die Frage ob am PC (Grafikkartendriver/Scalieroptionen) und TV(Pixelgenau/scalieren) alles richtig eingestellt ist.

Es geht um die interne Bildaufbereitung die jeder(?) moderne Fernseher heute hat.
Ein PC Monitor stellt das Eingangangssignal unverfälscht dar, was zu einem scharfen Bild führt, gut geeignet für Textdarstellung, graphische Benutzeroberflächen, Desktop, Bildbearbeitung usw.

Ein Fernseher hingegen hat integrierte Bildprozessoren in Hard- oder Software welche das Signal speziell für die Videowiedergabe aufbereiten
zb. Kompressionsartefakte glätten, Interlacingstreifen ausbügeln, Helligkeit und Kontrast anpassen, Bildwiederholungsrate vervielfachen und noch weitere "Verbrechen" :D.

Das führt dazu, daß SD-Videos an meinem 40" TV viel besser aussehen als an meinem 22" PC Monitor obwohl das Bild am TV stärker gestreckt wird.

Das Eingangssignal per HDMI oder DVI ist in der Tat immer gleich, egal von welchem Zuspieler.

Zitat

Ich hoffe ich werd nicht wieder von Bug-Reports erschlagen...

Ähm.. das war übrigens nicht ernst gemeint, ihr wisst schon Humor und so...

Also nicht so zurückhaltend..

Und danke an LigH für die Titeländerung.:daumen:

Zitat

Als PC-Monitor ist ein LCD-Fernseher aber nur eingeschränkt verwendbar. Man merkt schon eine gewisse Unschärfe, besonders bei feinen Strukturen (z.B. Texten) mit roter Farbe. Trotz DVI/HDMI-Anschluss. Scheint also wohl in der internen Bildaufbereitung zu liegen.

Die interne Bildaufbereitung ist bei Desktop- und Textdarstellung auf jeden Fall störend.
Bei manchen Herstellern gibt es Optionen die Signalprozessoren zu deaktivieren, aber selbst wenn es solch eine Funktion gibt ist es oft nur unzureichend dokumentiert.

Wieder das Beispiel Samsung (nur um das zu verdeutlichen):
- die Auflösung des Eingangssignals muss genau 1920x1080/60 betragen
- es funktioniert nur an einem bestimmten HDMI-Eingang
- der Name des Eingangs muss in einem Unscheinbaren Menü auf "PC" geändert werden

Auf diese Anleitung bin ich auch nur zufällig in einem Forum gestoßen, offiziell dokumentiert ist das soweit ich weiß nirgends.

Zitat

Ja, ein RaspberryPi ist mit seinem 700MHz-Prozessor relativ schwach. Gerade bei 10-bit-x264 braucht man aber genug CPU-Power, weil die Hardwaredecodierung nicht so richtig klappt (bei 8bit schon). Einen quadcore-1,6GHz-Android-mini-PC bekommt man schon ab ca. 60€ und ist eine leistungsfähige Alternative.

Der Raspberry ist nur eine Übergangslösung (war ein Geschenk) und mit den Android TV Boxen hab ich schlechte Erfahrungen gemacht.
Mir kommen auf jedenfall nur noch Lösungen ins Haus bei denen ich freie Hand bei der Wahl des Betriebssystems habe, egal ob ARM oder x86 basierend.

Für den nächsten Mediacenter PC hab ich die AM1 Plattform von AMD im Blick, welche Ende des Monats starten soll und günstige Mainbords sowie Prozessoren verspricht.