GNOME Bugzilla – Bug 761761
splitmuxsink: Caps changes not handled
Last modified: 2017-02-17 20:12:17 UTC
When changing caps the splitmuxsink closes the file being written to and stops processing frames. pipeline: appsrc -> videoscale -> capsfilter-> videorate -> videoconverter -> x264enc -> splitmuxsink The mux in the splitmuxsink is an avimux. The sink in the splitmuxsink is a filesink. Incoming frames have variable frame dimensions. If I replace the splitmuxsink with the avimux and filesink then the pipeline successfully adapts to changing frame dimensions.
Could you provide a sample application or an unit test to reproduce this issue?
Created attachment 345871 [details] [review] splitmuxsink: Change files on incompatible caps
Created attachment 345872 [details] [review] splitmuxsink: Remove unused ready_for_output
Created attachment 345873 [details] [review] splitmuxsink: Remove always TRUE if()
Created attachment 345874 [details] [review] splitmuxsink: Remove unused muxed_out_time
Created attachment 345875 [details] [review] splitmuxsink: Remove unused next_max_out_running_time
The first patch in the series fixes this bug by cutting a new file when the caps change and the muxer rejects that change. I'm totally unsure if I'm doing it correctly. My test case includes a RTP stream which a variable frame size.
Created attachment 345884 [details] [review] splitmuxsink: Reset ready_for_output on state change I'm not sure if this is enough, but it was strange that it was never reset.
Review of attachment 345874 [details] [review]: muxed_out_time isn't needed any more since I rewrote how fragments are scheduled for output / switching.
Review of attachment 345875 [details] [review]: cool
Review of attachment 345884 [details] [review]: Yes, thanks!
Review of attachment 345871 [details] [review]: I'm not sure this will work entirely correctly. I think it will attempt to open a new fragment without having collected the first buffer of the new fragment, which is needed for the format-location-full signal. We probably need some extra logic to end the old file, but defer opening the new one by setting ready_for_output to FALSE until the next video buffer arrives.
Created attachment 346028 [details] [review] splitmuxsink: Change files on incompatible caps Here is an updated version that instead just sends the EOS directly and drops all event until a buffer arrives so that we have the buffer for the signal.
Created attachment 346029 [details] [review] splitmuxsink: Change files on incompatible caps
Created attachment 346030 [details] [review] splitmuxsink: Change files on incompatible caps Updated again to reset the ready_for_output.. And also only drop sticky events as I think we want to let flushes through.
Review of attachment 346030 [details] [review]: Looks OK to me now :)
Merged: commit d8868c633900a77139ea263b4bfe26970991d8a0 Author: Olivier Crête <olivier.crete@collabora.com> Date: Wed Feb 15 14:48:58 2017 -0500 splitmuxsink: Change files on incompatible caps https://bugzilla.gnome.org/show_bug.cgi?id=761761 commit f79a7afac2413687705ba9ddb999b4914404c68b Author: Olivier Crête <olivier.crete@collabora.com> Date: Wed Feb 15 16:35:01 2017 -0500 splitmuxsink: Reset ready_for_output on state change https://bugzilla.gnome.org/show_bug.cgi?id=761761 commit 5059b9b8c99608cfd3321f96170e0c135457c041 Author: Olivier Crête <olivier.crete@collabora.com> Date: Wed Feb 15 15:09:06 2017 -0500 splitmuxsink: Remove unused next_max_out_running_time https://bugzilla.gnome.org/show_bug.cgi?id=761761 commit c98d932fb869ab6e763972360b435830147a4414 Author: Olivier Crête <olivier.crete@collabora.com> Date: Wed Feb 15 15:07:32 2017 -0500 splitmuxsink: Remove unused muxed_out_time https://bugzilla.gnome.org/show_bug.cgi?id=761761