[haiku-development] Re: MediaPlayer and the Media Kit
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 30 Nov 2012 11:55:51 +0100
Hi,
Am 27.11.2012 um 12:38 schrieb Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>:
> Stephan Aßmus <superstippi@xxxxxx> schrieb:
>> I don't know if it's still used in some fall back case, but if not,
>> the
>> code could perhaps even be removed. I would just keep it, though, its
>> design isn't bad. Maybe even better than what's used in the system
>> mixer
>> and it could be exchanged.
>
> Exchanged as in: the system mixer would use the code from MediaPlayer?
Yes. I don't really remember which one was more beautiful. Or if one was
significantly faster in converting. When in doubt, the last item should
probably matter most for a system mixer...
>
>> I am wondering about the performance hit that this would mean. In
>> particular, I remember having optimized this heavily, so slower
>> computers still manage to render subtitles even in full-screen.
>> Compositing the entire bitmap one more time, transfering it to another
>> node, would probably make the process too slow, certainly at least
>> introducing more latency.
>
> I see. IIRC DirectShow on uses such a node framework for everything,
> but then again, they can use all the hardware acceleration in the world
> to make things fast.
>
> Maybe it's just me and my love for APIs that allow me to connect objects
> into a data-flow graph... but I'd just love to be able to do things
> like this:
> (warning my attempt ASCII-drawing follows :) I hope the mailing list
> leaves it intact...)
>
> +----------------------------------------------------------+
> | |
> | MKV parser and demuxer node |
I would make that a generic FileReader node, using the low-level "reader"
plugins.
> | |
> | Implements BFileInterface, |
> | BBufferProducer (for reading files), |
> | BBufferConsumer (for writing files) |
> | |
> | Is set to the file using BMediaRoster::SetRefFor() |
> | |
> +--o-------------------------o-------------------------o---+
> | | |
> | B_MEDIA_ENCODED_AUDIO | B_MEDIA_ENCODED_VIDEO | B_MEDIA_TEXT
> | | |
> V V |
> +--o--------------+ +--o--------------+ |
> | MP3 codec node | | xvid codec node | |
> +--o--------------+ +--o--------------+ |
> | | |
> | B_MEDIA_RAW_AUDIO | B_MEDIA_RAW_VIDEO |
> | | |
> V | .--------'
> +--o-----------+ V V
> | System mixer | +--o----------------o--+
> +--------------+ | Subtitle render node |
> +--o-------------------+
> |
> | B_MEDIA_RAW_VIDEO
> |
> V
> +--o-------------------+
> | VideoConsumer window |
> +----------------------+
>
> With only one type of node-addons things become beautifully simple.
It doesn't need to be one type of add-ons behind the scenes to be neat. I would
keep that as it is.
> Adding streaming support would be straightforwad, too, just exchange
> the source node with e.g. a "HTTP stream receiver and demuxer"-node,
> all the rest can stay the same.
>
> It's weird that BeOS also had the separation already, because when you
> read the BeBook's MediaKit introduction, it builds a graph similar to
> the one above (although without subtitles and raw audio), using nodes
> only, without BMediaFile...
>
> Maybe I should go ahead and try out what Stephan suggested: implement
> two "wrapper" nodes around the plugins, one that acts as a universal
> codec node, another that acts as a universal parser/(de)muxer node. The
> two would simple report all capabilities of the available plug-ins as
> their own capabilities. Then I'll see what performance overhead this
> brings, and if it's big, forget about it again... ;-)
Well to be feature-complete and compatible with BeOS, we need to those nodes in
any case. BeOS had them. And there are situations where they are simply needed.
For example eXposer used the dormant DecoderNode. When it connected to the
system default video input, and when it happened to be the Firewire DV input,
that producer only gave encoded video. So it plugged the decoder node in
between its input and the system video output. eXposer is incomplete on Haiku,
since it cannot find this node. If someone completed the work on the UVC
driver, and some webcams happen to give encoded video only, and if we had the
universal decoder node, then eXposer would already work as is.
So regardless of what this may mean for MediaPlayer, your work would be greatly
appreciated. You could also have a look at the BEncoder and BDecoder classes,
both of which are currently stubbed out, if memory serves. There is an open
ticket, with a patch even, but for some reason I didn't apply it at the time.
So it probably needs some more work.
Best regards,
-Stephan
Other related posts:
