[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