[Haiku-commits] r33343 - in haiku/trunk/src/add-ons/media/plugins/theora: . libtheora libtheora/theora libtheora/x86

[Stephan Assmus]

Hi,

On 2009-09-29 at 17:10:33 [+0200], David McPaul <dlmcpaul at gmail.com> wrote:
> 2009/9/29 Stephan Assmus <superstippi at gmx.de>:
> > On 2009-09-29 at 11:55:02 [+0200], David McPaul <dlmcpaul at gmail.com> 
> > wrote:
> >> 2009/9/29 Stephan Assmus <superstippi at gmx.de>:
> >> > On 2009-09-29 at 09:51:52 [+0200], David McPaul <dlmcpaul at gmail.com> 
> >> > wrote:
> >> >> 2009/9/29 Stephan Assmus <superstippi at gmx.de>:
> >> > I don't understand what you mean. My concern is with manageable code 
> >> > as well. Compared to the code that wraps around the Xiph codecs in 
> >> > our repository, our FFmpeg wrapper is very little code. I consider 
> >> > that more manageable. So I was looking for other compelling 
> >> > arguments.
> >>
> >> We could just drop the whole plugin concept and use ffmpeg for 
> >> everything.  There is no plugin we have that ffmpeg has not got 
> >> covered.
> >>
> >> Where do we draw the line?
> >
> > To be honest, I see this more practical. IMHO, the plugin concept is 
> > nice, we should definitely keep that. But that doesn't mean we can't 
> > drop most of the plugins if there is a more maintainable way to support 
> > all those formats and codecs. To give a concrete example, I am having 
> > problems with some .wmv files I tested with
> 
> Ticket No?  :-)

I just found out today that it's actually the fault of the ASF reader, 
before I didn't even know where the problem was.

> >, and by switching to the ASF demuxer in
> > FFmpeg, all the problems go away. Can you give me a good reason why I 
> > should dig into the ASF demuxer code to find the problems when I have a 
> > much simpler solution right in front of me? Haiku is not about 
> > maintaining two code-bases for the very same purpose. I just don't see 
> > the point of it and until now, I have not heard a good argument pro 
> > maintaining our own codec and demuxer implementations, especially when 
> > all but two maintainers have pretty much no time for Haiku anymore.
> 
> 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 like programming Haiku because I get to learn about media formats and 
> codecs and the like and right now I seem to be the only person doing 
> anything with that part of the system.  I wrote a SSE2 conversion routine 
> for Haiku recently, it was difficult but rewarding.
>  I learnt a lot and Haiku video got to be faster on VESA machines.

That is nice and I agree with the motive, but there will be friction as 
soon as another option becomes available to everyone just interested in the 
solution. For example, I thought to clean up the color conversion code that 
we use in the FFmpeg plugin, since I am using swscale for the encoder, and 
I was actually planning to use it for decoding as well. It does exactly 
what you have created. I have not tested it, but what if it's faster? 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?

> Yes, i don't have enough time to do everything or even enough knowledge 
> to be able to but we have that problem all over Haiku

But that's exactly the reason why we should re-use simple blocks of 
functionality where possible. Such that the project doesn't overwhelm 
everybody. We've got to put some checkmarks at least somewhere.

> We need more developers and I think it is easier for a new developer to 
> step up and work on our codebase and get changes done than it will be for 
> someone to make changes to ffmpeg.

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.

[...]
> >> The Ogg reader code seems more complex but I don't know anything about 
> >> the ogg container format to decide.
> >> The original author looks to have created a track subclass for each 
> >> type of stream available in the container.
> >>
> >> So to fix the issue raised we just need to create a new subclass for 
> >> the missing codec.
> >
> > So you are saying we are better off when you (or someone else) spends 
> > his valuable time to try to dig into the OggReader source code to add 
> > the missing features, as well as fixing any issues that may pop up, 
> > when all we have to do is configure FFmpeg with Ogg support and be done 
> > with it? Especially when that would also take care of encoding for free?
> 
> Well, it is my time to spend.  There is not much else in Haiku that 
> interests me so I doubt I would do much else.

I don't really know what to say to that, see below.

> > It may seem like I have made up my own opinion on this subject, but I 
> > am actually trying to hear good arguments pro keeping the code we have. 
> > After all, it was hard work to create it. That a lot of the maintainers 
> > don't have time to keep working on their code is one thing. But if 
> > there are no other compelling arguments, like for example the Haiku 
> > code is multi-threaded, while FFmpeg is not... (which is not the case), 
> > or other technical reasons, I just don't see the point.
> 
> 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?

> 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. 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.

Best regards,
-Stephan