Recherche avancée

Sur d’autres sites (4355)

• Surfaceview/TextureView for subtitles alpha does not work

  27 mai 2018, par user654628

  Goal : trying to build video player with subtitles for android. Video can be low resolution but the subtitles should be resolution of phone (such that if video is 720p, the subtitles should render to screen size say 1080p).

  Issue : Render on Textureview or Surfaceview is not see through where you could get it to blend with the background views. I am using FFMPEG to render a frame at say 720p but phone device is 1080p. I need to display subtitles that are different resolution than the subtitles resolution so pixel blending is difficult.

  I first tried to scale the frame (AVFrame) with sws_convert but each frame took 80ms so that is not an option (since it is running software).

  Then I tried two surface views, one for the video and one for subtitles where video would be 720p and subtitles SurfaceView is 1080p, then the video scales up to the phone size. The issue here is that the subtitles are not translucent. Black opacity 0 would be transparent but white with alpha 0 is still white. Why is this ?

  //Code from Java, the view that extends FrameLayout
  
  public VideoView(@NonNull Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
  
      super(context, attrs, defStyleAttr);
  
      mVideoSurface = new SurfaceView(context);
  
      mSubtitlesSurface = new SurfaceView(context);
  
      addView(mVideoSurface);
  
      addView(mSubtitlesSurface);
  
      mVideoSurface.getHolder().addCallback(mSurfaceCallback);
  
      mSubtitlesSurface.getHolder().addCallback(mSurfaceCallback);
  
      mSubtitlesSurface.setZOrderMediaOverlay(true);
  
      mSubtitlesSurface.getHolder().setFormat(PixelFormat.TRANSLUCENT);
  
      //etc
  
  }

  Eventually I tried as a test to render a square to the subtitle surface view (C++)

  // Render the video frame, now render the subtitle frame
  
  ANativeWindow_Buffer buffer;
  
  ANativeWindow_setBuffersGeometry(subWindow, width, height, WINDOW_FORMAT_RGBA_8888);
  
  if ((ret = ANativeWindow_lock(subWindow, &buffer, NULL)) < 0) {
  
      return ret;
  
  }
  
  for (int j = height/2; j < height/2 + 100; j++) {
  
      for (int i = width/2; i < width/2 + 100; i++) {
  
          uint8_t * d =  (uint8_t*)buffer.bits + j * (buffer.stride * 4) + i * 4;
  
          d[0] = 0xff;
  
          d[1] = 0xff;
  
          d[2] = 0xFF;
  
          d[3] = 0;           /* alpha */
  
  
  
      }
  
  }
  
  ANativeWindow_unlockAndPost(subWindow);

  So above code should render a white square in the image with 0 alpha (so should be invisible), but it is shown. If I change it to yellow with alpha 0 it will be visible but not the correct color. If I change to white with 1 alpha, it is white and opaque. If I use black with alpha 0xCC, it is invisible, only if alpha is 0xFF then it is visible as black. Seems to have no translucency even though I added it to the SurfaceHolder. Why is it like this ? I can add more code if needed.

  Is my only option to do what I want to render frame as a texture in OpenGL and (GLSurfaceView), resize the image to phone resolution and blend the alpha subtitles onto the frame as a texture ?

  Thanks in advance.

• FFMPEG - Recursive mp3 bitrate-conversion (Windows)

  3 avril 2018, par ShroomPow

  I am looking for a way to convert every mp3-file in a directory (including sub-directories) to 128kbps using ffmpeg and preferably batch on windows.
  Either by replacing the original files or "cloning" the whole directory-structure.

  I am trying to cut down the size of my musiclibrary for my phone. Is this easily achievable ?

• avutil/aes : Don't use misaligned pointers

  21 octobre 2022, par Andreas Rheinhardt

  avutil/aes : Don't use misaligned pointers
  The AES code uses av_aes_block, a union consisting of
  
  uint64_t[2], uint32_t[4], uint8_t[4][4] and uint8_t[16].
  
  subshift() performs byte-wise manipulations of two av_aes_blocks,
  
  but when encrypting, it does so with a shift of two bytes ;
  
  more precisely, it uses
  
  "av_aes_block *s1 = (av_aes_block *) (s0[0].u8 - s)"
  
  and lateron uses the uint8_t[16] member to access s0.
  
  Yet av_aes_block requires to be suitably aligned for
  
  the uint64_t[2] member, which s0[0].u8 - 2 is certainly
  
  not. This is in violation of 6.3.2.3 (7) of C11. UBSan
  
  reports this in the aes_ctr, mov-3elist-encrypted,
  
  mov-frag-encrypted, mov-tenc-only-encrypted and srtp
  
  tests.
  
  Furthermore, there is another issue here : The pointer points
  
  outside of s0 ; this works, because all the accesses lateron
  
  use an index >= 3. (Clang-)UBSan reports this as
  
  "runtime error : index -2 out of bounds for type 'uint8_t[16]'".
  This commit fixes both of these issues : The latter issue
  
  is fixed by applying an offset of "+ 3" during the cast
  
  and subtracting this from the indices used lateron.
  
  The former issue is solved by not casting to av_aes_block*
  
  at all ; instead simply cast to unsigned char*.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavutil/aes.c