Re: [media cap] 1st draft agenda for telco

On 2/8/2012 1:24 PM, Travis Leithead wrote:
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>
>> On 02/07/2012 10:06 AM, Travis Leithead wrote:
>>> Rich brought up a topic a while ago that may merit some discussion, as
>> I'm also interested in the same:
>>>
>>> Rationale for keeping the definition of the MediaStream interface in the
>> WebRTC spec.
>>>
>>> I know that both PeerConnection and getUserMedia are entry points to
>>> get/create media streams. So I'd like to start a conversation about which
>>> spec should define the MediaStream interface and why.
>>
>> We've been over this before (thread "Defining the split..." starting on
>> Dec 7).
>> It petered out pretty quickly, with comments only from you, me and Rich
>> Tibbett (who started the thread, and then fell silent).
>>
>> I'd like to hear from more people before declaring that it's interesting
>> to reopen the issue.
>> (reviewing the thread, I also see that I did not respond to your last
>> questions on the thread; do you want to reopen those, or have they
>> become overtaken by events in the meantime?)
>
> My questions at the end of that thread [1] still stand. I don't have a strong
> grasp on the prior discussions that have formed your view on what the
> MediaStream is. To that end, some of the arguments you make don't make sense
> to me.
>
> I think hearing some background from you during our upcoming call would be helpful
> to me, and perhaps others.
>
> [1] http://lists.w3.org/Archives/Public/public-media-capture/2011Dec/0055.html

I wasn't part of that background either, but I have some ideas on your 
question here:

     For example, what's the "stream of bytes fallacy", and why is it
     a poor view of a MediaStream? Also, would love more info on what
     you say just below:

     >A MediaStream is not a stream of bytes. At some points it can be
     >represented as one; at other poitns it may create one. But it
     >isn't one.

A mediastream (ok, a mediatrack) is not a stream of bytes, it's a stream 
of data structured into frames/samples.  For video, those are fairly 
large entities with potentially more and more complex formats.  For 
audio, the frames are typically quite short and the structure is 
simpler. But they're not streams of bytes.

And in fact it's more complex than just a stream of samples - each 
sample also has implicit or explicit metadata associated with it 
(timestamps, for example, and size information and frame format for 
video, perhaps camera orientation info, etc).  Nothing says that a video 
mediatrack must have all captured frames the same size.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 8 February 2012 21:08:45 UTC