GNOME Bugzilla – Bug 793681
splitmuxsink: add a property "location-format-type" to allow filenames with values other than fragment index
Last modified: 2018-11-03 15:26:27 UTC
At present, location property only accepts "%d" format specifier which represents fragment-index. In many cases, it would be helpful to allow specifying other values such as first buffer PTS in filenames. An additional property for splitmuxsink, called "location-format-type" can be added to specify value type represented by format specifier in location string pattern. For e.g. if user wants to have first buffer's time in filenames, he should be able to specify the same by following property values : e.g. max-size-time=120000000000 location=video_%Y-%m-%d_%H:%M:%S location-format-type=2 Where, location-format-type can specify different format types such as (1): fragment-index - Fragment Index(Default) (2): first-buffer-pts - First Buffer PTS .. and so on Note: In plugin version 1.12, a new signal location-format-full was added, which is flexible to support above mentioned requirement, but it requires users to do signal handling stuff. While "first buffer's time" as part of filenames, is a very common requirement, it should be possible to specify by simple configuration, than complex signal handling stuff. This should justify above enhancement proposal.
Created attachment 368686 [details] [review] Patch for adding new property "location-format-type" Attached is the patch that I created for said requirement.
Thanks for the patch. However, I think this can and should be done via the "format-location-full" property instead, which is more flexible.
Hi, I agree that plumbing should be done by format-location-full. But when we want to use the above functionality from gstreamer 1.12.4's gst-launch-1.0 (i.e. from a shell), is there any way to pass such file names in the pipeline string? IMHO, there is no way for now as format-location-full is a signal but not a property.
That's correct, you have to write code for this in any of the languages you'd like to use. gst-launch is only a debugging tool.
I think debate is property vs signal. IMHO, while flexibility is good to have even if it comes at some overhead (writing code again and again by each user), for uncommon scenarios. But for common scenarios like "first buffer timestamp" as part of filename, which is very likely case it should be more convenient to have a simple plugin property than asking each user to write code again. That was the motivation for creating this patch. I hope, Community agrees that asking users to write signal handling code for frequent requirements is not as convenient as specifying property.
-- 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/442.