[haiku-inc] Re: Contract Proposal Probe

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-inc@xxxxxxxxxxxxx
  • Date: Sun, 28 Feb 2016 20:30:32 +0100

Hi,

On Sun, Feb 28, 2016 at 7:53 PM, Adrien Destugues <pulkomandy@xxxxxxxxx>
wrote:

On Sun, Feb 28, 2016 at 12:35:30PM +0000, Sean Collins wrote:
I would however fork the existing media kit, and call the existing media
kit
LibLegacyMediaKit and implement it is a library

It already is libmedia.so, and can't be renamed because of binary
compatibility.


We might introduce a libmedia2.so anyway.



to really accomplish what dario wants to do accomplish, is going to
require
scrapping a lot of the existing code and really changing the way things
operate.


I'm not going to rewrite the media_kit during this contract. The
BMediaClient API is something that will provide an higher level abstraction
over the media_kit. This will give us two advantages among the others, the
first is that we can begin to build more complex applications using the
current media_kit (such as libjackcompat), the second is that we give to
the applications using it a way to more easily switch to the new
media2_kit. To some extent this API is also an experimentation to what the
future API could look, but right now it's not related in any way to a
media_kit rewrite.


I think looking at existing solutions like ASIO or Jack would be
the best thing to do. also while FFMPEG is a nice layer for pro audio
work
everything is raw audio streams.

ffmpeg is only a plug-in, and only used to decode/encode media files. It
is not used in the core of the media kit anywhere (mixing, data streams,
etc).


Additionally existing frameworks are unusable due to being too much
concerned to a specific application (i.e. jack and audio) or being too much
generic for us. We can still learn from others and put advanced
technologies in the kit.



Moreover, the media kit is not limited to pro audio. It just works with
realtime streams, and is mostly independant of the stream contents. So
you can carry raw audio, raw video, encoded a/v, subtitles, or anything
you may think of that requires precise timing.

I dunno, I suppose fixing problems is a good plan, but it may also break
many existing apps, it may just be better to put in a layer of
abstraction
and start over to some extent.

As far as I can see, the goal of this contract is to improve on the
existing media kit, to better support streaming and fix several other
longstanding issues. This seems mostly independant from Dario's plan to
write a new media kit, which could be handled as you desccribed.


-- 
Best Regards,
Dario

Other related posts:

  1. Home
  2. haiku-inc
  3. Archive
  4. 02-2016