[gst-devel] Hi, question about seek on HTTP wav stream over either neonhttpsrc or gnomevfssrc.

Donny Viszneki donny.viszneki at gmail.com
Mon Feb 16 04:20:05 CET 2009


On Sun, Feb 15, 2009 at 8:29 PM, xiupeng xie <xiexiupeng at gmail.com> wrote:
> Hi Edward and All, Please give your kind help.
> last week, I raised the question about "question about seek on HTTP wav
> stream over either neonhttpsrc or gnomevfssrc."

I don't know enough about gstreamer to diagnose your problem, but as
you say that you want to stream WAV format media over HTTP with the
expectation of *seeking* in that media, I thought I should point out
that that sounds a little silly. What reason do you want to do this?
Is there a reason you cannot use another format (WAV is completely
uncompressed PCM audio sample data, it is enormous and not efficient
for most applications.)

>From what I know of HTTP, I can also say that an HTTP gst source that
supports seeking will need to do at least one of two things to
accomplish this:

1) Internally buffer all data in the stream
2) Use the Content-Range HTTP header to tell the server to "seek"
within the file

This situation is potentially very problematic for a variety of
reasons. First, if the HTTP gst source doesn't support option #2 from
above, then it seeking into "the future" of a file will cause a delay
until the data has arrived. Second, if the HTTP gst source doesn't
support option #1 from above, then it will cause a delay when you seek
*anywhere* outside of whatever small buffer it has.

Even if the HTTP gst source you use supports both of these techniques,
the server may not support the Content-Range header, or worse: the
stream itself may not be a file at all, but rather a formal media
stream which will likely not respect notions of seek position
(Content-Range) and will surely repeat data like media stream
formatting headers each time you open a new connection (seek.) (Is
that last part even doable with WAV? I'm not sure about that format;
I've never heard of anyone streaming WAV anyway.)

Is there a tee-like element that is intelligent about seeks and can
act as a cache/buffer for a streaming source to help mitigate some of
these issues?

-- 
http://codebad.com/




More information about the gstreamer-devel mailing list