1. 07 Mar, 2016 1 commit
  2. 22 Jan, 2016 2 commits
  3. 21 Jan, 2016 1 commit
    • Wim Taymans's avatar
      v4l2: Add adobe colorspace support · 681bab62
      Wim Taymans authored
      Use the new primaries and transfer function for Adobe RGB.
      Explicitly list the colorimetry instead of using the default GStreamer
      ones. The defaults for BT2020, for example, do not match.
      Explicitly set the matrix of SRGB to RGB.
      681bab62
  4. 19 Jan, 2016 2 commits
  5. 18 Dec, 2015 1 commit
    • Nicolas Dufresne's avatar
      v4l2object: Update formats table · 2538fee2
      Nicolas Dufresne authored
      This change add all the new RGB based format. Those format removes the
      ambiguity with the ALPHA channel. Some other missing multiplanar format
      has been added with some additional cleanup.
      2538fee2
  6. 25 Nov, 2015 1 commit
  7. 15 Nov, 2015 1 commit
  8. 13 Nov, 2015 1 commit
  9. 25 Jul, 2015 1 commit
  10. 29 Jun, 2015 1 commit
  11. 08 Jun, 2015 3 commits
  12. 05 Jun, 2015 1 commit
  13. 22 Apr, 2015 1 commit
  14. 02 Apr, 2015 1 commit
  15. 13 Mar, 2015 1 commit
  16. 26 Feb, 2015 1 commit
  17. 25 Feb, 2015 3 commits
  18. 20 Feb, 2015 1 commit
    • Nicolas Dufresne's avatar
      v4l2: Enable copy when no known allocation params · 6afd1c5d
      Nicolas Dufresne authored
      When there is no allocation parameters in the query, enable copy
      threshold. When this threshold is reached, the buffer pool will start
      copying when the pool reaches a critical level. If the driver supports
      CREATE_BUFS, this will be used instead.
      6afd1c5d
  19. 22 Jan, 2015 1 commit
  20. 15 Dec, 2014 1 commit
    • Nicolas Dufresne's avatar
      v4l2object: Always set format · 3dae65ed
      Nicolas Dufresne authored
      Right now we try to be clever by detecting if device format have
      changed or not, and skip setting format in this case. This is valid
      behaviour with V4L2, but it's also very error prone. The rational
      for not setting these all the time is for speed, though I can't
      measure any noticeable gain on any HW I own. Also, until recently,
      we where doing get/set on the format for each format we where
      probing, making it near to impossible that the format would match.
      This also fixes bug where we where skipping frame-rate setting if
      format didn't change.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740636
      3dae65ed
  21. 24 Nov, 2014 2 commits
  22. 21 Nov, 2014 2 commits
  23. 02 Nov, 2014 1 commit
  24. 01 Nov, 2014 1 commit
    • Simon Farnsworth's avatar
      v4l2: Clean up interlace support · 02040d50
      Simon Farnsworth authored
      Rather than try and guess interlace support as part of checking supported
      sizes, look for interlace support specifically in its own function.
      
      As a cleanup, use V4L2_FIELD_ANY when probing sizes, which should result in
      the driver doing the right thing.
      
      With my capture setup, this gets me the following sample caps:
      
      For 1080i resolution:
      video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, framerate=(fraction){ 25/1, 30/1 }
      
      For 720p resolution:
      video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction){ 50/1, 60/1 }
      
      For 576i/p resolution (both possible at the point of query):
      video/x-raw, format=(string)YUY2, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string){ progressive, interleaved }, framerate=(fraction){ 25/1, 50/1 }
      
      This, in turn, makes 576i work correctly; with the old code,
      the caps would be interlace-mode=progressive for interlaced video.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=726194
      02040d50
  25. 30 Sep, 2014 1 commit
  26. 09 Sep, 2014 2 commits
  27. 29 Aug, 2014 2 commits
  28. 25 Jul, 2014 3 commits