Re: [rtcweb] compressed codec-free webrtc?

[Magnus Westerlund <[e-mail]>]

Hi,

I think using RAW video is completely out of the question for general
WebRTC usage, however I would note that the specification needed to
encapsulate RAW video is available as RTP payload formats, so you are
free to implement and offer them in signalling.

RTP Payload Format for Uncompressed Video
Which supports up to 32768 scan lines and pixels per line. It also
supports various samplings and color spaces.

http://tools.ietf.org/html/rfc4175
Data rate will depend on resolution, frame-rate and sampling.

RTP Payload Format for Society of Motion Picture and Television
Engineers (SMPTE) 292M Video

http://tools.ietf.org/html/rfc3497

Total data rate be either 1.485 Gbps or 1.485/1.001 Gbps.

Cheers

Magnus


On 2013-10-30 04:00, Randell Jesup wrote:
> On 10/29/2013 4:00 PM, Dave Taht wrote:
>> On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach <[e-mail]> wrote:
>>> On 10/29/13 13:33, Dave Taht wrote:
>>>
>>> In having my eyes glaze over at the codec debate I found myself
>>> wondering to what extent anyone was pursuing truly low latency video
>>> and audio, along the lines of what the lola project has been doing for
>>> collaborative concerts.
>>>
>>> See:
>>>
>>> http://www.conts.it/artistica/lola-project
>>>
>>> They ship raw audio and raw video, they actually use cameras where
>>> they can get at scanlines and ship that (saving 16ms)
> 
> Yeah, such things are not the norm unless you build hardware at a low
> level; OS-level access is only at the frame level generally. Also, there
> are costs to pushing that many bits around, even in a local network. 
> (Check your network interface overhead when pushing that many bits!) 
> However: You could use slicing or equivalent to get almost the same
> delay characteristics at HUGELY lower datarates.
> 
> For example, use one-MB high slices with current-tech codecs or
> something very similar.  Compression will kinda suck (well, not so much
> if you let it reference previous slices in the same frame and later
> slices in previous frames), but for standard def (480/60p let's say) the
> inherent delay would be on the order of 0.5ms, perhaps with another
> 0.5ms for encode time (max, otherwise we aren't keeping up with 60fps. 
> For 30p it would be 2ms max.  I don't know about you, but I would have
> trouble seeing 2ms delay.  And how are you guaranteeeing you're not
> seeing a 16/33ms sync delay at the other end?  Are you somehow
> genlocking the displays?  Not *impossible*, but pretty unlikely.
> 
> Memory bandwidth >>> network bandwidth, even fiber, though realistic
> interfaces.   And display tech matters.  I think there must be some FUD
> out there about how compression delays everything and makes it
> problematic.  The one place where such tight latencies matter is audio
> (distributed bands, etc), and there speed-of-light (and
> speed-of-interfaces) are what trip you up generally.  There are video
> equivalents (coordinated remote dance, etc) - but you still have to
> solve the capture and display problems, and compression per se isn't the
> major problem (no new tech is needed, just correct use of current
> tech/codecs I think).
> 
> Brings to mind "Racing the beam".... ;-)
> 
>>>
>>> So I'm ignorant of what webrtc can do is there a codec selection (yuv?
>>> 48 bit audio? for the rawest video and audio possible?)
>>>
>>>
>>> In theory, what you're looking for is this:
>>> http://tools.ietf.org/html/rfc4175
>> Thank you!
>>
>>> However, the caveats in that document are pretty huge:
>>>
>>>     It is important to note that uncompressed video can have immense
>>>     bandwidth requirements (up to 270 Mbps for standard-definition
>>> video,
>>>     and approximately 1 Gbps for high-definition video).  This is
>>>     sufficient to cause potential for denial-of-service if transmitted
>>>     onto most currently available Internet paths.
>>>
>>>
>>> Given the risk of Destroying The Internet Forever[tm] if any major
>>> browser
>>> vendor implemented this, I don't expect you'll see much deployment
>>> any time
>>> soon.
>> I don't see people doing videoconferences in the same qty as we do,
>> say, torrents (famous last words!). Certainly the panopticon might
>> take over the internet (but in that case delays from encoding should
>> be acceptable to our new robotic panoptic overloads, it's just the
>> pesky humans that have trouble with latency)
>>
>> So, maybe running at rates like this would trouble the "Internet" a
>> bit now, but on internal networks, not so much.
>>
>> 270Mbits is a trivial amount of bandwidth for a modern switched
>> network. Homes and businesses that are wired are probably close to
>> universally switched GigE, so internal conversations could possibly
>> run at max speed and minimal latency.
>>
>> Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
>> above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.
>>
>> Removing a serious delay-inducing-encoding step makes things like echo
>> cancellation unneeded, and live lola-like-collaboration possible.
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------