From: Miguel F. <mfr...@gm...> - 2005-10-31 21:30:18
|
On 10/31/05, Darren Salt <li...@yo...> wrote: > As for vis plugins, we can't just wire one in straight away anyway: first= , we > need to know whether the stream is audio-only. isn't this what you get after xine_open()? > > i prefer having small functions that do simple things. open, play, stop= , > > close... all playlist handling, mediamarks, subtitles selection or per > > stream special attributes is ui's job. just my 2c ;-) > > The main reason for the queue is in case a stream is very short or is > inaccessible: in this case, it seems likely to me that another "stream > finished" will occur before playback of the previous stream is finished..= . if the stream is inaccessible xine_open should fail, and you can safely move to the next one... am i missing something? > Stream X finished > -> Stream Y requested by front end > Stream Y finished > -> Stream Z requested by front end > Playback of X finished > -> playback of Y is started (if possible) > -> front end updates display for Y > -- allows disposal of any temporary info associated with Y > Playback of Y finished > -> playback of Z is started (if possible) > -> front end updates display for Z you are assuming we have different events for decoder finished and playback finished. we do not (yet). i said i'm not against such event, it is just that it is not that easy to implement as it was making the gapless patch (were i just disabled the "wait for playback finished" code before firing an event). currently, the case above doesn't happen (because there is no such event). UI would update to display Y information as soon as X is nearly finished (like tenths of seconds from the end). Y information would blink (as the stream itself, since it is pretty short) and everything would go to Z. i don't know... people _might_ be nitpicking here imho. i agree there is probably space for improvement, but i'm not yet convinced we need a new api just for that. of course, i'm always open to review patches ;-) Miguel |