I actually agree with this -- I think that MPEG-4 already has lots of heavy
weight behind it and is quite a good format with lots of existing
implementations. Theora/Vorbis are definitely the upstarts in this; they
should live and die on their technical merits and adoption, not because of
In this case, there is a big difference between streamed data, which
can be played from various positions, and non-streamed data which
requires a complete download, or at least the start of the file.
Perhaps there should be some reflection of this in the tag?
On 23 Mar 2007, at 03:15,
Not in the EU, no such thing as a software patent.
On 23 Mar 2007, at 04:55, Ian Hickson wrote:
On Fri, 23 Mar 2007, Robert Sayre wrote:
MPEG-4 is proprietary, because it is covered by patents.
I hate to be the one to break this to you, but CSS is covered by
patents,
HTML is covered by
On Mar 23, 2007, at 02:04, Christoph Päper wrote:
(Why is i class=var better than var?)
It isn't. But i is better than var for editor UIs if all you
want to do is to italicize (the common case).
Isn't this a very western point of view?
Perhaps, but it is still the common case, because
Hi Vladimir,
Lets put any idea of using MPEG4 in the standard at rest right away.
Unless someone has a brilliant idea for who the open source and freely
distributable Firefox would avoid becoming non-distributable in large
parts of the world, and still conform to the standard by including MPEG4
Gareth Hay schrieb:
Not in the EU, no such thing as a software patent.
To my knowledge the MPEG patents are *not* software patents but are what
I know as Verfahrenspatente (crudely translated that would be Method
patents - anyone knowning the correct term?). Those patents are valid here.
[EMAIL PROTECTED] schrieb:
I actually agree with this -- I think that MPEG-4 already has lots of heavy
weight behind it and is quite a good format with lots of existing
implementations. Theora/Vorbis are definitely the upstarts in this; they
should live and die on their technical merits
It is an Urban Legend that there are no software patents in the EU. True
enough there is no 'EU' software patents, but a lot of member states do
have them. I suggest going the MPEG LA's webpage and looking at the
patent lists they have there for MPEG4. You will notice that a lot of
the patents are
Maciej Stachowiak schrieb:
This is true of hardware audio decoders, but not hardware video
decoders, which use dedicated circuit blocks. If Ogg suddenly became
popular it would likely be a several year pipeline before there were any
hardware decoders.
I'd say that any hardware player using
On 3/23/07, Sander Tekelenburg [EMAIL PROTECTED] wrote:
I don't know of a video container format that allows named anchors to be
specified, though.
QuickTime let's authors define points in a .mov container as chapters,
which, in the cotext of the Web, could function as named anchors I'd
Håkon Wium Lie schrieb:
Does Dirac aim at becoming a member in the Ogg family, or are you
primarily working towards a standalone format?
Dirac is container neutral to my knowledge. The implementation targeted
at end-users is embedding it in Ogg, though, so it can e.g. use the free
Ogg audio
* Christian F.K. Schaller wrote:
All w3c standards are royalty free and there is no reason why this
proposal should be different in that regard. And as Håkon Wium Lie
pointed out in another email, the latest SVG standard already mandates
Vorbis support, so half of what is needed is already
Hi Bjoern,
There is a w3c policy in place regarding this:
http://www.w3.org/Consortium/Patent-Policy-20040205/
Since I assume you knew about that I guess your claim about no guarantee
is more about 'there might be submarine patents', yes this is true. But
there is a major difference to a standard
Hi Gareth,
This is a strange way of looking at the issue. Once a patent is granted
it is by definition valid and enforceable. It is the people opposing it
who have to prove their non-legality at that point and not the other way
around. So sure a lot of software patents might be challenged around
Hi,
Even interoperability at the API and markup level would be a huge
step forward relative to the current state of web video. While also
having a single universally implemented codec would also be good,
that may not presently be feasible.
A huge step that does not go all the way is
Gareth Hay wrote:
At best, we can only conclude that this is a very grey area
throughout different regions of the world, and as such, is not only
out with the scope of this list, but possibly of the spec itself.
That's a non-sequitur.
Why does it not follow?
The fact that there is legal
I defer on the legal side, i really do,
On 23 Mar 2007, at 12:18, Christian F.K. Schaller wrote:
I mean what have we truly achieved if the new VIDEO element means that
web page developers still have to support Windows Media for Windows
clients, MPEG4 for Apple systems and Ogg for Linux/Unix
I am not denying the need to examine the legal situation when
deciding on our attitude to the codec question. I am denying that
the situation is so unclear that a person of ordinary intelligence
(and we have many people smarter than that) cannot understand the
shape of it and make
I don't really like this element. The name is confusing especially with an
attribute named src=. It also introduces yet another void element, can't
we just reuse param? The value= attribute of param would point to a
resource and the type= attribute (which has been dropped) would be added
On 23 Mar 2007, at 02:27, Robert Brodrecht wrote:
Just because most ... doesn't bother doesn't mean it ought to be
removed.
So let's not ignore elements because no one uses them.
Ignore them because they are useless.
I was thinking more along the lines of:
1) We start with a set containing
currentSrc relies on a definition that may not be defined. For instance,
if the src= attribute is not set and there are no source element
children.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
On Fri, 23 Mar 2007 13:40:47 +0100, Nicholas Shanks
[EMAIL PROTECTED] wrote:
Mostly unused, not even deprecated, these elements bloat the spec,
confuse lay authors (i.e. those not of a computer science background)
and I feel would be better represented by a custom XML vocabulary.
How does
Wouldn't it be better if no INDEX_SIZE_ERR was raised but instead the
previous value was retained? For consistency with
CanvasRenderingContext2D.globalAlpha for instance. It's not really
important, but I think that some consistency between the various APIs
would be nice.
--
Anne van
On 23 Mar 2007, at 13:17, Anne van Kesteren wrote:
On Fri, 23 Mar 2007 13:40:47 +0100, Nicholas Shanks
[EMAIL PROTECTED] wrote:
Mostly unused, not even deprecated, these elements bloat the spec,
confuse lay authors (i.e. those not of a computer science background)
and I feel would be better
Nicholas Shanks wrote:
On 23 Mar 2007, at 02:27, Robert Brodrecht wrote:
Just because most ... doesn't bother doesn't mean it ought to be
removed.
So let's not ignore elements because no one uses them.
Ignore them because they are useless.
I was thinking more along the lines of:
1) We
Also sprach Bjoern Hoehrmann:
the SVG 1.2 WD requires support for Ogg Vorbis:
http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html
And as Håkon Wium Lie
pointed out in another email, the latest SVG standard already mandates
Vorbis support, so half of what is needed is already
Kevin Calhoun schrieb:
Just a quick correction here: QuickTime does support the MPEG-4
container format.
Okay, thanks for pointing that out so confusion doesn't spread.
When thinking of QuickTime I was mostly thinking of older .mov files
that you can still see floating around here and there
On Fri, 2007-03-23 at 08:12 -0700, Kevin Calhoun wrote:
On Mar 23, 2007, at 2:56 AM, Maik Merten wrote:
MPEG4 adoption to the web has been poor from my point of view. Today
I'd
guess the absolute king in marketshare is Flash video, then following
Windows Media, then followed by
Matthew Raymond wrote:
I support the time element for the opposite reason, in fact. I
don't want to see authors styling the date format. I'd rather see the
date format localized or customized to a user preference. If the author
wants it in a specific format, they can use CSS to style the
On Mar 23, 2007, at 8:29 AM, Maik Merten wrote:
Kevin Calhoun schrieb:
Just a quick correction here: QuickTime does support the MPEG-4
container format.
Okay, thanks for pointing that out so confusion doesn't spread.
When thinking of QuickTime I was mostly thinking of older .mov files
that
On Mar 18, 2007, at 19:53, Alexey Feldgendler wrote:
* applet: the (old) way of activating Java. Probably must also
die, though I'm unsure about this one.
Why must it die? Browsers have to support it anyway, so documenting
it and letting it pass conformance checking seems sensible.
I
On 3/23/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
I don't really like this element. The name is confusing especially with an
attribute named src=. It also introduces yet another void element, can't
we just reuse param? The value= attribute of param would point to a
resource and the type=
Nicholas Shanks said:
Mostly unused, not even deprecated, these elements bloat the spec,
confuse lay authors (i.e. those not of a computer science background)
and I feel would be better represented by a custom XML vocabulary.
Your method might introduce a lot of stuff a lot of people need,
On Fri, 23 Mar 2007 10:24:30 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
Let's say there's http://example.com/example.html page which contains
embedded video:
...video src=video.ogg...
I'd like to be able to construct URL like:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA
The difference between streaming and non-streaming is artificial and
not technically necessary - except for life content, where you cannot
jump into the future.
Silvia.
On 3/23/07, Gareth Hay [EMAIL PROTECTED] wrote:
In this case, there is a big difference between streamed data, which
can be
How about the following idea:
Example.html contains:
video id=myvideo_1 src=video.ogg
to provide the full video
video id=myvideo_2 src=video.ogg?t=0:12:35
to provide the video from offset 12:35
video id=myvideo_3 src=video.ogg?t=0:12:35/0:20:40
to provide the video segment between offset
On 23 Mar 2007, at 17:59, Henri Sivonen wrote:
pretending that applet doesn't exist won't make applets
disappear. :-(
Perhaps not, but this will:
applet { display: none !important; }
:o)
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
On 23 Mar 2007, at 20:47, Maciej Stachowiak wrote:
I agree the repetition of source/src is a little weird.
and name the new element something like alt
I don't like abbreviations such as alt and src.
The use case is uncommon enough that alternate wouldn't be too much
of a burden to type and
Maciej Stachowiak wrote:
So to be sure I understand your proposal, you're suggesting that instead of
source type=audio/mpeg src=mysong.mp3
You'd say:
param type=audio/mpeg value=mysong.mp3
Why not call the element content instead of source? That way the src
and type attributes make more
On Fri, 23 Mar 2007 19:07:05 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
In this case, the browser shouldn't strip and normalizes the newlines
from the value attribute before passing to the plugin. (FF and IE
handle this nicely. They may do this only for the tcl plugin though.).
Per the
Nicholas Shanks said:
Browsers that don't natively support XHTML aren't that important anyway.
All of the browsers I have access to (that are currently maintained)
seem to cope with it. This includes Firefox, Opera, Safari, Amaya,
Lynx, Links, OmniWeb, iCab and many more smaller ones based on
Nicholas Shanks wrote:
Coming up with usage examples is trivial, justifying why they deserve
to make the cut into a formal specification is not.
I think the need to distinguish stuff to be typed in by the user from
other text without any need for CSS support is reason enough for kbd.
Once we
On Mar 23, 2007, at 2:26 PM, Nicholas Shanks wrote:
On 23 Mar 2007, at 20:47, Maciej Stachowiak wrote:
I agree the repetition of source/src is a little weird.
and name the new element something like alt
I don't like abbreviations such as alt and src.
The use case is uncommon enough that
On Mar 23, 2007, at 1:27 PM, Silvia Pfeiffer wrote:
On 3/23/07, Nicholas Shanks [EMAIL PROTECTED] wrote:
Can't we have all of:
1) A way for authors to match up timecodes with fragment identifiers
in the fallback content
2) A way for UAs to skip to that time code if a fragment identifier
is
On Mar 23, 2007, at 3:20 PM, Ian Hickson wrote:
On Fri, 23 Mar 2007, Anne van Kesteren wrote:
How can load() be invoked when certain method calls have not yet
returned?
Most of the methods result in synchronous event dispatch, which can
invoke further code.
Why does it switch to the
On Fri, 23 Mar 2007 20:57:24 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
video id=myvideo_3 src=video.ogg?t=0:12:35/0:20:40
to provide the video segment between offset 12:35 and 20:40
video id=myvideo_4 src=video.ogg?id=section4
to provide the video from named offset section4
These
On Mar 23, 2007, at 3:49 PM, Silvia Pfeiffer wrote:
Hi Eric,
On 3/24/07, Eric Carlson [EMAIL PROTECTED] wrote:
Even without a server component, #2 and #3 do not require the UA to
download the full file if it can use byte range requests for random
access
and the file format has time to
On Fri, 23 Mar 2007, Maciej Stachowiak wrote:
I would suggest adopting the states from the Apple proposal instead,
where this state would correspond to UNINITIALIZED (starting a load
would switch to LOADING state).
Yeah, I'm planning on merging the two. (I don't think the Apple proposal,
On 3/22/07, Nicholas Shanks [EMAIL PROTECTED] wrote:
I think you're wrong and clearly I'm not alone.
Nicholas,
I think you've taken the email more seriously than I intended. Glazou
seemed to catch the lightheartedness. I really do wish the list was
free of legal/patent traffic and remained
On Fri, 23 Mar 2007 18:59:47 +0100, Henri Sivonen [EMAIL PROTECTED] wrote:
* applet: the (old) way of activating Java. Probably must also die,
though I'm unsure about this one.
Why must it die? Browsers have to support it anyway, so documenting it
and letting it pass conformance checking
On Mar 23, 2007, at 4:37 PM, Ian Hickson wrote:
On Fri, 23 Mar 2007, Maciej Stachowiak wrote:
I would suggest adopting the states from the Apple proposal instead,
where this state would correspond to UNINITIALIZED (starting a load
would switch to LOADING state).
Yeah, I'm planning on
On Fri, 23 Mar 2007 13:36:15 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
I don't really like this element. The name is confusing especially with
an attribute named src=. It also introduces yet another void element,
can't we just reuse param? The value= attribute of param would
On 3/23/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Fri, 23 Mar 2007 19:07:05 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
In this case, the browser shouldn't strip and normalizes the newlines
from the value attribute before passing to the plugin. (FF and IE
handle this nicely. They may
53 matches
Mail list logo
