Mopidy: HTTP 오디오 출력 스트리밍 지원 추가

다음 코드를 가정합니다.

import logging
from BaseHTTPServer import BaseHTTPRequestHandler

from mopidy import get_version

logger = logging.getLogger('mopidy.outputs.http')

class StreamingHTTPRequestHandler(BaseHTTPRequestHandler):
    server_version = 'HTTPOutput/%s' % get_version()

    def do_GET(self):
        self.send_response(200)
        self.send_header('content-type', 'audio/mpeg')
        self.end_headers()

        register_fd_with_output(self.wfile.fileno())

        self.close_connection = 0

    def log_message(self, format, *args):
        logger.info(format, *args)

여기서 register_fd_with_output() 는 HTTPOutput( audioconvert ! lame ! multifdsink )의 fd 싱크에 추가 신호를 내보내는 함수이고 BaseHTTPServer.HTTPServer 실행 중인 ThreadingActor 가 있습니다. StreamingHTTPRequestHandler HTTP 스트리밍이 작동해야 합니다.

메타데이터와 같은 추가 기능의 경우 다음 링크가 유용해야 합니다.

• http://www.smackfu.com/stuff/programming/shoutcast.html
• http://sphere.sourceforge.net/flik/docs/streaming.html

위의 코드는 이 문제를 해결하는 데 사용하면 안 됩니다. 코드 기반의 현재 상태로 우리는 cherrypy를 기반으로 하는 무언가를 원합니다.

가장 먼저 해야 할 일은 OUTPUT 설정에서 사용할 수 있는 GStreamer 요소를 만들고 등록하는 것입니다. 믹서를 사용하면 #152 또는 Pitivi 예제의 코드로 시작하기에 충분해야 합니다. 요소는 기본적으로 multifdsink 래핑하고, 체리피 항목을 처리하고 이들 사이에 FD를 전달합니다.

HTTP 부분에 관해서는 적어도 그것에 대해 진행하는 방법이 있습니다. 첫 번째는 아마도 가장 쉬운 방법일 것입니다. 프론트엔드 서버에 대해 독립적인 cherrypy 서버를 시작하고 사용하십시오. 두 번째, 우리가 원하는 것은 프론트엔드와 코드의 스트리밍 부분 간에 공유되는 싱글톤 HTTP 서버를 갖는 것입니다. 이 부분은 현재 제가 아는 한 크게 알려지지 않은 부분입니다.

HTTP 서버가 배치되면 체리파이에서 소켓을 분리해야 합니다. ws4py를 보면 request.rfile.rfile._sock = None 것이 우리가 관리할 수 있는 가장 가능성 있는 해결 방법인 것 같습니다. 분리하기 전에 일부 헤더를 내보내고 싶을 것입니다. 그런 다음 fd를 분리하여 싱크로 내보내고 스트리밍해야 합니다. ws4py가 소켓을 인수하는 방법을 살펴보면 세부 정보를 파악할 수 있습니다.

다른 부분은 FD를 방출할 수 있도록 핵심 오디오 API를 확장하는지 여부입니다. 그것은 바로 그 경우에 특화된 것이거나 우리가 사용하고 있는 출력 빈에 접근할 수 있도록 하는 더 일반적인 것입니다.

내가 왜 이것을 더 일찍 생각하지 않았는지 나는 전혀 모른다. 그러나 소켓을 훔치는 것에 관해서는 우리가 socket.fromfd 을 사용하여 새 복사본을 생성하여 원본을 아무 영향 없이 닫을 수 있도록 해야 합니다.

가까운 장래에 출력 스트리밍을 추가할 계획이 있습니까?

나는 이것이 몇 달 전이라는 것을 알고 있지만 이것이 바닐라 MPD에서 전환하는 것을 막는 유일한 것입니다. 스피커가 연결되지 않은 서버에서 MPD를 실행하고 집 안팎의 다양한 컴퓨터/장치에서 HTTP 스트림을 조정합니다. Mopidy에서 이것을 보고 싶습니다. 그리고 그것이 이미 있다면 올바른 방향으로 저를 가리켜 주십시오! 잠시 동안 설명서를 읽었지만이 작업을 수행하는 방법을 찾지 못하는 것 같습니다.

AFAIK는 https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast에 문서화된 Icecast 및 몇 가지 해킹과 결합하여 Mopidy에서 작동하는 HTTP 스트리밍을 얻을 수 있습니다.

갭리스 브랜치(#1288 참조)에 대한 작업이 진행 중이며 다음 라운드의 갭리스 개선과 함께 스트림을 유지하기 위해 해킹 없이 Mopidy+Icecast가 작동하도록 해야 합니다.

저도 HTTP 스트리밍에 진지한 관심을 갖고 있다는 점에서 차임하고 싶습니다. 직장에서 내 웹 서버/VPN의 멋진 Moped 웹 인터페이스에서 Spotify를 듣는 데 사용하고 싶습니다. 로컬에서 실행하고 음악을 들었을 때 다소 화가 났고 원격으로 실행하려고 할 때 수많은 JACK 오류가 발생했습니다. 더 나은 코딩 방법을 안다면 직접 시도해 볼 것입니다. 감사 해요!

@jodal #1288에 대해 언급한 문제가 해결되었습니까?

즉, 문서의 이 부분을 제거할 수 있습니까?

현재 Mopidy는 GStreamer에서 트랙 끝과 스트림 끝 신호를 올바르게 처리하지 않습니다. 이로 인해 SHOUTcast 스트림이 각 트랙의 끝에서 연결이 끊어져 상당히 쓸모없게 됩니다. 자세한 내용은 #492를 참조하십시오. 아래에 언급된 해결 방법을 시도해 볼 수도 있습니다.

@JohnMaguire 문서의 어딘가에 링크를 포함하지 않았기 때문에 잊어버린 섹션이 있는지 여부는 알 수 없습니다. AFAIK 문서의 "개발" 버전은 2.0의 예정된 변경 사항으로 최신 상태입니다.

죄송합니다: https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

문서의 개발 버전에서 업데이트된 것 같습니다. 정확합니다: https://docs.mopidy.com/en/develop/audio/#streaming -through-icecast

@jodal님 감사합니다!

지난 2년 동안 업데이트가 있습니까?

지난 5년 동안 업데이트가 있습니까?

아니요. Icecast는 최고의 솔루션으로 남아 있습니다.

Mopidy 3의 일부로 hlssink2와 같은 HTTP 스트리밍을 위한 몇 가지 더 나은 옵션을 제공하는 GStreamer의 최소 지원 버전을 출시했습니다. 누구든지 이것을 추구하는 데 관심이 있다면 시작하는 것이 좋습니다.

Snapcast 는 또 다른 솔루션입니다. 멀티룸 재생용으로 만들어졌지만 단일 클라이언트로 스트리밍하는 데에도 사용할 수 없는 이유는 없습니다. 나는 그것을 테스트하지 않았지만 유망해 보입니다.

네, 저는 스냅캐스트를 사용했습니다. fifo의 사용은 약간 까다롭고 새로운 대체 방법이 개발되고 있었지만 마지막으로 그 방법에 자체 문제가 있다는 소식을 들었습니다. 또한 http 스트리밍이 아닙니다.