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

List:       kde-multimedia
Subject:    Re: Arts::Video
From:       Martin Vogt <mvogt () rhrk ! uni-kl ! de>
Date:       2002-04-11 4:06:48
[Download RAW message or body]

On Wed, Apr 10, 2002 at 06:10:52PM +0200, Nikolas Zimmermann wrote:
> Hi there,
> 
> Please look into kdenonbeta/arts-video and it's docs.
> Whitepaper can be found there.
>
Ok, I read it.
As already said, I like to contribute the image support.
The image structure is the most important one for the
framework. (From my experience with mpeglib I already
know the problems which can occur)

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))

The "idea ot the sync system", needs more.
mpeg system streams carry DTS,PTS information and
they have a timeshift between audio/video. Synchronistion
works here against a reference clock, feed with timestamps
from the mpeg stream.
(its a bit complex.) 
"calculate audio time and render some frames" wont work.
Usually you carry a "byte postion/pts token" for every
frame from the demux to the syncer.

regards,

Martin

_______________________________________________
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]