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

[Edward Hervey]

Hi,

On 11/4/06, Deeptendu Bikash <dbikash at gmail.com> wrote:
> Hello,
>
> I am using the latest CVS version of gst-ffmpeg to mux raw AAC files into
> MP4 format, but there seems to be some problem with the duration.
>
> gst-launch filesrc location=... ! audio/mpeg, rate=\(int\)8000,
> channels=\(int\)2, mpegversion=\(int\)4 ! ffmux_mp4 ! filesink location=...
>
> The resulting file has the MP4 file format but has a huge duration (8000
> hours etc) and a zero bitrate. And of course, no player, including VLC,
> could play it. Any suggestions on how to fix this?

  There are several issues at hand. What ffmpeg does, for a start, is
utterly wrong:
  in libavformat/movenc.c (the code used by quicktime/mp4/iso muxing),
the duration for a track is calculated using:
   mov->tracks[i].trackDuration = 	
	             (int64_t)mov->tracks[i].sampleCount *
mov->tracks[i].sampleDuration;
  The sampleCount is the number of samples for that track, and
sampleDuration is computed using:
  track->sampleDuration = st->codec->frame_size;
  All of this is done when writing the headers of the file, after
having received EOS. The problem is that the value of
st->codec->frame_size is only calculated when receiving the first
buffer (code you pasted below).... which doesn't mean anything
(nothing guarantees that all the following buffers will have the same
duration). In fact there's a VERY good chance that the first buffer
will last longer than the following ones. Resulting in a computed
duration which is way too big.

  The main problem, therefore, is that we need to give ffmpeg a
combination of st->codec->frame_size and st->codec->sample_rate in
such a way that:
  total_duration = frame_size * sample_rate * GST_SECOND.

  The fix I'm thinking about implementing is to, when we receive EOS
and before writing the headers, compute the proper frame_size
according to the real duration (which we know in GStreamer) as such :
  frame_size = RealDuration / (sample_rate * GST_SECOND).

  Unfortunately I currently don't have time to implement it right now
(apart from creating a crude hack, doing it properly requires
implementing GstSegment support in GstFFMpegMux so we get the REAL
duration). Anyone up to the job can follow these ideas if I still
haven't implmented it.

  Looking back on previous versions of both the ffmpeg and gst-ffmpeg
code, this has always been broken (resulting in completely broken
durations). The funniest part is that it plays fine in mplayer (using
ffmpeg of course). In fact all the files I tried to create using the
ffmpeg mov/mp4/iso muxers have broken duration with gstreamer qtdemux
and Quicktime Player... but give correct duration with... ffmpeg :(

>
> Looking at the code (gstffmpegmux.c), the portion that sets the framerate
> for audio, looks to incomplete/incorrect. There is a comment saying that
> this might not work for any kind of audio.
>
>     buffer=gst_collect_pads_peek(ffmpegmux->collect,
> (GstCollectData *)collect_pad);
>     if(buffer){
>         st->codec->frame_size = st->codec->sample_rate *
> GST_BUFFER_DURATION(buffer)/GST_SECOND;
>         gst_buffer_unref(buffer);
>     }
>
> When I print the values of st->codec->frame_size, st->codec->sample_rate and
> GST_BUFFER_DURATION(buffer)/GST_SECOND, I get the values
> 1266874889, 8000 and 1266874889. Evidently, the buffer duration is wrong.
> How can I correct it?
>
> Can anybody help with this much of info?

  I pasted all this mail to a bug so we can track this issue :

   http://bugzilla.gnome.org/show_bug.cgi?id=371939


    Edward

>
> Regards,
> Deeptendu
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>


-- 
Edward Hervey
Multimedia editing developer / Fluendo S.A.
http://www.pitivi.org/