Hi,
I wanted to start this topic since some months but it somewhat delayed to
now. I would like this post to be a resume of media_kit limits that have
been shown in the past and some other that i found myself.
1 - The latency is calculated on a per node basis. The entire concept of
having a global latency in the node can't work. It should be configured per
every input/output pair.
2 - Structs are hard to manage. This is a direct consequence of the above,
without classes such as BMediaInput and BMediaOutput it's hard to add a
better latency mechanism without generating a lot of complexity.
Looking at Be sample code comments it looks like Be planned this but for
some reason this work hasn't get out into the R5 updates.
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.
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.
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.
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).
7 - Code duplication and objective difficulty to handle all use cases. It's
enough to compare the various nodes implementations we have in tree to see
that we don't have any consistency to make all nodes behave correctly. I've
begun to work on a BMediaFilter class with the aim to allow easy creation
of media nodes. What happened is that bit after bit i realized that my
implementation will not work as i wanted just because the media_kit doesn't
provide enough support of a generic N:N client.
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.
---
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.
Considering the whole amount of work and how much time it will take to fix
all those things in the media_kit and mantaining compatibility at the same
time, in the end my conclusion is that we should seriously consider a
media2_kit. I've already had the invite to start a new media_kit from
various persons but it doesn't waste to listen if someone has something to
add on the topic :-)
--
Best Regards,
Dario
