1. 14 May, 2016 2 commits
  2. 07 May, 2016 1 commit
  3. 06 May, 2016 3 commits
  4. 03 May, 2016 2 commits
  5. 30 Apr, 2016 3 commits
  6. 29 Apr, 2016 1 commit
  7. 28 Apr, 2016 3 commits
  8. 25 Apr, 2016 1 commit
  9. 22 Apr, 2016 1 commit
  10. 14 Apr, 2016 1 commit
  11. 13 Apr, 2016 3 commits
  12. 10 Apr, 2016 1 commit
  13. 09 Apr, 2016 2 commits
  14. 05 Apr, 2016 1 commit
  15. 04 Apr, 2016 2 commits
  16. 30 Mar, 2016 1 commit
  17. 24 Mar, 2016 3 commits
  18. 15 Mar, 2016 1 commit
  19. 11 Mar, 2016 3 commits
  20. 09 Mar, 2016 1 commit
  21. 01 Mar, 2016 1 commit
  22. 26 Feb, 2016 3 commits
    • Sjors Gielen's avatar
      nle: Set the NleOperation flags to NLE_OBJECT_OPERATION · c247c911
      Sjors Gielen authored
      Reviewed By: thiblahute
      
      Differential Revision: https://phabricator.freedesktop.org/D770
      c247c911
    • Thibault Saunier's avatar
    • Sjors Gielen's avatar
      Handle changing playback rate · 84f7f04a
      Sjors Gielen authored
      Before this patch, NLE and GES did not support NleOperations (respectively
      GESEffects) that changed the speed/tempo/rate at which the source plays. For
      example, the 'pitch' element can make audio play faster or slower. In GES 1.5.90
      and before, an NleOperation containing the pitch element to change the rate (or
      tempo) would cause a pipeline state change to PAUSED after that stack; that has
      been fixed in 1.5.91 (see #755012 [0]). But even then, in 1.5.91 and later,
      NleComposition would send segment events to its NleSources assuming that one
      source second is equal to one pipeline second. The resulting early EOS event
      (in the case of a source rate higher than 1.0) would cause it to switch stacks
      too early, causing confusion in the timeline and spectacularly messed up
      output.
      
      This patch fixes that by searching for rate-changing elements in
      GESTrackElements such as GESEffects. If such rate-changing elements are found,
      their final effect on the playing rate is stored in the corresponding NleObject
      as the 'media duration factor', named like this because the 'media duration',
      or source duration, of an NleObject can be computed by multiplying the duration
      with the media duration factor of that object and its parents (this is called
      the 'recursive media duration factor'). For example, a 4-second NleSource with
      an NleOperation with a media duration factor of 2.0 will have an 8-second media
      duration, which means that for playing 4 seconds in the pipeline, the seek
      event sent to it must span 8 seconds of media. (So, the 'duration' of an
      NleObject or GES object always refers to its duration in the timeline, not the
      media duration.)
      
      To summarize:
      
      * Rate-changing elements are registered in the GESEffectClass (pitch::tempo and
        pitch::rate are registered by default);
      * GESTimelineElement is responsible for detecting rate-changing elements and
        computing the media_duration_factor;
      * GESTrackElement is responsible for storing the media_duration_factor in
        NleObject;
      * NleComposition is responsible for the recursive_media_duration_factor;
      * The latter property finally fixes media time computations in NleObject.
      
      NLE and GES tests are included.
      
      [0] https://bugzilla.gnome.org/show_bug.cgi?id=755012
      
      Differential Revision: https://phabricator.freedesktop.org/D276
      84f7f04a