[gstreamer-bugs] [Bug 469930] [mmssrc] seeking support PATCH

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=469930

  GStreamer | gst-plugins-bad | Ver: 0.10.5




------- Comment #15 from Hans de Goede  2008-02-25 15:20 UTC -------
(In reply to comment #14)
> Yes, I'd prefer to not change from pushsrc to basesrc and keep pushsrc.
> 
> And for seeking you have to implement a do_seek() function, yes. You then can
> either seek directly in there or update the offset in your instance struct and
> do the seeking in create() if last_offset!=new_offset.
> 
> The first one would be preffered if the libmms seeking happens instantly and
> without blocking, the second would be preffered otherwise (as it will block the
> UI when seeking if your seek blocks, for example)
> 

Ok,

Quite some time passed since I've done these patches, so I've been busy
re-familiarizing myself with the asfdemux code. The reason why I did things the
way I did them, is because keeping mmssrc as a push src and using do_seek, will
only work if the asfdemux code starts passing seek query's to its src when
operating in push mode, the current seek code in asfdemux only works in pull
mode and I'm not sure how easy it is to fix this as asfdemux is somewhat
convoluted IMHO:

There seem to be 2 almost completely different implementations for push and for
pull mode, which seems totally unnecessary, since when in push mode one can
just buffer data until a complete packet has been received and then dive into
the same code path used to process a packet when operating in pull mode.

The only reason I can see for having seperate push mode code, is because a
packet can contain multiple video frames and audio fragments, and you want to
push them as soon as you've received enough of a packet to push a frame / audio
fragment. But that is _only_ usefull when streaming over plain http, as mms and
mssh work packed based and libmms if it doesn't have all the requested data
buffered will always read a whole packet into its internal buffer before
returning from a read call, even if you've asked for less.

When I started working at the mms seeking I've seriously considered completely
ripping out the seperate push based asf demux code, but in the end I didn't get
around to that, after a full week of working on this I was happy to have things
working as well as I have them now.
Notice that currently mmssrc with my patches offers random access for non live
streams, so asfdemux will operate in pull mode for non live streams. And this
seems to work fine for all the Fedora users using livna, so thats upto about 1
million people, which IMHO is proof that there really is no reason to have
fully seperate code-paths in asfdemux for pull / push based mode.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=469930.