11-21-2012 10:09 AM
Are you asking if there is any way of passing a stream of bytes (encoded bytes; as opposed to be a container, in a URL) and do playback through mm-renderer?
If so, unfortunately, the multimedia platform currently doesn't support this feature. It is being planned and targetted for the future though; but we don't have any confirmed dates of delivery yet.
May we know what your use case is? There could be work around.....
11-21-2012 10:14 AM
11-22-2012 07:09 PM
We support that too, but only at the lower layers in the multimedia stack right now.
As mentioned, this is all on the roadmap and will be available when time permits.
Is your "pak" file compressed? If not, then you might consider just shipping the assets as individual files. You don't actually have the data in memory it seems, so there is no advantage over just using files.
11-22-2012 09:23 PM
11-23-2012 11:01 AM
I think you're missing the fact that mmap() does not actually load the file into ram, but just provides a memory-like interface to the file. Likewise, if you are using read(), you are already taking advantage of buffering by the filesystem, so chunks of the file will be in main memory already. Performance is all the same at the bottom layer (blocksizes withstanding). At the bottom layer in the OS, it's half a dozen of one or 6 of the other
As for documenting the low layer framework.. it is frightening stuff and is still churning regularly. The headers alone are over 600,000 lines of code and the complete multimedia codebase is somewhere on the order of 3 million. Aside from churning regularly, there are enough special use cases and gotchas that unless you sit next to the guys who wrote all of the plugins, filters, streamers, writers, readers, etc., it can sometimes be challenging to implement a graph and get it right on the first attempt.
We realize that there is a gap between the easy-to-use-but-less-flexible mm-renderer interface and the difficult-to-use-but-very-flexible low layer framework. We do intend to provide something which alleviates the difficulty factor of the latter. It just can't be promised for launch.
All that being said.. if you do want to stream files straight out of memory, I am told you may be able to use a pipe. The caveat being that we have not tested this thoroughly and that if you ever let the pipe run out of data, playback will error out and terminate (eg. make sure to keep the pipe fed!). At this point though, you may as well be using a file on the filesystem.
11-23-2012 09:04 PM - edited 11-23-2012 09:24 PM
>I think you're missing the fact that mmap() does not actually load the file into ram, but just provides >a memory-like interface to the file. Likewise, if you are using read(), you are already taking >advantage of buffering by the filesystem, so chunks of the file will be in main memory already.
In our pak file we have thousands of files, it's several hundreds of megabytes.
Are you telling me that it is more efficient for me to load these files over and over again when the user is playing the game? You do understand that by mapping my pak file, I am insuring that my memory does not get fragmented, every time I load a file?
Yes, using fread/fopen in a hello world program that prints out text that is a file (given that the size is smaller than the page size) is more efficient than memory mapping it. But otherwise, probably not.
You have to count in that, whenever I tell the os or whatever os specific framework I'm using to play the same audio track again, it's highly likely that it is already paged in by the os. In these circumstances, there are some obvious advantages to using memory mapped files.
Not to mention doing 0 syscalls whenever I have to load small files. Which is very, very often.
Your code size seems very large, and I'm not saying that you should expose everything....just support for ptr as input and size.
Pipe is an idea, but seeing as I've inserted a special case for blackberry 10 already, there is no need to change anything . Game runs on much more limited hardware than the alpha device has, and runs great on bb10 so I'm happy .