Proposal of new feature to wavparse

Tiago Katcipis katcipis at inf.ufsc.br
Fri Oct 31 06:44:39 PDT 2014


Sebastian,

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 :-().

When ignore-length is used, wavparse should probably not keep track of
> how much data is left itself but continue reading until upstream returns
> EOS. That should solve your problem, right?


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.

This can be seen here:

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/wavparse/gstwavparse.c#n1941

I thought the ignore-length would do the job too, I was surprised when I
was still getting EOS.


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 :)


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).

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).

It is not a very normal usage I know, but so far it has been quite useful
for me at work.


On Sat, Oct 25, 2014 at 9:45 PM, Tiago Katcipis <katcipis at inf.ufsc.br>
wrote:

> Hi,
>
> First I will describe my problem:
>
> I have an IMA ADPCM WAV file being recorded, as the file is recorded I
> need to:
>
> 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).
>
> 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).
>
> 3 - Just stop to send the audio when the file stops being recorded
> (basically I hit EOF).
>
> 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.
>
> 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).
>
> 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.
>
> Adding this kind of feature on wavparse makes sense ?
>
> Best regards,
> Tiago Katcipis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141031/c5ec69d4/attachment.html>


More information about the gstreamer-devel mailing list