Subject: [AVT] summery for draft-ietf-avt-smpte292-video-04.txt

From: Ladan Gharai <[email-masked]>
Date: Thu, 14 Mar 2002 20:44:07 +0000

Dear all:

The following is a summery 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.

1) packetiztion:
      - the draft now stipulates that SMPTE292 lines must not be
      fragmented across SAV and EAV values.
      - source format video lines must not be fragmented across 
      related YCrCb values.

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.

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. 

L.
-----------------------------------------------------------
Ladan Gharai                            [email-masked]
http://www.isi.edu/                     tel: (703) 812 3702
USC Information Sciences Institute      fax: (703) 812 3712

      

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

---

From: Chuck Harrison <[email-masked]>
Date: Sat, 16 Mar 2002 11:53:17 -0800

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
[CH] -1- As written, 148351, makes sense to me.

>       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
[CH] -3- Actually, the draft sec. 3 says MUST NOT. I believe
MUST NOT is inappropriate. See fuller discussion below at -10-.

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

>       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
  +1 (360) 863 8340 (voice)  PST = GMT-0800

---

From: Ladan Gharai <[email-masked]>
Date: Mon, 18 Mar 2002 14:10:44 +0000

> MUST NOT is more appropriate.

noted.

 > >       EAV+LN+CRC and SAV values, incase of packet loss.

I also understood that V is meant for vertical field blanking. The 
terminology used in the draft is from the SMPTE292M document, where
V is refered to as field balnking? However this can be easily fixed
in the draft, such that V refers to vertical field blanking.

 > conditions. (This is often done ["freewheeling"] in SMPTE292M

the line number, F and V fields are replacing the otherwise 16 unused
bits -  although with the finer granularity timestamps, the exact point
of data can be found, having line numbers does add a level of resilience.
 > in an earlier draft. Perhaps section 4.3?

good point. the previous draft was 4:2:2 specific and  therefore
pixel values natrually fell on 40bit boundries  - but this point 
must be addressed.  
  
 > 4 bytes of payload header as follows:

noted.
 > important to current studio practice using 292M.

noted.

 > of the coding structure used at the original source of the

this is a general applicaion of the ALF principle - a note could
be added to the draft that only if the video content is 4:4:4, 4:2:2 or
4:2:0 it SHOULD NOT be fragmented. Thereby not restraining the
packetiztion of other video conetent transported by SMPTE292M.

 > I am thinking of some kind of RLE which gives a count and

is it necessary to RLE? would it be possible to simply omit
the unused blanking data?
 > #################################################################
 > #################################################################
 > #################################################################
 > #####
 > #####
 > #####
 > #################################################################
 > #################################################################
 > #################################################################
 > 
 > #################################################################
 > #################################################################
 > #################################################################
 > #####
 > #####
 > #####
 > #################################################################
 > #################################################################
 > #################################################################