Created attachment 301045 [details] [review]
test: filesink: added testcase to verify append property

Added testcase to verify append property for filesink element

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?

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.

Yes, I understand that.

What I'm saying is that I am not sure the current behaviour is correct or intended like that.

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.

Check this https://bugzilla.gnome.org/show_bug.cgi?id=591441

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.

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.

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