Jonas Sicking wrote:
> Note that "hardware limitations" isn't as simple as "can play". For
> example a portable player device uses 90% CPU to play things certainly
> work, but possibly for an unacceptable short time before battery runs
> out.
That's correct.
Thankfully all mentioned codecs are we
Arve Bersvendsen wrote:
> On Thu, 16 Jul 2009 03:23:40 +0200, Nils Dagsson Moskopp
> wrote:
>
>> Am Mittwoch, den 15.07.2009, 19:16 -0500 schrieb Adam Shannon:
>>
>>> It has been tried but Apple will not implement it due to hardware
>>> limitations.
>>
>> As if. I somehow recall that a few years
Maciej Stachowiak wrote:
> So I don't
> think it's reasonable to assume that hardware implementations will just
> appear.
The dire need of ASIC "hardwired-style" implementations for Theora
hasn't been demonstrated either. H.264 has much higher computational
complexity, it may be interesting to con
Hi David,
that's an interesting comparison because it's a bit different from what
Greg Maxwell
(http://people.xiph.org/~greg/video/ytcompare/comparison.html) and I
(http://people.xiph.org/~maikmerten/youtube/) did. The comparisons done
by Greg and me try to answer the "how does Theora compare to c
Hi Chris,
I provide an additional comparison at
http://people.xiph.org/~maikmerten/youtube/ using different content.
This doesn't qualify as "more movement/action" (it's hard to get free HD
samples of such content in good quality), but content like the one I
used is common nonetheless on community
Frank Hellenkamp wrote:
> Well, the thing is (perhabs unfortunately because of patents and
> liscensing) that you can use h264 with the video tag (in safari and
> chrome), but at the same time you can send the same video to every old
> browser with the flash player 9 or 10, because it also supports
Mike Shaver wrote:
> Yep, I'll reach out to the o3d guys directly as well, see if they have
> the source video for that clip. More than happy to do the
> measurements on this side, I know what a pain travel can be...
I'll happily provide encoding-assistance if wanted :-)
Maik
Gregory Maxwell wrote:
> Perhaps then you wouldn't mind sharing the rough breakdown of how many
> YouTube distributed videos are the 'high quality' files which are
> encoded in H.264 and only provided on user-request vs the normal
> quality, which is provided by default, and which doesn't use H.264
~25% of users
(Firefox and Opera being Ogg-only) from the need of using Flash on
YouTube may very well have a strategic value to Google to enhance the
effect of their open-web strategy. Anyway, that's of course something
Google will have to discuss internally.
bye,
Maik Merten
't think they improve anything ;-)
On Tue, 25 Nov 2008, Maik Merten wrote:
This applet does not seek to the end of the stream to retrieve a
timestamp there.
It should. :-)
And it now does :-)
http://svn.wikimedia.org/viewvc/mediawiki/trunk/cortado/src/com/fluendo/player/DurationScanner
Silvia Pfeiffer schrieb:
The duration is indeed jumping quite a bit between 8min and 12 min and
even at the end still has a gap of actual end time of 9m54s while the
estimate is still at 10m44s.
Actually that gap means the byte-accounting is still buggy. Hmmm...
Players like YouTube's player
Silvia Pfeiffer schrieb:
> In any case - if you (and also Chris Double) are satisfied with the
> estimates you're getting for file duration/length - I'll stop arguing
> for it. It would be nice to hear some experimental evidence about how
> well it's doing, e.g. for typical movie trailers, so we ca
Silvia Pfeiffer schrieb:
Are you using the byte position to estimate duration or are you using
the granulepos in Ogg to do this? The granulepos on the last data page
may be more accurate than simply using byte positions in Ogg. However,
it may also be more complicated and error-prone.
This appl
Dave Singer schrieb:
I don't think you mean 'relative' here, which I would take to be "go
forward 10 seconds", but 'proportional', "please go to 60% of the way
through".
Right, "proportional" for sure is the correct word for what I had in
mind. Thanks.
IF we are to do this, I would have th
Eric Carlson schrieb:
QuickTime has used this method this since it started supporting VBR
mp3 in 2000, and in practice it works quite well. I am sure that there
are degenerate cases where the initial estimate is way off, but
generally it is accurate enough that it isn't a problem. An initial
Hello,
currently seeking in the media elements is done by manipulating the
currentTime attribute. This expects an absolute time offset in seconds.
This works fine as long as the duration (in absolute time) of the media
file is known and doesn't work at all in other cases.
Some media formats don't
Perhaps another possibility would be something similar to the current
navigagor.mimeTypes array (navigator.mediaMimeTypes?). Absolutely
old-school, but perhaps makes sense, as the ability to display certain
media types is mostly a property of the "navigator"/client, not as much
a property of the me
Oh, I see that there already was/is a discussion on querying media
format support (
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015620.html
).
Anyway, the question when error flags are supposed to be set and if such
flags could be used to "query" media format support with the h
Hello,
I'm trying to find out how to determine if a given media format is
supported by a media-element implementation. The motivation is to
replace e.g. elements with fitting fallbacks (video playback
applet, third party plugins like VLC etc.) if the user's client doesn't
support a fitting format
Chris Double schrieb:
Given that codecs are often highly optimized for forward playback the
cost in memory can be excessive to go the other way. Could there be a
possibility to say 'reverse playback not supported'?
This may be needed anyway, given that with streaming media you can't
reverse pl
Maik Merten schrieb:
If for sure welcome the stance of Mozilla and Opera to support
royality-free-for-any-purpose formats and I hope other vendors will
follow this path.
This sentence doesn't parse. Patched version:
"I for sure welcome the stance of Mozilla and Opera to support
David Gerard schrieb:
Ignoring IE, Firefox 3.1 will have this Just Work. So, as I said,
it'll be a process of them deciding whether there are business reasons
to come along at their leisure.
Yes, business reasons are usually indeed good reasons for businesses ;-)
The second-biggest browser ven
David Gerard schrieb:
The "IP concerns" are blatant FUD and it's ridiculous to describe them
in any other terms.
While I do agree that the "IP concerns" may actually be blown out of
proportion (after all the current state of being in a limbo, leaving the
field completely to proprietary techno
David Gerard schrieb:
Is the tag doing Ogg Theora in Opera yet?
In experimental builds, yes.
I'm sure Apple and Nokia can join the party at their leisure.
I assume the latest move by Mozilla (which I think is great, obviously)
won't do anything to address the IP concerns of mentioned pla
Krzysztof Żelechowski schrieb:
> Dnia 14-12-2007, Pt o godzinie 19:47 +0100, Maik Merten pisze:
>> Krzysztof Żelechowski schrieb:
>>> Remember the "-" in DOCTYPE HTML?
>> Feel free to be more specific.
>
> That prefix means that HTML DOCTYPE is not issued
Krzysztof Żelechowski schrieb:
> Remember the "-" in DOCTYPE HTML?
Feel free to be more specific.
Charles schrieb:
>> Right, but of course neither VCEG nor ISO/IEC have a monopoly on
>> setting standards.
>
> Certainly, sir, but that wasn't my point.
Noted.
> In my experience, an organization (non-profit or not) can't simply publish
> their own specification and claim, "hey, this is a stand
Charles schrieb:
> AVC is a standard under both the ITU-T Video Coding Experts Group (VCEG)
> and ISO/IEC Moving Picture Experts Group (MPEG).
Right, but of course neither VCEG nor ISO/IEC have a monopoly on setting
standards.
>
> Also, AVC is a de-facto standard. Every iPod supports it. Every P
Geoffrey Sneddon schrieb:
> Apart from those two, the others I can think of are those that are in
> excess of twenty years old (and therefore their patents have expired),
> such as H.260.
I couldn't find anything insightful about "H.260". Sure you don't mean
H.120, which is a 1982 video codec I co
Ian Hickson schrieb:
Ogg Theora has not had an exhaustive patent search (you may be thinking of
Ogg Vorbis). In fact, it is likely the case that H.264 has had a _more_
exhaustive patent search than Ogg Theora.
Well, thanks to VP3 having been a commercial product licensed to
numerous commercia
Ian Hickson schrieb:
One would imagine that they would happily take new risks if the rewards
were great (e.g. a better codec). Sadly the rewards in the case of Ogg
Theora are low -- there isn't much content using Theora, and Theora isn't
technically an especially compelling codec compared to ot
Ian Hickson schrieb:
The difference is that while Apple (for example) have already assumed the
risk of submarine patents with H.264, they currently have taken no risks
with respect to the aforementioned codecs, and they do not wish to take on
that risk.
Which surely means that they won't ever
that HTML5 is usually viewed in browsers that
implement at least a non-empty subset of HTML I imagine it should be
possible for the browser to layer something div-equivalent over the
media elements supporting captioning and pipe the HTML captions into it
(with caution, imagine a caption itself recursively embedding a video).
Maik Merten
sourcecode is open. However, thanks to the MPEG and Microsoft codecs
being patented (and because those patents are enforced) you cannot put
it into Mozilla.
"Open source" usually only covers copyright. Truly free codecs are open
sourced AND don't require patent licensing.
Maik Merten
tomers and they all can do WMV" - that could grow to an
unfortunate situation where actually "improving" interoperability with
one media system slams the door for Linux and MacOS users).
Maik Merten
Jerason Banes schrieb:
>
>
> On 6/26/07, *Maik Merten* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Opera and Mozilla already have implemented (early) Ogg Vorbis and Ogg
> Theora support.
>
>
> And (if this thread is any
ch would be the major use for web video) if you wish (below
one megabyte, even suitable for attaching to an email).
Maik Merten
> On 6/26/07, *Maik Merten* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Jerason Banes schrieb:
> H.263 is seriously
logy is nice and well performing - but
the licensing makes implementations in free software impossible (or at
least prevents distribution in e.g. Europe or North America).
Maik Merten
line
> for a few reasons:
H.263 is seriously outperformed by Theora. I don't know where all that
"Theora is high bitrate and low quality" talk comes from. It's not as
good as H.264, but it's for sure not worse than H.263 and from my tests
it's consistently better at low bitrate video.
Maik Merten
detailed explanation:
> http://www.xiph.org/theora/doc/Theora_I_spec.pdf
> and the Theora FAQ http://theora.org/theorafaq.html
>
> But I may have misunderstood what you were alluding to.
Well, I assume he's referring to "Apple, Inc. is no better than
Microsoft" - meaning th
ably will again (see the
> currently suspended 'quicktime download program').
Unsuspending that program or having talks with (in this case) xiph.org
(they already have a working QT component) outside of that program
sounds like a good way to strengthen the interoperability of Safari with
Opera and Mozilla. I heard that xiph.org tried to participate in that
QuickTime download program in the past but that this more or less
stalled on Apple's side (I only heard one side of the story, though).
Maik Merten
t ;-)
If Safari is encountering "application/ogg" and it can't decode that
stuff then redirect (after asking of course) the user to a fitting
QuickTime component download page on e.g. xiph.org or even automate the
process of installing a fitting 3rd-party component after the user
acknowledged the process.
That won't be as smooth as "native" and "out of the box" support - but
if the whole process only involves like 4 user mouse clicks then
operability is as "okay" as it can be under the given circumstances.
Maik Merten
not only was my post too harsh, it has mistakes in it, too.
Maik Merten
her
opinions are not seen as a try to "dictate" things - and my response got
more snappy than it is good for the discussion.
Maik Merten
timeless schrieb:
> On 4/2/07, Maik Merten <[EMAIL PROTECTED]> wrote:
>> Usually consumer hardware doesn't receive feature upgrades after it
>> shipped,
>
> since you're using (buying?) the n800, I wonder if you're counting it
> as a consumer product.
Maik Merten schrieb:
> This is vastly off-topic, but is there a formalized way for 3rd parties
> to register their qt components and have them in the download service?
Oh, didn't look hard enough yet.
http://developer.apple.com/quicktime/qtcdform.html
Maik Merten
Dave Singer schrieb:
> At 18:44 +0200 3/04/07, Maik Merten wrote:
>> Personally I don't see a reason why Apple couldn't simply queue an Ogg
>> Theora component provided by a 3rd party into the QuickTime component
>
> Alas, that wouldn't be Apple then that was
sually have a H.264-capable DSP - like the
Video iPod. That one comes with a Broadcom DSP which is 100%
reprogrammable and is well suited for Theora decoding (so I am told).
Now, of course that's implementation work, but so is the whole WHATWG
spec and I'm sure Broadcom would prefer doing the implementation work
over losing customers.
Maik Merten
ot on device B. So the profiles add another dimension to
interoperability issues (there are already many others).
Maik Merten
Dave Singer schrieb:
> are you telling us that all implementations of Ogg and Theora can play
> audio and video up to any bitrate, screensize, channel count etc.,
> without dropping frames, getting behind, decoding badly, or other
> limits? That would be quite an achievement...more impressive tha
ecial codec in
mind).
> Well, the official EULA for the Firefox download already prevents
> certain forms of modification, but granted the logo, name and so forth
> are not core features.
The EULA applies to the binary thing, not the source code, which is free
(and contains a different branding set IIRC) as far as I know.
bye,
Maik Merten
Maciej Stachowiak schrieb:
> It's not immediately clear to me that a Mozilla license would not cover
> redistribution, for instance the license fees paid by OS vendors
> generally cover redistribution when the OS is bundled with a PC. I think
> someone would have to look at the legal language of th
ph.org)? I guess that may lessen the interlectual
properties problems as another party is responsible for the component.
Maik Merten
ll be submarine patents out there. But
that possibility applies to all codecs that are younger than 20 years.
Microsoft was hit by a MP3 submarine patents despite licensing the usual
MP3 patents. Same could happen to AAC and H.264 as licensing from
MPEG-LA gives zero security against submarine patents.
Maik Merten
It is not. To this day neither Thomson nor Fraunhofer
made any patent claims and they did not issue any more statements
concerning the patent status of Vorbis, but still this old old old story
is doing its damage.
Maik Merten
uot;hacks".
Actually the current draft requires user agents to support PCM
in a .wav container (that's way stronger than what can be found in the
section). I guess your points apply there, too?
Maik Merten
oided if the assembled user agent vendors negotiate on a
gentlemen-agreement that is in spirit of the free nature of the Web -
and I think it can't harm if this gentlemen-agreement makes it into the
spec as optional part.
Maik Merten
Geoffrey Sneddon schrieb:
>
> That sort of info is held within the container, so everything within Ogg
> (so both Theora and Dirac) will suffer from it. H.264 being part of the
> MPEG-4 standard follows what Kevin Marks said:
>
> On 24 Mar 2007, at 08:57, Kevin Marks wrote:
>> 2. define a chunk/o
tations back to 1990,
> as well as WMP and RealPlayer and all the open source players.
Well, that would be a desperate measure. It won't work for web video at
all because compression efficiency is "lousy" (or even worse). People
could just as well embed animated GIF "films&
e and there and do not contain
MPEG codecs. IIRC the MPEG4 container was more or less derived from
QickTime's .mov container, so I'm not sure if .mov actually *is*
actually the MPEG4 container by now.
Maik Merten
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 c
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
[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
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.
Ho
Maciej Stachowiak schrieb:
> - As mentioned above, some devices may have a much harder time
> implementing Ogg than other codecs. Although a SHOULD-level requirement
> would excuse them, I'm not sure it's appropriate to have it if it might
> be invoked often.
Ogg Theora decoding has been demonstra
Håkon Wium Lie schrieb:
> > What WHATWG has been shooting for, is one common codec. At this point,
> > WHATWG folks want Theora.
>
> Yes, it's a likable format. If anyone has better ideas, this is the
> time to step forward.
There's Dirac in development right now. That's a next generation wave
Mihai Sucan schrieb:
> As a user, it's convenient for me to search for some video, click it and
> have it automatically play. Do I have to enable JavaScript for that? Or
> ... do I have to click the play button? Or ... wait, I have to enable JS
> for the play button as well. (*cough* forced branded
ty so compression
> is called for.
It's more or a less a tradeoff situation. If you double the processing
requirements you usually don't come even close to doubling the coding
efficiency. If you can't use special hardware you often end up not
having a choice but to choose a codec of moderate complexity.
Maik Merten
Bjoern Hoehrmann schrieb:
> Flash supports two codecs, the more recent one is VP6, a successor of
> VP3; VP3 in turn is what Ogg Theora is based on. I would be surprised
> to learn that On2 gave the superior codec away for free while it sells
> the inferior one.
On2 VP6 is performing better than
Elliotte Harold schrieb:
> Maik Merten wrote:
> I don't think we need a novideo element. This would work:
>
>
>
> Complete marked up transcript of the video.
>
>
>
> This is much more accessible and great for search engine optimization.
>
This
user has a fitting
plugin for the mandatory format installed.
Maik Merten
uldn't be a element but more something like
or something like that.
Maik Merten
develop his own cross-platform playback system that does seeking and A/V
sync you can get away with libvorbisdec, libtheoradec and libogg.
Compressed that is 102 K.
Maik Merten
Geoffrey Sneddon schrieb:
>
> On 4 Mar 2007, at 14:08, Maik Merten wrote:
>
>> - MPEG4: This is most common in forms of DivX and XviD. Predecessor of
>> H.264. As usual there's patent pool licensing involved. This means that
>> albeit XviD is open sourced it
ntations to only support
one format. It should require at least one base format (see above) and
allow optional formats to keep track of codec development and to keep
political minds calm. I doubt Microsoft would ever implement a
element if they weren't allowed to support their own formats as well (it
may be hard enough for them to support any base format not being theirs
anyway).
Sorry for this long mail,
Maik Merten
75 matches
Mail list logo
