Commit graph

7 commits

Author SHA1 Message Date
Sebastian Dröge
93ffec7b2e filesink/fdsink: Write 1 iovec directly without copying if there's no writev() support 2020-03-26 11:31:03 +00:00
Sebastian Dröge
c15f1b2bec fdsink/filesink: Refactor writev() code to prevent stack overflows
If buffer lists with too many buffers would be written before, a stack
overflow would happen because of memory linear with the number of
GstMemory would be allocated on the stack. This could happen for example
when filesink is configured with a very big buffer size.

Instead now move the buffer and buffer list writing into the helper
functions and at most write IOV_MAX memories at once. Anything bigger
than that wouldn't be passed to writev() anyway and written differently
in the previous code, so this also potentially speeds up writing for
these cases.

For example the following pipeline would crash with a stackoverflow:
gst-launch-1.0 audiotestsrc ! filesink buffer-size=1073741824 location=/dev/null
2020-03-26 11:31:03 +00:00
Sebastian Dröge
eec9bd8db3 filesink: Implement workaround for some (network) filesystems that spuriously return EACCES on write
This seems to happen when another client is accessing the file at the
same time, and retrying after a short amount of time solves it.

Sometimes partial data is written at that point already but we have no
idea how much it is, or if what was written is correct (it sometimes
isn't) so we always first seek back to the current position and repeat
the whole failed write.

It happens at least on Linux and macOS on SMB/CIFS and NFS file systems.

Between write attempts that failed with EACCES we wait 10ms, and after
enough consecutive tries that failed with EACCES we simply time out.

In theory a valid EACCES for files to which we simply have no access
should've happened already during the call to open(), except for NFS
(see open(2)).

This can be enabled with the new max-transient-error-timeout property, and
a new o-sync boolean property was added to open the file in O_SYNC mode
as without that it's not guaranteed that we get EACCES for the actual
writev() call that failed but might only get it at a later time.

Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/305
2019-05-16 14:15:02 +03:00
Tim-Philipp Müller
cf7cfb0a0e fakesink, identity: print metas attached to buffer in silent=false mode 2016-12-05 20:29:25 +00:00
Olivier Crête
5216322d39 fdsink: Block in preroll_wait on unlock
The correct behaviour of anything stuck in the ->render() function
between ->unlock() and ->unlock_stop() is to call
gst_base_sink_wait_preroll() and only return an error if this returns an
error, otherwise, it must continue where it left off!

https://bugzilla.gnome.org/show_bug.cgi?id=773912
2016-11-23 11:58:43 -05:00
Tim-Philipp Müller
66bdae5f33 plugins: add helper function for writing buffers out with writev() 2014-11-30 14:40:46 +00:00
Vincent Penquerc'h
a8ca56b42d gstbuffer: factor three flags-to-string loops 2014-06-04 12:30:36 +01:00