[haiku] Re: GSoC: Writing native interfaces for ported applications
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Fri, 02 Apr 2010 17:01:20 +0200
Hi,
> I've posted my proposal for working on Media Player, and was just
> wondering
> if some of my ideas are too much, or if I'm missing something really
> vital.
>
> For some reason the online editor is determined to mess up my page layout,
> so to avoid death by layout, it's also a public Google document
> http://docs.google.com/View?id=dsc8xgj_49cv7z3jfk
The proposal is nice and I personally like the project (and could probably
mentor it). However the proposal could be even stronger if you could use the
remaining time to research some of the topics which right now seem to be very
broad ideas yet. To give an example: In your proposal, you have options like
"Investigate which Kit could be used for streaming (Network Kit, Media Kit) and
implement streaming if necessary". You could investigate this right now, find
out exactly if implementing streaming is necessary (hint: it is), and how. If
you dig into the Media Kit code which reads from file streams, does the
demuxing and decoding (src/kits/media/MediaExtractor.cpp and friends as well as
most MediaExtractor plugins in src/add-ons/media/plugins/...), you will see it
is based on dynamic casting BDataIO objects (streams without position info)
into BPositionIO objects in order to do the necessary seeking to absolute file
positions which some container formats depend on. Instead, th
is will need to be done differently. Either the BDataIO is really a
BPositionIO or not, but if it isn't the code should not fail for some
containers, but only seeking should simply become unavailable instead.
Also as I mentioned, the MediaPlayer has an internal abstraction for the
MediaKit. So to get things going, you could work on extendng that code instead
of the MediaKit, at least at first because it may be easier (code is more
contained), and then transfer your work and experience over to the MediaKit
later, when you have a much better understanding of a lot more code. This again
could be mentioned in your proposal.
Much in the same way, more of your bullet points can be researched relatively
quickly I think. If you do that and replace some of the vagueness with concrete
ideas, your proposal will not only become much stronger, but you will have a
better idea what your work will be over the summer and what you can accomplish
in the time frame and what probably not. This in turn will give you confidence
and you could even extend your proposal with a rough timeline.
Other random tidbids:
* MediaPlayer already starts instantly, the QuickPreview thing is bogus, IMHO.
* Preview icons in Tracker are a nice idea, but will require to extend the
icon code to support arbitrary PNGs (not too hard, but probably a week of work
including testing).
* Tracker should use the Media Kit directly for generating previous, not the
MediaPlayer via scripting, IMHO.
Best regards,
-Stephan
Other related posts:
