GNOME Bugzilla – Bug 637486
qtmux: error if no buffers have arrived to one pad at EOS
Last modified: 2011-09-19 09:24:25 UTC
Created attachment 176608 [details] [review] Proposed patch that ignores the error. Mp4mux considers receiving end-of-stream event to a sink pad without any buffers as an error. However if there are other sink pads that have received data then should one zero duration track be allowed in this case? This might happen when dealing with live sources and stopping the pipeline very quickly. Example pipeline that results in similar error: gst-launch audiotestsrc num-buffers=0 is-live=1 ! faac ! mp4mux name=mux ! filesink location=video.mp4 videotestsrc num-buffers=50 is-live=1 ! ffenc_mpeg4 ! mux. ... ERROR: from element /GstPipeline:pipeline0/GstMP4Mux:mux: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstqtmux.c(2192): gst_qt_mux_add_buffer (): /GstPipeline:pipeline0/GstMP4Mux:mux: format wasn't negotiated before buffer flow on pad audio_00
commit 699e0abd492be2c740e75b3ff569aa84d35e03a7 Author: Lasse Laukkanen <lasse.laukkanen@digia.com> Date: Fri Dec 17 19:41:25 2010 +0200 qtmux: allow zero duration tracks
It looks this bug is alive again in plugins-good mp4mux, so reopening
Created attachment 196723 [details] [review] Proposed patch Proposing a new patch to fix this.
In future, please keep the old bug intact as it is including modules and versions etc., and instead clone the old bug.
With the patch applied, does this still make sense then? if (!GST_CLOCK_TIME_IS_VALID (qtpad->first_ts)) { GST_DEBUG_OBJECT (qtmux, "Pad %s has no buffers", GST_PAD_NAME (qtpad->collect.pad)); continue; } Or maybe it should just be moved before _add_buffer()?
(In reply to comment #5) > With the patch applied, does this still make sense then? > > if (!GST_CLOCK_TIME_IS_VALID (qtpad->first_ts)) { > GST_DEBUG_OBJECT (qtmux, "Pad %s has no buffers", > GST_PAD_NAME (qtpad->collect.pad)); > continue; > } > > Or maybe it should just be moved before _add_buffer()? Moving this before _add_buffer() fixes the problem too. However it looks it might affect corner case fixed by earlier commit: http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=4df05e76ed5133482b0e1c57c63ef71ca31539ee Adding Mark to cc.
Ah yes, qtmux is becoming quite a "bag of tricks" there with all that timestamp juggling. That fragment can't be moved before add_buffer if only a few buffers ever entered, in which case they are queued internally, which would have to be flushed first be add_buffer before checking for buffers. It might possible be a bit redundant afterwards with this additional check, but some extra checking likely does not hurt ... So committed proposed fix along with some additional commenting. commit 056e9188b13644aa1ed81216860c290f6e8ab864 Author: Lasse Laukkanen <lasse.laukkanen@digia.com> Date: Fri Sep 16 16:53:22 2011 +0300 isomp4: Fix allowing zero duration tracks https://bugzilla.gnome.org/show_bug.cgi?id=637486