Re: [rtcweb] Finishing up the Video Codec document

[Stephan Wenger <[e-mail]>]

Hi,
below a few generic comments (not directly related to my action item).
Stephan

1. Section 3: sRGB is fine.

2. Section 3: Add something like dynamic frame rate / frame interval based
on user locale, available bandwidth, and so on.  For example, in low light
conditions, it almost never makes sense to run a full 30 fps camera when
your transport has only bandwidth for 15 fps.

3. Section 3: Possibly missing: mention that the video scan pattern for
both VP8 and H.264 is YCrCb 4:2:0.

4. Section 3: Possibly missing: the screen content section should mention
that the scan format of video (YCrCb 4:2:0) is known to be suboptimal for
the representation of screen content as produced by systems at the time of
publication, which generally use at least 24 bits per sample RGB.  Perhaps
a forward looking statement: ³In the future, it may become advisable to
use video codecs optimized for screen content (scan pattern, color space,
signal characteristics) for the representation of this type of content.²



5. Section 5 second and third paragraphs: Mention Constrained Baseline
Profile here.   Otherwise, section 5 seems fine to me.  (I know that
constrained baseline is mentioned as a MUST later, but H.264 in isolation
is insufficient even in this overview part of the document).

6. Section 6, 3rd para, 1st and 2nd line, nit: "are MUST²

5. Section 6.2, profile_level_id, suggest to change the receiving side to
a MUST.  The decoder interprets the value anyway as presented in-band.
What¹s the point that a receiver accepts a bitstream (without checking
profile_level_id), and the croaks because the decoder cannot handle the
bitstream complexity as communicated in-band?

6. Section 6.2, max_mbps..., nit: par ameters (1st and second line)

Normative reference to H.264: depending on the timing, it may be better to
reference H.264v9.  That version is currently in ³pre-published² state and
not freely downloadable, but should be generally available rather sooner
than later (and almost certainly before we are through with this draft).

7. Section 6.2, sprop_parameter_sets: For avoidance of doubt, I would
rephrase that as ³this parameter MUST NOT be present².  It is possible to
have that parameter and later change parameter sets in-band, and that is a
condition I think you want to avoid.  (btw. my heart is bleeding.  Some of
you know why.  The rest: keep guessing :-)

8. Section 6.2, Possibly missing: for H.264, should we specify a pixel
aspect ratio?  VP8 uses square pixels, right?  Perhaps follow that lead?


9. Section 7: point to the payload formats also.  H.264 allows for active
content in SEI messages... and the payload formats contain the necessary
caveats.










On 11/25/14, 15:33, "Adam Roach" <[e-mail]> wrote:

>I've updated the draft-ietf-rtcweb-video based on the minutes from
>Hawaii. Now that we have a clear path to success, I'd like to get the
>document finalized and published as quickly as possible. This means I
>need your feedback on the remaining open issues (1, 4, and 5, below). If
>you are CCed on this mail, it's because you took an action item in
>Hawaii, and I'm waiting to hear back from you.
>
>New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/
>Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt
>____
>
>Action item for Harald Alvestrand from the minutes:
>> Mo Zanaty: An IANA registered header with reference to 3GPP document.
>> Codec specific mechanism way of doing this.
>> Harald: Will send some suggestions on doing this.
>
>Action item for Bernard Aboba and Stephan Wenger: collect list of H.264
>SEI messages we want to call out as MUST and/or SHOULD.
>____
>
>Open Issue 1: If you don't want sRGB to be the default color space, say
>something now.
>
>Open Issue 2 (closed): Took "screen source video metadata" issue out of
>the document, as this is an RTP issue, not a codec issue.
>
>Open Issue 3 (closed): New text in "stream orientation" section calling
>out various MUST/SHOULD/MAY levels, based on what I took away from the
>mic in Hawaii. If you care about this, double-check that these are what
>you expect them to be.
>
>Open Issue 4: In Toronto, it was suggested that we don't need to specify
>support for "bilinear" and "none" filter styles, since they're already
>required. I'm happy to remove the statement if someone can point me to
>where this is otherwise mandated. If no one comes forward with a
>citation, I'm going to close this open issue as harmless.
>
>Open Issue 5: Waiting on feedback from Bernard and Stefan, as detailed
>above.
>
>Open Issue 6 (closed): Please see the text in section 5 of the new
>document, which tracks the text from the Novel Proposal email pretty
>closely.
>
>/a