Skip to content
GitLab
  1. 13 Dec, 2012 1 commit
  3. 12 Dec, 2012 3 commits
  5. 10 Dec, 2012 4 commits
  7. 09 Dec, 2012 1 commit
  9. 05 Dec, 2012 3 commits
    • Thibault Saunier's avatar
      tests: encodebin: Properly rename new preset test · 12aef5f4
      Thibault Saunier authored
      12aef5f4
    • Thibault Saunier's avatar
      encodebin: Make use of the new preset_name when setting a preset · 7358cba0
      Thibault Saunier authored 
      The behaviour is sensibly changed here. Instead of purely falling when a
preset is set on the #GstEncodingProfile, we now make sure that the
element that is plugged corresponds to the one specified as preset. Then,
if we have a preset_name, we use it, if it fails, we fail (we might rather
just keep working even without setting the element properties?)

 + Add tests that it behave correctly
      7358cba0
    • Thibault Saunier's avatar
      encoding-profile: Let the user decide what preset name to use · 6a7f6889
      Thibault Saunier authored 
      It was possible to decide only what #GstElement implementing #GstPreset
to use during the encoding, we can now let the user select a specific preset previously
saved using #gst_preset_save_preset specifying the name chosen when it was saved
in the gst_encoding_profile_set_preset_name.

Actually loading a preset with %NULL as a name would have always failed, so
in the current state of the API that feature is unusable

API:
  gst_encoding_profile_set_preset_name
  gst_encoding_profile_get_preset_name
      6a7f6889
  11. 04 Dec, 2012 1 commit
  13. 02 Dec, 2012 2 commits
  15. 30 Nov, 2012 1 commit
  17. 29 Nov, 2012 1 commit
  19. 28 Nov, 2012 1 commit
    • Edward Hervey's avatar
      configure.ac: Update libtool versioning · 8edd1443
      Edward Hervey authored 
      In order for 1.x and 1.(x+1) versions to not invade on each other
we need to have different lib versions.

So we need a consistent and predictable scheme:
   library version number = MINOR * 100 + MICRO

Ex:
  1.0.0 => 0 (duh)
  1.0.3 => 3
  1.1.0 => 100
  1.1.1 => 101
  1.2.0 => 120
  1.10.5 => 1005
      8edd1443
  21. 27 Nov, 2012 2 commits
  23. 26 Nov, 2012 1 commit
    • Tim-Philipp Müller's avatar
      streamsynchronizer: don't send gap events with huge bogus durations when advancing EOS streams · 7c89a729
      Tim-Philipp Müller authored 
      When the input buffers for a stream don't have a duration set,
timestamp_end might still be GST_CLOCK_TIME_NONE. When advancing
EOSed streams via GAP events (with other streams not yet EOS), we
would then use the invalid timestamp_end to calculate the duration
of the gap. This in turn would make baseaudiosink abort, because it
would try to allocate memory for a trizillion samples.

So if buffers don't have a duration set, assume a duration of
one second for stream catch-up purposes, just so we can still
continue to catch up in those cases. And make sure that
timestamp_end is valid before doing calculations with it.

http://bugzilla.gnome.org/show_bug.cgi?id=678530
      7c89a729
  25. 25 Nov, 2012 1 commit
  27. 23 Nov, 2012 2 commits
  29. 22 Nov, 2012 2 commits
  31. 21 Nov, 2012 11 commits
  33. 20 Nov, 2012 3 commits