GNOME Bugzilla – Bug 607949
[avidemux] regression in stop position for mp3 streams
Last modified: 2010-01-26 16:09:50 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.
In the worst case 29 frames (iirc) are required btw, but that's quite unlikely. How was this handled before in avidemux?
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).
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.
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.
Created attachment 152296 [details] [review] possible patch possible patch
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