I am recording RTP stream (h264 / AMR) to a mov file using ffmux_mov.
AMR is rate 8000 Hz.

When reading the file, buffers are timestamped correctly and each one have a duration of 20 ms, except the last one which have a duration of 2.5 sec.

movenc.c : mov_write_stts_tag : the duration for each entry is based on next entry (dts(i+1) - dts(i)), except the last one which involves total track duration (trackduraion - dts(i) + dts(0))
I think there is a problem with the units dts and trackduration 

gstffmpegmux.c : gst_ffmpegmux_collected : it computes pkt.dts and pkt.duration as following :
    * pkt.dts = gst_ffmpeg_time_gst_to_ff(GST_BUFFER_TIMESTAMP(buffer), time_base).
    Duration for movenc will though be 160 : which is the number of samples for 20 ms at 8000Hz

    * pkt.duration = gst_util_..scale_int(GST_BUFFER_DURATION(buffer), AV_TIME_BASE, GST_SECOND) which leads to a duration expressed in seconds. (20 ms here)

Therefore, in movenc.c, computing trackDuration by adding pkt.duration and pkt.dts is weird ! samples + seconds !

This leads to a last packet duration of 20000 (ms) instead of 160 (samples), and when file is played with qtdemux, the last buffer has a duration of 2.5 seconds : 20000 / 8000 .... The other ones has the righet duration : 20 ms which is 160/8000

I think there is a correction to do in gstffmpegmux.c to express pkt.duration in samples instead of seconds, or pkt.dts in second instead of samples.
But oggenc or matroskaenc are also adding pts and duration.

What do you think, what is wrong ?

in gstffmpegmux.c 1.31 there was pts = GST_BUFFER_TIMESTAMP(buf) * AV_TIMEBASE / GST_SECOND. 
in 1.32 it changed in av_rescale_q(GST_BUFFER_TIMESTAMP(buf),bq, ffmpegmux...->time_base), ecpressing pts in timebase instead of time.