Proposal of new feature to wavparse

[Tiago Katcipis]

On Fri, Oct 31, 2014 at 11:44 AM, Tiago Katcipis <katcipis at inf.ufsc.br>
wrote:

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

Since ignore-length is not effectively ignoring the length of the file
isn't this a bug ?


>
> 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/20141111/7a60aac4/attachment-0001.html>