在单独的代码转换器之间共享文件索引 [英] Sharing of file indexes between seperate transcoders
问题描述
大家好，
我们的&lsquo ;工业实力’基于EE4的转码器项目进展顺利，但我希望更多地了解文件索引的工作原理，特别是在
中缓存这些索引。
我们通过SDK集成EE4并理解一次文件已被编入索引作为转码的一部分，因为EE4在第一个转码上创建的索引缓存
，所以对该文件的所有进一步操作都会更快。如果这是错的，请纠正我…。
< span style ="font-family：Calibri">问题的背景是我们打算在本地和远程（在我们打算提供的托管服务中）的各个地方托管多个转码器。
将代码转换为最不忙或最小队列的代码转换器，所以问题是：
假设文件的初始转码在Transcoder 1上创建SmoothStream和一堆缩略图，那么稍后同一个文件进入转码器2（不同的
机器）以生成更多缩略图：是否有任何方法可以使用转码器2共享转码器1中创建的缓存以加快转码？
另外，这些索引是否在转码器重新启动时缓存？
虽然我意识到在每个代码转换器上创建新索引的开销可能很小，但所有代码转换器都是全天24小时服务，所以我们觉得（此时无论如何…）
即使是小的性能提升也值得付出努力。
我们还在2月1日至3日举行了重要的客户演示，我们非常感谢SP1帮助我们做好准备。
谢谢，
Steve
< blockquote>
Steve，
源文件的索引仅针对特定文件类型。 MPEG2源文件是主要情况，因为我们需要生成索引以确保帧精确。 WMV和MP4容器已经包含了大部分索引，因此EE
只使用就地索引，在这种情况下确实没有比文件访问更多的开销。对于初始索引生成，MPEG2情况确实有相当多的开销。
就缓存而言，索引存储在运行编码器的机器上的.NET隔离存储中。因此，一旦生成索引，该计算机上编码器的所有后续实例都可以访问缓存并使用之前生成的
的索引。我们目前不支持跨机器共享索引，但这是一个有趣的场景，我将不得不考虑是否可以提供帮助。
-Sam
Hello all,
Our ‘industrial strength’ transcoder project based on EE4 is going well but I wish to understand a little more of how the indexing of files works, in particular the caching of these indexes.
We integrate EE4 via the SDK and understand that once a file has been indexed as part of a transcode, all further operations on that file are faster as EE4 caches the index it created on the first transcode. If this is wrong please correct me….
The background to the question is we intend to have multiple transcoders hosted in various places, both local and remote (in a hosted service we intend to offer). Transcodes will be farmed out to the transcoder that is least busy, or with the smallest queue and so the question is this:
Assuming the initial transcode of a file creates a SmoothStream and bunch of thumbnails on Transcoder 1, then at a later time the same file goes to Transcoder 2 (different machine) to generate more thumbnails: is there any way of sharing the cache created in transcoder 1 with transcoder 2 to speed up the transcode?
Additionally, are these indexes cached across restarts of a transcoder?
While I realise the overhead of creating a new index on each transcoder may be small, all transcoders will be a full pelt 24/7 so we feel (at this point anyway…) even a small performance improvement is worth the effort.
Also we have important customer demo on the 1-3 of February, and any heads up on SP1 would be greatly appreciated to help us prepare.
Thanks,
Steve
Hi Steve,
The indexing of a source file only occurs for particular file types. MPEG2 source files are the primary case, as we need to generate an index to make sure we are frame accurate. WMV and MP4 containers already contain an index for the most part, and so EE simply uses the in place index, and there really is no more overhead in this case than a file access. The MPEG2 case does have quite a bit of overhead for the initial index generation.
As far as caching, the index is stored in .NET isolated storage on the machine the encoder is running on. Therefore once an index is generated, all subsequent instances of the encoder on that machine have access to the cache and use the index that was previously generated. We don't currently support sharing the index across machines right now, but it's an interesting scenario that I'll have to think about to see if we can help out.
-Sam
这篇关于在单独的代码转换器之间共享文件索引的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
