Appsink vs Filesink Processing Speed.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Appsink vs Filesink Processing Speed.

Steve Chapman
I want to process audio data from an input set of buffers and make the processed audio data ready in an output set of buffers as soon as possible. I am using appsrc to get the data from the input buffers and appsink to put the data in the output buffers. My problem is this mechanism seems to introduce a delay that is comparable to the duration of the media being processed.

If I run a command line pipeline  (with gst-launch) from filesrc to filesink it completes in approx 50millisecs, e.g. 

gst-launch-1.0 filesrc location=input.wav ! wavparse ! audioconvert ! "audio/x-raw,format=S16LE,rate=8000" ! filesink location=output.wav

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.005366272
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

If I implement the same pipeline programatically and run it, the behaviour is the same and the processing is complete in approx 50millisecs, 
i.e. filesrc location=input.wav ! wavparse ! audioconvert ! "audio/x-raw,format=S16LE,rate=8000" ! filesink location=output.wav

Now if I substitute the filesrc for appsrc in my program and read data from the media file and push it into the pipeline using "push-buffer" once again the behaviour is the same and the processing is complete in approx 50millisecs, 
i.e. appsrc ! wavparse ! audioconvert ! "audio/x-raw,format=S16LE,rate=8000" ! filesink location=output.wav

Finally if I substitute the filesink element with appsink and write samples received into the output media file the behaviour changes and the processing time seems to take as long as the expected duration of the media. In the example this means the processing is complete in approx 10seconds?
i.e. appsrc ! wavparse ! audioconvert ! "audio/x-raw,format=S16LE,rate=8000" ! appsink

How can I get appsink (or the pipeline) to not delay the samples delivered? 

I have tried changing the appsink approach from signal based with a callback for "new-sample" to simply having a thread that loops calling gst_sample_get_buffer() as fast as possible. No change in behaviour.

I have also tried fiddling with the config of appsrc (latency, size, blocksize, block, is-live, stream-type). No change in behaviour.

I have also tried changing the audioconvert element config (dithering, noise-shaping). No change in behaviour.

I have also tried changing the appsink element config (blocksize, max-buffers, emit-signals). No change in behaviour.

Any advice appreciated.

Thanks
Steve

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Appsink vs Filesink Processing Speed.

Arjen Veenhuizen
By default, appsink's sync property is set to true. This means that it will process the media at its native playout speed (scheduling each buffer for playout when it is supposed to be played). If you set this property to false, it will no longer pay attention at sync and will process the buffers as fast as possible. That should bring your processing time down to roughly 50 milliseconds.

Note that in contrast, filesink's sync property is set to false by default.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Appsink vs Filesink Processing Speed.

Steve Chapman
In reply to this post by Steve Chapman
Thanks Arjen. 

I've set the sync property to false and now it runs sweetly.

Regards
Steve

On 7 July 2017 at 17:39, Arjen Veenhuizen <[hidden email]> wrote:
By default, appsink's sync property is set to true. This means that it will
process the media at its native playout speed (scheduling each buffer for
playout when it is supposed to be played). If you set this property to
false, it will no longer pay attention at sync and will process the buffers
as fast as possible. That should bring your processing time down to roughly
50 milliseconds.

Note that in contrast, filesink's sync property is set to false by default.



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Appsink-vs-Filesink-Processing-Speed-tp4683722p4683723.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Loading...