[gst-devel] Re: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond .....

Christian HJ Wiesner chris at matroska.org
Fri Apr 16 07:32:03 CEST 2004


Hi Thomas !

Its an honour to have you posting to our list, hope this wont be the 
last time.

Thomas Vander Stichele wrote:

>Hi,
>I think there isn't a real problem at all and it has just been blown out
>of proportion a little due to a lack of good communication.  I'll
>summarize in a nutshell what, IMO, went wrong, and then I'll try to
>explain by replying to parts...
>
>a) The actual implementation discussion was held on the matroska mailing
>list when it should have been held on the GStreamer mailing list.  If
>the technical problem is about GStreamer code that needs changing to run
>on Windows, it should be discussed on the GStreamer mailing list.  To me
>that seems clear.
>  
>
Yes, i agree with that. But as always, people are subscribed to too many 
lists already and therefore our devs were lazy and using the 
matroska-devel list for discussion, although i agree its actually not 
the right place. But it was convenient as BBB is subscribed there, and 
also you have to understand that currently not all team members of the 
matroska team are 100% enthusiastic about trying to create the next 
generation matroska tools ( incl. video editors ) based on Gstreamer. As 
a result, if we had been doing the discussion on your list, some 
matroska team members would have missed it all completely.
I am pretty sure we will find a way here, maybe by having a new, low 
traffic list together with you ( on your host or ours, that doesnt 
matter ) to care specifically about the Gstreamer porting to Windows and 
the matroska tools based on it, we'll see. For the time being i highly 
appreciate if you could copy matroska-devel, like you did in this email.

>b) When discussing the actual implementation, "the Matroska team" should
>regard Ronald's opinions as his own, and not as the GStreamer team's. 
>To me that seems fairly clear as well - if Ronald says he doesn't care
>about Windows, that doesn't mean GStreamer doesn't care about it. 
>Likewise, if Ronald says "a patch will be refused" it doesn't
>necessarily mean the GStreamer team will refuse it.  Again, it should
>have been discussed on the GStreamer mailing list.
>  
>
BBB is our friend, and we fully trust him on this, as we do now. Of 
course, we should have known he is a real Linux hardliner and take his 
comments with some grains of salt maybe ;-) .....

>c) There is a huge difference between "not accepting a patch" (for
>whatever reason), "refusing the patch", and "refusing the possibility of
>patching a certain piece of code".  What Ronald did was say "the patch
>done like this cannot go in".  That means you can rework the patch to
>address his concerns.
>  
>
ACK

>d) Announcing a fork is not a good way to address communication
>breakdowns.  It makes both teams look very silly and immature :)
>  
>
I apologize for that, but you have to admit, with announcing the fork i 
finally achieved what i wanted ..... a clear statement from one of the 
Gstreamer lead developers about this subject ;-) . Believe me, if  i had 
favoured to fork from gstreamer, i wouldnt have told you about it on IRC 
first ..... look at my announcement as a kind of wake up call on 
#gstreamer  :-D !

>>>So, if anybody here has problems with a Windows port because he wants 
>>>Gstreamer to be exclusively usable on Linux desktop's and hates Windows, 
>>>well, IMO you should rethink your point of view here.
>>>      
>>>
>I am pretty sure there aren't many on our team that feel that way.  What
>is true is that some of our developers just don't care about Window,
>period.  That is, mind you, quite a different point of view than hating
>Windows and wanting GStreamer to be exclusively usable on Linux.
>AFAICT, Ronald is one of these people, as he's stated repeatedly on IRC,
>and it is his right to do so, and from his POV I can understand.  But
>that doesn't mean everyone on our team feels the same way.
>To be clear, personally I think it would be incredible if GStreamer
>worked on Windows; I'm just not in a good position to help a lot beyond
>what we can do on our side to integrate code, since I haven't really
>used Windows for 4 years.
>  
>
Dont worry, the matroska team currently consists of more Windows coders 
than Linux coders ( only Haali and Mosu ), and i guess we have proved 
already that we are capable to make nice and stable Windows 
implementations of our stuff. As long as we get the support from your 
side to be able to do what is necessary to make this a succesful port, 
we wont run into problems IMO.

>>>What i understand from the matroska team is that using GCC is no option 
>>>for porting gstreamer, for reasons i dont know and won't comment on. So 
>>>please, have an internal meeting and make a decision on how we could 
>>>come together. After all, we are still interested a lot in making this 
>>>happen, but we wont maintain a parallel MSVC version of Gstreamer, with 
>>>the need to rewrite every single plugin to make it compile. I very much 
>>>hope you guys could move into our direction in this matter.
>>>      
>>>
>As far as I know, the ONLY problem there was was the use of variadic
>macros for the debugging system.  If there is something else then please
>speak up now.
>Now, on that matter, the patch that got proposed by you was one where
>you would create, for each GST_DEBUG type macro, a bunch of GST_DEBUG_x
>macros where x is the number of arguments.  I think you can see why this
>is an ugly hack, and I think you can also see why this would mean we
>need to rewrite EVERY piece of code that uses the debug system.  Ronald
>proposed to use inline functions as a solution and asked to rewrite the
>patch that way, but he says you didn't do so.  Getting a problem
>addressed is a matter of communicating and discussing possible
>implementations between two people.  It's up to the person trying to get
>a patch in to address concerns of the person who is looking at the
>patches.  In this case, it wasn't too hard I think to submit a patch
>doing just this.  In fact, David (from our team) did just that last
>evening, from the looks of CVS.
>
Jory got the latest 0.8.1 sources from your server yesterday, and was 
very delighted to see that most of the vararg macros seem to have 
disappeared :-) !

>>in the end these plugins would run under Windows and Linux. But you 
>>don't want this solution, don't you ?
>>    
>>
>
>Maybe I didn't understand what you are saying correctly.  So I'll just
>say what I think: I very much want a solution where most of the plugins
>are completely the same under Linux and Windows.  The only plugins that
>should be different are plugins that interface directly with the system;
>which would be input and output plugins.
>  
>
ACK. DirectX should be used for the output sinks IMO. As for the inputs, 
the matroska devs should comment on that.

>I mean, really.  A fork for some basic issue that could have been solved by the two teams talking to
>each other ?
>Let's just promise to talk some more to each other, and please have
>these discussions on the GStreamer mailing list instead of somehwere
>else.  At least that way everyone besides Ronald knows what's going on,
>and you guys also know what we think.  It's a lot better than assuming
>things we haven't said are true.  Let's work together to make GStreamer
>better on both Linux and Windows.
>I have no doubt in my mind that you guys are capable coders and that the
>work we can do together will benefit us both.  So let's make a bit more
>effort to talk to each other, as teams, and not only as individuals.
>And on that note - could you please let us know what else is causing
>problems on Windows now that the debugging problem has been resolved
>correctly (to the best of my knowledge, since I cannot test on Windows)
>Thomas
>  
>
Thomas, looking forward to get this moving with you guys !! I am just an 
organizer, and with limited time because of job and family, but rest 
assured i will try to help best i can !

Christian
matroska project admin





More information about the gstreamer-devel mailing list