Re: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
I'd like to push back gently on the change from 'text' to 'video', just to test the waters.
The media types 'video' and 'audio' express what you *get* if you decode the stream, not how it is *encoded*. They're not call 'float' or 'integer' or 'huffman', for example. Yet for some reason we want to reserve the media type 'text' for those that express their encoding in printable text, without regard for what they are expressing; this seems inconsistent.
No, that's not it at all. The restrictions on the text type have to do with the nature of the underlying data, not with how it is encoded. For example, there's plenty of use of text types, including text/plain, that requires binary encoding and cannot be accomodated by either 7bit or 8bit encodings. There are, however, more restrictions on text that then are on other top-level types. The fact that there are more restrictions may seem inconsistent, but that's how this stuff was defined long ago and it is way too late to change it.
I don't believe that everything expressed in say XML ought to be considered a 'text' media type, for example.
It's more likely that *nothing* expressed in XML would be considered to be a text media type. Ned
At 9:11 -0700 2/06/05, Ned Freed wrote:
I'd like to push back gently on the change from 'text' to 'video', just to test the waters.
The media types 'video' and 'audio' express what you *get* if you decode the stream, not how it is *encoded*. They're not call 'float' or 'integer' or 'huffman', for example. Yet for some reason we want to reserve the media type 'text' for those that express their encoding in printable text, without regard for what they are expressing; this seems inconsistent.
No, that's not it at all. The restrictions on the text type have to do with the nature of the underlying data, not with how it is encoded. For example, there's plenty of use of text types, including text/plain, that requires binary encoding and cannot be accomodated by either 7bit or 8bit encodings.
There are, however, more restrictions on text that then are on other top-level types. The fact that there are more restrictions may seem inconsistent, but that's how this stuff was defined long ago and it is way too late to change it.
I don't believe that everything expressed in say XML ought to be considered a 'text' media type, for example.
It's more likely that *nothing* expressed in XML would be considered to be a text media type.
Ned
Thanks, but now I am lost. Why is this a 'video' stream and not a 'text' stream, then? -- David Singer Apple Computer/QuickTime
Thanks, but now I am lost. Why is this a 'video' stream and not a 'text' stream, then?
Presumably because the intent is to display this as video. The rules for what can fit under video are pretty loose; this is certainly an acceptable use of the video top-level type. Text, OTOH, is usually thought of as a series of lines and not as a stream of characters. My (incorrect) understanding was that video was an unacceptable choice due to SDP constraints. Without that constraint I would have been pushing for this to go under video from the beginning. Ned
On Thursday, June 2, 2005, 6:32:45 PM, Ned wrote:
Thanks, but now I am lost. Why is this a 'video' stream and not a 'text' stream, then?
NF> Presumably because the intent is to display this as video. The rules for what NF> can fit under video are pretty loose; this is certainly an acceptable use of NF> the video top-level type. Text, OTOH, is usually thought of as a series of NF> lines and not as a stream of characters. Text is certainly a sequence of characters, which may or may not be preformatted into 'lines'. Other characteristics of text are that spell-checking and translation to a different language are reasonable things to do with it. Whether the text/* top level type is like that is another matter again, of course; that type having sufficient problems that it should really not be used for anything much beyond text/plain; charset=us-ascii. NF> My (incorrect) understanding was that video was an unacceptable choice due to NF> SDP constraints. Without that constraint I would have been pushing for this NF> to go under video from the beginning. Timed text, because of its time dependent nature, is an arguable fit for video (but something of a stretch). There is probably a need for a more reasonably defined top level type, like textual/* or something, but the timescales and amount of effort to establish such a thing are non-negligible. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead
At 18:47 +0200 2/06/05, Chris Lilley wrote:
On Thursday, June 2, 2005, 6:32:45 PM, Ned wrote:
Thanks, but now I am lost. Why is this a 'video' stream and not a 'text' stream, then?
NF> Presumably because the intent is to display this as video. The rules for what NF> can fit under video are pretty loose; this is certainly an acceptable use of NF> the video top-level type. Text, OTOH, is usually thought of as a series of NF> lines and not as a stream of characters.
Text is certainly a sequence of characters, which may or may not be preformatted into 'lines'. Other characteristics of text are that spell-checking and translation to a different language are reasonable things to do with it.
Whether the text/* top level type is like that is another matter again, of course; that type having sufficient problems that it should really not be used for anything much beyond text/plain; charset=us-ascii.
NF> My (incorrect) understanding was that video was an unacceptable choice due to NF> SDP constraints. Without that constraint I would have been pushing for this NF> to go under video from the beginning.
Timed text, because of its time dependent nature, is an arguable fit for video (but something of a stretch).
There is probably a need for a more reasonably defined top level type, like textual/* or something, but the timescales and amount of effort to establish such a thing are non-negligible.
Thanks guys. This is clearly a sticky area, and as you say, timed text is presumed to be visually presented (though I guess it could be read aloud) so I guess 'video' is OK. I suspect that the true distinction lies in considering presentation; 'text' types should be presentable by a text-to-speech system (for the vision impaired, for example), whereas 'video' would not be expected to be capable of this. This in turn would suggest moving back to 'text' here, but only if the rules and maybe name of the 'text' type were clarified, and I agree that that is a long road to hoe. I rest my case, let video rule (though I still doubt its true correctness). -- David Singer Apple Computer/QuickTime
There is probably a need for a more reasonably defined top level type, like textual/* or something, but the timescales and amount of effort to establish such a thing are non-negligible.
Agreed. Ned
(I trimmed the 'to' list down to the two lists) I think lots of "application" types contain text, have the feature that "spell-checking and translation to a different language" is a reasonable thing to do. I think these are suitable content features (attributes), not content-type (category), and the top level media type category isn't a good place to add more differentiation. Larry
Ned Freed wrote:
Thanks, but now I am lost. Why is this a 'video' stream and not a 'text' stream, then?
Presumably because the intent is to display this as video. The rules for what can fit under video are pretty loose; this is certainly an acceptable use of the video top-level type. Text, OTOH, is usually thought of as a series of lines and not as a stream of characters.
My (incorrect) understanding was that video was an unacceptable choice due to SDP constraints. Without that constraint I would have been pushing for this to go under video from the beginning.
You are correct it is not SDP that limits the usage, the question is what the right type is. 3GPP Timed text is clearly text and it is displayed as lines. However it also has connections to video by being specified to placed as an overlay in a specific part of the video display. In addition certain of the modifiers create video-like modifications of the text strings. Especially the karaoke modifier that repaint the characters with a time dependent speed. So it is text, but with a twist. My opinion is that this still is text and many streams will be possible to display on a text only device. You can could in fact make a stock ticker that receives this format. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
On 2 Jun 2005, at 18:04, Magnus Westerlund wrote:
Ned Freed wrote:
Thanks, but now I am lost. Why is this a 'video' stream and not a 'text' stream, then?
Presumably because the intent is to display this as video. The rules for what can fit under video are pretty loose; this is certainly an acceptable use of the video top-level type. Text, OTOH, is usually thought of as a series of lines and not as a stream of characters. My (incorrect) understanding was that video was an unacceptable choice due to SDP constraints. Without that constraint I would have been pushing for this to go under video from the beginning.
You are correct it is not SDP that limits the usage, the question is what the right type is. 3GPP Timed text is clearly text and it is displayed as lines. However it also has connections to video by being specified to placed as an overlay in a specific part of the video display. In addition certain of the modifiers create video- like modifications of the text strings. Especially the karaoke modifier that repaint the characters with a time dependent speed.
So it is text, but with a twist. My opinion is that this still is text and many streams will be possible to display on a text only device. You can could in fact make a stock ticker that receives this format.
And, it's straightforward to strip the formatting, and display as generic text. Colin
Magnus Westerlund <magnus.westerlund@ericsson.com> writes:
You are correct it is not SDP that limits the usage, the question is what the right type is. 3GPP Timed text is clearly text and it is displayed as lines. However it also has connections to video by being specified to placed as an overlay in a specific part of the video display.
Ummm. So anything that can be eventually displayed (on a monitor or other screen, since text could be displayed on a text-only display or beeper, etc) is "video"? This really, really rubs me the wrong way. It just feels "wrong". Now, it can be under anything. But what's the _purpose_ and effect? Often, applications using SDP limit the number of streams of a type (1 audio, 1 video, etc). Now, they could relax that, but it starts adding complexity to the negotiations ("1 video but 2 if one (and only one) of the streams selects a text payload type"). It makes sense for it to be video if it's intended to be in the same stream as "real" video as an alternate payload type (as an overlay on video). Maybe that's the case, in which case I partly withdraw my objection.
In addition certain of the modifiers create video-like modifications of the text strings. Especially the karaoke modifier that repaint the characters with a time dependent speed.
I wouldn't consider that "video-like". Non-static, but not video-like.
So it is text, but with a twist. My opinion is that this still is text and many streams will be possible to display on a text only device. You can could in fact make a stock ticker that receives this format.
Stock ticker, "beeper", IM-specific device, cell SMS messages, scrolling-text displays in stores, etc, etc. Note: I really haven't been following this, so take my comments with a block of salt. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team rjesup@wgate.com
participants (7)
-
Chris Lilley -
Colin Perkins -
Dave Singer -
Larry Masinter -
Magnus Westerlund -
Ned Freed -
Randell Jesup