У меня есть приложение, которое получает потоковое аудио с серверов Windows Media с типом контента application/x-mms-framed.Приложение удаляет кадрирование из данных перед передачей потока в конвейер gstreamer, например:
gst-launch fdsrc ! asfdemux ! fakesink
(конечно, обычно конвейер обычно включает в себя WMA-декодер и другие вещи - это просто необходимый минимумчтобы проиллюстрировать проблему).
Из выходных данных отладки видно, что синтаксический анализ ASF идет со вторым пакетом данных: он пытается прочитать его со смещением на +3 байта за пределы того места, где он фактически начинается.
Некоторые данные из выходных данных отладки:
- Начальный пакет заголовка ($ H из потока в кадре) составляет 5027 байтов и, кажется, анализируется правильно.Минимальный размер пакета составляет 1567.
- Каждый из следующих пакетов данных ($ D из созданного потока) содержит 1564 байта.
Я думаю, что проблема заключается в том, что демультиплексор ASFиспользуя фиксированное значение минимального размера пакета 1567 для каждого пакета, даже если он распознает, что фактический пакет содержит меньше данных.Он обрабатывает дополнительные 3 байта как неявное заполнение и (эффективно) пропускает их, а не уменьшает размер пакета для потребления.
Это, вероятно, потому, что мой код, который просто как-то обрезает кадрирование, также должен передавать фактический кадрразмер.Может быть, есть способ сделать это с помощью механизма прохождения буфера gstreamer, и в этом случае мне нужно написать плагин gstreamer для выполнения фрейминга.Такой плагин будет конвертировать application/x-mms-framed -> video/x-ms-asf.Я надеялся найти существующий плагин, который бы делал это, но пока безуспешно.
Я на правильном пути или это просто ошибка в демультиплексоре ASF (я подозреваю, что не так, как я на самом деле пытался 3различные плагины демультиплексора ASF)?