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 689326 - multifdsink: document that adding fd in NULL is not allowed
multifdsink: document that adding fd in NULL is not allowed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.x
Other Linux
: Normal minor
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-30 05:15 UTC by qmax
Modified: 2012-12-02 12:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description qmax 2012-11-30 05:15:34 UTC
Using 1.0.3-1~ubuntu12.04.1~ppa1 from ppa:gstreamer-developers
And the following python code:

--------------------------------------

import gi
gi.require_version('Gst', '1.0')
from gi.repository import GObject, Gst
GObject.threads_init()
Gst.init(None)

pipeline = Gst.parse_launch("""
    audiotestsrc ! vorbisenc ! mux.
    videotestsrc ! theoraenc ! mux.
    oggmux name=mux ! multifdsink name=out
    """)

out = pipeline.get_by_name('out')
piper, pipew = os.pipe()
out.emit('add', pipew)

--------------------------------------

0:00:02.711917442  7801      0x1083520 DEBUG        multihandlesink gstmultihandlesink.c:663:gst_multi_handle_sink_add_full:<out> [fd     6] adding client, sy
nc_method 0, min_format 0, min_value 0, max_format 0, max_value 18446744073709551615

(python:7801): GStreamer-CRITICAL **: gst_poll_add_fd: assertion `set != NULL' failed

(python:7801): GStreamer-CRITICAL **: gst_poll_restart: assertion `set != NULL' failed

0:00:02.885316157  7801      0x12ae720 LOG          multihandlesink gstmultihandlesink.c:1904:gst_multi_handle_sink_render:<out> received buffer 0x7f77f411739
0, in_caps: no, offset 6159, offset_end 22987, timestamp 0:00:00.000000000, duration 0:00:00.133333333
0:00:02.885323855  7801      0x12ae720 LOG          multihandlesink gstmultihandlesink.c:1707:gst_multi_handle_sink_queue_buffer:<out> Using max -1, softmax -
1
0:00:02.885328104  7801      0x12ae720 LOG          multihandlesink gstmultihandlesink.c:1726:gst_multi_handle_sink_queue_buffer:<out> [fd     6] client 0x126
83a0 at position 0
0:00:02.885332311  7801      0x12ae720 DEBUG               GST_POLL gstpoll.c:859:gst_poll_fd_ctl_write: 0x12ae050: fd (fd:6, idx:-1), active : 1
0:00:02.885336208  7801      0x12ae720 WARN                GST_POLL gstpoll.c:880:gst_poll_fd_ctl_write: 0x12ae050: couldn't find fd !
Comment 1 Tim-Philipp Müller 2012-11-30 10:29:24 UTC
I believe you need to set the state of multifdsink (or the pipeline as a whole) to something >GST_STATE_NULL first.
Comment 2 qmax 2012-12-02 02:41:37 UTC
Nope. That does not help.
Comment 3 qmax 2012-12-02 03:27:54 UTC
The same happens when using C:

#include <stdio.h>
#include <stdlib.h>
#include <gst/gst.h>
#include <glib.h>

int
main(int   argc, char *argv[])
{
  GMainLoop *loop;
  GstElement *pipeline, *sink;
  int pipefd[2];

  gst_init (&argc, &argv);

  pipeline = gst_parse_launch("audiotestsrc ! vorbisenc ! mux. "
                              "videotestsrc ! theoraenc ! mux. "
                              "oggmux name=mux ! multifdsink name=out",
                             NULL);
  sink = gst_bin_get_by_name((GstBin*)pipeline, "out"); 
  pipe(pipefd);
  g_signal_emit_by_name(sink, "add", pipefd[0]);
}
Comment 4 qmax 2012-12-02 04:44:53 UTC
Solved:

The critical mesages refer to multifdsink->fdset which is initialized at  gst_multi_fd_sink_start_pre

That leads that the element has to be in PLAYING or READY state before adding new fd.
This is quite not obvious and probably should be documented.
Comment 5 Tim-Philipp Müller 2012-12-02 12:56:31 UTC
> Solved:
> The critical mesages refer to multifdsink->fdset which is initialized at 
> gst_multi_fd_sink_start_pre
> That leads that the element has to be in PLAYING or READY state before adding
> new fd.

Yes, like I said in comment #1 ;)


> This is quite not obvious and probably should be documented.

I've made it print a warning now, and added a note to the docs.