[gstreamer-bugs] [Bug 541408] New: gstffmpegmux + movenc : last buffer duration unit mismatch ?

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=541408

  GStreamer | gst-ffmpeg | Ver: HEAD CVS
           Summary: gstffmpegmux + movenc : last buffer duration unit
                    mismatch ?
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-ffmpeg
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: gstelzz at yahoo.fr
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=541408.