[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set

[Ivan Schreter]

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 
as follows.
--   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 
sequence.

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
> 11th
>   
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.

Regards,

Ivan