1. 27 Apr, 2015 4 commits
  2. 26 Apr, 2015 15 commits
  3. 25 Apr, 2015 6 commits
  4. 24 Apr, 2015 10 commits
    • Thiago Santos's avatar
      tests: camerabin: add tests for GstPhotography image capture · dd2dba63
      Thiago Santos authored
      GstPhotography enables new paths in wrappercamerabinsrc that allows
      the source to be notified about the capture caps and provide an
      alternative caps if desired bypassing the negotiation (this doesn't
      seem like a good idea these days). To make sure it keeps working
      until we remove it from the API in favor of standard caps negotiation
      features this test was added.
      It adds 3 extra tests with a simple test source that will:
      1) Test that capturing with ANY caps work
      2) Test that capturing with a fixed caps work
      3) Test that capturing with a fixed caps and having the source
         pick a different resolution from GstPhotography API works
         by having wrappercamerabinsrc crop the capture to the final
         requested dimensions
    • Thiago Santos's avatar
      wrappercamerabinsrc: Rework cropping for zoom and dimension reduction · c6f4e4cf
      Thiago Santos authored
      wrappercamerabinsrc has a videocrop element to be used for
      zooming and for cropping when input caps is different when used
      with the GstPhotography interface. The zooming part needs
      the following elements:
      capsfilter ! videocrop ! videoscale ! capsfilter
      The capsfilters should always have the same caps to ensure the
      zooming is done and preserves dimensions, unless when it is needed
      to do more cropping due to input dimensions those caps
      need to be modified accordingly to preserve the output dimensions.
      This, however, makes it hard to get caps negotiation to work properly
      as we need to have different caps in the capsfilters to account for
      the extra cropping needed. It could be simple for fixed caps but it
      gets tricky with unfixed ones.
      To solve this, this patch splits the zooming and dimension reduction
      cropping into 2 separate videocrop elements. The first one does
      the dimension cropping, which is only needed when the GstPhotography
      API is used and the source provides a caps that is different than
      what is requested, while the second is dedicated to zoom crop only.
      The first part of the pipeline goes from:
      src ! videoconvert ! capsfilter ! videocrop ! videoscale ! capsfilter
      src ! videocrop ! videoconvert ! capsfilter ! videocrop ! videoscale ! capsfilter
      It might add an extra overhead in the image capture as the image might need
      to be cropped twice but this can be solved by enabling videocrop to use
      crop metas so only the later one does the real cropping.
      It also makes the code a bit simpler.
    • Thiago Santos's avatar
      wrappercamerabinsrc: remove obsolete comment · 524e536a
      Thiago Santos authored
      This is already handled in another place and doesn't make sense
      in the function context anymore
    • Thiago Santos's avatar
      wrappercamerabinsrc: error out if source fails to prepare for capture · 7b834cb0
      Thiago Santos authored
      Post an error when preparing the image capture through photography
      interface fails
    • Thiago Santos's avatar
      wrappercamerabinsrc: intersect instead of compare for equality · 0c04f2f0
      Thiago Santos authored
      Intersect is enough to check if the requested caps are compatible
      with what the source is going to provide. Equality will be too strict.
    • Thiago Santos's avatar
      wrappercamerabinsrc: fix typo · af1dda2e
      Thiago Santos authored
    • Thiago Santos's avatar
      camerabin: tests: remove unused macros · de5f0dd2
      Thiago Santos authored
      Those macros were with the wrong name (likely a copy n paste mistake)
      and were unused.
    • Thiago Santos's avatar
    • Luis de Bethencourt's avatar
      remove unused enum items PROP_LAST · c944093d
      Luis de Bethencourt authored
      This were probably added to the enums due to cargo cult programming and are
    • Matthew Waters's avatar
      glimagesink: balance change_state display ref/unref · b2166299
      Matthew Waters authored
      the display was being unreffed on the incorrect state change causing
      invalid state when changing from PLAYING/PAUSED->READY->PAUSED/PLAYING.
  5. 23 Apr, 2015 5 commits
    • Sebastian Dröge's avatar
      adaptivedemux: Don't claim to be live when answering the LATENCY query · 6c8eeb44
      Sebastian Dröge authored
      Even for "live" streams we are not live in the GStreamer meaning of the word.
      We don't produce buffers that are timestamped based on their "capture time"
      and our clock, but just based on whatever timestamps the stream might contain.
      Also even if we wanted to claim to be live, that wouldn't work well as we
      would have to return GST_STATE_CHANGE_NO_PREROLL when going from READY to
      PAUSED, which we can't. We first need data to know if we are "live" or not.
    • Sebastian Dröge's avatar
      hlsdemux: Use the downloader of the base class instead of creating our own · 7c2a5da1
      Sebastian Dröge authored
      The one of the base class is completely unused because we override all
      the downloading here, so let's just use that one instead.
    • Sebastian Dröge's avatar
      hlsdemux: Don't error out if we can't match variant playlists after updating · 5fd2fc30
      Sebastian Dröge authored
      It's better to just select some random variant playlist instead of stopping,
      chances are that it's still continuing to work and we might just have to
      select a different variant again later.
    • Sebastian Dröge's avatar
      hlsdemux: Fix how the playlists are refreshed · bb36ffb6
      Sebastian Dröge authored
      We should only refresh the currently selected variant playlist (if any,
      otherwise the main playlist), not the main playlist. And only try to
      refresh the main playlist if updating the variant playlist fails.
      Some servers (Wowza) use the request of the main playlist to create a
      "session", which is then part of the URI of the variant playlist and
      also the fragments. Refreshing the main playlist would generate a new
      session, and the server rate limits that usually. And after a few retries
      the server just kicks us out.
      Also as a side effect we now use the same downloader for all playlists, so
      that we only have 2 instead of 3 connections to the server. And also
      previously we just ignored the downloaded data from the main playlist that
      the base class gave to us.
    • Sebastian Dröge's avatar