Wie schnell den Framecount eines H.264 raw streams ermitteln?

    Da ich in Hybrid gerne auch mit H.264 RAW Streams hantieren würde, aber dafür den Framecount und die Framerate bräuchte bin ich auf der Suche nach einer schnellen Methode an den Framecount eines H.264 Elementarstreams zu kommen.
    Idealerweise sollte dies natürlich mit Tools geschehen die ich eh schon in sx264/Hybrid nutze, sprich mkvmerge/mkvextract/mp4box/mediainfo/ffmeg/mencoder/mplayer/tsMuxeR.
    Die schnellste Variante die ich bis dato gefunden habe wäre:

    Code
    mplayer -nofontconfig -msglevel all=0:statusline=5 -mc 0 -benchmark rawvideo.264 -nosound -vo null

    (+Ausgabe am Ende filtern)
    Dadurch wird der Stream einmal komplett decodiert und man kann aus der Ausgabe in der Konsole die Länge ablesen.

    Wollte mal fragen ob jemandem eine flottere Methode einfällt.

    Cu Selur

    Ps.: Im Notfall werde ich mich wohl mal genauer mit dem Parsen eines H.264 Streams beschäftigen müssen.

    Ich finde dgavcindex recht flott:

    dgavcindex -i source.h264 -o info.dga (-h (hidden))

    Letzte und vorletzte Zeile der info.dga steht der Framecount. Allerdings auch im log.

    Ich glaub ohne komplettes "decoding" ists gar nicht möglich die Frames von h264-raw zu ermitteln.

    mkvmerge gibt leider auch nur irgendwas annähernd Richtiges aus, nach dem containern:

    Code
    'raw.h264' Track 0: force_duration_on_last_packet: forcing at 00:21:38.000000000 with 40000.000ms

    Das wären 32400 frames, der stream hat aber 32451 :(

    Bezüglich etwas Eigenem, vielleicht darfst du dich ggf. aus mkvtoolnix bedienen, und lässt den ganzen filewriter weg, baust das somit in ein reines analysetool um. Vielleicht kann auch h264info da noch etwas beisteuern, was das Lesen der NALU betrifft.

    Eac3to gibt bei gesetztem -check Parameter die Anzahl der Frames bzw Fields zurück.

    z.b
    Fieldbasierender Stream
    eac3to fieldstream.h264 -check
    gibt zurück

    Zitat

    h264/AVC, 1440x1080 50i (16:9)
    Video track contains 2588 fields.
    eac3to processing took 1 second.
    Done.

    oder framebasierender Stream
    eac3to framestream.h264 -check

    Zitat

    h264/AVC, 1080p60 /1.001
    Video track contains 4923 frames.
    eac3to processing took 1 second.
    Done.

    Interessant, aber unter Linux auch nur mittels Wine nutzbar und leider ist es ClosedSource. :(

    Zitat

    Eventuell werden ja die Inputformate von x264 bald erweitert.


    Da ich die RAW Streams aber über mencoder je nach dem noch filtern würde ist das leider keine Hilfe. ;)

    Zitat

    # Frame numbering, a feature that allows the creation of "sub-sequences", enabling temporal scalability by optional inclusion of extra pictures between other pictures, and the detection and concealment of losses of entire pictures, which can occur due to network packet losses or channel errors.


    Wenn ich das richtig verstehe, sind die Frames numeriert.

    Gruß Frank

    Nein.
    Auch Sequence Parameter Sets, Picture Parameter Sets, Supplemental Enhancement Information, End of Sequence usw sind NAL Units.
    Selbst Frames bzw Fields sind meist in mehrere Slices sprich mehrere NAL Units unterteilt.
    Deshalb ja mein Vorschlag mit der Zählung der Picture Parameter Sets.

    Edit:
    Das mit den Pict-param-sets ist auch Unsinn, nicht jedes Frame/Field muss PPS haben...

    Einmal editiert, zuletzt von bigotti5 (4. Januar 2010 um 21:19)

    Hab mal einem kleinen TestRaw (http://www.selur.info/rawvideo.264 ist ca. 1MD groß) geguckt DGAVCDec berichtet: 428 (Preview durchlaufen lassen)
    Startend mit 00000001 hab ich gefunden:
    3x 0000000168
    3x 0000000167
    3x 0000000165
    251x 0000000141
    175x 0000000101

    Hab noch ein paar mit x264 erstellte RAW files ausprobiert und da ist #(0000000165) + #(0000000141) + #(0000000141) immer ein Frame mehr als DGAVCIndex anzeigt, werde morgen mal ein kleines Command Line Tool zusammenschreiben damit man das auch mit anderen Streams testen kann.

    Cu Selur

    3x 0000000165 - IDR Picture NAL Units (25, 45, 65)
    251x 0000000141 -
    175x 0000000101 - Non IDR Picture NAL Units (01, 21, 41, 61)
    3+251+175 = 429 Frames (DGAVCDec geginnt bei Frame 0)

    ...allerdings entspricht in deinem Stream ein Frame immer nur einer NAL Unit.
    Sind Frames bzw Fields auf mehrer NAL Units verteilt stimmt die Rechnung nicht mehr. Du musst auch das der NAL Unit Type folgende Byte beachten, ist dieses 00 darf dies nicht gezählt werden
    z.b
    00 00 00 01 65 00 - nicht zählen
    00 00 00 01 41 9B - zählen

    Okay, wenn ich Dich richtig verstanden habe muss, ich also alle Bytesequenzen
    00 00 00 01 01 xx
    00 00 00 01 21 xx
    00 00 00 01 25 xx
    00 00 00 01 41 xx
    00 00 00 01 45 xx
    00 00 00 01 65 xx
    zählen, wobei mit xx ungleich 00.

    hier eine Quick&Dirty CL-Variante: http://stashbox.org/759838/BinaryAnalyser.zip (32bit/36bit Variante und Sourcecode) scheint aber zu klappen :)

    Cu Selur

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden