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 336839 - [patch] seek option for gstfakesink
[patch] seek option for gstfakesink
Status: RESOLVED DUPLICATE of bug 337100
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-01 14:13 UTC by Vincent Torri
Modified: 2006-06-15 09:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for gstfakesink.c (7.21 KB, patch)
2006-04-01 14:14 UTC, Vincent Torri
rejected Details | Review
patch for gstfakesink.h (772 bytes, patch)
2006-04-01 14:15 UTC, Vincent Torri
rejected Details | Review
patch for Makefile.am (479 bytes, patch)
2006-04-01 14:16 UTC, Vincent Torri
rejected Details | Review
test application (8.34 KB, text/plain)
2006-04-01 14:17 UTC, Vincent Torri
  Details

Description Vincent Torri 2006-04-01 14:13:30 UTC
I have written a small sink that allow to get the buffer corresponding to some frame. Wim told me to add it as an option of the fakesink element.

so, here are 3 patch, for gstfakesink.c, gstfakesink.h and Makefile.am

Some comments : 

1) The api is in gstfakesink.[c/h]. So, in Makefile.am, I install gstfakesink.h. It's certainly not the good solution, as the applications must know where gstcoreelements.so is located. If some has an idea about that...
2) I have added several members in the GstFakeSink structure. Should I provide default values for all of them (like #define DEFAULT_Frame_NBR 0, for example) ?

I also provide a test example that show how to use it

Finally, one question : is it normal that, when I seek to frame 0, the timestamp of the buffer that gstreamer returns is > 0 ( that it, 1 / fps exactly)
Comment 1 Vincent Torri 2006-04-01 14:14:51 UTC
Created attachment 62541 [details] [review]
patch for gstfakesink.c
Comment 2 Vincent Torri 2006-04-01 14:15:25 UTC
Created attachment 62542 [details] [review]
patch for gstfakesink.h
Comment 3 Vincent Torri 2006-04-01 14:16:07 UTC
Created attachment 62543 [details] [review]
patch for Makefile.am
Comment 4 Vincent Torri 2006-04-01 14:17:24 UTC
Created attachment 62544 [details]
test application

test application. Usage : 

seek_sink video_file frame_number
Comment 5 Jan Schmidt 2006-04-03 09:08:26 UTC
I'm pretty sure that Wim didn't mean this by what he said, but I could be wrong.

We don't install headers for specific elements precisely because they should not have special API.

I'll leave it to Wim to explain more clearly exactly what he had in mind, I guess.
Comment 6 Michael Smith 2006-04-03 21:52:40 UTC
From some IRC discussion:

The reason for the first frame having a timestamp > 0 turns out to be (probably; haven't confirmed this with testing) because fakesink only does buffer-handoffs in its preroll function (well, in the attached code it's because that code is only run in the render() function, NOT in the preroll() function, but taking a different approach and using signal handoffs, you'd run into this problem.

So, this should probably be fixed in fakesink.
Comment 7 Tim-Philipp Müller 2006-06-15 09:24:51 UTC
This has been resolved by:

 2006-05-23  Tim-Philipp Müller  <tim at centricular dot net>

        Patch by: Julien Moutte  <julien at moutte net>

        * plugins/elements/gstfakesink.c: (gst_fake_sink_class_init),
        (gst_fake_sink_preroll):
        * plugins/elements/gstfakesink.h:
          API: Add new GstFakeSink::preroll-handoff signal (#337100).


hasn't it? If not, please re-open.


*** This bug has been marked as a duplicate of 337100 ***