Beiträge von LessThanJake

  • JM H264 Referenzencoder / -decoder kompilieren

    Ich versuche zu verstehen, wie man einige NALUs richtig decodiert.
    Das steht zwar alles in dem ITU Dokument, aber das ist da teilweise nicht immer so einfach zu verstehen, daher möchte ich den Output des Tracefiles von ldecod zusätzlich zum Verständnis heranziehen. :)

    Ein Tracefile-Beispiel davon gibts hier, falls du das noch nicht kennst (was ich mir fast nicht vorstellen kann ;)).
    http://forum.doom9.org/showthread.php?p=1079181#post1079181

    greets
    LTJ

  • JM H264 Referenzencoder / -decoder kompilieren

    Hallo,

    hat schonmal jemand versucht und geschafft den JM H264 Referenzencoder und -decoder zu kompilieren?

    http://iphome.hhi.de/suehring/tml/download/

    Laut Dokumentation muss, wenn der GCC verwendet wird zuerst "./unixprep.sh" und dann einfach "make" ausgeführt werden, allerdings bekomme ich da immer folgende error:

    Sieht ein bißchen so aus als fehlt irgendein Assembler-Compiler(?).

    Mir geht es um die Trace-Funktion des Decoders, die würde ich gerne mal testen. Wenn man in der Datei "defines.h" im Ordner ..\JM\ldecod\inc die Funktion aktiviert (einfach den Wert von 0 auf 1 setzen), wird dieses Feature mit kompiliert. Zumindest theoretisch, wenn es denn überhaupt kompiliert :hm:.

    Könnte das mal jemand testen? (Lord_Mulder? Du hast doch auch ein GCC-Setup. :zunge:).

    greets
    LTJ

  • Das Rauschen bei H.264 Umwandlung erhalten ?

    Zitat von LoRd_MuldeR

    Slices sind auch vollständige Frames, das hat ja nichts mit "interlacing" zu tun.
    Es geht lediglich darum, dass bestimmte Teile des Frames unabhängig voneinander und somit parallel decodiert werden können.
    Und wenn man sagt "ohne" Slices zu arbeiten, dann heißt das, dass man genau 1 Slice verwendet.

    Dass das nichts mit Interlacing zu tun hat, ist mir klar. Falls aber mehrere Slices vorhanden sind, was der H264 Standard ja erlaubt, brauche ich trotzdem alle um ein vollständiges Bild dekodieren zu können, egal ob die Slices unabhängig voneinader dekodierbar sind oder nicht. H264-Visa zeigt das x264 und der Mainconcept-Encoder nur Fullframesslices erzeugen. Mich interessiert, ob das die Regel ist und überhaupt, wo man das im Bitstream auslesen kann. Aber das gehört ja eigentlich alles ganicht hier in den Thread. Sorry lieber Threadersteller, ich möchte hier nicht vom Thema ablenken. :redface:.

    greets
    LTJ

  • HCEncoder richtig einstellen um Blockartefakte zuvermeiden

    Zitat von jackieninos

    Wie erkennst du es das sie kleiner als 8 pixel sind?

    1. Sieht man das, wenn man reinzoomt
    Ausschnitt aus dem HD-Screenshot 1000% vergrößert: Klick

    (Btw. Es gibt nach der ITU-T Rec H.264 auch 4x8 / 8x4, die beiden als Achterblock markieren Quadrate rechts sehen nach 2mal 4x8 aus. Verwendet x264 intern also auch 4x8 / 8x4 Submacroblockpartitionierung?

    2. steht in den settings "analyse=0x3:0x133" und das entspricht der x264-option "-A all", also sind auch 4x4 Macroblocks enthalten.

    Wie schon bereits erwähnt, die Quelle ist schon Mist und da kann Deblock_QED auch nicht zaubern.

    greets
    LTJ

  • slit-scan in AviSynth?

    Hallo,

    1. Verstehe nicht was du genau damit meinst
    2. Den AE Timedisplacement-Effekt kann man mit etwas Zeit ganz bestimmt als eigenes C/C++-Plugin oder als AVISynth-Script realisieren. Vielleicht versuche ich das mal, wenn ich Lust habe.
    3. Das ist mir zu hoch :hm:

    greets
    LTJ

  • x264 - Lossless Encoding

    Hallo,

    x264 ermöglicht mit -qp 0 verlustloses Encoding.
    Wie wirken denn dann die ganzen übrigen Einstellungen?
    Ich kann mit MeGUI als Frontend immer noch alle anderen Einstellungen tätigen, wie bspw. unterschiedliche Profil- und Levelbeschränkungen, Makroblock-Optionen, B-Frames, eben einfach alles, wie sonst auch.
    Warum sind gerade die Optionen zur Bewegungsabschätzung und die Quantisierungsoptionen nicht ausgegraut?
    Warum sollte man weitreichend nach Bewegung suchen lassen, wenn doch sowieso nicht quantisiert wird? Verlustlos ist doch verlustlos, ohne wenn und aber oder doch nicht?
    Erleuchtet mich doch bitte mal :).

    greets
    LTJ

  • DeBlock_QED filter richtig einbinden

    Zitat von LigH

    Und ein Schnipselchen Testmaterial wäre immer gut. Jetzt überlege ich bloß, wie man AVC schneiden kann... :grübeln:

    Quick und nicht dirty sondern ganz sauber aber nicht komfortabel ohne Vorschau von IDR zu IDR für ein AVC-RAW-Stream (x264-encodet), so wie ihn DGAVCDec akzeptiert:

    • Hex-Editor starten -> AVC-RAW-Stream öffnen
    • Per C&P SPS und PPS NALUs in ein leeres Hex-File einfügen.
      Hex-Sequenz "00 00 00 01 67" (SPS, ganz am Anfang) bis Ende "00 00 00 01 68" (PPS)
    • Ein IDR Frame für den Cut-In suchen (Hex-Sequenz: "00 00 00 01 65")
    • Hexcode bis zu dem nächsten gewünschten IDR-Frame suchen, den Bereich markieren und unter das SPS und PPS einfügen.
    • Neue Datei speichern. Wenn DGAVCIndex das File öffnen und indexieren kann, ist alles richtig gemacht worden.
    • Siehe auch Screenshot.


    Oder in Matroska muxen, mit mkvtoolnix schneiden und wieder demuxen.
    Oder AVIDemux verwenden (MKV geht, kann das auch AVC-RAW?)

    greets
    LTJ

  • slit-scan in AviSynth?

    Diese Art Effekt kann man auch gezielt nutzen, das heißt dann "Time Displacement".

    Beispiel:
    http://de.youtube.com/watch?v=I2MsDogV4g4

    Prinzip:
    Das Video wird mit einem Graustufenbild (Displacement-Map) überlagert. Ein Graustufenbild hat 256 Helligkeitswerte. Die Teile des momentanen Bildes, die mit helleren Werten der Map überlagert werden, werden durch Pixel aus später folgenden Frames des Quellvideos ersetzt und die Teile mit dunkleren Werten werden mit Pixeln aus schon vergangenen Frames des Quellvideos ersetzt. Bei einem Grauwert von 128 verbleiben die Pixel des aktuellen Frames unverändert. Mit folgender Formel kann man das Graubild auswerten:

    Displacement amount in seconds = maximum_displacement_time * (2 * (luminance_value – 128) / 256)

    Nimmt man statt eines statischen Graustufenbild ein Graustufenvideo, kann man damit ziemlich verrückte Verzerrungseffekte erstellen.

    So, wer will das Script programmieren? :zunge:
    Ich glaube in Adobe´s After Effects ist das doch etwas angenehmer zu händeln. :)

    greets
    LTJ

  • HC-Encoder: Fehlermeldung

    Zitat von LigH

    Übrigens - was meinst du mit "DAR=SAR von 1:1"?!


    Das ist natürlich Quatsch. SAR von 1:1 muss es heißen. Ich war wohl ein wenig neben der Spur durch

    Zitat von BJ1-Post #14

    Ein HDTV mit 1920x1080 ist exakt 16:9 (1920/16*9=1080). Hier ist PAR = DAR.


    Wahscheinlich hat sich BJ1 auch nur vertippt. Für HDTV muss es heißen PAR = 1:1 und DAR=16:9.

    ------

    Zitat von LigH

    Nur werden diese Flags ja vom Authoring-Tool erzeugt, und das wird beim Importieren des Videos wohl zunächst mal das Seitenverhältnis aus dem Video auslesen.

    Zitat von LessThanJake

    OK.
    Allerdings scheint das aber nicht notwendig zu sein. Denn spätestens beim Authoring wird das PAR-Flag automatisch passend zu dem angelegten Projekt-Typ gesetzt.

    Hiermit meinte ich, dass mit der Wahl des Projekttyps automatisch für das Authoringprogramm (zumindest scheint das bei Spruce DVD-Maestro so zu sein) schon klar ist, was in der IFO zu stehen hat. Das Auslesen des Flags ist ja dann nicht mehr nötig und es muss nur noch die tatsächliche Höhe und Breite des Quellvideos auf Konformität geprüft werden.

    Andererseits:

    Zitat von LigH

    Professionelle Studio-Authoringtools haben jedenfalls ordnungsgemäße Flags im Videostrom erwartet (z.B. Sonic DVD Creator 2.x), und erst gar kein MPEG2-Video angenommen, das nicht laut DVD-Spezifikationen mit DAR 4:3 oder DAR 16:9, sondern mit SAR 1:1 encodiert wurde.

    Zitat von BJ1

    DVDlab zeigt das im ES gesetzte DAR an (4:3 oder 16:9).

    Habt ihr denn tatsächlich überhaupt mal Streams getestet die mit einem SAR-Flag von 1:1 encodet wurden oder sind das Vermutungen?

    Ich will aber gar nicht streiten und auch keine Haarspalterei betreiben.
    Man könnte das tatsächlich mal einfach ausprobieren, indem man den HC mit SAR 1:1 encoden lässt und schaut ob auch andere Authoringprogramme diese Streams akzeptieren. Zudem könnte man auch mal den 4-Bit-Wert vor und nach Authoring aus dem ES auslesen und schauen ob die Authoringtools selbst patchen (falls der Stream akzeptiert wird) oder den IFO-Eintrag vorab generieren.

    Zitat von LigH


    Spruce ist tot. DVD Maestro ist zwar ein nach DVD-Spezifikation korrekt arbeitendes Programm; nach der Entwicklung von Windows als Betriebssystem, auf dem es laufen soll, jedoch völlig veraltet - es kann Multimedia-Möglichkeiten von Windows XP oder Vista nicht mehr nutzen.


    Das verstehe ich nicht. Es arbeitet korrekt! -> Ist doch Klasse.
    Welche Multimedia-Möglichkeiten sollen denn da groß ausgeschöft werden? :huh:
    Das Programm soll eine DVD produzieren und nichts weiter und das kann es.
    Natürlich möchte ich damit nicht abstreiten, dass DVDLab und Sonics Authoringtool und andere im Gegensatz zu DVDMaestro, was die Möglichkeiten und den Komfort angeht zeitlich auf der Höhe sind. :)

    Zitat von LigH

    MPEG-2 propagiert "Generic AR" (DAR für volle Bildfläche). Das ist die Theorie. Was die Praxis angeht, kann ich leider nicht viel mitreden, aber wenn festgestellt wird, dass viele DVD-Player ihr Video laut IRU-R BT.601 ausgeben (oder sind es die Fernseher, die es so darstellen?), dann ist das eben ein experimentell ermittelter Fakt...

    Ich glaube jetzt sind wir wieder hier
    http://encodingwissen.de/spezial/itur-bt601.html#generisch
    und hier
    http://encodingwissen.de/spezial/itur-bt601.html#diskussion
    angekommen.

    Das weiß ich nämlich jetzt auch nicht genau. Entzerrt der DVD-Player und der TV stellt einfach das 1:1 dar, was er vom Player bekommt oder schickt der Player das Flag weiter zum TV und der resized?

    Wenn Ersteres:
    Hat der DVD-Player den SAR-Faktor (Welchen Generic oder ITU?) einprogrammiert und bekommt ein DAR-Flag oder umgekehrt.
    Wenn Zweiteres:
    Hat der TV den SAR-Faktor (Welchen Generic oder ITU?) einprogrammiert und bekommt ein DAR-Flag oder umgekehrt.

    Ich vermute der SAR Faktor ist einprogrammiert, denn in IFOs finde ich nur DAR-Angaben. Und das von Gerät zu Gerät völlig durchmischt zwischen Generic und ITU, wobei es deshalb niemals ein generelles Richtig oder Falsch gibt.

    Irgendwie dreht sich gerade alles :D

    greets
    LTJ

  • HC-Encoder: Fehlermeldung

    Zitat von LigH

    Doch, das ist sinnvoll. Das AR-Flag im MPEG2-Video sollte doch bitteschön gleich von Anfang an stimmen, noch bevor es in das Authoringtool importiert wird. Dann stimmen beide überein (sowohl im Video in den VOBs, als auch in der IFO durch das Authoringtool).
    __

    PAR — P = Pixel oder Picture? Schwer zu unterscheiden. Daher in ISO/IEC 13818 (MPEG-2):

    DAR — D = Display: Wiedergabe des Gesamtbildes, Seitenverhältnis des Gesamtbildes (4:3 / 16:9)

    SAR — S = Sample: Element des Gesamtbildes, Seitenverhältnis des Bildpunktes (1:1, 11:12, 11:16)

    Nicht zwingend vorgeschrieben, aber meiner Meinung nach nützlich, um den Unterschied zu verstehen, was denn hier ins Verhältnis gesetzt wird.

    Ich hab jetzt nochmal nachgeschaut. Es gilt nach ITU-T H.262 für MPEG2 für das 4 Bit AR-Flag "aspect_ratio_information" im Sequence Header:
    [Blockierte Grafik: http://img2.abload.de/img/ar-mpeg2fn6y.jpg]
    Also im Grunde so wie du es auch geschrieben hast und wie das bei unserem Fr_An auf der Homepage auch beschrieben steht.

    Was die Entzerrung während der Wiedergabe angeht, so muss laut dieser Recommendation - wenn ich das halbwegs richtig übersetzt habe - ein Zuspielgerät, für den Fall, dass die volle TV-Bildfläche

    [Blockierte Grafik: http://www.abload.de/img/sde_not_present6l6r.png]

    genutzt wird, nach

    [Blockierte Grafik: http://www.abload.de/img/sar-formel7qt5.png]

    und resultierender Tabelle (PAL):

    für sowohl 704x576 und 720x576 für PAL
    immer auf 1024 (16:9) bzw. immer auf 768 (4:3) in horizontaler Richtung gestreckt werden.

    Zitat von BJ1

    Nein, das PAR (Pixel Aspect Ratio) bleibt am PC innerhalb der Verarbeitungskette immer gleich (1:1)


    Das ist mir klar.

    Zitat

    Ein HDTV mit 1920x1080 ist exakt 16:9 (1920/16*9=1080). Hier ist PAR = DAR. Soll das auf DVD, muss "unproportional" auf 720x576 resized werden.


    Das ist mir klar.

    Zitat von BJ1

    Das PAR dieses Bildes ist nun 5:4, dem Ausgabegerät muss ich aber mitteilen, ob das Bild denn auf 4:3 (768x576 Bildpunkte) oder 16:9 (1024x576 Bildpunkte) gestreckt werden soll.


    Das ist mir klar.

    Zitat von BJ1

    Dafür ist das DAR-Flag im MPEG da.
    Ein "richtiges" DVD-Authoring-Programm erwartet korrekt markierten Input. Ein als 16:9 geflaggtes MPEG wird es auch wieder als solches ausgeben.


    Eigentlich geht es nur um diesen Punkt. Dieser ist strittig, denn:

    • bei einer DVD wird das DAR/PAR/SAR, was auch immer, nicht aus dem MPEG2-Sequence-Header im RAW-Videobitstream gelesen, sondern aus der *.IFO Datei
    • wenn ich den HC mit einem SAR von 1:1 encoden lasse, sollte im Sequence-Header die Bitfolge 0001 für "aspect_ratio_information" stehen (ungetestet). DVDMaestro (benutze ich noch immer) nimmt das Material trotzdem an. (Wie siehts mit DVDLab aus, weiß das jemand?)
    • ohne Flag erzeugte DVDs spielen in Software-DVD-Playern (PowerDVD / VLC ...) und allen bisher von mir getesteten Hardware-DVD-Playern tadellos und korrekt ab --> Wieder ein Hinweis dafür, dass auf jeden fall die *.IFO benutzt wird.

    Anmerkung:
    Bei Transportstreams (*.TS) könnte es tatsächlich sein, dass das Flag nötig ist, bin aber gerade nicht sicher ob da nicht vielleicht auch im PES-Header ein paar Bits für reserviert sind. Und natürlich immer dann, wenn es direkt um Elementary Streams geht, die nicht weiterverarbeitet werden.

    Die gaanz einfache Frage am Ende ist also:
    Warum genau "sollte doch bitteschön gleich von Anfang an" (Ligh) das Flag für eine DVD gesetzt werden? Es gibt keinen wirklichen Grund. ;)
    Genau wie es bei der MPEG4-Geschichte auch keinen wirklichen Grund dafür gibt, wenn am Ende ein vollwertiger Film mit Audio, Subtitles, Chapters etc. gebaut wird, da muss auch immer ein Container her und da gehört dann das Flag rein. Ein vernünftiger Player kann das dann auch wieder auslesen und ist nicht auf das Flag im Bitstream angewiesen. Mosu lässt das Flag beim Muxen mit mkvmerge bei MKV glaube ich sogar auch rausfliegen, wenn man nicht explizit mitteilt, dass es erhalten werden soll. Aber ich schweife ab ... ;)


    greets
    LTJ