This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22692 - <video> readyState should be HAVE_NOTHING before video arrives
Summary: <video> readyState should be HAVE_NOTHING before video arrives
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-16 08:54 UTC by Harald Alvestrand
Modified: 2013-08-27 08:56 UTC (History)
1 user (show)

See Also:


Attachments

Description Harald Alvestrand 2013-07-16 08:54:28 UTC
In the current MediaCaptureAndStreams spec (4 July version), the following description is given:

readyState	unsigned short	HAVE_ENOUGH_DATA

with comment: "The media is provided locally in real time, so there is always enough data to play. (A MediaStream with no Tracks is equivalent to a downloaded file that contains no playable data.)"

This gives surprising behaviour for remote media streams, which pop into existence before the first frame of the video arrives. It's also potentially an issue with cameras that have long initialization times.

I suggest that we change this to be:

HAVE_NOTHING   before the first video frame arrives
HAVE_ENOUGH_DATA   after the arrival of the first video frame
Comment 1 Harald Alvestrand 2013-08-27 08:56:40 UTC
Resolved in 20130824 version of MediaCapture.