gst_event_new_eos gives NO GST_MESSAGE_EOS but instead warnings not and packet 13548 too late as #46078 was already popped

[Tim Müller]

On Thu, 2015-04-02 at 08:50 +0000, Marc Lievens wrote:

Hi Marc,

> With the used pipeline ( gstreamer V1.4.5) the video is saved to file
> and the onvif data is seen.
> 
>  
> 
> rtspsrclocation=rtspUrl name=rtspsrc rtspsrc.
> 
> ! queue name=videoqueue ! rtph264depay! h264parse! matroskamux !
> filesink rtspsrc.
> 
> ! queue name=onvifqueue ! application/x-rtp, media=application !
> fakesink 
> 
>  
> 
> But when I send a eos  as (bool reply true) 
> 
>  
> 
> gst_element_send_event(matroskamux, gst_event_new_eos());
> 
>  
> 
> or as 
> 
>  
> 
> pad = gst_element_get_static_pad(matroskamux, "video_0");
> 
> gst_pad_send_event(pad, gst_event_new_eos());
> 
>  
> 
> , then the GST_MESSAGE_EOS is never arrived and after a while the next
> warning are  continues logged.
> 
>  
> 
> warning
> rtpjitterbuffer.c2351:gst_rtp_jitterbuffer_chain:<rtpjitterbuffer0>
> packet 13548 too late as #46078 was already popped, dropping 7632
> 
>  
> 
> When I use only the Video channel then everything seems to work fine.
> The eos is send and processed on GST_MESSAGE_EOS

Usually bins (and the toplevel pipeline) will 'aggregate' EOS messages,
meaning they will not pass them on to the higher level or the
application until *all* sinks in the bin/pipeline have posted an EOS
message.

In your case, I suspect the EOS goes through to the filesink, but the
fakesink never posts one, so the pipeline doesn't forward the EOS to the
application.

Two options:

 - send the EOS event on rtspsrc (via gst_element_send_event)

 - set message-forward=true on the pipeline [1]

Cheers 
 -Tim

[1] see the bus message handler in
http://people.freedesktop.org/~tpm/code/test-backlog-recording-h264.c
for an example how to handle the EOS then.



-- 
Tim Müller, Centricular Ltd - http://www.centricular.com