GitLab

Submitted by yis..@..nt.com

Link to original bug (#781121)

Description

Created attachment 349593
attachment showing a potential fix (in function gst_qt_mux_start_file(...) under .../gst/isomp4/gstqtmux.c

There should be no seek in the mux when we set property of "fragment-duration" to non-zero and "streamable" to TRUE. However I found the qtmux still did "seek" under the function gst_qt_mux_stop_file(...) for updating the qtmux->moov->mvex.mehd.fragment_duration in our case.

Basically the "streamable" config got ignored because the qtmux_klass->format != GST_QT_MUX_FORMAT_ISML in our case. The streamable was set in a later stage by the following piece of code under function gst_qt_mux_start_file (GstQTMux * qtmux) when the code found that the downstream is not seekable:

case GST_QT_MUX_MODE_FRAGMENTED:  
  if (!gst_qt_mux_downstream_is_seekable (qtmux)) {  
    GST_WARNING_OBJECT (qtmux, "downstream is not seekable, but "  
        "streamable=false. Will ignore that and create streamable output "  
        "instead");  
    qtmux->streamable = TRUE;  
    g_object_notify (G_OBJECT (qtmux), "streamable");  

======

However it missed to update the qtmux->mux_mode to GST_QT_MUX_MODE_FRAGMENTED_STREAMABLE from GST_QT_MUX_MODE_FRAGMENTED after setting qtmux->streamable = TRUE

As we are not in GST_QT_MUX_MODE_FRAGMENTED_STREAMABLE which is needed to prevent the "seek" described above, we hit the issue.

A potential fix tested in our case is attached (screenshot of the change).

Please let us know if you need any more information regarding this bug.

Thanks,

Song

Attachment 349593, "attachment showing a potential fix (in function gst_qt_mux_start_file(...) under .../gst/isomp4/gstqtmux.c":

Version: 1.8.3