[AVT] RE: Comments: draft-ietf-avt-smpte292-video-04.txt

["Miller, William C." <[e-mail]>]

Chuck et al,

I'm forwarding this to SMPTE N26, which has custody of SMPTE 292M.  N26
folks, please review the draft at the link below.  Johann, please tell us
how you'd like the N26 comments handled.  Thanks.

Regards,
Bill

William C. Miller
ABC-TV
212-456-4448
212-456-2284 fax
[e-mail]


-----Original Message-----
From: Chuck Harrison [mailto:[e-mail]]
Sent: Saturday, March 16, 2002 2:53 PM
To: [e-mail]
Cc: [e-mail]
Subject: Comments: draft-ietf-avt-smpte292-video-04.txt


Hi Ladan,

Regarding
http://ietf.org/internet-drafts/draft-ietf-avt-smpte292-video-04.txt

Several comments which may bear discussion on Monday. I will not
be attending. I used numbering -1-... for reference.

Ladan Gharai wrote:
> 
> Dear all:
> 
> The following is a summary of changes made to
> draft-ietf-avt-smpte292-video-04.txt -- we would
> appreciate feedback on how to represent the
> 148500/1.001Hz timestamp value.
[CH] -1- As written, 148351, makes sense to me.

> 
> 1) packetiztion:
>       - the draft now stipulates that SMPTE292 lines must not be
>       fragmented across SAV and EAV values.
[CH] -2- Actually the draft sec. 3 says SHOULD NOT. I believe
MUST NOT is more appropriate.

>       - source format video lines must not be fragmented across
>       related YCrCb values.
[CH] -3- Actually, the draft sec. 3 says MUST NOT. I believe
MUST NOT is inappropriate. See fuller discussion below at -10-.

> 
> 2) timestamp:
>       - the RTP timestamp is now a 148500Hz or 148500/1.001Hz
>       value corresponding to the  SMPTE292M data rate of 1.485Gbps or
>       1.485/1.001Gbps respectively.
[CH] -4- Good idea. This granularity will support packet-loss
tolerance in receivers even when nonuniform packet lengths are
used.

> 
> 3) new fields in the payload header:
>       - line number, V and F bit flags have been added to the
>       payload header, thereby allowing reconstruction of the
>       EAV+LN+CRC and SAV values, in case of packet loss.
[CH] -5- The usage of V bit does not seem to correspond with
SMPTE 292M, where it identifies the vertical (field) blanking
period. Please explain and/or fix.

[CH] -6- The line no sounds plauible, but needs a fuller
explanation. I would like to see this explanation/rationale
in the draft. Also see suggestion for reordering of fields
at -8- below.

[CH] Note that, since we now have fine-granularity timestamps
(-4- above), received data regions belonging to lost packets
can be unambiguously identified as known-length erasures. SAV/EAV
locations and line numbering are highly redundant anyhow, so
higher-level protocols can reconstruct them reliably under these
conditions. (This is often done ["freewheeling"] in SMPTE292M
implementations today.)

------

[CH] -7- There seems to be nowhere in this draft that the payload
packetization itself is defined (packing 10-bit words into
32-bit chunks, end-of-packet padding, etc.) Surely this is an
accidental deletion? I am pretty sure this was clearly expounded
in an earlier draft. Perhaps section 4.3?

[CH] -8- If the 'line no' field is retained (I'm not sure it
is very valuable, see -6- above), I suggest reordering the last
4 bytes of payload header as follows:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    sequence# (high bits)      |F|V| Z |      line no          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This has (relatively minor) advantages as follows:
(a) the line no is extracted as an integer by masking only,
     no shifting required;
(b) the reserved Z field is available as an extension to the
     line no in the event this payload format is adapted to
     potential higher-resolution formats in Digital Cinema

[CH] -9- The introduction describes the space between EAV and
SAV as "digital line blanking". A statement that this area
can contain Horizontal Ancillary Data (H-ANC) and that this
data can be transported as part of this payload format should
be added. V-ANC (in the vertical blanking period) should
also be mentioned. H-ANC and V-ANC fields are extremely
important to current studio practice using 292M.

[CH] -10- Fragmentation constraint regarding related Y Cr Cb units
(-3- above). I strongly question the inclusion of this constraint.
It clearly makes the packetization rules dependent on the video
format being carried. This is in direct opposition to the goal
of a format-independent packetization. Furthermore, in many
applications it is likely that the packetizer will be unaware
of the coding structure used at the original source of the
video signal and I believe this is proper.

[CH] This constraint needs a rationale. The only one I have
thought of is that something in the depacketizer might be
video-format-dependent and optimized in a way that relies
on this structure. If this *is* the rationale, then I
really think the fragmentation parameter (3, 4, 6, ...
10-bit words, as described in sec. 3) should be negotiated
by sdp. Just like the fmtp length field, this is a request
by the receiver for the sender to format packets in a way
that it can properly handle.

[CH] However, I still question whether this constraint is wise
at all. Perhaps you should go back to the original vision
of treating 292M as a "dumb" container for 10-bit data
words, recognizing only the EAV, SAV and field/frame
structure at the RTP packetization layer.

[CH] -11- You might consider an extension to the payload
format which would support compression of unused blanking
data. This is not particularly elegant, but it could save
considerable bandwidth in routine applications. Specifically,
I am thinking of some kind of RLE which gives a count and
10bit word value.

Regards,
  Chuck Harrison
  Far Field Associates, LLC
  [phone] (voice)  PST = GMT-0800


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt