Блог

Я создаю видеопроигрыватель с libav. У меня работает декодирование видеопакетов, у меня работает воспроизведение в обратном порядке, у меня работает поиск. Все это работает без эмулятора Android x86, но не работает на реальном телефоне Android (arm64-v8a)

Ошибка в sws_scale() — возвращается 0. Видеокадры продолжают декодироваться правильно, без ошибок.

От libav нет ошибок, предупреждений, алертов. Я подключил avlog_callback

 void log_callback(void *ptr, int level, const char *fmt, va_list vargs) {
    if (level<= AV_LOG_WARNING)
        __android_log_print( level, LOG_TAG, fmt, vargs);
}
uint64_t openMovie( char* path, int rotate, float javaDuration )
{
    av_log_set_level(AV_LOG_WARNING);
    av_log_set_callback(log_callback);
  

Код для выполнения sws_scale() таков:

 int JVM_getBitmapBuffer( JNIEnv* env, jobject thiz, jlong av, jobject bufferAsInt, jbyte transparent ) { 
    avblock *block = (avblock *) av;
    if (!block) {
        __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, "  avblock is null");
        return AVERROR(EINVAL);
    }
    if (!block->pCodecCtx) {
        __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, "  codecctx is null");
        return AVERROR(EINVAL);
    }

    int width = block->pCodecCtx->width;
    int height = block->pCodecCtx->height;

    if (NULL == block->sws) {
        __android_log_print( ANDROID_LOG_ERROR, LOG_TAG, "getBitmapBuffer:n  *** invalid sws context ***" );
    }

    int scaleRet = sws_scale( block->sws,
            block->pFrame->data,
            block->pFrame->linesize,
            0,
            height,
            block->pFrameRGB->data,
            block->pFrameRGB->linesize
    );
    if (scaleRet == 0 ) {
        __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, "  scale failed");
        __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, "  pframe linesize    %d", block->pFrame->linesize[0]); 
        __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, "  pframergb linesize %d", block->pFrameRGB->linesize[0]); 
        __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, "  height  %d",
        height);
        return AVERROR(EINVAL);
    }
  

Настройка codex и avframes:

 //i have tried every combination of 1, 8, 16, and 32 for these values
int alignRGB = 32;
int align    = 16; 
int width    = block->pCodecCtx->width;
int height   = block->pCodecCtx->height;
block->pFrame    = av_frame_alloc();
block->pFrameRGB = av_frame_alloc();

block->pFrameRGBBuffer = av_malloc(
    (size_t)av_image_get_buffer_size(AV_PIX_FMT_RGB32, width, height, alignRGB) 
);

av_image_fill_arrays(
    block->pFrameRGB->data,
    block->pFrameRGB->linesize,
    block->pFrameRGBBuffer,
    AV_PIX_FMT_RGB32,
    width,
    height,
    alignRGB
);

block->pFrameBuffer = av_malloc(
        (size_t) av_image_get_buffer_size(block->pCodecCtx->pix_fmt,
                                          width, height, align
        )
);
av_image_fill_arrays(
    block->pFrame->data,
    block->pFrame->linesize,
    block->pFrameBuffer,
    block->pCodecCtx->pix_fmt,
    width, height,
    align
);
block->sws = sws_getContext(
    width, height,
    AV_PIX_FMT_YUV420P,
    width, height,
    AV_PIX_FMT_RGB32,
    SWS_BILINEAR, NULL, NULL, 0
);
  

Подстановочные знаки — это то, что:

• Я использую React-Native
• Мой эмулятор — x86 android api 28
• Моим реальным устройством является arm64-v8a AOSP (около api 28, точно не помню (

Другие примечания:

• файлы libav .so скомпилированы из проекта mobile-ffmpeg.
• Я также могу sws_scale также работает на x86_64 Linux, используя SDL для проецирования YV12
• Тестовое видео здесь:https://github.com/markkimsal/video-thumbnailer/tree/master/fixtures
• block это простая структура C с указателями на соответствующие структуры AV-памяти.
• Использование FFMPEG 4.3.2

Я почти уверен, что это как-то связано с выравниванием пикселей. Но документации по этой теме практически не существует. Это также может быть разница между форматами пикселей RGBA и RGB32, или, возможно, с малым порядком и с большим порядком.

Это известная ошибка в FFMPEG на архитектуре ARM.

Mythtv опубликовал обходной путь, который включает в себя вычитание 1 из целевой ширины, чтобы обойти неработающий код оптимизации.

https://code.mythtv.org/trac/ticket/12888

https://code.mythtv.org/trac/changeset/7de03a90c1b144fc0067261af1c9cfdd8d358972/mythtv

Сообщается в FFMPEG 3.2.1 http://trac.ffmpeg.org/ticket/6192

Все еще существует в FFMPEG 4.3.2

     int new_width = width;
#if ARCH_ARM
    // The ARM build of FFMPEG has a bug that if sws_scale is
    // called with source and dest sizes the same, and
    // formats as shown below, it causes a bus error and the
    // application core dumps. To avoid this I make a -1
    // difference in the new width, causing it to bypass
    // the code optimization which is failing.
    if (pix_fmt == AV_PIX_FMT_YUV420P
      amp;amp; dst_pix_fmt == AV_PIX_FMT_BGRA)
        new_width = width - 1;
#endif
    d->swsctx = sws_getCachedContext(d->swsctx, width, height, pix_fmt,
                                     new_width, height, dst_pix_fmt,
                                     SWS_FAST_BILINEAR, NULL, NULL, NULL);
  

Обновить:

Сборка mobile-ffmpeg 4.3.2 с --debug опцией создает рабочий двоичный файл.

ОБНОВЛЕНИЕ 2:

Флаг —debug, похоже, больше не работает. Должно быть, были какие-то нечистые сборки. Похоже, это связано с альфа-каналом.

Единственный не альфа-формат RGB, поддерживаемый обоими Android.Bitmap.Config и ffmpeg имеют значение RGB_565. Использование 565 работает с четными значениями ширины назначения.

в libswscale/yuv2rgb.c :

 SwsFunc ff_yuv2rgb_get_ptr(SwsContext *c) {
   ...
   switch(c->dstFormat) {
   case AV_PIX_FMT_RGBA:
       return (CONFIG_SWSCALE_ALPHA amp; isALPHA(c->srcFormat)) ? yuva2rgb_c: yuv2rgb_c_32;
   ....
   case AV_PIX_FMT_RGB565:
       return yuv2rgb_c_16_ordered_dither;
   ...
  

Мой исходный код — YUV420P и не поддерживает альфа-каналы (например, yuv A 420p). Когда моим целевым форматом является RGB565, у этого метода, похоже, нет никаких проблем.

Жаль, что я не могу создать какой-либо альфа-канал для Android. Я думаю, реальный ответ заключается в том, чтобы просто использовать OpenGL и использовать surface, который напрямую поддерживает blitting YUV.

ОБНОВЛЕНИЕ 3

Я нашел пути к коду в libswscale/swscale_unscaled.c и libswscale/yuv2rgb.c

Если вы масштабируете выходные данные, вы можете преобразовать их в формат RGBA dest.

Если вы добавите флаг SWS_ACCURATE_RND в свой SwsContext, вы также избежите неправильного пути к коду.