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

[Ladan Gharai <[e-mail]>]

Chuck - thank you for your comments! my notes are inline:

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

noted.

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

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.

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

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

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

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

noted.


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


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.

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

is it necessary to RLE? would it be possible to simply omit
the unused blanking data?
 > 
 > 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