[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@xxxxxxxxx>: [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@xxxxxxxxxxxxxx> 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@xxxxxxxxx>: > 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
