• Alicia Boya García's avatar
    qtmux: round to nearest when computing mehd and tkhd duration · 5fcb7f71
    Alicia Boya García authored
    This fixes a bug where in some files mehd.fragment_duration is one unit
    less than the actual duration of the fragmented movie, as explained below:
    
    mehd.fragment_duration is computed by scaling the end timestamp of
    the last frame of the movie in (in nanoseconds) by the movie timescale.
    
    In some situations, the end timestamp is innacurate due to lossy conversion to
    fixed point required by GstBuffer upstream.
    
    Take for instance a movie with 3 frames at exactly 3 fps.
    
    $ gst-launch-1.0 -v videotestsrc num-buffers=3 \
      ! video/x-raw, framerate="(fraction)3/1" \
      ! x264enc \
      ! fakesink silent=false
    
    dts: 999:59:59.333333334,  pts: 1000:00:00.000000000, duration: 0:00:00.333333333
    dts: 999:59:59.666666667,  pts: 1000:00:00.666666666, duration: 0:00:00.333333334
    dts: 1000:00:00.000000000, pts: 1000:00:00.333333333, duration: 0:00:00.333333333
    
    The end timestamp is calculated by qtmux in this way:
    
    end timestamp = last frame DTS + last frame DUR - first frame DTS =
      = 1000:00:00.000000000 + 0:00:00.333333333 - 999:59:59.333333334 =
      = 0:00:00.999999999
    
    qtmux needs to round this timestamp to the declared movie timescale, which can
    ameliorate this distortion, but it's important that round-neareast is used;
    otherwise it would backfire badly.
    
    Take for example a movie with a timescale of 30 units/s.
    
    0.999999999 s * 30 units/s = 29.999999970 units
    
    A round-floor (as it was done before this patch) would set fragment_duration to
    29 units, amplifying the original distorsion from 1 nanosecond up to 33
    milliseconds less than the correct value. The greatest distortion would occur
    in the case where timescale = framerate, where an entire frame duration would
    be subtracted.
    
    Also, rounding is added to tkhd duration computation too, which
    potentially has the same problem.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=793959
    5fcb7f71
atoms.c 143 KB