Subject: [rtcweb] Video Open Issue #6: H.264 SEI messages

From: Adam Roach <[email-masked]>
Date: Thu, 12 Feb 2015 16:18:39 -0600

Also breaking this one off from the previous thread...

On 11/25/14 23:27, Stephan Wenger wrote:
> Hi,
>
> I meant to copy the mailing list on two emails regarding my (and
> Bernard’s) action items.  I mis-spelled rtcweb.  So here the content
> integrated into a single email.  (Bernard and Adam: there’s nothing new
> herein.)
>
> Hi,
> So here my proposal, with respect to H.264 baseline:
>
> MUST:
> Filler payload.  You see this occasionally from mostly early generation)
> encoder chips.  It¹s basically a way to waste bits so to fulfill buffer
> constraints.  Implementation complexity is zero: throw away bits.
>
> Full frame freeze: used in video switching MCUs, to ensure a stable
> decoded displayed picture while switching channels in probably a
> media-unaware way.  Commonly used in H.32x legacy environments and also in
> some SIP MCUs.

To be clear, you are specifically leaving off "full frame freeze 
release" on purpose, right?

> MAY:
> User data T.35 registered, and user data unregistered
> Especially the latter you see occasionally for proprietary extensions.
> It¹s a good idea to advise implementers that a bitstream may contain that
> kind of stuff, even if they don¹t act on it.
>
> Display orientation SEI, as it is referenced in section 4.

Seems reasonable to me.

Based on this advice, I have added the following text to -04:

H.264 codecs MAY send and MUST support proper interpretation of SEI "filler
payload" and "full frame freeze" messages. "Full frame freeze" messages are
used in video switching MCUs, to ensure a stable decoded displayed picture
while switching among various input streams.

When video orientation (CVO) is not signaled as part of the SDP, H.264
implementations MAY send and SHOULD support proper interpretation of Display
Orientation SEI messages.

Implementations MAY send and act upon "User data registered by Rec. ITU-T
T.35" and "User data unregistered" messages. Even if they do not act on 
them,
implementations MUST be prepared to receive such messages without any ill
effects.

Stephan: could you sanity-check that this captures your recommendations 
accurately? Thanks!

/a

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 13 Feb 2015 09:54:41 +0000

Hi,
A few comments inline.
Stephan

>release" on purpose, right?

Yes.  I’m not aware of any product that uses full frame freeze release in
an SEI message.  H.323 systems send this command over H.245 signaling (and
there is a reason for it, but that would probably go a bit too far for the
discussion here.)

>Stephan: could you sanity-check that this captures your recommendations

Sounds OK.  Quick question for my education and to make sure: SDP CVO
refers to the presence of that RTP header extension that indicates picture
orientation, and not to a fixed orientation signaled in the SDP, right?

The reason I’m asking is that the SEI message and the RTP header extension
both allow to change display orientation on the fly, which is obviously
useful for handheld devices.  That’s what we need. A fixed orientation is
too inflexible for almost all applications that matter.

---

From: Adam Roach <[email-masked]>
Date: Fri, 13 Feb 2015 11:56:17 -0600

On 2/13/15 03:54, Stephan Wenger wrote:
> refers to the presence of that RTP header extension that indicates 
> picture orientation, and not to a fixed orientation signaled in the 
> SDP, right?

Yes. I've added some more text to hopefully make this clearer:

When the use of the video orientation (CVO) RTP header extension is not
signaled as part of the SDP, H.264 implementations MAY send and SHOULD 
support
proper interpretation of Display Orientation SEI messages.

/a