[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set
Fri Feb 20 15:50:24 CET 2009
Michael Niedermayer wrote:
> based on this, i guess, your patch is ok. Also trying what the official
> recommandition is, that is trying to parse it with the flag set and not set
> and picking what succeeded could be done, it likely is more reliable than
> using the SPS which does really not contain sufficient information
> to determine the flag anyway.
I take this as OK, it will be applied...
Good to know that I'm not the only one who doesn't get the standard in
this place :-)
As for the second option, the standard also says in D.2.2:
The presence of picture timing SEI message in the bitstream is specified
-- If CpbDpbDelaysPresentFlag is equal to 1 or pic_struct_present_flag
is equal to 1, one picture timing SEI message
shall be present in every access unit of the coded video sequence.
-- Otherwise (CpbDpbDelaysPresentFlag is equal to 0 and
pic_struct_present_flag is equal to 0), no picture timing
SEI messages shall be present in any access unit of the coded video
I.e., presence of picture_timing SEI indicates, CpbDpbDelaysPresentFlag
is 1 and/or pic_struct_present_flag is 1, so 3 possibilities would have
to be checked. Unfortunately, it's impossible to infer the values for
the two flags and needed field sizes just from SEI itself (or its bit size).
The standard also says, SEI picture piming "shall be present in every
access unit of the coded video sequence", i.e., these two flags
obviously do not change in the middle of the sequence. This implies that
EACH SPS must define pic_struct_present_flag and appropriate VUI flags
throughout the stream consistently, so it's not important which SPS will
be used to get the flags.
>> BTW, why copy SPS (in general) instead of keeping a pointer to current SPS?
> because there is no current sps
> you can have 10 sps NALS in a access unit and have the slices refer to a
Yes, I know.
I've seen that decode_slice_header() copies SPS to some kind of
"current" SPS (at least for the slice). Therefore I asked.
> You can even have a sps occur many frame in the future and refer to it before
> if the bitstream as been cut
I suppose you mean a corrupted stream or when reading from the middle
after a seek? In the latter case, I expect that within SEI recovery
frame count frames after a key frame the SPS will be redefined correctly.
More information about the ffmpeg-devel