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 607949 - [avidemux] regression in stop position for mp3 streams
[avidemux] regression in stop position for mp3 streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal blocker
: 0.10.18
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 608136
Blocks:
 
 
Reported: 2010-01-24 17:12 UTC by Edward Hervey
Modified: 2010-01-26 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
possible patch (1.14 KB, patch)
2010-01-26 10:25 UTC, Wim Taymans
none Details | Review

Description Edward Hervey 2010-01-24 17:12:43 UTC
the timestamp on mp3 packets indicates that this is the first packet needed to decode the requested timestamp... but the mp3 decoder will need the one (or two) following packets in order to decode that requested timestamp.

Currently avidemux EOS's after having pushed the buffer for the requested stop position... resulting in the mp3 decoder not having enough data to actually decode up to the requested stop position.

avidemux should push out the following 1/2 buffers for those streams.
Comment 1 Sebastian Dröge (slomo) 2010-01-24 17:16:38 UTC
In the worst case 29 frames (iirc) are required btw, but that's quite unlikely. How was this handled before in avidemux?
Comment 2 Sebastian Dröge (slomo) 2010-01-24 17:19:52 UTC
Oh wait, isn't it the other way around only? An MP3 frame can depend on up to 29 previous frames but not on frames in the future (unless we're talking about reverse playback of course).
Comment 3 Wim Taymans 2010-01-25 17:22:37 UTC
The code that seems to cause EOS was there for ages. I can't seem to figure out why it would suddenly be a regression... I guess I'll have to write a test app.
Comment 4 Wim Taymans 2010-01-26 10:21:35 UTC
The reason for this regression is because we now handle all streams independently and when one of the streams goes EOS, we shut down all other streams too.

Patch follows.
Comment 5 Wim Taymans 2010-01-26 10:25:11 UTC
Created attachment 152296 [details] [review]
possible patch

possible patch
Comment 6 Wim Taymans 2010-01-26 16:09:50 UTC
commit 01f0a5ce3271cc133dbb26a9dc5553ddd1c51726
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Tue Jan 26 11:18:28 2010 +0100

    avidemux: ignore streams that finished
    
    When we receive an UNEXPECTED from a stream, move to the next stream and only go
    EOS when all streams are EOS. When selecting a stream to push, ignore streams
    that went EOS.
    
    Fixes #607949