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 490283 - [multifilsrc] move to -good
[multifilsrc] move to -good
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal blocker
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-10-25 20:54 UTC by David Schleef
Modified: 2008-02-08 04:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Schleef 2007-10-25 20:54:21 UTC
After some prodding, it's time to move multifilesrc/sink to -good.
Comment 1 David Schleef 2007-10-26 01:44:39 UTC
Recently updated in CVS.
Comment 2 Jan Schmidt 2008-02-07 02:05:36 UTC
I'm a bit dubious about the test that does a g_mkdir in the current dir - perhaps it should use g_get_tmp_dir and mkdtemp() ?

The docs for multifilesink should have an example launch line, and a better explanation of the 'location' property format.

The element details string for both elements could be a little more descriptive, like "Read a sequentially named set of files into buffers" perhaps.

Otherwise looks good for move.
Comment 3 Tim-Philipp Müller 2008-02-07 10:06:06 UTC
Random comments:

 - I wonder if it would make sense to use g_file_get_contents() for
   multifilesrc, it's likely to provide better error checking (this
   should be decided before the move, since it determines the filename
   encoding on win32).

 - same for multifilesink: use g_file_set_contents()?

 - would be nice if it was possible (in code, at least), to make
   multifilesrc read in a bunch of files that doesn't follow the rigid
   filename + index pattern. This could be done either by setting a
   fixed G_TYPE_STRV-type property which takes a list in advance, or
   by emitting some kind of "next" signal from the create function
   (I guess notify::index would do too, but it's not really particularly
   discoverable or intuitive), which the app could then hook up to and
   set a new filename. This stuff can always be added later of course.

 - same for multifilesink

 - multifilesink should probably error out, or at least send a warning
   message, if it receives more than one new-segment event.

 - seems to have some copy'n'paste leftovers (the lseek defines etc.)

Otherwise +1 for move.
Comment 4 David Schleef 2008-02-08 03:54:29 UTC
- Changed test to create a real tempdir.

- Fixed element detail string.

- Changed to use g_file_[gs]et_contents().

- Removed lseek defines.

Not yet done:

- Better docs for location property and example line for multifilesink.

Won't fix:

- filename lists.  I haven't seen a real need for this.  I initially wanted to do this, but the use cases that I came up with would be better handled by the application feeding data using appsrc.  multifilesrc/sink is mostly meant to be a gst-launch element.
Comment 5 Jan Schmidt 2008-02-08 04:25:13 UTC
Plugin moved in CVS: 

2008-02-08  Jan Schmidt  <jan.schmidt@sun.com>

        * configure.ac:
        * docs/plugins/Makefile.am:
        * docs/plugins/gst-plugins-good-plugins-docs.sgml:
        * docs/plugins/gst-plugins-good-plugins-sections.txt:
        * docs/plugins/gst-plugins-good-plugins.args:
        * docs/plugins/gst-plugins-good-plugins.hierarchy:
        * docs/plugins/inspect/plugin-multifile.xml:
        * tests/check/Makefile.am:
        * tests/check/elements/.cvsignore:

        Move multifile plugin from -bad.
        Fixes: #490283