bus-sync-handler vs bus-watch vs both.

[wl2776]

My player sets both the bus-sync-signal-handler and the bus-watch.
And, it seems, bus-watch is not called at all.

And the code, processing the messages, is identical in these handlers. The difference is only in the return values.

So, is it necessary to set up both handlers?
If no, what should I choose?

[wl2776]

wl2776 wrote

My player sets both the bus-sync-signal-handler and the bus-watch.
And, it seems, bus-watch is not called at all.

And the code, processing the messages, is identical in these handlers. The difference is only in the return values.

So, is it necessary to set up both handlers?
If no, what should I choose?

Found. The documentation says, the bus-sync-signal-handler "is usually only called by the creator of the bus. Applications should handle messages asynchronously using the gst_bus watch and poll functions."

However, my player has to pause the pipeline after the first frame is displayed, I can only do this in the bus-sync-handler.

The question remains, why my bus watch isn't called at all?

My bus-sync-handler consists of only one switch operator:

GstBusSyncReply bus_sync_handler(GstBus * bus, GstMessage * message)
{
  switch (GST_MESSAGE_TYPE (message)) {
    case GST_MESSAGE_EOS:
      // process eos, just prints.
      break;
    case GST_MESSAGE_BUFFERING:
      // process BUFFERING message, again just prints
      break;
    case GST_MESSAGE_ELEMENT:
      if (!gst_structure_has_name (message->structure, "prepare-xwindow-id"))
        return GST_BUS_PASS;
      if(/* we have hwnd of a window, where to draw  */)
        gst_x_overlay_set_xwindow_id (GST_X_OVERLAY (GST_MESSAGE_SRC(message)),m_hwnd);
      else
        return GST_BUS_PASS;
      break;
    case GST_MESSAGE_ERROR:
     // again, just print error info and debug details
      break;
    case GST_MESSAGE_DURATION:
      //query stream duration
      break;
    case GST_MESSAGE_STATE_CHANGED:
      gst_message_state_changed(bus,message);  
      // again, just check message owner and set the m_player to paused state
      break;
    default:
      GST_DEBUG("message %s(%d) from %s",
          GST_MESSAGE_TYPE_NAME(message),
          GST_MESSAGE_TYPE(message),
          GST_MESSAGE_SRC_NAME(message));
      return GST_BUS_PASS;
  }
  gst_message_unref (message);
  return GST_BUS_DROP;
}

[wl2776]

wl2776 wrote

wl2776 wrote

My player sets both the bus-sync-signal-handler and the bus-watch.
And, it seems, bus-watch is not called at all.
And the code, processing the messages, is identical in these handlers. The difference is only in the return values.
So, is it necessary to set up both handlers?
If no, what should I choose?

Found. The documentation says, the bus-sync-signal-handler "is usually only called by the creator of the bus. Applications should handle messages asynchronously using the gst_bus watch and poll functions."
However, my player has to pause the pipeline after the first frame is displayed, I can only do this in the bus-sync-handler.

Finally, after some research, I've come to an answer.
I can also answer the question, which was here, about the running g_main_loop in a separate thread - that's possible, I've performed this using GThreads.
I am writing an embedded player, which is an ActiveX component, and it seems, there is no main loop by default, where I could insert gst_bus_poll.

When the message is posted, the bus-sync-handler is called immediately, and there are a lot of functions like gst_element_post_message in the call stack - this handler is called from elements' threads.
A bit later, a bus-watch is called, the call stack is much less, and it contains g_main_loop function.

Since that, bus-sync-handler should process a minimum messages, which really must be processed very quickly. All other processing should be in the bus-watch.

For example, my handler processes GST_MESSAGE_ELEMENT, if it contains the "prepare-xwindow-id" bit, to set the HWND, and GST_MESSAGE_STATE_CHANGED in the very beginning, if the message source is the playbin2 - my player has to display the first video frame and go to the paused state.
The sync-handler returns GST_BUS_DROP on these messages and unrefs them and GST_BUS_PASS on all others.
All other messages (EOS, ERROR, BUFFERING, TAG, etc) are processed in the bus-watch.