Networking/Archive/DASH/Implementation: Difference between revisions
| Line 38: | Line 38: | ||
'''Description needed''' | '''Description needed''' | ||
''''Question: What XML parsing capabilities do we have in Gecko?'''' | |||
== Capability/Load Monitoring == | == Capability/Load Monitoring == | ||
Revision as of 02:02, 11 January 2012
Work in progress
This design page for DASH implementation in Gecko is focused on the Networking/Necko code to be implemented.
Current Design and Behavior of non-adaptive streams
With current native video, Necko buffers the data until it is safe to start playing. nsMediaChannelStream downloads data via HTTP and puts that data in an nsMediaCache. nsMediaCache in turn makes this data available to decoder threads via read() and seek() APIs. The decoders then read the data and enqueue it in A/V queues.
Diagram needed
High Level Approaches - Segment Request and Delivery to MediaStream/MediaCoder
Two initial ideas were suggested by Rob O'Callahan:
- One nsMediaDASHStream class is created which manages the monitoring of local capabilities/load and adapts download by switching streams as necessary. Then one nsMediaCache provides data to a single nsWebMDecoder.
Diagram needed
Description needed
- One nsMediaDASHStream as before, but with multiple nsWebMDecoders, one for each encoded stream available on the server. Only one nsWebMDecoder would be used at a time.
Diagram needed
Description needed
Question: Are these approaches possible? Can a single MediaCoder handle multiple streams? Can a single MediaStream handle changes in bitstream coming from DASH?
MPD
Diagram needed
Description needed
MPD Classes and Objects
Diagram needed
Description needed
MPD Parsing and Behavior
Diagram needed
Description needed
'Question: What XML parsing capabilities do we have in Gecko?'
Capability/Load Monitoring
How will this be provided?
Media Segments
Diagram needed
Description needed
Media Segment Classes and Objects
Diagram needed
Description needed