Hi, question about seek on HTTP wav stream over either neonhttpsrc or gnomevfssrc.
Locked
Hi, question about seek on HTTP wav stream over either neonhttpsrc or gnomevfssrc.
 
|
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."
thanks Edward respond with below advices, i tried these steps, but seems there are problem too.
Just make sure i understand this advice well, i attached my codes and logs at the end of mail:
the steps from Edward:
This is not specific to http, but common to any non-live pipeline. The
problem is that the state change to PAUSED/PLAYING happens asynchronously. What you want to do is the following: * set state to PAUSED
* WAIT (in the mainloop or polling) for the confirmation that the pipeline has changed state to PAUSED. This means that all sinks are prerolled (one buffer is waiting in each sink) and the pipeline is fully responsive to seeks/playback/... * Do your seek. * You don't need to wait for the pipeline to be pre-rolled (PAUSED) again to set it to PLAYING, you can straight away set it to PLAYING. You might also want to listen for ERROR/EOS messages on the pipeline
bus, because although the remote http uri accepts seeks according to its headers (which is why the seek would return True), many things could go wrong in between also. - Edward
This question cause me several days without final idea. My purpose is to seek on HTTP wav stream over either neonhttpsrc or <neonhttpsrc> pausing after gst_pad_push() = wrong-state
memset(&(renderer->audioDecoder), 0, sizeof(renderer->audioDecoder));
//3. open audioconvert g_signal_connect(pHttpDecoder->decoder, "pad-added", gst_element_link_many(pHttpDecoder->convert, pHttpDecoder->aresample, gst_element_set_state(hRenderer->audioDecoder.pipeline,
------------------------------------------------------------------------------------------- 0:00:26.600566000 32405 0xb9dc3e0 DEBUG basesink ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Hi, question about seek on HTTP wav stream over either neonhttpsrc or gnomevfssrc.
|
|
On Sun, Feb 15, 2009 at 8:29 PM, xiupeng xie <[hidden email]> 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/ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Hi, question about seek on HTTP wav stream over either neonhttpsrc or gnomevfssrc.
|
|
In [hidden email], Donny Viszneki <[hidden email]> wrote:
> 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.) Not all HTTP servers are on the other side of the internet. More and more of them will be inside your house in the future. Not all HTTP servers are apache. More and more they will be embedded in your cell phone and your CD player and your DVD jukebox and your car stereo and your NAS appliance under the table in the spare bedroom. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Hi, question about seek on HTTP wav stream over either neonhttpsrc or gnomevfssrc.
|
|
On Wed, Feb 18, 2009 at 1:44 PM, Bob Forsman <[hidden email]> wrote:
> In [hidden email], Donny Viszneki <[hidden email]> wrote: >> 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.) > > Not all HTTP servers are on the other side of the internet. More and > more of them will be inside your house in the future. > > Not all HTTP servers are apache. More and more they will be embedded > in your cell phone and your CD player and your DVD jukebox and your car > stereo and your NAS appliance under the table in the spare bedroom. Not untrue Bob! I guess it was my reaction to think this was ridiculous not because of a bandwidth bottleneck, but because I've often had to deal with excessively long WAV audio files in the past (which ran several gigabytes) and at some point you do run out of virtual memory ;) -- http://codebad.com/ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |