changing title. The problem is with ALL iso-based muxers (mov, 3gp, 3g2, mp4, m4a, 3j2, psp) since they all share the same code (libavformat/movenc.c)

Please check the thread on the gst-devel mailing list with the thread titles:

"[gst-devel] ffmux_mp4 (gst-ffmpeg-0.10.1.1 CVS version) not correctly muxing AAC file to MP4"

Also, check bug #371939 which seems to be the same thing.

ffmpeg movenc only supports packets with a fixed duration.
It does not respect timestamps on incomming packets so the input data needs to be a perfect stream.

The following line sortof works:

gst-launch audiotestsrc num-buffers=100 ! lame ! mp3parse ! ffmux_mp4 ! filesink location=test.mp4

For aac, we don't have a parser.

Created attachment 78138 [details] [review]
cleanups and duration fixes

This patch fixes the duration in muxed files by setting the frame size to a sensible value based on the total duration and number of frames received.

This still doesn't fix it.

The problem seems to be that mov_write_moov_tag (called by _write_trailer()) doesn't compute the SampleDuration for each track based on the frame size, it assumes that frame_size never changed :(

So the choice is now :
_ Either figure out the total duration of the file right at the beginning (contained in newsegment), so we can give the proper value for ->frame_size (kind of hacky).
_ Modify libavformat/movenc.c so that it recomputes the SampleDuration before writing the headers in _write_trailer().

Example pipeline where the behaviour is still broken (mpeg4/mp3 in .mp4):

gst-launch-0.10 filesrc location=/data/multimedia/matrix.ogg ! decodebin name=dbin ! queue name=vinq ! videoscale ! video/x-raw-yuv,width=128,height=96 ! ffenc_mpeg4 ! queue name=voutq ! ffmux_mp4 name=mux ! filesink location=matrix.mp4 dbin. ! queue name=ainq ! audioconvert ! audioresample ! audiorate ! lame ! queue name=aoutq ! mux.

by the way, you will only see the error if you have another stream apart from the audio stream. Else it works (like with audiotestsrc ! lame ! ffmux_mp4).

Like I said: ffmpeg movenc only supports packets with a fixed duration. If you give it the right fixed duration (with a parser) it works, if you don't (like in your example) it does not.

Created attachment 103123 [details] [review]
Patch for gstffmpegmux.c revision 1.48

Patch 'migrated' to revision 1.48 :
- some indentations are probably wrong. 
- compilation / runtime wroks but as it did before.... May be this patch will help someone.

pileline used to check :
gst-launch videotestsrc num-buffers=100 ! video/x-raw-yuv, framerate=\(fraction\)8/1, width=176, height=144 ! ffenc_h263p bitrate=36000 rtp-payload-size=1400 !  ffmux_mov audiotestsrc num-buffers=100 samplesperbuffer=160 ! amrnbenc ! identity sync=true ! ffmux_mov0. ffmux_mov0. ! filesink location=/tmp/lglayal.3gp


Resulting file properties :
[lglayal@tuxy mpeg4ip-1.5.0.1]$ ./lib/mp4v2/util/mp4info /tmp/lglayal.3gp
/home/lglayal/TMP/mpeg4ip-1.5.0.1/lib/mp4v2/util/.libs/lt-mp4info version 1.5.0.1
/tmp/lglayal.3gp:
Track   Type    Info
1       video   H263, 15637.375 secs, 0 kbps, 0x0 @ 0.006395 fps
2       audio   AMR, 4.480 secs, 6 kbps, 8000 Hz


Durations, like rate, size, fps are wrong.

Created attachment 103124 [details] [review]
Patch to release 1.48 of gstffmpegmux.c

correct regression about 'opended' variable.

The generated file does not seem to be usable with the following pipeline :

GST_DEBUG=3 gst-launch filesrc location=/tmp/lglayal.3gp ! decodebin ! fakesink 2>&1 | egrep "audio_|video_" | grep adding
0:00:00.224855000 28223 0x8152ab0 INFO      GST_ELEMENT_PADS gstelement.c:632:gst_element_add_pad:<qtdemux0> adding pad 'video_00'


Only a video pad is detected, on a correct file both pads, audio and video, are created.

Hi Laurent, regarding my promise to get this patch merged yesterday I need to break it. After a new discussion between myself, edward and wim we decided to that merging the patch before the ffmuxer problems are actually solved would be a bad idea. Going from broken to different broken doesn't really get us anywhere, and I assume the improvements which the patch currently bring doesn't really help you either. If you are interested in working on getting this up and running properly that would of course be great.

That's okay, unfortunately  i won't have time to work on it in the next months,... sorry :(

Due to updates in ffmpeg and fixes in gstffmpegmux (see also bug #371939 and bug #541408), it appears this problem no longer applies and ffmux_mov & co produce working mov/mp4 files with proper properties according to qtinfo/mp4info (at least so for ffenc_mpeg4/x264/lame/faac etc).