"RTP senders SHOULD NOT transmit
picture timing SEI messages for
pictures
that are not supposed to be displayed as
multiple
fields."
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Aaron Wells
Sent: Friday, May 15, 2009 7:56 PM
To: avt at ietf.org
Subject: [AVT] FW: RE: 3984bis-06 and pic timing SEI
All,
Apologies in advance if this retraces old ground:
I see the following directive in the draft:
"RTP senders SHOULD NOT transmit picture timing SEI messages for
pictures that are not supposed to be displayed as multiple
fields."I understand this to mean that pic_timing SEI should
not be sent for field pictures.If so, this raises a few questions for me:
The picture timing SEI message tells the decoder whether a field is to
be displayed as a top (pic_struct=1) or bottom (pic_struct=2)
field. If the RTP sender were to strip these SEI from the stream,
how is this information conveyed to the decoder?The standard directs that if pic_stuct_present flag
is set in the SPS, then a picture_timing_SEI message will
be present in every access unit.
Similarly, the SEI message is required if either
nal_hrd_parameters or vcl_hrd_parameters is set to 1.
Is it further intended that the RTP sender also to parse
VUI and mask out these bits?If the pic timing SEI message is stripped and if
the h.264 stream contains both field and frame coded video,
then is it expected that the RTP sender parses into each slice
header to determine the picture structure, then selectively
strips the pic timing SEI messages from field pictures?If this is the case, how should the pic_struct_present flag
be set in the VUI?Why is the immediately preceding directive
"Receivers SHOULD ignore any picture timing SEI messages included
in access units that have only one display timestamp.
Instead, receivers SHOULD use the RTP timestamp for
synchronizing the display process"
insufficient?Thanks
Aaron