<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 31, 2014 at 11:44 AM, Tiago Katcipis <span dir="ltr"><<a href="mailto:katcipis@inf.ufsc.br" target="_blank">katcipis@inf.ufsc.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Sebastian,</div><div><br></div>I don't know why I did not receive your answer on my email, luckily I checked the mailing list archive and was able to see it there (it is not the first time this happens :-().<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">When ignore-length is used, wavparse should probably not keep track of<br>how much data is left itself but continue reading until upstream returns<br>EOS. That should solve your problem, right?</blockquote><div><br></div><div>It should, but it doesn't :-). My problem is the dataleft control. It actually checks how much data has already been streamed and if it comes to 0 it will send an EOS, even if the upstream still have more data.<br><br>This can be seen here:</div><div><br></div><div><a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/wavparse/gstwavparse.c#n1941" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/wavparse/gstwavparse.c#n1941</a></div><div><br></div><div>I thought the ignore-length would do the job too, I was surprised when I was still getting EOS.<br></div></div></blockquote><div><br></div><div>Since ignore-length is not effectively ignoring the length of the file isn't this a bug ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Apart from that, what you're describing here is never going to work reliable in the general situation. It can happen because of various reasons that wavparse reads faster than the writer writes, and the you will get an EOS too early. But you probably know that already :)</blockquote><div><br></div><div>Yeah I know, but the old solution using gstreamer 0.10 has been made this way and we did manage to make it reliable enough for usage :-) (it is alread deployed on several clients for some time).</div><div><br></div><div>I did some several tests this week and we keep a reading speed that does not exceed the writing (more than two hours for example, which is enough for a lot of skews).</div><div><br></div><div>It is not a very normal usage I know, but so far it has been quite useful for me at work.</div><div> </div></div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 25, 2014 at 9:45 PM, Tiago Katcipis <span dir="ltr"><<a href="mailto:katcipis@inf.ufsc.br" target="_blank">katcipis@inf.ufsc.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>First I will describe my problem:</div><div><br></div><div>I have an IMA ADPCM WAV file being recorded, as the file is recorded I need to:</div><div><br></div><div>1 - Open it, get the duration from the wav header and seek to near the end (the client wants to hear what is being said on the audio with the minimum latency possible).</div><div><br></div><div>2 - Start to stream the audio to a client while it is still being recorded (with care to not send it faster then it is being recorded).</div><div><br></div><div>3 - Just stop to send the audio when the file stops being recorded (basically I hit EOF).</div><div><br></div><div>I was able to use wavparse ignore-length property to bypass the duration found on the header file. But still I was getting EOS while the recording was still going on.</div><div><br></div><div>Checking out wavparse closer it uses a field dataleft to define when to EOS. Disabling EOS from dataleft I was able to do everything I wanted (seek, get duration and stream audio until the source indicates that there is no more data left).</div><div><br></div><div>It worked perfectly fine, but I did some nasty stuff on the wavparse and basically forked it as another plugin. I can think on a way to make this work using wavparse, through a property (like ignore-length), but I don't know if the use case is good enough to justify the addition of this feature.</div><div><br></div><div>Adding this kind of feature on wavparse makes sense ?</div><div><br></div><div>Best regards,</div><div>Tiago Katcipis</div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>