autobuffer attribute?

[Christopher Blizzard]

What's the behaviour of autobuffer? Does it try to buffer the entire
video up to the size of the media cache?

--Chris

[Robert O'Callahan]

On Thu, May 28, 2009 at 5:25 AM, Christopher Blizzard
<bliz...@mozilla.com>wrote:

> What's the behaviour of autobuffer? Does it try to buffer the entire video
> up to the size of the media cache?
>

Yes. Note that the media cache is shared among all media streams so we
actually divide up the media cache so each stream gets a fair share.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

[Christopher Blizzard]

On May 27, 2009, at 3:59 PM, Robert O'Callahan wrote:

> On Thu, May 28, 2009 at 5:25 AM, Christopher Blizzard <bliz...@mozilla.com
> > wrote:
> What's the behaviour of autobuffer? Does it try to buffer the
> entire video up to the size of the media cache?
>
> Yes. Note that the media cache is shared among all media streams so
> we actually divide up the media cache so each stream gets a fair
> share.

Great, thanks. Sheppy has apparently updated the docs.

You guys might want to have a quick look through these pages to make
sure they look OK, just FYI:

https://developer.mozilla.org/En/HTML/Element/Video
https://developer.mozilla.org/En/HTML/Element/Audio
https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox

--Chris

[Robert O'Callahan]

On Thu, May 28, 2009 at 8:05 AM, Christopher Blizzard
<bliz...@mozilla.com>wrote:

> On May 27, 2009, at 3:59 PM, Robert O'Callahan wrote:
>
> On Thu, May 28, 2009 at 5:25 AM, Christopher Blizzard <
> bliz...@mozilla.com> wrote:
>
>> What's the behaviour of autobuffer? Does it try to buffer the entire
>> video up to the size of the media cache?
>>
>
> Yes. Note that the media cache is shared among all media streams so we
> actually divide up the media cache so each stream gets a fair share.
>
>
> Great, thanks. Sheppy has apparently updated the docs.
>
> You guys might want to have a quick look through these pages to make sure
> they look OK, just FYI:
>
> https://developer.mozilla.org/En/HTML/Element/Video
> https://developer.mozilla.org/En/HTML/Element/Audio
> https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox
>

These pages need links to the HTML5 spec. All the elements, attributes
events and APIs are defined in HTML5, in much more detail than in these
pages here, which is fine as long as we link to the real definitions.

I'm going to make some other edits. For example the 'controls' attribute on
<audio> is supported.

[Robert O'Callahan]

On Thu, May 28, 2009 at 9:33 AM, Robert O'Callahan <rob...@ocallahan.org>wrote:

> I'm going to make some other edits. For example the 'controls' attribute on
> <audio> is supported.
>

Also, I think there should be a page on supported media types, listing the
supported types and their MIME names, and describing how to use the 'codecs'
parameter as per http://www.rfc-editor.org/rfc/rfc2361.txt. Eric, can you
add that?

The Wave types are:
"audio/x-wav",
"audio/wav",
"audio/wave", (preferred)
"audio/x-pn-wav"
with Wave codec "1".

The Ogg types are
"video/ogg", (preferred)
"audio/ogg", (preferred)
"application/ogg"
with codecs
"vorbis"
"theora"

[Eric Shepherd]

I'll take care of all these things this evening and drop another reply
once that's done. Just back from dinner, and about to go into a
meeting, but wanted to let you know I'm on it right after that.

Eric Shepherd
Developer Documentation Lead
Mozilla Corporation
http://www.bitstampede.com/

[Eric Shepherd]

On 5/27/09 5:33 PM, Robert O'Callahan wrote:
> These pages need links to the HTML5 spec. All the elements, attributes
> events and APIs are defined in HTML5, in much more detail than in these
> pages here, which is fine as long as we link to the real definitions.

I've added the links to the pages that didn't already have them (some
did, some didn't).

> I'm going to make some other edits. For example the 'controls' attribute
> on <audio> is supported.

Thanks; it wasn't at the time I wrote the document, so that's appreciated.

--

[Eric Shepherd]

On 5/27/09 5:39 PM, Robert O'Callahan wrote:
> Also, I think there should be a page on supported media types, listing
> the supported types and their MIME names, and describing how to use the
> 'codecs' parameter as per http://www.rfc-editor.org/rfc/rfc2361.txt.
> Eric, can you add that?

https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements

Let me know if there's anything confusing or wrong there.

[Robert O'Callahan]

On Thu, May 28, 2009 at 1:08 PM, Eric Shepherd <eshe...@mozilla.com>wrote:

> On 5/27/09 5:39 PM, Robert O'Callahan wrote:
>
>> Also, I think there should be a page on supported media types, listing
>> the supported types and their MIME names, and describing how to use the
>> 'codecs' parameter as per http://www.rfc-editor.org/rfc/rfc2361.txt.
>> Eric, can you add that?
>>
>
>
> https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements
>
> Let me know if there's anything confusing or wrong there.
>

Thanks! I guess one potentially confusing thing is that the video/ogg and
application/ogg types can include a Vorbis track.

Another thing we might want to explain somewhere is how to use the MIME
"codecs" parameter to write detailed types for media files that include
codec information. (See http://www.rfc-editor.org/rfc/rfc4281.txt.) We
should recommend that authors do this, because it will help future-proof
their content. For example, authors might want to use the type "video/ogg;
codecs=vorbis,theora" so that if some browser supports the Ogg container and
the Vorbis codec, but not the Theora codec, it will know to skip that
content. Or they could use "video/ogg; codecs=vorbis,dirac" and Firefox 3.5
will know to skip it.

[Robert O'Callahan]

On Thu, May 28, 2009 at 1:25 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:

> On Thu, May 28, 2009 at 1:08 PM, Eric Shepherd <eshe...@mozilla.com>wrote:
>
>> On 5/27/09 5:39 PM, Robert O'Callahan wrote:
>>
>>> Also, I think there should be a page on supported media types, listing
>>> the supported types and their MIME names, and describing how to use the
>>> 'codecs' parameter as per http://www.rfc-editor.org/rfc/rfc2361.txt.
>>> Eric, can you add that?
>>>
>>
>>
>> https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements
>>
>> Let me know if there's anything confusing or wrong there.
>>
>
> Thanks! I guess one potentially confusing thing is that the video/ogg and
> application/ogg types can include a Vorbis track.
>

One way of addressing this would be to organize by container first: Wave and
Ogg, and the MIME types to use for those containers. Then within each
container, list the codecs we support, with the official codec name, and say
a little bit about each one. Note that the Wave PCM codec's name is "1".

[Eric Shepherd]

On 5/27/09 9:25 PM, Robert O'Callahan wrote:
> Another thing we might want to explain somewhere is how to use the MIME
> "codecs" parameter to write detailed types for media files that include
> codec information. (See http://www.rfc-editor.org/rfc/rfc4281.txt.) We
> should recommend that authors do this, because it will help future-proof
> their content. For example, authors might want to use the type
> "video/ogg; codecs=vorbis,theora" so that if some browser supports the
> Ogg container and the Vorbis codec, but not the Theora codec, it will
> know to skip that content. Or they could use "video/ogg;
> codecs=vorbis,dirac" and Firefox 3.5 will know to skip it.

This looks like it's something the web server would have to handle, to
report the MIME type as specified. Or is it something that can be
overridden in the HTML?

[Christopher Blizzard]

On May 28, 2009, at 10:35 AM, Eric Shepherd wrote:

> On 5/27/09 9:25 PM, Robert O'Callahan wrote:
>> Another thing we might want to explain somewhere is how to use the
>> MIME
>> "codecs" parameter to write detailed types for media files that
>> include
>> codec information. (See http://www.rfc-editor.org/rfc/rfc4281.txt.)
>> We
>> should recommend that authors do this, because it will help future-
>> proof
>> their content. For example, authors might want to use the type
>> "video/ogg; codecs=vorbis,theora" so that if some browser supports
>> the
>> Ogg container and the Vorbis codec, but not the Theora codec, it will
>> know to skip that content. Or they could use "video/ogg;
>> codecs=vorbis,dirac" and Firefox 3.5 will know to skip it.
>
> This looks like it's something the web server would have to handle,
> to report the MIME type as specified. Or is it something that can be
> overridden in the HTML?

That's all in the client. Server's not involved at that point.

--Chris

[Eric Shepherd]

On 5/27/09 9:28 PM, Robert O'Callahan wrote:
> One way of addressing this would be to organize by container first: Wave
> and Ogg, and the MIME types to use for those containers. Then within
> each container, list the codecs we support, with the official codec
> name, and say a little bit about each one. Note that the Wave PCM
> codec's name is "1".

OK, I've cleaned up the article to hopefully be clearer on this:

https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements

[Eric Shepherd]

On 5/28/09 10:36 AM, Christopher Blizzard wrote:
> That's all in the client. Server's not involved at that point.

Ah, OK, I hadn't previously seen the "type" attribute. Got it.

[Eric Shepherd]

On 5/27/09 9:25 PM, Robert O'Callahan wrote:
> Another thing we might want to explain somewhere is how to use the MIME
> "codecs" parameter to write detailed types for media files that include
> codec information. (See http://www.rfc-editor.org/rfc/rfc4281.txt.) We
> should recommend that authors do this, because it will help future-proof
> their content. For example, authors might want to use the type
> "video/ogg; codecs=vorbis,theora" so that if some browser supports the
> Ogg container and the Vorbis codec, but not the Theora codec, it will
> know to skip that content. Or they could use "video/ogg;
> codecs=vorbis,dirac" and Firefox 3.5 will know to skip it.

I've added some info about this to the doc for the source element as
well to "Using audio and video in Firefox":

https://developer.mozilla.org/En/HTML/Element/Source
https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox

[Robert O'Callahan]

On Fri, May 29, 2009 at 2:35 AM, Eric Shepherd <eshe...@mozilla.com>wrote:

> On 5/27/09 9:25 PM, Robert O'Callahan wrote:
>
>> Another thing we might want to explain somewhere is how to use the MIME
>> "codecs" parameter to write detailed types for media files that include
>> codec information. (See http://www.rfc-editor.org/rfc/rfc4281.txt.) We
>> should recommend that authors do this, because it will help future-proof
>> their content. For example, authors might want to use the type
>> "video/ogg; codecs=vorbis,theora" so that if some browser supports the
>> Ogg container and the Vorbis codec, but not the Theora codec, it will
>> know to skip that content. Or they could use "video/ogg;
>> codecs=vorbis,dirac" and Firefox 3.5 will know to skip it.
>>
>

> This looks like it's something the web server would have to handle, to
> report the MIME type as specified. Or is it something that can be overridden
> in the HTML?
>

This is described in the spec, but both the <source> "type" attribute and
the server MIME type are involved. Basically if you list a <source> element
with a "type" we know we can't handle, we won't even try to load it and skip
to the next <source>. Otherwise we load it, we get the type from the server
and check again if we can handle that, and if we can't, then we skip to the
next <source>. Does that make sense?

[Eric Shepherd]

On 5/28/09 4:02 PM, Robert O'Callahan wrote:
> This is described in the spec, but both the <source> "type" attribute
> and the server MIME type are involved. Basically if you list a <source>
> element with a "type" we know we can't handle, we won't even try to load
> it and skip to the next <source>. Otherwise we load it, we get the type
> from the server and check again if we can handle that, and if we can't,
> then we skip to the next <source>. Does that make sense?

Total sense; I'd inferred that but had forgotten to say it clearly. Now
the docs for the source element say that outright:

https://developer.mozilla.org/En/HTML/Element/Source

[Paul Rouget]

I'd like to talk about these features:
http://blog.mozbox.org/post/2009/05/31/VideoAudioUpdate
(password: foobar)

Can please someone review this post and translate it to a real English from my french-english.

Thanks.

> _______________________________________________
> evangelism mailing list
> evang...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/evangelism
-- Paul

[Chris Double]

I get a 404 - Document not found on this page.

[Paul Rouget]

Chris Double wrote:
> I get a 404 - Document not found on this page.

Sorry, already published:
http://blog.mozbox.org/post/2009/05/31/VideoAudioUpdates