H264ParamReader

[tobiasm767]

Hi

 

ich habe mal eine Frage zum H264ParamReader.

 

Und zwar für das auslesen der timing info, wenn das timing_info_present_flag gesetzt ist.

die felder num_units_in_tick und time_scale sind ja laut spec 32 bit lang.

 

ich schreibe gerade meinen eigenen parser aber ich komme bei diesen feldner nicht immer auf die gleichen werte wie ihr.

bei manchen sender kappts (zb hd suisse mit 1200 und 120000) und bei anderen nicht (zb pro7 hd - ihr habt num_units_in_tick = 1 & time_scale = 50 und ich num_units_in_tick = 48 & time_scale = 16777216).

 

falls das nicht zu viel verlangt ist, könnt ihr mir sagen, wie ihr diese felder auswertet?

[Griga]

und ich num_units_in_tick = 48 & time_scale = 16777216

Etwas abenteuerliche Werte. Vermutlich falsch. Entweder hast du bereits vorher einen Fehler drin, d.h. es wird irgendwo nicht die korrekte Anzahl Bits gelesen - dieses Bitstream-Handling ist allgemein ziemlich übel. Oder die wahrscheinlichste Ursache: Du hast das emulation_prevention_three_byte nicht ausreichend berücksichtigt. Darüber bin ich zunächst gestolpert.

 

Dieser Mechanismus soll verhindern, dass in einer NAL Unit zufällig die Bytefolgen 00 00 00, 00 00 01 oder 00 00 02 auftauchen, was zu Verwechslungen mit reservierten Bytefolgen wie 00 00 00 01 (NAL unit start code) führen könnte. Deshalb wird nach zwei Nullbytes das emulation_prevention_three_byte 03 eingestreut. Es muss übersprungen werden. Im H264ParamReader werden die einzelnen Bytes des Streams so gelesen:

 

function TfrmH264Reader.GetByte: Byte;
begin
 result := GetRawByte; //read next byte from stream
 if (LastTwoBytes = 0) and (result = 3) then //skip emulation_prevention_three_byte
 begin
LastTwoBytes := 3;
result := GetRawByte;
 end;
 LastTwoBytes := LastTwoBytes shl 8 + result; //LastTwoBytes is a 16 bit value
end;

[tobiasm767]

Danke für die flotte Antwort!

 

Es war wirklich das emulation_prevention_three_byte.

Das hatte ich in der Spec gar nicht richtig für voll genommen, was da vorne stand aber es war wohl wichtig

 

Stimmt schon dieses ganze Bitstream-Handling ist schon nicht ohne aber andererseits schon cool, wie man damit noch ein paar bits sparen kann...