[Haiku-commits] r33343 - in haiku/trunk/src/add-ons/media/plugins/theora: . libtheora libtheora/theora libtheora/x86
superstippi at gmx.de
Wed Sep 30 10:45:38 CEST 2009
On 2009-09-30 at 03:13:25 [+0200], David McPaul <dlmcpaul at gmail.com> wrote:
> 2009/9/30 Stephan Assmus <superstippi at gmx.de>:
> > On 2009-09-29 at 17:10:33 [+0200], David McPaul <dlmcpaul at gmail.com>
> > wrote:
> >> That same argument could be used for why are we building Haiku at all
> >> or the MediaPlayer app when we have VLC.
> > I think the comparison is not fair. It's like you tell me I shouldn't
> > try to build a house if I am not interested in making my own stones.
> I think it is, MediaPlayer could be replaced by an mplayer port. mplayer
> uses ffmpeg and other libraries to handle media files. mplayer provides a
> complete solution to playing media. So why is it ok for you to write and
> maintain a media player but not ok for me to write and maintain an asf
MediaPlayer has a lot of features. For example, it uses media nodes not
only for audio, but also for video. It has playlist management and lots of
other things that work differently from how mplayer works. The sum of the
features result in a user experience. The ASF demuxer has exactly one
feature: It takes a stream of bytes and splits it up into chunks. There is
exactly one correct end-result. My question all a long was, what, in your
opinion, are the *technical* benefits of writing and maintaining your own
ASF demuxer versus making a five lines patch to the FFmpeg reader to enable
ASF demuxing (i.e. utilizing the code which is also already in our repo).
May I remind you that we talked about how to support MPEG streams? You told
me you would probably consider porting mpeg123. Later I went ahead and
imported libavformat alongside libavcodec. Same thing as porting mpeg123,
pretty much. Only that this work enabled supporting a whole bunch of other
formats for free, by making five lines patches.
> Please don't put colour conversion at the decoder or encoder level. It is
> something that has to be done at the media kit level so it is available
> for everything to use.
> > same problem would arise when somebody comes along with a better
> > app_server. The app_server was my playing ground and I know there is a
> > lot of room for improvements. The app_server is sufficiently complex
> > and unique that it is unlikely that we can re-use something existing
> > and maintained elsewhere, but suppose it were the case, then we'd have
> > the same situation: app_server is my playground, but everybody is
> > interested in it being as fast and robust as possible. So what should
> > be done in such a situation?
> As I said where do we draw the line. This is what we are arguing over.
Yes, but you don't give arguments. The only argument so far is that it
means fun to you maintaining your own ASF demuxer. That's of course a valid
argument, I really don't dispute that, but I feel that I also have valid
arguments. And I don't like to be the bad guy because of it.
> > We can just keep the code in the repository and if someone comes along
> > and is interested in picking up the work, then that's awesome. I am
> > just interested in rock-solid media capabilities, because I find
> > projects such as Clockwerk much more interesting to spend time on.
> Once we switch to using ffmpeg for all our media needs, I very much doubt
> someone will come along and work on anything else.
What does that tell you? To me it means we probably found a good solution
to a problem then.
> >> There is no argument, we need developers. If we can attract
> >> developers who are interested in writing and maintaining media code
> >> then we should have the code. If we cannot then we just become
> >> another user of ffmpeg.
> > But what is so bad about that?
> Good luck getting changes to ffmpeg merged upstream.
I am not even interested in making changes in ffmpeg. And if I indeed find
a valid bug and even have a patch, why would it not be applied?
> >> Certainly the last thing Haiku needs is to rely on me fixing Media
> >> issues.
> > You need to make up your mind. Either it's about experimenting and
> > learning, or it is about implementing the best solution to a problem,
> > even if that means to re-use existing code.
> I am trying to do both.
Me too. :-)
> > One part of the equation is
> > certainly the perceived progress. If you have enough time to spend on
> > coding, such that everyone feels things are moving forward fast enough,
> > then why would anyone look for other options? Do you want to work on
> > the OggReader? Or do you want to maintain ASF, MOV and MP4? Personally,
> > I am interested in reliable demuxing of the videos I happen to come
> > across, and I am very interested in support for the Xiph codecs,
> > especially also encoding. That just seems like a lot of work if it were
> > to be based on our own plug-in.
> Ok I get it, I am not working fast enough but I think we are all waiting
> on things to be done by others. I am still waiting on a fix for the
> Intel Extreme driver so I don't have to use VESA on my EEE PC.
> Marcus would like the MediaPlayer code to be fixed so that it uses the
> mixer code instead of it's own code and give him back 5.1 channel AC3.
> Well it is simple enough I suppose, I don't have any more time available
> so if my efforts are not enough to let you make whatever your deadlines
> are then just tell me to step aside and I will.
I can absolutely feel your pain about having to wait on some random feature
in Haiku. And considering how many bugs are assigned to me, there are
probably quite a few things people wait on for me to finish. But there is a
difference between work that has to be done (and where any alternative
means just as much or even more work) and a five lines patch enabling work
that is already accomplished. Exactly because all of our plates are so
full, I am even making this proposal.
You have to consider the history of this: I imported FFmpeg to support mpg
files. It would have been laughable if Haiku R1/alpha1 got released without
support for mpg files, don't you agree? I decided to use an existing
library, just what you would have done (!!). But I ended up using one that
makes it possible to support so many more formats, and even encoding, too.
So having done all this work, I begin to wonder if I couldn't use this to
fix some problems in the existing code. But sadly it means this code would
become obsolete. Of course I wonder why it was written in the first place
instead of porting libavformat which was available also back then. I am
trying to get more input by starting this discussion. But the only real
argument is that I would hurt your feelings. And now I am the bad guy. :-(
More information about the Haiku-commits