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 651443 - multifilesink: add next-file=max-size mode and max-file-size property
multifilesink: add next-file=max-size mode and max-file-size property
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-05-30 09:28 UTC by sreerenj
Modified: 2011-12-01 13:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adding a size-limit property to multifilesink (5.16 KB, patch)
2011-05-30 09:28 UTC, sreerenj
needs-work Details | Review

Description sreerenj 2011-05-30 09:28:22 UTC
Created attachment 188865 [details] [review]
Adding a size-limit property to multifilesink

Adding a size-limit property to multifilesink. When ever the size of current file exceeds the specified limit, mulitfilesink will start a new file.
Comment 1 sreerenj 2011-07-08 14:29:25 UTC
Any updates?
Comment 2 Vincent Penquerc'h 2011-10-28 12:13:37 UTC
Review of attachment 188865 [details] [review]:

::: gst/multifile/gstmultifilesink.c
@@ +546,3 @@
+        filename = g_strdup_printf (multifilesink->filename,
+            multifilesink->index);
+        multifilesink->file = g_fopen (filename, "wb");

This uses glib g_fopen, but the above uses libc close.
In any case, looking at the existing code, the open/close code was refactored so you can now make use of this new code instead.

@@ +554,3 @@
+
+      ret = fwrite (GST_BUFFER_DATA (buffer), GST_BUFFER_SIZE (buffer), 1,
+          multifilesink->file);

The blocks are written as one chunk, which means the size limit is only approximate. It'd be more intuitive to write buffers in more than one file if necessary.
Comment 3 Tim-Philipp Müller 2011-10-28 22:28:24 UTC
I've implemented pretty much the same thing locally, will have a look..
Comment 4 Tim-Philipp Müller 2011-12-01 13:16:59 UTC
Pushed this now:

 commit ab96fb7cdb9048d1b8205293f82ef17dad80e7f1
 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
 Date:   Sun Sep 25 14:57:56 2011 +0100

    multifilesink: add basic buffer list handling
    
    We assume for now that all buffers in a buffer list
    should end up in the same file (so we can group GOPs
    in buffer lists, for example). Could optimise this
    a bit to avoid the memcpy.

 commit 82ac47f33fbf9d4d3b79824f2d39dde810cb4cfc
 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
 Date:   Fri Sep 23 18:43:35 2011 +0100

    multifilesink: write stream-headers when switching to the next file in max-size mode

 commit bced3c218a795992dd8a9b60d5d38f35fa5c0b4b
 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
 Date:   Fri Sep 23 18:31:01 2011 +0100

    multifilesink: add new 'max-size' mode for switching to the next file

 commit 5ffee06f14e3b40208a3a127a0196dfa70d7a426
 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
 Date:   Fri Sep 23 17:49:05 2011 +0100

    multifilesink: add "max-file-size" property for new next-file mode


Your naming (with '-limit') might be nicer though, but the max-*size is more in line with what we use for e.g. queues. I don't really mind. If anyone has a strong opinion on this, we can still change it :)

I've pushed my patches now since I know they've been tested and because I'm not convinced yours is entirely right as is (e.g. if you call it a limit, it should be a hard limit IMHO, but the way I read your patch is that you only start a new file once you're over the limit).

Please test it and let us know if there are any problems.