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 554901 - ffmux does not clean up properly on PAUSED->READY
ffmux does not clean up properly on PAUSED->READY
Status: RESOLVED DUPLICATE of bug 491271
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.x
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-10-03 18:09 UTC by Pavel Zeldin
Modified: 2009-03-05 08:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
clean stream context (4.04 KB, patch)
2008-10-03 18:14 UTC, Pavel Zeldin
needs-work Details | Review
test program to run a pipeline (5.02 KB, text/plain)
2008-10-06 23:13 UTC, Pavel Zeldin
  Details

Description Pavel Zeldin 2008-10-03 18:09:56 UTC
Please describe the problem:
Pipeline with ffmux cannot be set to PAUSED/NULL and then PLAYING again.
ffmux does not clean stream context, and after the pipeline goes to PLAYING it
rejects new buffers because the source timestamps appear to be earlier than it expects


Steps to reproduce:
1. Build pipeline with ffmux_asf or ffmux_mpeg
2. Go to PLAYING state
3. Go to NULL (or READY) state
4. Go to PLAYING state again

Actual results:
error, non monotone timestamps" from libavformat/utils.c

Expected results:
no errors

Does this happen every time?
yes

Other information:
Comment 1 Pavel Zeldin 2008-10-03 18:14:17 UTC
Created attachment 119881 [details] [review]
clean stream context
Comment 2 Pavel Zeldin 2008-10-06 23:13:14 UTC
Created attachment 120068 [details]
test program to run a pipeline

This could be useful in reproducing the problem.
To compile/link run:
gcc -o pipelineplayer `pkg-config --cflags-only-I gstreamer-0.10` pipelineplayer.c `pkg-config --libs gstreamer-0.10`

This programs expect one argument: pipeline to execute. While the program is
running send HUP signal and it will set pipeline to NULL and then PLAYING again,
which could help, except that it exposes another one:
GST_DEBUG=3 ./pipelineplayer 'videotestsrc ! ffmpegcolorspace ! timeoverlay ! ffenc_msmpeg4 ! ffmux_asf ! ffdemux_asf ! ffdec_msmpeg4 ! ffmpegcolorspace ! ximagesink'
results in:
0:00:04.215762175 26071  0x9556008 WARN                ffmpeg gstffmpegdemux.c:1440:gst_ffmpegdemux_sink_activate_push:<ffdemux_asf0> error: failed to activate sinkpad in pull mode, push mode not implemented yet
0:00:04.215981693 26071  0x9556008 INFO      GST_ERROR_SYSTEM gstelement.c:1677:gst_element_message_full:<ffdemux_asf0> posting message: Element doesn't implement handling of this stream. Please file a bug.
0:00:04.216157382 26071  0x9556008 INFO      GST_ERROR_SYSTEM gstelement.c:1700:gst_element_message_full:<ffdemux_asf0> posted error message: Element doesn't implement handling of this stream. Please file a bug.
Comment 3 Sebastian Dröge (slomo) 2008-10-08 10:43:08 UTC
We don't patch ffmpeg so this patch is not the correct solution. You should clean everything up with the stuff that is provided by ffmpeg from the GStreamer plugin, maybe by recreating the av_streams or something.
Comment 4 Edward Hervey 2009-03-05 08:08:20 UTC

*** This bug has been marked as a duplicate of 491271 ***