Subject: [AVT] RE: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt

From: Dave Singer <[email-masked]>
Date: Thu, 6 Nov 2003 10:33:35 -0800

I am not attending MPS so I'm going to give my comments here.  I hope 
they're helpful.

My comments on the draft are in roughly three buckets:  (a) whether 
we should have it at all (b) the overall nature of the draft, (c) 
detailed comments and (d) where to go.

(a) Do we want it at all?

I think yes, for the following reasons.

Ideally, we see an authoring language from w3c, for which there is a 
similarly powerful RTP expression, and that these are supersets of 
the 3GPP format.

But the ideal is unlikely.  For a start, the w3c format is designed 
to be able to express things as diverse as 3GPP and EIA sub-titling. 
It is unlikely that any given delivery system will be able to carry 
everything that can be expressed in the w3c format;  profiles will be 
needed for different delivery environments.  A generic timed text 
format, which would need to cover captioning (both for hearing 
disabled and for language, which are different), displayed timed text 
(e.g. titling), karaoke, ticker tapes, and so on.  Having 
participated in the w3c discussions so far, I am realizing how broad 
this question is.  This is akin to searching for a generic 'video' 
payload format, or, dare I say it, a generic MPEG-4 format!

Secondly, I don't see a reason why text (which is a data type) 
shouldn't be treated like video.  That is, different ways to express 
('compress') the text are conveyed in different 'codecs' and 
different payload formats.  We tried a fairly general-purpose format 
in the MPEG-4 'simple' draft and it was not pleasant.  Targetted 
formats for well-defined coding systems work better.

So, I am not convinced that a targetted 3GPP timed text format is 
'wrong'.  As long as we admit that there may (will) be a family of 
text presentation formats (like audio and video), it is not a 
problem, either.

(b) Overall comments.

The 3GPP timed text spec is conceptually pretty simple;  this payload 
format seems pretty complex.  There are several bit-fields, for 
example.  It uses two payload type indicators.  I think that we can 
use one payload type indicator, and one header which tells us (i) is 
the 'static information' present? (ii) is this a single fragment or a 
set of whole samples? (iii) what are the various offsets etc.

I get the idea of giving the explicit offset to the start of a box, 
and also the need to 'place' a fragment in the string, and so on. 
I'm just aware that it comes across complex as is, and wonder if we 
can't skin it slightly differently -- possibly at the expense of a 
few bytes for unusual cases -- for a simpler spec.

I'm willing to spend time in this direction if there is consensus 
that such an exploration take place.

(c) Details.

I have a number of detailed comments:  things talked about before 
they are defined (e.g. T=1 in 4.1);  what is the SIDX field for? and 
so on.  However, I'd rather see us work out the direction in general 
(a) and the approach (b) before dealing with details.

(d) Where to go.

I think we should proceed with this.  Though it is not on the table 
for release 6 of 3GPP officially, no-one there will object if text 
becomes streamable:  it's a useful good idea.  I don't think the W3C 
work is either going to complete soon, or be a direct translation 
into an RTP format, and that's the only 'bigger' idea on the horizon. 
And I don't think this should be shoe-horned into the MPEG-4 payload 
format either;  it has unique needs (and it ought to be possible to 
make it simpler).

A liaison or communication from the chairs to 3GPP and W3C saying 
what the Minneapolis meeting thinks is the direction would be prudent 
and courteous, however.
-- 
David Singer
Apple Computer/QuickTime

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

---

From: "Jose Rey" <[email-masked]>
Date: Fri, 7 Nov 2003 10:15:11 +0100

Hi Dave,

thanks for your comments. I also think it is better to stay in the
abstract plane for now, and leave the details for later...and I
appreciate very much your readiness to help. Please see inline.

---cut---
> that such an exploration take place.

Yes, the draft is pretty complex and yes we can make it simpler, of
course by having more overhead. The draft has a lot of functionalities,
which would probably (?) be seldom used. The question is where and how
to cut down.

In particular, the thing that 'bothers' me most is the following: the
draft allows for self-contained packets of the two kinds of text sample
fragments: those containing text strings and those that not.  Apart from
the current composition of the headers, 1) do we want to keep that? 2)
or is it enough to guarantee the display of just the text strings
(plain) in the case of packet losses? Is it correct to assume modifier
boxes would very seldom expand over several RTP packets so that the
effort for specific modifier field fragment headers would not be worth?
or is it preferable to stay in the safe side and contemplate those rare
cases also by introducing overhead? Comments are welcome!

> (a) and the approach (b) before dealing with details.

I agree, I prefer to comment this later, it might change.

> what the Minneapolis meeting thinks is the direction would be prudent

Good idea.

cheers,

Jose