After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747435 - test: filesink: add test to verify append mode
test: filesink: add test to verify append mode
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-07 04:19 UTC by Prashant Gotarne
Modified: 2018-11-03 12:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test: filesink: added testcase to verify append property (3.34 KB, patch)
2015-04-07 04:20 UTC, Prashant Gotarne
reviewed Details | Review

Description Prashant Gotarne 2015-04-07 04:19:30 UTC
Add testcase to verify append mode property for filesink element
Comment 1 Prashant Gotarne 2015-04-07 04:20:21 UTC
Created attachment 301045 [details] [review]
test: filesink: added testcase to verify append property

Added testcase to verify append property for filesink element
Comment 2 Tim-Philipp Müller 2015-04-08 09:05:24 UTC
Comment on attachment 301045 [details] [review]
test: filesink: added testcase to verify append property

>+  gst_segment_init (&segment, GST_FORMAT_BYTES);
> ...
>+  PUSH_BYTES (100);
>+  CHECK_QUERY_POSITION (filesink, GST_FORMAT_BYTES, 100);
>+  CHECK_WRITTEN_BYTES (0, 100, 100);
> ...
>+  /* Re-opening temp file in append mode and write 100 bytes */
>+  /* This seek operation should be successful for seekable files as we have
>+   * opened file in append mode */
>+  segment.start = 100;
>+  if (gst_pad_push_event (mysrcpad, gst_event_new_segment (&segment))) {
>+    GST_LOG ("seek ok");
>+    /* Should be successful as we have opened file in append mode which
>+     * already has 100 bytes*/
>+    CHECK_QUERY_POSITION (filesink, GST_FORMAT_BYTES, 100);
>+    PUSH_BYTES (100);
>+    CHECK_QUERY_POSITION (filesink, GST_FORMAT_BYTES, 200);

I'm not so sure about this, if this should be the behaviour, i.e. if a seek to the end should be required. "append" to me sounds like it should just do that automatically and if needed rebase everything on top of the existing data.

What are the use cases for "append" I wonder?
Comment 3 Prashant Gotarne 2015-04-08 09:11:12 UTC
Filesink support the append property. when user set the property to append, it opens the file in append mode and set the current position 0.

In this test case it tries to seek to the end of file to ensure that the file is opened in append mode. If we do not seek before we push the data, it will override the existing data.
Comment 4 Tim-Philipp Müller 2015-04-08 09:14:24 UTC
Yes, I understand that.

What I'm saying is that I am not sure the current behaviour is correct or intended like that.
Comment 5 Prashant Gotarne 2015-04-08 09:46:33 UTC
Yes, even I think that the current behavior is not correct. Opening a file in append mode and setting the position to 0 is as good as opening file in write mode. But then I thought that developer intended this current behavior. 

As there is no unit test case to test append property, I wrote this one to match with the current behavior.

With this test case we can atleast make sure that by setting the append property, filesink element is opening a file in append mode.
Comment 6 Prashant Gotarne 2015-04-08 10:28:41 UTC
Check this https://bugzilla.gnome.org/show_bug.cgi?id=591441
Comment 7 Tim-Philipp Müller 2015-04-08 11:51:35 UTC
Right, so: the file will be opened with mode "ab" which will position the write cursor at the end of the file.

However, we then send a SEGMENT event to the sink.

If the SEGMENT event is in TIME format (as in the original feature request for which append mode was added), filesink will not do a seek and just continue to add data at the end of the file.

However, if we send a SEGMENT event in BYTE format, filesink will seek back to the beginning of the file.

I guess what we need to decide is if a BYTE seek to 0 should end up at the beginning of the file, or where the write cursor was when the file was opened in append mode (i.e. the end of the file before it was appended to). I can't really see a valid use case for the former.
Comment 8 Prashant Gotarne 2015-04-09 09:29:27 UTC
I think of following use case where above append property can be useful.

The current filesink element opens file in append mode and with seek operation we can set the write cursor position. Default initial cursor position is set to 0 i.e beginning of the file.

Consider the use case where user want to implement downloader using gstreamer.
In this case following simple pipeline can be useful where data is downloaded from the 'httpsrc' element and can be saved into a file using 'filesink' element.

httpsrc --> filesink

In application we can set the source URL for httpsrc element and destination file in filesink element. With the start of pipeline, file get downloaded to local disk.

If there is some network error occured because of broken connection, application can restart the pipeline to resume the download by setting the filesink in append mode and by performing seek operation on both elements with size equal to size of previously downloaded data.

With this downloader can resume the file download operation.

If we consider this usecase scenario the current behavior of the filesink for append mode is correct.
Comment 9 GStreamer system administrator 2018-11-03 12:26:38 UTC
-- 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/gstreamer/issues/104.