[gst-devel] Seek events: do_seek vs. newsegment

[Jay L. T. Cornwall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm currently tracing a problem in Rhythmbox where .m4a files are
seekable locally but not over DAAP. qtdemux/qtdemux.c incorrectly
assumes that only pull sources are seekable (push sources are now
seekable too, given some constraints). Fixing this enables seeking but
leads to a crash.

- From what I can see, Rhythmbox's GStreamer source element never receives
a do_seek notification. Seeking a .mp3 file generates this event, but
.m4a does not. This seems to stem from the events that each demuxer
chooses to issue during a seek:

  gstmad.c:
    seek_event = gst_event_new_seek (rate, GST_FORMAT_BYTES, flags,
      cur_type, bytes_cur, stop_type, bytes_stop);

  qtdemux.c:
    gst_qtdemux_push_event (qtdemux, gst_event_new_new_segment (TRUE,
      qtdemux->segment.rate, qtdemux->segment.format,
      qtdemux->segment.start, qtdemux->segment.last_stop,
      qtdemux->segment.time));

GStreamer's "playbin" element seeks fine with both demuxers, so I
thought by adding a check for "newsegment" I could cover both bases
(although it's an untidy feature of GStreamer). However, I notice this
in base/gstbasesrc.h:

  /* generate and send a newsegment (UNUSED) */
  gboolean      (*newsegment)   (GstBaseSrc *src);

And, sure enough, this is not called in base/gstbasesrc.c. So what's the
deal here, should qtdemux.c be generating do_seek events? Should
Rhythmbox be catching something else to handle seeks from the .m4a demuxer?

For extra fun, I now also see a prepare_seek_segment vfunc in CVS HEAD
base/gstbasesrc.h. Gah!

- --
Jay L. T. Cornwall
http://www.jcornwall.me.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG4yVYdQczt3VeX8URAhhsAJ9lRRNCDtgWixZ3kuJBPP3X038JMwCfeIbI
tNRdFxU7sWnlkCa9iLdpj5s=
=DNSg
-----END PGP SIGNATURE-----