What would be a use case for this?

Some comments:
 
 - Make the message name something more unique like "GstMultiFilesink" instead
   of "Info".
 - The message fields should be lowercase.
 - The timestamp of the buffer does not mean much without the preceeding
   newsegment. Better add  stream-time, running-time, duration (see also
   -good/gst/spectrum/gstspectrum.c)
 - use GST_TYPE_CLOCK_TIME for the timestamp values (not string)
 - You probably also want the buffer offsets because most file data is byte
   based.

I needed to keep timestamp information for saving jpeg files, to pass it to another software module in real time.

Ok, update the patch to what Wim said and it can be included I guess :)

I don't understand what is the buffer offsets can i have more explanation?

it's GST_BUFFER_OFFSET().

Also passing around jpeg files using multifdsink and posting the metadata as messages and all this in real-time sounds like a crack idea.

Created attachment 142910 [details] [review]
New patch multifilesink

This is the new patch for multifilesink to show message for each saving file and the comment of Wim Taymans that are respected normally. :)

Any reason you are not using appsink or fakesink and doing the file writing yourself?

yes i have reason because i think that multifilesink is more high-performance than saving file myself (and threading using queues is so easy).

Moreover, the application is in python, which has terrible performance with fakesink and appsink cannot be used (AFAIK).

I don't know if your performance worries are warranted or not, but it doesn't sound like you've even tried. Appsink works fine with python as far as I know, it's just that the convenience library isn't wrapped (or is it now?), but you should still be able to use the methods via emitting GObject signals.

IMHO this looks all highly cracktastic/WONTFIXy to me and should be achieved differently, for example by writing a minimal passthrough element that goes before the sink and posts those messages (or by using identity+handoff or pad probes or whatever).

Casting GstMultiFileSink to GstBaseTransform also doesn't look entirely right btw, so I find it hard to believe that the patch even works right.

Ok for the casting GstMultiFileSink to GstBaseTransform is not good, i will find a solution to get stream-time and running-time.
However i need multifilesink with the message to get path and name of file is saving.

I agree with Tim, this is not the solution for your problem. The solutions that Tim mentioned in comment #10 are better and will actually work reliable.

Also note that messages are asynchronous (usually).

I'm closing this as WONTFIX now.

The goal here is to keep some list of jpeg files with an associated timestamp. jpegenc provides a "frame-encoded" signal, but again, no way to get the final location on the local disk.

Problem with a passtrough element is that how is it supposed to "know" the path that the following multifilesink will use for storing the data ? It would need to mimic multifilesink's path incrementation and assume that all parameters will be default.

Other options could be:
* to embed the timestamping using EXIF, e.g. using metadatamux
* to use the file creation time (but it might be linked to disk flushing times, ...)

Do you see other alternatives ?

Regardless of this particular use case, I think it makes sense to emit a message when multifilesink has written a file.

I'll commit a patch.

> Do you see other alternatives ?

You could implement GST_QUERY_URI for multifilesink.

Thanks wim.

@Tim: just to understand, the software would then need to poll multifilesink for it's current URI every 500ms or so, and the moment the URI query result has changed could be used as timestamping reference ?

It (an element before the sink) could do the query whenever a buffer comes through just before or after it would be pushed to the sink.

However, if Wim is going to make multifilesink post a message, it will probably have the name anyway, and any info it doesn't have you could add in a sync message handler if needed, so better wait for Wim's fix.

commit f68cd7e7080a9221cae97d29289e6b8bb12f5fbc
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Fri Sep 11 12:16:18 2009 +0200

    multifilesink: post messages for each buffer
    
    Add a silent property that can be set to FALSE to post messages on the bus for
    each written file.
    Do some more cleanups.
    Add some docs.
    
    Fixes #594663

On a related note, I just added a property new-file for when a new file should be created.  This makes the posted message more ambiguous -- should it still be for every buffer, or for each file?  Should it be sent when the file is opened, or closed?  I assume that "each file" and "closed" is the behavior that makes the most sense.