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 324696 - [videotestsrc] does not start counting the time from zero when restarted
[videotestsrc] does not start counting the time from zero when restarted
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-21 12:42 UTC by Michal Benes
Modified: 2006-01-03 08:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Start counting buffer times from zero after restart. (1.93 KB, patch)
2005-12-21 12:43 UTC, Michal Benes
reviewed Details | Review

Description Michal Benes 2005-12-21 12:42:03 UTC
The problem is that videotestsrc->n_frames and videotestsrc->running_time are never reseted.

Attached patch also fixes simple printf format bug.
Comment 1 Michal Benes 2005-12-21 12:43:22 UTC
Created attachment 56252 [details] [review]
Start counting buffer times from zero after restart.
Comment 2 alfredoj69 2005-12-22 12:53:03 UTC
Thanks for taking the time to report this bug.
This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a more useful description to this bug.
Comment 3 Elijah Newren 2005-12-22 15:27:43 UTC
alfredoj69: He has a patch to fix the issue; he did far better than just describing it well enough.
Comment 4 Michal Benes 2005-12-22 15:55:50 UTC
Hello, It may sound a little stupid but after my last cvs update the bug can not longer be easily reproduced. The thing is that since Dec 12, basing performs seek to 0 when inactivating its sink pad. Of course, this resets videotests running time and the timestamps are correct as the result.

The bug does not hurt me anymore, so you can close it as invalid if you wish.

Just to save my reputation, let me explain the thing once more:
In videotestsrc, variables running_time and n_frames are never reseted when the element is going to READY state. This means that when running videotestsrc for three seconds, going to NULL and going to PLAYING again, videotestsrc will start from timestamp 3 * GST_SECOND. I think that the correct behavior would be to start the stream from the beginning.
Comment 5 Michal Benes 2005-12-22 15:58:04 UTC
Sorry, there was a typo in the first paragraph that rendered it confusing:

Hello, It may sound a little stupid but after my last cvs update the bug can
not longer be easily reproduced. The thing is that since Dec 12, basesink
performs seek to 0 when inactivating its sink pad. Of course, this resets
videotests running time, and the timestamps are correct as the result.
Comment 6 Tim-Philipp Müller 2005-12-23 22:04:39 UTC
Michel, your report was perfectly fine (and FYI, alfredoj69 is not a GStreamer developer). Haven't looked at it before because gst-plugins-base was frozen until the 0.10.1 release, so it couldn't have been committed anyway.

It's good to know that it doesn't happen any longer, those variables should probably be reset in any case though ;)
Comment 7 Tim-Philipp Müller 2005-12-27 22:32:33 UTC
Fixed in CVS, thanks!

I have not committed those "printf-format fixes", as I don't understand them (where are they passed as first argument to printf? Does it not work already for you now without those?).


2005-12-27  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/videotestsrc/gstvideotestsrc.c:
        (gst_video_test_src_class_init), (gst_video_test_src_start):
          Add start method to reset running time and number of frames sent
          when starting up (fixes #324696; patch by: Michal Benes).

(Thomas: we need a 0.10.2 version target ...)