1. 16 May, 2020 3 commits
  2. 15 May, 2020 19 commits
  3. 14 May, 2020 15 commits
  4. 13 May, 2020 3 commits
    • Jan Ekström's avatar
      avformat/tls_schannel: immediately return decrypted data if available · 6f8826e4
      Jan Ekström authored
      Until now, we would have only attempted to utilize already decrypted
      data if it was enough to fill the size of buffer requested, that could
      very well be up to 32 kilobytes.
      
      With keep-alive connections this would just lead to recv blocking
      until rw_timeout had been reached, as the connection would not be
      officially closed after each transfer. This would also lead to a
      loop, as such timed out I/O request would just be attempted again.
      
      By just returning the available decrypted data, keep-alive based
      connectivity such as HLS playback is fixed with schannel.
      6f8826e4
    • Jan Ekström's avatar
      avformat/tls_schannel: always decrypt all received data · 39977fff
      Jan Ekström authored
      The dec_buf seems to be properly managed between read calls,
      and we have no logic to decrypt before attempting socket I/O.
      Thus - until now - such data would not be decrypted in case of
      connections such as HTTP keep-alive, as the recv call would
      always get executed first, block until rw_timeout, and then get
      retried by retry_transfer_wrapper.
      
      Thus - if data is received - decrypt all of it right away. This way
      it is available for the following requests in case they can be
      satisfied with it.
      39977fff
    • Martin Storsjö's avatar
      pixblockdsp, avdct: Add get_pixels_unaligned · 353aecbb
      Martin Storsjö authored
      Use this in vf_spp.c, where the get_pixels operation is done on
      unaligned source addresses.
      
      Hook up the x86 (mmx and sse) versions of get_pixels to this
      function pointer, as those implementations seem to support unaligned
      use.
      
      This fixes fate-filter-spp on armv7.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      353aecbb