1. 08 Jul, 2014 1 commit
  2. 10 Feb, 2014 1 commit
  3. 11 Dec, 2013 2 commits
  4. 23 Nov, 2013 1 commit
  5. 16 Nov, 2013 1 commit
  6. 31 Oct, 2013 1 commit
  7. 25 Jul, 2013 1 commit
  8. 27 Apr, 2013 1 commit
    • Luca Barbato's avatar
      avplay: remove a warning · 26a44143
      Luca Barbato authored
      Set the data field in the flush_pkt to the pointer to the actual packet.
      The field needs to contain a valid unique pointer, no read nor writes
      are ever made to it.
      26a44143
  9. 11 Apr, 2013 2 commits
  10. 19 Mar, 2013 1 commit
  11. 09 Mar, 2013 1 commit
  12. 08 Mar, 2013 1 commit
  13. 09 Feb, 2013 1 commit
  14. 29 Nov, 2012 1 commit
  15. 13 Oct, 2012 2 commits
  16. 12 Oct, 2012 1 commit
  17. 08 Oct, 2012 1 commit
  18. 05 Oct, 2012 1 commit
  19. 01 Oct, 2012 1 commit
  20. 24 Sep, 2012 1 commit
  21. 11 Sep, 2012 2 commits
  22. 19 Aug, 2012 5 commits
  23. 08 Aug, 2012 1 commit
  24. 22 Jul, 2012 1 commit
  25. 08 Jul, 2012 1 commit
  26. 05 Jul, 2012 1 commit
  27. 04 Jul, 2012 1 commit
    • Martin Storsjö's avatar
      avplay: Add an option for not limiting the input buffer size · 296d0da8
      Martin Storsjö authored
      For reading from normal files on disk, the queue limits for
      demuxed data work fine, but for reading data from realtime
      streams, they mean we're not reading from the input stream
      at all once the queue limit has been reached. For TCP streams,
      this means that writing to the socket from the peer side blocks
      (potentially leading to the peer dropping data), and for UDP
      streams it means that our kernel might drop data.
      
      For some protocols/servers, the server initially sends a
      large burst with data to fill client side buffers, but once
      filled, we should keep reading to avoid dropping data.
      
      For all realtime streams, it IMO makes sense to just buffer
      as much as we get (rather in buffers in avplay.c than in
      OS level buffers). With this option set, the input thread
      should always be blocking waiting for more input data,
      never sleeping waiting for the decoder to consume data.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      296d0da8
  28. 03 Jul, 2012 1 commit
    • Luca Barbato's avatar
      avplay: fix write on freed memory for rawvideo · 906f9dce
      Luca Barbato authored
      Do not assume avpacket and the decoded frames are independent.
      
      To be absolutely sure and not sprinkle av_free_packet around the code
      the call had been placed before getting the frame and on the error path.
      906f9dce
  29. 30 Jun, 2012 1 commit
  30. 22 Jun, 2012 1 commit
  31. 14 Jun, 2012 1 commit
  32. 05 Jun, 2012 1 commit