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 142268 - avidemux forwards flush events event when not seeking
avidemux forwards flush events event when not seeking
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.1
Other Linux
: Normal normal
: 0.8.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-10 12:52 UTC by Sebastien Cote
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Sebastien Cote 2004-05-10 12:52:51 UTC 
On Fri, 2004-05-07 at 21:28, Sebastien Cote wrote:
> When reading the avi, riff-read seeks in the input
> file which causes the filesrc to send a FLUSHING
> event.  riff then does a gst_pad_event_default() on
> the sinkpad of the avidemux which pushes it to the
> next element in the pipeline.  But this event
> shouldn't leave the avidemux since we're not really
> seeking in the media. If there's a queue in the
> pipeline, it will empty itself when it receives this
> event.
> 
> So I intercepted the FLUSHING event in riff-read.c to
> get rid of it.  It works, but I think this could break
> REAL seeking.
> 
> Does anyone know what the correct fix is?

Check avidemux->state (probably needs to be moved to riff->state), and
don't forward flush events if we're != GST_AVI_DEMUX_MOVI (should be
renamed GST_RIFF_READ_DATA).
Comment 1 Ronald Bultje 2004-05-11 01:23:11 UTC 
Riff has no padding bytes (oi!) so I can't add this until 0.9.x. I'm sorry,
you'll have to live with a local hack for now. :-(.
Comment 2 Sebastien Cote 2004-05-11 02:05:17 UTC 
Do you mean that this would break ABI compatibility?  If so, could it be done in
the avidemux by adding a event handler on the sink pad?
Comment 3 David Schleef 2004-05-11 02:22:06 UTC 
Ronald, do you mean GstRiffRead?  If it's really important, we can steal a field
from the padding in GstElement to mean "oops, my subclass forgot to use padding".
Comment 4 Ronald Bultje 2004-05-11 02:42:33 UTC 
Yes, GstRiffRead. Stealing from GstElement is an option... I guess using a
GstElement field is an option. Better than a bug. What's the suggested field
name? "subclass_forlorn_field"? :).
Comment 5 Ronald Bultje 2004-10-01 11:16:06 UTC 
I just fixed this differently.