Получить данные rtpL16 в локальный файл |Как проверить файл как положено? - PullRequest
0 голосов
/ 18 декабря 2018

Как заголовок (название), здесь я сталкиваюсь с двумя вопросами.

1.Получение полезной нагрузки Rtp в локальный файл.

Теперь это я выполнил, как показано ниже

gst-launch-1.0 udpsrc port=5000 ! "application/x-rtp,media=(string)audio, clock-rate=(int)44100, width=16, height=16, encoding-name=(string)L16, encoding-params=(string)1, channels=(int)1, channel-positions=(int)1, payload=(int)96" ! rtpL16depay ! filesink location=TestFile.pcm

Но я не уверен, как правильно закрыть файл !!!Сейчас я отключаю исходный конвейер (он отключается автоматически, когда аудиофайл достигает своего конца) .И это перестает записывать данные в файл.Есть ли способ, которым конвейер на стороне клиента (тот, что приведен выше) распознал бы, что нет входящих данных, и поэтому конвейер становится свободным.

2.Как проверить сгенерированный файл TestFile.pcm

Файл, сгенерированный из вышеуказанного конвейера, содержит необработанные аудиоданные.Как это воспроизвести (проигрыватель аудиофайлов на основе linux (mplayer) не может его воспроизвести), чтобы проверить, совпадают ли отправленные и полученные данные.

Пожалуйста, помогите.Любые предложения или советы будут чрезвычайно оценены:)

1 Ответ

0 голосов
/ 18 декабря 2018
  1. Попробуйте поэкспериментировать со свойством timeout элемента udpsrc.Напишите логику, которая останавливает ваш конвейер в функции обратного вызова timeout.

  2. Вы пытались сохранить файл в разных форматах?например, mp4, avi и т. д. Знаете ли вы, если какая-либо кодировка была сделана в источнике?Если это сделано, то вы должны использовать соответствующий декодер после элемента rtpL16depay для декодирования видео из этого формата кодека в необработанный формат.Возможно, причина в том, что вы не можете воспроизвести файл.Это может быть диким предположением, но я думаю, что L16 может быть вашим форматом кодирования в источнике.

...