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 151661 - [PATCH] [mad] Possible bug in mad plugin
[PATCH] [mad] Possible bug in mad plugin
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.2
Other Linux
: Normal normal
: 0.8.8
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-09-02 01:11 UTC by Francis Labonte
Modified: 2005-01-09 01:57 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Proposed patch (2.59 KB, patch)
2004-09-22 01:40 UTC, Francis Labonte 		none Details | Review
Sample causing me the problem (42.02 KB, application/octet-stream)
2005-01-07 17:07 UTC, Francis Labonte 		  Details

Description Francis Labonte 2004-09-02 01:11:48 UTC 
Hi,

I've got a problem when trying to decode a mp3 file (filesrc location=a.mp3 ! 
mad ! ...).  I've founded that the caps was'nt set correctly.  I think this 
problem come from the method use to recover from a "MAD_ERROR_LOST_SYNC".

Actually, when this happen and the data is a id3tag, then "mad_stream_skip" is 
used to move at the and of the current tag, and it is followed by a call 
to "mad_stream_sync".

However, I've founded that "mad_stream_sync" does'nt move the actual data 
pointer, but only set an internal offset/skip value.   

So, "mad_stram_sync" move the data pointer to the next frame and the next time 
you call mad_decode, the offset will be applied.  Of course, the position will 
now be wrong and will cause the decoder to return a sync error once again.

I think we should not call "mad_stram_sync" when "mad_stream_skip" has just 
been called.  OR, "mad_stream_skip" should consider the skip/offset if there 
is one.
Comment 1 Francis Labonte 2004-09-22 01:40:55 UTC 
Created attachment 31803 [details] [review]
Proposed patch
Comment 2 Christian Fredrik Kalager Schaller 2004-12-21 15:32:34 UTC 
Adding patch keyword and setting milestone to be sure this gets reviewed before
next release of gst-plugins.
Comment 3 Thomas Vander Stichele 2004-12-23 12:19:45 UTC 
DON'T milestone to next release without a possible resolution
Comment 4 Ronald Bultje 2005-01-07 10:05:23 UTC 
Francis,

* do you have a testcase that I can test this against?
* can you please not use hungary coding style? bResync -> resync.
Comment 5 Francis Labonte 2005-01-07 17:07:15 UTC 
Created attachment 35622 [details]
Sample causing me the problem
Comment 6 Ronald Bultje 2005-01-09 01:57:51 UTC 
ok, seems sane, applied, thanks.