[haiku-development] Re: Ideas related to the media_kit
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 14 Nov 2015 19:12:44 +0100
On Sat, Nov 14, 2015 at 06:28:56PM +0100, Dario Casalinuovo wrote:
3 - Hard channels synchronization. I figured out this while developing a
node with more than one output. I've miserably failed to get synchronized
sound from two mono tracks both connected at the system mixer.
How do we manage to play audio and video from a file with reasonable
syncing then? Because I'm sure that works.
4 - Midi support. The above problems are a clear response to the fact that
the midi support hasn't been included in the media_kit. I doubt we will
ever get a decent MIDI support as things work now.
Our MIDI kit is far more than decent, it works very well as it is. Are
you aware of some limitations? (besides the fact that it doesn't use the
media kit, so of course a media2_kit could take into account that we may
want it to transport MIDI and other things)
5 - DVD support
and
6 - Streaming. We know that the media_kit rely a lot on seeking and this
make difficult to implement streaming. This is not solvable cleanly without
a major API change AFAIK.
The media kit API does not put any restrictions on this. There is a
small part of the media kit where seeking is used (to rewind the stream
and pass it to multiple decoder plugins until one can handle it) but
that is easily solved by copying a small chunk of the stream to a
BMemoryIO and passing that to the plugins instead.
The main problem is that ffmpeg also relies on seeking before it will
play anything, but there may be ways around that. In any case, this is
not solved by replacing the media kit, I think.
As for DVD support, it may be possible to do that with the existing
features already. We have some buffering adapters written, and the dvd
decoder node could expose controls for the "remote control" buttons (to
navigate the DVD menus, etc). Are we missing something else?
Another thing to note is the difficulty to have media nodes to work
correctly over network without a min/max latency system (such as jack).
I thnk we support several different ways to handle the latency (the
default being to increase it whenever the node is late). If none of the
existing modes are sutable (which would be surprising), a new one can be
introduced.
8 - Further considerations:
It was also discussed if there is any need to have each node manage it's
own port. The design that I have proposed is to stop relying on ports, move
synchronization and buffer management server side. This may allow the
media_node to publish semaphores to the media_server and let it decide when
a buffer is received and processing will start. The idea is to have the
media_server run a graph behind and nodes to wait for them to be called to
process a buffer or handle an event.
To me, the decentralized approach with data flowing from ports to ports
looks quite good. I recall you already discussed this idea of a
centralized graph management in media_server, but I did not understand
what the problem is with the ports system and how the centralized
approach would be better.
Does the semaphore system require the media server to be scheduled and
run each time a nodes finishes processing its data, before the data can
reach the next node? That would be two context switches for the price of
one and I'm not sure I see what it helps with.
---
The real purpose of this topic is to make us to think which media_kit we
want.
We can just stay closer to the actual implementation, relying on ports,
fixing the fixable and waiting for a major API breakage to fix the
remaining things.
We can alternatively consider the current media_kit just outdated, take the
good, throw out the bad and try to get it into a modern media stack, i.e. a
media2_kit.
Each of the options have pros and cons, and each of the points have
different consequences in the ABI. For example 1, 2 and 7 could be fixed in
the current media_kit without any ABI breakage.
We won't drop the old ABI before R1 is released. But I think that
doesn't prevent starting to work on the new one if they can live in
parallel. I would prever people to focus on the R1 tasks, but I can't
decide for you, and you seem more motivated in exploring a new design
than improving the existing one.
--
Adrien.
Other related posts:
