[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Arts::Video
From:       Ewald Snel <ewald () rambo ! its ! tudelft ! nl>
Date:       2002-04-11 13:01:24
[Download RAW message or body]

Hi Martin,

[...]

> Back to the whitepaper.
> The videodecoder pushes the images to the syncer in the
> graphic. bad from my experience. mpeglib does it this way
> and xine as well.(mpeg2dec pushes the images to the image api)
> The reason is, that this needs callbacks to the syncer.
> A better solution is a push/pull approach.
>
> while(1) {
>   state=decoder->getstate()){
>   switch(state) {
>   case WANT: decoder->push data
>   case HAVE: decoder->pull image, forward to syncer
>   }
> }
>
> callbacks to api in decoders are bad, don't do it.
> (deadlock problems, callstack through decoder (bad,bad,bad))

I don't think there's that much difference between xine and your solution, 
unless I have misinterpreted your example.

The "WANT" state is implemented in xine (video_decoder.c) like this.

"	  decoder->decode_data (this->cur_video_decoder_plugin, buf);  "

The decoder will decode the image and, if there is enough data to complete it, 
place it on the frame queue. You'll probably need a similar queue for your 
suggestion, or you would have to buffer data (inefficient extra copy) if 
there's more than one frame in it. This is not unlikely for MPEG B-frames.

The "HAVE" state is implemented in xine (video_out.c) like this.

"    img = get_next_frame (this, vpts);"

The "get_next_frame" will retrieve the frame from the same queue as the 
decoder uses. I think this is very similar to the "pull" in your push/pull 
design suggestion: the decoder pushes frames onto this queue on request and 
the video output pulls these frames from the queue for display.

You are right that there is some communication between the decoder and other 
parts of the video API (the frame queue). However, this allows you to render 
directly into allocated frames without the need to copy data. The "frames" 
could even be located in video RAM, although this is currently not the case 
for xine (AFAIK).

> regards,
>
> Martin

Too bad that xine has such a bad reputation among (most) KDE multimedia 
developers. I think the design is pretty good, but that's just an opinion. :)

bye,

ewald

_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]