Hello Stefan,

Friday, December 29, 2000, 7:52:36 AM, you wrote:


SW> Doing "streaming video" may mean different things. One would be that the
SW> input of an object which plays something is a stream (rather than a file).
SW> In fact, there have been some discussions on the list recently, and some
SW> ideas for interfaces for doing this have been floating around, but right
SW> now, nobody has really tried to implement the necessary bits of code. Martin
SW> Vogt - if I understood him correctly - wanted to give it a try, but not
SW> before KDE 2.1.

SW> Then, "streaming video" may mean that you have a stream of pictures rather
SW> than a stream of samples, managed my aRts, so that you can for instance
SW> apply effects to pictures in a streaming fashion. While I think something
SW> like this would be great, it's quite a bit of work, and it's work that
SW> goes deep into the framework. It would allow writing encoders and decoders
SW> accepting a stream of pictures, though, so that you can for instance convert
SW> a video into a different format, or grab something with your TV card.

SW> Finally, "streaming video" may mean something completely different.

SW> As for mpeglib <-> aRts, the relation is this: aRts standarizes how certain
SW> types of objects are to be implemented, and how they interact. On the other
SW> hand, mpeglib implements some objects for playing something. However, to
SW> implement an "Arts::PlayObject", you need not use mpeglib. So you can write
SW> your video objects independant from mpeglib.

I need to explain more properly what I meant... Right now I see that
arts is used only for management of sound and PlayObject interfaces.
Code that does all actual work on parsing, decoding and drawing anything
is safely hidden beyond undocumented and obscure interfaces of mpeglib.
What's worse, it is unusable for anybody who does not want to completely
integrate into it.

I recently studied how this is done in MS DirectShow. DirectShow MPEG
player might consist of File Reader object, MPEG Demultiplexer object,
two Decoder objects and Renderer object. All these small objects have
predefined DirectShow interfaces and are connected using simple rules.
Programmer can insert his own filter somewhere in the graph without need
to change much code. He can rearrange a few objects and receive a
 MPEG->AVI recompressor. You probably understand what's this, it is
close to what you describe in the second paragraph of your message.

I know that I don't need mpeglib to implement Arts::PlayObject (already
done it in my project), but I don't like the idea of having two
incompatible video & audio renderers, audio/video syncers, etc.
For sure this would require much work, you'll need to define all
necessary interfaces, apply heavy changes to mpeglib, but I think that
it's worth it.

-- 
Best regards,
 Eugene                            mailto:divx@euro.ru


_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia