FLOSS Multimedia Support in Fedora

Gregory Maxwell gmaxwell at gmail.com
Mon Feb 9 16:36:07 UTC 2009


[hopefully the amount of OT material in my post is offset by the fact
that I'm sending one reply rather than four]

2009/2/9 Martin Sourada <martin.sourada at gmail.com>:
[snip]
> Yeah, I haven't too, though I sometimes produce something in mkv+theora
> because e.g. there isn't a way how to add subtitle streams to ogg.

Thats not correct. For example, --subtitles argument to ffmpeg2theora
takes a .SRT file and multiplexes it as Ogg/Kate.
(http://wiki.xiph.org/index.php/OggKate)

(Thats a case where playback support is lacking in many tools— but it
exists, is well specified, and isn't some kludge)

> Putting video in ogg is suboptimal and if theora starts to get used more
> widely, people will probably realize the need for full featured
> containers like matroska for storing theora.

Matroska is reasonable, but 'suboptimal' really depends on your usage.
Ogg is designed for real-time streaming and does that better than
Matroska. Matroska is designed for non-linear access, can't be written
in a single pass (AFAIK), and does non-linear access better. (For
typical usage Ogg is lower overhead too, though the difference is
small).  If you need to do piece wise editing, Matroska is vastly
superior. For 'play a movie' purposes, the fundamental differences are
small enough that most users will not care.

>> Some of the proprietary-codecs focused tools provide their own home
>> grown implementations of the codecs (i.e. ffmpeg). These often do not
>> implement the full spec, so its important to test their behaviour.
>>
> Last time I checked, ffmpeg contained open source but patent encumbered
> codecs (i.e. not libre)... I don't think that classifies as proprietary.

Webster says:

Proprietary — something that is used, produced, or marketed under
exclusive legal right of the inventor or maker  ; specifically : a
drug (as a patent medicine) that is protected by secrecy, patent, or
copyright against free competition as to name, product, composition,
or process of manufacture

This is pretty much a perfect description of the codecs licensed by mpeg-la.

There pretty much isn't a word that you can use to describe codecs
free of copyright restrictions but encumbered by patents that won't
cause someone to object.

On Mon, Feb 9, 2009 at 6:20 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> FFmpeg is NOT proprietary-codecs focused. It just strives to be able to decode
> any audio and video codec and demux any container that has ever been used.

Yet it has a pretty long history of poor and support for freely
licensed codecs. That ffmpeg has better support for things which must
be reverse engineered than for things with freely licensed references
is a strong argument against the position you are taking here.  I
won't continued to claim otherwise, however, if that isn't the
official line.

> What's unfortunate about that? libtheora and libvorbis are not written
> in an optimal way according to FFmpeg developers.

Only, because the implementation is inferior, not spec compliant, and
because it causes problems for users who become unsuspecting users of
these versions.

Even ignoring the incompatibility—

A 45kbit/sec Vorbis file from libVorbis:
http://myrandomnode.dyndns.org:8080/vorbis/sample-libvorbis45kbit.ogg

Vs what you get when you ask ffmpeg for 128kbit/sec: (the result is
really 64kbit/sec)
http://myrandomnode.dyndns.org:8080/vorbis/sample-ffmpeg128kbit.ogg

This is not a small difference.  Listen to them and tell me again that
you think the developers of FFmpeg have made a reasonable decision in
their determination that libVorbis is "not written in an optimal way".

The only people in the free software world who have interest in
contributing to FFmpeg's "optimal" reimplementation of these libraries
is the ffmpeg developers themselves, whos efforts are obviously
insufficient.  Everyone else would prefer to work on the reference
versions which are more widely used and higher performing.

So— I think it's good that FFMpeg developers are doing their own
thing, but when you come in suggesting that libavcodec is something
other pieces of free software should be using for libre codecs, I must
protest loudly.

Since you clearly care about making ffmpeg work, I'd be glad to send
examples your way. However, you should start with disabling the Ogg
CRC check and fuzz testing the input using zzuf.  The last time I did
this to ffmpeg it failed very miserably.

> While I agree that FFmpeg's Vorbis implementation has its own problems,
> I resent your suggestion that there is a "proprietary codec culture"
> at FFmpeg.

I should have perhaps been more specific. One issue with the
encumbered codecs is that there does not usually exist a liberally
licensed well performing alternative, so you are forced to write your
own.  libVorbis, libTheora, etc. are by no means perfect but to a
media related project which dealt only with open codecs,
reimplementing these codecs would be simply inconceivable.  If the
codecs had problems, they'd submit patches, or —at worst— fork the
reference.   FFmpeg, on the other hand, ships a half-working non-spec
compliant from-scratch version.  While even that much is an impressive
accomplishment, and additional interoperable implementations are
helpful, habitually broken ones are not.  ...and that FFmpeg undertook
the large labour of reimplementing while basic functionality was still
missing is exactly the 'culture' that I'm talking about.
"Reimplement everything from scratch" only seems reasonable if you
live in a world mostly of non-free things.

> Most of FFmpeg developers are from the Europe, where
> stupid US patent law.

Often these liberally-copyright-licensed-but-patent-encumbered media
infrastructures are promoted with claims that that codec patents do
not exist in Europe. But this is, pardon the pun, patently false. In
fact, the majority of the codec rights holders are European companies,
who hold various patents in Europe, and the relevant US patents refer
to the foreign filings of the same patents.

Pure software is not patentable in the US: To patent software in the
US you must undertake a little dance where you patent "A
microprocessor, configured via software, executes task X".  This
method of patenting software 'indirectly' has been clearly available
in the US since the early 80s.  The exact same method works in Europe
since 1986 (http://eupat.ffii.org/papers/epo-t840208/index.en.html).

There has been a span of time when 'pure software' has been patentable
in the US, as a result of State Street Bank v. Signature Financial
Group in 1998. Interestingly, the European patent office also
authorized pure software claims the same year
(http://eupat.ffii.org/papers/epo-t971173/index.en.html).  Now,
however, the standing case law in the US comes from In re Bilski last
year which appears to have substantially overturned State Street on
this point.  The software-patent argument in Europe is largely over
the validity of the patent office's authority to make this
pure-software determination without legislative input.  I'm not aware
of any evidence that the 'indirect' method is believed to be
inapplicable in Europe.

While the non-patentability of pure software is important it is not of
relevance to codec patents: Many interesting codec patents are
pre-1998 and were granted patents long before 'pure software' was
patentable. These patents have been enforced all over the world, and
net their holders hundreds of millions of dollars a year.  It is true
that since pure software is not patentable, those distributing source
and not combining it with a machine can probably dodge patent
litigation. This isn't really helpful to our users, making them into
criminals, and it's not something unique to Europe.  There are a great
many things which are forbidden under copyright and patent law which
99.99% of the people can get away with 99% of the time, this is true
no matter where you are, but it doesn't make doing it wise.

> H.264 codec has an open specification and is
> superior to ANY libre video codec, maybe excluding Dirac (but Dirac
> is incomplete and Snow is better anyway). Also it is one of the most
> popular commercially used codecs, so it's only natural that there is
> significant interest in having a superior implementation of it in FFmpeg.

I will humbly submit to you that the major commercial interests have
no monopoly on brilliance: The continued success of the FFMpeg
developers (in things other than support for libre codecs) has easily
demonstrated their intellectual prowess. Likewise, we see evidence of
brilliance from other teams, for example Xvid is an astonishingly good
implementation of MPEG4 part 2.

Almost every libre codec has been primarily one or two person
development. The open-copyright-license but encumbered codecs have
continued to capture significantly larger portion of the FLOSS
developer base. Often these copyright-permissive versions of
encumbered codecs encoder are equal to or substantially better than
the best commercial offerings and they are almost all uniformly better
than the published reference implementations (where ones exist).

And why would patent holders complain about this? Developers who would
never pay anyways, making better versions of codecs that the license
holders still own regardless, more people adopting… then they can pick
and choose who they come demanding payment from.

So I do not think it is unreasonable to suggest that the libre codecs
will stop being inferior as soon as free software authors stop
spending so much time making the worlds best implementations of
non-libre codecs and pretending that they are libre because no one has
knocked down their door yet.

2009/2/9 Martin Sourada <martin.sourada at gmail.com>:
> Interesting thing I noticed was that the videos,
> even when compressed losslessly using dirac, are slightly less sharp
> than the original images [2].

I don't have tools to pick apart dirac streams as I do for Theora, but
I'd put money on your 'lossless' dirac only being a lossless copy of
the colorspace converted input.  Your RGB data was probably first
converted into YUV 4:2:0 which has lower resolution for the color
planes and can result in a slight loss of sharpness.




More information about the devel mailing list