[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-commits
Subject:    Re: [Haiku-commits] r33343 - in
From:       Stephan Assmus <superstippi () gmx ! de>
Date:       2009-09-30 8:45:38
Message-ID: 20090930104538.974.3 () bepc ! 1254292571 ! fake
[Download RAW message or body]

Hi,

On 2009-09-30 at 03:13:25 [+0200], David McPaul <dlmcpaul@gmail.com> wrote:
> 2009/9/30 Stephan Assmus <superstippi@gmx.de>:
> > On 2009-09-29 at 17:10:33 [+0200], David McPaul <dlmcpaul@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 
> demuxer?

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.

100% agreed.

> >The
> > 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. :-(

Best regards,
-Stephan

_______________________________________________
Haiku-commits mailing list
Haiku-commits@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/haiku-commits
[prev in list] [next in list] [prev in thread] [next in thread]