GNOME Bugzilla – Bug 615166
multifile: add support for reading filenames from a list file
Last modified: 2018-11-03 14:41:16 UTC
Created attachment 158188 [details] listfilesrc element After watching someone on IRC struggling with multifilesrc for the nth time, I figured it'd be easier to use in some cases if you could give it a file containing a list of source files, rather than having to number the files sequentially. What I'm attaching is a quick hack based on multifilesrc. It might be worth considering adding the functionality to multifilesrc rather than creating a new element, or sharing the common code (which is most of it) some other way.
Created attachment 158189 [details] listfilesrc header
I was sugesting on irc to add a "method" enum with the default="template". Jonathans case could be integrated as method="file-list" and using location for the file. Other options might me callback (it would ask the application to update the filename via callback). It seems to be a common case to have filenames with some sort of datestamp. That could be covered by adding a "files-by-name" method. It would require the element to scan the dir given in location and sort the names. I am just a bit afraid that then people want different sort orders and so on (just check the options from sort command).
I think building directory scanning and sorting into the element is probably excessive. It's not really GStreamer's job, and I don't think you want it in your API if you can avoid it. If you're running a pipeline with gst-launch, you can use shell commands to construct the list. If you're writing an application, maybe appsrc would be a better option. The 'read file into buffer' part of the element is not very complicated, so I'm not sure it makes sense to build too much other stuff into the element to provide access to it.
Anyway the file that contains filesname sounds good and if this would support reading from stdin if the filename is '-' or empty, then one can use it nicely with the shell (a pipe).
Ok is there still interest in this? If so, is someone going to write a patch for multifilesrc?
I have no less interest in this than I originally did.. I'll see if I can work on it some time soon.
Created attachment 303360 [details] [review] multifilesrc: added support to read filenames from list Added support to read filenames from list stored in file, by setting attribute "method=file-list". Default value for the "method" attribute will be "pattern" where it will create filenames using pattern provided in location property.
I don't know how much of an actual use case for this there actually this. Certainly not something I see come up much on IRC or the mailing list (and this bug is five years old now). Main problem I see is those who want to create a stream from multiple image files, which the imagesequencesrc in another bug will solve. I'm leaning towards just WONTFIXing this instead of just adding more properties because we can. Moving the list to a file is awkward too, then next thing someone will want a property. Next it needs to be dynamic. Might just as well add signals to get the next filename instead ;)
Created attachment 307527 [details] [review] multifilesrc: added signal to get dynamic filenames Added signals to get dynamic filenames from user. This gives user more flexibility to provide filenames for multifilesrc. If the location property set to NULL, this signal can be used to get the filename to create next buffer. If return filename is NULL then multifilesrc return EOS.
ping
Hi, Please review the patch.
After 1.6 is out.
-- 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/gst-plugins-good/issues/24.