After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 637486 - qtmux: error if no buffers have arrived to one pad at EOS
qtmux: error if no buffers have arrived to one pad at EOS
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 0.10.21
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-12-17 18:05 UTC by Lasse Laukkanen
Modified: 2011-09-19 09:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch that ignores the error. (921 bytes, patch)
2010-12-17 18:05 UTC, Lasse Laukkanen
committed Details | Review
Proposed patch (1.45 KB, patch)
2011-09-16 14:17 UTC, Lasse Laukkanen
committed Details | Review

Description Lasse Laukkanen 2010-12-17 18:05:11 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
Comment 1 Sebastian Dröge (slomo) 2010-12-17 18:30:39 UTC
commit 699e0abd492be2c740e75b3ff569aa84d35e03a7
Author: Lasse Laukkanen <lasse.laukkanen@digia.com>
Date:   Fri Dec 17 19:41:25 2010 +0200

    qtmux: allow zero duration tracks
Comment 2 Lasse Laukkanen 2011-09-16 14:14:47 UTC
It looks this bug is alive again in plugins-good mp4mux, so reopening
Comment 3 Lasse Laukkanen 2011-09-16 14:17:31 UTC
Created attachment 196723 [details] [review]
Proposed patch

Proposing a new patch to fix this.
Comment 4 Tim-Philipp Müller 2011-09-16 14:28:55 UTC
In future, please keep the old bug intact as it is including modules and versions etc., and instead clone the old bug.
Comment 5 Tim-Philipp Müller 2011-09-16 18:44:57 UTC
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()?
Comment 6 Lasse Laukkanen 2011-09-19 08:27:50 UTC
(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.
Comment 7 Mark Nauwelaerts 2011-09-19 09:24:08 UTC
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