Re: [whatwg] Recording interface (Re: Peer-to-peer communication, video conferencing, and related topics (2))
Sorry for the top posting, but I would like to reiterate my considered
opinion that Speex be supported for recording. It is the standard
format available from Adobe Flash recording, low bandwidth, open
source and unencumbered, efficient, and it is high quality for its
bandwidth.
On Tue, Mar 29, 2011 at 11:37 PM, Stefan Håkansson LK
stefan.lk.hakans...@ericsson.com wrote:
-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
whatwg-requ...@lists.whatwg.org
Sent: den 29 mars 2011 20:33
To: whatwg@lists.whatwg.org
Subject: whatwg Digest, Vol 84, Issue 69
I also believe that the recording interface should be
removed from
this part of the specification; there should be no requirement
that all streams be recordable.
Recording of streams is needed for some use cases unrelated
to video
conferencing, such as recording messages.
Having a recording function is needed in multiple use cases;
I think we all agree on that.
This is mostly a matter of style, which I'm happy to defer on.
The streams should be regarded as a control surface,
not as a data
channel; in many cases, the question of what is the
format of the stream at this point
is literally unanswerable; it may be represented as hardware
states, memory buffers, byte streams, or something
completely different.
Agreed.
Recording any of these requires much more specification
than just
record here.
Could you elaborate on what else needs specifying?
One thing I remember from an API design talk I viewed:
An ability to record to a file means that the file format is
part of your API.
For instance, for audio recording, it's likely that you want
control over whether the resulting file is in Ogg Vorbis
format or in MP3 format; for video, it's likely that you may
want to specify that it will be stored using the VP8 video
codec, the Vorbis audio codec and the Matroska container
format. These desires have to be communicated to the
underlying audio/video engine, so that the proper transforms
can be inserted into the processing stream, and I think they
have to be communicated across this interface; since the
output of these operations is a blob without any inherent
type information, the caller has to already know which format
the media is in.
This is absolutely correct, and it is not only about codecs or
container formats. Maybe you need to supply info like audio
sampling rate, video frame rate, video resolution, ...
There was an input on this already last November:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029069.html
Clearer?
--
Message: 2
Date: Tue, 29 Mar 2011 15:27:58 +0200
From: Wilhelm Joys Andersen wilhel...@opera.com
To: whatwg@lists.whatwg.org
Subject: [whatwg] details, summary and styling
Message-ID: op.vs3w0wvrm3w...@kunnskapet.oslo.osa
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Hi,
I'm currently writing tests in preparation for Opera's implementation
of details and summary. In relation to this, I have a few
questions
about issues that, as far as I can tell, are currently
undefined in the
specification.
The spec says:
If there is no child summary element [of the details element], the
user agent should provide its own legend (e.g. Details). [1]
How exactly should this legend be provided? Should the user agent add
an implied summary element to the DOM, similar to tbody, a
pseudo-element, or a magic non-element behaving differently from both
of the above? In the current WebKit implementation[2], the UA-provided
legend behaves inconsistently from from an author-provided summary
in the following ways:
* Although it can be styled with rules applying to
summary, it does
not respond to :hover or :first-child.
* With regards to text selection, it behaves more like an input
type='submit' than a user-provided summary. Text within this
implied element may only be selected _together_ with the text
preceding and following it.
* A different mouse cursor is used.
This indicates that it is slightly more magic than I would prefer. I
believe a closer resemblance to an ordinary element would be more
convenient for authors - a ::summary pseudo element with Details as
its content() might be the cleanest approach, although that would
require a few more bytes in the author's stylesheet to cater to both
author- and UA-defined summaries:
summary, ::summary {
color: green;
}
Furthermore, the rendering spec says:
The first container is expected to contain at least one line box,
and that line box is expected to contain a disclosure
widget (typically
a triangle), horizontally positioned within the left padding of the
details element. [3]
For user agents aiming to support the suggested default rendering, how
should the disclosure widget be embedded?
[whatwg] Recording interface (Re: Peer-to-peer communication, video conferencing, and related topics (2))
-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
whatwg-requ...@lists.whatwg.org
Sent: den 29 mars 2011 20:33
To: whatwg@lists.whatwg.org
Subject: whatwg Digest, Vol 84, Issue 69
I also believe that the recording interface should be
removed from
this part of the specification; there should be no requirement
that all streams be recordable.
Recording of streams is needed for some use cases unrelated
to video
conferencing, such as recording messages.
Having a recording function is needed in multiple use cases;
I think we all agree on that.
This is mostly a matter of style, which I'm happy to defer on.
The streams should be regarded as a control surface,
not as a data
channel; in many cases, the question of what is the
format of the stream at this point
is literally unanswerable; it may be represented as hardware
states, memory buffers, byte streams, or something
completely different.
Agreed.
Recording any of these requires much more specification
than just
record here.
Could you elaborate on what else needs specifying?
One thing I remember from an API design talk I viewed:
An ability to record to a file means that the file format is
part of your API.
For instance, for audio recording, it's likely that you want
control over whether the resulting file is in Ogg Vorbis
format or in MP3 format; for video, it's likely that you may
want to specify that it will be stored using the VP8 video
codec, the Vorbis audio codec and the Matroska container
format. These desires have to be communicated to the
underlying audio/video engine, so that the proper transforms
can be inserted into the processing stream, and I think they
have to be communicated across this interface; since the
output of these operations is a blob without any inherent
type information, the caller has to already know which format
the media is in.
This is absolutely correct, and it is not only about codecs or
container formats. Maybe you need to supply info like audio
sampling rate, video frame rate, video resolution, ...
There was an input on this already last November:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029069.html
Clearer?
--
Message: 2
Date: Tue, 29 Mar 2011 15:27:58 +0200
From: Wilhelm Joys Andersen wilhel...@opera.com
To: whatwg@lists.whatwg.org
Subject: [whatwg] details, summary and styling
Message-ID: op.vs3w0wvrm3w...@kunnskapet.oslo.osa
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Hi,
I'm currently writing tests in preparation for Opera's implementation
of details and summary. In relation to this, I have a few
questions
about issues that, as far as I can tell, are currently
undefined in the
specification.
The spec says:
If there is no child summary element [of the details element], the
user agent should provide its own legend (e.g. Details). [1]
How exactly should this legend be provided? Should the user agent add
an implied summary element to the DOM, similar to tbody, a
pseudo-element, or a magic non-element behaving differently from both
of the above? In the current WebKit implementation[2], the UA-provided
legend behaves inconsistently from from an author-provided summary
in the following ways:
* Although it can be styled with rules applying to
summary, it does
not respond to :hover or :first-child.
* With regards to text selection, it behaves more like an input
type='submit' than a user-provided summary. Text within this
implied element may only be selected _together_ with the text
preceding and following it.
* A different mouse cursor is used.
This indicates that it is slightly more magic than I would prefer. I
believe a closer resemblance to an ordinary element would be more
convenient for authors - a ::summary pseudo element with Details as
its content() might be the cleanest approach, although that would
require a few more bytes in the author's stylesheet to cater to both
author- and UA-defined summaries:
summary, ::summary {
color: green;
}
Furthermore, the rendering spec says:
The first container is expected to contain at least one line box,
and that line box is expected to contain a disclosure
widget (typically
a triangle), horizontally positioned within the left padding of the
details element. [3]
For user agents aiming to support the suggested default rendering, how
should the disclosure widget be embedded? Ideally, graphical browsers
should all do this in a similar manner, and in a way that
allows authors
to style these elements to the same extent as any other element.
There are several options:
* A ::marker pseudo element[4].
* A default, non-repeating background image positioned within
the recommended 40 pixel left padding.
* A method similar to
[whatwg] Recording interface (Re: Peer-to-peer communication, video conferencing, and related topics (2))
I also believe that the recording interface should be removed from this part of the specification; there should be no requirement that all streams be recordable. Recording of streams is needed for some use cases unrelated to video conferencing, such as recording messages. Having a recording function is needed in multiple use cases; I think we all agree on that. This is mostly a matter of style, which I'm happy to defer on. The streams should be regarded as a control surface, not as a data channel; in many cases, the question of what is the format of the stream at this point is literally unanswerable; it may be represented as hardware states, memory buffers, byte streams, or something completely different. Agreed. Recording any of these requires much more specification than just record here. Could you elaborate on what else needs specifying? One thing I remember from an API design talk I viewed: An ability to record to a file means that the file format is part of your API. For instance, for audio recording, it's likely that you want control over whether the resulting file is in Ogg Vorbis format or in MP3 format; for video, it's likely that you may want to specify that it will be stored using the VP8 video codec, the Vorbis audio codec and the Matroska container format. These desires have to be communicated to the underlying audio/video engine, so that the proper transforms can be inserted into the processing stream, and I think they have to be communicated across this interface; since the output of these operations is a blob without any inherent type information, the caller has to already know which format the media is in. Clearer?
