Beiträge von Brother John

    richardbird schrieb:

    Bruder Johannes, womit hast du die Screenshots gemacht?


    Die Quelle ist das originale, verlustlose 1920×1080-PNG-Einzelbild. Der 1080p-Ausschnitt ist unverändert darauf gecroppt. Für die niedrigen Auflösungen habe ich mit (iirc) Lanczos3 runter und wieder rauf skaliert.


    Der Vergleich ist auch nur dazu gedacht, die verschiedenen Detaillevel zu illustrieren. Es war bewusst kein Encoding dabei. Codierartefakte vergrößern i.d.R. der Vorteil hoher Auflösungen. Man schaut ja im Vollbild und je kleiner die Auflösung, desto stärker muss man fürs Vollbild beim Abspielen hochskalieren. Dadurch werden auch Artefakte größer = besser sichtbar.


    Selur schrieb:

    Wobei in 5-10 Jahren, dir vermutlich 1910x1080 eh etwas niedrig vorkommt, dann sollte sich 4k ja langsam verbreitet haben


    Im Moment seh ich beim aktuellen FullHD grob die Grenze erreicht, was in einem normalen Wohnzimmer mit einem normalgroßen Bildschirm – sagen wir Hausnummer bis 50" – noch sinnvoll ist. Fürs extra Heimkino, wo die ganze Wand zur Leinwand wird, mag das anders aussehen.

    LigH schrieb:

    Beachte, dass 1920×1080 auf Blu-ray interlaced-encodiert sein muss


    Nur bei 25 und 29.97fps. 1080p ist für 24 und 23,976fps erlaubt.


    richardbird schrieb:

    Also sollte ich besser CRF-20 + 720p nehmen, um Blockbildung zu vermeiden?


    Ich hatte mich mal an einem Vergleich versucht, wieviel Bilddetail in die typischen Auflösungen reinpasst: http://encodingwissen.de/forma…und-bluray#icImgContainer
    Was dort deutlich wird, kann ich zumindest aus persönlicher Erfahrung bestätigen: Der Sprung von DVD auf 720p ist massiv, der Sprung von 720p auf 1080p sind im Vergleich Kleinigkeiten. Einfach beim Anschauen fällt mir auch auf dem großen dicken neuen 46"-Fernseher kein wesentlicher Unterschied zwischen 720 und 1080 auf.


    Für Langzeitarchivierung würde ich trotzdem lieber ein paar GB mehr verbraten und bei 1080 bleiben. Jetzt mit großem Aufwand 720p-Versionen herzustellen und in 5–10 Jahren festzustellen, dass die vollen 1080p inzwischen doch ganz nötig wären? Nee, da könnte ich nicht ruhig schlafen. :)

    Und: es gibt schon Blu-rays mit HD 11.1 Ton. Alles Gimmick? :-)


    Definitiv. Blu-ray-Audio ist bis maximal 8 Kanäle spezifiziert. Mehr kann also maximal gematrixt sein. Aber:

    von Selurs Link schrieb:

    The Neo:X algorithm can take anywhere from 2.0 to 7.1 channels of input and offers a 9.1 channel or 11.1 channel conversion.


    Das klingt nichtmal nach Matrix, sondern danach, dass sich ein Algorithmus einfach zwei oder vier zusätzlich Kanäle ausdenkt. Ist also genau so eine Wundertechnik wie die Bildschirme, die aus einer DVD brilliantestes 1080p herrechnen.


    Edit: Beim nochmal drüberlesen: Meinen die da wirklich unter anderem eine 2.0->11.1-Konvertierung? Das wär ja so dermaßen lächerlich!


    Ohne eigenes Heimkinozimmer ist es imo müßig, über mehr als 5.1 überhaupt nachzudenken. Mindestens muss man dann ganz genauso auch über die Raumakustik nachdenken. Aus meiner eigenen Erfahrung: der Sprung von Stereo auf Stereo + Front Center ist deutlich. Die Dialoge kommen damit einfach viel klarer rüber. Hinten noch zwei Boxen dranzuhängen, hilft bei manchen Filmen in den richtigen Szenen für einen zusätzlichen Kick. Aber im Vergleich zum Center ist das schon eher Zusatzluxus. Noch mehr Kanäle? OK, bringt nochmal ein paar Nuancen. Aber ist das wirklich relevant?


    OT: Beim Bild haben wir den Effekt ja auch. DVD->720p ist ein massiver Unterschied, 720p->1080p liefert ein paar Nuancen mehr fürs extraknackige Bild. Aber wirklich entscheidend ist das nicht mehr.

    Servus zusammen!


    Eigentlich wollte ich nur meine gruselig veraltete BeSweet-basierte Audio-Transcoding-Batchdatei erneuern. Irgendwie ist das dann gewachsen, so wie »Ich hack mir mal schnell«-Projekte halt wachsen.


    Herausgekommen ist ein Pythonskript, das per FFmpeg Audio frisst und incl. Logdatei und auf Wunsch ein bisschen Processing mit Qaac, Nero AAC, Oggenc oder FFmpeg-FLAC. encodiert. Ich würde mich über Feedback freuen, und vielleicht ist es ja für den einen oder anderen wirklich nützlich.


    Hier ist der Hilfetext:

    Code
    1. Audio Transcode Script v1.0 by Brother Johnan implementation of the FFmpeg/SoX approachUsage:aenc inputfile {qaac|naac|vorbis|flac} {highest|high|low|lowest} [--2ch] [--PALspeeddown] [--force-norm|--no-norm]Encoders qaac Qaac naac Nero CLI vorbis Vorbis (Oggenc) flac FLAC (FFmpeg)Profiles Qaac Nero AAC Vorbis FLAC highest TVBR 75 Q 0.31 Q 4.0 Level 8 high TVBR 50 Q 0.25 Q 3.0 Level 6 low CVBR 160 HE Q 0.18 Q 2.0 Level 5 lowest CVBR 80 HE Q 0.15 Q 0.0 Level 4--2ch, --stereo Forces stereo output instead of source channel count.--PALspeeddown Reverses a usual PAL speedup, i.e. slows down the track by 4% affecting both runtime and pitch. This corresponds to changing the video speed from 25fps to 24fps.--force-norm Force normalisation even for lossless to lossless transcoding. Usually normalisation only runs when at least one of the input and output formats is lossy.--no-norm Disable normalisation.WARNING: When you do a lossloss to lossless encoding (e.g. TrueHD to FLAC) andwant to ensure true losslessness you must not use any processing like changingthe number of channels, audio speed or even normalisation.


    Download: https://bitbucket.org/BrotherJ…/raw/b248d04affad/aenc.py


    Ich werde es früher oder später vergessen, den Link zu aktualisieren. Das Skript liegt auf Bitbucket. Wer aktuell bleiben will, clont sich am besten das Repo.

    Code
    1. hg clone https://bitbucket.org/BrotherJohn/avtools


    Python 3.x ist nötig.


    Edit:
    Man kann auch eine Konfigurationsdatei (aenc.ini) anlegen, um die Pfade zu den externen Tools anzupassen; und zwar nach dem Muster:

    Code
    1. ffmpeg=C:\Pfad\zu\ffmpeg.exe
    2. sox=D:\Keine Quotes\trotz Leerzeichen\sox.exe
    3. qaac=relativer Pfad\ist relativ\zum Skript selbst\qaac.exe
    4. naac=E:\neroaacenc.exe
    5. vorbis=oggenc


    FLAC nutzt FFmpeg, weil man Standalone FLAC nicht per Pipe mit Daten füttern kann, ohne manuell sämtliche Parameter des Audiostreams anzugeben. Deswegen gibt es auch keinen extra flac=-Eintrag.

    De-M-oN, Xdar, bevor das hier ausartet und der Schlüsselbund kommen muss: Ich schlage vor, ihr einigt euch auf eine gemeinsame Quelle und testet mit der eure Youtube-»Preencoding«-Setups. Verschiedene Videos zu vergleichen, ist vollkommen aussagelos, weil unklar bleibt, welche Effekte auf die unterschiedliche Quelle zurückzuführen sind und welche tatsächlich auf unterschiedliche Encodereinstellungen.

    Ja, DVDs sind aufwändiger in der Herstellung (und deshalb anfälliger für Billigproduktion), weil die Datenschicht zwischen zwei Plasikscheiben »eingesandwicht« ist; im Gegensatz zu CDs, die nur Scheibe mit Datenlack oben drauf sind. Die Blu-ray hat btw in der Hinsicht mehr die CD als Vorbild.


    Davon abgesehen ist langfristige Haltbarkeit an sich keine der hervorragenden Eigenschaften von brennbaren optischen Medien. Mit gutem Gewissen kannst du den Scheiben ein paar Jahre geben, vielleicht ein Jahrzehnt; und stark schwankend noch dazu. Wenns langfristig und erschwinglich sein soll, führt imo an Festplatte+Festplatte oder Disc+Festplatte oder einer ähnlichen Kombi kein Weg vorbei.

    Zitat

    Was bringt mir diese Command Line?


    Nichts. Benutze --preset und --tune. Alles andere nur dann,wenn du einen konkreten Grund dazu hast und auch verstehst, was du da tust.


    Dieses Youtube-Video ist entweder total veraltet oder Müll. Wahrscheinlich beides.

    Mir wurde in einem anderen Forum wiederum gesagt, dass beim 2pass die Bits besser platziert werden als bei nur einem Durchgang.


    Besser als 1-Pass Bitrate: ja. Besser als 1-Pass CRF: nein. 2-Pass und CRF benutzen die selbe Rate Control, d.h. ein CRF-Encoding ist qualitativ praktisch identisch zu einem gleich großen 2-Pass-Encoding.


    Nimm Pi-mal-Daumen einen CRF-Wert, der »gut genug« ist, dir die Upload-Zeiten nicht ins Unendliche treibt und encodiere mit dem langsamsten Preset, das du zeitlich akzeptieren willst. Das könnte auf sowas wie CRF 16-18 und --preset slow oder slower rauslaufen. Alle Feinheiten sind wg. der erzwungenen Recodierung eh egal. Youtube kriegt heutzutage zwar recht brauchbare Qualität hin, aber das Endergebnis *wird* schlechter sein als dein Encoding vor dem Upload.

    Selur, du sprichst mir aus der Seele. :)


    Besonders skeptisch bin ich dann bei dem hier geworden:

    http://lib-ray.org/spec.html schrieb:

    Lib-Ray is essentially a "multimedia website on a disk"


    Ein auf einem physischen Datenträger basierendes Format etablieren zu wollen, halte ich für zum Scheitern verurteilt. Datenträger sind hauptsächlich für die Wohnzimmer-Hardware interessant. Ohne dicke Industrieunterstützung auf die Geräte kommen zu wollen, ist … mutig. Ob das alternativ über die Anime- oder Pornoschiene was werden kann, bin ich auch skeptisch. Die beiden waren schon immer eher vorne dabei bei neuer Technologie, und der Trend geht weg vom Datenträger und hin zum Netz als Verbreitungsmedium.


    Wenn Datenträger aber uninteressant(er) werden, dann hat ein Format, das aus einem ganzen Dateizirkus besteht, echte Nachteile. Nervig zu handhaben und störanfällig – es werden Dateien weggkommen.


    Das Unbehagen bei HTML5 hab ich genauso. Ich würde es ja noch verstehen, wenn Lib-ray einen Qualitätsstandard für Web-Video im Browser bauen wollte. Das ist dann aber nicht mehr »on a disk«, sondern »on the web«. ;) Dort kann ich mir Lib-rays Zukunft schon eher vorstellen. Und das wäre ja auch ein schöner Erfolg.


    Interessant ist es auf jeden Fall. Ihr 19000$-Ziel haben sie ja erreicht. Mal sehen, was wir davon haben.


    Selur schrieb:

    2. der Player den sie verwenden muss auch brauchbar sein (oder nutzt hier wer den OSMO4 Player um MP4-Menus zu nutzen?)


    Imo hängt die Akzeptanz nicht zuletzt davon ab, dass lib-ray stressfrei auf den großen plattformübergreifenden Playern – also VLC und mplayer – läuft und auf den üblichen Playern der jeweiligen Plattformen – also unter Windows mindestens WMP und empfehlenswerterweise MPC HC, um die Videoenthusiasten mit abzuholen. Mit Python bin ich deswegen skeptisch, weil mir unter den Voraussetzungen eine solide Backend-Library am sinnvollsten vorkommt, die sich ohne Megaaufwand an die verschiedenen Player anbinden lässt. Dafür ist Python sicher nicht die ideale Sprache.

    LC AAC ist sozusagen der »normale« Umfang von AAC. Dann gibts oben drauf eine Technologie namens SBR (spectral band replication): LC+SBR heißt HE-AAC oder AAC+, AAC plus o.ä. Nochmal oben drauf gibts eine Technologie namens PS (parametric stereo): LC+SBR+PS heißt HEv2 – obs analog ein »superplus« ;) oder so gibt, weiß ich nicht aus dem Kopf.


    Fürs Matroska-Muxing ist aber nur wichtig, ob reines LC vorliegt oder nicht.

    Xvid YV12 hat auch mit bestimmten Crop-Werten einen sichtbaren Bug. Zumindest war das zu 1.2.x-Zeiten so. Weiß nicht, ob das seitdem behoben wurde. Jedenfalls ist ein anderer Decoder kein Fehler. Der von deinem Link, der Helix YV12 oder ffdshow. Obwohl ffdshow sich auf eine Art und Weise im System verankert, die StaxRip nicht immer richtig erkennt.

    H264x
    Wie viele Leute sollen es dir denn noch in kleinschneiden, vorkauen und füttern, bis du endlich mal auf die Idee kommst, selbst auszuprobieren? Tipps und Erklärungen hast du bis zum Abwinken bekommen. Deinen Hintern in die Höhe resp. die Finger an die Tastatur musst du schon selbst bekommen.


    Um der zwölftausendsten Rückversicherung vorzubeugen, ist hier dicht.


    edit: Huch, der Thread ist ja gewandert, ich darf ja gar nicht mehr absperren. Muss sich gerade überschnitten haben. OK, dann versteht das bitte als meine Empfehlung fürs weitere Vorgehen. ;)