[Bug 765072] splitmuxsink: Sometimes creates a small one-frame file after EOS

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=765072

Xavier Claessens <xclaesse at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #2 from Xavier Claessens <xclaesse at gmail.com> ---
I'm waiting to get EOS event on the bin's bus.

Here is what I think happens:

 - EOS is catched on all streams in handle_mq_input().

 - In handle_gathered_gop() at_eos is TRUE, it sets state to
SPLITMUX_STATE_ENDING_FILE, but max_out_running_time is not set to
GST_CLOCK_TIME_NONE in that case. So it could still have a possibly incomplete
GOP in the mq that won't be allowed to leave.

 - complete_or_wait_on_out() will call send_eos() on every streams. Note that
those EOS are not the EOS queued in the mq, since they are queued behind the
last GOP. It generates eos events because state is SPLITMUX_STATE_ENDING_FILE
just like if we reached file size limit.

 - bus_handler() catch EOS. It change state to
SPLITMUX_STATE_START_NEXT_FRAGMENT, and won't let that EOS propagate to
application, so my app won't change state to NULL yet.

 - start_next_fragment() goes in the case when reference EOS has in_eos set to
TRUE. It sets state to SPLITMUX_STATE_WAITING_GOP_COMPLETE and
max_out_running_time to GST_CLOCK_TIME_NONE. Note that it also uselessly set
splitmux->have_muxed_something = FALSE; since that value is changed the line
just after.

 - The last GOP goes out in a new file, then queued EOS pop out of the mq. This
time the EOS event is propagated up to the pipeline.

 - My app catch EOS, change state of splitmuxsink to NULL and it teardown
everything.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.