Streamlink抓取YouTube直播音频转MP3的实现方案及选型咨询

1. Streamlink直接导出MP3的可行性 #

Streamlink本身仅负责直播流的拉取，不内置转码能力，无法直接保存为MP3格式，但可以通过标准输出将流管道给FFmpeg实时转码，无需先保存完整的.ts文件到本地。
针对YouTube直播，你可以直接指定audio_only流质量，无需拉取包含视频的流，大幅节省带宽：

streamlink [YT直播URL] audio_only -O | ffmpeg -i pipe:0 -acodec libmp3lame -ab 128k 输出文件名.mp3

2. 转码方案选择 #

因为你处理的是直播流，不存在"下载完成"的状态，必须采用边拉取边转码的并行方案：

• 不需要单独处理已下载的.ts分片，直接通过系统管道将Streamlink拉取的流实时传给FFmpeg转码即可，资源开销极低，也不需要额外开线程管理分片转码
• 如果需要额外备份原始.ts流，可以同时写本地文件+管道给FFmpeg，不需要等全量下载完成再处理

3. 命令行调用 vs 原生Python模块调用的差异 #

你当前选择的subprocess调用命令行的方案完全可用，实现更简单，适配性更高，Streamlink版本升级不需要修改代码。
原生Python模块调用的优势仅在以下场景体现：

• 需要自定义断流重试、流质量自动降级等逻辑时，可以直接获取流状态，不需要解析命令行的文本输出
• 需要在Python进程内直接处理音频流数据，不需要落地文件也不需要走跨进程管道
• 需要更精细的错误捕获，比如特定地区版权限制、频道未开播等状态的判断

4. 参考代码的删减优化 #

你提供的示例是为了实时解码显示视频帧，所有和视频相关的逻辑完全可以删除：

• 可以移除cv2、numpy两个依赖，以及对应的逐帧读取、数组转换、画面显示的全部代码
• 移除FFmpeg参数中video选择器、rawvideo输出、像素格式配置，替换为音频转MP3的参数
• 分片下载逻辑建议保留：直播流本身是HLS协议的.ts分片结构，按分片拉取可以在网络波动时仅重试失败的分片，不需要重启整个拉流进程，大幅提升抓取可靠性

5. 简化后的实现示例 #

import subprocess as sp

def save_youtube_live_audio(stream_url, output_mp3_path):
    # streamlink拉取音频-only流，输出到stdout
    streamlink_cmd = [
        "streamlink",
        stream_url,
        "audio_only",
        "-O"
    ]
    streamlink_proc = sp.Popen(streamlink_cmd, stdout=sp.PIPE)
    
    # ffmpeg从stdin读流，转成mp3输出到文件
    ffmpeg_cmd = [
        "ffmpeg",
        "-i", "pipe:0",
        "-acodec", "libmp3lame",
        "-ab", "128k",
        "-y", # 覆盖已存在文件
        output_mp3_path
    ]
    ffmpeg_proc = sp.Popen(ffmpeg_cmd, stdin=streamlink_proc.stdout)
    
    try:
        ffmpeg_proc.wait()
    except KeyboardInterrupt:
        # 手动停止时正常关闭进程
        streamlink_proc.terminate()
        ffmpeg_proc.terminate()

# 调用示例
# save_youtube_live_audio("https://www.youtube.com/[频道直播URL]", "直播录音.mp3")

内容的提问来源于stack exchange，提问作者samas