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 619634 - audio dropout in unpausing the media
audio dropout in unpausing the media
Status: RESOLVED DUPLICATE of bug 639240
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.29
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-25 16:36 UTC by gudake
Modified: 2011-02-15 14:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
proposed patch (649 bytes, patch)
2010-05-25 16:37 UTC, gudake 		rejected Details | Review

Description gudake 2010-05-25 16:36:50 UTC 
play a media file, pause the media, resuming the media, heard a sound glitch.
Comment 1 gudake 2010-05-25 16:37:58 UTC 
Created attachment 161956 [details] [review]
proposed patch

I found a way to fix the problem.  The idea is only change the base time when a seeking happens (reset_start_time() is called);  if user just pause and resume,  do not change the base_time.  See attached patch.
Comment 2 Wim Taymans 2010-05-26 10:15:33 UTC 
unfortunately that would not work when the clock advances in the paused state, such as when streaming media from a network.
Comment 3 gudake 2010-05-26 20:58:38 UTC 
please advice a better way to resolve this,  like a special clock changed event sent from rtspsrc maybe?
Comment 4 gudake 2010-05-28 18:13:35 UTC 
How about this: add a property "elapseInPaused" to the GstClock.  GstAudioClock set this to be false,  "true" for SystemClock (created by gstrtpdec).   So only GstAudioClock doesn't need to recalculate when playing->paused->playing and no seeking happens.   gstrtpdec remains the same way: always recalculating the base time when paused->playing.
Comment 5 Wim Taymans 2011-02-15 14:47:32 UTC 

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