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 709940 - [pitivi] Audio glitch / sound jerkiness at some points in time when mixing multiple audio clips
[pitivi] Audio glitch / sound jerkiness at some points in time when mixing mu...
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-editing-services
1.1.90
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-11 21:05 UTC by Jean-François Fortin Tam
Modified: 2018-01-23 11:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2013-10-11 21:05:16 UTC
Grab this sample project: http://jeff.ecchi.ca/public/sample-pitivi-projects/sound-glitch-test.xges_tar

Rendering it will produce: http://jeff.ecchi.ca/public/sample-pitivi-projects/sound-glitch-test.ogv

Now, the bug is rather subtle, but if you listen closely (you can compare with the music soundtrack MP3 file) you will hear the music "hiccup" at the following times: 5, 18, 21 seconds; 1m + {8, 11, 16} seconds.

(note that I purposedly lowered the volume of narration so that you can actually hear the glitches in the music)
Comment 1 Thibault Saunier 2013-10-12 12:39:42 UTC
I investigated that and what I noticed is that at it happens at the precise time where you have the transition between 2 source.

I can notice that at that exact time you have a discont buffer, which means that "the buffer marks a data discontinuity in the stream. This typically occurs after a seek or a dropped buffer from a live or network source." which might be a beginning of a lead.

In playback the glitch does not happen and, if you do not encode the audio stream while rendering (for example you can use raw audio in mkv), the glitch does not happen.

I will check further how to solve that issue later.
Comment 2 Thibault Saunier 2013-10-12 14:59:15 UTC
So, as I understand it now, we get incoherencies in timestamp whenever we have a cut in the composition.

For example:

0         5          10        15
          [  clip 1  ] 
[            clip2             ]

The buffer timestamp comming into the encoder at around 5 look like:

0:00:04.935691609 (duration = 23219955)
0:00:04.958911564
0:00:04.982131519

And then we have the update in the pipeline created by gnl and the next timestamp will be:

0:00:05.000000000

instead of 4982131519 + 23219955 = 5005351474


I do know much about that kind of stuff and how audio encoder support this kind of things, could that be the reason why we get that "glitches" when such thing happen?
Comment 3 Tim-Philipp Müller 2014-11-24 10:41:39 UTC
Still a problem one year on with new gnl, audiomixer, etc?
Comment 4 Tim-Philipp Müller 2018-01-23 11:24:19 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!