Actionscript 3 超过16776秒无法搜索

我有一个自定义播放器，可以播放录音（仅音频）。如果音频文件很长，NetStream类将无法很好地查找它。我发现在16776秒（04:39:36）之后，NetStream seek函数从文件的开头再次启动。以下是最短的伪代码：

package com.name.player
{
    import flash.net.NetConnection;
    import flash.net.NetStream;
    ...

    public class StreamingPlayer extends Sprite
    {
        public var maStream:NetStream;
        ...

        public function aFunction
        {
            maStream = new NetStream( maConnection );
            maStream.inBufferSeek = true; // ==> Generates compile error: 
            //Error: Access of possibly undefined property inBufferSeek through a reference with static type flash.net:NetStream.
            //    [mxmlc] 
            //    [mxmlc]             maStream.inBufferSeek = true;
            //    [mxmlc]                      ^

            maStream.play('sName', 0, -1, true);
            // Now try these (one at a time)
            maStream.seek(16775); // Seeks to the desired position and plays the file till the end
            maStream.seek(16776); // Seeks at second 0 ( begining )
            maStream.seek(16778); // Seeks at second 0 ( begining )
            maStream.seek(16780); // Seeks at second 3
            maStream.seek(16786); // Seeks at second 9
            maStream.seek(16796); // Seeks at second 19
            ...

        }
        ...
    }
    ...
}

我尝试了不同的格式（speex、wav）/代码/比特率：
-RIFF（little endian）数据、波形音频、ITU G.711 A-law、单声道8000 Hz
-RIFF（little endian）数据、波形音频、Microsoft PCM、16位、单声道44100 Hz
-Ogg数据，Speex音频

文件大小或总长度无关紧要，我尝试了在1.1-1500 MB之间和04:40:00（17000秒）到14:56:41（53801秒）之间

我正在为新浏览器使用html5，但我们仍然需要支持旧浏览器（在一些无法更新安装新软件的客户端PC上，因此我需要为这些浏览器提供flash解决方案，因为flash已经安装并运行在IE6:（））

问：
我是否做错了什么，或者NetStreamer有限制，如果有什么解决方案，我必须能够播放这些长文件

另外，这是我第一次使用flash，所以如果你有答案/意见，请尽量说得更清楚一点

编辑：添加了Adobe ID 3492103的bug

编辑：
我有一位同事测试了stream server，他在日志中发现了一些有趣的东西：

// This is lower than 16776 seconds, and works
01-26 13:02:14.277  RtmpProtocol:891        [ID-007] Seeking to 1594380
...
01-26 13:02:14.279  FileReaderWav:194       [ID-007] <Stream0001> Seeking to 15943804 sf_seek 127550432
...
01-26 13:02:16.250  FileReaderWav:230       [ID-007] <Stream0001> Current position: 15943824

// This is when it plays from the beginning (seeking after 16776 seconds)
// according to the log it should just play at the desired position, but it's not
01-26 13:02:23.294  RtmpProtocol:891        [ID-007] Seeking to 16990012
01-26 13:02:23.303  FileReaderWav:194       [ID-007] <Stream0001> Seeking to 16990012 sf_seek 135920096
01-26 13:02:23.463  FileReaderWav:230       [ID-007] <Stream0001> Current position: 16990032

//这低于16776秒，并且有效
01-26 13:02:14.277 RTMProtocol:891[ID-007]寻求1594380
...
01-26 13:02:14.279 FileReaderWav:194[ID-007]寻求15943804 sf_寻求127550432
...
01-26 13:02:16.250文件阅读器WAV:230[ID-007]当前位置：15943824
//这是它从一开始播放的时间（16776秒后搜索）
//根据日志，它应该只在所需的位置播放，但它不是
01-26 13:02:23.294 RTMProtocol:891[ID-007]寻求16990012
01-26 13:02:23.303文件阅读器WAV:194[ID-007]寻求16990012 sf_寻求135920096
01-26 13:02:23.463文件阅读器WAV:230[ID-007]当前位置：16990032

我们的流服务器可能有问题，一些整数转换或类似的问题。如果我得到更多信息，我会更新

---

<谢谢> <强> > /p> < p>我想，如果文件被完全缓冲到所需的查找位置，你必须考虑。如果你正在尝试<强>流文件（AKA没有满负荷），并寻找文件未被完全加载的位置…它会产生错误，或者只是不去那里。

解决方案：

（1） 在查找之前，请确保文件已缓冲到该位置

（2） 使用PHP（或任何服务器端）在所需位置为您提供文件。这将为您节省带宽，因为只传递请求的数据

---

例如，如果您要求的文件大小为1500mb，但您只需要800-1500mb……那么请在该位置提供该文件。

文档中没有任何内容表明17000+是不可接受的值，并且NetStream.seek（）没有记录任何错误.也许你发现了一个新的？我怀疑很多用户都试图播放这么长的文件before@LeeBurrows有什么方法可以填补漏洞？从开发的角度来看，AFAIK flash或多或少已经死了，但我认为应该让他们知道。漏洞可以在这里存档：。flash当然没有死；flash网站可能会死，但not flash本身我生成了一个1.1MB的ogg文件，很容易放入缓冲区，我在同一秒也遇到了同样的问题。我倾向于认为这是NetStream中的一个bug，考虑到flash或多或少已经死了，这个bug不会被修复。@RaduMaris flash远没有死，我不确定Apache的更新过程，但我“我确信他们很有能力处理问题/更新。对于你的问题，这很可能是一个bug。就我个人而言，我倾向于分割文件并提供块（以节省带宽），因此我没有遇到过这种情况。但我今晚将测试这一点，并让你知道我的发现。还可以尝试[inBufferSeek]，这是NetStream的一个方法，它应该告诉您数据是否为“智能”流进行了缓冲（）我在尝试inBufferSeek时出错“错误：通过静态类型flash.net:NetStream的引用访问可能未定义的属性inBufferSeek”。我更新了代码以查看netStream的定义位置和方式。免责声明：我没有构建播放器，这是我第一次使用flash:）@RaduMaris您使用的sdk版本是什么？无。我使用的是一个简单的文本编辑器，编译是在Ubuntu服务器10.04 LTS上使用ant、mxmlc和Flex3.4完成的。我现在正在检查流服务器。见更新的问题。