Sending EOS to a pipeline containing webrtcbin and Appsrc

Serhan Gül serhan at fastmail.com
Wed Dec 9 09:54:41 UTC 2020


I'm still struggling with this issue. Now suspecting that the EOS message that is sent to the pipeline is not traveling downstream, I enabled message forwarding on the pipeline:
> g_object_set (G_OBJECT(m_pPipeline), "message-forward", true, nullptr);

and started listening for GST_MESSAGE_ELEMENT on my bus:
>. case GST_MESSAGE_ELEMENT:
    {
        const GstStructure *s = gst_message_get_structure(pMsg);

        if (gst_structure_has_name(s, "GstBinForwarded"))
        {
            GstMessage *forward_msg = nullptr;

            gst_structure_get (s, "message", GST_TYPE_MESSAGE, &forward_msg, NULL);
            if (GST_MESSAGE_TYPE (forward_msg) == GST_MESSAGE_EOS)
            {
                LOGGER("EOS from element " << GST_OBJECT_NAME (GST_MESSAGE_SRC (forward_msg)));
            }
            gst_message_unref(forward_msg);
        }
        break;
    }

I also send an EOS event to the encoder element:
> gst_element_send_event(m_pEncoder, gst_event_new_eos());

After these two additions, I can get a forwarded GST_MESSAGE_EOS from the element filesink but still the captured file is unplayable. Interestingly, if I don't send an EOS event to the encoder element and send it just to the pipeline, my bus doesn't get any forwarded EOS messages.

I tried to debug this by setting GST_DEBUG=*:5 and doing "grep -i eos". Here is the full log:
https://pastebin.com/jcS8fEyG
I see there the log "Sending eos event to sink pads" but can't figure out if the EOS message reaches to both of the sinks (webrtcbin and filesink). Any help would be great.

Thanks.


On Mon, Dec 7, 2020, at 9:10 PM, Serhan Gül wrote:
> Hi, I have a pipeline that receives a video stream using from an application appsrc and streams that stream to a WebRTC client. At the same time, the pipeline attempts to save the video to a file (as MP4 but could also be Matroska etc) in a separate branch using the tee command. The pipeline is created programmatically using gst_parse_launch and looks as follows:
> 
> webrtcbin bundle-policy=max-bundle name=myserver stun-server=stun://global.stun.twilio.com:3478?transport=udp appsrc name=TextureSource-1 ! videoconvert ! video/x-raw,format=I420 ! x264enc name=VideoEncoder-1 tune=zerolatency speed-preset=superfast ! tee name=t ! queue ! video/x-h264,stream-format=byte-stream ! filesink location=capture.mp4 t. ! queue ! rtph264pay ! application/x-rtp,media=video,encoding-name=H264,payload=96 ! myserver. 
> 
> I can receive the stream without issues on my WebRTC client but the problem is, the saved MP4 file is mostly unplayable. Somehow, I can only play the file using ffplay which plays it at approximately twice the speed of the capture rate. After some web search, I found out that I need to send an EOS event to the pipeline (so that the MP4 header could be written properly and the file becomes playable) through a command like: 
> 
> gst_element_send_event(m_pPipeline, gst_event_new_eos()); 
> 
> where m_pPipeline is a pointer to my pipeline element.
> 
> However, on my bus I never get a message of type GST_MESSAGE_EOS which, in my understanding, means that the EOS message somehow does not travel downstream to my sinks. I tried to add the "message-forward" parameter using g_object_set (G_OBJECT(m_pPipeline), "message-forward", true, nullptr); but I observed the same behaviour.
> 
> What am I doing wrong here, should the EOS message not directly be sent to the pipeline but to the individual sinks (in this case filesink and webrtcbin)? Is there anything specific to webrtcbin that prevents receiving the EOS message?
> 
> Thank you for your help.
> 
> -- 
>   Serhan Gül
>   serhan at fastmail.com
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201209/10004dd1/attachment.htm>


More information about the gstreamer-devel mailing list