Как MediaExtractor определяет, что поместить в блоки H2AL NAL?
Я проверил вывод MediaExtractor на двух устройствах Android, и он, похоже, производит на них немного разные сэмплы, учитывая один и тот же видеофайл.
С одним устройством блоки NAL без VCL объединяются со следующим блоком VCL для получения образца. На другом устройстве каждый блок без VCL составляет полный образец.
Другое отличие: на одном устройстве сэмплы имеют начальный 0-байтовый и начальный префикс кода (001) в сэмпле; с другой стороны, эти байты опущены.
Если я пытаюсь использовать формат блоков NAL для первого устройства на другом устройстве, видео не воспроизводится.
Если я создаю свои собственные блоки NAL (не используя MediaExtractor), есть ли принципиальный способ узнать, какой формат ожидает декодер MediaCodec H264?
1 ответ
Официальным способом является наличие префиксов начального кода (которые необходимы для наличия нескольких блоков NAL в одном пакете) - это то, что ожидают все декодеры OpenMAX IL (стандарт, используемый внутри MediaCodec), даже если некоторые также могут поддерживать другие форматы). Есть ли у вас SPS/PPS в отдельном буфере (с BUFFER_FLAG_CODEC_CONFIG флажок) или добавление в буфер с блоками VCL NAL не должно иметь значения - я думаю, что декодеры должны быть в состоянии обрабатывать оба. Я не думаю, что вы найдете какой-либо отдельный документ, который проясняет это для Android, кроме как косвенным образом выводить его из того, что на самом деле делают устройства.
Можете ли вы назвать, какие устройства (и какие версии платформ) выводят, какую комбинацию этих вариантов битового потока и какая комбинация дает сбой на каком устройстве? AFAIK поток с присутствующими стартовыми кодами должен работать везде, но, конечно, могут быть исключения. Начиная с Android 4.3, эти вещи должны быть намного лучше, чем на 4.1 и 4.2.
Некоторые поставщики, кажется, делают нестандартные вещи в MediaExtractor - об этом я написал сообщение об ошибке по адресу https://code.google.com/p/android/issues/detail?id=74356. В этом случае специфическое нестандартное поведение Samsung сигнализируется с помощью isDMCMMExtractor=1 введите MediaFormat. Я действительно согласен с тем, что MediaExtractor должен быть более строгим, поскольку в настоящее время он в основном используется только для подачи данных в MediaCodec (где предполагается, что он должен быть понят, по крайней мере, для кодеков HW конкретного поставщика), но сложно сказать, что он на самом деле делает, если приложение захочет сделать что-то еще с выходом MediaExtractor (например, декодировать с помощью стороннего связанного декодера или отправить извлеченные данные по сети и т. д.).
Если какое-то устройство не может декодировать де-факто стандартный формат битового потока (но успешно, только если оно искажено так, как это делает MediaExtractor платформы), звучит так, как будто требуется другой тест на совместимость с CTS, путем тестирования декодирования необработанных, жестко закодированных пакетов (так что MediaExtractor не может получить промежуточное и преобразовать вещи). Работают ли тесты CTS, такие как EncodeDecodeTest (см. Http://bigflake.com/mediacodec/), на этом устройстве? Если это произойдет, но если декодирование стандартных форматов пакетов не удастся, это будет означать, что кодер устройства также выводит что-то нестандартное.