搜索
Playlist传输方案分析以及对比upnpplayList传输方案有两种：方案一：添加私有action（playList），以歌曲PATH+name为value，CP每次传输一首或多首歌曲，在render（char*）端，接收到相应的action以后，取出value值，存入本地playlist。方案一示意图方案一还有两种细节的方式：一种是，每一个歌曲的trakcInfo都为一个action的value，有多少首歌曲，就发送几个action。第二种方式是将所有的歌曲按照一定的格式，组合成一个action的value，不管有多少首歌曲，都发送一个action。第一种方式，随着歌曲数量的增加，action被发送的次数也会增加，会大大消耗系统的资源，造成效率降低或可靠性降低。第二种方式，无论歌曲的数量为多少，都只发送一个action，只是value的长度增加。因此，第二种方式相对更优一些。方案二：添加私有action（m3u），CP端新建一个m3u文件将歌曲path+name写入m3u文件，CP以m3u文件的url地址为action的value，render接收到相应的action以后，取出url，然后通过url下载m3u文件到本地，解析m3u文件，获取歌曲path+name，存入本地playlist。方案二示意图：在第二中方案，CP端写m3u文件相对难度不大，解析m3u文件的难度相对也不大。解析m3u文件有两种方式，第一种是自己写解析代码，第二种为通过totem库来解析代码。由于移植totem库比较麻烦，并且系统flash资源相对紧张，因此，选用第一种方式，自己写解析代码会更优很多。方案实现方法优点缺点方案一传输actionPATH+name每一首歌曲一个action代码实现简单Action传输次数过多。可控性/可靠性差使用一个action，value为所有歌曲的trackInfo代码实现简单，Action传输次数少。标准性/可靠性较差方案二传输actionM3uurl使用标准库解析m3u文件代码简单，可靠性高移植工作量大，硬件资源紧张。实现代码解析m3u文件总体工作量小。标准化好。传输出错可能性小。代码相对复杂。综合比较，选用方案二，第二种传输方式。即，使用m3u文件承载歌曲信息，然后自己写代码解析m3u文件，获取playlist。