Use the -e parameter on gst-launch to properly shut down the pipeline. Without that the headers of the MP4 file will not be rewritten and are broken.

In your own application you would implement the same by first sending on EOS event to the pipeline, then waiting for the EOS message from the pipeline... and only then shut down the pipeline (i.e. set it to READY or NULL state).

(In reply to comment #1)
> Use the -e parameter on gst-launch to properly shut down the pipeline. Without
> that the headers of the MP4 file will not be rewritten and are broken.

I'm confused by this as the file created by gst-launch was not broken and played fine.

> In your own application you would implement the same by first sending on EOS
> event to the pipeline, then waiting for the EOS message from the pipeline...
> and only then shut down the pipeline (i.e. set it to READY or NULL state).

Thanks, I'll have a look, I thought we got an EOS message at the end of each track which we listen for to shut down the pipeline but I need to check exactly what's happening there.

(In reply to comment #2)
> > In your own application you would implement the same by first sending on EOS
> > event to the pipeline, then waiting for the EOS message from the pipeline...
> > and only then shut down the pipeline (i.e. set it to READY or NULL state).
> 
> Thanks, I'll have a look, I thought we got an EOS message at the end of each
> track which we listen for to shut down the pipeline but I need to check exactly
> what's happening there.

At the moment sound-juicer does
  priv->pipeline = gst_pipeline_new ("pipeline");
  bus = gst_element_get_bus (priv->pipeline);
  gst_bus_add_signal_watch (bus);
  g_signal_connect (bus, "message::eos", G_CALLBACK (eos_cb), extractor);
/* create pipeline elelments, add them to the pipeline and link them */
  state_ret = gst_element_set_state (priv->pipeline, GST_STATE_PLAYING);

in eos_cb it does
  gst_element_set_state (priv->pipeline, GST_STATE_NULL);

So it sets the pipeline to GST_STATE_PLAYING and waits for the eos message at the end of the track and then sets the pipeline state to GST_STATE_NULL. I'm not sure what should it be doing differently as it only sets the pipeline to GST_STATE_NULL when it gets an eos message so surely the pipeline should shut down properly and the MP4 file headers written?

Can you provide the encodebin profile. Notice this:

0:00:19.077658053 27666 0x7f8670004cf0 WARN                   qtmux gstqtmux.c:1649:gst_qt_mux_start_file:<muxer> downstream did not handle seeking query
0:00:19.077709467 27666 0x7f8670004cf0 WARN                   qtmux gstqtmux.c:1658:gst_qt_mux_start_file:<muxer> warning: Downstream is not seekable and headers can't be rewritten

Also notice that sound-juicer uses giosink, not filesink. Can you test case (need to write it in C or Python) a muxing pipeline with giosink. Might be where the problem is. I'm not familiar with seeking a sink, but I think that's what mp4mux. For mp4 we put the header and index at the start, hence we need to seek back in the file at EOS, and prepend that data. It is likely that giosink is missing this feature. But I'm pretty much guessing at the moment.

(In reply to comment #4)
> Can you provide the encodebin profile.

[profile-m4a]
name = m4a
description = MPEG 4 Audio
format = video/quicktime, variant=iso
type = container

[streamprofile-m4a-1]
parent = m4a
type = audio
format = audio/mpeg, mpegversion=4, stream-format=raw
presence = 1


> Notice this:
> 
> 0:00:19.077658053 27666 0x7f8670004cf0 WARN                   qtmux
> gstqtmux.c:1649:gst_qt_mux_start_file:<muxer> downstream did not handle seeking
> query
> 0:00:19.077709467 27666 0x7f8670004cf0 WARN                   qtmux
> gstqtmux.c:1658:gst_qt_mux_start_file:<muxer> warning: Downstream is not
> seekable and headers can't be rewritten
> 
> Also notice that sound-juicer uses giosink, not filesink. Can you test case
> (need to write it in C or Python) a muxing pipeline with giosink. Might be
> where the problem is. I'm not familiar with seeking a sink, but I think that's
> what mp4mux. For mp4 we put the header and index at the start, hence we need to
> seek back in the file at EOS, and prepend that data. It is likely that giosink
> is missing this feature. But I'm pretty much guessing at the moment.

Thanks, I think you're right. I just changed the sound-juicer pipeline to use faac ! mp4mux instead of encodebin and I get the same error so it looks like giosink is the problem. For mp3 encoding xingmux manages to put the Xing header at the front of the file with giosink though.

Note, GstGioBaseSink do support seeking, so there might be another bug.

This was fixed already some time ago, it also caused problems for gnome-sound-recorder. The fix will be in 1.4.

commit e8d176c20c6bbde070701bf029913a4fa930e51f
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Fri Apr 25 17:32:59 2014 +0200

    giobasesink: Implement handling of the SEEKING query

As there is no related bug.