1. 01 Jun, 2013 1 commit
    • Clément Bœsch's avatar
      lavc/avpacket: fill padding area on side data split. · 151b4947
      Clément Bœsch authored
      The padding data is assumed to be 0 in several places, notably in
      subtitles. This problem was not detected with fate-sub-srt test because
      the first element of the side data (x1) is 0 in the test, so the
      trailing side data present in the packet wasn't read by the decoder. The
      issue can be observed with a large enough x1.
      
      It is also noted in FF_INPUT_BUFFER_PADDING_SIZE doxy that MPEG
      bitstreams require that padding with 0, so it might fix other issues.
      151b4947
  2. 14 May, 2013 1 commit
  3. 29 Apr, 2013 1 commit
  4. 13 Mar, 2013 2 commits
  5. 08 Mar, 2013 1 commit
  6. 13 Jan, 2013 1 commit
    • Anton Khirnov's avatar
      avpacket: free side data in av_free_packet(). · 90cfc084
      Anton Khirnov authored
      Freeing it in av_destruct_packet(), as is done currently, would mean
      that we allow it to be allocated with other means. But that would make
      av_packet_new_side_data() unsafe.
      
      Side data is not expected to be large, so copying it if required
      shouldn't be a problem.
      90cfc084
  7. 20 Sep, 2012 2 commits
  8. 17 Sep, 2012 1 commit
  9. 15 Sep, 2012 1 commit
  10. 15 Aug, 2012 1 commit
  11. 03 Jun, 2012 1 commit
  12. 21 May, 2012 1 commit
  13. 12 Apr, 2012 1 commit
  14. 01 Mar, 2012 1 commit
  15. 14 Jan, 2012 1 commit
    • Reimar Döffinger's avatar
      Fix leaking of side data. · c4ba5198
      Reimar Döffinger authored
      While we correctly "register" the side data when we split it,
      the application (in this case FFmpeg) might not update the
      AVPacket pool it uses to finally free the packet, thus
      causing a leak.
      This also makes the av_dup_packet unnecessary which could
      cause an even worse leak in this situation.
      Also change the code to not modify the user-provide AVPacket at all.
      Signed-off-by: 's avatarReimar Döffinger <Reimar.Doeffinger@gmx.de>
      c4ba5198
  16. 06 Nov, 2011 1 commit
  17. 21 May, 2011 1 commit
  18. 15 Apr, 2011 2 commits
  19. 19 Mar, 2011 1 commit
  20. 21 Nov, 2010 1 commit
  21. 11 Dec, 2009 2 commits
  22. 30 Apr, 2009 1 commit
  23. 11 Apr, 2009 1 commit
  24. 08 Apr, 2009 1 commit
  25. 07 Apr, 2009 1 commit