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 705748 - Duration is taken as an outpoint instead in ges_timeline_object_set_duration ()
Duration is taken as an outpoint instead in ges_timeline_object_set_duration ()
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-editing-services
0.10.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-08-10 01:32 UTC by Alexandre Quessy
Modified: 2013-08-11 10:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example code that demonstrates that duration is taken as an outpoint (5.85 KB, text/x-csrc)
2013-08-10 01:32 UTC, Alexandre Quessy
Details

Description Alexandre Quessy 2013-08-10 01:32:10 UTC
Created attachment 251265 [details]
Example code that demonstrates that duration is taken as an outpoint

When calling ges_timeline_object_set_duration (), it seems like the outpoint becomes the value of the duration, and not the inpoint plus the duration, as it should be.

Let say one specifies a in-point of 3.0 seconds, and a duration of 6.0 seconds, the resulting clip should last 6.0 seconds, but it lasts only 3.0 seconds.

So, the duration is taken as an outpoint instead. The outpoint should be inpoint + duration.

See the complete C file attached.
Comment 1 Alexandre Quessy 2013-08-10 01:43:12 UTC
Note that GES_TIMELINE_OBJECT_DURATION () returns 0:00:06.000000000, as it should be, but the resulting clip actually last 3 seconds, as reported by the time(1) command.
Comment 2 Tim-Philipp Müller 2013-08-10 09:53:30 UTC
Thanks for the bug report. However, 0.10 is not maintained any longer. Does this still happen with ges as in git master?
Comment 3 Tim-Philipp Müller 2013-08-11 10:55:47 UTC
<thiblahute> I just tested that and it works just as expected in 1.0/master