[gstreamer-bugs] [Bug 338827] [patch] gnomevfssrc should use async api to not block on network problems

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=338827

  GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Comment #13 from Wim Taymans  2006-10-22 11:31 UTC -------
returning ASYNC from a source plugin should theoretically work. The idea would
indeed be to start the open() in a different thread (which must also be
cancelable or you might end up with a dozen threads hanging around). 

The thing is that basesrc has no idea that starting the task to perform the
read() should be delayed until the state change completes. An alternative way
would something like this:

start { 
  /* check URI, do all the stuff that does not block. BaseSrc will start a */
  /* task. */
  ...
  /* assume all this to be TRUE or based on the uri protocol. */
  if (file://,...) {
    seekable = TRUE;
    random_access = TRUE;
  }
  else {
    seekable = FALSE;
    random_access = FALSE;
  }
  return TRUE;
}

stop {
   /* try to cancel all actions that can block the streaming thread */
   cancel_open();
   cancel_read();
   return TRUE;
}

change_state {
   ..

   res = parent_change_state()   /* (de)activates the pad and starts the task
*/

   READY_TO_PAUSED:
     res = ASYNC;                /* overwrite result to be ASYNC */
     break;
   PAUSED_TO_READY:
     opened = FALSE;
     break;

   return res;
}

create {
  if (!opened) {
     open();         /* blocks but is cancelable */
     opened = true;
     commit_state()  /* commit state from READY to PAUSED */
  }
  read();
}

In fact, you might just want to skip the ASYNC stuff entirely, as long as you
don't produce data, the sinks will return ASYNC anyway.

It's still awkward because after opening the device, basesrc will need some
info (seekable, random access, ...) which you don't know yet. Assuming values
based on the uri protocol might work just fine.

Also, when operating in random access mode, the sequence is a little different
because the start/stop methods will be called when downstream activates itself
(so before the change_state). Above code will handle that.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email