Блог

Я разрабатываю веб-ресивер для chromecast.

Согласно документации chromecast, поддерживается HLS с сквозной передачей AC-3. Это должно быть проверено с помощью canDisplayType, и после этого я предполагаю, что использовать кодек должно быть нормально.

Кажется, я не могу заставить chromecast принимать манифесты HLS с AC-3 в списке кодеков. Я пробовал это на chromecast поколения gen2 и gen3, и они оба отвергают его. canDisplayType вернет true или false в зависимости от настроек, сделанных в приложении Google Home. Когда у меня есть сервер, который фактически отправляет ac-3, он выдает cast.player.api.ErrorCode.MANIFEST/411 , прерывает и больше ничего не запрашивает у сервера.

Я также, похоже, не могу получить какой-либо подробной причины для этого, было бы полезно, если бы в журналах мне сообщили, почему кодек предположительно был отклонен.

Вот типичный файл manifest.m3u8, с которым я экспериментировал:

 #EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5499178,AVERAGE-BANDWIDTH=5499178,CODECS="avc1.640028,mp4a.a5",RESOLUTION=720x576,FRAME-RATE=50
main.m3u8?<snip>amp;VideoCodec=h264amp;AudioCodec=ac3,aac,mp3amp;<snip>amp;TranscodingMaxAudioChannels=6amp;<snip>amp;h264-profile=high,main,baseline,constrainedbaselineamp;h264-level=41amp;<snip>
 

Из моих экспериментов, mp4a.a5 , mp4a.A5 и ac-3 все проходят тест canDisplayType, но на этом этапе терпят неудачу.

Например:

 > context.canDisplayType("video/mp4", "avc1.640028,mp4a.a5", 1920, 1080, 50)
< true
 

Я также пытался обмануть плеер, заменив значение на mp4a.40.2 или просто притворяясь, что звука нет. В этом случае результаты немного отличаются, но обычно он запрашивает некоторые .ts файлы, прежде чем он сдается, или он вообще не воспроизводит звуковую дорожку. Для сравнения, тот же носитель, перекодированный с использованием aac-lc 2ch, работает нормально.

Нужно ли сделать что-нибудь особенное, чтобы подготовить приемник к использованию сквозного звука?