Beiträge von LigH

    Man braucht keinen "Decoder für FDK-AAC", sondern nur einen Decoder für jegliches LC-AAC und HE-AAC, egal von welchem Encoder es erzeugt wurde, solange es spezifikationskonform gespeichert wurde.


    Zwar ist der xHE-AAC-Codec technisch effizienter als HE-AAC v1 oder v2. Leider speichert der Exhale-Encoder seine Ergebnisse nicht im herkömmlichen MPEG-Audio-Standard für LC-AAC (ISO/IEC 13818-3) oder HE-AAC (ISO/IEC 14496-3), sondern im moderneren USAC-Standard (ISO/IEC 23003-3).


    https://de.wikipedia.org/wiki/…d_Speech_and_Audio_Coding


    Um dieses neue Container-Format zu unterstützen, müsste also erst mal jemand diese Fähigkeit für libavcodec bzw. libavformat programmieren. Für foobar2000 gibt es einen "packet decoder", der nach diesen Audioblöcken auch in diesem USAC-Container suchen kann.


    https://forum.doom9.org/showthread.php?t=181381

    Tja, OpenSource-Player können nur abspielen, was an Spezifikationen öffentlich bekannt ist und von Freiwilligen implementiert wurde (wenn nicht gar die Entwickler wenigstens Decoder-Software bereitstellen).


    Als Encoder wird Exhale gerade von MABS unterstützt, aber deren Dateiformat war wohl nicht so verbreitet wie das, was im ISO-Base-Media-Standard üblich ist.

    Frage:

    Muss man die Bitrate nicht durch 6 Kanäle teilen. Ich gehe von DD 5.1 aus.

    Nein. Das liegt am "Channel Coupling", das bei AC3 technisch gut implementiert ist (bei MP2 ist es das nicht!):


    So wie es bei zwei Kanälen auch bei MP3 ein Mid/Side-Verfahren gibt (es werden Summe und Differenz encodiert, statt beide Kanäle direkt; die Summe mit höherer Genauigkeit, die Differenz fällt meist deutlich weniger ins Gewicht), so kann man auch mit mehr Kanälen vergleichbar arbeiten, es wird aber bei Surroundkanälen ein wenig komplexer mit der Hierarchie. Das Ergebnis ist, dass man schätzungsweise nur den Faktor der Quadratwurzel aus der Anzahl der Kanäle mit vollem Frequenzumfang an Bitrate braucht, im Vergleich zu einem Monokanal.


    Bei DD 5.1 braucht man also optimistisch nur etwa √5× die Bitrate, die für mono ausreichend wäre. Bei 5.1 mit 448 kbps entspräche das (nächst niedrigere konstante Blockbitrate) gut 192 kbps mono, bei 5.1 mit 384 kbps gut 160 kbps mono ... okay, das ist ziemlich optimistisch. Im Vergleich mit stereo wäre es realistisch.


    HQ-LQ :

    Dolby Digital ist für sich allein bis 640 kbps spezifiziert (ATSC-A/52-Standard), und auf Blu-ray kommt das auch vor. Aber die DVD-Video-Spezifikationen erlauben Dolby Digital nur bis 448 kbps.

    AAC arbeitet zwar effizienter, aber man sollte doch auf dem Ton-Niveau einer DVD bleiben.

    Der Ton mit einer variablen Bitrate ist eine Streitfrage. Sinn macht das nur, wenn man z. Bsp. ein Video mit langer Laufzeit, mit 3- oder 4-Stunden auf YT hochlädt. Das kann aber jeder so machen, wie er will, das Ist nur meine persönliche Meinung.


    Ich habe in den 17 Jahren für meine Kunden bei einer DVD, nie beim Ton eine variable Bitrate verwendet.

    Da sind auch nie Klagen über eine eventuelle schlechte Tonqualität gekommen.

    Ob eine Audiospur konstante oder variable Bitrate braucht bzw. verwenden darf oder muss, ist eine Frage der Spezifikationen des gewünschten Zielformates. Rein technisch ist die variable Bitrate bei Audio wie bei Video das natürliche Ergebnis für relativ gleich bleibende Qualität. Damit man keinen Qualitätsverlust bemerkt, muss nur genug Spielraum sein, um hinreichend akkurat zu encodieren.


    Wenn Audiospuren mit konstanter Bitrate erforderlich sind, hat das sicherlich technische Gründe, aber eben auch Nebenwirkungen: Solange der Encoder noch nicht gesättigt ist, kann die Qualität schwanken (vielleicht unhörbar, aber nachweisbar), und wenn er gesättigt wird, dann wird der Rest von der encodierten bis zur Ziel-Bitrate mit Füllbits verschwendet, nur um Spezifikationen zu erfüllen.


    Der MP4-Container unterstützt Audiospuren mit variabler Bitrate. Erst recht für AAC, das im Gegensatz zu MP3 von vorn herein für kontinuierlich variable Bitrate ausgelegt ist (MP3 meldet diskrete Bitrate-Stufen pro Audioblock).


    Die DVD-Video-Spezifikationen verlangen Tonspuren mit konstanter Bitrate. Da hast du keine Wahl, da muss großzügig bis verschwenderisch encodiert werden, auch wenn AC3 ebenso blockweise variabel sein könnte wie MP3. Was gibt es schöneres als Stille bei 448 (AC3) / 912 (MP2) / 1536 (LPCM) kbps? {SarcMark™}

    108 Kbps sind noch schlechter, als MP3 mit 128 Kbps.

    Das würde ich bei AAC nicht so pauschal sagen, da AAC (je nach Encoder-Implementation) erstens effizienter codieren kann als MP3 und zweitens meist auch in variabler Bitrate verwendet wird, also weniger in stillen Szenen verschwendet.


    Allerdings wundert mich, dass MediaInfo hier acht Tonspuren meldet: vier mit 108 bis 109 kbps (alle verschieden) und angeblich CBR, und dann noch mal vier mit je exakt 3375 bits pro Sekunde. Ziemlich unsinnig das ganze. Da hat wohl das Programm, das den MP4-Container erzeugt hat, Unsinn in den Header geschrieben. Oder wirklich merkwürdige Tonspuren. Von einem "Tipard TS Konverter" höre ich hier zum ersten Mal. Auf ffmpeg basierende Freeware hätte man sicher auch verwenden können.

    Zu kompliziert, für MPEG-2 gilt Generisches Seitenverhältnis: Ist das Bild in voller Breite sichtbar? Dann hast du entzerrt 576 * 4:3 = 768 Pixel. Das Pixel-Seitenverhältnis 1,094 gilt für ITU-R-Seitenverhältnis, dann wären aber nur 704 (bzw. 702) der 720 Pixel Breite mit interessantem Bildinhalt belegt.


    Bei 1080 Pixel Höhe hättest du also 1440 Pixel Breite.


    Bleibt nur die Frage: Lohnt sich das Upscaling überhaupt? Immerhin benötigt das Ergebnis viel mehr Bitrate, enthält aber nicht wirklich mehr Detailinformationen.

    Nun ja, Pixel vergleichen müssen sie alle erstmal; mit welcher Metrik sie die Unterschiede bewerten, ist dann die Frage.


    Auch wichtig zu wissen: Willst du u.U. Bilder unterschiedlicher Dimensionen vergleichen (z.B. HD mit SD)?


    Für solche Probleme gibt es in der Informatik eine eigene Abteilung. Entsprechend kannst du da u.U. auf typischen Programmierer-Diskussionsseiten auch Bibliotheken finden, die sogar verzerrte Bilder miteinander vergleichen können.

    Man könnte sich sowas in AviSynth zusammenbasteln, zwei Clips mit ImgSource, vergleichen mit Compare und evtl. SSIM; wichtig ist dabei aber, dass ein Ergebnisbild dabei ausgegeben wird (z.B. Subtract.Levels zur Visualisierung des Unterschiedes), damit der Graphbuilder nicht die Analysefilter verwirft, weil die keinen Clip erzeugen, der am Ergebnis beteiligt wäre.


    Die "Schweizer Offiziersmesser" für Bildverarbeitung an der Konsole wären ImageMagick oder GraphicsMagick. Die MSE-Metrik in den angegebenen Beispielen wäre da recht brauchbar für den Zweck.


    Hier noch eine witzige Seite: Prozentuale Abweichung zweier Bilder in vielen Programmiersprachen (RGB Durchschnitt, ungewichtet, wie bei Compare in AviSynth).

    Meiner Meinung nach ist das "Aliasing". Liegt daran, dass sich flache schräge Kanten durchs Bild bewegen und in jedem Frame bei der Aufnahme anders gesampelt wurden. Bei Quellen mit Interlacing merkt man das stärker. Vielleicht hilft in der Szene ein Filter, der speziell dagegen entwickelt wurde. Oder EDI Superresolution und Rückverkleinerung. Oder ein schwacher vertikaler Weichzeichner.

    Auch wichtig zu wissen: Welche VOB-Datei genau (Dateiname) - vielleicht ist es eine, in der nur ein Menü enthalten ist oder nur Navigationsinformationen? Oder du hast eine PGC extrahiert, in der nicht der Hauptfilm logisch enthalten ist, sondern nur Navigationshilfsstrukturen.


    Man sollte niemals eine VOB-Datei so verarbeiten, wie sie 1:1 von Disc kopiert wurde. Die meisten Konverter verarbeiten Filme auf DVD nur dann korrekt, wenn man vorher die logische Einheit "Hauptfilm" in eine zusammenhängende Datei extrahiert, und das erfordert Hilfsprogramme, die deren logische Struktur verstehen, welche in den IFO-Dateien hinterlegt sind.

    Korrekt geraten ... im dritten Bild: QTGMC, Bob. Wenn du die gleiche Framerate und Frameanzahl willst, nicht die Bob-Option verwenden, dann wird die Hälfte der Bilder weggeworfen.


    Und zur Sicherheit noch mal genau überlegen, ob du wirklich deinterlacen willst/musst. Man könnte auch interlaced encodieren. Wenn das Material überhaupt interlaced ist.


    Laut Dateiname sieht es aus, als wäre dein Material von einer Sportübertragung. Da ist Deinterlacing mit Bobbing eigentlich nützlich, um die Flüssigkeit der Bewegungen zu erhalten; 720p50 als Auflösung wäre u.U. kompatibel zu Blu-ray und DVB.

    *.avsi-Dateien sind keine Plugin-DLLs, die werden nicht mit LoadPlugin, sondern mit Import eingebunden (wenn sie nicht eh automatisch geladen werden, weil sie im passenden Verzeichnis liegen).


    Bei Dateien mit unkomprimierten Inhalten kommt es drauf an ... AVI-Dateien kann man mit AviSource laden, MP4-Dateien mit LSMASHVdieoSource/LSMASHAudioSource. Alles eine Frage von Container und Inhalt, lässt sich nicht pauschal für sämtliches Material beantworten.