Apache OpenOffice (AOO) Bugzilla – Issue 69665
Duplicate
Last modified: 2007-06-24 18:58:41 UTC
Create Quicktime backend for avmedia module, to support native audio and video on Mac OS X. Although this implementation concentrates on Mac OS X, it should be possible to make this work on Windows-platform too. Initial (non-working) patch included below, created from the stubs of Xine backend, in milestone m184.
Created attachment 39238 [details] initial (non-working) patch, structure for quicktime backend of avmedia
. OK - who will continue to work on this? Mox or Eric? Or (preferably :-) both together?
I am open to other people also working on this. It was just important for me to have a sane basis for this work (directory structure, naming conventions, stubs).
changed to task issue duplicated with #i66170# @all : please read carefully http://www.openoffice.org/FAQs/faq-licensing.html#usinglicenses *** This issue has been marked as a duplicate of 66170 ***
EricB: 1) The other bug has a less informative title than this one. 2) Stop making empty accusations! There is nothing wrong with the licensing in my patch. All the xine backend code that I used as basis are from OOo CVS: avmedia/source/xine. And my patch has licenses that are exactly like your files. 3) in wiki you claim to have an initial implementation. It is not an implementation for macosx. It is cut-n-paste of windows backend, with some function names changed. I checked this. You are no further than me. 4) quicktime is NOT aqua. If you copy-n-pasted the gstreamer backend and called that aqua player, you would be as close to truth as you are now. Once quicktime backend is ready, it is not a big change to make the same backend run on Windows. How do you explain that you can have a "aqua player" running in Windows OpenOffice.org???
ericb->mox There is no accusation, so please, calm down. Second, what is the problem with the work I did with the wiki page ? *None* was working on it, and just after I created the wiki page, you came and modified everything: I simply disagree. Open a track, find/read/calculate it's parameter, play stop, playback using QuickTime API..etc is not the most complicated: our problem is to define a correct design for the correct implementation. If I already wrote the method names, you can believe me, I have a good idea of what they will contain, just free time is missing to complete the work. FYI, what I want to do is describe the design of the implementation, with a complete description of our work (even in time), to proof we really did the work. Not just put a patch coming from nowhere, without explanations. About the naming conventions, I perfectly know the API is QuickTime, corresponding files have to be completely rewritten, for Mac OS X, using Mac OS X API, but I have good reasons to use something else than QuickTime. The windows files are just here as reminder, obviously. Last, if you want to know the exact reasons why I proceed like that, I invite you to discuss about that on IRC. Quietly.
Created attachment 39320 [details] work-in-progress patch of quicktime backend, version 2
the v2 of the patch has a partial implementation of the Quicktime backend. The most important part missing is the window/frame/graphics handling (i.e. the glue to have video output target that quicktime can attach to) + the player creation. The simple playing functions are implemented. Status of the backend is shown below. DONE: * player: 70% * makefile.mk 95% * framegrabber: 100% * quicktimecommon: 100% * quicktimeuno: 100% * manager: 100% * window: .hxx 95%, .cxx 30% Since it seems likely that this same backend could be used (with some additional porting) in X11 and "aqua" on Mac OS X and in Windows, I see no reason to change the naming conventions I did, to the "design" of EricB. It is just not the best one.
ericb->mox Again, I invite you to discuss quietly about the player implementation using IRC on irc.freenode.net e.g. on #ooo_macport channel
EricB: If you had wanted to respect my work, at the beginning, you would have contacted me with email to and asked what you did not understand. I have already explained my choices and now I want to spend my time coding instead of discussing. We can have a discussion if/when my implementation is more complete. Only by coding I can get an understanding of what are the good choices.
.
Closing duplicate.
QTKit is a better choice for the future than QuickTime ( soon deprecated). Mox: where are you with that task ? If you don't want to continue, please reassign to macport, and somebody else will take over. Thanks.
QTKit is just another way to implement Quicktime viewer, although better one, if Cocoa can be used (although I was not at the WWDC, so what do I know). Anyway. As this is a duplicate, nothing in here matters.
ericb->mox ok, I was just doing some cleanup : I consider nobody is working on native sound support at this time, but we will use the attached code as starting point.
Why has the summary been changed to duplicate? It is meaningless.