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

[Michael Niedermayer]

On Fri, Feb 20, 2009 at 01:15:04PM +0100, Ivan Schreter wrote:
> 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).

looking at the relevant MLs the chairmen of JVT confirms that the needed
flags are indeterminate within the spec and you should just guess based
on size of the SEI ;)
sorry, mans, the truth about these specs slowly comes out ...

"
+> What is the purpose of allowing the flag to be set by 'some means not
+> specified'?  My problem with this clause is that renders it 
+> impossible
+> to parse SEI pic_timing reliably given a 3rd party bitstream 
+> where you
+> do not know whether CpbDpbDelaysPresentFlag was set by some means
+> unspecified.  Why not force the encoder to set at least one of
+> vcl_hrd_parameters_present_flag or nal_hrd_parameters_present_flag
+> (adding only a few bytes to the SPS) if it wants to include
+> cpb_removal_delay and dpb_output_delay?

...
You may be right that this particular aspect could perhaps have been
designed better for parsing.  However, I believe that the use
environment should make the use unambiguous.  When the video is used in
a system that provides no other means to carry this information, then
the decoder does not need to worry about what the data provided by other
means is saying.
Also, I think it should not be difficult in most cases to figure out
what is in the picture timing SEI message by examining their size and
content.
"

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.


>
> 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?

because there is no current sps
you can have 10 sps NALS in a access unit and have the slices refer to a
11th
You can even have a sps occur many frame in the future and refer to it before
if the bitstream as been cut


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090220/76419236/attachment.pgp>