[haiku-commits] Re: haiku: hrev52434 - src/kits/media src/kits/codec headers/os/codec headers/private/media src/kits/media/experimental

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 25 Oct 2018 08:45:04 +0200

Good morning,

As already stated, the idea is that libcodec will be something more like
libstagefright, where libmedia2 will be like libmedia (I mean the android
versons OFC).
I think it is rather *obvious* why I choose this path in the end. But I
understand my work may be obvious sometimes so let's clarify a few things.

Okay, calling all comas, let's reply to the same questions again.

The media kit is, well, the base API for media processing. Media file I/O

is part of that, so to me it seems they should be in the same kit.


Not necessarily. This is not an argument at all. Media file I/O is
something fundamentally different than real time A/V. There are different
tolerances in play and there are different functionalities. Ideally, a file
API should be targeted at flexibility (like format conversions), where real
time A/V will be targeted at stability and performances. So, no, it is all
in your mind and, again, no arguments for a non-sense critics.

Additionally, the codec kit will be low level in the sense that it will
take care of formats and conversions, where the media2 will not have to
care about that except respecting the constraints of the codec kit.


Huh? That's the job of individual plugins, and then the media kit
respects those constraints already. Isn't that what we have now? Why do we
need a media2 here?


Sorry you don't understand the current issues with the media_kit. I am not
willing to repeat again and again.



As stated like a dozillion times in IRC and ML we don't properly support
format constraints. The media nodes does crazy format change handshake
which in the end doesn't work and make the whole design painful. There are
a number of things overlooked in a realtime A/V framework that should be
really put elsewhere.
For example, BFileInterface is rather ugly and will be replaced by
something much more linear and simple (following).



The API design of BMediaTrack might need to be rethought, but the plug-in
API itself seemed mostly sound.


No. The problem is not BMediaTrack itself that works like similar classes
in other systems, the problem is what you plug into it.


We need to abstract the concept of media_source and media_destination once
more. In this case those will become "abstract source/destination objects"
that will be useful to abstract a bit more (with the help of BAdapterIO)
some parts of the codecs.


Should I read "splitting them in a separate kit"? If not, I already
stated in a previous post that I may in the end use the same library for
the codec and media2 kit.


This doesn't make much sense. If you are trying to reuse code between the
Media Kit and Media2 Kit, then just move the functionality to the Media2
Kit and reimplement the Media 1 Kit classes using the new APIs. Which seems
to be what you are doing away, only fragmenting APIs in a way that makes
little sense.


Again, it seems you don't understand what I am doing.


I don't know where you got that thing, I am not trying to reuse code
between Media Kit and Media2 Kit. The inverse, I am trying to move out the
codecs from the current media kit to improve abstraction.

-- 
Saluti,
Dario

Other related posts:

  1. Home
  2. haiku-commits
  3. Archive
  4. 10-2018