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 756810 - segment_to_stream_time and position_from_stream_time miscalculate when applied_rate < 0
segment_to_stream_time and position_from_stream_time miscalculate when applie...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 1.6.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 757033
 
 
Reported: 2015-10-19 13:25 UTC by Vivia Nikolaidou
Modified: 2015-10-27 15:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch with correct stream_time calculations for negative applied rate. (3.97 KB, patch)
2015-10-19 13:56 UTC, Vivia Nikolaidou
none Details | Review
Added unit tests (5.58 KB, patch)
2015-10-19 14:46 UTC, Vivia Nikolaidou
none Details | Review
Added unit tests for rate > 0 and applied_rate < 0 (6.65 KB, patch)
2015-10-19 15:05 UTC, Vivia Nikolaidou
committed Details | Review

Description Vivia Nikolaidou 2015-10-19 13:25:17 UTC
Pasting from design docs:

===============================
Stream time is calculated using the buffer times and the preceding SEGMENT
event as follows:

    stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time

For negative rates, B.timestamp will go backwards from S.stop to S.start,
making the stream time go backwards.
===============================

The way I understand it, the calculation for applied_rate < 0 should be:

    stream_time = (S.stop - B.timestamp) * ABS (S.applied_rate) + S.time

The existing code does not take into account S.stop at all, it just does B.timestamp again.

Patch coming soon.
Comment 1 Vivia Nikolaidou 2015-10-19 13:56:25 UTC
Created attachment 313663 [details] [review]
Patch with correct stream_time calculations for negative applied rate.
Comment 2 Vivia Nikolaidou 2015-10-19 14:46:07 UTC
Created attachment 313667 [details] [review]
Added unit tests

Added unit tests to make sure things won't break in the future.
Comment 3 Vivia Nikolaidou 2015-10-19 15:05:43 UTC
Created attachment 313668 [details] [review]
Added unit tests for rate > 0 and applied_rate < 0
Comment 4 Sebastian Dröge (slomo) 2015-10-20 07:43:39 UTC
Comment on attachment 313668 [details] [review]
Added unit tests for rate > 0 and applied_rate < 0

commit 45f0f354ac34618d6f6adf20b0bffcf14a3f0a29
Author: Vivia Nikolaidou <vivia@ahiru.eu>
Date:   Mon Oct 19 16:50:51 2015 +0300

    segment: Correct stream_time calc for negative applied rate
    
    Updated gst_segment_position_from_stream_time and gst_segment_to_stream_time to reflect correct calculations for the case when the applied rate is negative.
    
    Pasting from design docs:
    
    ===============================
    Stream time is calculated using the buffer times and the preceding SEGMENT
    event as follows:
    
        stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time
    
    For negative rates, B.timestamp will go backwards from S.stop to S.start,
    making the stream time go backwards.
    ===============================
    
    Therefore, the calculation for applied_rate < 0 should be:
    
        stream_time = (S.stop - B.timestamp) * ABS (S.applied_rate) + S.time
    
    and the reverse:
    
        B.timestamp = S.stop - (stream_time - S.time) / ABS (S.applied_rate)
    
    https://bugzilla.gnome.org/show_bug.cgi?id=756810
Comment 5 Sebastian Dröge (slomo) 2015-10-20 07:44:02 UTC
Should get this into 1.6.1 after it settled a bit in master.