#211 Last frame of media clip gets chopped off on 24fps media

head
closed
nobody
None
5
2014-05-12
2014-05-08
No

Hi!
I posted on the forum, but after doing some more digging I'm more and more convinced this is a bug.

mlt chops off the last frame of a clip @24fps. I think it has to do with not rounding decimals up on the conversion from milliseconds to frames. On 25fps material everything works just fine.
I noticed because I'm trying to create a play-out application for a work in progress film using daily renders of the shots. All Shots are rendered out in exact length so when they all come out one frame short in mlt everything gets offset and more and more wrong.

Here is an example of how I came to my conclusion:

I know my material is 188 frames long
Frame rate: 24
Duration from ffprobe: 00:00:07.83

1 frame in milliseconds = 1 / 24 = 0.041666667
188 * 0.041666667 = 7.833333396 (which confirms ffprobe's duration)

If we break the duration in frames down like this:
7 * 24 = 168
0.83 / 0.041666667 = 19.919999841

this gives us duration of:
168 + 19 = 187

Where does the 0.919999841 go?
Shouldn't there be a rounding upwards here?

Thanks,
-Daniel

Related

Bugs: #211

Discussion

  • Dan Dennedy
    Dan Dennedy
    2014-05-08

    We have received a number of bug reports in this area with most people complaining that there are too many frames. Internally, MLT uses frame units and frame counts - not time. It gets the duration from libavformat:
    https://github.com/mltframework/mlt/blob/master/src/modules/avformat/producer_avformat.c#L603

    As you can see, there is no rounding. This is probably intentional due to the number of complaints about too many frames. Feel free to experiment, make a change as you need, but any change here is going to require a lot of testing against many samples.

     
  • Thanks for the reply. I'm no C++ expert but will take a look.
    Any Ideas on why there's a difference in 24 vs 25 fps?

     
  • Dan Dennedy
    Dan Dennedy
    2014-05-08

    How do you know MLT's determination of the #frames? Depending upon the format, it is not reliable by rendering/encoding to a file and then inspecting the file. After all, this could be a bug running to full length or in the output. Run "melt inputfile -consumer xml" and look at the length property in the xml output to see exactly what MLT determines for the input.

    Are you compiling MLT yourself? If so, edit the source code file I mentioned, and insert '+ 0.5' before the last ')' to do a form of rounding. If not, as a workaround, you can override duration by setting properties:
    melt inputfile length=188 out=187 ...
    You must also set the out point, which is 0-based. Otherwise, it is based on the computed length - 1, which will otherwise be 186.

     
    • I get the shot length from an external database.
      When I run "melt infile -consumer xml" I get a length of 187 as suspected.

      The command line trick with length=188 and out=188 works! Unfortunately I can't get the same result in my XML. (Realize I should have mentioned this earlier.. I'm creating and plying back an XML/mlt)

      I'm not able to get the same result through xml playback when providing the length attribute. Is there a special way to achieve the same in an xml?

      I will look into changing the source code while I wait for a response.

       
      • Dan Dennedy
        Dan Dennedy
        2014-05-09

        Overriding the length does work through XML as well. Maybe you did not update other time-related attributes on producer element or other elements that contain or use the producer.

         
        • I was successful in updating the length, but it only repeats the "last"
          frame.

          -Daniel
          On May 9, 2014 6:25 PM, "Dan Dennedy" ddennedy@users.sf.net wrote:

          Overriding the length does work through XML as well. Maybe you did not
          update other time-related attributes on producer element or other elements
          that contain or use the producer.


          Status: open
          Group: head
          Created: Thu May 08, 2014 10:59 AM UTC by Daniel Flehner Heen
          Last Updated: Fri May 09, 2014 09:10 AM UTC
          Owner: nobody

          Hi!
          I posted on the forum, but after doing some more digging I'm more and more
          convinced this is a bug.

          mlt chops off the last frame of a clip @24fps. I think it has to do with
          not rounding decimals up on the conversion from milliseconds to frames. On
          25fps material everything works just fine.
          I noticed because I'm trying to create a play-out application for a work
          in progress film using daily renders of the shots. All Shots are rendered
          out in exact length so when they all come out one frame short in mlt
          everything gets offset and more and more wrong.

          Here is an example of how I came to my conclusion:

          I know my material is 188 frames long
          Frame rate: 24
          Duration from ffprobe: 00:00:07.83

          1 frame in milliseconds = 1 / 24 = 0.041666667
          188 * 0.041666667 = 7.833333396 (which confirms ffprobe's duration)

          If we break the duration in frames down like this:
          7 * 24 = 168
          0.83 / 0.041666667 = 19.919999841

          this gives us duration of:
          168 + 19 = 187

          Where does the 0.919999841 go?
          Shouldn't there be a rounding upwards here?

          Thanks,
          -Daniel


          Sent from sourceforge.net because you indicated interest in
          https://sourceforge.net/p/mlt/bugs/211/

          To unsubscribe from further messages, please visit
          https://sourceforge.net/auth/subscriptions/

           

          Related

          Bugs: #211

  • OK, not sure if I managed to upload files that are linked to this thread, but if you get two files called sample_24fps_photojpeg.mov and sample_25fps_photojpeg.mov they're from me. They are both from the same image sequence and should both be 233 frames long.
    melt infile -consumer xml shows two different lengths.

     
  • Dan Dennedy
    Dan Dennedy
    2014-05-10

    I downloaded the samples, but I am getting 233 frames length for both:
    $ melt -consumer xml sample_24fps_sRGB_photojpeg.mov 2>/dev/null | grep length
    <property name="length">233</property>
    $ melt -consumer xml sample_25fps_sRGB_photojpeg.mov 2>/dev/null | grep length
    <property name="length">233</property>
    The line in producer_avformat.c that I mentioned changed since the last release of MLT. I changed it back to the old formula to see if this was fixed since the last release, and that gave me the same result! That suggests the difference is due to version of libavformat. I am using 55. 37.101 from FFmpeg git master built on April 24.

    I uninstalled my ffmpeg and rebuilt MLT against Ubuntu 12.04 Libav - their libavformat v53.2.0 - and that reproduced the problem. Next, I reverted my local change to the length computation, and it still reproduced the problem. Finally, I made a local change to add rounding to my formula, and that did not improve it either. Your version of libavformat is the problem.

     
    • Wow, this is really good news! I tried compiling a newer version of libav
      with no luck. There might be a difference between it and ffmpeg. (Or I
      pulled an older version then I thought) I'll give it a go compiling against
      ffmpeg.
      Thank you very much for investing so much time into this. I'll let you know
      how it goes.

      -Daniel
      On May 10, 2014 9:15 PM, "Dan Dennedy" ddennedy@users.sf.net wrote:

      I downloaded the samples, but I am getting 233 frames length for both:
      $ melt -consumer xml sample_24fps_sRGB_photojpeg.mov 2>/dev/null | grep
      length
      233
      $ melt -consumer xml sample_25fps_sRGB_photojpeg.mov 2>/dev/null | grep
      length
      233
      The line in producer_avformat.c that I mentioned changed since the last
      release of MLT. I changed it back to the old formula to see if this was
      fixed since the last release, and that gave me the same result! That
      suggests the difference is due to version of libavformat. I am using 55.
      37.101 from FFmpeg git master built on April 24.

      I uninstalled my ffmpeg and rebuilt MLT against Ubuntu 12.04 Libav -
      their libavformat v53.2.0 - and that reproduced the problem. Next, I
      reverted my local change to the length computation, and it still reproduced
      the problem. Finally, I made a local change to add rounding to my formula,
      and that did not improve it either. Your version of libavformat is the
      problem.


      Status: open
      Group: head
      Created: Thu May 08, 2014 10:59 AM UTC by Daniel Flehner Heen
      Last Updated: Fri May 09, 2014 09:10 AM UTC
      Owner: nobody

      Hi!
      I posted on the forum, but after doing some more digging I'm more and more
      convinced this is a bug.

      mlt chops off the last frame of a clip @24fps. I think it has to do with
      not rounding decimals up on the conversion from milliseconds to frames. On
      25fps material everything works just fine.
      I noticed because I'm trying to create a play-out application for a work
      in progress film using daily renders of the shots. All Shots are rendered
      out in exact length so when they all come out one frame short in mlt
      everything gets offset and more and more wrong.

      Here is an example of how I came to my conclusion:

      I know my material is 188 frames long
      Frame rate: 24
      Duration from ffprobe: 00:00:07.83

      1 frame in milliseconds = 1 / 24 = 0.041666667
      188 * 0.041666667 = 7.833333396 (which confirms ffprobe's duration)

      If we break the duration in frames down like this:
      7 * 24 = 168
      0.83 / 0.041666667 = 19.919999841

      this gives us duration of:
      168 + 19 = 187

      Where does the 0.919999841 go?
      Shouldn't there be a rounding upwards here?

      Thanks,
      -Daniel


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/mlt/bugs/211/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #211

      Attachments
  • Dan Dennedy
    Dan Dennedy
    2014-05-10

    • status: open --> closed
     
  • Confirmed! Thanks!