1. 04 Oct, 2019 3 commits
    • Daniel Kolesa's avatar
      swscale: Fix AltiVec/VSX build with recent GCC · e6625ca4
      Daniel Kolesa authored
      The argument to vec_splat_u16 must be a literal. By making the
      function always inline and marking the arguments const, gcc can
      turn those into literals, and avoid build errors like:
      
      swscale_vsx.c:165:53: error: argument 1 must be a 5-bit signed literal
      
      Fixes #7861.
      Signed-off-by: 's avatarDaniel Kolesa <daniel@octaforge.org>
      Signed-off-by: 's avatarLauri Kasanen <cand@gmx.com>
      e6625ca4
    • Daniel Kolesa's avatar
      swscale: Replace illegal vector keyword usage in altivec code · 1bdb47b7
      Daniel Kolesa authored
      While this technically compiles in current ffmpeg, this is only
      because ffmpeg is compiled in strict ISO C mode, which disables
      the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
      replaced with a macro inside altivec.h, which defines vector to
      be actually __vector, which accepts random types.
      
      Normally, the vector keyword should be used only with plain
      scalar non-typedef types, such as unsigned int. But we have the
      vec_(s|u)(8|16|32) macros, which can be used in a portable manner,
      in util_altivec.h in libavutil.
      
      This is also consistent with other AltiVec/VSX code elsewhere in
      the tree.
      
      Fixes #7861.
      Signed-off-by: 's avatarDaniel Kolesa <daniel@octaforge.org>
      Signed-off-by: 's avatarLauri Kasanen <cand@gmx.com>
      1bdb47b7
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Fix demuxing ProRes · 581419ea
      Andreas Rheinhardt authored
      The structure of a ProRes frame in mov/mp4 is that of a typical atom:
      First a 32 bit BE size field, then a tag detailling the content. Said
      size field includes the eight bytes of the atom header.
      
      This header is actually redundant, as the size of the atom is already
      known from the containing atom. It is therefore stripped away when muxed
      into Matroska and so the Matroska demuxer has to recreate upon demuxing.
      But it did not account for the fact that the size field includes the
      size of the header and this can lead to problems when a decoder uses the
      in-band size field.
      
      Fixes ticket #8210.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      Signed-off-by: 's avatarJames Almer <jamrial@gmail.com>
      581419ea
  2. 03 Oct, 2019 11 commits
  3. 02 Oct, 2019 4 commits
  4. 01 Oct, 2019 15 commits
  5. 30 Sep, 2019 7 commits