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 142851 - gstid3tag sends wrong offset on discont events
gstid3tag sends wrong offset on discont events
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal normal
: 0.8.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-20 16:17 UTC by Arwed v. Merkatz
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch for gstid3tag.c (672 bytes, patch)
2004-05-20 16:18 UTC, Arwed v. Merkatz 		none Details | Review

Description Arwed v. Merkatz 2004-05-20 16:17:00 UTC 
gstid3tag sends a discont event containing the offset in the whole file, not the
offset of the file stripped of id3 tags. This is inconsistent with the buffer
offsets it sets and basically means that a decoder element has to know that the
file contains an id3v2 tag (or ignore the discont value and use the offset of
the next buffer, but that's ugly).
I got a patch that fixes it, but for some reason that breaks flac files with id3
tags.
Comment 1 Arwed v. Merkatz 2004-05-20 16:18:20 UTC 
Created attachment 27878 [details] [review]
patch for gstid3tag.c
Comment 2 Ronald Bultje 2004-05-20 16:33:03 UTC 
How does this break FLAC files? Patch looks good, I'd vote for applying it.
Comment 3 Arwed v. Merkatz 2004-05-20 16:45:34 UTC 
Normal flac files work fine, .flac files with id3 tags report a wrong total
lenght in gst-player and seeking always seeks back to start of file.
Comment 4 Ronald Bultje 2004-05-20 17:24:01 UTC 
It probably *reports* a new timestamp of zero. That sounds like the same bug
that I just fixed in the mad plugin. It really does seek halfway, but it reports
a timestamp of zero afterwards.
Comment 5 Benjamin Otte (Company) 2004-06-06 21:03:18 UTC 
applied