MediaCacheLocalFirstRandomAccessReader是一个自定义的IRandomAccessReader接口的实现，它优先在Wowza服务器的本地Content目录下查找点播文件，如果找到了就直接播放，如果没有找到再继续走MediaCache的流程，到远端的MediaCache Source中获取视频内容。 这个功能可以用在VOD业务的CDN回源流程中，你可以将热点内容放在Wowza本机上(通常是一个Wowza Vod Edge服务器)，再将一些非热点内容或新更新的内容放在远端的MediaCache Source上。

注意:

• 针对Wowza Streaming Engine™ 4.0及以上版本
  
  
  
• 这个自定义的Media Reader既可以被设置到VOD应用中，也可以被设置到VOD EDGE应用中。两个不同的应用的配置各有些不同。其实你可以理解为：对于VOD应用，加上VOD EDGE的相关功能；对于VOD EDGE应用，加上VOD的相关功能。
  
  因此，从这个角度来看，其实Wowza的VOD应用和VOD EDGE应用可以非常轻松的整合在一起。根本没有必要分成两个不同的Application Type。

关于这个Media Reader编译后的版本，你可以在Wowza 的自定义模块中找到。

配置

---

要启用这个MediaReader，你需要在Wowza应用的Properties中添加下面的参数。




注意:

• 这个地方不是要添加一个新的Module，而是给已有的内建Module设置一个新的Java实现类。
  
  
  
• 如果你使用的是VOD Edge应用，这个参数是已经有了，只是它的默认值是com.wowza.wms.mediacache.impl.MediaCacheRandomAccessReaderVODEdge，你要把这个默认值改为上面的这个设置。另外，注意：randomAccessReaderClass参数只能设置一个。

其它参数

---

当你启用了MediaReader后，你可以继续在你的Wowza应用的Properties上添加以下参数来调整它的默认行为。



注意:

• 这个mediaCacheLocalFirstRandomAccessReaderClassName的参数，你只针对VOD应用，对于VOD EDGE应用，那这个参数是不需要。

如何使用?

---

对mediaCacheLocalFirstMediaCachePath 参数的设置说明

mediaCacheLocalFirstMediaCachePath 参数可以使用以下变量，当需要查找视频文件时，这些变量会被自动替换为实际的值。



注意:

• 如果你希望仅在某一个Media Cache中查找视频文件，你需要将mediaCacheLocalFirstMediaCachePath设置为这个Media Cache Source的前缀(或者加上更深一层次的路径)。
  
  
  
• 如果在Wowza本地和远端的Media Cache都没有找到这个视频文件，则Wowza会返回一个"Stream Not Found (404)" 的error信息。

Wowza Streaming Engine接收到播放请求后的搜寻视频处理逻辑

当一个播放器请求播放一个视频内容时，Wowza应用将按下面的流程处理:

1. Wowza应用首先会到本机的Content目录下寻找视频文件，如果找到，就直接播放。
   
   
   
2. 如果在Content目录下，没有找到这个视频文件，然后就用视频点播请求路径与mediaCacheLocalFirstMediaCachePath参数中配置的路径进行匹配检查:
   
   注意: 如果这个参数使用了系统变量，那么它首先会被解析为实际路径。
   • 如果视频点播请求路径是以mediaCacheLocalFirstMediaCachePath参数配置的路径开始的，或者这个参数为空字符串，那么视频点播请求路径会被当作Media Cache Source中的完整路径来继续由Media Cache处理。系统会假定这个视频点播请求路径指向了一个合法的Media Cache source。
     
     
     
   • 如果视频点播请求路径不是以mediaCacheLocalFirstMediaCachePath参数配置的路径开始的，那么这个参数的路径就会被加到这个视频点播路径的最前面作为一个指向Media Cache source的最终的完整路径，继续由Media Cache处理。

下面是几个例子

1. 场景1:sample.mp4文件存在于Wowza应用的Content目录下。
   
   处理逻辑: 播放器请求点播sample.mp4文件时，Wowza直接从这个目录中加载视频。
   
   
   
2. 场景2:Wowza应用的Content目录下是空的，而mediaCacheLocalFirstMediaCachePath 参数被设置为 mysource/，sample.mp4存储在一个前缀为mysource/的Media Cache source 的根目录下。
   
   处理逻辑: 播放器请求点播sample.mp4文件时，首先Wowza在本地Content路径下没找到视频文件，接着Wowza会在点播请求路径前面加上mysource/，因此，新的请求路径mysource/sample.mp4会继续由Media Cache来处理。
   
   
   
3. 场景3:sample.mp4文件存在于Wowza应用的Content目录下。而mediaCacheLocalFirstMediaCachePath参数被设置为mysource/，sample.mp4存储在一个前缀为mysource/的Media Cache source 的根目录下。
   
   处理逻辑: 播放器请求点播mysource/sample.mp4。首先Wowza在本地Content路径下没找到视频文件(因为在这个路径下根本就没有叫做mysource的目录)，因此mysource/sample.mp4 会继续Media Cache来处理。
   
   
   
4. 场景4:一个直播应用刚刚完成了录制，并将录制文件存放在了Content目录下。你需要定期将这些录制文件上传到一个存储设备上，作为一个集中的Media Cache source(前缀为mysource/)，然后再Wowza本机上的录制文件删除掉。而mediaCacheLocalFirstMediaCachePath 被设置为 mysource/。
   
   处理逻辑: 播放器请求点播myStream.mp4文件，而刚好这个文件Wowza本机上还没有被删除掉，这是就直接播放了。一会儿之后，播放器再来请求同样的这个资源(myStream.mp4)，而这个文件已经被上传到远端并且在本地被删除掉了，自然在本地找不到这个文件，这是mysource/会被添加到请求请求路径的前面，作为最终路径继续由MediaCache来处理。
   
   
   
5. 场景5:一个直播应用刚刚完成了录制，但是需要将录制文件上传到两个不同的Media Cache source上。第一个录制文件(myStream.mp4)存在本地的mysource/文件夹下(当然，它是Content目录的子目录) ，然后第二个录制文件(stream1.mp4)也存放在Content路径下的myothersource/monday/子目录中。
   
   这两个文件要分别被上传到两个不同的Media Cache source上，一个是上传到前缀为mysource/的Media Cache source的根目录下，另一个要上传到前缀为myothersource/的Media Cache source的下一级目录monday下。
   注意:
   • 在这个场景中，非常重要的一点是：存储录制文件的本地路径(相对于Content路径的相对路径)与Media Cache Source的前缀完全匹配，并且两边的内部子目录也完全匹配。
     
     
     
   • 因为涉及到多个不同的Media Cache source，因此你需要将mediaCacheLocalFirstMediaCachePath参数设置为空字符串。播放器在发起点播请求时使用了完整的Media Cache source 路径(也就是说包含了前缀)。
   处理逻辑: 播放器请求点播mysource/myStream.mp4文件时，如果它还在本地路径下，则会直接播放。否则，Wowza会继续走MediaCache的流程，到前缀为mysource/的Media Cache Source中查找myStream.mp4文件。
   
   如果播放器请求点播myothersource/monday/stream1.mp4文件时，和上面的流程一样，先在本地找，本地找不到了，继续走MediaCache的流程，到前缀为myothersource/的Media Cache Source的下一级目录monday目录下找stream1.mp4文件。