1. 14 Aug, 2015 2 commits
  2. 10 Aug, 2015 2 commits
  3. 16 Jul, 2015 1 commit
  4. 15 Jul, 2015 2 commits
  5. 14 Jul, 2015 1 commit
  6. 06 Jul, 2015 1 commit
    • Stian Selnes's avatar
      rtcpbuffer: Fix validation of packets with padding · 1586981b
      Stian Selnes authored
      The padding (if any) is included in the length of the last packet, see
      RFC 3550.
      
      Section 6.4.1:
         padding (P): 1 bit
            If the padding bit is set, this individual RTCP packet contains
            some additional padding octets at the end which are not part of
            the control information but are included in the length field. The
            last octet of the padding is a count of how many padding octets
            should be ignored, including itself (it will be a multiple of
            four).
      
      Section A.2:
         *  The padding bit (P) should be zero for the first packet of a
            compound RTCP packet because padding should only be applied, if it
            is needed, to the last packet.
      
         *  The length fields of the individual RTCP packets must add up to
            the overall length of the compound RTCP packet as received.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=751883
      1586981b
  7. 22 Jun, 2015 2 commits
  8. 11 Jun, 2015 2 commits
  9. 05 Jun, 2015 1 commit
  10. 02 Jun, 2015 1 commit
  11. 29 May, 2015 1 commit
  12. 23 May, 2015 1 commit
  13. 19 May, 2015 1 commit
  14. 18 May, 2015 1 commit
  15. 26 Apr, 2015 2 commits
  16. 23 Apr, 2015 2 commits
  17. 17 Apr, 2015 1 commit
  18. 14 Apr, 2015 1 commit
  19. 13 Apr, 2015 3 commits
  20. 10 Apr, 2015 2 commits
  21. 09 Apr, 2015 2 commits
  22. 08 Apr, 2015 3 commits
  23. 07 Apr, 2015 3 commits
  24. 05 Apr, 2015 2 commits
    • Tim-Philipp Müller's avatar
      tests: appsrc: clean up block_deadlock test and make it work in valgrind · 0aa0b89a
      Tim-Philipp Müller authored
      Remove all the bus watch and main loop code from the block_deadlock
      test, it's not needed: neither pipeline will ever post an EOS or ERROR
      message on the bus, and we're the only ones posting an error, from a
      timeout. Might just as well just sleep for a bit and then do whatever
      we want to do.
      
      Don't gratuitiously set tcase timeout, just use whatever is the
      default (or set via the environment).
      
      Make individual pipeline runs shorter.
      
      Check for valgrind and only do a handful iterations when running
      in valgrind, not 100 (each iteration takes about 4s on a core i7).
      
      Make videotestsrc output smaller buffers than the default resolution,
      we don't care about the buffer contents here anyway.
      
      Fixes test timeouts when run in valgrind.
      0aa0b89a
    • Tim-Philipp Müller's avatar
      tests: multisocketsink: fix flaky unit test · 46aa4744
      Tim-Philipp Müller authored
      On slower systems, or under high system load (e.g. check-valgrind),
      the sending_buffers_with_9_gstmemories test would sometimes fail,
      because the read call only returns 32 bytes instead of the full
      36 bytes expected. This is because multisocketsink might end up
      doing a partial write of 32 bytes first, and then write the
      missing 4 bytes later, but since we don't wait for all of data
      to be written, there's a short window where our read call in the
      unit test might then only receive the 32 bytes written so far,
      which makes it deeply unhappy.
      
      Instead, make sure we loop to read all bytes.
      46aa4744