Re: publish FPWD of Media Capture Depth Stream Extensions; respond by 26 Sept 2014.

Ningxin, you also proposed an approach based on using existing codecs in 
our Use Case document - reference 8

http://www.w3.org/wiki/Media_Capture_Depth_Stream_Extension#References
[8] http://web4.cs.ucl.ac.uk/staff/j.kautz/publications/depth-streaming.pdf

For the benefit of others that haven't read that reference, this 
approach tunnels depth data through existing codecs. In this model the 
depth stream is an encoded media stream just like a video media stream 
and that then makes it clear what addTrack(mst) should do - just add it 
to the "track set" like normal.

Perhaps we should call this out more explicitly in the Use Case document 
and maybe add some discussion about it in the spec? Or do implementers 
see this as just an implementation detail? Open to comments/suggestions...

roBman


On 24/09/14 7:20 AM, Hu, Ningxin wrote:
> Hi Harald,
 >
 >> This seems to be a multifaceted thing, since I don't know how a
 >> depth channel should be represented across the network either;
 >> there are H.26x extensions for carrying depth channels inside a
 >> video stream, but I'm not sure those extensions are supported by
 >> the relevant RTP formats.
 >>
 >
 > Thanks for the comments. I captured it as an issue [1]
 >
 > For depth representation across the network, what are your thoughts
 > on 3D Video in the Session Description Protocol (SDP) [2]?
 >
 >> And how is a depth channel best represented if there's no
 >> associated video?
 >
 > For 3D video use case, depth channel should have associated video.
 > However, for some use cases, such as depth-based hand tracking, it
 > might only need depth info. WDYT?
 >
 > Thanks, -ningxin
 >
 > [1] https://github.com/w3c/mediacapture-depth/issues/12 [2]
 > http://tools.ietf.org/html/draft-capelastegui-mmusic-3dv-sdp-00
 >
 >>
 >>>
 >>> [This should not block the FPWD publication, however.]
 >>>
 >>> Thanks,
 >>>
 >>> -Anssi
 >>>
 >>> [1] https://github.com/w3c/mediacapture-depth/issues/18
 >>

Received on Tuesday, 23 September 2014 23:14:46 UTC