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

[Ivan Schreter]

Michael Niedermayer wrote:
> On Tue, Feb 17, 2009 at 09:57:32PM +0100, Ivan Schreter wrote:
>   
>
>> #6 (h264_default_sps): Parsing SPS doesn't assign the just-parsed SPS as 
>> current SPS on the context. Thus, decoding of SEIs (especially SEI 
>> buffering period) depending on current SPS wouldn't work. Assign 
>> just-parsed SPS as current SPS for the context.
>>     
>
> this is wrong, buffering period contains a sps_id selecting the sps it
> doesnt depend on the "current sps"
>   
Buffering period does, my mistake.

Picture timing SEI in first frame will not be decoded (decodes 0 bits), 
since required VUI flags are in SPS. Current SPS is not filled at the 
beginning, though. I.e., my frame has:

[...]
NAL_SPS
[...]
NAL_SEI buffering_period (decodes OK, as sps_id provided)
[...]
NAL_SEI picture_timing (decodes 0 bits, as current SPS on context is 
filled with zeroes)
[...]

So picture timing of the initial frame as well as of frames where 
relevant VUI parameter change (can they?) cannot be decoded correctly, 
which leads to various problems (like, first frame of interlaced video 
is identified as progressive frame instead of field picture). 
Furthermore, following SEIs are not decoded correctly, since current SEI 
handling code doesn't skip not decoded bytes (i.e., it tries to decode 
wrong SEI type following picture_timing).

I don't quite understand, if VUI parameters are always associated with 
SPS or if they are global, only provided via SPS. Do you know it? If the 
latter, then the whole handling of VUI is wrong and they must be 
factored out of SPS.

The standard doesn't specify which SPS to use for getting relevant VUI 
flags for SEI picture timing (no sps_id provided in this SEI). In the 
stream, there is just one NAL_SPS preceding first picture timing, so 
implicitly it must be VUI in that one (we have no other SPS).

Patch attached again.

Or do you have an idea where to get required VUI flags for picture timing?

BTW, why copy SPS (in general) instead of keeping a pointer to current SPS?

Regards,

Ivan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264_current_sps.patch
Type: text/x-patch
Size: 326 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090220/c919299c/attachment.bin>