1. 20 Jun, 2020 13 commits
  2. 19 Jun, 2020 16 commits
  3. 18 Jun, 2020 5 commits
  4. 17 Jun, 2020 6 commits
    • François Cartegnie's avatar
      f1118eb9
    • François Cartegnie's avatar
      016f5b16
    • Romain Vimont's avatar
      opengl: apply OpenGL vflip from interop · 1fee4df0
      Romain Vimont authored and Alexandre Janniaux's avatar Alexandre Janniaux committed
      Uploading a picture_t to OpenGL flips it vertically.
      
      To display the video in the correct orientation, the renderer reversed
      the transformation: each vertex received as attribute texture
      coordinates (x, 1-y) instead of (x, y), in order to flip the image
      vertically.
      
      This caused several problems.
      
      Firstly, the renderer must be independent of the input picture storage.
      Otherwise, when it receives an input in the normal orientation, it will
      wrongly apply a vertical flip.
      
      Secondly, since the vflip was applied on the input coordinates, it
      occurred before the orientation transform:
      
          OrientationMatrix * VFlipMatrix * input_coords  (semantically)
      
      whereas the correct transformation is:
      
          VFlipMatrix * OrientationMatrix * input_coords
      
      (for reasons explained in e329c4bb
      
      ).
      
      Since matrix multiplication is not commutative, it resulted in a
      wrong orientation in some cases (for example if OrientationMatrix
      contains a rotation by 90 degrees).
      
      (In fact, in pratice, this case still worked, because the initialization
      of OrientationMatrix was also wrong, see the two previous commits).
      
      To fix all these problems, initialize the texture coordinates in the
      normal orientation in the renderer, and apply the vertical flip on the
      interop format orientation.
      
      This also allows to simplify the Android interop, which can just provide
      its own transform matrix without compensating for the vertical flip
      that was applied in the renderer.
      
      Signed-off-by: Alexandre Janniaux's avatarAlexandre Janniaux <ajanni@videolabs.io>
      1fee4df0
    • Romain Vimont's avatar
      opengl: refactor orientation matrices · 7cff25fb
      Romain Vimont authored and Alexandre Janniaux's avatar Alexandre Janniaux committed
      
      
      Simplify the initialization matrices and document, so that they do not
      just contain magic values.
      
      Signed-off-by: Alexandre Janniaux's avatarAlexandre Janniaux <ajanni@videolabs.io>
      7cff25fb
    • Romain Vimont's avatar
      opengl: fix orientation matrices · ed1f5dd5
      Romain Vimont authored and Alexandre Janniaux's avatar Alexandre Janniaux committed
      
      
      The orientation matrices were incorrect.
      
      This commit is just here to show the differences, but the next commit
      will rewrite their initialization to make them more readable.
      
      Signed-off-by: Alexandre Janniaux's avatarAlexandre Janniaux <ajanni@videolabs.io>
      ed1f5dd5
    • Alexandre Janniaux's avatar
      mkv: remove typeid code in EBML dispatcher · c7644611
      Alexandre Janniaux authored
      EBML can associate multiple class to a single EBML ID, which mean that
      it potentially needs typeid checks. However, libmatroska always exposes
      a single type per EBML ID, so it never needs those checks.
      
      In addition, those checks are leading to warnings (attached below) and
      issues depending on the visibility and optimization level on clang. See
      the following mail on the mailing list for reference:
      
      https://lists.llvm.org/pipermail/llvm-dev/2014-June/073465.html
      
      To sum up, typeinfo are becoming different between libmatroska and the
      matroska modules for the same classes, so the matroska demuxer is never
      able to open correctly in those case, and it fallbacks on avformat
      demuxer if available.
      
      Compilation warning fixed by this patch:
      
          ../../../modules/demux/mkv/chapter_command.cpp:35:13: warning: expression with side effects will be evaluated despite being used as an operand to 'typeid'
                [-Wpotentially-evaluated-expression]
                  if( MKV_CHECKED_PTR_DECL( p_cpt, KaxChapterProcessTime const, command[i] ) )
                      ^
          ../../../modules/demux/mkv/mkv.hpp:116:63: note: expanded from macro 'MKV_CHECKED_PTR_DECL'
          #define MKV_CHECKED_PTR_DECL( name, type, src ) type * name = MKV_IS_ID(src, type) ? static_cast<type*>(src) : NULL
                                                                        ^
          ../../../modules/demux/mkv/mkv.hpp:115:52: note: expanded from macro 'MKV_IS_ID'
          #define MKV_IS_ID( el, C ) ( el != NULL && typeid( *el ) == typeid( C ) )
                                                             ^
          ../../../modules/demux/mkv/chapter_command.cpp:44:13: warning: expression with side effects will be evaluated despite being used as an operand to 'typeid'
                [-Wpotentially-evaluated-expression]
                  if( MKV_CHECKED_PTR_DECL( p_cpd, KaxChapterProcessData const, command[i] ) )
                      ^
          ../../../modules/demux/mkv/mkv.hpp:116:63: note: expanded from macro 'MKV_CHECKED_PTR_DECL'
          #define MKV_CHECKED_PTR_DECL( name, type, src ) type * name = MKV_IS_ID(src, type) ? static_cast<type*>(src) : NULL
                                                                        ^
          ../../../modules/demux/mkv/mkv.hpp:115:52: note: expanded from macro 'MKV_IS_ID'
          #define MKV_IS_ID( el, C ) ( el != NULL && typeid( *el ) == typeid( C ) )
      
      The issue was initially spotted through link-time warnings mentionning
      incompatible visibility settings between the library archives and the
      final static libvlc archive when compiling for iOS.
      
      Fix videolan/VLCKit#372
      c7644611