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 660468 - speexenc: fix calculation of filler data size
speexenc: fix calculation of filler data size
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other All
: Normal normal
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-29 13:26 UTC by Vincent Penquerc'h
Modified: 2011-10-03 14:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
speexenc: fix calculation of filler data size (959 bytes, patch)
2011-09-29 13:26 UTC, Vincent Penquerc'h
none Details | Review

Description Vincent Penquerc'h 2011-09-29 13:26:42 UTC
speexenc: fix calculation of filler data size
Comment 1 Vincent Penquerc'h 2011-09-29 13:26:44 UTC
Created attachment 197764 [details] [review]
speexenc: fix calculation of filler data size
Comment 2 Sebastian Dröge (slomo) 2011-10-03 09:29:07 UTC
Is this still valid after the GstAudioEncoder port?
Comment 3 Vincent Penquerc'h 2011-10-03 12:09:02 UTC
The new code seems to do the flush-with-0 at every buffer. Is that intended ?
If so, then it handles the filler well, so my patch is unneeded.
Current code also writes the buffer twice, but only when the input isn't a multiple of bytes, so I guess not very often anyway.
Comment 4 Mark Nauwelaerts 2011-10-03 14:03:12 UTC
It performs it now sort-of at every buffer (intended), because AudioEncoder is configured to ensure that there won't be some mod leftover (except when performing flushing/draining).

If by "writing the buffer twice" is meant first some 0-filling and then a subsequent copy, that should not be big deal as the flushing/draining should only happen (insignificantly) rarely.

So closing.