Comments on: ffmpeg http://blogs.gnome.org/otte/2008/12/05/126/ Swfdec, GStreamer, Cairo, GNOME, me Thu, 09 Feb 2012 19:43:42 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Does FFmpeg Actually Suck? | Breaking Eggs And Making Omelettes http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-853 Does FFmpeg Actually Suck? | Breaking Eggs And Making Omelettes Tue, 09 Dec 2008 05:01:35 +0000 http://blogs.gnome.org/otte/?p=126#comment-853 [...] author Benjamin Otte has a blog post lamenting the problems of developing directly with FFmpeg. This finally prompted me to use my sucky [...] [...] author Benjamin Otte has a blog post lamenting the problems of developing directly with FFmpeg. This finally prompted me to use my sucky [...]

]]> By: otte http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-852 otte Sat, 06 Dec 2008 21:10:58 +0000 http://blogs.gnome.org/otte/?p=126#comment-852 Adam: You pretty much say exactly the same as me. Devs should try to avoid using ffmpeg and use something else instead. Plus: I didn't say ffmpeg sucks, I said they don't care about you. noname: Yes it will. Swfdec will support everything Flash files need. And RTMP is part of that. Besides, it's what I'm hacking on right now. Adam: You pretty much say exactly the same as me. Devs should try to avoid using ffmpeg and use something else instead. Plus: I didn’t say ffmpeg sucks, I said they don’t care about you.

noname: Yes it will. Swfdec will support everything Flash files need. And RTMP is part of that. Besides, it’s what I’m hacking on right now.

]]> By: noname http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-851 noname Sat, 06 Dec 2008 19:12:36 +0000 http://blogs.gnome.org/otte/?p=126#comment-851 unrelated to anything current does swfdec support rtmp? will it? unrelated to anything current

does swfdec support rtmp? will it?

]]> By: Adam Williamson http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-850 Adam Williamson Sat, 06 Dec 2008 18:37:38 +0000 http://blogs.gnome.org/otte/?p=126#comment-850 otte: if you meant it that way, then sure. But then, that's kind of the purpose of ffmpeg - they intend to provide a collection of codecs to be used by other projects. It's fine to say "it's better to use gstreamer or xine for purpose X than using raw ffmpeg because they provide a richer, stabler interface", but it's not really fine to finish with "...so FFMPEG SUXORS!", because to a large extent, gstreamer and xine can only do that because ffmpeg does such good work on the codecs. It's being deeply ungrateful to the guys who do a lot of hard work on the codec. Yes, it would be nice if they'd do proper releases with proper API/ABI stability guarantees. Believe me, I package or help to package several things which use ffmpeg, so I know that (it's probably worse for packagers than developers). But I'm not going to sit here and tell them they SUXORS just because they're not perfect. Just like I won't say gstreamer SUXORS because its codec compatibility is not yet anywhere near ffmpeg's. otte: if you meant it that way, then sure. But then, that’s kind of the purpose of ffmpeg – they intend to provide a collection of codecs to be used by other projects. It’s fine to say “it’s better to use gstreamer or xine for purpose X than using raw ffmpeg because they provide a richer, stabler interface”, but it’s not really fine to finish with “…so FFMPEG SUXORS!”, because to a large extent, gstreamer and xine can only do that because ffmpeg does such good work on the codecs. It’s being deeply ungrateful to the guys who do a lot of hard work on the codec.

Yes, it would be nice if they’d do proper releases with proper API/ABI stability guarantees. Believe me, I package or help to package several things which use ffmpeg, so I know that (it’s probably worse for packagers than developers). But I’m not going to sit here and tell them they SUXORS just because they’re not perfect. Just like I won’t say gstreamer SUXORS because its codec compatibility is not yet anywhere near ffmpeg’s.

]]> By: Alex http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-849 Alex Sat, 06 Dec 2008 16:28:44 +0000 http://blogs.gnome.org/otte/?p=126#comment-849 bkor: FFmpeg is a collection of libraries, and a collection of developers. Some of the developers do their best to help users who are having trouble. If you limit your complaints to specific individuals like Michal, then I will limit mine to specific individuals like Vincent. otte: FFmpeg provides a a .pc file for each of its libraries (libavformat, libavcodec, libavutil, and libswscale.pc). complaining that their is no ffmpeg.pc is like complaining that their is no gnome.pc. As far as the situation this week goes, VXL probably should have stopped in configure and asked Dave to install libswscale-dev. Ronald: agreed And everyone please try to understand, ffmpeg only has a handful of active developers. The most knowledgeable of which has specific was that he like to do things just like a Drepper (who also doesn't make releases, though he does make branches) or De Raadt. Due to legal fears, it doesn't get nearly the amount of corporate money as Gnome. It's biggest user, YouTube won't even acknowledge that it uses it. bkor: FFmpeg is a collection of libraries, and a collection of developers. Some of the developers do their best to help users who are having trouble. If you limit your complaints to specific individuals like Michal, then I will limit mine to specific individuals like Vincent.

otte: FFmpeg provides a a .pc file for each of its libraries (libavformat, libavcodec, libavutil, and libswscale.pc). complaining that their is no ffmpeg.pc is like complaining that their is no gnome.pc.

As far as the situation this week goes, VXL probably should have stopped in configure and asked Dave to install libswscale-dev.

Ronald: agreed

And everyone please try to understand, ffmpeg only has a handful of active developers. The most knowledgeable of which has specific was that he like to do things just like a Drepper (who also doesn’t make releases, though he does make branches) or De Raadt. Due to legal fears, it doesn’t get nearly the amount of corporate money as Gnome. It’s biggest user, YouTube won’t even acknowledge that it uses it.

]]> By: Ronald http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-848 Ronald Sat, 06 Dec 2008 15:42:20 +0000 http://blogs.gnome.org/otte/?p=126#comment-848 Benjamin: ffmpeg provides (and installs, unless the package is broken) separate libavformat, libavcodec, libavutil and libswscale.pc files. The broken API may be becuase of improper API use in projects, such as using private functions (not prefixed by av_*()) or stuff like that. You may be directly accessing codecs or codec features that don't yet exist, you may be statically allocating variable-size structures (new members are continuously added at the end, hence the existence of all av_*_context_alloc() functions), and there's a bunch more of these options. If used correctly, ffmpeg is API/ABI-stable. The adding of new items (and because of gobject, the not accessing struct members directly) is used more widely than just ffmpeg. The public API and ABI was never broken over the past 2 yrs, until September '08. The new API/ABI will be in place for the coming 1-2 yrs. This is the direction glib/gtk also discussed taking, and the kernel takes a similar approach. It needs to be broken occasionally for new features that weren't taken into account in the old API. Here's my suggestion: instead of seeing an ffmpeg problem and just blaming an pointing fingers, why not try to understand the problem at the developer-level (you're very, very smart, you'd have no problem whatsoever) and then try to see where the problem really is? You'll notice that personalities aside, the problem is usually in the application, not in ffmpeg. If you can point at the exact problem, it'd actually be helpful because ffmpeg developers can fix their mistakes. And they will. Right now it's just blaming and pointing fingers and this bidirectional hate makes the working situation worse, not better. Benjamin: ffmpeg provides (and installs, unless the package is broken) separate libavformat, libavcodec, libavutil and libswscale.pc files.

The broken API may be becuase of improper API use in projects, such as using private functions (not prefixed by av_*()) or stuff like that. You may be directly accessing codecs or codec features that don’t yet exist, you may be statically allocating variable-size structures (new members are continuously added at the end, hence the existence of all av_*_context_alloc() functions), and there’s a bunch more of these options. If used correctly, ffmpeg is API/ABI-stable. The adding of new items (and because of gobject, the not accessing struct members directly) is used more widely than just ffmpeg.

The public API and ABI was never broken over the past 2 yrs, until September ’08. The new API/ABI will be in place for the coming 1-2 yrs. This is the direction glib/gtk also discussed taking, and the kernel takes a similar approach. It needs to be broken occasionally for new features that weren’t taken into account in the old API.

Here’s my suggestion: instead of seeing an ffmpeg problem and just blaming an pointing fingers, why not try to understand the problem at the developer-level (you’re very, very smart, you’d have no problem whatsoever) and then try to see where the problem really is? You’ll notice that personalities aside, the problem is usually in the application, not in ffmpeg. If you can point at the exact problem, it’d actually be helpful because ffmpeg developers can fix their mistakes. And they will. Right now it’s just blaming and pointing fingers and this bidirectional hate makes the working situation worse, not better.

]]> By: otte http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-847 otte Sat, 06 Dec 2008 14:47:44 +0000 http://blogs.gnome.org/otte/?p=126#comment-847 Adam: GStreamer and Xine are the better ooptions because they do as much as ffmpeg (as they use it) and more, like for example providing a stable API and caring about their users. Which is why I suggested using it instead. GStreamer also adds dynamic codec installation or patent problem avoidance to the game, which ffmpeg doesn't offer. So from my POV ffmpeg is just worse. Ronald: No, that's an ffmpeg problem, just because it didn't only happen to Dave, but because it happens all the time. If ffmpeg cannot make it easy to write a configure script, it provide a crappy API (hint: an ffmpeg.pc would be nice). Also, they broke API way more often, because I remember people shouting at me from Gentoo, Debian, and wherever else when I still used it. Adam: GStreamer and Xine are the better ooptions because they do as much as ffmpeg (as they use it) and more, like for example providing a stable API and caring about their users. Which is why I suggested using it instead.
GStreamer also adds dynamic codec installation or patent problem avoidance to the game, which ffmpeg doesn’t offer. So from my POV ffmpeg is just worse.

Ronald: No, that’s an ffmpeg problem, just because it didn’t only happen to Dave, but because it happens all the time. If ffmpeg cannot make it easy to write a configure script, it provide a crappy API (hint: an ffmpeg.pc would be nice). Also, they broke API way more often, because I remember people shouting at me from Gentoo, Debian, and wherever else when I still used it.

]]> By: Ronald http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-846 Ronald Sat, 06 Dec 2008 14:38:46 +0000 http://blogs.gnome.org/otte/?p=126#comment-846 He was missing swscale-dev, it's a simple case of pebkac, presented as a ffmpeg problem. Blaming ffmpeg for everything and the kitchensink is about the lamest thing you could do, especially given how dependent everyone is on their codec (and muxing format, for some projects) implementations. Ffmpeg has broken their public API/ABI once in the past ~2 yrs, going from v51 to v52 in september '08. That was properly announced on the developer mailinglist and website. That is better behaviour than the kernel. Don't be so negative. He was missing swscale-dev, it’s a simple case of pebkac, presented as a ffmpeg problem. Blaming ffmpeg for everything and the kitchensink is about the lamest thing you could do, especially given how dependent everyone is on their codec (and muxing format, for some projects) implementations.

Ffmpeg has broken their public API/ABI once in the past ~2 yrs, going from v51 to v52 in september ’08. That was properly announced on the developer mailinglist and website. That is better behaviour than the kernel. Don’t be so negative.

]]> By: Peteris Krisjanis http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-845 Peteris Krisjanis Sat, 06 Dec 2008 12:46:58 +0000 http://blogs.gnome.org/otte/?p=126#comment-845 Adam Williamson: not so easy. In my opinion, ffmpeg has hintered *proper* development of free decoders/enconders of these formats. Everyone hacks on (literarly) on ffmpeg and no one is interested in proper and tested way of doing things. Users may like ffmpeg devs, but other devs have huge problems of "we-won't-do-stable-release-ever" attitude of theirs. Adam Williamson: not so easy. In my opinion, ffmpeg has hintered *proper* development of free decoders/enconders of these formats. Everyone hacks on (literarly) on ffmpeg and no one is interested in proper and tested way of doing things.

Users may like ffmpeg devs, but other devs have huge problems of “we-won’t-do-stable-release-ever” attitude of theirs.

]]> By: bkor http://blogs.gnome.org/otte/2008/12/05/126/comment-page-1/#comment-844 bkor Sat, 06 Dec 2008 09:30:39 +0000 http://blogs.gnome.org/otte/?p=126#comment-844 Alex: ffmpeg is one thing, GNOME is a collection. Your statement is wrong for the patches I receive. Please be more careful when trying to troll. Alex: ffmpeg is one thing, GNOME is a collection. Your statement is wrong for the patches I receive. Please be more careful when trying to troll.

]]>