GNOME Bugzilla – Bug 770461
flacenc: Implement flushing
Last modified: 2018-11-03 15:11:04 UTC
Created attachment 334249 [details] [review] flacenc: Implement flushing This allows flacenc to flush its internal state when requested to do so. This is useful when placed into a pipeline to transcode and a seek is performed on that pipeline. Currently, a seek would lead to an error (+ assertion) like this: WARN: gstaudioencoder.c:gst_audio_encoder_finish_frame:1028: error: received more encoded samples 4608 than provided 684 as inputs
Created attachment 335367 [details] [review] flacenc: Implement flushing Updated patch.
Comment on attachment 335367 [details] [review] flacenc: Implement flushing >+ case GST_EVENT_FLUSH_START: >+ flacenc->flushing = TRUE; >+ ... >+ break; >+ case GST_EVENT_FLUSH_STOP: >+ if (!flacenc->encoding) { >+ flacenc->flushing = FALSE; ... Since FLUSH_START will be called from a thread other than the streaming thread, this is not really thread-safe without locking (setting flacenc->flushing in FLUSH_START and reading it in the coder elsewhere). Ideally you'd do nothing in FLUSH_START and only flush/reset the encoder in FLUSH_STOP I think. Is that possible?
Thanks for the feedback. I'll update the patch with more locking. The issue I'm seeing is that it is sitting in gst_flac_enc_write_callback() trying to push the buffer, which is called by either FLAC__stream_encoder_process_interleaved() or FLAC__stream_encoder_finish(). However the FLUSH_START can come in when it is sitting there, so from that point on I need to somehow clear the encoder so that it doesn't keep pushing buffers into gst_audio_encoder_finish_frame(). Which is what triggers this warning. Also, since it is sitting in the FLAC__*() calls, if I didn't remember that a FLUSH_START happened then it could be possible to receive a FLUSH_STOP and not having actually flushed anything.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/293.