User: Password:
|
|
Subscribe / Log in / New account

libtheora 1.1 released

The libtheora 1.1 release has been announced. It looks like a fairly major step forward for the theora codec. "This release incorporates all the work we've been doing over the last year, and the encoder has been completely rewritten, although some of the code had its genesis way back in 2003. It also brings substantial performance and robustness improvements to the 1.0 decoder."
(Log in to post comments)

libtheora 1.1 released

Posted Sep 27, 2009 7:32 UTC (Sun) by pheldens (guest, #19366) [Link]

Despite being an open codec it's horribly supported by mplayer, does anybody know why? always sync problems, and no encoding possibilities

libtheora 1.1 released

Posted Sep 27, 2009 9:38 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Many players use ffmpeg and ffmpeg developers insist on implementing everything from scratch instead of using existing libraries. That gives them more independence but can lead to such problems.

libtheora 1.1 released

Posted Sep 27, 2009 9:56 UTC (Sun) by tajyrink (subscriber, #2750) [Link]

Well, my outsider view, which can be corrected if needed, is that mplayer/ffmpeg developers historically don't give a damn about sw patents, truly freely usable formats or other than personal media usage. So they just focus on getting the best image quality etc. out for themselves, which is generally quite understandable if not doing any business. Their main interest is probably x264 / ffmpeg's mpeg-4 avc, which are great (the best quality) open source video codecs out there, just not freely usable in this problematic world. On the other hand, mplayer apparently has quite a hard-to-maintain code structure, which resulted it taking ages for supporting other container formats besides AVI in encoding. So, it's mainly the usual "roots of the project" + lack of manpower.

As usual, no multimedia code in existence is free from submarine-patent threat, and anyway it would be best if open source implementations could be made from standards like h.264. But as long as the world doesn't change, Theora is the best choice for endorsing at least some open standard. And with 1.1 the quality of Theora is really quite acceptable for most general usages, and definitely for all web viewing usage.

Here's hoping that Theora (/ Ogg) support now finally raises, and more sites besides Wikimedia projects start using (more content to Wikipedia et al would also be good). Firefox 3.5 supports it, Google Chrome apparently supports it, and some Android phones support it. However, Nokia's N900 still does not support it, which is a bit sad because it could have been a right time (with Mozilla's and especially Google's support) for Nokia as well.

libtheora 1.1 released

Posted Sep 27, 2009 11:37 UTC (Sun) by tzafrir (subscriber, #11501) [Link]

To put this bluntly: why should the Nokia need Theora support in the browser (besides for Wikipedia)?

Or for the flip side: I have a nice video and I want to make it available, but:

a. I can't spare bandwidth of my own for that
b. I still want to make it available as Ogg/Theora

Where can I host it? Anything along the lines of YouTube?

libtheora 1.1 released

Posted Sep 27, 2009 12:00 UTC (Sun) by tajyrink (subscriber, #2750) [Link]

To the first one, because they claim to be part of the open source ecosystem, and not supporting open media formats hurts the ecosystem. Ie. it's not as practical as it's a show of trusting that the open way is the better way. And to solve the chicken-and-egg problem. Wikipedia also is a top-10 web site, but the audio and video content is still relatively limited. Of course in reality they still want to vendor-lock users like any big company wanting to keep market share, but still they have partially played very nicely with the open source community. I just think that with other mobile phone vendors starting to support Ogg, they could have been in the forefront rather than latecomers a few years from now, especially since they have been doing better community interaction than eg. Android, Palm with their Maemo. I do understand reasons they chose not to, but one can still hope (for the good of the ecosystem).

To the second one, http://openvideo.dailymotion.com/ at least. Apparently blip.tv also, plus http://v2v.cc/, http://tinyvid.tv/, ... it'd be great if Google would now support Ogg / HTML5 output in Youtube with the release of Theora 1.1. I think in general showing good support to Theora / Vorbis would be beneficial to Google, as they want everyone to have equivalent access to Internet (and their services / ads). Maybe we need Google then be the big company that shows the way, before others follow.

libtheora 1.1 released

Posted Sep 27, 2009 15:26 UTC (Sun) by tzafrir (subscriber, #11501) [Link]

Thanks for your reply.

http://openvideo.dailymotion.com/ and http://blip.tv/ did not seem to offer me Ogg/Theora downloads. With http://openvideo.dailymotion.com/ I also saw an explicit list of allowed upload formats that did not include Ogg.

http://v2v.cc/ is an interesting concept. Though I think it is not simple enough for most users. http://tinyvid.tv/ should indeed work. Sadly it is not close to having the pipe size of YouTube :-(

libtheora 1.1 released

Posted Sep 27, 2009 21:01 UTC (Sun) by drag (subscriber, #31333) [Link]

I found several videos in the openvideo dailymotion site that were Ogg. Quite easy and avialable from the page your linking to. Unless you have flash block and your not using a modern Firefox/Chrome browser then your not going to notice a difference.. you have to go and right click on the video to see if its flash or not.

libtheora 1.1 released

Posted Sep 27, 2009 21:14 UTC (Sun) by DOT (subscriber, #58786) [Link]

Every video you've been watching on openvideo.dailymotion.com has been provided to you by means of Theora in the <video> tag. Disable Flash in your browser if you don't believe me.

blib.tv allows you to publish Theora if you want. It's a choice of the distributor.

As for allowing Theora input... even Youtube allows Theora. I think most video sites use ffmpeg to decode the input files. Even if they don't advertise as such, they accept almost any input format.

libtheora 1.1 released

Posted Oct 1, 2009 3:03 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

archive.org appears to accept almost any video format.

libtheora 1.1 released

Posted Sep 28, 2009 22:16 UTC (Mon) by jzbiciak (subscriber, #5246) [Link]

However, Nokia's N900 still does not support it, which is a bit sad because it could have been a right time (with Mozilla's and especially Google's support) for Nokia as well.

I wonder if that will change once the port to the C64x+ DSP is complete? The Theora announcement mentions the port being "in progress" on the announcement page, and I believe the OMAP processor in the N900 relies on the DSP to handle video decode acceleration for formats that its dedicated accelerators don't handle.

I unfortunately didn't find many details on the web out the DSP port. I guess I could ask the TIer listed as the mentor for the GSoC project, as the GSoC project seems to have last touched the port. As a C64x+ geek, I get a kick out of optimizing the occasional computational kernel. (I wrote a few of the C64x IMGLIB functions around a decade ago, and influenced some of the C64x instruction set choices.)

libtheora 1.1 released

Posted Oct 1, 2009 6:32 UTC (Thu) by njs (guest, #40338) [Link]

Nokia was one of the companies that blocked Theora support being mandated in HTML 5, on the grounds that they can't implement it because of patent concerns. Unfortunately, I don't think the problem here is just a technical one.

libtheora 1.1 released

Posted Oct 1, 2009 7:30 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]

I was not aware of this! Thanks for the detail.

I'm still drooling over the N900 though, Theora support or not. I admit it's partly driven by the fact I am a member of the team that made the DSP that's in the OMAP chip in there. :-)

libtheora 1.1 released

Posted Sep 28, 2009 1:18 UTC (Mon) by DonDiego (guest, #24141) [Link]

The sync problems you talk about are news to me. Do you have a sample file?

Regarding encoding capabilities: You can encode Theora with MEncoder through FFmpeg, which has
a wrapper for libtheora, should you be so inclined.

libtheora 1.1 released

Posted Sep 28, 2009 3:31 UTC (Mon) by gmaxwell (guest, #30048) [Link]

In the near future the best solution for decoding with the mplayer front end and encoding to theora will probably be to use a yuv4ogg lossless pipeline. There exist a set of patches for mplayer to output yuv4ogg, a resyncing tool, and an encoder for yuv4ogg input. But the tools are still new and raw and not quite there yet.

Encoding Theora with FFMpeg isn't really advisable— although it uses libtheora it implements its own Ogg muxer which works fairly poorly (adding considerable overhead by placing only one packet per Ogg page). Also— FFMpeg does not yet support two-pass encoding or most of the other libtheora settings… and since it never even bothered supporting constant QI encoding, I wouldn't hold my breath on any of it. :)

The most reliable tool for encoding to Ogg/Theora using FFmpeg as the decoding front end is ffmpeg2theora. Since yuv4ogg isn't really 'there' yet, the best bet for using mplayer as a front end is to decode audio and video separately and remux.

libtheora 1.1 released

Posted Sep 28, 2009 12:48 UTC (Mon) by DonDiego (guest, #24141) [Link]

Whatever you tried to link to there, it was not a set of patches to MPlayer.

We have never received bug reports or patches for our Ogg muxer. Neither have we received
patches or suggestions for our libtheora wrapper. Why?

P.S.: It's called FFmpeg, not FFMpeg.

libtheora 1.1 released

Posted Sep 28, 2009 13:01 UTC (Mon) by tajyrink (subscriber, #2750) [Link]

Well, my post in Jan 2006 was a bug report (not much of a patch) at least. The problem seems to be the same nowadays, but of course I'm not playing ogg:s with mplayer because of the various problems.

libtheora 1.1 released

Posted Sep 29, 2009 9:42 UTC (Tue) by DonDiego (guest, #24141) [Link]

The file linked to from that message disappeared. Do you have a sample that still shows the problem. There have been a ton of changes since January 2006, I suspect this was fixed a long time ago.

libtheora 1.1 released

Posted Sep 29, 2009 11:11 UTC (Tue) by tajyrink (subscriber, #2750) [Link]

http://iki.fi/tjyrinki/3d_prod/harj5_final.ogg is a more stable URL. But I at least stand corrected, using newer than rc2 mplayer seems to have (at least more) problem-free playback experience.

So probably nowadays mplayer plays back theora/ogg fine. I think I tried with rc2 the previous time, and it still had problems.

libtheora 1.1 released

Posted Sep 29, 2009 15:16 UTC (Tue) by gmaxwell (guest, #30048) [Link]

(FWIW, mplayer uses libtheora now for Theora decoding)

libtheora 1.1 released

Posted Sep 30, 2009 18:41 UTC (Wed) by DonDiego (guest, #24141) [Link]

The sample works fine both when decoding with FFmpeg or libtheora.

libtheora 1.1 released

Posted Sep 28, 2009 13:11 UTC (Mon) by gmaxwell (guest, #30048) [Link]

You have a funny definition of never: https://roundup.ffmpeg.org/roundup/ffmpeg/issue556

libtheora 1.1 released

Posted Sep 29, 2009 8:56 UTC (Tue) by DonDiego (guest, #24141) [Link]

You have a funny definition of Ogg muxer and libtheora wrapper. The bug report you linked to is about FFmpeg's Vorbis encoder (Before anybody asks: It's poor quality.), not about its Ogg muxer or libtheora wrapper, and it is fixed. Also, it does not appear to have been you or another Xiph person that reported it.

So I repeat: We have never received bug reports or patches for our Ogg muxer. Neither have we received patches or suggestions for our libtheora wrapper. Why?

libtheora 1.1 released

Posted Sep 29, 2009 15:12 UTC (Tue) by gmaxwell (guest, #30048) [Link]

...

"ffmpeg's ogg encoding is buggy, according to ogginfo" "Negative or zero granulepos (0) on vorbis stream outside of headers. This file was created by a buggy encoder"

The complaint is produced because FFMpeg places one packet per page and the initial non-header vorbis packet is all lapped priming audio so it doesn't complete any samples and thus has a negative granpos, causing a non-header ogg page to be emitted with a granpos of zero. (…and causing an additional 8% of file size or so on typical vorbis files)

So I repeat: We have never received bug reports or patches for our Ogg muxer. Neither have we received patches or suggestions for our libtheora wrapper. Why?
In an effort to not waste an excess of time on an off-topic tangent I didn't provide an example for bug reports on libtheora wrapper, but I can: https://roundup.ffmpeg.org/roundup/ffmpeg/issue949

Moreover, you'd get more reports and if you didn't aggressively NOTABUG real and serious bugs in ffmpeg: For example, a case where ffmpeg was sending crap values to the libtheora API can be seen in bug620 (before you stand by your prior NOTABUG, here is where it was fixed some 6 months after you and michaelni NOTABUGed it for the second time).

Another contributing factor is that you've insisted on reinventing the wheel— often badly. Ogg, Theora, Vorbis, etc. have BSD licensed reference libraries and written specifications. The majority of applications simply use the reference libraries, so when someone wants to contribute to one of these formats they are best off contributing to the reference library as almost everything will benefit. I appreciate that there are more implementations, as test cases for the spec but they don't do much good for that when they don't follow the spec. E.g. FFMpeg demands justification with files in the wild for simple spec compliance (i.e. bug1041, and then declares it a feature request)— so it's not like I could ever feel comfortable recommending ffmpeg for anything Ogg.

Meanwhile with comments like mru's "the only "valid" reason I can think of for using theora is because it works in ogg and the only "valid" reason I can think of for using ogg is that theora works there" and "The more I think about it, the more it appears as an abomination. Just like everything Ogg related. No surprises there. ", it's clear enough to me that the feeling is mutual.

libtheora 1.1 released

Posted Sep 30, 2009 22:17 UTC (Wed) by iive (guest, #59638) [Link]

Have you ever considered that mru hate for ogg/ogm and theora may be because he is too familiar with the "technology" involved?
Here http://hardwarebug.org/2008/11/17/ogg-timestamps-explored/ is probably the best explanation on one of the many horrible design shortcomings in ogg/ogm.

I've urged mru and other developers to write similar detailed explanations for the other shortcoming of ogg/ogm and theora. They all consider it massive loss of time and effort. I also suspect they try to avoid flaming with technically less-competent people who have strong philosophical motivation.
So far I managed to get only list of short descriptions, and it is long list. (e.g. first line is - theora 16pixel motion vector range limitation).

It's nice that you provide BSD code, but if the only way to create specification complain files is to use your source, then maybe it's better to scrap that format and use something else (mkv is free too). The situation somehow reminds me of MS-OOXML ( vs ODF).

And yes, if you know how to fix FFmpeg, send a patch.

libtheora 1.1 released

Posted Sep 30, 2009 22:30 UTC (Wed) by DonDiego (guest, #24141) [Link]

> The complaint is produced because FFMpeg places one packet per page and the initial
> non-header vorbis packet is all lapped priming audio so it doesn't complete any samples and
> thus has a negative granpos, causing a non-header ogg page to be emitted with a granpos of
> zero. (…and causing an additional 8% of file size or so on typical vorbis files)

Finally some details about what is wrong with the Ogg muxer. Excessive overhead will not be
fixed by Baptiste Coudurier, the original author of the Ogg muxer. Of course if somebody steps
forward and volunteers.. Is there any problem apart from the overhead?

> > So I repeat: We have never received bug reports or patches for our Ogg muxer. Neither have
> > we received patches or suggestions for our libtheora wrapper. Why?

> In an effort to not waste an excess of time on an off-topic tangent I didn't provide an example
> for bug reports on libtheora wrapper, but I can:
> https://roundup.ffmpeg.org/roundup/ffmpeg/issue949

Patches welcome. The libtheora wrapper is unmaintained. You appear to have enough knowledge
of libtheora to do a good job maintaining it, interested?

> Moreover, you'd get more reports and if you didn't aggressively NOTABUG real and serious
> bugs in ffmpeg: For example, a case where ffmpeg was sending crap values to the libtheora
> API can be seen in bug620 (before you stand by your prior NOTABUG, here is where it was
> fixed some 6 months after you and michaelni NOTABUGed it for the second time).

I still believe that libtheora crashing when fed wrong width/height values is a bug in libtheora
and not in FFmpeg. But in any case, it's fixed from our side now. However, I sure hope that
libtheora cannot be made to crash quite so easily any longer.

You would receive a friendlier reaction when reporting bugs if you did not flatly request to
replace our Theora decoder with yours because yours is faster (like you did in
http://roundup.ffmpeg.org/roundup/ffmpeg/issue1043). How would you react if I requested
that you replace libvorbis with our Vorbis decoder? After all, our badly reinvented Vorbis decoder
is much faster than libvorbis, around 60% on x86_64 the last time I checked.

You could of course provide a patch that added a libtheora wrapper for decoding Theora. Then
FFmpeg could use both the native as well as the libtheora decoder.

> Another contributing factor is that you've insisted on reinventing the wheel— often badly. Ogg,
> Theora, Vorbis, etc. have BSD licensed reference libraries and written specifications.

While we're on the subject of reinventing the wheel: The whole Xiph project keeps reinventing
the wheel - often badly. Vorbis is good, Theora is substandard (and nobody ever even checked
that it does not infringe on MPEG-LA patents), Ogg is, well, "not so good". So if nothing else I
see a case of a pot calling the kettle black here.

> The majority of applications simply use the reference libraries, so when someone wants to
> contribute to one of these formats they are best off contributing to the reference library as
> almost everything will benefit.

Is that so? One of the bug reports you reference talks about problems that Wikipedia files show
because they use FFmpeg to handle video...

> I appreciate that there are more implementations, as test cases for the spec but they don't do
> much good for that when they don't follow the spec. E.g. FFMpeg demands justification with
> files in the wild for simple spec compliance (i.e. bug1041, and then declares it a feature
> request)

That bug is not classified as feature request.

You complain about the state of things like our libtheora wrapper. Note that the Dirac people do
a good job of maintaining the wrapper for their libraries in FFmpeg. Why shouldn't you be able
to do the same? Everybody would benefit if you provided high-quality wrappers...

P.S.: Please stop misspelling FFmpeg as FFMpeg.

libtheora 1.1 released

Posted Oct 2, 2009 22:22 UTC (Fri) by gerv (subscriber, #3376) [Link]

"Theora is substandard (and nobody ever even checked that it does not infringe on MPEG-LA patents),"

You sound very confident.

Do you really think Mozilla and Google would have shipped Theora support in their browsers without investigating the patent situation?

libtheora 1.1 released

Posted Oct 4, 2009 23:46 UTC (Sun) by DonDiego (guest, #24141) [Link]

> Do you really think Mozilla and Google would have shipped Theora support
> in their browsers without investigating the patent situation?

There is no need for Google to check, they are an MPEG-LA licensee.

I don't know about Mozilla, but I would expect them to publicize their findings if they had. I
haven't seen them publicize anything, have you? Strangely, nobody has ever publicized anything.
Isn't that mighty strange?

Why is it that the Theora patent situation can be exempt from common sense? If a politician or
engineer or doctor or scientist or salesman or neighbor approached you and said "I know you are
in this thorny situation, but I have this wonder product/cure/discovery that can help you.",
wouldn't you want to see some proof. Would you just take their word if your
business/health/whatever depended on it? Wouldn't it be perfectly normal for you to want to see
some proof? Wouldn't you be called a fool if you agreed without asking for proof?

Until somebody presents me with *facts* I shall remain convinced that
- nobody has looked or
- whoever dared look found skeletons in the closet.

libtheora 1.1 released

Posted Oct 5, 2009 9:58 UTC (Mon) by gerv (subscriber, #3376) [Link]

Of course we haven't publicised anything, and there are lots of good reasons for not doing so. :-) The nature of the patent system means that if you do look, it's much better not to publish your results. Patent application is not black and white. Entirely hypothetically, saying "we think there's a 15% chance that patent 1234567890 could be held in court to apply to Theora" just makes the owner of patent 1234567890 say "Oh, really? Thanks for letting us know" and consult their lawyers.

Mozilla has shipped Theora. Reasonable people should be able to conclude from this that they do not think there is a sufficient risk of being sued to not ship it. Given that they employ a general counsel, reasonable people should also be able to conclude that he was involved in that decision.

Gerv

libtheora 1.1 released

Posted Oct 5, 2009 21:22 UTC (Mon) by DonDiego (guest, #24141) [Link]

But there would be no problem for you to say "we checked patents X, Y and Z and do not think they
apply", but you haven't. In other words, you found skeletons in the closet. Just as I suspected...

libtheora 1.1 released

Posted Oct 5, 2009 21:33 UTC (Mon) by gerv (subscriber, #3376) [Link]

Let's say we did say that. Then the owner of patent Z says "You know, I had no idea that patent was anything to do with Theora, but now you mention it, you're right, it might be. And I think it applies, even if you don't. See you in court!"

The way the patent system works, any non-trivial program has "skeletons in the closet" of the sort you are suggesting.

But if you think we found scary stuff and decided to cross our fingers and ship anyway, I think you severely overestimate the gung-ho-ness (if that's a word) of our lawyers.

Anyway, if you are looking for some people who shipped a codec and then got surprised by submarine patents, you want to talk to Microsoft about their experience shipping MP3.

Gerv

libtheora 1.1 released

Posted Oct 5, 2009 23:19 UTC (Mon) by dlang (subscriber, #313) [Link]

Quote:

The way the patent system works, any non-trivial program has "skeletons in the closet" of the sort you are suggesting.

that is exactly the point that was being made. claiming that theora has no patent issues is questionable, if not misleading

libtheora 1.1 released

Posted Oct 5, 2009 23:24 UTC (Mon) by gmaxwell (guest, #30048) [Link]

that is exactly the point that was being made. claiming that theora has no patent issues is questionable, if not misleading
What "claiming" are you referring to here?

libtheora 1.1 released

Posted Oct 6, 2009 1:11 UTC (Tue) by dlang (subscriber, #313) [Link]

the inital statement was that all codecs were at risk

the response was that theora was not at risk

that is the 'claiming' I am referring to.

libtheora 1.1 released

Posted Oct 6, 2009 2:42 UTC (Tue) by gmaxwell (guest, #30048) [Link]

I'm sorry, I'm having trouble locating the text you're referring to. Would you mind quoting it exactly?

libtheora 1.1 released

Posted Oct 5, 2009 23:37 UTC (Mon) by DonDiego (guest, #24141) [Link]

I'm not talking about submarine patents. I'm talking about the patent portfolio of the MPEG-LA.
They have very much to do with video coding and the patent holders know that and they know
about Theora, so there are no sleeping dogs that you might wake.

Having lawyers check such patents is as nonsensical as asking lawyers for a medical diagnosis.
Unless of course that lawyer happens to be an expert on the inner workings of video codecs.

libtheora 1.1 released

Posted Sep 30, 2009 23:44 UTC (Wed) by DonDiego (guest, #24141) [Link]

> In an effort to not waste an excess of time on an off-topic tangent I didn't provide an
> example for bug reports on libtheora wrapper, but I can:
> https://roundup.ffmpeg.org/roundup/ffmpeg/issue949

Fixed.

libtheora 1.1 released

Posted Oct 11, 2009 5:06 UTC (Sun) by DonDiego (guest, #24141) [Link]

> The sync problems you talk about are news to me. Do you have a sample file?

We worked around some timestamping shortcomings in libtheora, so sync issues should have improved, hopefully to the point of being fixed (http://roundup.ffmpeg.org/roundup/ffmpeg/issue1197).

libtheora 1.1 released

Posted Sep 28, 2009 4:59 UTC (Mon) by SEJeff (subscriber, #51588) [Link]

At the expense of sounding like a troll, why not try a video player which
doesn't use ffmpeg? Or at least one that uses a sane framework like
gstreamer? You won't have a single problem using totem + gstreamer to watch
these videos.

libtheora 1.1 released

Posted Sep 28, 2009 12:38 UTC (Mon) by DonDiego (guest, #24141) [Link]

GStreamer uses FFmpeg. There is no free software general purpose video player that does not use
FFmpeg.

libtheora 1.1 released

Posted Sep 28, 2009 12:49 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Gstreamer can use ffmpeg but it doesn't require it. It has independent
implementations of the codecs.

libtheora 1.1 released

Posted Sep 29, 2009 8:49 UTC (Tue) by DonDiego (guest, #24141) [Link]

Indeed, you can replace some of our fast free software implementations by slow proprietary ones. Way to go!

And I'm fully aware that GStreamer supports multiple decoding backends. Still none of the alternatives to FFmpeg support nearly as many different formats as FFmpeg does. That's why I spoke of "use", not of "require" and of "general purpose", not of "single format" video player.

libtheora 1.1 released

Posted Sep 29, 2009 9:13 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

I wasn't talking about proprietary ones but free software implementation of the codecs which do not require ffmpeg. I haven't done a detailed comparison but it satisfies my purposes just fine.

Until the point that ffmpeg does regular releases and separates the patent encumbered portions like gstreamer has, Fedora really cannot fully take advantage of it and that's a shame.

libtheora 1.1 released

Posted Sep 30, 2009 17:41 UTC (Wed) by DonDiego (guest, #24141) [Link]

I wasn't talking about proprietary ones but free software implementation of the codecs which do not require ffmpeg. I haven't done a detailed comparison but it satisfies my purposes just fine.

GStreamer is separated from video decoding because it does no video decoding itself. Instead it relies on external libraries to do the decoding. On Linux FFmpeg is the most important such library. If you haven't been using FFmpeg, then you cannot have decoded very much different kind of content.

Until the point that ffmpeg does regular releases

Been hiding under a rock? We just released 0.5 :)

and separates the patent encumbered portions like gstreamer has, Fedora really cannot fully take advantage of it and that's a shame.

All video formats younger than 20 years are patent-encumbered, don't kid yourself into believing otherwise. That said, you can build custom versions of FFmpeg with any number of codecs disabled.

libtheora 1.1 released

Posted Oct 1, 2009 0:16 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Yes, I like the design of Gstreamer using existing libraries. That means the official repository of a distribution can just exclude the bad and ugly plugins while a third repository can include them.

I am aware FFmpeg has done a recent release however what I said about lack of regular releases still remains true. Just one release isn't enough. A continuous stream of releases is needed at regular intervals. The lack of regular releases has resulted in a lot of players shipping patched snapshots which is a problem.

I haven't seen any patent holder claim make a specific patent claim against Ogg Theora. If that exists, pointing it would be more convincing that a blanket claim. A customized version while feasible is not ideal at all. The Gstreamer model is the model I would like to see FFmpeg follow.

libtheora 1.1 released

Posted Oct 1, 2009 9:24 UTC (Thu) by DonDiego (guest, #24141) [Link]

You misunderstand what GStreamer and FFmpeg are all about. GStreamer does no decoding on its
own, FFmpeg is all about decoding. There is no reasonable way for FFmpeg to follow the GStreamer
model.

libtheora 1.1 released

Posted Oct 1, 2009 10:10 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

I don't think there is any misunderstanding at all. By Gstreamer model, I meant the following things

* A regular release schedule with a stable ABI and parallel installability if ABI does change

* A plugin model for adding or removing codecs

libtheora 1.1 released

Posted Oct 1, 2009 13:13 UTC (Thu) by DonDiego (guest, #24141) [Link]

> I don't think there is any misunderstanding at all. By Gstreamer model,
> I meant the following things
> * A regular release schedule with a stable ABI and parallel
> installability if ABI does change

We shall see how regular our release schedule will be. Our ABI has always been stable. Don't believe the hearsay.

> * A plugin model for adding or removing codecs

FFmpeg is already modular, so you can enable and disable whatever you want. For some external libraries we support dynamic loading. Beyond that we have no interest in providing dynamic loading. I see little point in an FFmpeg decoding plugin that supports FFmpeg decoding plugins.

libtheora 1.1 released

Posted Oct 1, 2009 13:59 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

The point is for distributions to be able to cleanly separate what they can include it in their primary repository vs what should be included in a separate repository. If any set of codecs in FFmpeg can be cherry picked and separately packaged as a add-on of sorts, it would help distributions take advantage of FFmpeg more.

libtheora 1.1 released

Posted Sep 29, 2009 0:44 UTC (Tue) by SEJeff (subscriber, #51588) [Link]

You are misinformed at best. While gstreamer does support using ffmpeg to
decode media, it does not require it.

libtheora 1.1 released

Posted Sep 29, 2009 18:06 UTC (Tue) by wtay (guest, #55923) [Link]

GStreamer prefers (with its ranking system) to use libtheora for decoding theora video. Also, all ffmpeg demuxers (and muxers) are ranked as marginal in favour of the more functional native gstreamer implementations.

We try to avoid using ffmpeg as much as possible because of its rather poor quality and confusing, ever changing, API. That said, decoders like h264 and mpeg4 are working very well in ffmpeg.

libtheora 1.1 released

Posted Sep 30, 2009 18:39 UTC (Wed) by DonDiego (guest, #24141) [Link]

We try to avoid using ffmpeg as much as possible because of its rather poor quality and confusing, ever changing, API.

Where does this "ever-changing" rumor come from? The last libavcodec API change (major version 52) was in September 2008, major version 51 is from December 2005, major version 50 is from September 2005, major version 49 is from July 2004. How long do you expect the API to remain stable? Is it all because of the relatively quick change between 50 and 51?

libtheora 1.1 released

Posted Sep 30, 2009 19:38 UTC (Wed) by bcoudurier (guest, #61079) [Link]

> GStreamer prefers (with its ranking system) to use libtheora for decoding theora video. Also,
> all ffmpeg demuxers (and muxers) are ranked as marginal in favour of the more functional
> native gstreamer implementations.

Wasn't gmaxwell talking about reinventing the wheel earlier ?
It seems to me that's a perfect example of reinvention.

> We try to avoid using ffmpeg as much as possible because of its rather poor quality and
> confusing, ever changing, API. That said, decoders like h264 and mpeg4 are working very well
> in ffmpeg.

I believe several people do not agree with you, though I feel concerned about your comments
somewhat rude. Would you be willing to detail which codecs you think are poor quality ? I don't
recall VLC having problems with them, and the fact that Google Chrome chose to use them
seems to prove the contrary IMHO.

Besides, related to closed source Gstreamer modules, I'm not sure preferring closed source
alternative seems to go in the right directory, my philosophy has always been to promote open
source software.

libtheora 1.1 released

Posted Sep 30, 2009 21:36 UTC (Wed) by tpm (subscriber, #56271) [Link]

> Besides, related to closed source Gstreamer modules, I'm not sure
> preferring closed source alternative seems to go in the right
> direct[ion], my philosophy has always been to promote open
> source software.

Who said anything about closed source software? I don't think that was what wtay was refering to at all. All GStreamer hackers I know are passionate free and open source software advocates and they will choose and promote open source alternatives over proprietary solutions anytime where that's a possibility. Proprietary closed source GStreamer plugins exist of course, but they are mostly just a necessary evil that allows vendors to distribute certain things in a way compliant with the law. There are FLOSS versions of almost everything available as proprietary plugins by third parties (including wrapped ffmpeg codecs of course).

Also, last I checked GStreamer wasn't exactly the only project that relies on ffmpeg primarily for the codecs but prefers to do their own demuxers and network/protocol handlers. Don't e.g. VLC and mplayer do that as well?

libtheora 1.1 released

Posted Sep 30, 2009 22:07 UTC (Wed) by DonDiego (guest, #24141) [Link]

> All GStreamer hackers I know are passionate free and open source software advocates and they
> will choose and promote open source alternatives over proprietary solutions anytime where that's
> a possibility.

Does that include the people working for Fluendo peddling proprietary software?

libtheora 1.1 released

Posted Oct 1, 2009 10:27 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Yes. Fluendo codecs are unfortunately the only legal solution available to some users. While I am no fan of software patents, not everyone can ignore them while they still exist. This doesn't change the fact that Gstreamer developers are very dedicated Free software developers.

libtheora 1.1 released

Posted Oct 1, 2009 13:22 UTC (Thu) by DonDiego (guest, #24141) [Link]

> Fluendo codecs are unfortunately the only legal solution available to
> some users. While I am no fan of software patents, not everyone can
> ignore them while they still exist.

There are 5-6 billion people on this planet. How many of them are affected by licensing fees on multimedia codecs? The only ones that *might* have a problem are a few companies with deep pockets in certain countries. They don't even amount to 0.01% of the total. Yet you keep refusing to serve the needs of the 99.99% because of them. This is detrimental to the cause of free software.

> This doesn't change the fact that Gstreamer developers are very
> dedicated Free software developers.

I suggest you give at least as much credit to the people actually producing free software as you give to the ones selling proprietary software.

libtheora 1.1 released

Posted Oct 1, 2009 14:03 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

We can argue about the exact percentage but the fact remains that there are a lot of mainstream distributions which simply cannot include FFmpeg in their primary repository due to the various factors that I explained in detail already. Even if it is a small percentage of users whose legal multimedia needs can only be solved by using the Fluendo plugin, then so be it. Why does that have to bother anybody else?

Of course, I don't deny in any way that FFmpeg developers are doing valuable work as well but there is no need to talk down Gstreamer developers. They are *both* doing a good job and serve different purposes.

libtheora 1.1 released

Posted Oct 2, 2009 8:16 UTC (Fri) by bilboed (subscriber, #54668) [Link]

> I suggest you give at least as much credit to the people actually producing free software as you give to the ones selling proprietary software.

I sense a pinch of misconception here, so let me settle this once and for all : GStreamer developers ARE NOT PROPRIETARY SOFTWARE DEVELOPERS PRIMARILY !
The vast majority of us (GStreamer developers) started hacking on this way before GStreamer had any commercial application... and most of the companies working/using GStreamer push back their commits upstream and get involved in the open-source process. Takes time and effort to explain the values of open-source to big companies/corporations, but it definitely pays off in the long run.

Ok, so fine, there's one company who had the idea to make proprietary legal codecs. Are you going to blame the framework they chose to distribute those codecs ? Did they have a choice ? Do you know any other multimedia framework which is at the same time (1) cross-platform, (2) completely media-agnostic, (3) LGPL, (4) not strongly tied to *obvious* patent-encumbered technologies through a plugin system ?

(N.B. I don't work for Fluendo in case you're wondering, but for Collabora Multimedia whose goal is to push GStreamer's adoption as much as possible in both proprietary usages and FOSS usages).
--

And could we *please* drop this childish FFmpeg vs GStreamer flamewar ? They're not opposites, they complement each others.

YES, FFmpeg beats the crap out of most FOSS/proprietary codec implementations out there, and YES, thank god there's an alternative, and YES most GStreamer applications on a desktop machine will most likely use FFmpeg for decoding/encoding.

But don't forget the other side.

Ok, so some distros don't want to ship FFmpeg, fine. With a couple of clicks you can enable a repository containing gstreamer plugins that the distro didn't want to ship. You try to play a file for which you don't have a codec => a dialog box pops up => you click [OK INSTALL CODECS] (which will most likely be gst-ffmpeg) => you go back to watching your movie. No extra application to install, No need to dig up in forums what to install, no need to even restart your media player, transcoder, cd/dvd ripper or video editor !

More recent/mainstream example : The Nokia N900. It comes with GStreamer for all multimedia support, but doesn't come with FFmpeg or theora/vorbis. If it hasn't already been done, someone will most likely make a gst-ffmpeg package for the N900 (with OMAP optimisations and co), you install it => BLAM you automatically get all those codecs in all the STANDARD N900 applications ! You don't have to install another application (like you would have to on iPhone, Android,...), it just plain works ! Doesn't that rock for FFmpeg ?
Same argument obviously applies also for theora/vorbis, install gst-plugin-theora/vorbis and you get support for those in existing applications. Same applies also for any other device supporting GStreamer (like the Palm Pre for ex). So in the end... GStreamer is allowing FFmpeg being even more streamlined for all of those devices.

We complement each other.

--

As for writing demuxers/muxers as native GStreamer plugins (hello Baptiste)... there's 3 main reasons:

** They're available as individual shared libraries => They're not tied to any other patent-pool => If a vendor has the license for said technology they can cherry-pick that implementation (unlike in libav*, where everything is bundled together and it's *very* tricky for lawyers to guarantee that even if you compile ffmpeg with only selected codec/format support it's not picking up other patented technologies).
Yes, software patents suck, but we don't want this to be a show-stopper for manufacturers to ship GStreamer (and thereby give the potential to install any GStreamer plugin you want as a user).

** The libavformat API is really hard/inefficient to wrap (notice : I did not speak about the (de)muxer implementations) and other FFmpeg developers seem to agree on that point. libavcodec doesn't really have that problem in the sense that codecs are much simpler to use from an outside point of view (roughly : configure(), encode(), decode()).
For demuxers alone... it's starts getting really tricky because there just isn't a generic set of methods that (1) fit all situations and (2) does it efficiently. (Hos do you notify program changes (specific to mpeg-ts) ? how do you expose the various programs available to outside application ? what format is the metadata in ? How do you expose format-specific binary-blob metadata ? How do you signal the fact that the provided duration is just an estimation and that you can provide a more accurate duration once you have enough info ? ...).

** Usage of libavformat ... implies usage of libavcodec :( This one is actually very painful. Because not only we have to try to map GStreamer behaviours to libavformat behaviours... but also libavcodec. And I'm not just talking about CodecID or common structures (like AVPacket), but the fact that both libraries are strongly tied together as to how they fill each other's structure and communicate (common examples : do I need a parser or not for this codec stream based on that demuxer ? What do the outgoing packets represent in terms of units ? How should the codec_data be formatted and what does it represent ?). Try integrating libavformat with a non-libavcodec codec... and see how much trouble it is.

--

GStreamer will never be a big-awesome-binary-that-does-it-all... we have to play with everybody in the game... and it's not just FFmpeg, and it's not just theora/vorbis and it's not just the open-source community and it's not just proprietary vendors, it's EVERYBODY.

Regards,

Edward

libtheora 1.1 released

Posted Oct 8, 2009 10:49 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

> There are 5-6 billion people on this planet. How many
> of them are affected by licensing fees on multimedia codecs?

It's not that much about license fees, but basically all of them wanting to use free software distributions are affected by the license _hassle_, ie. unavailability of the codec support etc. in the distribution. Even in the most popular/easy option of Ubuntu, they will be confronted by some warnings and always require network access to download any support (in the form of GStreamer codec packages).

And when it comes to license fees, any commercial entity wanting to publish material on their web page is affected also by the fees, therefore Theora is ideal, and about the only option, for all of them.

libtheora 1.1 released

Posted Oct 11, 2009 11:39 UTC (Sun) by DonDiego (guest, #24141) [Link]

> > There are 5-6 billion people on this planet. How many
> > of them are affected by licensing fees on multimedia codecs?

> It's not that much about license fees, but basically all of them
> wanting to use free software distributions are affected by the
> license _hassle_, ie. unavailability of the codec support etc.
> in the distribution.

And this is what distributions should fix. Distros were able to work around *military* export restrictions and provide cryptography to the world at large. How hard can it be to achieve the same for multimedia?

> And when it comes to license fees, any commercial entity wanting to
> publish material on their web page is affected also by the fees,
> therefore Theora is ideal, and about the only option, for all of them.

Nonsense.

a) What happens when somebody publishes something on their web page is far beyond the scope of distributions. If you think your argument through, you would see that distributions would have to stop shipping web servers. After all, commercial entities that publish material on their web pages, can be by licensing fees, depending on the material.

b) The MPEG-LA does not go after small fishes. They never have in the past and it's not in their best interest to do so. Small fish are not worth the hassle. You get no money out of them and it's much better to see your technologies widely used.

libtheora 1.1 released

Posted Oct 13, 2009 5:31 UTC (Tue) by tajyrink (subscriber, #2750) [Link]

> And this is what distributions should fix. Distros were able to
> work around *military* export restrictions and provide cryptography
> to the world at large. How hard can it be to achieve the same
> for multimedia

About impossible without any costs - and license-based costs make it impossible to have an open source based solution. Plus any costs make it impossible for random small distro wanting to "do it right" but without money. Just because it's military export restriction doesn't mean it's somehow hard to overcome. The patents around most of the video/audio codecs are actively pursuited, so the bigger the distro player, the more sure one will get sued.

I do agree that _if_ it would be allowed to world-widely use H.264 open source implementations, if only for decoding, it would be a massive improvement. Such a deal has not been possible so far.

> a) What happens when somebody publishes something on their web page
> is far beyond the scope of distributions.

I was only talking about why web publishers should use Theora/Vorbis instead of patent-encumbered formats when using open source software, unless they pay the roaylties.

> b) The MPEG-LA does not go after small fishes.

So not paying licenses is correct because of that?

But generally, I agree to disagree. You have such a strong point of view about not caring about these issues, or the option of using truly Free format (despite its problems including submarine patents even for it), that there is probably no point trying to argue more. Being pragmatic about these is probably worthwhile when doing one's own encodings, but being idealistic hopefully somehow changes the world for the better for all users, and makes free software more competitive.

Theora 1.1 looks like a "true 1.0 release" with improvements all-over, two-pass support and bitrate problems corrected. Regarding the results in the linked article, it seems a bit low point for Theora with that animation material, since I've seen a massive improvement in results with 1.1 vs. 1.0 when correctly used, and some previous comparisons showed even 1.0 being better or equal than that compared to others.

libtheora 1.1 released

Posted Oct 1, 2009 8:19 UTC (Thu) by DonDiego (guest, #24141) [Link]

> Also, last I checked GStreamer wasn't exactly the only project that relies on ffmpeg
> primarily for the codecs but prefers to do their own demuxers and network/protocol
> handlers. Don't e.g. VLC and mplayer do that as well?

I can only speak for MPlayer. There it is largely historical because MPlayer's own demuxers and
protocol handlers predate FFmpeg's. But nowadays we are moving toward using the ones from
FFmpeg.

libtheora 1.1 released

Posted Sep 30, 2009 21:45 UTC (Wed) by gmaxwell (guest, #30048) [Link]

>> GStreamer prefers (with its ranking system) to use libtheora for decoding theora video. Also,
>> all ffmpeg demuxers (and muxers) are ranked as marginal in favour of the more functional
>> native gstreamer implementations.

> Wasn't gmaxwell talking about reinventing the wheel earlier ?
> It seems to me that's a perfect example of reinvention.

I can't speak for other things— but for Ogg gstreamer's muxer just uses libogg.

(I understand that Mplayer also doesn't use (all of) ffmpeg's demuxer code; one of the most frequent complaints I hear about ffmpeg2theora is "can't this be based on mplayer instead? mplayer is more reliable at decoding random files"; but I may have been given bad information on this point)

libtheora 1.1 released

Posted Oct 1, 2009 1:43 UTC (Thu) by bcoudurier (guest, #61079) [Link]

>>> GStreamer prefers (with its ranking system) to use libtheora for decoding theora video.
>>> Also, all ffmpeg demuxers (and muxers) are ranked as marginal in favour of the more
>>> functional native gstreamer implementations.
>>
>> Wasn't gmaxwell talking about reinventing the wheel earlier ?
>> It seems to me that's a perfect example of reinvention.
>
>I can't speak for other things— but for Ogg gstreamer's muxer just uses libogg.
>(I understand that Mplayer also doesn't use (all of) ffmpeg's demuxer code; one of the most
>frequent complaints I hear about ffmpeg2theora is "can't this be based on mplayer instead?
>mplayer is more reliable at decoding random files"; but I may have been given bad information
>on this point)

Mplayer, like VLC, need and prefers FFmpeg demuxers for some formats. Gstreamer has been
reinventing the wheel in the past years reimplementing its own demuxers and muxers. Still,
Gstreamer requires FFmpeg for some formats.

libtheora 1.1 released

Posted Sep 29, 2009 7:41 UTC (Tue) by ovitters (subscriber, #27950) [Link]

Nice blogpost about this by Christopher Blizzard: http://hacks.mozilla.org/2009/09/theora-1-1-released/

animation encoding quality comparison

Posted Oct 1, 2009 13:28 UTC (Thu) by DonDiego (guest, #24141) [Link]

Here is a good article that compares different codecs for encoding Anime that includes libtheora among many other things:

http://x264dev.multimedia.cx/?p=102

If you wish to skip to the results, here is a neat graph:

http://x264dev.multimedia.cx/wp-content/uploads/2009/08/q...

You can find libtheora on the far right.

animation encoding quality comparison

Posted Oct 3, 2009 7:51 UTC (Sat) by tajyrink (subscriber, #2750) [Link]

It had rate control issues because of which the release was delayed, I'd like to see final 1.1 used. Would be nice to see if it's eg. Xvid equivalent. Of course, there are also many types of materials.

animation encoding quality comparison

Posted Oct 6, 2009 21:03 UTC (Tue) by DonDiego (guest, #24141) [Link]

Check back, the article has been updated with libtheora 1.1.

Executive summary: There is no quality improvement since the beta, the rate control is better but not fixed and but framedrop issues make the codec near unusable. Even without those bugs, the quality would be slightly below that of FLV (used in Flash/YouTube).

animation encoding quality comparison

Posted Oct 8, 2009 10:45 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

Cool, ok. Anyway, not terribly far behind XviD, so perfectly usable, especially if the kind of animation material happens to be hard for Theora.

1.1 two-pass would be worthy of other test material comparisons as well. Not that it'd matter compared to x264 etc. as its uniqueness lies elsewhere, but the quality is finally adequate.

animation encoding quality comparison

Posted Oct 11, 2009 11:43 UTC (Sun) by DonDiego (guest, #24141) [Link]

That's a peculiar way to read the results of the article. The verdict on Theora is that both the format and the encoder are stuck in the 1990s and serious bugs in the implementation make using it a PITA or even an impossibility right now.


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds