Потоковая передача iPhone HE-AAC через мобильную сеть (3G)

Разработал стример интернет-радио с использованием jPlayer, который использует аудио-теги html5 с jQuery и имеет резервное копирование flash для неподдерживаемых браузеров. При тестировании плеера на iPhone (iOS 5.0.1) мы столкнулись с очень своеобразной проблемой.

Когда iPhone подключен к Wi-Fi, он отлично передает потоки, используя поток HE-AAC V2 @ 64 кбит / с 44,1 кГц (предпочтительный кодек для продуктов Apple). Однако, когда iPhone подключен к мобильной сети 3G, он «заикается» или прекращает потоковую передачу на 1-2 секунды каждые 1-2 минуты (не прекращает потоковую передачу полностью). Беспокоит то, что когда iPhone вынужден использовать отдельный поток MP3 с той же скоростью передачи данных, у него нет этой проблемы и он очень хорошо работает в 3G.

ОБНОВЛЕНИЕ 5

Недавно мы приобрели мобильную точку доступа 3G / 4G Sprint и протестировали эту проблему с устройством. Когда iPhone подключен к мобильной точке доступа, он отображается как подключенный к устройству Wi-Fi, и проблема не отображается, даже если фактическое соединение осуществляется через 3G / 4G. Это может указывать на проблему, заключающуюся в том, что iPhone не обрабатывает HE-AAC через HTTP Live Streaming и при прямом подключении к мобильной сети.

ОБНОВЛЕНИЕ 4

Обновил iPhone до iOS 5.1, но проблема не устранена.

ОБНОВЛЕНИЕ 3

Прочтите здесь о различных проблемах, связанных с некорректным рендерингом скрипта при подключении к мобильным сетям. Кажется, что палец указывает на операторов мобильной сети, которые могут вставлять прокси для обслуживания веб-страниц, например для уменьшения размера изображений. Также он может внедрять некоторые страницы JavaScript. Тестовую страницу можно найти ЗДЕСЬ. Примечание: на этой странице используется HE-AAC, поэтому она будет работать только на iPhone. ...

ОБНОВЛЕНИЕ

Согласно документу Apple HTTP Live Streaming для устройств iOS, «только аудио-контент может быть либо транспортным MPEG-2, либо элементарными аудиопотоками MPEG, либо в формате AAC с заголовками ADTS, либо в формате MP3». Наш музыкальный сервер использует кодировщик OddcastV3 для отправки трех потоков (MP3, HE-AAC V2 и Oggvorbis) на сервер icecastV2. Не уверен, вставляет ли кодировщик заголовки ADTS для потока HE-AAC V2. Есть ли способ это проверить?


iphone mp3 mobile-safari http-live-streaming icecast
person Community    schedule 09.01.2012    source источник
comment
это ваше дело, но я вам советую набрать больше репутации в SO и начать вознаграждение за первый вопрос. Вы можете заработать репутацию, отвечая на любые темы, не только связанные с ios.   -  person A-Live    schedule 09.01.2012
comment
Прочтите из документа Apple HTTP Live Streaming для устройств iOS, что аудио-контент может быть либо транспортным MPEG-2, либо элементарными аудиопотоками MPEG, либо в формате AAC с заголовками ADTS, либо в формате MP3. Не уверен, есть ли у потока заголовки ADTS. Не уверен, что проблема в этом ...   -  person RMX    schedule 10.01.2012
comment
Здесь http://developer.apple.com/resources/http-streaming/ справа от вас. можно найти инструмент для проверки потока. После установки вы используете его так: mediastreamvalidator validate --timeout = 60 ssite.com/track.mp3 Вы увидите самые важные проблемы в журнале.   -  person A-Live    schedule 18.01.2012

Ответы (2)


arrow_upward
1
arrow_downward

Исходя из точки зрения радиопланирования - вот мои два цента:

То, что вы описываете, похоже на формирование полосы пропускания, которое является обычным и часто необходимым проектом радиосетей (например, сетей 3G). В большинстве операторов 3G, с которыми я работал, вы обычно оптимизируете свою сеть, чтобы обеспечить высокоскоростную серию (подумайте о загрузке изображения, отправке одного электронного письма или получении одной HTML-страницы) по сравнению с «длительно работающими» службами с высокой пропускной способностью. Это связано с тем простым фактом, что это то, чего хочет / нужно большинству пользователей.

Такое формирование в типичной сети 3GPP (GSM 3G) может привести к тому, что вы сначала получите RAB (канал радиодоступа), поддерживающий 384 кбит, а затем будет понижен до версии, пока ваше устройство принимает это. Это означает, что обычно вы переключаетесь с 384 -> 256 -> 128, затем на 64 Кбит, где, возможно, ваше устройство начинает медленно получать данные, затем сеть обновляет его и через некоторое время снова понижает его.

Так почему же тогда не заикается файл MP3? Я предполагаю, что общая скорость передачи в кбитах может отличаться - так что с RAB на 64 Кбит все нормально. Это обычное явление.

person Magnus    schedule 01.07.2012
comment
вы говорите, что общий размер может отличаться, однако нет общего размера, поскольку это потоковая радиостанция и не загружает файл определенного размера, будь то MP3 или HE-AAC. - person RMX; 03.07.2012
comment
извините - я имел в виду общую скорость кбит / с. Я обновил свой ответ. Вы выполняли сетевое отслеживание (это легко можно сделать с помощью инструментов в симуляторе) - person Magnus; 05.07.2012
comment
Не проводил слежку за сетью. Даже не знаю, что это такое! ржу не могу - person RMX; 06.07.2012
comment
Протестировали эту проблему с HE-AAC @ 128kbps, и она все еще возникает. Вы бы сказали, что это соответствует вашему ответу? - person RMX; 07.07.2012
comment
Я думаю, что путь вперед - это проверить, что здесь происходит в сети. Я предлагаю вам запустить инструменты, чтобы увидеть, что происходит. - person Magnus; 09.07.2012
comment
Я предполагаю, что Магнус мог сказать, что потоки, помеченные как 64 кбит / с, на самом деле могут быть немного больше или немного меньше, с учетом заголовков и т. Д., И это может привести к тому, что потоки будут падать по обе стороны от выделенной скорости носителя радиодоступа. И если это хотя бы несколько бит, теоретически это может привести к рассинхронизации потока и необходимости перебуферизации. - person RipperDoc; 10.07.2012
comment
Мне все это не кажется правдоподобным. Тот факт, что MP3 отлично работает там, где поток HE-ACC не работает при тех же скоростях передачи (или даже ниже или выше), похоже, указывает на механизмы доставки, а не на мобильные сети. Это может быть комбинация кодировщика и потокового сервера (icecast, shoutcast). - person RMX; 10.07.2012

arrow_upward
0
arrow_downward

Нам удалось заставить работать то же самое. 64 Кбит AAC-v2 на мобильных устройствах. Мы транслируем файлы, а не постоянный поток, я думаю, что Магнус прав, когда он объясняет, как сеть приоритизировала трафик для пакетов, в нашем случае это означает, что у нас сразу же есть большие части файла, и игрок может продолжать играть до следующего приходит всплеск. В вашем случае это означает, что поток приостанавливается до следующего всплеска.

Либо вы можете переключиться на более крупные фрагменты потоковой передачи (больший буфер), либо вместо этого выполнять потоковую передачу целых файлов?

У нас был очень странный феномен с iOS: нам пришлось переименовать все файлы из .m4a в .aac, чтобы иметь возможность передавать их в потоковом режиме на iOS. Если бы мы не переименовали их, iOS их не воспроизводила бы.

Удачи.

person Community    schedule 15.07.2012
comment
Спасибо за ваш вклад. К сожалению, мы не можем транслировать целые файлы, поскольку он создан для интернет-радиостанции, которая ведет непрерывную трансляцию 24 часа в сутки. Кроме того, это не приложение, вместо этого мы осуществляем потоковую передачу с использованием HTTP Live Streaming для iOS (непосредственно через мобильный Safari), поэтому мы не можем контролировать буферизацию. Я все еще очень запутался в вопросе радио. Разве тот факт, что эта проблема все еще возникает на 128k AAC-V2, не отменяет объяснение по радио? Также тот факт, что MP3 отлично работает со скоростью 64 кбит / с ... Любое понимание этого может помочь нам решить проблему. Еще раз спасибо - person RMX; 21.07.2012