Subject: RE: I-D ACTION:draft-ietf-avt-dv-video-01.txt

From: Bill Nowicki <[email-masked]>
Date: Thu, 21 Oct 1999 17:46:41 -0700

Generally the protocol is very nice and simple. However, the document has
some minor problems.

There are two spaces between "Carsten" and "Bormann" on the first page?

Be consistent about "IEC 61834" having a space between the letters and
numbers. Similarly, "IEEE 1394" is the convention, not "IEEE1394". Also put
a space before open parentheses consistently.

The designations "D-7" and "D-9" are tape formats. They correspond to
products with the DVCPRO and Digital-S trademarks respectively; is the
policy to avoid trademarks in IETF standards? If not, mentioning them might
be useful. The professional 25Mbps variants are generally the same DV
stream, just on different physical tape, so it is not clear the full matrix
is relevant to an RTP payload, but I suppose it does not hurt. There are
some subtle differences in audio support, 625 line color model, etc.

Might mention somewhere that SD-VCR stands for "Standard Definition Video
Cassette Recorder", etc. I do not know exactly what "SDL" stands for, since
nobody uses it that I know of.

Section 2 and the first paragraph of section 3 have many English errors, and
are redundant. Suggested rewording:

2. Introduction

   This document specifies payload formats for encapsulating 
   both consumer and professional use DV format data
   streams into the Real-time Transport Protocol (RTP), version 2 [6].
   DV compression audio and video formats were designed for helical-scan 
   magnetic tape media. The DV standard for consumer market devices,
   the IEC 61883 and 61834 series, includes many aspects of
   consumer use digital video, including mechanical specifications of a
   cassette, magnetic recording format, error correction on the
   magnetic tape, DCT video encoding format, and audio encoding
   format[1]. The digital interface part of IEC 61883 defines an
   interface  on an IEEE 1394 network[2,3]. This specification set supports
   several video formats: SD-VCR (Standard Definition), HD-VCR (High
   Definition), SDL-VCR (Standard Definition - Long), PALPlus, DVB (Digital
Video
   Broadcast) and ATV (Advanced Television). North American formats are
indicated
   with a number of lines and "/60", while European formats use "/50".
   DV standards extended for professional use were published by
   SMPTE as 306M and 314M, for higher color resolution and faster bit
rates[4,5].

   IEC 61834 also includes magnetic tape recording for digital TV
   broadcasting systems (such as DVB and ATV) that use MPEG2 encoding.
   The payload format for encapsulating MPEG2 into RTP has already been
   defined in RFC 2250[7] and others. 

   Consequently, the payload specified in this document will
   support six video formats of the IEC standard: SD-VCR (525/60,
   625/50), HD-VCR (1125/60, 1250/50) and SDL-VCR (525/60, 625/50), and
   six of the SMPTE standards: 306M (525/60, 625/50), 314M 25Mbps (525/60,
625/50)
   and 314M 50Mbps (525/60, 625/50). In the future it can be extended
   for other high-definition formats.

   Throughout this specification, we make extensive use of the
   terminology of IEC and SMPTE standards. The reader should consult the
   original references for definitions of these terms.

3. DV format encoding

   <delete first paragraph> The DV format the DCT compression technique only

   within each frame, contrasting with the interframe compression
   of the MPEG video standards [ref]. 

"Audio data part" should be "The audio data"

several DIF sequence. should be "several DIF sequences."

Section 4.1

"in VAUX. Because" should be "in VAUX, because"

   ... Even if VAUX data is
   received, the receiver cannot obtain the attribute until the video
   encoding format is determined.

This sentence is confusing, and I think is just trying to say what has
already been said - use payload types to determine format, not the DV
stream. It is ambiguous, however, in the bundled case, if just changing the
audio format counts as a payload type change? Looks like "no" in this draft.

Section 4.2:

It is not clear if Header and Subcode DIF blocks may, should or must be
sent?

How can the sender omit AAUX blocks in a bundled stream? If so, then all the
audio information must be specified in ugly "a-encode" lines like the
previous draft, but those are now gone? So I would say remove the reference
to AAUX here. They are not separate DIF blocks anyway, but embedded in the
Audio blocks, so just passing them through sounds like the best idea.

Section 5:

   ... SDP carries several m=?? lines which is for media type ...
should be:
   ... SDP carries several m=?? lines, one for each media type ...

Section 5.2:

"Too many audio formats" omit "Too", please be objective (thought I agree!).

flame --> frame

Reword middle of paragraph to:

   ... These attributes are carried as
   AAUX data within audio DIF blocks. Describing all these attributes
   with SDP would require large SDP descriptions to enumerate
   all combinations.  Therefore, the SDP entry to describe bundled streams
   does not include audio format parameters.

Does it include video format parameters? MAY? The example uses "encode:"
instead of "v-encode:" why be inconsistent?

Looking forward to implementations, 
	Bill Nowicki
	Omneon Video Networks
	408-558-2126

---

From: Tobias Öbrink <[email-masked]>
Date: Fri, 22 Oct 1999 09:56:58 +0200 (MET DST)

On Thu, 21 Oct 1999, Bill Nowicki wrote:

:
:
> Looking forward to implementations, 

There are at least three implementations under way that I know of:

http://www.sfc.wide.ad.jp/DVTS

http://www.it.kth.se/~nv91-tob/Report/Prototype/

And Carsten Bormann has something brewing. I have no pointer to that 
work, though.

/Tobias
............................................................................
Tobias Öbrink                 Grad. Stud. Dept. of Teleinformatics, KTH
Phone numbers:				Paper mail address:
	+46 8 752 14 75 (IT, work)		KTH-ELECTRUM/204
        +46 8 751 17 93 (Fax)			S-164 40 Kista
						Sweden
E-mail: [email-masked]	URL: http://www.it.kth.se/~nv91-tob/
See if I'm logged in: http://www.it.kth.se/~nv91-tob/notice.html

---

From: ikob <[email-masked]>
Date: Fri, 22 Oct 1999 20:21:57 +0900

Bill,

Thanks for useful comment.

From: Bill Nowicki <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-avt-dv-video-01.txt
Date: Thu, 21 Oct 1999 17:46:41 -0700
Message-ID: <[email-masked]>

> a space before open parentheses consistently.

We will correct them in the next publication.

> be useful. 

I agree it, the name DVCPRO and Digital-S are well known compared with
SMPTE standard number. I don't know the exact attitude of IETF for
trademark. If we can import it without trouble, it is better to clearly
specify trademark.

Does someone know the IETF attitude or the reference concerning 
the trademark issue ?

> The professional 25Mbps variants are generally the same DV

I think generally the same. But system data treatment is different,
it is safe to distinguish them. As you mentioned, the picture sampling
structures in 625 are not the same, cunsumer uses 4:2:0 and
professional is 4:1:1. I think this difference is not small.
In the implementation, same CODEC hardware and software can be used
with mode switching.

> nobody uses it that I know of.

The relation between SDL and SD is the same between LP and standard
on DAT. That standarization is working in IEC SC100B/PT 61834-6.
The SDL is also specified in the BlueBook.

> are redundant. Suggested rewording:

Thanks, we will incorporate your input in the next draft.

..snip..

> audio format counts as a payload type change? Looks like "no" in this draft.

In bundled case, only audio format changing is permitted. How about
remove sentence bellow as ?

     ... Although VAUX data contains some encoding attributes of
     the stream, the sender MUST NOT expect to notify the receiver
     of an encoding format change with the information included
     in VAUX because the packet carrying the VAUX data might be lost.

And changes the sentence concerning VAUX:

     ...Even if the VAUX data is received, the receiver cannot obtain
     the attributes until the video encoding format is determined
     because the VAUX data only represents sub-attribute information
     which relies on the video encoding format.

> It is not clear if Header and Subcode DIF blocks may, should or must be

Add sentence as:

    ...Other system data header and subcode DIF block MAY also be
    sent. When header and subcode DIF blocks is sent, the both blocks
    MUST be included in the video stream.

> Audio blocks, so just passing them through sounds like the best idea.

I think our draft only say as "... send null AAUX information 
and omit VAUX DIF block....". If this sentence leads other people in
confusion, we have to change it.

> Section 5:

..snip..

>    does not include audio format parameters.

We will change to:

    This includes audio attribute information carried as AAUX data within
    audio DIF blocks. Many audio format attributes are defined in DV, such
    as sampling, quantization, number of audio channels, channel
    assignment, language, emphasis and the picture frame locking.
    Describing all these attributes with SDP would require large SDP
    descriptions to enumerate all combinations.  Therefore, the SDP entry
    to describe bundled streams does not include audio format parameters.

> Looking forward to implementations, 

If we get stable implementation, we will demonstrate in opportunity.

                                              [email-masked]