我这里有一个独特的问题!更新2因此,事实证明,下面的开发是FALSE,该错误的不一致使它看起来好像没有关闭流就可以工作了……但实际上,同样的问题仍然存在!更新有趣的发展;如果我在下面注释掉ffmpegBufferedIn.Close();,则整个流总是可以正常运行...请求永无止境。这可能是怎么回事?我正在编写一个将音频文件存储在Azure Blob存储中的Web服务,并在通过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浏览器将缓冲流的前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.100Input #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 : OtherOutput #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 libmp3lameStream mapping: Stream #0:0 -> #0:0 (mp3 (native) -> mp3 (libmp3lame))size= 6kB time=00:00:00.21 bitrate= 227.6kbits/ssize= 102kB time=00:00:04.31 bitrate= 193.7kbits/ssize= 202kB time=00:00:08.56 bitrate= 192.9kbits/ssize= 341kB time=00:00:14.49 bitrate= 192.5kbits/ssize= 489kB time=00:00:20.82 bitrate= 192.4kbits/ssize= 642kB time=00:00:27.35 bitrate= 192.3kbits/ssize= 792kB time=00:00:33.75 bitrate= 192.2kbits/ssize= 950kB time=00:00:40.49 bitrate= 192.2kbits/ssize= 1106kB time=00:00:47.15 bitrate= 192.2kbits/ssize= 1258kB time=00:00:53.63 bitrate= 192.1kbits/ssize= 1415kB time=00:01:00.31 bitrate= 192.1kbits/ssize= 1563kB time=00:01:06.66 bitrate= 192.1kbits/ssize= 1710kB time=00:01:12.90 bitrate= 192.1kbits/ssize= 1857kB time=00:01:19.17 bitrate= 192.1kbits/ssize= 2008kB time=00:01:25.63 bitrate= 192.1kbits/ssize= 2162kB time=00:01:32.21 bitrate= 192.1kbits/ssize= 2299kB time=00:01:38.03 bitrate= 192.1kbits/ssize= 2457kB time=00:01:44.80 bitrate= 192.1kbits/ssize= 2600kB time=00:01:50.89 bitrate= 192.1kbits/ssize= 2755kB time=00:01:57.52 bitrate= 192.1kbits/ssize= 2864kB time=00:02:02.17 bitrate= 192.1kbits/ssize= 3022kB time=00:02:08.88 bitrate= 192.1kbits/ssize= 3172kB time=00:02:15.31 bitrate= 192.1kbits/ssize= 3284kB time=00:02:20.06 bitrate= 192.1kbits/ssize= 3385kB time=00:02:24.40 bitrate= 192.1kbits/ssize= 3529kB time=00:02:30.51 bitrate= 192.0kbits/ssize= 3687kB time=00:02:37.25 bitrate= 192.0kbits/ssize= 3838kB time=00:02:43.71 bitrate= 192.0kbits/ssize= 3988kB time=00:02:50.11 bitrate= 192.0kbits/ssize= 4138kB time=00:02:56.53 bitrate= 192.0kbits/ssize= 4279kB time=00:03:02.54 bitrate= 192.0kbits/ssize= 4408kB time=00:03:08.03 bitrate= 192.0kbits/ssize= 4544kB time=00:03:13.85 bitrate= 192.0kbits/ssize= 4683kB time=00:03:19.78 bitrate= 192.0kbits/ssize= 4805kB time=00:03:24.95 bitrate= 192.0kbits/ssize= 4939kB time=00:03:30.67 bitrate= 192.0kbits/ssize= 5049kB time=00:03:35.38 bitrate= 192.0kbits/ssize= 5141kB time=00:03:39.32 bitrate= 192.0kbits/ssize= 5263kB time=00:03:44.49 bitrate= 192.0kbits/ssize= 5372kB time=00:03:49.17 bitrate= 192.0kbits/sThe thread 0xb24 has exited with code 259 (0x103).size= 5436kB time=00:03:51.91 bitrate= 192.0kbits/ssize= 5509kB time=00:03:55.02 bitrate= 192.0kbits/ssize= 5657kB time=00:04:01.32 bitrate= 192.0kbits/ssize= 5702kB time=00:04:03.22 bitrate= 192.0kbits/svideo:0kB audio:5701kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.005738%有任何想法吗?感谢您提出的建议-我已经追赶了一个星期! 最佳答案 您的问题是转换音频的速度和消耗音频的速度之间的差异。您正在为ffmpegBufferedIn填充一个缓冲区并将其发送到ffmpeg,但是您仅在用户浏览器读取ffmpegBufferedOut时才从其中读取内容,这是在进程完成并且用户没有完成使用,在垃圾回收器和使用ffmpegBufferedOut的用户之间存在竞争。如果您从未关闭ffmpegBufferedOut,它将永远不会进行垃圾回收,因为该进程正在等待流中的更多数据,因此它可以正常工作。您需要检测响应何时完成发送的解决方案,而不仅仅是关闭流资源,我不太确定该怎么做。