Chrome 在从 ASP.NET Web Api 流式传输 FFMPEG 输出时超时答案

【问题标题】：Chrome times out on streaming FFMPEG output from ASP.NET Web ApiChrome 在从 ASP.NET Web Api 流式传输 FFMPEG 输出时超时
【发布时间】：2014-07-26 01:59:57
【问题描述】：

我有一个独特的问题！

UPDATE 2 所以事实证明下面的开发是 FALSE，错误的不一致使它看起来好像没有关闭流使它工作......但实际上同样的问题仍然存在！

~~更新有趣的发展；如果我在下面注释掉ffmpegBufferedIn.Close();，整个流总是可以通过……请求永远不会结束。这里会发生什么？~~

我正在编写一个 Web 服务，它将音频文件存储在 Azure Blob 存储中，并在通过我的 ASP.NET Web API 端点请求时将它们实时转换为 MP3。我通过 Azure 存储 API 使用“DownloadToStream”来完成此操作，通过 FFMPEG 进程的 STDIN 提供该流，并将 STDOUT 流作为请求响应发送。

执行此操作的代码块如下所示：

public HttpResponseMessage Get(Guid songid)
{
    // This could take awhile.
    HttpContext.Current.Server.ScriptTimeout = 600;

    Process ffmpeg = new Process();
    ProcessStartInfo startinfo = new ProcessStartInfo(HostingEnvironment.MapPath("~/App_Data/executables/ffmpeg.exe"), "-i - -vn -ar 44100 -ac 2 -ab 192k -f mp3 - ");
    startinfo.RedirectStandardError = true;
    startinfo.RedirectStandardOutput = true;
    startinfo.RedirectStandardInput = true;
    startinfo.UseShellExecute = false;
    startinfo.CreateNoWindow = true;
    ffmpeg.StartInfo = startinfo;
    ffmpeg.ErrorDataReceived += ffmpeg_ErrorDataReceived;

    // Our response is a stream
    var response = Request.CreateResponse();
    response.StatusCode = HttpStatusCode.OK;

    // Retrieve storage account from connection string.
    CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
        CloudConfigurationManager.GetSetting("StorageConnectionString"));

    // Create the blob client.
    CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

    // Retrieve reference to a previously created container.
    CloudBlobContainer container = blobClient.GetContainerReference("songs");

    // Retrieve reference to a blob
    CloudBlockBlob blockBlob = container.GetBlockBlobReference(songid.ToString());

    ffmpeg.Start();
    ffmpeg.BeginErrorReadLine();

    // Buffer the streams
    var ffmpegBufferedIn = new BufferedStream(ffmpeg.StandardInput.BaseStream);
    var ffmpegBufferedOut = new BufferedStream(ffmpeg.StandardOutput.BaseStream);

    blockBlob.DownloadToStreamAsync(ffmpegBufferedIn).ContinueWith((t) => {
        ffmpegBufferedIn.Flush();
        ffmpegBufferedIn.Close();
    });

    response.Content = new StreamContent(ffmpegBufferedOut);
    response.Content.Headers.ContentType = new MediaTypeHeaderValue("audio/mpeg");

    System.Diagnostics.Debug.WriteLine("Returned response.");
    return response;
}

这在所有浏览器中都非常有效——除了 Chrome，它有一种有趣的音频流缓冲方式。 Chrome 将缓冲流的前约 2 兆字节，然后保持连接打开并等待用户接近播放文件的下一段，然后再使用流的其余部分。这应该没问题 - 对于某些歌曲来说是这样。对于其他人，我明白了：

起初我认为这是由于某种超时造成的 - 但它发生在每个文件的不同时间和大小。然而，在相同的歌曲上，它在大约 15 秒内是一致的。服务端输出正常——没有抛出异常，FFMpeg成功完成歌曲编码。

这是上述请求的服务器端输出：

ffmpeg version N-64919-ga613257 Copyright (c) 2000-2014 the FFmpeg developers
  built on Jul 23 2014 00:27:32 with gcc 4.8.3 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
  libavutil      52. 92.101 / 52. 92.101
  libavcodec     55. 69.100 / 55. 69.100
  libavformat    55. 48.101 / 55. 48.101
  libavdevice    55. 13.102 / 55. 13.102
  libavfilter     4. 11.102 /  4. 11.102
  libswscale      2.  6.100 /  2.  6.100
  libswresample   0. 19.100 /  0. 19.100
  libpostproc    52.  3.100 / 52.  3.100
Input #0, mp3, from 'pipe:':
  Metadata:
    TSRC            : AUUM71001516
    title           : Sunlight
    track           : 2
    artist          : Bag Raiders
    copyright       : 2010 Modular Recordings
    genre           : Electronic
    album           : Bag Raiders
    album_artist    : Bag Raiders
    disc            : 1/1
    publisher       : Modular Recordings
    composer        : Chris Stracey/Jack Glass/Dan Black
    date            : 2010
  Duration: N/A, start: 0.000000, bitrate: 320 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
    Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg), 600x600 [SAR 300:300 DAR 1:1], 90k tbr, 90k tbn, 90k tbc
    Metadata:
      title           : 
      comment         : Other
Output #0, mp3, to 'pipe:':
  Metadata:
    TSRC            : AUUM71001516
    TIT2            : Sunlight
    TRCK            : 2
    TPE1            : Bag Raiders
    TCOP            : 2010 Modular Recordings
    TCON            : Electronic
    TALB            : Bag Raiders
    TPE2            : Bag Raiders
    TPOS            : 1/1
    TPUB            : Modular Recordings
    TCOM            : Chris Stracey/Jack Glass/Dan Black
    TDRL            : 2010
    TSSE            : Lavf55.48.101
    Stream #0:0: Audio: mp3 (libmp3lame), 44100 Hz, stereo, s16p, 192 kb/s
    Metadata:
      encoder         : Lavc55.69.100 libmp3lame
Stream mapping:
  Stream #0:0 -> #0:0 (mp3 (native) -> mp3 (libmp3lame))
size=       6kB time=00:00:00.21 bitrate= 227.6kbits/s    
size=     102kB time=00:00:04.31 bitrate= 193.7kbits/s    
size=     202kB time=00:00:08.56 bitrate= 192.9kbits/s    
size=     341kB time=00:00:14.49 bitrate= 192.5kbits/s    
size=     489kB time=00:00:20.82 bitrate= 192.4kbits/s    
size=     642kB time=00:00:27.35 bitrate= 192.3kbits/s    
size=     792kB time=00:00:33.75 bitrate= 192.2kbits/s    
size=     950kB time=00:00:40.49 bitrate= 192.2kbits/s    
size=    1106kB time=00:00:47.15 bitrate= 192.2kbits/s    
size=    1258kB time=00:00:53.63 bitrate= 192.1kbits/s    
size=    1415kB time=00:01:00.31 bitrate= 192.1kbits/s    
size=    1563kB time=00:01:06.66 bitrate= 192.1kbits/s    
size=    1710kB time=00:01:12.90 bitrate= 192.1kbits/s    
size=    1857kB time=00:01:19.17 bitrate= 192.1kbits/s    
size=    2008kB time=00:01:25.63 bitrate= 192.1kbits/s    
size=    2162kB time=00:01:32.21 bitrate= 192.1kbits/s    
size=    2299kB time=00:01:38.03 bitrate= 192.1kbits/s    
size=    2457kB time=00:01:44.80 bitrate= 192.1kbits/s    
size=    2600kB time=00:01:50.89 bitrate= 192.1kbits/s    
size=    2755kB time=00:01:57.52 bitrate= 192.1kbits/s    
size=    2864kB time=00:02:02.17 bitrate= 192.1kbits/s    
size=    3022kB time=00:02:08.88 bitrate= 192.1kbits/s    
size=    3172kB time=00:02:15.31 bitrate= 192.1kbits/s    
size=    3284kB time=00:02:20.06 bitrate= 192.1kbits/s    
size=    3385kB time=00:02:24.40 bitrate= 192.1kbits/s    
size=    3529kB time=00:02:30.51 bitrate= 192.0kbits/s    
size=    3687kB time=00:02:37.25 bitrate= 192.0kbits/s    
size=    3838kB time=00:02:43.71 bitrate= 192.0kbits/s    
size=    3988kB time=00:02:50.11 bitrate= 192.0kbits/s    
size=    4138kB time=00:02:56.53 bitrate= 192.0kbits/s    
size=    4279kB time=00:03:02.54 bitrate= 192.0kbits/s    
size=    4408kB time=00:03:08.03 bitrate= 192.0kbits/s    
size=    4544kB time=00:03:13.85 bitrate= 192.0kbits/s    
size=    4683kB time=00:03:19.78 bitrate= 192.0kbits/s    
size=    4805kB time=00:03:24.95 bitrate= 192.0kbits/s    
size=    4939kB time=00:03:30.67 bitrate= 192.0kbits/s    
size=    5049kB time=00:03:35.38 bitrate= 192.0kbits/s    
size=    5141kB time=00:03:39.32 bitrate= 192.0kbits/s    
size=    5263kB time=00:03:44.49 bitrate= 192.0kbits/s    
size=    5372kB time=00:03:49.17 bitrate= 192.0kbits/s    
The thread 0xb24 has exited with code 259 (0x103).
size=    5436kB time=00:03:51.91 bitrate= 192.0kbits/s    
size=    5509kB time=00:03:55.02 bitrate= 192.0kbits/s    
size=    5657kB time=00:04:01.32 bitrate= 192.0kbits/s    
size=    5702kB time=00:04:03.22 bitrate= 192.0kbits/s

video:0kB audio:5701kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.005738%

有什么想法吗？感谢您的建议 - 我已经追了一个星期了！

【问题讨论】：

为了什么缘故，您通过网络角色流媒体而不使用 Azure 媒体服务？？
Azure 媒体服务不支持我需要的音频编解码器范围。
你确定吗？ Azure 媒体服务官方文档没有向您展示如何进行 H.264 基线配置文件编码，但显然您可以：blogs.staykov.net/2013/04/bending-windows-azure-media.html 官方文档也不会向您展示如何修剪/剪切视频，但您也可以这样做：@ 987654322@ 从我在您的 ffmpeg 输出中看到的，您的音频中没有什么特别之处在于不受媒体服务的支持。只需要找出来:)
我没有找到任何声称支持 FLAC 和 OGG 等音频编解码器的东西，不幸的是，这对我来说是绝对必要的！如果它们得到支持，我肯定会使用 Azure 媒体服务。
嗨海登，我面临同样的问题。你在哪里可以解决这个问题？

标签： c# asp.net google-chrome azure ffmpeg

【解决方案1】：

您的问题在于转换音频的速度和消耗它的速度不同。

您正在将一个缓冲区填充到ffmpegBufferedIn 并将其发送到ffmpeg，但是当用户浏览器读取它时，您只是从ffmpegBufferedOut 读取它，正在发生的事情是进程完成而用户尚未完成使用 ffmpegBufferedOut 时，垃圾收集器和使用 ffmpegBufferedOut 的用户之间存在竞争。

如果您从不关闭ffmpegBufferedIn，它将永远不会对它进行垃圾收集，因为该进程正在等待来自流的更多数据，所以它可以工作。

您需要检测响应何时完成发送并且仅关闭流资源的解决方案，我不确定该怎么做。

【讨论】：

感谢您的回答 - 我想可能是这样的。我会进一步研究这个问题，如果它引导我找到答案或者我没有收到任何其他问题，我会标记为已解决。
我已经更新了问题 - 让流打开实际上并不能解决问题。我不认为 GC 是这里的问题——我为每个必需的对象保留了引用，但连接仍然失败。

【解决方案2】：

在 DownloadToStreamAsync 任务完成后关闭 ffmpegBufferedIn 流可能会有所帮助。见Task.ContinueWith(TResult) Method (Func(Task, TResult)) (System.Threading.Tasks)

blockBlob.DownloadToStreamAsync(ffmpegBufferedIn).ContinueWith((t) =>
{
    ffmpegBufferedIn.Flush();
    //ffmpegBufferedIn.Close();
}).Wait();
ffmpegBufferedIn.Close();

【讨论】：

查看我上面的更新 - 事实证明，不关闭流实际上没有任何区别！不过，感谢您的回答。