Changing filesink location after a mux with many inputs.

[Paddy]

OK some progress.

To reprise: this is my situation

videotestsrc ---> timeoverlay ---> x264enc ---> videoQ ---\
                                                                                
+--> matroskamux ---> filesink
audiotestsrc ---------> faac ----------------->  audioQ ---/

where everything upstream of the queues are test elements - to act as
pretend RTSP sources. They'll actually be IP cameras & mics. The mux &
filesink are in their own bin.

I want to save to a new file periodically (every 2 minutes)
To this end I blocked both queue src pads & waited for both callbacks before
continuing to unlink the mux/file bin, send it an EOS, then set it to NULL
state & remove it from the pipeline. I then added & linked a new bin with
new file location properties, sync it's state & unblocked the queue src
pads. I believe this to be the correct procedure.

The problem that I have is that the second pad to be blocked never generates
a callback (I've left it for days & never seen one). The code in the
previous post above demonstrates this. The missing callback was for the
audio path as I usually did this second, but swapping teh order made no
difference.

Now to the progress bit: if, after blocking both src pads, I unlink the bin
on the first blocked callback - I get the second blocked callback soon
after. I have to unlink both pads to see the second callback; I don't see it
just unlinking the pad I receive the first callback for. Carrying on as
above, the next file is created & no data is lost at the start of the new
file. However I'm missing the last 1.3sec of the last file (the 1.3sec
before I blocked the pads).

Hopefully someone can help me with these questions:

Is the missing second callback after blocking both queues expected
behaviour, or a bug ??

Is it safe to unlink both paths even tho' only one has issued the callback
?? In the first callback, both pads state they are active, blocked & not
blocking; as reported by gst_pad_is_active/blocked/blocking. If it's not
safe then what is the alternative given waiting for both callbacks is futile
??

What happened to the missing 1.3 sec of data at the end of the file ?? I'm
sending an EOS to both ghostpads on the bin but the handle_message function
in the bin only reports the first, the second is never observed (I've got a
theme going here). On the first EOS rx'd the handler uses g_idle_add to
launch the bin teardown function which sets the bin state to GST_STATE_NULL
& removes it from the pipeline. 
DO I need to send the EOS twice to the bin ?? 
Is the missing 1.3sec of av a feature of my test srcs ??
Where's the best place to start looking for my missing data, what
debug/logging should I be looking for etc. ?? 

Thanks again. 



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Changing-filesink-location-after-a-mux-with-many-inputs-tp4656116p4656227.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.