c# - Chrome 在从 ASP.NET Web Api 流式传输 FFMPEG 输出时超时

Question

我这里有一个独特的问题!

更新2所以事实证明下面的开发是错误的，错误的不一致使得看起来不关闭流使它工作......但事实上同样的问题仍然存在!

更新有趣的发展；如果我注释掉 ffmpegBufferedIn.Close();下面，整个流总是顺利进行......请求永远不会结束。这里可能发生了什么？

我正在编写一个 Web 服务，该服务将音频文件存储在 Azure Blob 存储中，并在通过我的 ASP.NET Web API 端点请求时将它们转换为 MP3 Live。我通过 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 有一种有趣的缓冲音频流的方式。 Chrome 将缓冲流的前约 2 MB，然后保持连接打开并等待用户接近播放文件的下一段，然后再使用流的其余部分。这应该没问题——对于某些歌曲来说确实如此。对于其他人，我得到这个:

起初我以为这是由于某种超时造成的 - 但它发生在每个文件的不同时间和大小。然而，对于同一首歌曲，它在大约 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%

有什么想法吗？我很感谢您的建议 - 我已经追求这个一周了!

Answer 1

您的问题是转换音频的速度和使用音频的速度之间的差异。

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

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

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